From marla_azinger at eli.net Wed Dec 1 14:16:59 2004 From: marla_azinger at eli.net (Azinger, Marla) Date: Wed, 1 Dec 2004 11:16:59 -0800 Subject: [ppml] RE: Process improvement for Repeat Proposals Message-ID: <10ECB7F03C568F48B9213EF9E7F790D2627A4C@wava00s2ke2k01.corp.pvt> Is any body out there? Or did everyone pass out from eating to much triptafan in the Turkey? Just looking for some input on the posting I sent out on the 23rd. Cheers! Marla Electric Lightwave -----Original Message----- From: Azinger, Marla Sent: Tuesday, November 23, 2004 9:20 AM To: 'John Brown CT'; Scott.Shackelford at cox.com Cc: Azinger, Marla; randy at psg.com; memsvcs at arin.net; ppml at arin.net Subject: Process improvement for Repeat Proposals Excuse me but I lost track of who made this statement: "Further I'd ad that some policy issues aren't related to integer > managment, but maybe related to people management at the policy orgs". I heard many people agree with this sentiment above at the last meeting. We should keep in mint that this "people management" issue tends to get a little carried away at times in order to try and preserve the "spirit of unabashed input from all". However, there is another suggestion I put forward for a specific reoccuring experience. The experience I am referring to is when a proposal has come back to a conference for discussion and vote for a second, third or God help us all a fourth time. I suggest that when a proposal is coming back for a repeated time that a certain process is put in place. Here it is: 1. Results of the previouse conference discussion in regards to the re-visited proposal be placed up on a slide. This slide should include the summary of all discussion points and the results of voting on those discussion points. I also suggest that discussion points already voted on not be re-debated at the new conference since they have already been voted on. This way...we could move forward alot faster and not spend every conference discussing the same thing over again and not getting anywhere. That is my suggestion. I'm sure it can be added on or improved...but hopefully this starts the way to moving policy proposal a little faster towards its implementation or its abandonment. Marla Azinger Electric Lightwave -----Original Message----- From: John Brown CT [mailto:john at chagres.net] Sent: Tuesday, November 23, 2004 8:50 AM To: Scott.Shackelford at cox.com Cc: marla_azinger at eli.net; randy at psg.com; memsvcs at arin.net; ppml at arin.net Subject: Re: [ppml] composition of and representation on the BoT voteing is a subset of participate. review/comment should be encouraged prior to vote, imho Scott.Shackelford at cox.com wrote: > ammend to say: > > How do we encourage people to read policy, propose new policy, > review/comment/participate on both existing and or new policy? > > And ultimately to become more active in voting which is where I thought > this all started. > > > Scott Shackelford > IP Engineer/IP Administrator > Cox Communications > Office: 404-269-7312 > IM: cypscott > > > > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On Behalf Of John > Brown CT > Sent: Tuesday, November 23, 2004 11:41 AM > To: Azinger, Marla > Cc: Randy Bush; Member Services; ppml at arin.net > Subject: Re: [ppml] composition of and representation on the BoT > > >>"How do we encourage people to read policy, policy proposals and voice > > an > >>opinion?" > > > ammend to say: > > How do we encourage people to read policy, propose new policy, > review/comment/participate on both existing and or new poilicy? > > Further I'd ad that some policy issues aren't related to integer > managment, but maybe related to people management at the policy orgs. > > > From stacy at hilander.com Wed Dec 1 14:30:54 2004 From: stacy at hilander.com (stacy at hilander.com) Date: Wed, 1 Dec 2004 12:30:54 -0700 Subject: [ppml] RE: Process improvement for Repeat Proposals In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D2627A4C@wava00s2ke2k01.corp.pvt> References: <10ECB7F03C568F48B9213EF9E7F790D2627A4C@wava00s2ke2k01.corp.pvt> Message-ID: <1101929454.41ae1bee7409c@www.hilander.com> I wholeheartedly support your idea, Marla. I believe it will relieve much of the hairpulling we who are sentient at the meetings experience due to redundant discussion. We already summarize ppml discussions for the meeting, so it would be great have this summarization too. /s Quoting "Azinger, Marla" : > Is any body out there? Or did everyone pass out from eating to much > triptafan in the Turkey? > > Just looking for some input on the posting I sent out on the 23rd. > > Cheers! > Marla > Electric Lightwave > > -----Original Message----- > From: Azinger, Marla > Sent: Tuesday, November 23, 2004 9:20 AM > To: 'John Brown CT'; Scott.Shackelford at cox.com > Cc: Azinger, Marla; randy at psg.com; memsvcs at arin.net; ppml at arin.net > Subject: Process improvement for Repeat Proposals > > > Excuse me but I lost track of who made this statement: > > "Further I'd ad that some policy issues aren't related to integer > > managment, but maybe related to people management at the policy orgs". > > I heard many people agree with this sentiment above at the last meeting. We > should keep in mint that this "people management" issue tends to get a > little carried away at times in order to try and preserve the "spirit of > unabashed input from all". > > However, there is another suggestion I put forward for a specific reoccuring > experience. The experience I am referring to is when a proposal has come > back to a conference for discussion and vote for a second, third or God help > us all a fourth time. I suggest that when a proposal is coming back for a > repeated time that a certain process is put in place. Here it is: > > 1. Results of the previouse conference discussion in regards to the > re-visited proposal be placed up on a slide. This slide should include the > summary of all discussion points and the results of voting on those > discussion points. I also suggest that discussion points already voted on > not be re-debated at the new conference since they have already been voted > on. This way...we could move forward alot faster and not spend every > conference discussing the same thing over again and not getting anywhere. > > That is my suggestion. I'm sure it can be added on or improved...but > hopefully this starts the way to moving policy proposal a little faster > towards its implementation or its abandonment. > > > Marla Azinger > Electric Lightwave > > > -----Original Message----- > From: John Brown CT [mailto:john at chagres.net] > Sent: Tuesday, November 23, 2004 8:50 AM > To: Scott.Shackelford at cox.com > Cc: marla_azinger at eli.net; randy at psg.com; memsvcs at arin.net; > ppml at arin.net > Subject: Re: [ppml] composition of and representation on the BoT > > > voteing is a subset of participate. review/comment should be > encouraged prior to vote, imho > > Scott.Shackelford at cox.com wrote: > > ammend to say: > > > > How do we encourage people to read policy, propose new policy, > > review/comment/participate on both existing and or new policy? > > > > And ultimately to become more active in voting which is where I thought > > this all started. > > > > > > Scott Shackelford > > IP Engineer/IP Administrator > > Cox Communications > > Office: 404-269-7312 > > IM: cypscott > > > > > > > > -----Original Message----- > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On Behalf Of John > > Brown CT > > Sent: Tuesday, November 23, 2004 11:41 AM > > To: Azinger, Marla > > Cc: Randy Bush; Member Services; ppml at arin.net > > Subject: Re: [ppml] composition of and representation on the BoT > > > > > >>"How do we encourage people to read policy, policy proposals and voice > > > > an > > > >>opinion?" > > > > > > ammend to say: > > > > How do we encourage people to read policy, propose new policy, > > review/comment/participate on both existing and or new poilicy? > > > > Further I'd ad that some policy issues aren't related to integer > > managment, but maybe related to people management at the policy orgs. > > > > > > > From billd at cait.wustl.edu Wed Dec 1 14:42:49 2004 From: billd at cait.wustl.edu (Bill Darte) Date: Wed, 1 Dec 2004 13:42:49 -0600 Subject: [ppml] RE: Process improvement for Repeat Proposals Message-ID: <50C9C45A7E8DCE41A19F7A94715BABFD02A5AE@kronos.cait.wustl.edu> Marla, all, I think any mechanism to first, ensure that a policy proposal is processed 'completely' the first time is our most important task. If it must come back, again agreed, it should be 'focused' in the best way possible to expedite its completion. Limiting discussion at a PP meeting to items that have not been previously discussed is a little tricky though since there may be people present who weren't engaged in the first round of discussion. I think we set ourselves up for a lot of deserved criticism if we limit debate access to people wishing to contribute. I also think that it is crucial the the debate is 1. Well structured, 2. Tighly managed, 3. Directed towards achieving consensus (now). I welcome continued input on what contributes to those objectives (or others that should be included beyond my list of 3). Bill Darte ARIN Advisory Council 314 935-7575 > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Azinger, Marla > Sent: Wednesday, December 01, 2004 1:17 PM > To: Azinger, Marla; 'John Brown CT'; 'Scott.Shackelford at cox.com' > Cc: 'randy at psg.com'; 'memsvcs at arin.net'; 'ppml at arin.net' > Subject: [ppml] RE: Process improvement for Repeat Proposals > > > Is any body out there? Or did everyone pass out from eating > to much triptafan in the Turkey? > > Just looking for some input on the posting I sent out on the 23rd. > > Cheers! > Marla > Electric Lightwave > > -----Original Message----- > From: Azinger, Marla > Sent: Tuesday, November 23, 2004 9:20 AM > To: 'John Brown CT'; Scott.Shackelford at cox.com > Cc: Azinger, Marla; randy at psg.com; memsvcs at arin.net; ppml at arin.net > Subject: Process improvement for Repeat Proposals > > > Excuse me but I lost track of who made this statement: > > "Further I'd ad that some policy issues aren't related to integer > > managment, but maybe related to people management at the > policy orgs". > > I heard many people agree with this sentiment above at the > last meeting. We should keep in mint that this "people > management" issue tends to get a little carried away at times > in order to try and preserve the "spirit of unabashed input from all". > > However, there is another suggestion I put forward for a > specific reoccuring experience. The experience I am > referring to is when a proposal has come back to a conference > for discussion and vote for a second, third or God help us > all a fourth time. I suggest that when a proposal is coming > back for a repeated time that a certain process is put in > place. Here it is: > > 1. Results of the previouse conference discussion in regards > to the re-visited proposal be placed up on a slide. This > slide should include the summary of all discussion points and > the results of voting on those discussion points. I also > suggest that discussion points already voted on not be > re-debated at the new conference since they have already been > voted on. This way...we could move forward alot faster and > not spend every conference discussing the same thing over > again and not getting anywhere. > > That is my suggestion. I'm sure it can be added on or > improved...but hopefully this starts the way to moving policy > proposal a little faster towards its implementation or its > abandonment. > > > Marla Azinger > Electric Lightwave > > > -----Original Message----- > From: John Brown CT [mailto:john at chagres.net] > Sent: Tuesday, November 23, 2004 8:50 AM > To: Scott.Shackelford at cox.com > Cc: marla_azinger at eli.net; randy at psg.com; memsvcs at arin.net; > ppml at arin.net > Subject: Re: [ppml] composition of and representation on the BoT > > > voteing is a subset of participate. review/comment should be > encouraged prior to vote, imho > > Scott.Shackelford at cox.com wrote: > > ammend to say: > > > > How do we encourage people to read policy, propose new policy, > > review/comment/participate on both existing and or new policy? > > > > And ultimately to become more active in voting which is where I > > thought this all started. > > > > > > Scott Shackelford > > IP Engineer/IP Administrator > > Cox Communications > > Office: 404-269-7312 > > IM: cypscott > > > > > > > > -----Original Message----- > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On Behalf Of > > John Brown CT > > Sent: Tuesday, November 23, 2004 11:41 AM > > To: Azinger, Marla > > Cc: Randy Bush; Member Services; ppml at arin.net > > Subject: Re: [ppml] composition of and representation on the BoT > > > > > >>"How do we encourage people to read policy, policy > proposals and voice > > > > an > > > >>opinion?" > > > > > > ammend to say: > > > > How do we encourage people to read policy, propose new policy, > > review/comment/participate on both existing and or new poilicy? > > > > Further I'd ad that some policy issues aren't related to integer > > managment, but maybe related to people management at the > policy orgs. > > > > > > > From marla_azinger at eli.net Wed Dec 1 15:25:01 2004 From: marla_azinger at eli.net (Azinger, Marla) Date: Wed, 1 Dec 2004 12:25:01 -0800 Subject: [ppml] RE: Process improvement for Repeat Proposals Message-ID: <10ECB7F03C568F48B9213EF9E7F790D209B056@wava00s2ke2k01.corp.pvt> Tracey and Bill Thank you for waking up! ha ha Yeah, I was waiting for someone to point out the limitting/cutting off discussion aspect. But you do have a point that if we focus on the 3 pillars you made...it should go alot smoother. Here is my suggestion on how we support these 3 Pillars of proposal discussion. 1. Well structured = This can be acheived through the slide review I suggested? 2. Tighly managed = Limit the time or quantity of remarks in regards to already "debated" topics. Someone would have to be responsible for managing this and ensuring it is abided by. They would have to open the mic in an organized manner. Open Mic Management measures: For example: Open the mic in order of topic 1, topic 2 then open mic for new topics within that policy. obviously we can move to close an old topic discussion within that policy and move on to topic 2 or open mic for new topics if no one chooses to debate any given one again. Topic Debate Management Measures: For example: Open the mic for 5 minutes per topic debate or instead of time go for quantity of remaks and allow 1 to 2 pro's and con's of that topic. This above rule would only apply to previously discussed topics/debates. New topics not brought up previously would not apply to this rule but would in essense be discussed until all points within a reasonable expectation are addressed. 3. Directed towards achieving consensus (now) = Someone keeps track of the different debated topics and their summaies in a votable manner. Then that person or the proposal writer leads everyone through an organized vote based off the topic/debate summaries. Maybe we even change process and take a break from that proposal being discussed in order to redo the slide and then make votes based off of the new updated slide? Thank you for your time Marla Electric Lightwave -----Original Message----- From: Bill Darte [mailto:billd at cait.wustl.edu] Sent: Wednesday, December 01, 2004 11:43 AM To: Azinger, Marla; 'John Brown CT'; 'Scott.Shackelford at cox.com' Cc: 'ppml at arin.net' Subject: RE: [ppml] RE: Process improvement for Repeat Proposals Marla, all, I think any mechanism to first, ensure that a policy proposal is processed 'completely' the first time is our most important task. If it must come back, again agreed, it should be 'focused' in the best way possible to expedite its completion. Limiting discussion at a PP meeting to items that have not been previously discussed is a little tricky though since there may be people present who weren't engaged in the first round of discussion. I think we set ourselves up for a lot of deserved criticism if we limit debate access to people wishing to contribute. I also think that it is crucial the the debate is 1. Well structured, 2. Tighly managed, 3. Directed towards achieving consensus (now). I welcome continued input on what contributes to those objectives (or others that should be included beyond my list of 3). Bill Darte ARIN Advisory Council 314 935-7575 > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Azinger, Marla > Sent: Wednesday, December 01, 2004 1:17 PM > To: Azinger, Marla; 'John Brown CT'; 'Scott.Shackelford at cox.com' > Cc: 'randy at psg.com'; 'memsvcs at arin.net'; 'ppml at arin.net' > Subject: [ppml] RE: Process improvement for Repeat Proposals > > > Is any body out there? Or did everyone pass out from eating > to much triptafan in the Turkey? > > Just looking for some input on the posting I sent out on the 23rd. > > Cheers! > Marla > Electric Lightwave > > -----Original Message----- > From: Azinger, Marla > Sent: Tuesday, November 23, 2004 9:20 AM > To: 'John Brown CT'; Scott.Shackelford at cox.com > Cc: Azinger, Marla; randy at psg.com; memsvcs at arin.net; ppml at arin.net > Subject: Process improvement for Repeat Proposals > > > Excuse me but I lost track of who made this statement: > > "Further I'd ad that some policy issues aren't related to integer > > managment, but maybe related to people management at the > policy orgs". > > I heard many people agree with this sentiment above at the > last meeting. We should keep in mint that this "people > management" issue tends to get a little carried away at times > in order to try and preserve the "spirit of unabashed input from all". > > However, there is another suggestion I put forward for a > specific reoccuring experience. The experience I am > referring to is when a proposal has come back to a conference > for discussion and vote for a second, third or God help us > all a fourth time. I suggest that when a proposal is coming > back for a repeated time that a certain process is put in > place. Here it is: > > 1. Results of the previouse conference discussion in regards > to the re-visited proposal be placed up on a slide. This > slide should include the summary of all discussion points and > the results of voting on those discussion points. I also > suggest that discussion points already voted on not be > re-debated at the new conference since they have already been > voted on. This way...we could move forward alot faster and > not spend every conference discussing the same thing over > again and not getting anywhere. > > That is my suggestion. I'm sure it can be added on or > improved...but hopefully this starts the way to moving policy > proposal a little faster towards its implementation or its > abandonment. > > > Marla Azinger > Electric Lightwave > > > -----Original Message----- > From: John Brown CT [mailto:john at chagres.net] > Sent: Tuesday, November 23, 2004 8:50 AM > To: Scott.Shackelford at cox.com > Cc: marla_azinger at eli.net; randy at psg.com; memsvcs at arin.net; > ppml at arin.net > Subject: Re: [ppml] composition of and representation on the BoT > > > voteing is a subset of participate. review/comment should be > encouraged prior to vote, imho > > Scott.Shackelford at cox.com wrote: > > ammend to say: > > > > How do we encourage people to read policy, propose new policy, > > review/comment/participate on both existing and or new policy? > > > > And ultimately to become more active in voting which is where I > > thought this all started. > > > > > > Scott Shackelford > > IP Engineer/IP Administrator > > Cox Communications > > Office: 404-269-7312 > > IM: cypscott > > > > > > > > -----Original Message----- > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On Behalf Of > > John Brown CT > > Sent: Tuesday, November 23, 2004 11:41 AM > > To: Azinger, Marla > > Cc: Randy Bush; Member Services; ppml at arin.net > > Subject: Re: [ppml] composition of and representation on the BoT > > > > > >>"How do we encourage people to read policy, policy > proposals and voice > > > > an > > > >>opinion?" > > > > > > ammend to say: > > > > How do we encourage people to read policy, propose new policy, > > review/comment/participate on both existing and or new poilicy? > > > > Further I'd ad that some policy issues aren't related to integer > > managment, but maybe related to people management at the > policy orgs. > > > > > > > From billd at cait.wustl.edu Wed Dec 1 15:43:36 2004 From: billd at cait.wustl.edu (Bill Darte) Date: Wed, 1 Dec 2004 14:43:36 -0600 Subject: [ppml] RE: Process improvement for Repeat Proposals Message-ID: <50C9C45A7E8DCE41A19F7A94715BABFD02A5B8@kronos.cait.wustl.edu> So, Marla. Imagine that the first thing on the PP Agenda (1st day) were policy proposals. Voting on these proposals was organized overnight for a vote on the 2nd day...and if some specific preliminaries were needed for 1 or 2 those could be addressed concisely just before the vote.... would this be in line with what you propose under # 3 below? bd > > Tracey and Bill Thank you for waking up! ha ha > > Yeah, I was waiting for someone to point out the > limitting/cutting off discussion aspect. But you do have a > point that if we focus on the 3 pillars you made...it should > go alot smoother. > > Here is my suggestion on how we support these 3 Pillars of > proposal discussion. > > 1. Well structured = This can be acheived through the slide > review I suggested? > > 2. Tighly managed = Limit the time or quantity of remarks > in regards to already "debated" topics. Someone would have > to be responsible for managing this and ensuring it is abided > by. They would have to open the mic in an organized manner. > > Open Mic Management measures: > For example: Open the mic in order of topic 1, topic 2 then > open mic for new topics within that policy. obviously we can > move to close an old topic discussion within that policy and > move on to topic 2 or open mic for new topics if no one > chooses to debate any given one again. > > Topic Debate Management Measures: > For example: Open the mic for 5 minutes per topic debate or > instead of time go for quantity of remaks and allow 1 to 2 > pro's and con's of that topic. This above rule would only > apply to previously discussed topics/debates. New topics not > brought up previously would not apply to this rule but would > in essense be discussed until all points within a reasonable > expectation are addressed. > > 3. Directed towards achieving consensus (now) = Someone > keeps track of the different debated topics and their > summaies in a votable manner. Then that person or the > proposal writer leads everyone through an organized vote > based off the topic/debate summaries. Maybe we even change > process and take a break from that proposal being discussed > in order to redo the slide and then make votes based off of > the new updated slide? > > > Thank you for your time > Marla > Electric Lightwave > > > -----Original Message----- > From: Bill Darte [mailto:billd at cait.wustl.edu] > Sent: Wednesday, December 01, 2004 11:43 AM > To: Azinger, Marla; 'John Brown CT'; 'Scott.Shackelford at cox.com' > Cc: 'ppml at arin.net' > Subject: RE: [ppml] RE: Process improvement for Repeat Proposals > > > Marla, all, > > I think any mechanism to first, ensure that a policy proposal > is processed 'completely' the first time is our most > important task. If it must come back, again agreed, it > should be 'focused' in the best way possible to expedite its > completion. > > Limiting discussion at a PP meeting to items that have not > been previously discussed is a little tricky though since > there may be people present who weren't engaged in the first > round of discussion. I think we set ourselves up for a lot > of deserved criticism if we limit debate access to people > wishing to contribute. > > I also think that it is crucial the the debate is 1. Well > structured, 2. Tighly managed, 3. Directed towards achieving > consensus (now). > > I welcome continued input on what contributes to those > objectives (or others that should be included beyond my list of 3). > > Bill Darte > ARIN Advisory Council > 314 935-7575 > > > > -----Original Message----- > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > > Behalf Of Azinger, Marla > > Sent: Wednesday, December 01, 2004 1:17 PM > > To: Azinger, Marla; 'John Brown CT'; 'Scott.Shackelford at cox.com' > > Cc: 'randy at psg.com'; 'memsvcs at arin.net'; 'ppml at arin.net' > > Subject: [ppml] RE: Process improvement for Repeat Proposals > > > > > > Is any body out there? Or did everyone pass out from eating > > to much triptafan in the Turkey? > > > > Just looking for some input on the posting I sent out on the 23rd. > > > > Cheers! > > Marla > > Electric Lightwave > > > > -----Original Message----- > > From: Azinger, Marla > > Sent: Tuesday, November 23, 2004 9:20 AM > > To: 'John Brown CT'; Scott.Shackelford at cox.com > > Cc: Azinger, Marla; randy at psg.com; memsvcs at arin.net; ppml at arin.net > > Subject: Process improvement for Repeat Proposals > > > > > > Excuse me but I lost track of who made this statement: > > > > "Further I'd ad that some policy issues aren't related to integer > > > managment, but maybe related to people management at the > > policy orgs". > > > > I heard many people agree with this sentiment above at the > > last meeting. We should keep in mint that this "people > > management" issue tends to get a little carried away at times > > in order to try and preserve the "spirit of unabashed input > from all". > > > > However, there is another suggestion I put forward for a > > specific reoccuring experience. The experience I am > > referring to is when a proposal has come back to a conference > > for discussion and vote for a second, third or God help us > > all a fourth time. I suggest that when a proposal is coming > > back for a repeated time that a certain process is put in > > place. Here it is: > > > > 1. Results of the previouse conference discussion in regards > > to the re-visited proposal be placed up on a slide. This > > slide should include the summary of all discussion points and > > the results of voting on those discussion points. I also > > suggest that discussion points already voted on not be > > re-debated at the new conference since they have already been > > voted on. This way...we could move forward alot faster and > > not spend every conference discussing the same thing over > > again and not getting anywhere. > > > > That is my suggestion. I'm sure it can be added on or > > improved...but hopefully this starts the way to moving policy > > proposal a little faster towards its implementation or its > > abandonment. > > > > > > Marla Azinger > > Electric Lightwave > > > > > > -----Original Message----- > > From: John Brown CT [mailto:john at chagres.net] > > Sent: Tuesday, November 23, 2004 8:50 AM > > To: Scott.Shackelford at cox.com > > Cc: marla_azinger at eli.net; randy at psg.com; memsvcs at arin.net; > > ppml at arin.net > > Subject: Re: [ppml] composition of and representation on the BoT > > > > > > voteing is a subset of participate. review/comment should be > > encouraged prior to vote, imho > > > > Scott.Shackelford at cox.com wrote: > > > ammend to say: > > > > > > How do we encourage people to read policy, propose new policy, > > > review/comment/participate on both existing and or new policy? > > > > > > And ultimately to become more active in voting which is where I > > > thought this all started. > > > > > > > > > Scott Shackelford > > > IP Engineer/IP Administrator > > > Cox Communications > > > Office: 404-269-7312 > > > IM: cypscott > > > > > > > > > > > > -----Original Message----- > > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of > > > John Brown CT > > > Sent: Tuesday, November 23, 2004 11:41 AM > > > To: Azinger, Marla > > > Cc: Randy Bush; Member Services; ppml at arin.net > > > Subject: Re: [ppml] composition of and representation on the BoT > > > > > > > > >>"How do we encourage people to read policy, policy > > proposals and voice > > > > > > an > > > > > >>opinion?" > > > > > > > > > ammend to say: > > > > > > How do we encourage people to read policy, propose new policy, > > > review/comment/participate on both existing and or new poilicy? > > > > > > Further I'd ad that some policy issues aren't related to integer > > > managment, but maybe related to people management at the > > policy orgs. > > > > > > > > > > > > From L.Howard at stanleyassociates.com Wed Dec 1 16:23:26 2004 From: L.Howard at stanleyassociates.com (Howard, William L.) Date: Wed, 1 Dec 2004 16:23:26 -0500 Subject: [ppml] RE: Process improvement for Repeat Proposals Message-ID: When you say "voting" . . . ? I could imagine discussion slides listing key points of a proposal, toward building incremental consensus. Lee > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Bill Darte > Sent: Wednesday, December 01, 2004 3:44 PM > To: 'Azinger, Marla'; Bill Darte; 'John Brown CT'; > 'Scott.Shackelford at cox.com' > Cc: 'ppml at arin.net' > Subject: RE: [ppml] RE: Process improvement for Repeat Proposals > > > So, Marla. > Imagine that the first thing on the PP Agenda (1st day) were > policy proposals. Voting on these proposals was organized > overnight for a vote on the 2nd day...and if some specific > preliminaries were needed for 1 or 2 those could be addressed > concisely just before the vote.... would this be in line with > what you propose under # 3 below? > > bd > > > > > > Tracey and Bill Thank you for waking up! ha ha > > > > Yeah, I was waiting for someone to point out the > > limitting/cutting off discussion aspect. But you do have a > > point that if we focus on the 3 pillars you made...it should > > go alot smoother. > > > > Here is my suggestion on how we support these 3 Pillars of > > proposal discussion. > > > > 1. Well structured = This can be acheived through the slide > > review I suggested? > > > > 2. Tighly managed = Limit the time or quantity of remarks > > in regards to already "debated" topics. Someone would have > > to be responsible for managing this and ensuring it is abided > > by. They would have to open the mic in an organized manner. > > > > Open Mic Management measures: > > For example: Open the mic in order of topic 1, topic 2 then > > open mic for new topics within that policy. obviously we can > > move to close an old topic discussion within that policy and > > move on to topic 2 or open mic for new topics if no one > > chooses to debate any given one again. > > > > Topic Debate Management Measures: > > For example: Open the mic for 5 minutes per topic debate or > > instead of time go for quantity of remaks and allow 1 to 2 > > pro's and con's of that topic. This above rule would only > > apply to previously discussed topics/debates. New topics not > > brought up previously would not apply to this rule but would > > in essense be discussed until all points within a reasonable > > expectation are addressed. > > > > 3. Directed towards achieving consensus (now) = Someone > > keeps track of the different debated topics and their > > summaies in a votable manner. Then that person or the > > proposal writer leads everyone through an organized vote > > based off the topic/debate summaries. Maybe we even change > > process and take a break from that proposal being discussed > > in order to redo the slide and then make votes based off of > > the new updated slide? > > > > > > Thank you for your time > > Marla > > Electric Lightwave > > > > > > -----Original Message----- > > From: Bill Darte [mailto:billd at cait.wustl.edu] > > Sent: Wednesday, December 01, 2004 11:43 AM > > To: Azinger, Marla; 'John Brown CT'; 'Scott.Shackelford at cox.com' > > Cc: 'ppml at arin.net' > > Subject: RE: [ppml] RE: Process improvement for Repeat Proposals > > > > > > Marla, all, > > > > I think any mechanism to first, ensure that a policy proposal > > is processed 'completely' the first time is our most > > important task. If it must come back, again agreed, it > > should be 'focused' in the best way possible to expedite its > > completion. > > > > Limiting discussion at a PP meeting to items that have not > > been previously discussed is a little tricky though since > > there may be people present who weren't engaged in the first > > round of discussion. I think we set ourselves up for a lot > > of deserved criticism if we limit debate access to people > > wishing to contribute. > > > > I also think that it is crucial the the debate is 1. Well > > structured, 2. Tighly managed, 3. Directed towards achieving > > consensus (now). > > > > I welcome continued input on what contributes to those > > objectives (or others that should be included beyond my list of 3). > > > > Bill Darte > > ARIN Advisory Council > > 314 935-7575 > > > > > > > -----Original Message----- > > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of > > > Azinger, Marla > > > Sent: Wednesday, December 01, 2004 1:17 PM > > > To: Azinger, Marla; 'John Brown CT'; 'Scott.Shackelford at cox.com' > > > Cc: 'randy at psg.com'; 'memsvcs at arin.net'; 'ppml at arin.net' > > > Subject: [ppml] RE: Process improvement for Repeat Proposals > > > > > > > > > Is any body out there? Or did everyone pass out from > eating to much > > > triptafan in the Turkey? > > > > > > Just looking for some input on the posting I sent out on the 23rd. > > > > > > Cheers! > > > Marla > > > Electric Lightwave > > > > > > -----Original Message----- > > > From: Azinger, Marla > > > Sent: Tuesday, November 23, 2004 9:20 AM > > > To: 'John Brown CT'; Scott.Shackelford at cox.com > > > Cc: Azinger, Marla; randy at psg.com; memsvcs at arin.net; ppml at arin.net > > > Subject: Process improvement for Repeat Proposals > > > > > > > > > Excuse me but I lost track of who made this statement: > > > > > > "Further I'd ad that some policy issues aren't related to integer > > > > managment, but maybe related to people management at the > > > policy orgs". > > > > > > I heard many people agree with this sentiment above at the last > > > meeting. We should keep in mint that this "people > management" issue > > > tends to get a little carried away at times in order to try and > > > preserve the "spirit of unabashed input > > from all". > > > > > > However, there is another suggestion I put forward for a specific > > > reoccuring experience. The experience I am referring to > is when a > > > proposal has come back to a conference for discussion and > vote for a > > > second, third or God help us all a fourth time. I > suggest that when > > > a proposal is coming back for a repeated time that a > certain process > > > is put in place. Here it is: > > > > > > 1. Results of the previouse conference discussion in > regards to the > > > re-visited proposal be placed up on a slide. This slide should > > > include the summary of all discussion points and the results of > > > voting on those discussion points. I also suggest that > discussion > > > points already voted on not be re-debated at the new conference > > > since they have already been voted on. This way...we could move > > > forward alot faster and not spend every conference discussing the > > > same thing over again and not getting anywhere. > > > > > > That is my suggestion. I'm sure it can be added on or > > > improved...but hopefully this starts the way to moving policy > > > proposal a little faster towards its implementation or its > > > abandonment. > > > > > > > > > Marla Azinger > > > Electric Lightwave > > > > > > > > > -----Original Message----- > > > From: John Brown CT [mailto:john at chagres.net] > > > Sent: Tuesday, November 23, 2004 8:50 AM > > > To: Scott.Shackelford at cox.com > > > Cc: marla_azinger at eli.net; randy at psg.com; memsvcs at arin.net; > > > ppml at arin.net > > > Subject: Re: [ppml] composition of and representation on the BoT > > > > > > > > > voteing is a subset of participate. review/comment should be > > > encouraged prior to vote, imho > > > > > > Scott.Shackelford at cox.com wrote: > > > > ammend to say: > > > > > > > > How do we encourage people to read policy, propose new policy, > > > > review/comment/participate on both existing and or new policy? > > > > > > > > And ultimately to become more active in voting which is where I > > > > thought this all started. > > > > > > > > > > > > Scott Shackelford > > > > IP Engineer/IP Administrator > > > > Cox Communications > > > > Office: 404-269-7312 > > > > IM: cypscott > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > > Behalf Of > > > > John Brown CT > > > > Sent: Tuesday, November 23, 2004 11:41 AM > > > > To: Azinger, Marla > > > > Cc: Randy Bush; Member Services; ppml at arin.net > > > > Subject: Re: [ppml] composition of and representation on the BoT > > > > > > > > > > > >>"How do we encourage people to read policy, policy > > > proposals and voice > > > > > > > > an > > > > > > > >>opinion?" > > > > > > > > > > > > ammend to say: > > > > > > > > How do we encourage people to read policy, propose new policy, > > > > review/comment/participate on both existing and or new poilicy? > > > > > > > > Further I'd ad that some policy issues aren't related to integer > > > > managment, but maybe related to people management at the > > > policy orgs. > > > > > > > > > > > > > > > > > > From marla_azinger at eli.net Wed Dec 1 16:38:13 2004 From: marla_azinger at eli.net (Azinger, Marla) Date: Wed, 1 Dec 2004 13:38:13 -0800 Subject: [ppml] RE: Process improvement for Repeat Proposals Message-ID: <10ECB7F03C568F48B9213EF9E7F790D2627A53@wava00s2ke2k01.corp.pvt> Yes. Either the next day or at the end of the day depending on when that day the proposal was discussed. MA -----Original Message----- From: Bill Darte [mailto:billd at cait.wustl.edu] Sent: Wednesday, December 01, 2004 12:44 PM To: Azinger, Marla; Bill Darte; 'John Brown CT'; 'Scott.Shackelford at cox.com' Cc: 'ppml at arin.net' Subject: RE: [ppml] RE: Process improvement for Repeat Proposals So, Marla. Imagine that the first thing on the PP Agenda (1st day) were policy proposals. Voting on these proposals was organized overnight for a vote on the 2nd day...and if some specific preliminaries were needed for 1 or 2 those could be addressed concisely just before the vote.... would this be in line with what you propose under # 3 below? bd > > Tracey and Bill Thank you for waking up! ha ha > > Yeah, I was waiting for someone to point out the > limitting/cutting off discussion aspect. But you do have a > point that if we focus on the 3 pillars you made...it should > go alot smoother. > > Here is my suggestion on how we support these 3 Pillars of > proposal discussion. > > 1. Well structured = This can be acheived through the slide > review I suggested? > > 2. Tighly managed = Limit the time or quantity of remarks > in regards to already "debated" topics. Someone would have > to be responsible for managing this and ensuring it is abided > by. They would have to open the mic in an organized manner. > > Open Mic Management measures: > For example: Open the mic in order of topic 1, topic 2 then > open mic for new topics within that policy. obviously we can > move to close an old topic discussion within that policy and > move on to topic 2 or open mic for new topics if no one > chooses to debate any given one again. > > Topic Debate Management Measures: > For example: Open the mic for 5 minutes per topic debate or > instead of time go for quantity of remaks and allow 1 to 2 > pro's and con's of that topic. This above rule would only > apply to previously discussed topics/debates. New topics not > brought up previously would not apply to this rule but would > in essense be discussed until all points within a reasonable > expectation are addressed. > > 3. Directed towards achieving consensus (now) = Someone > keeps track of the different debated topics and their > summaies in a votable manner. Then that person or the > proposal writer leads everyone through an organized vote > based off the topic/debate summaries. Maybe we even change > process and take a break from that proposal being discussed > in order to redo the slide and then make votes based off of > the new updated slide? > > > Thank you for your time > Marla > Electric Lightwave > > > -----Original Message----- > From: Bill Darte [mailto:billd at cait.wustl.edu] > Sent: Wednesday, December 01, 2004 11:43 AM > To: Azinger, Marla; 'John Brown CT'; 'Scott.Shackelford at cox.com' > Cc: 'ppml at arin.net' > Subject: RE: [ppml] RE: Process improvement for Repeat Proposals > > > Marla, all, > > I think any mechanism to first, ensure that a policy proposal > is processed 'completely' the first time is our most > important task. If it must come back, again agreed, it > should be 'focused' in the best way possible to expedite its > completion. > > Limiting discussion at a PP meeting to items that have not > been previously discussed is a little tricky though since > there may be people present who weren't engaged in the first > round of discussion. I think we set ourselves up for a lot > of deserved criticism if we limit debate access to people > wishing to contribute. > > I also think that it is crucial the the debate is 1. Well > structured, 2. Tighly managed, 3. Directed towards achieving > consensus (now). > > I welcome continued input on what contributes to those > objectives (or others that should be included beyond my list of 3). > > Bill Darte > ARIN Advisory Council > 314 935-7575 > > > > -----Original Message----- > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > > Behalf Of Azinger, Marla > > Sent: Wednesday, December 01, 2004 1:17 PM > > To: Azinger, Marla; 'John Brown CT'; 'Scott.Shackelford at cox.com' > > Cc: 'randy at psg.com'; 'memsvcs at arin.net'; 'ppml at arin.net' > > Subject: [ppml] RE: Process improvement for Repeat Proposals > > > > > > Is any body out there? Or did everyone pass out from eating > > to much triptafan in the Turkey? > > > > Just looking for some input on the posting I sent out on the 23rd. > > > > Cheers! > > Marla > > Electric Lightwave > > > > -----Original Message----- > > From: Azinger, Marla > > Sent: Tuesday, November 23, 2004 9:20 AM > > To: 'John Brown CT'; Scott.Shackelford at cox.com > > Cc: Azinger, Marla; randy at psg.com; memsvcs at arin.net; ppml at arin.net > > Subject: Process improvement for Repeat Proposals > > > > > > Excuse me but I lost track of who made this statement: > > > > "Further I'd ad that some policy issues aren't related to integer > > > managment, but maybe related to people management at the > > policy orgs". > > > > I heard many people agree with this sentiment above at the > > last meeting. We should keep in mint that this "people > > management" issue tends to get a little carried away at times > > in order to try and preserve the "spirit of unabashed input > from all". > > > > However, there is another suggestion I put forward for a > > specific reoccuring experience. The experience I am > > referring to is when a proposal has come back to a conference > > for discussion and vote for a second, third or God help us > > all a fourth time. I suggest that when a proposal is coming > > back for a repeated time that a certain process is put in > > place. Here it is: > > > > 1. Results of the previouse conference discussion in regards > > to the re-visited proposal be placed up on a slide. This > > slide should include the summary of all discussion points and > > the results of voting on those discussion points. I also > > suggest that discussion points already voted on not be > > re-debated at the new conference since they have already been > > voted on. This way...we could move forward alot faster and > > not spend every conference discussing the same thing over > > again and not getting anywhere. > > > > That is my suggestion. I'm sure it can be added on or > > improved...but hopefully this starts the way to moving policy > > proposal a little faster towards its implementation or its > > abandonment. > > > > > > Marla Azinger > > Electric Lightwave > > > > > > -----Original Message----- > > From: John Brown CT [mailto:john at chagres.net] > > Sent: Tuesday, November 23, 2004 8:50 AM > > To: Scott.Shackelford at cox.com > > Cc: marla_azinger at eli.net; randy at psg.com; memsvcs at arin.net; > > ppml at arin.net > > Subject: Re: [ppml] composition of and representation on the BoT > > > > > > voteing is a subset of participate. review/comment should be > > encouraged prior to vote, imho > > > > Scott.Shackelford at cox.com wrote: > > > ammend to say: > > > > > > How do we encourage people to read policy, propose new policy, > > > review/comment/participate on both existing and or new policy? > > > > > > And ultimately to become more active in voting which is where I > > > thought this all started. > > > > > > > > > Scott Shackelford > > > IP Engineer/IP Administrator > > > Cox Communications > > > Office: 404-269-7312 > > > IM: cypscott > > > > > > > > > > > > -----Original Message----- > > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of > > > John Brown CT > > > Sent: Tuesday, November 23, 2004 11:41 AM > > > To: Azinger, Marla > > > Cc: Randy Bush; Member Services; ppml at arin.net > > > Subject: Re: [ppml] composition of and representation on the BoT > > > > > > > > >>"How do we encourage people to read policy, policy > > proposals and voice > > > > > > an > > > > > >>opinion?" > > > > > > > > > ammend to say: > > > > > > How do we encourage people to read policy, propose new policy, > > > review/comment/participate on both existing and or new poilicy? > > > > > > Further I'd ad that some policy issues aren't related to integer > > > managment, but maybe related to people management at the > > policy orgs. > > > > > > > > > > > > From marla_azinger at eli.net Wed Dec 1 16:40:39 2004 From: marla_azinger at eli.net (Azinger, Marla) Date: Wed, 1 Dec 2004 13:40:39 -0800 Subject: [ppml] RE: Process improvement for Repeat Proposals Message-ID: <10ECB7F03C568F48B9213EF9E7F790D2627A54@wava00s2ke2k01.corp.pvt> Yes. All topic votes within the realm of the proposal will be voted on leading up to an end all final vote of the proposal itself. Marla -----Original Message----- From: Howard, William L. [mailto:L.Howard at stanleyassociates.com] Sent: Wednesday, December 01, 2004 1:23 PM To: 'Bill Darte'; Azinger, Marla; 'John Brown CT'; 'Scott.Shackelford at cox.com' Cc: 'ppml at arin.net' Subject: RE: [ppml] RE: Process improvement for Repeat Proposals When you say "voting" . . . ? I could imagine discussion slides listing key points of a proposal, toward building incremental consensus. Lee > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Bill Darte > Sent: Wednesday, December 01, 2004 3:44 PM > To: 'Azinger, Marla'; Bill Darte; 'John Brown CT'; > 'Scott.Shackelford at cox.com' > Cc: 'ppml at arin.net' > Subject: RE: [ppml] RE: Process improvement for Repeat Proposals > > > So, Marla. > Imagine that the first thing on the PP Agenda (1st day) were > policy proposals. Voting on these proposals was organized > overnight for a vote on the 2nd day...and if some specific > preliminaries were needed for 1 or 2 those could be addressed > concisely just before the vote.... would this be in line with > what you propose under # 3 below? > > bd > > > > > > Tracey and Bill Thank you for waking up! ha ha > > > > Yeah, I was waiting for someone to point out the > > limitting/cutting off discussion aspect. But you do have a > > point that if we focus on the 3 pillars you made...it should > > go alot smoother. > > > > Here is my suggestion on how we support these 3 Pillars of > > proposal discussion. > > > > 1. Well structured = This can be acheived through the slide > > review I suggested? > > > > 2. Tighly managed = Limit the time or quantity of remarks > > in regards to already "debated" topics. Someone would have > > to be responsible for managing this and ensuring it is abided > > by. They would have to open the mic in an organized manner. > > > > Open Mic Management measures: > > For example: Open the mic in order of topic 1, topic 2 then > > open mic for new topics within that policy. obviously we can > > move to close an old topic discussion within that policy and > > move on to topic 2 or open mic for new topics if no one > > chooses to debate any given one again. > > > > Topic Debate Management Measures: > > For example: Open the mic for 5 minutes per topic debate or > > instead of time go for quantity of remaks and allow 1 to 2 > > pro's and con's of that topic. This above rule would only > > apply to previously discussed topics/debates. New topics not > > brought up previously would not apply to this rule but would > > in essense be discussed until all points within a reasonable > > expectation are addressed. > > > > 3. Directed towards achieving consensus (now) = Someone > > keeps track of the different debated topics and their > > summaies in a votable manner. Then that person or the > > proposal writer leads everyone through an organized vote > > based off the topic/debate summaries. Maybe we even change > > process and take a break from that proposal being discussed > > in order to redo the slide and then make votes based off of > > the new updated slide? > > > > > > Thank you for your time > > Marla > > Electric Lightwave > > > > > > -----Original Message----- > > From: Bill Darte [mailto:billd at cait.wustl.edu] > > Sent: Wednesday, December 01, 2004 11:43 AM > > To: Azinger, Marla; 'John Brown CT'; 'Scott.Shackelford at cox.com' > > Cc: 'ppml at arin.net' > > Subject: RE: [ppml] RE: Process improvement for Repeat Proposals > > > > > > Marla, all, > > > > I think any mechanism to first, ensure that a policy proposal > > is processed 'completely' the first time is our most > > important task. If it must come back, again agreed, it > > should be 'focused' in the best way possible to expedite its > > completion. > > > > Limiting discussion at a PP meeting to items that have not > > been previously discussed is a little tricky though since > > there may be people present who weren't engaged in the first > > round of discussion. I think we set ourselves up for a lot > > of deserved criticism if we limit debate access to people > > wishing to contribute. > > > > I also think that it is crucial the the debate is 1. Well > > structured, 2. Tighly managed, 3. Directed towards achieving > > consensus (now). > > > > I welcome continued input on what contributes to those > > objectives (or others that should be included beyond my list of 3). > > > > Bill Darte > > ARIN Advisory Council > > 314 935-7575 > > > > > > > -----Original Message----- > > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of > > > Azinger, Marla > > > Sent: Wednesday, December 01, 2004 1:17 PM > > > To: Azinger, Marla; 'John Brown CT'; 'Scott.Shackelford at cox.com' > > > Cc: 'randy at psg.com'; 'memsvcs at arin.net'; 'ppml at arin.net' > > > Subject: [ppml] RE: Process improvement for Repeat Proposals > > > > > > > > > Is any body out there? Or did everyone pass out from > eating to much > > > triptafan in the Turkey? > > > > > > Just looking for some input on the posting I sent out on the 23rd. > > > > > > Cheers! > > > Marla > > > Electric Lightwave > > > > > > -----Original Message----- > > > From: Azinger, Marla > > > Sent: Tuesday, November 23, 2004 9:20 AM > > > To: 'John Brown CT'; Scott.Shackelford at cox.com > > > Cc: Azinger, Marla; randy at psg.com; memsvcs at arin.net; ppml at arin.net > > > Subject: Process improvement for Repeat Proposals > > > > > > > > > Excuse me but I lost track of who made this statement: > > > > > > "Further I'd ad that some policy issues aren't related to integer > > > > managment, but maybe related to people management at the > > > policy orgs". > > > > > > I heard many people agree with this sentiment above at the last > > > meeting. We should keep in mint that this "people > management" issue > > > tends to get a little carried away at times in order to try and > > > preserve the "spirit of unabashed input > > from all". > > > > > > However, there is another suggestion I put forward for a specific > > > reoccuring experience. The experience I am referring to > is when a > > > proposal has come back to a conference for discussion and > vote for a > > > second, third or God help us all a fourth time. I > suggest that when > > > a proposal is coming back for a repeated time that a > certain process > > > is put in place. Here it is: > > > > > > 1. Results of the previouse conference discussion in > regards to the > > > re-visited proposal be placed up on a slide. This slide should > > > include the summary of all discussion points and the results of > > > voting on those discussion points. I also suggest that > discussion > > > points already voted on not be re-debated at the new conference > > > since they have already been voted on. This way...we could move > > > forward alot faster and not spend every conference discussing the > > > same thing over again and not getting anywhere. > > > > > > That is my suggestion. I'm sure it can be added on or > > > improved...but hopefully this starts the way to moving policy > > > proposal a little faster towards its implementation or its > > > abandonment. > > > > > > > > > Marla Azinger > > > Electric Lightwave > > > > > > > > > -----Original Message----- > > > From: John Brown CT [mailto:john at chagres.net] > > > Sent: Tuesday, November 23, 2004 8:50 AM > > > To: Scott.Shackelford at cox.com > > > Cc: marla_azinger at eli.net; randy at psg.com; memsvcs at arin.net; > > > ppml at arin.net > > > Subject: Re: [ppml] composition of and representation on the BoT > > > > > > > > > voteing is a subset of participate. review/comment should be > > > encouraged prior to vote, imho > > > > > > Scott.Shackelford at cox.com wrote: > > > > ammend to say: > > > > > > > > How do we encourage people to read policy, propose new policy, > > > > review/comment/participate on both existing and or new policy? > > > > > > > > And ultimately to become more active in voting which is where I > > > > thought this all started. > > > > > > > > > > > > Scott Shackelford > > > > IP Engineer/IP Administrator > > > > Cox Communications > > > > Office: 404-269-7312 > > > > IM: cypscott > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > > Behalf Of > > > > John Brown CT > > > > Sent: Tuesday, November 23, 2004 11:41 AM > > > > To: Azinger, Marla > > > > Cc: Randy Bush; Member Services; ppml at arin.net > > > > Subject: Re: [ppml] composition of and representation on the BoT > > > > > > > > > > > >>"How do we encourage people to read policy, policy > > > proposals and voice > > > > > > > > an > > > > > > > >>opinion?" > > > > > > > > > > > > ammend to say: > > > > > > > > How do we encourage people to read policy, propose new policy, > > > > review/comment/participate on both existing and or new poilicy? > > > > > > > > Further I'd ad that some policy issues aren't related to integer > > > > managment, but maybe related to people management at the > > > policy orgs. > > > > > > > > > > > > > > > > > > From gregm at datapro.co.za Thu Dec 2 06:17:03 2004 From: gregm at datapro.co.za (Gregory Massel) Date: Thu, 2 Dec 2004 13:17:03 +0200 Subject: [ppml] RE: Process improvement for Repeat Proposals References: <10ECB7F03C568F48B9213EF9E7F790D2627A4C@wava00s2ke2k01.corp.pvt> Message-ID: <006201c4d860$73bc3230$68f223c4@gregm> > 1. Results of the previouse conference discussion in regards to the > re-visited proposal be placed up on a slide. This slide should include > the > summary of all discussion points and the results of voting on those > discussion points. I also suggest that discussion points already voted on > not be re-debated at the new conference since they have already been voted > on. This way...we could move forward alot faster and not spend every > conference discussing the same thing over again and not getting anywhere. I agree. It may, however, be quite tricky to implement, depending on the level of detail of minutes taken at meetings. From L.Howard at stanleyassociates.com Thu Dec 2 08:59:58 2004 From: L.Howard at stanleyassociates.com (Howard, William L.) Date: Thu, 2 Dec 2004 08:59:58 -0500 Subject: [ppml] RE: Process improvement for Repeat Proposals Message-ID: It may seem like a fine distinction, but. . . We don't vote at public policy meetings. Elections begin after public policy meetings. ARIN facilitates regional ASO elections, which may coincide with ARIN meetings. We don't vote on policy proposals in whole or in part, because a key part of the policy process is the participation of the public on the mailing lists. Consensus at a meeting may be outweighed by lack of consensus on mailing lists. When we use a show of hands to get a sense of the room, it's to determine whether there's a large amount of silent support for or opposition to a proposed policy. This is input for the AC to judge the level of consensus. My description of what you're suggesting would be: 1. The text of the proposed policy is read. If the proposed policy is to verbose to read, it's probably too complicated to consider in a public meeting. 2. Einar describes the discussion on the mailing list. 3. Key points (as identified by the AC) are presented, bulletized, for discussion. The length of discussion on each is limited. 4. Any additional points for discussion are raised. This would give the AC clearer feedback on what parts of a proposal (failed to) receive(d) support, so they could adjust the wording as needed. Lee > -----Original Message----- > From: Azinger, Marla [mailto:marla_azinger at eli.net] > Sent: Wednesday, December 01, 2004 4:41 PM > To: 'Howard, William L.'; 'Bill Darte'; 'John Brown CT'; > 'Scott.Shackelford at cox.com' > Cc: 'ppml at arin.net' > Subject: RE: [ppml] RE: Process improvement for Repeat Proposals > > > Yes. All topic votes within the realm of the proposal will > be voted on leading up to an end all final vote of the > proposal itself. > > Marla > > -----Original Message----- > From: Howard, William L. [mailto:L.Howard at stanleyassociates.com] > Sent: Wednesday, December 01, 2004 1:23 PM > To: 'Bill Darte'; Azinger, Marla; 'John Brown CT'; > 'Scott.Shackelford at cox.com' > Cc: 'ppml at arin.net' > Subject: RE: [ppml] RE: Process improvement for Repeat Proposals > > > When you say "voting" . . . ? > > I could imagine discussion slides listing key points of a > proposal, toward building incremental consensus. > > Lee > > > > -----Original Message----- > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > > Behalf Of Bill Darte > > Sent: Wednesday, December 01, 2004 3:44 PM > > To: 'Azinger, Marla'; Bill Darte; 'John Brown CT'; > > 'Scott.Shackelford at cox.com' > > Cc: 'ppml at arin.net' > > Subject: RE: [ppml] RE: Process improvement for Repeat Proposals > > > > > > So, Marla. > > Imagine that the first thing on the PP Agenda (1st day) were > > policy proposals. Voting on these proposals was organized > > overnight for a vote on the 2nd day...and if some specific > > preliminaries were needed for 1 or 2 those could be addressed > > concisely just before the vote.... would this be in line with > > what you propose under # 3 below? > > > > bd > > > > > > > > > > Tracey and Bill Thank you for waking up! ha ha > > > > > > Yeah, I was waiting for someone to point out the > limitting/cutting > > > off discussion aspect. But you do have a point that if > we focus on > > > the 3 pillars you made...it should go alot smoother. > > > > > > Here is my suggestion on how we support these 3 Pillars > of proposal > > > discussion. > > > > > > 1. Well structured = This can be acheived through the > slide review > > > I suggested? > > > > > > 2. Tighly managed = Limit the time or quantity of remarks in > > > regards to already "debated" topics. Someone would have to be > > > responsible for managing this and ensuring it is abided by. They > > > would have to open the mic in an organized manner. > > > > > > Open Mic Management measures: > > > For example: Open the mic in order of topic 1, topic 2 then open > > > mic for new topics within that policy. obviously we can move to > > > close an old topic discussion within that policy and move on to > > > topic 2 or open mic for new topics if no one chooses to > debate any > > > given one again. > > > > > > Topic Debate Management Measures: > > > For example: Open the mic for 5 minutes per topic debate > or instead > > > of time go for quantity of remaks and allow 1 to 2 pro's > and con's > > > of that topic. This above rule would only apply to previously > > > discussed topics/debates. New topics not brought up > previously would > > > not apply to this rule but would in essense be discussed > until all > > > points within a reasonable expectation are addressed. > > > > > > 3. Directed towards achieving consensus (now) = Someone keeps > > > track of the different debated topics and their summaies in a > > > votable manner. Then that person or the proposal writer leads > > > everyone through an organized vote based off the topic/debate > > > summaries. Maybe we even change process and take a break > from that > > > proposal being discussed in order to redo the slide and then make > > > votes based off of the new updated slide? > > > > > > > > > Thank you for your time > > > Marla > > > Electric Lightwave > > > > > > > > > -----Original Message----- > > > From: Bill Darte [mailto:billd at cait.wustl.edu] > > > Sent: Wednesday, December 01, 2004 11:43 AM > > > To: Azinger, Marla; 'John Brown CT'; 'Scott.Shackelford at cox.com' > > > Cc: 'ppml at arin.net' > > > Subject: RE: [ppml] RE: Process improvement for Repeat Proposals > > > > > > > > > Marla, all, > > > > > > I think any mechanism to first, ensure that a policy proposal is > > > processed 'completely' the first time is our most > important task. > > > If it must come back, again agreed, it should be 'focused' in the > > > best way possible to expedite its completion. > > > > > > Limiting discussion at a PP meeting to items that have not been > > > previously discussed is a little tricky though since there may be > > > people present who weren't engaged in the first round of > discussion. > > > I think we set ourselves up for a lot of deserved criticism if we > > > limit debate access to people wishing to contribute. > > > > > > I also think that it is crucial the the debate is 1. Well > > > structured, 2. Tighly managed, 3. Directed towards achieving > > > consensus (now). > > > > > > I welcome continued input on what contributes to those objectives > > > (or others that should be included beyond my list of 3). > > > > > > Bill Darte > > > ARIN Advisory Council > > > 314 935-7575 > > > > > > > > > > -----Original Message----- > > > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > > Behalf Of > > > > Azinger, Marla > > > > Sent: Wednesday, December 01, 2004 1:17 PM > > > > To: Azinger, Marla; 'John Brown CT'; 'Scott.Shackelford at cox.com' > > > > Cc: 'randy at psg.com'; 'memsvcs at arin.net'; 'ppml at arin.net' > > > > Subject: [ppml] RE: Process improvement for Repeat Proposals > > > > > > > > > > > > Is any body out there? Or did everyone pass out from > > eating to much > > > > triptafan in the Turkey? > > > > > > > > Just looking for some input on the posting I sent out > on the 23rd. > > > > > > > > Cheers! > > > > Marla > > > > Electric Lightwave > > > > > > > > -----Original Message----- > > > > From: Azinger, Marla > > > > Sent: Tuesday, November 23, 2004 9:20 AM > > > > To: 'John Brown CT'; Scott.Shackelford at cox.com > > > > Cc: Azinger, Marla; randy at psg.com; memsvcs at arin.net; > ppml at arin.net > > > > Subject: Process improvement for Repeat Proposals > > > > > > > > > > > > Excuse me but I lost track of who made this statement: > > > > > > > > "Further I'd ad that some policy issues aren't related > to integer > > > > > managment, but maybe related to people management at the > > > > policy orgs". > > > > > > > > I heard many people agree with this sentiment above at the last > > > > meeting. We should keep in mint that this "people > > management" issue > > > > tends to get a little carried away at times in order to try and > > > > preserve the "spirit of unabashed input > > > from all". > > > > > > > > However, there is another suggestion I put forward for > a specific > > > > reoccuring experience. The experience I am referring to > > is when a > > > > proposal has come back to a conference for discussion and > > vote for a > > > > second, third or God help us all a fourth time. I > > suggest that when > > > > a proposal is coming back for a repeated time that a > > certain process > > > > is put in place. Here it is: > > > > > > > > 1. Results of the previouse conference discussion in > > regards to the > > > > re-visited proposal be placed up on a slide. This slide should > > > > include the summary of all discussion points and the results of > > > > voting on those discussion points. I also suggest that > > discussion > > > > points already voted on not be re-debated at the new conference > > > > since they have already been voted on. This way...we > could move > > > > forward alot faster and not spend every conference > discussing the > > > > same thing over again and not getting anywhere. > > > > > > > > That is my suggestion. I'm sure it can be added on or > > > > improved...but hopefully this starts the way to moving policy > > > > proposal a little faster towards its implementation or its > > > > abandonment. > > > > > > > > > > > > Marla Azinger > > > > Electric Lightwave > > > > > > > > > > > > -----Original Message----- > > > > From: John Brown CT [mailto:john at chagres.net] > > > > Sent: Tuesday, November 23, 2004 8:50 AM > > > > To: Scott.Shackelford at cox.com > > > > Cc: marla_azinger at eli.net; randy at psg.com; memsvcs at arin.net; > > > > ppml at arin.net > > > > Subject: Re: [ppml] composition of and representation on the BoT > > > > > > > > > > > > voteing is a subset of participate. review/comment should be > > > > encouraged prior to vote, imho > > > > > > > > Scott.Shackelford at cox.com wrote: > > > > > ammend to say: > > > > > > > > > > How do we encourage people to read policy, propose > new policy, > > > > > review/comment/participate on both existing and or new policy? > > > > > > > > > > And ultimately to become more active in voting which > is where I > > > > > thought this all started. > > > > > > > > > > > > > > > Scott Shackelford > > > > > IP Engineer/IP Administrator > > > > > Cox Communications > > > > > Office: 404-269-7312 > > > > > IM: cypscott > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > > > Behalf Of > > > > > John Brown CT > > > > > Sent: Tuesday, November 23, 2004 11:41 AM > > > > > To: Azinger, Marla > > > > > Cc: Randy Bush; Member Services; ppml at arin.net > > > > > Subject: Re: [ppml] composition of and representation > on the BoT > > > > > > > > > > > > > > >>"How do we encourage people to read policy, policy > > > > proposals and voice > > > > > > > > > > an > > > > > > > > > >>opinion?" > > > > > > > > > > > > > > > ammend to say: > > > > > > > > > > How do we encourage people to read policy, propose > new policy, > > > > > review/comment/participate on both existing and or > new poilicy? > > > > > > > > > > Further I'd ad that some policy issues aren't related > to integer > > > > > managment, but maybe related to people management at the > > > > policy orgs. > > > > > > > > > > > > > > > > > > > > > > > > > From plzak at arin.net Thu Dec 2 11:22:26 2004 From: plzak at arin.net (Ray Plzak) Date: Thu, 2 Dec 2004 11:22:26 -0500 Subject: [ppml] ULA Discussion in ARIN Message-ID: <20041202162019.8919F1FE89@mercury.arin.net> As I said in an earlier email regarding activity in the IETF, the IETF is composed of individuals not organizations. The likelihood is that a single letter from ARIN would be viewed as one contribution not a representative, collective contribution from a body of people. For this reason, ARIN, as an organization will not be making a position statement regarding ULA. Each concerned person in the ARIN community needs to speak individually about this issue. The IETF works best when people directly contribute to the discussion and consensus building process. I invite the IESG to note all of the comments made on this list as they evaluate the ULA draft. Raymond A. Plzak President and CEO ARIN From memsvcs at arin.net Thu Dec 2 16:34:17 2004 From: memsvcs at arin.net (Member Services) Date: Thu, 2 Dec 2004 16:34:17 -0500 (EST) Subject: [ppml] Proposed Policy: PI assignments for V6 Message-ID: ARIN received the following proposed policy. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List and being placed on ARIN's website. The ARIN Advisory Council will review the proposal and within ten working days may decide to: 1) support the proposal as is, 2) work with the author to clarify, divide or combine one or more policy proposals, or 3) not support the policy proposal. If the AC supports the proposal or reaches an agreement to work with the author, then the proposal will be posted as a formal policy proposal to the Public Policy Mailing List and it will be presented at the Public Policy Meeting. If the AC does not support the proposal, then the author may elect to use the petition process to advance the proposal. If the author elects not to petition or the petition fails, then the proposed policy will be considered closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/ipep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal Name: PI assignments for V6 Author: Owen DeLong Policy term: permanent Policy statement: Any end-site or other organization which meets the current tests for assignment of an autonomous system number (ASN) shall also qualify for one IPv6 prefix assignment or allocation of the minimum size justified by them under the ARIN guidelines for LIR assignment to such an organization. If the organization wishes to receive an allocation, they must meet the tests for being an LIR, except that this smaller allocation will not require a plan for assigning to an additional 200 organizations. To qualify as an LIR under this policy, the organization must have the intent of assigning to additional organizations, and, should be able to show ARIN reasonable evidence of such intent. If the organization grows to require more space, they will not be entitled to an additional block, but, may obtain a new replacement block of sufficient size to meet their needs in exchange for agreement that their existing block will be reclaimed and may be reissued to a different organization in 24 months. Rationale: There is a legitimate and growing need for provider independent addressing for end-site organizations and small ISPs. While there were and are technical reasons for limiting this in the v4 world, they need to be solved in the v6 world, or, we will not see widespread adoption of v6. This policy does not promote extreme growth in the routing table, as it would provide support for fewer than 70,000 v6 prefixes if every organization that currently has an ASN were to get an assignment, grow, and, be in the 24 month renumbering period. Realistically, it is unreasonable to think that this policy would contribute even 10,000 routes to the v6 table in the near term future. This policy provides for reasonable v6 provider independent assignments and allocations without creating a land-grab, explosive routing table growth, or a v6 swamp. All such assignments under this policy shall be subject to the same renewal criteria as v4 end-user assignments with a fee structure to be set by ARIN in the usual and customary way. Timetable for implementation: Upon adoption by the ARIN board of trustees. From stephen at sprunk.org Sat Dec 4 06:45:27 2004 From: stephen at sprunk.org (Stephen Sprunk) Date: Sat, 4 Dec 2004 05:45:27 -0600 Subject: [ppml] Proposed Policy: PI assignments for V6 References: Message-ID: <0a8401c4d9f6$c3239dd0$6801a8c0@stephen> > Policy Proposal Name: PI assignments for V6 > > Author: Owen DeLong > > Policy term: permanent Should this policy automatically expire once a certain number of prefixes are assigned, after a certain period of time, when 32-bit ASNs are deployed, etc. or can we reasonably expect operators to force repealing the policy if a "land rush" develops? > Policy statement: > > Any end-site or other organization which meets the current tests for > assignment of an autonomous system number (ASN) shall also qualify for one > IPv6 prefix assignment or allocation of the minimum size justified by them > under the ARIN guidelines for LIR assignment to such an organization. I had to read this several times to understand you weren't expecting end sites to become LIRs; please consider separating end sites and small ISPs into different paragraphs. > If the organization grows to require more space, they will not be entitled > to an additional block, but, may obtain a new replacement block of > sufficient size to meet their needs I don't like the wording here, but I can't seem to come up with something better... > in exchange for agreement that their existing block will be reclaimed and > may be reissued to a different organization in 24 months. 24 months seems excessive for end-site renumbering since they won't have to coordinate with sub-assignees. Perhaps different limits for allocations and assignments? Other comments: Should prefixes be required to be taken from block(s) designated for this use, since that will help ISPs adjust their filters? This seems common with other recent proposals. Should multiple organizations using the same ASN be considered a single end-site and thus required to share a prefix? Should having PI space disqualify an end-site from PA assignments, or vice versa? What about PI space allocated under other policies? Should we include any way for disconnected sites (which many not have an ASN) to get PI space? The IPv4 policy directs such sites to use RFC 1918 space, but there is no equivalent (yet) in IPv6. > All such assignments under this policy shall be subject to the same > renewal criteria as v4 end-user assignments with a fee structure to be set > by ARIN in the usual and customary way. In another forum it was claimed that ARIN charged ISPs $100/yr for IPv6 PI allocations; looking at the fee schedule, it appears that starting 1 Jan 05, the fees will be $2,500 plus $2,250/yr for a /32. Anyone requesting a second allocation pays $20k plus $18k/yr. That's quite a difference from $100/yr. ARIN's "usual and customary way" has already set the fees for end-user direct assignments to be the same as for ISP allocations, per section 12(D) of the 3 Aug 04 BoT meeting. At these fee levels, I must question the viability of direct PI assignments as a replacement for many or even most potential ULA uses, which I understand to be a central motivation for this policy proposal. Of course, this policy is still warranted for "normal" uses of PI space in IPv6. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2767 bytes Desc: not available URL: From ejay.hire at isdn.net Sat Dec 4 09:25:35 2004 From: ejay.hire at isdn.net (Ejay Hire) Date: Sat, 4 Dec 2004 08:25:35 -0600 Subject: [ppml] Proposed Policy: PI assignments for V6 In-Reply-To: <0a8401c4d9f6$c3239dd0$6801a8c0@stephen> Message-ID: <200412041428.iB4ES7l6008068@rex.isdn.net> Our Primary obstacle to deploying IPV6 at this time is the cost of a PI allocation. It's difficult to justify >$2k/yr for a "next generation" service when "current generation" IPv4 services seem to be the rule for the forseeable future. > the fees will be $2,500 plus $2,250/yr for a /32. Anyone requesting a > second allocation pays $20k plus $18k/yr. That's quite a > difference from > $100/yr. From owen at delong.com Sat Dec 4 11:44:51 2004 From: owen at delong.com (Owen DeLong) Date: Sat, 04 Dec 2004 08:44:51 -0800 Subject: [ppml] Proposed Policy: PI assignments for V6 In-Reply-To: <0a8401c4d9f6$c3239dd0$6801a8c0@stephen> References: <0a8401c4d9f6$c3239dd0$6801a8c0@stephen> Message-ID: <2147483647.1102149891@imac-en0.delong.sj.ca.us> --On Saturday, December 4, 2004 5:45 AM -0600 Stephen Sprunk wrote: >> Policy Proposal Name: PI assignments for V6 >> >> Author: Owen DeLong >> >> Policy term: permanent > > Should this policy automatically expire once a certain number of prefixes > are assigned, after a certain period of time, when 32-bit ASNs are > deployed, > etc. or can we reasonably expect operators to force repealing the policy > if > a "land rush" develops? > I think that in the unlikely event of a v6 "land rush" (remember, under this policy, it would require an ASN rush as well), we can expect the BOD to act properly under their emergency authority and also that we can expect the community to take action appropriate to the circumstances and technology of the time. I don't think we need to automatically expire this policy on either of the proposed basis. >> Policy statement: >> >> Any end-site or other organization which meets the current tests for >> assignment of an autonomous system number (ASN) shall also qualify for >> one IPv6 prefix assignment or allocation of the minimum size justified >> by them under the ARIN guidelines for LIR assignment to such an >> organization. > > I had to read this several times to understand you weren't expecting end > sites to become LIRs; please consider separating end sites and small ISPs > into different paragraphs. > Will do. >> If the organization grows to require more space, they will not be >> entitled to an additional block, but, may obtain a new replacement block >> of sufficient size to meet their needs > > I don't like the wording here, but I can't seem to come up with something > better... > >> in exchange for agreement that their existing block will be reclaimed and >> may be reissued to a different organization in 24 months. > > 24 months seems excessive for end-site renumbering since they won't have > to > coordinate with sub-assignees. Perhaps different limits for allocations > and > assignments? > While I agree that 24 months is a bit excessive, I don't think there's any real penalty to the community from this, and, I didn't want to be presumptuous about how complicated renumbering could be. I think that 24 months is a reasonable timeframe for an ISP with less than 200 customers. I think there's no harm letting end-sites have the same amount of time. As such, I figured keeping it simple and having one time limit made more sense. > Other comments: > > Should prefixes be required to be taken from block(s) designated for this > use, since that will help ISPs adjust their filters? This seems common > with > other recent proposals. > I'm not opposed to this, but, at the same time, I'm not sure it's necessary or beneficial. > Should multiple organizations using the same ASN be considered a single > end-site and thus required to share a prefix? > For purposes of this proposal, I think so. The requirements for getting an ASN are fairly simple. If you aren't multihomed or are multihomed only at the IGP level, then, you should be able to work out a shared prefix just as easily. Essentially, I think for purposes of this policy, multiple organizations sharing an AS looks a lot like a small ISP (the actual AS owner) providing LIR services to a small number of customers (the other orgs). > Should having PI space disqualify an end-site from PA assignments, or vice > versa? What about PI space allocated under other policies? > I think ARIN should leave the PA decision to the LIR. Having PA space should not disqualify an org from obtaining PI space under this policy, but, LIRs may require the PA space to be returned after some reasonable renumbering period. I think each LIR should set their own policy in this regard. Direct PI allocation/assignment under other RIR policy should, indeed, be a disqualifying factor. I will attempt to codify this in the next revision of the policy. > Should we include any way for disconnected sites (which many not have an > ASN) to get PI space? The IPv4 policy directs such sites to use RFC 1918 > space, but there is no equivalent (yet) in IPv6. > If they are truly disconnected, I'm not sure why IETF or RIRs should be getting involved in their choice of addressing policy. If they are "partially disconnected", then, they are somewhat connected, and, I think PA space is the preferred alternative if their needs for PI can't meet the simple tests of this policy. >> All such assignments under this policy shall be subject to the same >> renewal criteria as v4 end-user assignments with a fee structure to be >> set by ARIN in the usual and customary way. > > In another forum it was claimed that ARIN charged ISPs $100/yr for IPv6 PI > allocations; looking at the fee schedule, it appears that starting 1 Jan > 05, > the fees will be $2,500 plus $2,250/yr for a /32. Anyone requesting a > second allocation pays $20k plus $18k/yr. That's quite a difference from > $100/yr. > Yes. > ARIN's "usual and customary way" has already set the fees for end-user > direct assignments to be the same as for ISP allocations, per section > 12(D) > of the 3 Aug 04 BoT meeting. > Except that ARIN's current fee structure does not address any assignment smaller than /32. That would need to be addressed, and, I would hope that we could get something similar to current IPv4 pricing under 2002-3, including the $100 annual renewal for all resources that current end-sites pay. > At these fee levels, I must question the viability of direct PI > assignments > as a replacement for many or even most potential ULA uses, which I > understand to be a central motivation for this policy proposal. Of > course, > this policy is still warranted for "normal" uses of PI space in IPv6. > I am confident that if this policy is adopted, the fee structure will be adjusted accordingly. 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 L.Howard at stanleyassociates.com Mon Dec 6 09:36:17 2004 From: L.Howard at stanleyassociates.com (Howard, W. Lee) Date: Mon, 6 Dec 2004 09:36:17 -0500 Subject: [ppml] Proposed Policy: PI assignments for V6 (and v6 fees) Message-ID: > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Stephen Sprunk > Sent: Saturday, December 04, 2004 6:45 AM > To: ARIN Policy > Subject: Re: [ppml] Proposed Policy: PI assignments for V6 > > Should we include any way for disconnected sites (which many > not have an > ASN) to get PI space? The IPv4 policy directs such sites to > use RFC 1918 space, but there is no equivalent (yet) in IPv6. If a site isn't connected, why would PI space be necessary? RFC1918 made it so that private organizations who interconnected would always have overlapping assignments. Maybe there's a Better Practice available for IPv6, to reduce the likelihood of conflict (by increasing randomization). > > All such assignments under this policy shall be subject to the same > > renewal criteria as v4 end-user assignments with a fee > structure to be > > set by ARIN in the usual and customary way. > > In another forum it was claimed that ARIN charged ISPs What forum? I should join. > $100/yr for IPv6 PI allocations; looking at the fee schedule, > it appears that starting 1 Jan 05, the fees will be $2,500 > plus $2,250/yr for a /32. Anyone requesting a second > allocation pays $20k plus $18k/yr. That's quite a difference > from $100/yr. There has been constant fee-tweakage by the Board. The current combination of fees and waivers is such that an IPv4 subscriber pays only maintenance fees on their IPv6 allocation. You have to read the Board minutes to keep up, since the Fee Schedule page is out of date. Start with: http://www.arin.net/library/minutes/bot/bot2004_1020.html "The ARIN Board of Trustees sets the fees for IPv6 allocations as follows: XS/Micro /48 $1,250 Small /32 $2,250 Medium /30-31 $4,500 Large /27-29 $9,000 X-Large /22-26 $18,000 XX-Large /21 or greater $36,000 This fee structure is effective January 1, 2005." See also http://www.arin.net/library/minutes/bot/bot2004_1109.html "The ARIN Board of Trustees extends the current waiver of all IPv6 fees to all members in good standing for the period of January 1, 2005 until December 31, 2006. This waiver is not extended to any outstanding IPv6 related fees that were regularly invoiced in 2004." Thus, if you are a subscriber member (already pay for allocations) or an individual member ($500, see http://www.arin.net/registration/fee_schedule_new.html#annual ) you will have two years of fees waived. This seemed like a good compromise based on feedback during the public policy and members meetings. Would ARIN staff please update http://www.arin.net/registration/fee_schedule_new.html#ipv6_allocation appropriately? > ARIN's "usual and customary way" has already set the fees for > end-user direct assignments to be the same as for ISP > allocations, per section 12(D) of the 3 Aug 04 BoT meeting. > > At these fee levels, I must question the viability of direct > PI assignments as a replacement for many or even most > potential ULA uses, which I understand to be a central > motivation for this policy proposal. Of course, this policy > is still warranted for "normal" uses of PI space in IPv6. Arguably, you could put this proposal together with the newly adopted fee schedule and waiver and say that there's a two-year trial period; after two years, end-user sites will have to decide whether to pay $2,250 annually, or return their space and renumber into provider-assigned space. Lee Treasurer > S > > Stephen Sprunk "God does not play dice." --Albert Einstein > CCIE #3723 "God is an inveterate gambler, and He throws the > K5SSS dice at every possible opportunity." --Stephen Hawking > From L.Howard at stanleyassociates.com Mon Dec 6 09:41:33 2004 From: L.Howard at stanleyassociates.com (Howard, W. Lee) Date: Mon, 6 Dec 2004 09:41:33 -0500 Subject: [ppml] Proposed Policy: PI assignments for V6 Message-ID: It was the consensus of the public when creating IPv6 policy to enforce provider-based aggregation. As I recall, this was the proposal that came from the IETF, and was ratified by all of the RIRs through their policy processes. The primary obstacle to deploying IPv6, therefore, would be a dearth of IPv6 ISPs who can make assignments. The root cause, which can be inferred from your statement, is that there's no demand for the next generation service, since the current generation will last for the forseeable future. IMHO, Lee > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Ejay Hire > Sent: Saturday, December 04, 2004 9:26 AM > To: 'ARIN Policy' > Subject: RE: [ppml] Proposed Policy: PI assignments for V6 > > > Our Primary obstacle to deploying IPV6 at this time is the > cost of a PI allocation. It's difficult to justify >$2k/yr > for a "next generation" service when "current generation" > IPv4 services seem to be the rule for the forseeable future. > > > the fees will be $2,500 plus $2,250/yr for a /32. Anyone > requesting a > > second allocation pays $20k plus $18k/yr. That's quite a > > difference from > > $100/yr. > > From owen at delong.com Mon Dec 6 13:04:51 2004 From: owen at delong.com (Owen DeLong) Date: Mon, 06 Dec 2004 10:04:51 -0800 Subject: [ppml] Proposed Policy: PI assignments for V6 In-Reply-To: References: Message-ID: <2147483647.1102327491@imac-en0.delong.sj.ca.us> --On Monday, December 6, 2004 9:41 AM -0500 "Howard, W. Lee" wrote: > It was the consensus of the public when creating IPv6 > policy to enforce provider-based aggregation. As I recall, > this was the proposal that came from the IETF, and was > ratified by all of the RIRs through their policy processes. > When that consensus was achieved, there were rapid/easy renumbering features and other capabilities being proposed in IPv6 which have since been removed. Those features were what made non-PI space acceptable to multihomed end-sites. Since they have been removed, current IPv6 implementations do not make PA space as palatable to a large portion of organizations, and, as such, the needs of the community have changed. This is an attempt to change ARIN policy in recognition of those changing needs. 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 owen at delong.com Mon Dec 6 13:02:25 2004 From: owen at delong.com (Owen DeLong) Date: Mon, 06 Dec 2004 10:02:25 -0800 Subject: [ppml] Proposed Policy: PI assignments for V6 (and v6 fees) In-Reply-To: References: Message-ID: <2147483647.1102327345@imac-en0.delong.sj.ca.us> > If a site isn't connected, why would PI space be necessary? > RFC1918 made it so that private organizations who interconnected > would always have overlapping assignments. Maybe there's a > Better Practice available for IPv6, to reduce the likelihood of > conflict (by increasing randomization). > For one thing, RFC1918 doesn't apply to v6. For another, the V6WG killed the Site Local proposal (which I think should be resurrected, but, that's a separate issue). The current proposal is ULA, which, for a variety of reasons is operationally a very bad idea in my opinion, but, meets your criteria in your last sentence). I think a better approach is to recognize that networks fall into 3 categories: 1. Connected -- need unique v6 addresses among a common namespace known as "the internet". 2. Disconnected -- might as well run their own separate registry and distribute another copy of the entire v6 space in whatever way they see fit, no need for IETF to set policy in any way. 3. Semi-Connected -- This is what most people are calling a disconnected network. The reality is that these hosts are connected, directly, or, indirectly to the larger internet, and, as such, need unique addresses. A simple recognition that these hosts are connected, but, don't want global reachability would allow us to allocate space to them in a rational manner. I see no need for PI space for such hosts in an organization that doesn't otherwise qualify for PI space. I'd like to see site-local resurrected for these sites. Another alternative would be for these hosts to receive part of a PA block and simply filter at the borders. Either way, I think ARINs involvement should be limited to category 1. >> > All such assignments under this policy shall be subject to the same >> > renewal criteria as v4 end-user assignments with a fee >> structure to be >> > set by ARIN in the usual and customary way. >> >> In another forum it was claimed that ARIN charged ISPs > > What forum? I should join. > >> $100/yr for IPv6 PI allocations; looking at the fee schedule, >> it appears that starting 1 Jan 05, the fees will be $2,500 >> plus $2,250/yr for a /32. Anyone requesting a second >> allocation pays $20k plus $18k/yr. That's quite a difference >> from $100/yr. > > There has been constant fee-tweakage by the Board. The current > combination of fees and waivers is such that an IPv4 subscriber > pays only maintenance fees on their IPv6 allocation. You have to > read the Board minutes to keep up, since the Fee Schedule page > is out of date. > > Start with: http://www.arin.net/library/minutes/bot/bot2004_1020.html > "The ARIN Board of Trustees sets the fees for IPv6 allocations as follows: > > XS/Micro /48 $1,250 > Small /32 $2,250 > Medium /30-31 $4,500 > Large /27-29 $9,000 > X-Large /22-26 $18,000 > XX-Large /21 or greater $36,000 > > This fee structure is effective January 1, 2005." > Lee, what about non-subscriber prices? > Would ARIN staff please update > http://www.arin.net/registration/fee_schedule_new.html#ipv6_allocation > appropriately? > Definitely. > Arguably, you could put this proposal together with the newly > adopted fee schedule and waiver and say that there's a two-year > trial period; after two years, end-user sites will have to > decide whether to pay $2,250 annually, or return their space > and renumber into provider-assigned space. > Or, during that two years, we can work with the board and membership to try and achieve a more useful fee structure for the new policies. 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 stephen at sprunk.org Mon Dec 6 13:01:25 2004 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 6 Dec 2004 12:01:25 -0600 Subject: [ppml] Proposed Policy: PI assignments for V6 (and v6 fees) References: Message-ID: <006801c4dbbf$7239bec0$6801a8c0@stephen> Thus spake "Howard, W. Lee" >> Should we include any way for disconnected sites (which many >> not have an >> ASN) to get PI space? The IPv4 policy directs such sites to >> use RFC 1918 space, but there is no equivalent (yet) in IPv6. > > If a site isn't connected, why would PI space be necessary? > RFC1918 made it so that private organizations who interconnected > would always have overlapping assignments. Maybe there's a > Better Practice available for IPv6, to reduce the likelihood of > conflict (by increasing randomization). IPv6 Site-Local Addresses, the analog of RFC 1918, were deprecated because ambiguous addresses were considered technically flawed. The IPv6 WG has proposed Unique Local Addresses which use a 40-bit random field in the prefix to reduce or eliminate (depending on the class) the chance of ambiguity. ULAs are intended to be used for internal-only communication (possibly layered on top of PA addresses), private connections between companies, and any other purpose that needs uniqueness but not global routability. While ULAs appear to have consensus, a few vocal objectors wanted to see if the RIRs would change their policies to provide PI space for these needs before letting us proceed with ULAs. > It was the consensus of the public when creating IPv6 > policy to enforce provider-based aggregation. As I recall, > this was the proposal that came from the IETF, and was > ratified by all of the RIRs through their policy processes. > > The primary obstacle to deploying IPv6, therefore, would > be a dearth of IPv6 ISPs who can make assignments. The > root cause, which can be inferred from your statement, is > that there's no demand for the next generation service, > since the current generation will last for the forseeable > future. OTOH, it's been asserted by many folks, including myself, that even end-sites that wish to deploy IPv6 will not do so if they are locked into provider-based addresses for their internal communications. Multihoming in particular is not feasible with the existing scheme, and some believe that this will lead to organizations using ULAs internally and NATing at their borders into PA space. Since NAT is generally considered evil and was supposed to be unnecessary in IPv6, the only solution is to create allow IPv6 PI assignments. I'll note that this proposal was solicited by an active AC member, and several other ARIN-related folks seem to agree -- at least until the Multi6 WG comes up with something better (years if not decades away). >> > All such assignments under this policy shall be subject to the same >> > renewal criteria as v4 end-user assignments with a fee >> structure to be >> > set by ARIN in the usual and customary way. >> >> In another forum it was claimed that ARIN charged ISPs > > What forum? I should join. NANOG >> $100/yr for IPv6 PI allocations; looking at the fee schedule, >> it appears that starting 1 Jan 05, the fees will be $2,500 >> plus $2,250/yr for a /32. Anyone requesting a second >> allocation pays $20k plus $18k/yr. That's quite a difference >> from $100/yr. > > There has been constant fee-tweakage by the Board. The current > combination of fees and waivers is such that an IPv4 subscriber > pays only maintenance fees on their IPv6 allocation. You have to > read the Board minutes to keep up, since the Fee Schedule page > is out of date. Argh. These kinds of things really need to be kept current. > Start with: http://www.arin.net/library/minutes/bot/bot2004_1020.html > "The ARIN Board of Trustees sets the fees for IPv6 allocations as follows: > > XS/Micro /48 $1,250 ... > This fee structure is effective January 1, 2005." Okay, that's what I'd have expected anyways. > See also http://www.arin.net/library/minutes/bot/bot2004_1109.html > "The ARIN Board of Trustees extends the current waiver of all IPv6 fees to > all members in good standing for the period of January 1, 2005 until > December 31, 2006. This waiver is not extended to any outstanding IPv6 > related fees that were regularly invoiced in 2004." > > Thus, if you are a subscriber member (already pay for allocations) > or an individual member ($500, see > http://www.arin.net/registration/fee_schedule_new.html#annual ) > you will have two years of fees waived. This seemed like a good > compromise based on feedback during the public policy and members > meetings. Glad to hear it. >> ARIN's "usual and customary way" has already set the fees for >> end-user direct assignments to be the same as for ISP >> allocations, per section 12(D) of the 3 Aug 04 BoT meeting. >> >> At these fee levels, I must question the viability of direct >> PI assignments as a replacement for many or even most >> potential ULA uses, which I understand to be a central >> motivation for this policy proposal. Of course, this policy >> is still warranted for "normal" uses of PI space in IPv6. > > Arguably, you could put this proposal together with the newly > adopted fee schedule and waiver and say that there's a two-year > trial period; after two years, end-user sites will have to > decide whether to pay $2,250 annually, or return their space > and renumber into provider-assigned space. $1,250/yr since the expected assignment would be /48 for nearly all sites. Still, that's a fair chunk of change if one doesn't need global routability, particularly compared to (free) ULA space. I do think it's reasonable to people upgrading from PA space; it's a drop in the bucket compared to being multihomed in the first place. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From L.Howard at stanleyassociates.com Mon Dec 6 13:19:57 2004 From: L.Howard at stanleyassociates.com (Howard, W. Lee) Date: Mon, 6 Dec 2004 13:19:57 -0500 Subject: [ppml] Proposed Policy: PI assignments for V6 (and v6 fees) Message-ID: > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Monday, December 06, 2004 1:02 PM > To: Howard, W. Lee; 'Stephen Sprunk'; ARIN Policy > Subject: RE: [ppml] Proposed Policy: PI assignments for V6 > (and v6 fees) > > > > If a site isn't connected, why would PI space be necessary? RFC1918 > > made it so that private organizations who interconnected > would always > > have overlapping assignments. Maybe there's a Better Practice > > available for IPv6, to reduce the likelihood of conflict (by > > increasing randomization). > > > For one thing, RFC1918 doesn't apply to v6. For another, the True, but we have operational experience based on it. > V6WG killed the Site Local proposal (which I think should be > resurrected, but, that's a separate issue). The current > proposal is ULA, which, for a variety of reasons is > operationally a very bad idea in my opinion, but, meets your > criteria in your last sentence). It overkills my criterion. > I think a better approach is to recognize that networks fall into 3 > categories: > > 1. Connected -- need unique v6 addresses among a > common namespace known as "the internet". "The Internet." > 2. Disconnected -- might as well run their own > separate registry > and distribute another copy of the entire v6 > space in whatever > way they see fit, no need for IETF to set > policy in any way. Agree. > 3. Semi-Connected -- This is what most people are calling a > disconnected network. The reality is that > these hosts are > connected, directly, or, indirectly to the > larger internet, > and, as such, need unique addresses. A simple > recognition > that these hosts are connected, but, don't want global > reachability would allow us to allocate space to them in > a rational manner. I see no need for PI space for such > hosts in an organization that doesn't otherwise qualify > for PI space. I'd like to see site-local > resurrected for > these sites. Another alternative would be for > these hosts > to receive part of a PA block and simply filter > at the borders. In a significant portion of these cases, they may be connected to "an internet" but not the Internet. An internet is two or more networks under separate authority which connect to each other. > Either way, I think ARINs involvement should be limited to category 1. I agree that ARIN's policy involvement is limited to numbering on the Internet, but we sure (the public) sure have some useful expertise on internets. > > Start with: > http://www.arin.net/library/minutes/bot/bot200> 4_1020.html > > > "The ARIN Board of Trustees sets the fees for > IPv6 allocations as > > follows: > > > > XS/Micro /48 $1,250 > > Small /32 $2,250 > > Medium /30-31 $4,500 > > Large /27-29 $9,000 > > X-Large /22-26 $18,000 > > XX-Large /21 or greater $36,000 > > > > This fee structure is effective January 1, 2005." > > > Lee, what about non-subscriber prices? Multiple choice: A. There's no such thing. Policy requires 200 sub-assignments within 5 years (IIRC), therefore anyone meeting those criteria is a subscriber, receiving an allocation. http://www.arin.net/policy/index.html#six5 "To qualify for an initial allocation of IPv6 address space, an organization must . . . not be an end site." B. Except micro-allocations, which have a category all their own (above). C. In case an assignment policy is ever established, the Board passed a motion setting initial fees to be the same as allocations, with maintenance fees consistent with other maintenance fees (currently $100): http://www.arin.net/library/minutes/bot/bot2004_0803.html item 12D. > > Arguably, you could put this proposal together with the > newly adopted > > fee schedule and waiver and say that there's a two-year > trial period; > > after two years, end-user sites will have to decide whether to pay > > $2,250 annually, or return their space and renumber into > > provider-assigned space. > > > Or, during that two years, we can work with the board and > membership to try and achieve a more useful fee structure for > the new policies. Fair enough. Lee > > Owen > > -- > If it wasn't crypto-signed, it probably didn't come from me. > From owen at delong.com Mon Dec 6 13:28:14 2004 From: owen at delong.com (Owen DeLong) Date: Mon, 06 Dec 2004 10:28:14 -0800 Subject: [ppml] Proposed Policy: PI assignments for V6 (and v6 fees) In-Reply-To: <006801c4dbbf$7239bec0$6801a8c0@stephen> References: <006801c4dbbf$7239bec0$6801a8c0@stephen> Message-ID: <2147483647.1102328894@imac-en0.delong.sj.ca.us> > ULAs are intended to be used for internal-only communication (possibly > layered on top of PA addresses), private connections between companies, > and any other purpose that needs uniqueness but not global routability. > While ULAs appear to have consensus, a few vocal objectors wanted to see > if the RIRs would change their policies to provide PI space for these > needs before letting us proceed with ULAs. > I don't think "a few vocal objectors" is an accurate characterization of the discussion on PPML and/or NANOG that ensued the announcement of ULA to the operational community. > OTOH, it's been asserted by many folks, including myself, that even > end-sites that wish to deploy IPv6 will not do so if they are locked into > provider-based addresses for their internal communications. > I would argue that under the current structure, a lot of end-sites will not deploy IPv6 if they are locked into provider-based addresses for their external connectivity either. > Multihoming in particular is not feasible with the existing scheme, and > some believe that this will lead to organizations using ULAs internally > and NATing at their borders into PA space. Since NAT is generally > considered evil and was supposed to be unnecessary in IPv6, the only > solution is to create allow IPv6 PI assignments. > Others believe, as I do, that it will lead instead to companies pressuring their ISPs to route their ULAs globally and not NAT at their borders to PA space. > I'll note that this proposal was solicited by an active AC member, and > several other ARIN-related folks seem to agree -- at least until the > Multi6 WG comes up with something better (years if not decades away). > Exactly. >> XS/Micro /48 $1,250 > ... >> This fee structure is effective January 1, 2005." > > Okay, that's what I'd have expected anyways. > Note: This is strictly an ALLOCATION fee as there is no ASSIGNMENT fee structure in v6 ARIN policy since there is no v6 ASSIGNMENT policy for ARIN. ARIN's current v6 policy is strictly directed at ALLOCATION to ISPs, so, you would have to compare that to the pricing for v4 /22 Allocations, not v4 /22 assignments. If you look at the ARIN pricing for ALL v4 assignments, it's $100/year regardless of what you have (ASN, v4 IPs, etc.). > Still, that's a fair chunk of change if one doesn't need global > routability, particularly compared to (free) ULA space. I do think it's > reasonable to people upgrading from PA space; it's a drop in the bucket > compared to being multihomed in the first place. > That's not entirely true. I could be multihomed for around $200/month. $1,250 is not a drop in the bucket compared to $2,400. Especially not when it's in addition to the $2,400. However, most end-sites would not need v6 allocations, they would need v6 assignments. If ARIN adopts similar pricing for v6 assignments to what is there for v4 assignments, then, I think you will find it quite reasonable. Organizations that don't require global routability probably won't be looking for allocations. They'll probably want assignments. ~$2,500 initial and $100/year doesn't seem horrible for that purpose. 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 owen at delong.com Mon Dec 6 13:34:26 2004 From: owen at delong.com (Owen DeLong) Date: Mon, 06 Dec 2004 10:34:26 -0800 Subject: [ppml] Proposed Policy: PI assignments for V6 (and v6 fees) In-Reply-To: References: Message-ID: <2147483647.1102329266@imac-en0.delong.sj.ca.us> > > In a significant portion of these cases, they may be connected > to "an internet" but not the Internet. An internet is two or more > networks under separate authority which connect to each other. > If any of the member networks on "an internet" is connected to "The internet", then, they fall into category 1. If not, then, it's category 2 and not an ARIN issue. (Just my opinion, but, I think that works generally) >> Either way, I think ARINs involvement should be limited to category 1. > > I agree that ARIN's policy involvement is limited to numbering on > the Internet, but we sure (the public) sure have some useful expertise > on internets. > Yes. We're talking policy here (it is the policy mailing list afterall :-), so, expertise is a separate issue. > Multiple choice: > A. There's no such thing. Policy requires 200 sub-assignments within 5 > years (IIRC), therefore anyone meeting those criteria is a subscriber, > receiving an allocation. http://www.arin.net/policy/index.html#six5 > "To qualify for an initial allocation of IPv6 address space, an > organization must . . . not be an end site." > Right... This proposal is an attempt to change exactly that. > B. Except micro-allocations, which have a category all their own (above). > Micro-Allocations should still be SUBCSCRIBERS. They are ALLOCATIONS, and, as such, the recipient is an LIR and should be a SUBSCRIBER. I agree the SUBSCRIBER fees should be smaller than /32 SUBSCRIBER fees, and I think the previously described fee structure makes sense for these. > C. In case an assignment policy is ever established, the Board passed > a motion setting initial fees to be the same as allocations, with > maintenance fees consistent with other maintenance fees (currently $100): > http://www.arin.net/library/minutes/bot/bot2004_0803.html item 12D. > Right... That's what I'm hoping for in terms of ASSIGNMENT or NON-SUBSCRIBER policy. Stephen, does that address your fee concerns? >> Or, during that two years, we can work with the board and >> membership to try and achieve a more useful fee structure for >> the new policies. > > Fair enough. > Heck... Based on the above, it looks like if we get this policy implemented, the structure is already there. 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 L.Howard at stanleyassociates.com Mon Dec 6 14:01:09 2004 From: L.Howard at stanleyassociates.com (Howard, W. Lee) Date: Mon, 6 Dec 2004 14:01:09 -0500 Subject: [ppml] Proposed Policy: PI assignments for V6 (and v6 fees) Message-ID: > -----Original Message----- > From: Stephen Sprunk [mailto:stephen at sprunk.org] > Sent: Monday, December 06, 2004 1:01 PM > To: Howard, W. Lee; ARIN Policy > Subject: Re: [ppml] Proposed Policy: PI assignments for V6 > (and v6 fees) > > > Thus spake "Howard, W. Lee" > >> Should we include any way for disconnected sites (which > many not have > >> an > >> ASN) to get PI space? The IPv4 policy directs such sites > to use RFC > >> 1918 space, but there is no equivalent (yet) in IPv6. > > > > If a site isn't connected, why would PI space be necessary? RFC1918 > > made it so that private organizations who interconnected > would always > > have overlapping assignments. Maybe there's a Better Practice > > available for IPv6, to reduce the likelihood of conflict (by > > increasing randomization). > > IPv6 Site-Local Addresses, the analog of RFC 1918, were > deprecated because > ambiguous addresses were considered technically flawed. The > IPv6 WG has > proposed Unique Local Addresses which use a 40-bit random > field in the > prefix to reduce or eliminate (depending on the class) the chance of > ambiguity. > > ULAs are intended to be used for internal-only communication > (possibly > layered on top of PA addresses), private connections between > companies, and > any other purpose that needs uniqueness but not global > routability. While > ULAs appear to have consensus, a few vocal objectors wanted When discussed at ARIN fora, there seemed to be consensus against. > to see if the > RIRs would change their policies to provide PI space for > these needs before > letting us proceed with ULAs. Can you describe the difference between uniqueness and routability? If it is unique, it could be routed. It might not be routed, but it is route-able. > > > It was the consensus of the public when creating IPv6 > > policy to enforce provider-based aggregation. As I recall, > this was > > the proposal that came from the IETF, and was ratified by > all of the > > RIRs through their policy processes. > > > > The primary obstacle to deploying IPv6, therefore, would > > be a dearth of IPv6 ISPs who can make assignments. The > > root cause, which can be inferred from your statement, is > that there's > > no demand for the next generation service, since the current > > generation will last for the forseeable future. > > OTOH, it's been asserted by many folks, including myself, that even > end-sites that wish to deploy IPv6 will not do so if they are > locked into > provider-based addresses for their internal communications. Bummer. > Multihoming in particular is not feasible with the existing > scheme, and some Multihoming is not feasible because address space is aggregated? In IPv4, BGP4 speakers can announce more-specifics of PA space and be multihomed. This isn't possible with IPv6? > believe that this will lead to organizations using ULAs > internally and > NATing at their borders into PA space. I can't figure out why NAT would even be required if a site has a globally unique prefix. > Since NAT is > generally considered evil I've heard that, but never completely understood why it is evil. >From what I can tell, the most insidious thing about NAT is that it makes IPv6 far far less urgent. > and was supposed to be unnecessary in IPv6, the only > solution is to > create allow IPv6 PI assignments. I am not convinced that there is consensus around these assumptions: - ULA is desirable - NAT is evil - multihoming in PA space is impossible - renumbering is hard (is this an assumption of yours?) > I'll note that this proposal was solicited by an active AC > member, and > several other ARIN-related folks seem to agree -- at least > until the Multi6 > WG comes up with something better (years if not decades away). Don't take this personally. Although it may seem like it, I'm not actually taking a position, I'm trying to clarify several points about this proposal, the need for it, and the ramifications. > >> In another forum it was claimed that ARIN charged ISPs > > > > What forum? I should join. > > NANOG Yes, I've been away too long. > > There has been constant fee-tweakage by the Board. The current > > combination of fees and waivers is such that an IPv4 > subscriber pays > > only maintenance fees on their IPv6 allocation. You have to > read the > > Board minutes to keep up, since the Fee Schedule page is > out of date. > > Argh. These kinds of things really need to be kept current. It turns out that the meeting minutes were posted mere moments before I went looking for them, so the web site was less than an hour out of date. Sorry for tweaking the staff on that. > > > Start with: > http://www.arin.net/library/minutes/bot/bot2004_1020.html > > "The ARIN Board of Trustees sets the fees for IPv6 allocations as > > follows: > > > > XS/Micro /48 $1,250 > ... > > This fee structure is effective January 1, 2005." > > Okay, that's what I'd have expected anyways. > > > See also http://www.arin.net/library/minutes/bot/bot2004_1109.html > > "The ARIN Board of Trustees extends the current waiver of all IPv6 > > fees to all members in good standing for the period of > January 1, 2005 > > until December 31, 2006. This waiver is not extended to any > > outstanding IPv6 related fees that were regularly invoiced in 2004." > > > > Thus, if you are a subscriber member (already pay for > allocations) or > > an individual member ($500, see > > http://www.arin.net/registration/fee_schedule_new.html#annual ) you > > will have two years of fees waived. This seemed like a good > > compromise based on feedback during the public policy and members > > meetings. > > Glad to hear it. > > >> ARIN's "usual and customary way" has already set the fees for > >> end-user direct assignments to be the same as for ISP allocations, > >> per section 12(D) of the 3 Aug 04 BoT meeting. > >> > >> At these fee levels, I must question the viability of direct PI > >> assignments as a replacement for many or even most potential ULA > >> uses, which I understand to be a central motivation for > this policy > >> proposal. Of course, this policy is still warranted for "normal" > >> uses of PI space in IPv6. > > > > Arguably, you could put this proposal together with the > newly adopted > > fee schedule and waiver and say that there's a two-year > trial period; > > after two years, end-user sites will have to decide whether to pay > > $2,250 annually, or return their space and renumber into > > provider-assigned space. > > $1,250/yr since the expected assignment would be /48 for > nearly all sites. The proposal says: "[If it can get an ASN, an organization] shall also qualify for one IPv6 prefix assignment or allocation of the minimum size justified by them under the ARIN guidelines for LIR assignment to such an organization. " http://www.arin.net/mailing_lists/ppml/3007.html That means a /32. The micro-allocation policy (/48) is for "critical infrastructure providers." http://www.arin.net/policy/index.html#six10 Lee > > S > > Stephen Sprunk "God does not play dice." --Albert Einstein > CCIE #3723 "God is an inveterate gambler, and He throws the > K5SSS dice at every possible opportunity." --Stephen Hawking > From marcelo at it.uc3m.es Mon Dec 6 14:10:34 2004 From: marcelo at it.uc3m.es (marcelo bagnulo braun) Date: Mon, 6 Dec 2004 20:10:34 +0100 Subject: [ppml] Proposed Policy: PI assignments for V6 In-Reply-To: References: Message-ID: <81464318-47BA-11D9-97A6-000D93ACD0FE@it> Hi all, i think it is not a good idea to accept this policy _now_ i think that probably a PI assignment policy will be needed in the future, but i wouldn't promote it now. here is why: for several years now the community have been working on a multihoming solution that is compatible with PA assignments. this has been considered important in order to preserve the health of the global routing system as you al already know. This is a difficult problem and it is really taking quite some time to figure out how to solve it and to reach consensus. However, some progress is being made and i guess that we are not so far from agreeing on which way to go. During last IETF in washington the multi6 wg agreed to follow a path towards a solution. Yes, there is still some way to develop and deploy a solution, but we are moving. In any case, as you may well notice, any multihoming solution compatible with PA addressing will require that: - multiple PA prefixes configured in the multihomed sites (instead of one) - it won't provide PI addressing (so a multihomed site will still have to renumber if it changes providers) This two reasons make it a priori an inferior solution to obtaining PI addressing on the eyes of the multihomed site, even though it is a much superior solution in the eyes of the community since it preserves global routing system scalability. In any case, if a PI assignment policy is adopted, the PA compatible multihoming solution won't get any chance to get deployed i guess, since i guess that multihomed sites will have the following choices: - A PA compatible solution which: doesn't provides provider independence, requires multiple prefixes and it is new i.e. no experience, no products, no previous knowledge - a PI multihoming solution: everything works as you already know What do you think multihomed sites will choose? My proposal is to wait until a PA compatible solution for multihoming is developed and some experience is gained with it. Then we can see if it is useful and especially who is useful for. Probably it won't be good enough for some sites, and probably then we will need a PI asignment policy to satisfy the need of those sites. But we shouldn't do it now, that the multihoming solution is not yet here, and we would be killing it before it comes. Regards, marcelo El 02/12/2004, a las 22:34, Member Services escribi?: > ARIN received the following proposed policy. In accordance with the > ARIN > Internet Resource Policy Evaluation Process, the proposal is being > posted > to the ARIN Public Policy Mailing List and being placed on ARIN's > website. > > The ARIN Advisory Council will review the proposal and within ten > working > days may decide to: > 1) support the proposal as is, > 2) work with the author to clarify, divide or combine one or more > policy > proposals, or > 3) not support the policy proposal. > > If the AC supports the proposal or reaches an agreement to work with > the > author, then the proposal will be posted as a formal policy proposal to > the Public Policy Mailing List and it will be presented at the Public > Policy Meeting. If the AC does not support the proposal, then the > author > may elect to use the petition process to advance the proposal. If the > author elects not to petition or the petition fails, then the proposed > policy will be considered closed. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/ipep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/index.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > ### * ### > > Policy Proposal Name: PI assignments for V6 > > Author: Owen DeLong > > Policy term: permanent > > Policy statement: > > Any end-site or other organization which meets the current tests for > assignment of an autonomous system number (ASN) shall also qualify for > one > IPv6 prefix assignment or allocation of the minimum size justified by > them > under the ARIN guidelines for LIR assignment to such an organization. > If > the organization wishes to receive an allocation, they must meet the > tests > for being an LIR, except that this smaller allocation will not require > a > plan for assigning to an additional 200 organizations. To qualify as > an > LIR under this policy, the organization must have the intent of > assigning > to additional organizations, and, should be able to show ARIN > reasonable > evidence of such intent. > > If the organization grows to require more space, they will not be > entitled > to an additional block, but, may obtain a new replacement block of > sufficient size to meet their needs in exchange for agreement that > their > existing block will be reclaimed and may be reissued to a different > organization in 24 months. > > Rationale: > > There is a legitimate and growing need for provider independent > addressing > for end-site organizations and small ISPs. While there were and are > technical reasons for limiting this in the v4 world, they need to be > solved in the v6 world, or, we will not see widespread adoption of v6. > > This policy does not promote extreme growth in the routing table, as it > would provide support for fewer than 70,000 v6 prefixes if every > organization that currently has an ASN were to get an assignment, grow, > and, be in the 24 month renumbering period. Realistically, it is > unreasonable to think that this policy would contribute even 10,000 > routes > to the v6 table in the near term future. > > This policy provides for reasonable v6 provider independent assignments > and allocations without creating a land-grab, explosive routing table > growth, or a v6 swamp. > > All such assignments under this policy shall be subject to the same > renewal criteria as v4 end-user assignments with a fee structure to be > set > by ARIN in the usual and customary way. > > Timetable for implementation: > > Upon adoption by the ARIN board of trustees. > From stephen at sprunk.org Mon Dec 6 14:03:14 2004 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 6 Dec 2004 13:03:14 -0600 Subject: [ppml] Proposed Policy: PI assignments for V6 (and v6 fees) References: <2147483647.1102329266@imac-en0.delong.sj.ca.us> Message-ID: <01f001c4dbc8$932c4270$6801a8c0@stephen> Thus spake "Owen DeLong" > > In a significant portion of these cases, they may be connected > > to "an internet" but not the Internet. An internet is two or more > > networks under separate authority which connect to each other. > > If any of the member networks on "an internet" is connected to "The > internet", then, they fall into category 1. If not, then, it's category 2 > and not an ARIN issue. > > (Just my opinion, but, I think that works generally) Categorizing semi-connected networks separately makes sense because their addressing needs do not include global routability; policies (or standards work) relating to that category may be different than for fully-connected networks. > > C. In case an assignment policy is ever established, the Board passed > > a motion setting initial fees to be the same as allocations, with > > maintenance fees consistent with other maintenance fees (currently > > $100): > > http://www.arin.net/library/minutes/bot/bot2004_0803.html item 12D. > > Right... That's what I'm hoping for in terms of ASSIGNMENT or NON- > SUBSCRIBER policy. Stephen, does that address your fee concerns? If I'm understanding the terms correctly, this will mean that end sites will pay only $100/yr. That seems perfectly acceptable for multihoming purposes and probably even semi-connected networks (though this policy doesn't apply to the latter). I'm initial fee still seems steep based on the lower level of review needed under this policy, but I doubt I'd have trouble convincing mgmt to pay it. Not an issue. > Heck... Based on the above, it looks like if we get this policy > implemented, > the [fee] structure is already there. Indeed. Once ARIN gets around to putting this information in the fee schedule, everything's fine on this front. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From paul at vix.com Mon Dec 6 14:45:05 2004 From: paul at vix.com (Paul Vixie) Date: Mon, 06 Dec 2004 19:45:05 +0000 Subject: [ppml] Proposed Policy: PI assignments for V6 (and v6 fees) In-Reply-To: Message from "Stephen Sprunk" of "Mon, 06 Dec 2004 13:03:14 CST." <01f001c4dbc8$932c4270$6801a8c0@stephen> Message-ID: <20041206194505.F34A113E12@sa.vix.com> (this is my first ppml post, ever.) > Categorizing semi-connected networks separately makes sense because their > addressing needs do not include global routability; policies (or standards > work) relating to that category may be different than for fully-connected > networks. i don't think it'll work like you're saying. let's say ULA goes into general use and that a number of enterprises who are all customers of a set of ISP's decide that rather than tunnelling, they'd like their shared set of ISP's to "just route the ULA prefixes please." by enterprise i'm talking Ford and GM and Daimler and their rust-belt supply network, or perhaps Wal-Mart and its offshore vendor network. we know what the ISP's will say: "yes, ma'am, and would you like fries with that?" now let's assume that someone wants to enter one of these enterprise frays and their ISP is not "part of the collective". the ISP in question will not want to allow sheer force to be applied to this customer, so they'll join the collective either by direct peering or by tunnels. lather, rinse, repeat. human action (per von mises and others) automatically turns ULA into PI over time, with increasing horizons and therefore decreasing margins between what it means to be "unique" and what it means to be "global". you cannot legislate human nature, but you can make it take perverse turns to get where it's going, and make it take longer to get there, if you want. i don't want us to do that or even try to do that. instead, let's just recognize that a far larger segment of the enterprise community needs PI than was previously believed, and transform all ULA arguments to date into "PI reform" arguments, and then restore "site local" addressing, which was valuable precisely because it was dangerous and self-limiting. From owen at delong.com Mon Dec 6 15:12:13 2004 From: owen at delong.com (Owen DeLong) Date: Mon, 06 Dec 2004 12:12:13 -0800 Subject: [ppml] Proposed Policy: PI assignments for V6 (and v6 fees) In-Reply-To: References: Message-ID: <2147483647.1102335133@imac-en0.delong.sj.ca.us> > "[If it can get an ASN, an organization] shall also qualify for one > IPv6 prefix assignment or allocation of the minimum size justified by > them under the ARIN guidelines for LIR assignment to such an > organization. " > http://www.arin.net/mailing_lists/ppml/3007.html > > That means a /32. The micro-allocation policy (/48) is for "critical > infrastructure providers." > http://www.arin.net/policy/index.html#six10 > I had not expected this to be as confusing as it apparently is. The intent in my language in the proposal was to have ARIN make a direct assignment of the same size as ARIN would permit an LIR to make to the organization. Thus, it would be a /48 (or shorter prefix/more addresses) under current guidelines, not a /32 as stated by Lee. I will make the language more clear in the next revision of the proposal. 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 owen at delong.com Mon Dec 6 15:23:21 2004 From: owen at delong.com (Owen DeLong) Date: Mon, 06 Dec 2004 12:23:21 -0800 Subject: [ppml] Proposed Policy: PI assignments for V6 In-Reply-To: <81464318-47BA-11D9-97A6-000D93ACD0FE@it> References: <81464318-47BA-11D9-97A6-000D93ACD0FE@it> Message-ID: <2147483647.1102335801@imac-en0.delong.sj.ca.us> > i think it is not a good idea to accept this policy _now_ > OK... We can agree to disagree on this. > i think that probably a PI assignment policy will be needed in the > future, but i wouldn't promote it now. > I think it is more needed now than it may be in the future, and, if that is the case, we can always repeal it in the future if that is desirable to the community. [snip -- stuff about theory that IETF will produce a good multihoming solution for PA space eventually and we should all just wait] > In any case, as you may well notice, any multihoming solution compatible > with PA addressing will require that: > - multiple PA prefixes configured in the multihomed sites (instead of one) > - it won't provide PI addressing (so a multihomed site will still have to > renumber if it changes providers) > This two reasons make it a priori an inferior solution to obtaining PI > addressing on the eyes of the multihomed site, even though it is a much > superior solution in the eyes of the community since it preserves global > routing system scalability. I think you have a different perception of the community than many on this list. The community includes the multihomed organizations as well as the providers. The reality is that PI as implemented in V6 currently provides yet another path for provider-lockin through the difficulty of renumbering and many organizations do not consider that a palatable situation. If v6 ever delivers a solution that solves the various issues (multihoming in various forms is but one of the issues) related to PA space, then, we can revisit and possibly repeal the policy. Unlike the v4 swamp, there's no address space in v6 that isn't subject to renewal by the registry. As such, policy changes can, in the v6 world, correct past allocation policies in the long run. > In any case, if a PI assignment policy is adopted, the PA compatible > multihoming solution won't get any chance to get deployed i guess, since > i guess that multihomed sites will have the following choices: > - A PA compatible solution which: doesn't provides provider independence, > requires multiple prefixes and it is new i.e. no experience, no products, > no previous knowledge > - a PI multihoming solution: everything works as you already know > What do you think multihomed sites will choose? > Or translated: You want to see PA multihoming get adopted even though you know it will be perceived as an inferior solution by a significant portion of the community. Therefore, you think ARIN should block the solution which is perceived as superior in order to support the other one. Provider independence is a BIG IMPORTANT factor to a lot of organizations in the community. > My proposal is to wait until a PA compatible solution for multihoming is > developed and some experience is gained with it. Then we can see if it is > useful and especially who is useful for. Probably it won't be good enough > for some sites, and probably then we will need a PI asignment policy to > satisfy the need of those sites. > But we shouldn't do it now, that the multihoming solution is not yet > here, and we would be killing it before it comes. > If it's truly beneficial when it comes, we can look at repealing this policy or providing incentives for it. However, many organizations have real networks to run in the meantime. We shouldn't abandon this policy just because it might interfere with the adoption rate of some future proposal that may or may not meet the desires of the community. 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 owen at delong.com Mon Dec 6 15:28:45 2004 From: owen at delong.com (Owen DeLong) Date: Mon, 06 Dec 2004 12:28:45 -0800 Subject: [ppml] Proposed Policy: PI assignments for V6 (and v6 fees) In-Reply-To: <01f001c4dbc8$932c4270$6801a8c0@stephen> References: <2147483647.1102329266@imac-en0.delong.sj.ca.us> <01f001c4dbc8$932c4270$6801a8c0@stephen> Message-ID: <2147483647.1102336125@imac-en0.delong.sj.ca.us> --On Monday, December 6, 2004 1:03 PM -0600 Stephen Sprunk wrote: > Thus spake "Owen DeLong" >> > In a significant portion of these cases, they may be connected >> > to "an internet" but not the Internet. An internet is two or more >> > networks under separate authority which connect to each other. >> >> If any of the member networks on "an internet" is connected to "The >> internet", then, they fall into category 1. If not, then, it's category >> 2 and not an ARIN issue. >> >> (Just my opinion, but, I think that works generally) > > Categorizing semi-connected networks separately makes sense because their > addressing needs do not include global routability; policies (or > standards work) relating to that category may be different than for > fully-connected networks. > >From an ARIN perspective, uniqueness is all that matters. ARIN does not guarantee routability. I believe that a semi-connected network, for ARIN purposes, should qualify just like a connected network. The fact that their routes do not need to appear in the global routing table is a convenience and benefit for the operational community, but, not really an issue for ARIN. >> > C. In case an assignment policy is ever established, the Board passed >> > a motion setting initial fees to be the same as allocations, with >> > maintenance fees consistent with other maintenance fees (currently >> > $100): >> > http://www.arin.net/library/minutes/bot/bot2004_0803.html item 12D. >> >> Right... That's what I'm hoping for in terms of ASSIGNMENT or NON- >> SUBSCRIBER policy. Stephen, does that address your fee concerns? > > If I'm understanding the terms correctly, this will mean that end sites > will pay only $100/yr. That seems perfectly acceptable for multihoming > purposes and probably even semi-connected networks (though this policy > doesn't apply to the latter). > $100/yr, exactly correct. As to semi-connected, it may or may not. Depends on the nature of their "semi-connection". > I'm initial fee still seems steep based on the lower level of review > needed under this policy, but I doubt I'd have trouble convincing mgmt to > pay it. Not an issue. > And, it might be possible to reduce that somewhat, too. >> Heck... Based on the above, it looks like if we get this policy >> implemented, >> the [fee] structure is already there. > > Indeed. Once ARIN gets around to putting this information in the fee > schedule, everything's fine on this front. > Cool... I suspect that will happen before the policy comes out of the AC. :-) 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 Michael.Dillon at radianz.com Tue Dec 7 05:44:01 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 7 Dec 2004 10:44:01 +0000 Subject: [ppml] Proposed Policy: PI assignments for V6 (and v6 fees) In-Reply-To: <20041206194505.F34A113E12@sa.vix.com> Message-ID: > i don't think it'll work like you're saying. let's say ULA goes into > general use and that a number of enterprises who are all customers of a > set of ISP's decide that rather than tunnelling, they'd like their > shared set of ISP's to "just route the ULA prefixes please." by > enterprise i'm talking Ford and GM and Daimler and their rust-belt supply > network, or perhaps Wal-Mart and its offshore vendor network. we know > what the ISP's will say: "yes, ma'am, and would you like fries with that?" This sounds a lot like what the European auto industry does with Deutsche Telekom, France Telecom, Telefonica and Infonet. http://www.enxo.com The original design for the ENX was to have these ISPs routing their traffic across separate peering connections from their other IP traffic. As far as I know it still works that way. The way to stop this is to create ULAs and also create geographically agregatable addresses. Then the vast majority of users who might otherwise have chosen the ULA peering route will instead choose to use geographically agregatable addresses. Traffic destined to Ford's plant in Sacramento will always head towards California regardless of which provider network it travels on. Do you think Ford really cares if the traffic bounces off of San Francisco before reaching Sacramento? > instead, > let's just recognize that a far larger segment of the enterprise community > needs PI than was previously believed, I strongly agree with this one. And I think we need a serious assessment of geographic addressing before we decide how to solve this. By serious, I mean some hard numbers that show us things like the number of households in every LATA in the USA as well as every Canadian province. In IPv6, the household is the basic unit of measure, better known as the /48. If we build a geographical addressing scheme that will handle the current number of households plus a bit, then we have something that will last for many years. And when it starts getting tight in one region or other, we can simply allocate a new continental agreggate because the impact on the global routing table will be minimal. We should be able to get this right with only these two allocations so that it will last the entire lifetime of IPv6 as we know it. > and transform all ULA arguments to > date into "PI reform" arguments, and then restore "site local" addressing, > which was valuable precisely because it was dangerous and self-limiting. Personally, I'm not that bothered by ULA addressing. And I expect that any address range set aside for site local will end up being used as ULA addresses because the random prefix idea is too good to go away. In fact, if ULAs don't make it through the IETF, then people will do this anyway. The box is open, we now have to deal with it. --Michael Dillon From marcelo at it.uc3m.es Tue Dec 7 05:49:05 2004 From: marcelo at it.uc3m.es (marcelo bagnulo braun) Date: Tue, 7 Dec 2004 11:49:05 +0100 Subject: [ppml] Proposed Policy: PI assignments for V6 In-Reply-To: <2147483647.1102335801@imac-en0.delong.sj.ca.us> References: <81464318-47BA-11D9-97A6-000D93ACD0FE@it> <2147483647.1102335801@imac-en0.delong.sj.ca.us> Message-ID: <9D4297F2-483D-11D9-97A6-000D93ACD0FE@it.uc3m.es> Hi Owen, El 06/12/2004, a las 21:23, Owen DeLong escribi?: [...] >> In any case, as you may well notice, any multihoming solution >> compatible >> with PA addressing will require that: >> - multiple PA prefixes configured in the multihomed sites (instead of >> one) >> - it won't provide PI addressing (so a multihomed site will still >> have to >> renumber if it changes providers) >> This two reasons make it a priori an inferior solution to obtaining PI >> addressing on the eyes of the multihomed site, even though it is a >> much >> superior solution in the eyes of the community since it preserves >> global >> routing system scalability. > > I think you have a different perception of the community than many on > this > list. The community includes the multihomed organizations as well as > the > providers. Ok. First of all, imho we should separate providers from end-sites. Providers imho should be able to get their own PA address block, since they will aggregate their customers blocks. As you may know in some regions any ISP can get their own PA block (IPv4) just paying the fee. imho that's good OTOH, imho end-sites should not, by default, be able to get their own IPv6 PI block, yet, until we explore other options. (just a terminology nit, if we are assigning address block to a provider, and this provider will assign it to their customers, it is by definition PA, right. OTOH, if we assign it directly to end-sites, this is really PI. So i am not sure that the terminology applied in the proposed policy really applies to isps, but in any case this is not the main issue here) > The reality is that PI as implemented in V6 currently provides > yet another path for provider-lockin through the difficulty of > renumbering > and many organizations do not consider that a palatable situation. OK, this is a very good point So we are not talking about using PI addressing to achieve multihoming here, but PI as a goal in itself, to obtain provider independence. OK, conceptually i very much subscribe to your p.o.v. that provider independence is a very important thing. However, i have have some concerns/questions: First, if provider independence is a value in itself, then why do you associate it it with multihoming? i mean, as i read the policy, the way for an end site to obtain a PI block is basically to be multihomed, why do you want to provide such privilege to multihomed users? i mean provider independence is a value for any user, multihomed or not. Moreover, if a multihomed user is using PA addressing from his upstreams, then i would argue that he is more independent from his isps than a single homed user. This is because he has two (or more) address blocks, so if he decides to change one of his providers, he still has the addresses from the other providers stable. In the case of a single homed user, when he decides to change his only provider, he has no stable addresses. So i would conclude that it would be better to provide a PI assignment policy that doesn't really depends on whether the user is multihomed or not. Second, are there any other options that would provide the benefits of pi without actually assigning pi blocks? i mean renumbering procedures in ipv6 are suppose to address some part of this problem, are there any operational experience that they are not good enough? ULAs are supposed to provide stable internal addressing without the problems caused by ambiguity, are there any operational experience that there are problems with this? are you aware of other features provided by PI addressing that should be addressed? (besides multihoming, i mean :-) Third, do we know that we can make PI addressing work/scale? or, to be fair, do we know that it doesn't work? from what i heard, some experts consider that this is a huge problem, but you may have heard different... > If v6 > ever delivers a solution that solves the various issues (multihoming in > various forms is but one of the issues) related to PA space, then, we > can > revisit and possibly repeal the policy. Unlike the v4 swamp, there's > no > address space in v6 that isn't subject to renewal by the registry. As > such, > policy changes can, in the v6 world, correct past allocation policies > in > the long run. Ok, i don't really buy this stuff I don't think we can easily correct mistakes, see v4 swamp now, see the % of the IPv4 address space that was assigned before CIDR. > >> In any case, if a PI assignment policy is adopted, the PA compatible >> multihoming solution won't get any chance to get deployed i guess, >> since >> i guess that multihomed sites will have the following choices: >> - A PA compatible solution which: doesn't provides provider >> independence, >> requires multiple prefixes and it is new i.e. no experience, no >> products, >> no previous knowledge >> - a PI multihoming solution: everything works as you already know >> What do you think multihomed sites will choose? >> > Or translated: > > You want to see PA multihoming get adopted even though you know it will > be perceived as an inferior solution by a significant portion of the > community. Therefore, you think ARIN should block the solution which > is > perceived as superior in order to support the other one. > YES, this is whole point since this is the only way we know to prevent the tragedy of the commons or public goods problem. Trust and enforcement. From the perception of each individual, the solution that preserves the public goods is an inferior solution, and it is probably more expensive/difficult for him. (in our case, a PA compatible multihoming solution will impose managing multiple prefixes, gaining new experience and so on) However, from the community p.o.v. this is the only solution in the log run. So how do solve this problem? You cannot expect that those who would get the benefit refrain themselves because they know that is the best thing to do for the community. So, the community as a whole has to preclude the behaviours that hinder/abuse from the public goods in benefiting a few ones (in our case public good=global routing table, the few ones that are benefited= multihomed users) So we should build policies that protect the community. Please note that trust is another fundamental factor, since the preservation of the public good only makes sense if everybody preserves it. So if trust is broken i.e. a behaviour that allows individual to benefit from the public good is permitted, then the trust is broken and you cannot expect anyone else to preserve the resource. (in other words, imho this is global problem, not local to a region, that is why i am here, so far from home :-) So i would indeed expect the community to prevent solutions that are perceived as superior by the individuals but are perceived as inferior by the community as a whole > Provider independence is a BIG IMPORTANT factor to a lot of > organizations > in the community. as i said before i very much agree with this point, but i would like to explore alternatives to achieve the same goal. In particular, i would like that people could give a chance to the PA compatible multihoming solution, and to IPv6 renumbering mechanisms, and ULAs and so on... > >> My proposal is to wait until a PA compatible solution for multihoming >> is >> developed and some experience is gained with it. Then we can see if >> it is >> useful and especially who is useful for. Probably it won't be good >> enough >> for some sites, and probably then we will need a PI asignment policy >> to >> satisfy the need of those sites. >> But we shouldn't do it now, that the multihoming solution is not yet >> here, and we would be killing it before it comes. >> > If it's truly beneficial i guess that by now, it is clear that the key question is: beneficial for who? for the community, of course. For the user, probably less beneficial that the PI based one (just because its experience with the existing solution) > when it comes, we can look at repealing this policy > or providing incentives for it. this means that we would be accepting a solution that we have serious hypothesis that doesn't scale without giving a chance to exploring other solutions that may work. i am not sure is like this approach > However, many organizations have real networks > to run in the meantime. We shouldn't abandon this policy just because > it > might interfere with the adoption rate of some future proposal that > may or > may not meet the desires of the community. i guess this is a key issue here. are current running networks have a desperate need for this PI assignment that we cannot wait to explore alternative solutions? Regards, marcelo > > Owen > > -- > If it wasn't crypto-signed, it probably didn't come from me. From Michael.Dillon at radianz.com Tue Dec 7 05:59:41 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 7 Dec 2004 10:59:41 +0000 Subject: [ppml] Provider Independence??? In-Reply-To: <2147483647.1102335801@imac-en0.delong.sj.ca.us> Message-ID: > Provider independence is a BIG IMPORTANT factor to a lot of organizations > in the community. What on earth is provider independence? Does it mean that a company wants to be their own network provider? Probably not because then they would have to haul fiber (or lightwaves) to every business partner. Of course, a few companies actually will go this far because there are lots of IRUs and lightpaths available, especially in metro areas. But that's not the core meaning. Seems to me that it means that a company wants their network addressing to be independent of the provider from whom they are buying Internet connectivity so that they can switch providers without incurring internal cost penalties that arise from reconfiguring a network. If that is what we are talking about, then we have a company who is in one physical location and they want addresses that identify that same physical location regardless of which network operator provides the last mile connection. This sounds very geographical to me. If ARIN had allocated a block of IPv6 addresses to be used only for locations in Sacramento then Ford could switch providers at will as long as those providers maintain a connection to a local Sacramento peering point. These would be provider independent (PI) addresses that stay with Ford Sacramento forever. In New York we will never see this PI block in the routing tables because it will be part of the Western USA aggregate. In Denver, we won't see it either because it will be part of the Northern California regional aggregate. In Los Angeles, it will only be visible in the network that won the bid for connecting all the Ford dealerships in California. That's because they want to route it internally on their fiber route that goes to SF via Sacramento rather than the main undersea fiber route that was lit two years ago in 2009. Doesn't this scenario make some kind of sense? Isn't it worth pursuing this class of solution to make sure that there are LOTS of PI address blocks available in v6? --Michael Dillon P.S. Apologies to Ford for singling them out but I really do think I have a better idea here. From L.Howard at stanleyassociates.com Tue Dec 7 10:48:11 2004 From: L.Howard at stanleyassociates.com (Howard, W. Lee) Date: Tue, 7 Dec 2004 10:48:11 -0500 Subject: [ppml] Provider Independence??? Message-ID: > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Michael.Dillon at radianz.com > Sent: Tuesday, December 07, 2004 6:00 AM > To: ppml at arin.net > Subject: [ppml] Provider Independence??? > > > If that is what we are talking about, then we have > a company who is in one physical location and they > want addresses that identify that same physical location > regardless of which network operator provides the last mile > connection. This sounds very geographical to me. If ARIN had > allocated a block of IPv6 addresses to be used only for > locations in Sacramento then Ford could switch providers at > will as long as those providers maintain a connection to a local > Sacramento peering point. Is it possible to peer privately? Is it possible to multihome to geographically diverse locations? Is it possible for an office to move to another location? > These would be provider independent (PI) addresses > that stay with Ford Sacramento forever. In New York > we will never see this PI block in the routing tables > because it will be part of the Western USA aggregate. Where is this aggregation occurring? > In Denver, we won't see it either because it will be > part of the Northern California regional aggregate. > In Los Angeles, it will only be visible in the network > that won the bid for connecting all the Ford dealerships > in California. If a single provider is connecting all those dealerships, then they don't have provider independence. If by going to another provider we lose aggregation, what's the benefit? Or have I completely missed your point? > --Michael Dillon > > P.S. Apologies to Ford for singling them out but > I really do think I have a better idea here. Lee From Michael.Dillon at radianz.com Tue Dec 7 11:17:33 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 7 Dec 2004 16:17:33 +0000 Subject: [ppml] Provider Independence??? In-Reply-To: Message-ID: > Is it possible to peer privately? Why not? > Is it possible to multihome to geographically diverse > locations? This costs money roughly proportional to circuit miles. One would hope that when ARIN determines the *ROUGH* boundaries for geographic agreggation, they leave in reasonable possibilities for separacy of connectivity. For instance the the Sacramento region might extend as far west as Walnut Creek on the edge of Berkeley. This isn't rocket science because people already do buy separacy, especially in a city like Sacramento. By the way, I'm borrowing the term separacy here from the SAN people to denote true diversity right down to layer one with "separate" entrances into the building. The desire for this kind of service is generally what drives the demand for multihoming. In any case, if people really feel a need to be connected outside of a local geographic agreggate, they can either buy connectivity in a neighboring region and slightly inflate the regional routing table. Or they can do traditional multihoming with the non-geographic v6 ranges currently on offer. Or they can do some whiz-bang stuff with the output of MULTI6. The point is that by giving people some choices we avoid the whole "swamp" thing. My definition of the IPv4 swamp is that it is what results when the address allocation rules do not offer the range of choices that networks need. In the early IPv4 days, this lack of flexibility resulted in the swamp. In the v6 scenario the details may be different. The v6 swamp may be ULAs that swell up the global routing table because endsites can't multihome in a local or regional way. > Is it possible for an office to move to another location? Not without doing a lot of work on the network infrastructure. Renumbering is minor compared with the work of physically moving everything. > > because it will be part of the Western USA aggregate. > > Where is this aggregation occurring? Good question. I don't know yet and I think it has to depend on the density of the population, i.e. the number of households per LATA. Perhaps it occurs everywhere. For instance, Sacramento and San Francisco are in the Northern California region. XPs located in both cities have circuits going to Denver. They both announce the Northern California agreggate to Denver as a matter of course. Now, maybe 1 XP in Denver *WANTS* to see the detail of Northern California. That's fine. On the other hand if both San Francisco and Sacramento have circuits to an XP in New York, I think it likely that they will be satisfied with the default announcement of Northern California. Geographically organized addressing isn't about forcing people into a single worldview of the v6 network. It's about creating the choices that allow people to build a network where the logical topology more closely matches the physical. And they can evolve into something that fits best. The original geographical aggregation hierarchy that ARIN creates will be a "best effort" and operators will evolve within that framework. > If a single provider is connecting all those dealerships, > then they don't have provider independence. If by going > to another provider we lose aggregation, what's the > benefit? I don't know. I didn't put this network out for bid. Maybe there is no benefit. That's the way things work today, ARIN creates a framework but individuals inside companies build networks in a lot of different ways. The economy sorts things out eventually and shows us who is doing the right thing. I want ARIN to create a geographic addressing framework and apply for the correct size of v6 address block to do this right, i.e. better than 50% chance of only having to ask for one geographic allocation. But it's up to the people in North America to build the networks as they see fit, including the choice to not use geographic addressing and the choice to use geographic addressing in dumb ways. --Michael Dillon From owen at delong.com Tue Dec 7 12:13:46 2004 From: owen at delong.com (Owen DeLong) Date: Tue, 07 Dec 2004 09:13:46 -0800 Subject: [ppml] Proposed Policy: PI assignments for V6 (and v6 fees) In-Reply-To: References: Message-ID: <2147483647.1102410826@imac-en0.delong.sj.ca.us> > The way to stop this is to create ULAs and also > create geographically agregatable addresses. Then > the vast majority of users who might otherwise have > chosen the ULA peering route will instead choose to > use geographically agregatable addresses. Traffic destined > to Ford's plant in Sacramento will always head towards California > regardless of which provider network it travels on. Do you > think Ford really cares if the traffic bounces off of > San Francisco before reaching Sacramento? > No. However, I don't think that the majority of providers will necessarily cooperate in the transit love-fest that you envision to make this actually work, either. >> instead, >> let's just recognize that a far larger segment of the enterprise > community >> needs PI than was previously believed, > > I strongly agree with this one. And I think we need a serious > assessment of geographic addressing before we decide how to > solve this. By serious, I mean some hard numbers that show us > things like the number of households in every LATA in the USA > as well as every Canadian province. In IPv6, the household is > the basic unit of measure, better known as the /48. If we > build a geographical addressing scheme that will handle the current > number of households plus a bit, then we have something that will > last for many years. And when it starts getting tight in one region > or other, we can simply allocate a new continental agreggate because > the impact on the global routing table will be minimal. We should > be able to get this right with only these two allocations so that > it will last the entire lifetime of IPv6 as we know it. > Noted, but, I'm not planning on adding geographical addressing to my proposal. If you want to propose geographical addressing, feel free in the appropriate ICANN or ARIN forum. Please don't use it as an excuse to side-track this proposal. > Personally, I'm not that bothered by ULA addressing. And I > expect that any address range set aside for site local will end > up being used as ULA addresses because the random prefix idea is > too good to go away. In fact, if ULAs don't make it through the > IETF, then people will do this anyway. > Nothing wrong with SLA being used as ULA. That's the intent. Difference is SLA is known non-unique, therefore, known not-globally routable. ULA, OTOH creates at least an illusion of uniqueness, giving any end-site with a quarter of a clue no reason not to expect their ISP to route it. My only objection to ULA is that it is PI under an insidious name. If we're going to have PI, let's call it PI and allocate it sanely. If we're going to claim no PI space, then, let's not create PI space. 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 paul at vix.com Tue Dec 7 12:19:51 2004 From: paul at vix.com (Paul Vixie) Date: Tue, 07 Dec 2004 17:19:51 +0000 Subject: [ppml] Proposed Policy: PI assignments for V6 (and v6 fees) In-Reply-To: Message from Michael.Dillon@radianz.com of "Tue, 07 Dec 2004 10:44:01 GMT." Message-ID: <20041207171951.5CCC313E12@sa.vix.com> > The way to stop this is to create ULAs and also > create geographically agregatable addresses. geo-agg makes sense inside dense networks like isp's but it's not the right model to capture the hairball nature of other networks. note that ITU-T has proposed political-agg, largely because they think that'll be the same as geo-agg and because they don't know how isp's are interconnected -- the idea seems to be a derivative of "let's keep local traffic local" but with no understanding of the non-hierarchical placement of exchange points. we COULD try to make geo-agg (or pol-agg) work, but it would be a new economy and infrastructure compared to the one we're trying to upgrade using ipv6. > In IPv6, the household is the basic unit > of measure, better known as the /48. that's obscene on so many levels. given that ietf chose a fixed-length addressing scheme for "IPng" based on the needs of low-level hardware, it was inevitable that certain fixed patterns would emerge in allocations -- for example, the /64-per-LAN idea used by EUI64. very few LANs in this century will have more than 65536 devices attached to them and the vast majority will have fewer than 256. however, EUI64 fits 18446744073709551616. some people (me, for example) call this wasteful, and wish that the EUI64 spec had used a denser hash function on the MAC rather than this sparse one. but if you buy into the EUI64 madness, it's really "8+8" in a way, and the "network part" of an address only has 64 bits in it. on the assumption that bits we don't use are wasted since not using them means they didn't need to be there and nobody wants to be wasteful, how do we "use" these other 64 bits? why, by allowing every household to have 65536 networks, even though most will have only one and very few will ever have more than 16. so ok, now we have the /48 as the basic unit of measure. however, if we allow these "microallocations" to be the general PI allocation to small and medium enterprise, then the routing table might someday have to contain 281474976710656 routes, and not even moore himself would say that's reasonable in our lifetimes, at least with distance-vector routing protocols like BGP. so it's clear that we still need hierarchical routing and that paths will follow addressing. it's also clear that political and geographical aggregation won't work unless the political/geographical "units of measure" become traffic carriers, traffic sources, traffic sinks, and traffic exchangers. that's not going to happen in our lifetimes, either. > > and transform all ULA arguments to date into "PI reform" arguments, > > and then restore "site local" addressing, which was valuable > > precisely because it was dangerous and self-limiting. > > Personally, I'm not that bothered by ULA addressing. And I expect that > any address range set aside for site local will end up being used as > ULA addresses because the random prefix idea is too good to go > away. In fact, if ULAs don't make it through the IETF, then people > will do this anyway. let me tell you a story. due to an accident of history, my name and phone number and e-mail address comes up when you do a "whois" on the network that contains the nameservers for the RFC1918 PTR zones, like 10.IN-ADDR.ARPA. when the AS112 (see www.as112.net) project first began, my phone started ringing, and a week never goes by without at least one call of the form: them: "hello, mr. vixie, why are you attacking my windows server?" me: "what do you mean? what are you talking about?" them: "PRISONER.IANA.ORG shows up in my 'netstat', and that's you, right?" me: "well, sort of, i mean, i guess it's me. did you read www.as112.net?" them: "yes, but i didn't understand it. why are you attacking my server?" me: "let me as you a couple of questions, ok?" them: "sure." me: "do you use 192.168.0.0 as your local network?" them: "yes." me: "do you use DHCP and is your DHCP server a windows machine?" them: "uh, yeah." me: "and do you have some number of windows desktops and laptops?" them: "yes." me: "can you grab one and check your 'network properties' and tell me if the box for 'update the dns' is checked in the 'advanced' tab?" them: "let me look. . yes, it is." me: "ok, you have to uncheck that box." them: "um, ok." me: "on every desktop and laptop you have." them: "ALL OF THEM?" me: "yes, all of them. plus any new ones you get." them: "and that'll remove PRISONER.IANA.ORG from my 'netstat'?" me: "yup." them: "uh, well, thanks, i guess." now, i'm not complaining. only about one in seven of these callers is rude and obnoxious and threatens to call the FBI and report my activities. but it gives me what i think is a very special perspective on your assertion that: > ... site local will end up being used as ULA addresses because the > random prefix idea is too good to go away. i do not expect the average v6 site-local user, or their vendors, to be any higher on the clue totem than the average RFC1918 user, or their vendors. that means i don't expect most of them to even become aware of the random prefix idea, and those that become aware of it will either find it too complex, too cumbersome, too ugly ("all those extra hex digits, ick"), or whatever. this is a plug-and-play world now. > The box is open, we now have to deal with it. if by "deal with" you mean enable and predict digital data market behaviour then i agree. sadly, a lot of people think they can "control" it -- ouch. From owen at delong.com Tue Dec 7 12:58:26 2004 From: owen at delong.com (Owen DeLong) Date: Tue, 07 Dec 2004 09:58:26 -0800 Subject: [ppml] Proposed Policy: PI assignments for V6 In-Reply-To: <9D4297F2-483D-11D9-97A6-000D93ACD0FE@it.uc3m.es> References: <81464318-47BA-11D9-97A6-000D93ACD0FE@it> <2147483647.1102335801@imac-en0.delong.sj.ca.us> <9D4297F2-483D-11D9-97A6-000D93ACD0FE@it.uc3m.es> Message-ID: <2147483647.1102413506@imac-en0.delong.sj.ca.us> >> I think you have a different perception of the community than many on >> this >> list. The community includes the multihomed organizations as well as >> the >> providers. > > Ok. First of all, imho we should separate providers from end-sites. That's already done. However, _BOTH_ are part of the community. > Providers imho should be able to get their own PA address block, since > they will aggregate their customers blocks. That's already policy, but, it's a PI block from which they assign PA space. However, in v6 policy, it's limited to providers that have a plan to assign addresses to 200+ organizations within some time period. > As you may know in some regions any ISP can get their own PA block (IPv4) > just paying the fee. imho that's good > OTOH, imho end-sites should not, by default, be able to get their own > IPv6 PI block, yet, until we explore other options. This is what you've already said. We can agree to disagree about it. > (just a terminology nit, if we are assigning address block to a provider, > and this provider will assign it to their customers, it is by definition > PA, right. OTOH, if we assign it directly to end-sites, this is really > PI. So i am not sure that the terminology applied in the proposed policy > really applies to isps, but in any case this is not the main issue here) > OK... Again, to clarify the terminology: If an RIR ALLOCATES or ASSIGNS a block, it is a PI block. The block can be used by the receiving entity regardless of what upstream(s) said entity does or does not remain connected to. The BLOCK, therefore is PROVIDER INDEPENDENT (PI). Once an RIR ALLOCATES a block to an LIR, the LIR (also the provider) can make ASSIGNMENTS from that block to END SITES. Those ASSIGNMENTS are considered PA (Provider Allocated) blocks. Hopefully this clarifies the terms PI, PA, ALLOCATE/ALLOCATION and ASSIGN/ ASSIGNMENT. The terminology in the policy is intended to apply to ISPS that have a small number of NETWORK customers and some number of SINGLE-ADDRESS customers as well as END SITES that have a need for PI space in order to obtain the same operational quality as what is currently present in IPv4. >> The reality is that PI as implemented in V6 currently provides >> yet another path for provider-lockin through the difficulty of >> renumbering >> and many organizations do not consider that a palatable situation. > > OK, this is a very good point > So we are not talking about using PI addressing to achieve multihoming > here, but PI as a goal in itself, to obtain provider independence. OK, > conceptually i very much subscribe to your p.o.v. that provider > independence is a very important thing. Good... At least we agree on part of this. Multihoming is an important part of provider independence in my opinion. Afterall, the only way to make a painless transition from one ISP to another is to be connected to both of them for some period of time. > However, i have have some concerns/questions: > First, if provider independence is a value in itself, then why do you > associate it it with multihoming? i mean, as i read the policy, the way > for an end site to obtain a PI block is basically to be multihomed, why > do you want to provide such privilege to multihomed users? i mean > provider independence is a value for any user, multihomed or not. Because there is value to the community in having some level of provider-based aggregation. The average small network which can live without multihoming can usually accept a renumber-based solution to provider migration. Larger sites that care more about this are usually multihomed. It provides a way to prevent a land-rush from overflowing the routing tables. It has worked quite well so far in the v4 arena with current assignment/allocation policies. Since we have a track record in v4 with a similar policy and it has worked well, it seemed like a good idea for initial v6 policy. > Moreover, if a multihomed user is using PA addressing from his upstreams, > then i would argue that he is more independent from his isps than a > single homed user. This is because he has two (or more) address blocks, > so if he decides to change one of his providers, he still has the > addresses from the other providers stable. In the case of a single homed > user, when he decides to change his only provider, he has no stable > addresses. So i would conclude that it would be better to provide a PI > assignment policy that doesn't really depends on whether the user is > multihomed or not. The problem with that is that his TCP sessions (or any other established flow) can't survive provider-death during the flow. As such, this form of multihoming does not meet the needs of a significant portion of the community. I agree that in an ideal world, it would be desirable to be able to give EVERYONE PI space and be done with it. Unfortunately, what is really needed is a separation between end-point identifier and route- descriptor. This didn't happen in IPv6, so, we are where we are... The only end-point identifier we have also has to serve as the route-descriptor. Given the limitations of current and likely future hardware, the global routing table simply can't support PI for absolutely everyone, so, we need to figure out some way to identify the greatest needs for PI space that we can support and go in that direction. First, obviously, is providers. That's already mostly taken care of, but, smaller providers are still out in the cold. This policy would rectify that. Second, in my opinion, is sites that require a unique routing policy. In general, that means multihoming. There are a few other cases. In any case, this policy also addresses those needs. Third, in my opinion, is the general case of every site should be able to tell their provider to take a hike and switch to a new provider relatively painlessly and without having to renumber. Unfortunately, it is not currently realistic to solve this problem. > Second, are there any other options that would provide the benefits of pi > without actually assigning pi blocks? i mean renumbering procedures in > ipv6 are suppose to address some part of this problem, are there any > operational experience that they are not good enough? ULAs are supposed > to provide stable internal addressing without the problems caused by > ambiguity, are there any operational experience that there are problems > with this? are you aware of other features provided by PI addressing that > should be addressed? (besides multihoming, i mean :-) The renumbering procedures that were supposed to be so easy in IPv6 were deprecated early in the process. Things like A6/DNAME that would have been a big help here were dropped because of some perceived complexity or risk. As such, v6 did not address the renumbering issue adequately to provide a meaningful alternative to PI. Yes, there is operational experience to support this. ULAs are a bad idea. ULAs are simply PI pretending not to be PI. In fact, the only reason I oppose ULAs is because they are an illusion. While there is no operational experience with ULAs (we haven't created them yet, how can we have operational experience with them), we do have operational experience with human nature. Paul Vixie posted a response on this thread about ULAs that summed it up pretty well. In short, human nature will migrate ULAs from Local to PI over time. How hard it is and how much time it takes is an unknown variable, but, over time, ULAs will become PI. Multihoming and Provider Independence from a service viability perspective are the biggies. Saying are there any other features provided besides these is sort of like saying "Are there any benefits to breathing, besides continuing to live?" > Third, do we know that we can make PI addressing work/scale? or, to be > fair, do we know that it doesn't work? from what i heard, some experts > consider that this is a huge problem, but you may have heard different... > I'm not sure who considers it a huge problem. I do think I have a certain amount of expertise in this area. I certainly have a fair amount of experience in this area. Based on operational experience over most of the last year with policies 2002-3 and 2003-15, it does not appear that an IPv4 land-rush was created by those policies. Worst case, if every ASN went for a prefix under this policy (remember, all those current transit ASNs won't go for one) and tried to expand the following day, you'd have approximately 60,000 new v6 routes. I think the current v6 table could handle that without difficulty, so, yes, it scales for now. The reality is that most probably won't go for it, and, I'll be surprised if this policy contributed 10,000 routes to the v6 table over the next 5 years. As to the long-term implications, such as what happens when we have more than 64k ASNs (Pekka's big concern), I still suspect you won't see more than 40 or 50,000 routes contributed by this policy. Even if we assume there are as many as 10,000 major ISPs world-wide that have to announce as many as 8 routes (remember, 8 /32s is 2 million customers, and, ISPs that burn through a couple of /32s probably get a /30 next time), that's still only 130,000 routes total. What's the current routing table size for v4? 160,000 or so? Yep... I think it scales. >> If v6 >> ever delivers a solution that solves the various issues (multihoming in >> various forms is but one of the issues) related to PA space, then, we >> can >> revisit and possibly repeal the policy. Unlike the v4 swamp, there's >> no >> address space in v6 that isn't subject to renewal by the registry. As >> such, >> policy changes can, in the v6 world, correct past allocation policies >> in >> the long run. > > Ok, i don't really buy this stuff > I don't think we can easily correct mistakes, see v4 swamp now, see the % > of the IPv4 address space that was assigned before CIDR. > Right... The v4 swamp was assigned before CIDR. The v4 swamp also has absolutely no right of reclamation or annual renewal. Addresses issued prior to the RIR system CAN NOT be taken away from the people that have them. Those people do not pay annual fees for them. That is a very different case from what would happen under this policy with v6. With this policy, the RIR can inform an organization that their allocation/assignment will not be renewed and that they must obtain replacement space under new policies. There's absolutely no way to do this with the v4 swamp because it is not subject to renewal. That's the key difference. Is it easy, no. However, it's possible, and, with patience, it's even easy. Just requires a substantial amount of time. However, I think that's OK. The big issue with the mistakes we made in v4 was to stop making them. The need to reverse the ones already made is not really a big deal to most of the community at this point. If we discover this was a bad idea, I think it would be much the same. Once we stopped the policy, the majority of the issue would be resolved. Recovering the existing allocations/assignments made under the policy would be much easier than in v4, but, similarly unnecessary. >> Or translated: >> >> You want to see PA multihoming get adopted even though you know it will >> be perceived as an inferior solution by a significant portion of the >> community. Therefore, you think ARIN should block the solution which >> is >> perceived as superior in order to support the other one. >> > > YES, this is whole point since this is the only way we know to prevent > the tragedy of the commons or public goods problem. > Trust and enforcement. Well... I don't subscribe to your theory of punish the masses to make my solution that favors the few more viable. > From the perception of each individual, the solution that preserves the > public goods is an inferior solution, and it is probably more > expensive/difficult for him. (in our case, a PA compatible multihoming > solution will impose managing multiple prefixes, gaining new experience > and so on) And it won't provide flow survivability. > However, from the community p.o.v. this is the only solution in the log > run. So how do solve this problem? Again, you attempt to define the community only in terms of providers. WRONG!!! The community includes the end sites too. I don't think your proposed solution is better for the community or for any of the individuals it claims to serve. I think it is an inferior solution that does not provide important elements that are available with PI space. It's only better for the ISPs. > So we should build policies that protect the community. Please note that > trust is another fundamental factor, since the preservation of the public > good only makes sense if everybody preserves it. So if trust is broken > i.e. a behaviour that allows individual to benefit from the public good > is permitted, then the trust is broken and you cannot expect anyone else > to preserve the resource. (in other words, imho this is global problem, > not local to a region, that is why i am here, so far from home :-) > Yes, and, I am attempting to do just that with this policy. I think this policy is a better solution for the community. The only people who don't benefit from this policy are large providers and certain transit networks. > So i would indeed expect the community to prevent solutions that are > perceived as superior by the individuals but are perceived as inferior by > the community as a whole > >> Provider independence is a BIG IMPORTANT factor to a lot of >> organizations >> in the community. > > as i said before i very much agree with this point, but i would like to > explore alternatives to achieve the same goal. In particular, i would > like that people could give a chance to the PA compatible multihoming > solution, and to IPv6 renumbering mechanisms, and ULAs and so on... > Please explain to me how established flows (excluding SCTP) survive provider failure in your scenario. If you can't, please accept that this policy is necessary. >> If it's truly beneficial > > i guess that by now, it is clear that the key question is: beneficial for > who? > for the community, of course. For the user, probably less beneficial that > the PI based one (just because its experience with the existing solution) > The USERs are the MAJORITY of the community. You need to learn this. You need to learn that LARGE PROVIDERS are the MINORITY in the community. They are the people that the USERs PAY in order to meet the needs of the USERs. >> when it comes, we can look at repealing this policy >> or providing incentives for it. > > this means that we would be accepting a solution that we have serious > hypothesis that doesn't scale without giving a chance to exploring other > solutions that may work. i am not sure is like this approach > I don't have any such serious hypothesis. I think this solution scales to the defined set of users just fine. I don't, on the other hand, believe anyone has proposed any other solutions that may actually work. > >> However, many organizations have real networks >> to run in the meantime. We shouldn't abandon this policy just because >> it >> might interfere with the adoption rate of some future proposal that >> may or >> may not meet the desires of the community. > > i guess this is a key issue here. are current running networks have a > desperate need for this PI assignment that we cannot wait to explore > alternative solutions? > There are current running networks that will not migrate to v6 until they can get PI assignments or allocations. Further, we have explored alternative solutions, and, the solutions that have been explored so far are very flawed from an end-user perspective. They do not provide the same fundamental capabilities as PI space and they require much greater administrative overhead on the part of the end-site to deal with their implementation. As such, as far as I am concerned, we have explored your proposed solution and deemed it inferior to PI space. This sentiment has been echoed on this list and others by multiple members of the community. (although possibly not by any large ISPs, so, possibly not by what you consider the community). 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 owen at delong.com Tue Dec 7 13:05:39 2004 From: owen at delong.com (Owen DeLong) Date: Tue, 07 Dec 2004 10:05:39 -0800 Subject: [ppml] Provider Independence??? In-Reply-To: References: Message-ID: <2147483647.1102413939@imac-en0.delong.sj.ca.us> The fundamental flaw with the theory of geographical aggregation is that it would need a form of provider transit love-fest to become feasible that simply isn't the reality of today's market conditions. If we had instituted this while it was still NSFnet and there was still a central authority that could drive such policies, it might have been possible. Today, you would need to get all the major providers in every region to agree to provide some form of transit for lots of people that aren't paying them to talk to lots of other people that aren't paying them. I just don't see that as being likely to happen. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From marcelo at it.uc3m.es Tue Dec 7 14:40:53 2004 From: marcelo at it.uc3m.es (marcelo bagnulo braun) Date: Tue, 7 Dec 2004 20:40:53 +0100 Subject: [ppml] Proposed Policy: PI assignments for V6 In-Reply-To: <2147483647.1102413506@imac-en0.delong.sj.ca.us> References: <81464318-47BA-11D9-97A6-000D93ACD0FE@it> <2147483647.1102335801@imac-en0.delong.sj.ca.us> <9D4297F2-483D-11D9-97A6-000D93ACD0FE@it.uc3m.es> <2147483647.1102413506@imac-en0.delong.sj.ca.us> Message-ID: El 07/12/2004, a las 18:58, Owen DeLong escribi?: >>> I think you have a different perception of the community than many on >>> this >>> list. The community includes the multihomed organizations as well as >>> the >>> providers. >> >> Ok. First of all, imho we should separate providers from end-sites. > > That's already done. However, _BOTH_ are part of the community. > agree with that >> Providers imho should be able to get their own PA address block, since >> they will aggregate their customers blocks. > > That's already policy, but, it's a PI block from which they assign PA > space. However, in v6 policy, it's limited to providers that have a > plan to assign addresses to 200+ organizations within some time period. > imho this is problem with current policy and need to be changed. This is not only a problem with small ISPs as you mention, but it is also a problem for transit providers who only sell transit to other isp and that may be less than 200, it is also a problem for mobile providers who may have millions of customers, but they only assign a /128 or a /64. i agree that there is a problem with the v6 policy >> As you may know in some regions any ISP can get their own PA block >> (IPv4) >> just paying the fee. imho that's good >> OTOH, imho end-sites should not, by default, be able to get their own >> IPv6 PI block, yet, until we explore other options. > > This is what you've already said. We can agree to disagree about it. > ok >> (just a terminology nit, if we are assigning address block to a >> provider, >> and this provider will assign it to their customers, it is by >> definition >> PA, right. OTOH, if we assign it directly to end-sites, this is really >> PI. So i am not sure that the terminology applied in the proposed >> policy >> really applies to isps, but in any case this is not the main issue >> here) >> > OK... Again, to clarify the terminology: > > If an RIR ALLOCATES or ASSIGNS a block, it is a PI block. The block > can > be used by the receiving entity regardless of what upstream(s) said > entity > does or does not remain connected to. The BLOCK, therefore is PROVIDER > INDEPENDENT (PI). > > Once an RIR ALLOCATES a block to an LIR, the LIR (also the provider) > can > make ASSIGNMENTS from that block to END SITES. Those ASSIGNMENTS are > considered PA (Provider Allocated) blocks. > > Hopefully this clarifies the terms PI, PA, ALLOCATE/ALLOCATION and > ASSIGN/ > ASSIGNMENT. > ok, i guess this is somehow different from the RIPE terminology, but i see what you mean > The terminology in the policy is intended to apply to ISPS that have a > small > number of NETWORK customers and some number of SINGLE-ADDRESS customers > as well as END SITES that have a need for PI space in order to obtain > the > same operational quality as what is currently present in IPv4. ok, my point is that i would treat these two separately. I don't have a problem with small isps getting their PI allocation, my objection are related to PI assignments to end sites > >>> The reality is that PI as implemented in V6 currently provides >>> yet another path for provider-lockin through the difficulty of >>> renumbering >>> and many organizations do not consider that a palatable situation. >> >> OK, this is a very good point >> So we are not talking about using PI addressing to achieve multihoming >> here, but PI as a goal in itself, to obtain provider independence. OK, >> conceptually i very much subscribe to your p.o.v. that provider >> independence is a very important thing. > > Good... At least we agree on part of this. Multihoming is an important > part of provider independence in my opinion. Afterall, the only way to > make a painless transition from one ISP to another is to be connected > to > both of them for some period of time. > >> However, i have have some concerns/questions: >> First, if provider independence is a value in itself, then why do you >> associate it it with multihoming? i mean, as i read the policy, the >> way >> for an end site to obtain a PI block is basically to be multihomed, >> why >> do you want to provide such privilege to multihomed users? i mean >> provider independence is a value for any user, multihomed or not. > > Because there is value to the community in having some level of > provider-based aggregation. The average small network which can live > without multihoming can usually accept a renumber-based solution to > provider migration. Larger sites that care more about this are > usually multihomed. It provides a way to prevent a land-rush from > overflowing the routing tables. It has worked quite well so far in > the v4 arena with current assignment/allocation policies. Since we > have a track record in v4 with a similar policy and it has worked > well, it seemed like a good idea for initial v6 policy. > I am not sure about this. I mean with current widespread of DSL and CATV and so one, a SOHO can be easily multihomed. I mean, i am not sure that being multihomed is an exclusive feature of really big and complex networks, i would expect that more and more homes will be multihomed. >> Moreover, if a multihomed user is using PA addressing from his >> upstreams, >> then i would argue that he is more independent from his isps than a >> single homed user. This is because he has two (or more) address >> blocks, >> so if he decides to change one of his providers, he still has the >> addresses from the other providers stable. In the case of a single >> homed >> user, when he decides to change his only provider, he has no stable >> addresses. So i would conclude that it would be better to provide a PI >> assignment policy that doesn't really depends on whether the user is >> multihomed or not. > > The problem with that is that his TCP sessions (or any other > established > flow) can't survive provider-death during the flow. i think we have a misunderstanding here... i was not considering this as a mutlihoming but a isp transition mechanism. My point was that if a multihomed site that has two PA blocks changes one of its providers, it still has the address space of the other provider stable. while if a single homed site changes provider, it has no stable address space (this was a sort of reason to show that single homed sites may be needing PI addressing more than multihomed sites) > As such, this form > of multihoming does not meet the needs of a significant portion of the > community. I agree that in an ideal world, it would be desirable to be > able to give EVERYONE PI space and be done with it. fully agree with this point (i guess that our differences are about the view of what is technically possible and what is not) > Unfortunately, what > is really needed is a separation between end-point identifier and > route- > descriptor. Yes > This didn't happen in IPv6, so, we are where we are... I didn't happen in the past but it is somehow happening now (at least an attempt to do something in this direction). Are you familiar with the work being done in multi6? i guess that at this point we diverge. multi6 is working to do this id/locator split that you consider necessary to solve this problem. The problem is that is not ready yet. If we give up waiting now, the PI approach will take over and the multi6 approach will never get a chance. So, if i were to give up, i probably agree with you that the steps that you mention below are a reasonable approach. The point is that imho we need more time before going there. I don't know how familiar you are with the work being done in multi6, but i would ask you to check it out and decide if it deserves to have a chance. > The > only end-point identifier we have also has to serve as the > route-descriptor. > Given the limitations of current and likely future hardware, the global > routing table simply can't support PI for absolutely everyone, so, we > need > to figure out some way to identify the greatest needs for PI space that > we can support and go in that direction. > > First, obviously, is providers. That's already mostly taken care > of, but, smaller providers are still out in the cold. This policy > would > rectify that. > > Second, in my opinion, is sites that require a unique routing policy. > In general, that means multihoming. There are a few other cases. In > any > case, this policy also addresses those needs. > > Third, in my opinion, is the general case of every site should be > able to tell their provider to take a hike and switch to a new provider > relatively painlessly and without having to renumber. Unfortunately, > it > is not currently realistic to solve this problem. > >> Second, are there any other options that would provide the benefits >> of pi >> without actually assigning pi blocks? i mean renumbering procedures >> in >> ipv6 are suppose to address some part of this problem, are there any >> operational experience that they are not good enough? ULAs are >> supposed >> to provide stable internal addressing without the problems caused by >> ambiguity, are there any operational experience that there are >> problems >> with this? are you aware of other features provided by PI addressing >> that >> should be addressed? (besides multihoming, i mean :-) > > The renumbering procedures that were supposed to be so easy in IPv6 > were > deprecated early in the process. Things like A6/DNAME that would have > been a big help here were dropped because of some perceived complexity > or risk. As such, v6 did not address the renumbering issue adequately > to > provide a meaningful alternative to PI. Yes, there is operational > experience to support this. > > ULAs are a bad idea. ULAs are simply PI pretending not to be PI. In > fact, > the only reason I oppose ULAs is because they are an illusion. While > there > is no operational experience with ULAs (we haven't created them yet, > how > can we have operational experience with them), we do have operational > experience with human nature. Paul Vixie posted a response on this > thread > about ULAs that summed it up pretty well. In short, human nature will > migrate ULAs from Local to PI over time. How hard it is and how much > time > it takes is an unknown variable, but, over time, ULAs will become PI. > > Multihoming and Provider Independence from a service viability > perspective > are the biggies. Saying are there any other features provided besides > these is sort of like saying "Are there any benefits to breathing, > besides > continuing to live?" > >> Third, do we know that we can make PI addressing work/scale? or, to be >> fair, do we know that it doesn't work? from what i heard, some experts >> consider that this is a huge problem, but you may have heard >> different... >> > I'm not sure who considers it a huge problem. I do think I have a > certain > amount of expertise in this area. I certainly have a fair amount of > experience in this area. Based on operational experience over most of > the > last year with policies 2002-3 and 2003-15, it does not appear that an > IPv4 land-rush was created by those policies. Worst case, if every ASN > went for a prefix under this policy (remember, all those current > transit > ASNs won't go for one) and tried to expand the following day, you'd > have > approximately 60,000 new v6 routes. I think the current v6 table could > handle that without difficulty, so, yes, it scales for now. The > reality > is that most probably won't go for it, and, I'll be surprised if this > policy contributed 10,000 routes to the v6 table over the next 5 years. > i agree that for the next few years there won't be problems with the size of the ipv6 routing table, but i don't agree with the next point, that the routing system will be able to deal with the load imposed by multihomed users in the future there are at least some doubts about this, see for instance RFC 3221 > As to the long-term implications, such as what happens when we have > more than 64k ASNs (Pekka's big concern), I still suspect you won't > see more than 40 or 50,000 routes contributed by this policy. why do you assume this? do you expect that there won't be more than 50,000 multihomed users? you don't buy the dsl catv soho multihoming? see rfc 3221 for the rationale about this (section 5.1 describes why a small site would want to multihome) i mean if there is no other multihoming solution, then all multihomed site will want a pi block is guess and those will be more than 50,000 i guess. > Even > if we assume there are as many as 10,000 major ISPs world-wide that > have to announce as many as 8 routes (remember, 8 /32s is 2 million > customers, and, ISPs that burn through a couple of /32s probably get > a /30 next time), that's still only 130,000 routes total. What's the > current routing table size for v4? 160,000 or so? > > Yep... I think it scales. > >>> If v6 >>> ever delivers a solution that solves the various issues (multihoming >>> in >>> various forms is but one of the issues) related to PA space, then, we >>> can >>> revisit and possibly repeal the policy. Unlike the v4 swamp, there's >>> no >>> address space in v6 that isn't subject to renewal by the registry. >>> As >>> such, >>> policy changes can, in the v6 world, correct past allocation policies >>> in >>> the long run. >> >> Ok, i don't really buy this stuff >> I don't think we can easily correct mistakes, see v4 swamp now, see >> the % >> of the IPv4 address space that was assigned before CIDR. >> > Right... The v4 swamp was assigned before CIDR. The v4 swamp also has > absolutely no right of reclamation or annual renewal. Addresses issued > prior to the RIR system CAN NOT be taken away from the people that have > them. Those people do not pay annual fees for them. That is a very > different case from what would happen under this policy with v6. > > With this policy, the RIR can inform an organization that their > allocation/assignment will not be renewed and that they must obtain > replacement space under new policies. Have you ever saw this really happening? do you really believe this is an option? i mean i don't think this is reasonable to do, actually. I mean, imagine you are an huge end site. Now you get a PI block, and you hardcode it into your apps. Now, the next year the riri decides to take it back and that you need to get a PA block, do you see this happening? > There's absolutely no way to > do this with the v4 swamp because it is not subject to renewal. > > That's the key difference. > > Is it easy, no. However, it's possible, and, with patience, it's even > easy. Just requires a substantial amount of time. However, I think > that's > OK. The big issue with the mistakes we made in v4 was to stop making > them. > The need to reverse the ones already made is not really a big deal to > most > of the community at this point. If we discover this was a bad idea, I > think it would be much the same. Once we stopped the policy, the > majority > of the issue would be resolved. Recovering the existing > allocations/assignments > made under the policy would be much easier than in v4, but, similarly > unnecessary. The point is that since we have been using this multihoming solution, we have not tried alternatives solution, so what will happen is that some folks will still have their PI address, and the others will have to wait for the new multihoming solution to be tried and deployed, all this with real IPv6 production widespread > >>> Or translated: >>> >>> You want to see PA multihoming get adopted even though you know it >>> will >>> be perceived as an inferior solution by a significant portion of the >>> community. Therefore, you think ARIN should block the solution which >>> is >>> perceived as superior in order to support the other one. >>> >> >> YES, this is whole point since this is the only way we know to prevent >> the tragedy of the commons or public goods problem. >> Trust and enforcement. > > Well... I don't subscribe to your theory of punish the masses to make > my solution that favors the few more viable. I really think that we have a misunderstanding here. I am not proposing to punish the masses. multihomed users =! masses actually multihomed users are really a minority that are heavily contributing with the pollution of the bgp global routing table So, waiting for a PA compatible multihoming solution is NOT punishing the masses Giving PI address blocks to multihomed users is benefiting a few ones (the multihomed users) at expenses of the whole community (all the other users that are not multihomed) So my theory is exactly the opposite of what you stated above > >> From the perception of each individual, the solution that preserves >> the >> public goods is an inferior solution, and it is probably more >> expensive/difficult for him. (in our case, a PA compatible multihoming >> solution will impose managing multiple prefixes, gaining new >> experience >> and so on) > > And it won't provide flow survivability. No, check multi6 work please > >> However, from the community p.o.v. this is the only solution in the >> log >> run. So how do solve this problem? > > Again, you attempt to define the community only in terms of providers. > WRONG!!! The community includes the end sites too. > > I don't think your proposed solution is better for the community or for > any of the individuals it claims to serve. I think it is an inferior > solution that does not provide important elements that are available > with PI space. It's only better for the ISPs. > I fail to see why you consider that i am trying to benefits the ISPs, but you for the record, this is not my intention. The growth of the bgp problem is a problem that affect all the internet users, not only isps. I mean, bgp table size limits for instance the reconvegence time of the routing system. This implies that if there is a failure, the routing system will take longer to recover, breaking for instance established communication. If we abuse of the routing system it won't provide the basic features needed. So i am definetly not concerned about the problems of the isps, i am concerned about the functioning of the internet. OTOH, i think you have some sort of misunderstanding of what a multi6 would provide (or at least attempts to provide. For instance session survivability is a preferred feature) >> So we should build policies that protect the community. Please note >> that >> trust is another fundamental factor, since the preservation of the >> public >> good only makes sense if everybody preserves it. So if trust is broken >> i.e. a behaviour that allows individual to benefit from the public >> good >> is permitted, then the trust is broken and you cannot expect anyone >> else >> to preserve the resource. (in other words, imho this is global >> problem, >> not local to a region, that is why i am here, so far from home :-) >> > Yes, and, I am attempting to do just that with this policy. I think > this > policy is a better solution for the community. The only people who > don't > benefit from this policy are large providers and certain transit > networks. > No, single homed users don't benefit from this policy but they will definitely suffer from it, if the routing sysem is not able to deal with the size of the routing table. (Just for the record, i still like the idea of sites not having to pay the cost of renumbering when changing isps, but i like more the idea of the routing system working properly, if you see what i mean) >> So i would indeed expect the community to prevent solutions that are >> perceived as superior by the individuals but are perceived as >> inferior by >> the community as a whole >> >>> Provider independence is a BIG IMPORTANT factor to a lot of >>> organizations >>> in the community. >> >> as i said before i very much agree with this point, but i would like >> to >> explore alternatives to achieve the same goal. In particular, i would >> like that people could give a chance to the PA compatible multihoming >> solution, and to IPv6 renumbering mechanisms, and ULAs and so on... >> > Please explain to me how established flows (excluding SCTP) survive > provider failure in your scenario. If you can't, please accept that > this > policy is necessary. Please see multi6 work and accept that this policy should wait until the multi6 solution has a fair chance :-) > >>> If it's truly beneficial >> >> i guess that by now, it is clear that the key question is: beneficial >> for >> who? >> for the community, of course. For the user, probably less beneficial >> that >> the PI based one (just because its experience with the existing >> solution) >> > The USERs are the MAJORITY of the community. You need to learn this. > You need to learn that LARGE PROVIDERS are the MINORITY in the > community. > They are the people that the USERs PAY in order to meet the needs of > the > USERs. Please, i very much agree with you on this but using your style on this... SINGLE-HOMED users are the MAJORITY of the community. MULTIHOMED users are the MINORITY of the community see my point? > >>> when it comes, we can look at repealing this policy >>> or providing incentives for it. >> >> this means that we would be accepting a solution that we have serious >> hypothesis that doesn't scale without giving a chance to exploring >> other >> solutions that may work. i am not sure is like this approach >> > I don't have any such serious hypothesis. I think this solution > scales > to the defined set of users just fine. I don't, on the other hand, > believe > anyone has proposed any other solutions that may actually work. > well we have already covered these points, DSL+CATV user case, RFC 3221 for some doubts if this would scale, multi6 work for a proposal of how this could work >> >>> However, many organizations have real networks >>> to run in the meantime. We shouldn't abandon this policy just >>> because >>> it >>> might interfere with the adoption rate of some future proposal that >>> may or >>> may not meet the desires of the community. >> >> i guess this is a key issue here. are current running networks have a >> desperate need for this PI assignment that we cannot wait to explore >> alternative solutions? >> > There are current running networks that will not migrate to v6 until > they > can get PI assignments or allocations. agree, but the cases that i know of are really big end sites. For those i suspect that we probably will need a policy of PI. But i would like that it is more restrictive that the one you have proposed and probably i would wait some time until we determine which users can be served by a multi6 solution > Further, we have explored alternative > solutions, and, the solutions that have been explored so far are very > flawed > from an end-user perspective. They do not provide the same fundamental > capabilities as PI space and they require much greater administrative > overhead on the part of the end-site to deal with their implementation. > please see the multi6 work, and point out what do you consider to be the problems flaws in it > As such, as far as I am concerned, we have explored your proposed > solution > and deemed it inferior to PI space. i don't know what you have explored, but the multi6 proposal have been available since washington IETF, and is still not complete i.e. you can contribute and state what is the features that you need > This sentiment has been echoed on this > list and others by multiple members of the community. (although > possibly not > by any large ISPs, so, possibly not by what you consider the > community). > again, i don't see where do get this idea from :-( regards, marcelo > Owen > > -- > If it wasn't crypto-signed, it probably didn't come from me. From michel at arneill-py.sacramento.ca.us Tue Dec 7 22:00:13 2004 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 7 Dec 2004 19:00:13 -0800 Subject: [ppml] Proposed Policy: PI assignments for V6 (and v6 fees) Message-ID: > Owen DeLong > ULA OTOH creates at least an illusion of uniqueness, > giving any end-site with a quarter of a clue no > reason not to expect their ISP to route it. Indeed, and since numbers of these end-sites would be willing to pay a reasonable fee to ARIN to get PI space, they would just transfer the payment from the RIR to their ISP. > My only objection to ULA is that it is PI under > an insidious name. It's actually worse, because in most cases ULAs would not be traceable back to the source because they would not be registered. Even everyone-can-get-one, low $$$ PI direct from ARIN to the end-site would be better than ULAs-turned-PI. > If we're going to have PI, let's call it PI and > allocate it sanely. If we're going to claim no > PI space, then, let's not create PI space. I made that point myself earlier, and this is where your proposal has merit, because unlike ULAs that try to dissimulate what they really are, your proposal calls for a debate on the real issue: do we or do we not want to create PI addresses for v6 and if yes what would be the policies to allocate them. Michel. From kurtis at kurtis.pp.se Wed Dec 8 02:21:49 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Wed, 8 Dec 2004 08:21:49 +0100 Subject: [ppml] Provider Independence??? In-Reply-To: <2147483647.1102413939@imac-en0.delong.sj.ca.us> References: <2147483647.1102413939@imac-en0.delong.sj.ca.us> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-12-07, at 19.05, Owen DeLong wrote: > The fundamental flaw with the theory of geographical aggregation is > that > it would need a form of provider transit love-fest to become feasible > that > simply isn't the reality of today's market conditions. If we had > instituted > this while it was still NSFnet and there was still a central authority > that > could drive such policies, it might have been possible. Today, you > would > need to get all the major providers in every region to agree to provide > some form of transit for lots of people that aren't paying them to talk > to lots of other people that aren't paying them. I just don't see that > as being likely to happen. Is anyone still actually proposing geo based addressing (short of the ITU-T) ? - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQbarlaarNKXTPFCVEQIxVQCeIp2IUVSS1gyP8AwhEuWuNpaVKt4AoMp8 q4GhxEN3mwfp6RNSgqV80SJz =bVfe -----END PGP SIGNATURE----- From kurtis at kurtis.pp.se Wed Dec 8 02:21:04 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Wed, 8 Dec 2004 08:21:04 +0100 Subject: [ppml] Proposed Policy: PI assignments for V6 In-Reply-To: <2147483647.1102413506@imac-en0.delong.sj.ca.us> References: <81464318-47BA-11D9-97A6-000D93ACD0FE@it> <2147483647.1102335801@imac-en0.delong.sj.ca.us> <9D4297F2-483D-11D9-97A6-000D93ACD0FE@it.uc3m.es> <2147483647.1102413506@imac-en0.delong.sj.ca.us> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-12-07, at 18.58, Owen DeLong wrote: > Good... At least we agree on part of this. Multihoming is an important > part of provider independence in my opinion. Afterall, the only way to > make a painless transition from one ISP to another is to be connected > to > both of them for some period of time. I am not sure I buy this that easily. Are you saying that the only way to do ISP transition is with PI addresses and being connected to both ISPs at the same time? > Because there is value to the community in having some level of > provider-based aggregation. The average small network which can live > without multihoming can usually accept a renumber-based solution to > provider migration. Larger sites that care more about this are > usually multihomed. It provides a way to prevent a land-rush from > overflowing the routing tables. It has worked quite well so far in > the v4 arena with current assignment/allocation policies. Since we > have a track record in v4 with a similar policy and it has worked > well, it seemed like a good idea for initial v6 policy. Do we? How much of these problems are really just covered up with NAT? And how many enterprises that you argue would like your PI+multihoming capability would much rather that their NAT boxes worked with v6 so they didn't have to learn about that comples routing stuff? > The problem with that is that his TCP sessions (or any other > established > flow) can't survive provider-death during the flow. As such, this form > of multihoming does not meet the needs of a significant portion of the > community. I agree that in an ideal world, it would be desirable to be > able to give EVERYONE PI space and be done with it. Unfortunately, > what > is really needed is a separation between end-point identifier and > route- > descriptor. This didn't happen in IPv6, so, we are where we are... The > only end-point identifier we have also has to serve as the > route-descriptor. > Given the limitations of current and likely future hardware, the global > routing table simply can't support PI for absolutely everyone, so, we > need > to figure out some way to identify the greatest needs for PI space that > we can support and go in that direction. Marcelo already pointed this out but I think you really ought to catch up with the work in multi6. > The renumbering procedures that were supposed to be so easy in IPv6 > were > deprecated early in the process. Things like A6/DNAME that would have > been a big help here were dropped because of some perceived complexity > or risk. As such, v6 did not address the renumbering issue adequately > to > provide a meaningful alternative to PI. Yes, there is operational > experience to support this. This is not what is argued through several internet-drafts on renumbering in v6. Those are also based on operational experience AFAIK. Seems YMMV quite a lot. > Right... The v4 swamp was assigned before CIDR. The v4 swamp also has > absolutely no right of reclamation or annual renewal. Addresses issued > prior to the RIR system CAN NOT be taken away from the people that have > them. Those people do not pay annual fees for them. That is a very > different case from what would happen under this policy with v6. I have no problem with the v4 swamp that is not advertised and no longer in use. I have a problem with the v4 swamp that IS advertised and IS being used.... >> However, from the community p.o.v. this is the only solution in the >> log >> run. So how do solve this problem? > > Again, you attempt to define the community only in terms of providers. > WRONG!!! The community includes the end sites too. > > I don't think your proposed solution is better for the community or for > any of the individuals it claims to serve. I think it is an inferior > solution that does not provide important elements that are available > with PI space. It's only better for the ISPs. I think PI for v6 is fine coupled with smd's old suggestion of transit providers charging per announced prefix. That is AFAIk the only model with give away PI that works. And PI+ASN = give away PI today. That said. There are a few things I think is being forgotten in this discussion, and I really, really didn't want to point this out, but I guess I have to. PI space have the property that you can take it with you when you change providers, and really only solves renumbering. It does not give you anything wrt provider independence you do not already have. Why? Because you can today already either get multiple PAs, which won't help the problem with surviving TCP flows, but honestly, PI won't help you with that either. The multiple PAs help with migration. So, why else do you want PA space, redundancy? Sure, as an end-site you will today get a /48. There is nothing in the world to prevent you from advertising your /48 to several upstreams, except filtering by the upstreams. Will PI space help you there? Not if the PI space is /48.... > Please explain to me how established flows (excluding SCTP) survive > provider failure in your scenario. If you can't, please accept that > this > policy is necessary. See all the multi6dt drafts and year worth of multi6 email. > There are current running networks that will not migrate to v6 until > they > can get PI assignments or allocations. Current running networks will migrate to v6 when they see a business need. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQbarZ6arNKXTPFCVEQJcpQCg3jMX1uiJ4gy32nXhimfzgZu0elwAnj5c LCYIp1VS5oOBv043sbZNhTtg =z9+7 -----END PGP SIGNATURE----- From bmanning at vacation.karoshi.com Wed Dec 8 04:39:43 2004 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 8 Dec 2004 09:39:43 +0000 Subject: [ppml] Provider Independence??? In-Reply-To: References: <2147483647.1102413939@imac-en0.delong.sj.ca.us> Message-ID: <20041208093943.GA19470@vacation.karoshi.com.> On Wed, Dec 08, 2004 at 08:21:49AM +0100, Kurt Erik Lindqvist wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 2004-12-07, at 19.05, Owen DeLong wrote: > > > The fundamental flaw with the theory of geographical aggregation is > > that > > it would need a form of provider transit love-fest to become feasible > > that > > simply isn't the reality of today's market conditions. If we had > > instituted > > this while it was still NSFnet and there was still a central authority > > that > > could drive such policies, it might have been possible. Today, you > > would > > need to get all the major providers in every region to agree to provide > > some form of transit for lots of people that aren't paying them to talk > > to lots of other people that aren't paying them. I just don't see that > > as being likely to happen. > > Is anyone still actually proposing geo based addressing (short of the > ITU-T) ? > > - - kurtis - > sure ... like exchange points. --bill From Michael.Dillon at radianz.com Wed Dec 8 07:07:26 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 8 Dec 2004 12:07:26 +0000 Subject: [ppml] Proposed Policy: PI assignments for V6 In-Reply-To: <2147483647.1102413506@imac-en0.delong.sj.ca.us> Message-ID: > Right... The v4 swamp was assigned before CIDR. The v4 swamp also has > absolutely no right of reclamation or annual renewal. Addresses issued > prior to the RIR system CAN NOT be taken away from the people that have > them. Those people do not pay annual fees for them. That is a very > different case from what would happen under this policy with v6. I disagree. If there is ever a real crunch on the IPv4 address space then we most certainly will impose annual fees on the swamp and/or reclaim and reissue those addresses. This is no different from domain names which once were free and now are not. IP addresses are not property. Nobody owns them. The right to use IP addresses derives from the community of Internet users and is coordinated by those users through the RIR system. --Michael Dillon From Michael.Dillon at radianz.com Wed Dec 8 07:17:24 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 8 Dec 2004 12:17:24 +0000 Subject: [ppml] Provider Independence??? In-Reply-To: <2147483647.1102413939@imac-en0.delong.sj.ca.us> Message-ID: > The fundamental flaw with the theory of geographical aggregation is that > it would need a form of provider transit love-fest to become feasible that > simply isn't the reality of today's market conditions. That's a big mouthful. Love-fest is not a network technical term so I have no idea what you are driving at. Clearly, providers do currently interconnect through private peering and through exchange points. There is no single model for how these interconnects are organized and managed. I see no reason to assume that all providers would reject routing addresses that require them to have peering connections with their local competitors since many of them already have such peering connections to reduce their costs. Secondly, the reality of today's market conditions is not equivalent in all regions of North America or in all regions of the world. One could reasonably assume that at any given point of time, some region somewhere is in recession. This is not a good reason to not do geographic addressing. >Today, you would > need to get all the major providers in every region to agree to provide > some form of transit for lots of people that aren't paying them to talk > to lots of other people that aren't paying them. I just don't see that > as being likely to happen. I have no idea what you are talking about. This sounds like you are taking the position of the big five networks circa 1994 who were trying to prevent their customers from selling connectivity to downstream ISPs. The market has worked out this problem. We have lots of paths with greater than 2 ASNs in them. Geographic addressing doesn't change this in any way. --Michael Dillon From Michael.Dillon at radianz.com Wed Dec 8 07:24:15 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 8 Dec 2004 12:24:15 +0000 Subject: [ppml] Proposed Policy: PI assignments for V6 (and v6 fees) In-Reply-To: Message-ID: > It's actually worse, because in most cases ULAs would not be traceable > back to the source because they would not be registered. Wrong. ULAs are easy to track back to the source. First check the DHCP6 server and if it's not there, someone on the LAN has an unauthorized machine. Traceroute should localise the switch and then you can check the MAC address and ask the switch which port it's plugged into. It can't be an external source because there's a filter on the Internet gateway blocking the whole ULA range. --Michael Dillon From william at elan.net Wed Dec 8 07:55:51 2004 From: william at elan.net (william(at)elan.net) Date: Wed, 8 Dec 2004 04:55:51 -0800 (PST) Subject: [ppml] Proposed Policy: PI assignments for V6 In-Reply-To: Message-ID: On Wed, 8 Dec 2004 Michael.Dillon at radianz.com wrote: > > Right... The v4 swamp was assigned before CIDR. The v4 swamp also has > > absolutely no right of reclamation or annual renewal. Addresses issued > > prior to the RIR system CAN NOT be taken away from the people that have > > them. Those people do not pay annual fees for them. That is a very > > different case from what would happen under this policy with v6. > > I disagree. If there is ever a real crunch on the IPv4 address > space then we most certainly will impose annual fees on the > swamp and/or reclaim and reissue those addresses. This is no > different from domain names which once were free and now are > not. IP addresses are not property. Nobody owns them. The right > to use IP addresses derives from the community of Internet users > and is coordinated by those users through the RIR system. Annual maintanance fees for organizations is $100/year no matter number of ip blocks, ASNs, etc. We could require all legacy holders to pay this fee (it already happens to those who want ip block name changed or some other serious service change from arin) but I doubt it will seriously change anything and its certainly does not impose any financial pressure on them to change how ip blocks are used. So if we follow your intent (when there is ip4 crunch), ARIN would need to start chargning annual maintance fees for ALL assigned ip blocks (no matter legacy or not) in the same manner as for IPSs. I think we might run into serious opposition to this idea from all those who have these blocks (consider difference of paying $100/year and $5000/year!). Reclaiming is more likely to be successfull and have positive total effect and could free up for reuse 10 - 15% of ip4 space. -- William Leibzon Elan Networks william at elan.net From david.kessens at nokia.com Wed Dec 8 07:32:29 2004 From: david.kessens at nokia.com (David Kessens) Date: Wed, 8 Dec 2004 04:32:29 -0800 Subject: [ppml] Proposed Policy: PI assignments for V6 In-Reply-To: References: <81464318-47BA-11D9-97A6-000D93ACD0FE@it> <2147483647.1102335801@imac-en0.delong.sj.ca.us> <9D4297F2-483D-11D9-97A6-000D93ACD0FE@it.uc3m.es> <2147483647.1102413506@imac-en0.delong.sj.ca.us> Message-ID: <20041208123229.GA8428@nokia.com> Marcelo, On Tue, Dec 07, 2004 at 08:40:53PM +0100, marcelo bagnulo braun wrote: > > imho this is problem with current policy and need to be changed. This > is not only a problem with small ISPs as you mention, but it is also a > problem for transit providers who only sell transit to other isp and > that may be less than 200, it is also a problem for mobile providers > who may have millions of customers, but they only assign a /128 or a /64. I haven't seen any plans for mobile providers to assign /128's. I agree that the 200 limit is not optimal. However, I have not heard of a single mobile provider who could not get the ipv6 addresses that they needed. David Kessens --- From marcelo at it.uc3m.es Wed Dec 8 09:12:32 2004 From: marcelo at it.uc3m.es (marcelo bagnulo braun) Date: Wed, 8 Dec 2004 15:12:32 +0100 Subject: [ppml] Provider Independence??? In-Reply-To: References: Message-ID: <33E15679-4923-11D9-9194-000D93ACD0FE@it> Hi Michael, I guess that the problem that Owen is pointing out is that when there are multiple ISP providing service to users within the same geographical region, all these providers will have to announce the aggregate address block that corresponds to the complete region. Since all the isps are announcing the whole geo block, this means that they will receive packets for all the users within the region, some of which won't be their direct costumers. At the end of the day, this means that ISPA will be carrying traffic for some of the customers of ISPB, which i guess lacks of a business case. Regards, marcelo El 08/12/2004, a las 13:17, Michael.Dillon at radianz.com escribi?: >> The fundamental flaw with the theory of geographical aggregation is >> that >> it would need a form of provider transit love-fest to become feasible > that >> simply isn't the reality of today's market conditions. > > That's a big mouthful. > > Love-fest is not a network technical term so I have > no idea what you are driving at. Clearly, providers > do currently interconnect through private peering and > through exchange points. There is no single model for > how these interconnects are organized and managed. I see > no reason to assume that all providers would reject > routing addresses that require them to have peering > connections with their local competitors since many > of them already have such peering connections to reduce > their costs. > > Secondly, the reality of today's market conditions is > not equivalent in all regions of North America or in all > regions of the world. One could reasonably assume that at > any given point of time, some region somewhere is in > recession. This is not a good reason to not do geographic > addressing. > >> Today, you would >> need to get all the major providers in every region to agree to >> provide >> some form of transit for lots of people that aren't paying them to >> talk >> to lots of other people that aren't paying them. I just don't see >> that >> as being likely to happen. > > I have no idea what you are talking about. This sounds like > you are taking the position of the big five networks circa 1994 > who were trying to prevent their customers from selling connectivity > to downstream ISPs. The market has worked out this problem. > We have lots of paths with greater than 2 ASNs in them. > Geographic addressing doesn't change this in any way. > > --Michael Dillon > From marcelo at it.uc3m.es Wed Dec 8 09:17:35 2004 From: marcelo at it.uc3m.es (marcelo bagnulo braun) Date: Wed, 8 Dec 2004 15:17:35 +0100 Subject: [ppml] Proposed Policy: PI assignments for V6 In-Reply-To: <20041208123229.GA8428@nokia.com> References: <81464318-47BA-11D9-97A6-000D93ACD0FE@it> <2147483647.1102335801@imac-en0.delong.sj.ca.us> <9D4297F2-483D-11D9-97A6-000D93ACD0FE@it.uc3m.es> <2147483647.1102413506@imac-en0.delong.sj.ca.us> <20041208123229.GA8428@nokia.com> Message-ID: Hi David, El 08/12/2004, a las 13:32, David Kessens escribi?: > > Marcelo, > > On Tue, Dec 07, 2004 at 08:40:53PM +0100, marcelo bagnulo braun wrote: >> >> imho this is problem with current policy and need to be changed. This >> is not only a problem with small ISPs as you mention, but it is also a >> problem for transit providers who only sell transit to other isp and >> that may be less than 200, it is also a problem for mobile providers >> who may have millions of customers, but they only assign a /128 or a >> /64. > > I haven't seen any plans for mobile providers to assign /128's. > well, reading RFC 3177 recommends to assign: - /128 when it is absolutely known that one and only one device is connecting. i guess that most current mobile phones would fit in this category (yes i am familiar with manets and so on but i guess that most cell phones only connect one device) > I agree that the 200 limit is not optimal. However, I have not heard > of a single mobile provider who could not get the ipv6 addresses that > they needed. Agree, but i guess that the point is that policy should be crisp and clear and should express the reality But this is a different discussion, imho, and i guess this is a more local discussion. My concern with this PI initiative is that i see more of a global issue Regards, marcelo > > David Kessens > --- > From david.kessens at nokia.com Wed Dec 8 09:43:24 2004 From: david.kessens at nokia.com (David Kessens) Date: Wed, 8 Dec 2004 06:43:24 -0800 Subject: [ppml] Proposed Policy: PI assignments for V6 In-Reply-To: References: <81464318-47BA-11D9-97A6-000D93ACD0FE@it> <2147483647.1102335801@imac-en0.delong.sj.ca.us> <9D4297F2-483D-11D9-97A6-000D93ACD0FE@it.uc3m.es> <2147483647.1102413506@imac-en0.delong.sj.ca.us> Message-ID: <20041208144324.GC8738@nokia.com> Marcelo, On Wed, Dec 08, 2004 at 03:17:35PM +0100, marcelo bagnulo braun wrote: > > well, reading RFC 3177 recommends to assign: > > - /128 when it is absolutely known that one and only one device > is connecting. > > i guess that most current mobile phones would fit in this category (yes > i am familiar with manets and so on but i guess that most cell phones > only connect one device) You are describing why mobiles don't fit in the /128 category: it is certainly not absolutely known that only one device is connecting. > >I agree that the 200 limit is not optimal. However, I have not heard > >of a single mobile provider who could not get the ipv6 addresses that > >they needed. > > Agree, but i guess that the point is that policy should be crisp and > clear and should express the reality > But this is a different discussion, imho, and i guess this is a more > local discussion. > My concern with this PI initiative is that i see more of a global issue I agree that there is issues with the current policy for various categories of address space users but I don't see the problem for mobile providers. They clearly qualify and the registries agree considering the allocations that have been done so far. David Kessens --- From Michael.Dillon at radianz.com Wed Dec 8 10:12:35 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 8 Dec 2004 15:12:35 +0000 Subject: [ppml] Provider Independence??? In-Reply-To: <33E15679-4923-11D9-9194-000D93ACD0FE@it> Message-ID: > At the end of the day, this means that > ISPA will be carrying traffic for some of the customers of ISPB, which > i guess lacks of a business case. Please remember that we are talking about IPv6 here not IPv4. In other words we are talking about a network which does not currently exist. There is no reason why it has to be deployed identically to v4 with just a different layer 3 protocol. It will likely be different in many ways, depending on what applications it is built to support. I can envision ISPA operating in 3 regions with 4 ASNs, 1 for each region and one for their non-geographic network. They would only announce the geo aggregate for region 1 using their region 1 AS. This means that they will only be carrying some of ISPBs traffic if that traffic is destined to region 1. Since both ISPs operate in region 1 they will have some sort of peering agreement at region 1 exchange points. Otherwise the traffic would never get to it's destination in ISPB's network and ISPA would also lose traffic that comes in on ISPB's regional links. So the business case is clear, as it was back in the early 90's. Everybody needs to carry competitor's traffic in order to create the "network effect" which makes the network valuable to customers. And any imbalances are worked out in peering and transit agreements. In fact, I think the real leaders in this will not be the ISPs but the exchange points, especially the larger operations like Equinix. If geo addressing is accepted in v6, then this allows for the v6 network to be built as a network of exchange points. I believe that this will provide better resiliency and seperacy than v6 networks and that, in the end, will drive the mass migration to v6 networks. --Michael Dillon From Michael.Dillon at radianz.com Wed Dec 8 10:33:06 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 8 Dec 2004 15:33:06 +0000 Subject: [ppml] Geographic v6 addresses Message-ID: For those interested in the issue of geographic addressing in IPv6 you should probably read this current draft by Tony Hain http://www.potaroo.net/ietf/idref/draft-hain-ipv6-pi-addr-use/ I happen to disagree with his proposal to encode longitude and latitude into such addresses because I believe that it will cause many people to NOT use them due to fear of security issues. Instead, I favour a scenario in which the geographic addresses are tied to exchange point locations, not endpoint locations. I also favour a somewhat fuzzier unit of subdivision so that the RIRs only apply the geographic topology of the addresses down to a certain level, certainly no more granular than city or county. From a network perspective, there is no reason why an organization needing PI addresses needs to identify their exact location. It's good enough to know that they connect to an ISP who connects to and exchange point in city X. That way, if the Russian embassy in Washington DC feels the need to use Moscow IP addresses, they can tunnel back home and do so. There may even be a perfectly valid reason for doing this to enable diplomats and their laptops to easily travel back and forth. ------------------------------------------------------- Michael Dillon Capacity Management, 66 Prescot St., London, E1 8HG, UK Mobile: +44 7900 823 672 Internet: michael.dillon at radianz.com Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 http://www.radianz.com Voted "Best Network Provider 2004" Waters Magazine From jeroen at unfix.org Wed Dec 8 10:47:16 2004 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 08 Dec 2004 16:47:16 +0100 Subject: [ppml] Geographic v6 addresses In-Reply-To: References: Message-ID: <1102520836.6383.3.camel@firenze.zurich.ibm.com> On Wed, 2004-12-08 at 15:33 +0000, Michael.Dillon at radianz.com wrote: > For those interested in the issue of geographic addressing in IPv6 > you should probably read this current draft by Tony Hain > http://www.potaroo.net/ietf/idref/draft-hain-ipv6-pi-addr-use/ > Instead, I favour a scenario in which the geographic > addresses are tied to exchange point locations, not endpoint > locations. The big question: Who is going to pay for who's traffic. > That way, if the Russian embassy in Washington DC > feels the need to use Moscow IP addresses, they can tunnel > back home and do so. I seem to fail to see where the (IP level) 'multihoming' argument comes in here... > There may even be a perfectly valid > reason for doing this to enable diplomats and their laptops > to easily travel back and forth. Never heard of the various mobility protocols I assume? Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From owen at delong.com Wed Dec 8 11:55:47 2004 From: owen at delong.com (Owen DeLong) Date: Wed, 08 Dec 2004 08:55:47 -0800 Subject: [ppml] Proposed Policy: PI assignments for V6 In-Reply-To: References: Message-ID: <2147483647.1102496147@imac-en0.delong.sj.ca.us> --On Wednesday, December 8, 2004 12:07 PM +0000 Michael.Dillon at radianz.com wrote: >> Right... The v4 swamp was assigned before CIDR. The v4 swamp also has >> absolutely no right of reclamation or annual renewal. Addresses issued >> prior to the RIR system CAN NOT be taken away from the people that have >> them. Those people do not pay annual fees for them. That is a very >> different case from what would happen under this policy with v6. > > I disagree. If there is ever a real crunch on the IPv4 address > space then we most certainly will impose annual fees on the > swamp and/or reclaim and reissue those addresses. This is no > different from domain names which once were free and now are > not. IP addresses are not property. Nobody owns them. The right > to use IP addresses derives from the community of Internet users > and is coordinated by those users through the RIR system. Under what authority? You have no right. Those addresses were assigned under an agreement that said they were assigned in perpetuity. Any attempt by any collection of ISPs or others to prevent them reasonable access to the internet under terms available to any other RIR/ICANN/NIC assigned block would be a violation of law, at least in the US. The v4 swamp is the v4 swamp. Draining it would require voluntary cooperation of the address owners. You might or might not get that. Certainly, you will meet rather fierce opposition if you attempt to simply impose it. 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 owen at delong.com Wed Dec 8 11:59:22 2004 From: owen at delong.com (Owen DeLong) Date: Wed, 08 Dec 2004 08:59:22 -0800 Subject: [ppml] Provider Independence??? In-Reply-To: References: Message-ID: <2147483647.1102496362@imac-en0.delong.sj.ca.us> >> Today, you would >> need to get all the major providers in every region to agree to provide >> some form of transit for lots of people that aren't paying them to talk >> to lots of other people that aren't paying them. I just don't see that >> as being likely to happen. > > I have no idea what you are talking about. This sounds like > you are taking the position of the big five networks circa 1994 > who were trying to prevent their customers from selling connectivity > to downstream ISPs. The market has worked out this problem. > We have lots of paths with greater than 2 ASNs in them. > Geographic addressing doesn't change this in any way. However, it's very hard to point to any of those paths in today's world and identify three consecutive ASNs with unique owners where money doesn't change hands in at least one of those connections. Your proposal would either break connectivity, or, require a substantial change to this fact. 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 cscott at gaslightmedia.com Wed Dec 8 13:17:50 2004 From: cscott at gaslightmedia.com (Charles Scott) Date: Wed, 8 Dec 2004 13:17:50 -0500 (EST) Subject: [ppml] Provider Independence??? In-Reply-To: Message-ID: Michael: Working through this, I guess this means that there needs to be "exchange points" everywhere, even in rural areas. If not, then the policy needs to account for the "closest exchange point", and in cases where providers don't, or can't, agree to exchange traffic, then the closest common point would have to aggrigate the the announcement. But where might that be? In an otherwise amorphous network, that will be difficult to define. Also, how then do you propose to handle situtations where there is a great disparity in backbone bandwidth between providers. Unless the route costs are announced differently for each providers customers the least well connected provider will choke, and doing so breaks the model. Just don't see how this works unless there's some V6 magic that can solve this. Chuck On Wed, 8 Dec 2004 Michael.Dillon at radianz.com wrote: > So the business case is clear, as it was back in the > early 90's. Everybody needs to carry competitor's > traffic in order to create the "network effect" which > makes the network valuable to customers. And any > imbalances are worked out in peering and transit agreements. > > In fact, I think the real leaders in this will > not be the ISPs but the exchange points, especially > the larger operations like Equinix. If geo addressing > is accepted in v6, then this allows for the v6 network > to be built as a network of exchange points. I believe > that this will provide better resiliency and seperacy > than v6 networks and that, in the end, will drive the > mass migration to v6 networks. > > --Michael Dillon From marcelo at it.uc3m.es Wed Dec 8 13:40:23 2004 From: marcelo at it.uc3m.es (marcelo bagnulo braun) Date: Wed, 8 Dec 2004 19:40:23 +0100 Subject: [ppml] Proposed Policy: PI assignments for V6 In-Reply-To: <20041208144324.GC8738@nokia.com> References: <81464318-47BA-11D9-97A6-000D93ACD0FE@it> <2147483647.1102335801@imac-en0.delong.sj.ca.us> <9D4297F2-483D-11D9-97A6-000D93ACD0FE@it.uc3m.es> <2147483647.1102413506@imac-en0.delong.sj.ca.us> <20041208144324.GC8738@nokia.com> Message-ID: <9EF2431C-4948-11D9-9194-000D93ACD0FE@it.uc3m.es> El 08/12/2004, a las 15:43, David Kessens escribi?: > > Marcelo, > > On Wed, Dec 08, 2004 at 03:17:35PM +0100, marcelo bagnulo braun wrote: >> >> well, reading RFC 3177 recommends to assign: >> >> - /128 when it is absolutely known that one and only one device >> is connecting. >> >> i guess that most current mobile phones would fit in this category >> (yes >> i am familiar with manets and so on but i guess that most cell phones >> only connect one device) > > You are describing why mobiles don't fit in the /128 category: > it is certainly not absolutely known that only one device is > connecting. > so, i guess that the right thing to do would be to assign a /48 to each mobile phone, right? since RFC 3177 states that: - /48 in the general case, except for very large subscribers. - /64 when it is known that one and only one subnet is needed by design. - /128 when it is absolutely known that one and only one device is connecting. and since we cannot be sure that a mobile phone will have a single subnetwork behind, i guess that the /48 would be the proper choice I am sorry but i think this is a huge waste. For the time being, most of mobile phones will not have a manet behind, not one not many subnetworks. I think there must be something very wrong if we assign a /48 to each mobile phone regards, marcelo >>> I agree that the 200 limit is not optimal. However, I have not heard >>> of a single mobile provider who could not get the ipv6 addresses that >>> they needed. >> >> Agree, but i guess that the point is that policy should be crisp and >> clear and should express the reality >> But this is a different discussion, imho, and i guess this is a more >> local discussion. >> My concern with this PI initiative is that i see more of a global >> issue > > I agree that there is issues with the current policy for various > categories of address space users but I don't see the problem for > mobile providers. They clearly qualify and the registries agree > considering the allocations that have been done so far. > > David Kessens > --- > From marcelo at it.uc3m.es Wed Dec 8 13:34:42 2004 From: marcelo at it.uc3m.es (marcelo bagnulo braun) Date: Wed, 8 Dec 2004 19:34:42 +0100 Subject: [ppml] Provider Independence??? In-Reply-To: References: Message-ID: El 08/12/2004, a las 16:12, Michael.Dillon at radianz.com escribi?: >> At the end of the day, this means that >> ISPA will be carrying traffic for some of the customers of ISPB, which >> i guess lacks of a business case. > > Please remember that we are talking about IPv6 here > not IPv4. In other words we are talking about a network > which does not currently exist. :-) > There is no reason why > it has to be deployed identically to v4 with just a > different layer 3 protocol. It will likely be different > in many ways, depending on what applications it is > built to support. > > I can envision ISPA operating in 3 regions with > 4 ASNs, 1 for each region and one for their non-geographic > network. They would only announce the geo aggregate for > region 1 using their region 1 AS. This means that they > will only be carrying some of ISPBs traffic if that traffic > is destined to region 1. agree > Since both ISPs operate in region 1 > they will have some sort of peering agreement at region 1 > exchange points. i agree to assume this for the sake of this discussion (in real life i guess that there is nothing imposing this, so this may not be the case and the aggregation would break (which is the other problem of geo addressing (topology may not match geography, hence hindering aggregation), but let's focus on one problem at the time, especially because imho the problem with the business case is more relevant. > Otherwise the traffic would never get to > it's destination in ISPB's network and ISPA would also > lose traffic that comes in on ISPB's regional links. > > So the business case is clear, as it was back in the > early 90's. Everybody needs to carry competitor's > traffic in order to create the "network effect" which > makes the network valuable to customers. And any > imbalances are worked out in peering and transit agreements. > but what happens if a ISP don't want to accept the peering conditions of the other ISPs in the region, what happens then? i don't know, but i would like to hear some feedback about this business case from some isps, just to see if this make sense to them. regards, marcelo > In fact, I think the real leaders in this will > not be the ISPs but the exchange points, especially > the larger operations like Equinix. If geo addressing > is accepted in v6, then this allows for the v6 network > to be built as a network of exchange points. I believe > that this will provide better resiliency and seperacy > than v6 networks and that, in the end, will drive the > mass migration to v6 networks. > > --Michael Dillon > > > From randy at psg.com Wed Dec 8 13:55:31 2004 From: randy at psg.com (Randy Bush) Date: Wed, 8 Dec 2004 10:55:31 -0800 Subject: [ppml] Provider Independence??? References: Message-ID: <16823.20003.73136.218327@ran.psg.com> the geographic allocation of address space is so completely ops-clueless and brain-dead that discussing it at all is a red herring to getting useful work done. randy From stephen at sprunk.org Wed Dec 8 14:09:15 2004 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 8 Dec 2004 13:09:15 -0600 Subject: [ppml] Proposed Policy: PI assignments for V6 References: <81464318-47BA-11D9-97A6-000D93ACD0FE@it> <2147483647.1102335801@imac-en0.delong.sj.ca.us> <9D4297F2-483D-11D9-97A6-000D93ACD0FE@it.uc3m.es> <2147483647.1102413506@imac-en0.delong.sj.ca.us> <20041208144324.GC8738@nokia.com> <9EF2431C-4948-11D9-9194-000D93ACD0FE@it.uc3m.es> Message-ID: <00e901c4dd59$9125fbf0$6801a8c0@stephen> Thus spake "marcelo bagnulo braun" > so, i guess that the right thing to do would be to assign a /48 to each > mobile phone, right? > > since RFC 3177 states that: > - /48 in the general case, except for very large subscribers. > - /64 when it is known that one and only one subnet is needed by > design. > - /128 when it is absolutely known that one and only one device > is connecting. > > and since we cannot be sure that a mobile phone will have a single > subnetwork behind, i guess that the /48 would be the proper choice > > I am sorry but i think this is a huge waste. > For the time being, most of mobile phones will not have a manet behind, > not one not many subnetworks. I think there must be something very wrong > if we assign a /48 to each mobile phone Do mobile phones even count as an "assignment"? i.e. will ISPs be assigning a static prefix to each customer, regardless of location, and putting SWIP info in WHOIS? I admit I'm not familiar with what the telcos are planning, but this seems ridiculous. I would expect each cell tower (or whatever the logical unit is) to be assigned a /64, and phones would be individual hosts with addresses provided by DHCP or autoconfiguration. If a phone allowed hosts behind it, they could be bridged into that same subnet. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From gih at apnic.net Wed Dec 8 14:49:15 2004 From: gih at apnic.net (Geoff Huston) Date: Thu, 09 Dec 2004 06:49:15 +1100 Subject: [ppml] Proposed Policy: PI assignments for V6 In-Reply-To: <00e901c4dd59$9125fbf0$6801a8c0@stephen> References: <81464318-47BA-11D9-97A6-000D93ACD0FE@it> <2147483647.1102335801@imac-en0.delong.sj.ca.us> <9D4297F2-483D-11D9-97A6-000D93ACD0FE@it.uc3m.es> <2147483647.1102413506@imac-en0.delong.sj.ca.us> <20041208144324.GC8738@nokia.com> <9EF2431C-4948-11D9-9194-000D93ACD0FE@it.uc3m.es> <00e901c4dd59$9125fbf0$6801a8c0@stephen> Message-ID: <6.0.1.1.2.20041209063828.022d96f0@kahuna.telstra.net> >>I am sorry but i think this is a huge waste. >>For the time being, most of mobile phones will not have a manet behind, >>not one not many subnetworks. I think there must be something very wrong >>if we assign a /48 to each mobile phone > >Do mobile phones even count as an "assignment"? Would personal LANs such as Bluetooth alter this perspective in any way? The challenge here is to craft policies that look forward and attempt to anticipate some of the more obvious near term technologies. Its also worth bearing in mind the larger picture of the total address space - even if there was to be a /48 for each mobile handset, what's the total address consumption. 1 billion handsets is 30 bits. Allowing for an HD ration of 0.8 there is a further 8 bits - i.e. this is a /10, or 1/1000th of the total address space. Of course this arithmetic allows 16 bits for a personal lAN. Maybe its worth considering a slightly smaller subnet size - an 8 bit subnet would imply that the total consumption would be a /18, for the entire deployment across 1 billion such devices . So perhaps a /56 per customer allocation in such context may represent a possible balance between total consumption and recognition of this emerging personal lan technology. Its worth considering in any case. regards, Geoff Huston From gih at apnic.net Wed Dec 8 15:00:41 2004 From: gih at apnic.net (Geoff Huston) Date: Thu, 09 Dec 2004 07:00:41 +1100 Subject: [ppml] Provider Independence??? In-Reply-To: <16823.20003.73136.218327@ran.psg.com> References: <16823.20003.73136.218327@ran.psg.com> Message-ID: <6.0.1.1.2.20041209065129.023bfec0@kahuna.telstra.net> At 05:55 AM 9/12/2004, Randy Bush wrote: >the geographic allocation of address space is so completely >ops-clueless and brain-dead that discussing it at all is >a red herring to getting useful work done. Unfortunately others appear to have latched onto this as the foundation of a 'competitive' approach to address distribution mechanism (see the ITU paper at http://www.itu.int/ITU-T/tsb-director/itut-wsis/files/zhao-netgov02.doc (yes, its a word file)). I wonder if there is anyone interested in working with me off this list in writing done the issues behind geo-addressing? While Randy's observations are ones I can certainly agree with, I suspect that there is some further work to do here in generating documentation refuting proposals that, on the whole, attempt to borrow from telephone geo-addressing schemes and then cast it onto the Internet. Geoff From gih at apnic.net Wed Dec 8 16:24:26 2004 From: gih at apnic.net (Geoff Huston) Date: Thu, 09 Dec 2004 08:24:26 +1100 Subject: [ppml] Provider Independence??? In-Reply-To: <33E15679-4923-11D9-9194-000D93ACD0FE@it> References: <33E15679-4923-11D9-9194-000D93ACD0FE@it> Message-ID: <6.0.1.1.2.20041209081700.0227eec0@kahuna.telstra.net> Marcelo, Yes, "no money, no transit" is the business rule used by most financially solvent ISPs out there today. Other models have been tried in the past. I guess that most of the folk that did bet their business on other models are no longer with us today. So, as a logical extension of your comment, it appears that in order to get geo addressing to work in a routing-efficient manner the consequent task is to grapple with the topic of inter-provider financial settlements for IP transit. I think at that stage we are well off the core topic of this mailing list, so I'll take Randy's advice and make any further comment from me off list. Geoff At 01:12 AM 9/12/2004, marcelo bagnulo braun wrote: >Hi Michael, > >I guess that the problem that Owen is pointing out is that when there are >multiple ISP providing service to users within the same geographical >region, all these providers will have to announce the aggregate address >block that corresponds to the complete region. Since all the isps are >announcing the whole geo block, this means that they will receive packets >for all the users within the region, some of which won't be their direct >costumers. At the end of the day, this means that ISPA will be carrying >traffic for some of the customers of ISPB, which i guess lacks of a >business case. > >Regards, marcelo From stephen at sprunk.org Wed Dec 8 17:51:07 2004 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 8 Dec 2004 16:51:07 -0600 Subject: [ppml] Provider Independence??? References: Message-ID: <028b01c4dd79$869a7fb0$6801a8c0@stephen> Thus spake > I have no idea what you are talking about. This sounds like > you are taking the position of the big five networks circa 1994 > who were trying to prevent their customers from selling connectivity > to downstream ISPs. The market has worked out this problem. > We have lots of paths with greater than 2 ASNs in them. > Geographic addressing doesn't change this in any way. As tempting as it is to continue discussing how a geographic addressing plan would work in practice, it is clear that the current Internet topology and transit/peering model do not support such a plan at this time and it would take years (and probably regulatory pressure) to make it happen. In that light, it appears necessary to provide PI prefixes in the immediate future, and we should be debating the current proposal in comparison to the proposed alternatives (none) and to doing nothing. If/when a viable alternative is developed, ARIN can modify or repeal the PI policy based on community discussion. Unlike v4 swamp assignments, ARIN also has clear authority to reclaim _all_ v6 assignments if necessary. Today, there are about 16k origin-only ASes; that is the number of new IPv6 routes that one would expect this policy to generate and is clearly within the capabilities of today's hardware. If demand is significantly stronger than expected, the community can revisit whether it is necessary to modify or repeal the policy to address operational concerns even if no viable alternative has presented itself yet. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From stephen at sprunk.org Wed Dec 8 19:15:23 2004 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 8 Dec 2004 18:15:23 -0600 Subject: [ppml] Proposed Policy: PI assignments for V6 References: <81464318-47BA-11D9-97A6-000D93ACD0FE@it> <2147483647.1102335801@imac-en0.delong.sj.ca.us> <9D4297F2-483D-11D9-97A6-000D93ACD0FE@it.uc3m.es> <2147483647.1102413506@imac-en0.delong.sj.ca.us> Message-ID: <03b001c4dd87$ce53ac10$6801a8c0@stephen> Thus spake "Kurt Erik Lindqvist" > On 2004-12-07, at 18.58, Owen DeLong wrote: >> Good... At least we agree on part of this. Multihoming is an important >> part of provider independence in my opinion. Afterall, the only way to >> make a painless transition from one ISP to another is to be connected to >> both of them for some period of time. > > I am not sure I buy this that easily. Are you saying that the only way to > do ISP transition is with PI addresses and being connected to both ISPs at > the same time? No, but having PI space makes the process less painful. Only the border routers need to be updated, and it can be done as quickly as BGP convergence can be completed (twice). A PA site would add a second PA prefix to all of their routers/hosts, wait a few days, switch all the addresses in DNS, wait another few days, then remove the first PA prefix. This kills any active connections during the last step, but that's arguably minor. Depending on the number of routers/hosts, this does require extensive effort on the admins' part. > Do we? How much of these problems are really just covered up with NAT? And > how many enterprises that you argue would like your PI+multihoming > capability would much rather that their NAT boxes worked with v6 so they > didn't have to learn about that comples routing stuff? It's not the "comples [sic] routing stuff" that sites are avoiding -- it's the renumbering of routers/hosts. Some also consider NAT to be a security feature because individual hosts or general topology can't be determined if there's a single IP visible externally; there is a strong belief that security by obscurity is necessary even if the people involved _know_ that it doesn't provide real security. > Marcelo already pointed this out but I think you really ought to catch up > with the work in multi6. Consensus is that multi6's proposals are not viable today nor will they be in the near future. The possibility of progress a decade from now should not hold up people trying to deploy real networks today. >> Right... The v4 swamp was assigned before CIDR. The v4 swamp also has >> absolutely no right of reclamation or annual renewal. Addresses issued >> prior to the RIR system CAN NOT be taken away from the people that have >> them. Those people do not pay annual fees for them. That is a very >> different case from what would happen under this policy with v6. > > I have no problem with the v4 swamp that is not advertised and no longer > in use. I have a problem with the v4 swamp that IS advertised and IS being > used.... This is also a considerable portion of the v4 swamp that is being used but not advertised globally. However, none of that is relevant to the proposal at hand, since ARIN can revoke or reclaim any IPv6 assignments in the future if necessary. >>> However, from the community p.o.v. this is the only solution in the log >>> run. So how do solve this problem? >> >> Again, you attempt to define the community only in terms of providers. >> WRONG!!! The community includes the end sites too. >> >> I don't think your proposed solution is better for the community or for >> any of the individuals it claims to serve. I think it is an inferior >> solution that does not provide important elements that are available >> with PI space. It's only better for the ISPs. > > I think PI for v6 is fine coupled with smd's old suggestion of transit > providers charging per announced prefix. That is AFAIk the only model with > give away PI that works. And PI+ASN = give away PI today. That model is infeasible today for a variety of human and technical reasons. > That said. There are a few things I think is being forgotten in this > discussion, and I really, really didn't want to point this out, but I > guess I have to. PI space have the property that you can take it with you > when you change providers, and really only solves renumbering. It does not > give you anything wrt provider independence you do not already have. Why? > Because you can today already either get multiple PAs, which won't help > the problem with surviving TCP flows, but honestly, PI won't help you with > that either. Please explain how connections using PI addresses do not survive when a site's link to the respective provider goes down, either intentionally or otherwise. > The multiple PAs help with migration. So, why else do you want PA space, > redundancy? Sure, as an end-site you will today get a /48. There is > nothing in the world to prevent you from advertising your /48 to several > upstreams, except filtering by the upstreams. Will PI space help you > there? Not if the PI space is /48.... If there is a PI block with a minimum assignment/allocation of /48, then presumably providers will relax their filters for that block. This has been the case when RIRs have changed allocation policies for IPv4. There is strong historical record to show that most will NOT accept a route longer than the minimum allocation size in a particular block. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From Michael.Dillon at radianz.com Thu Dec 9 10:15:20 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 9 Dec 2004 15:15:20 +0000 Subject: [ppml] Provider Independence??? In-Reply-To: Message-ID: > but what happens if a ISP don't want to accept the peering conditions > of the other ISPs in the region, what happens then? Then they don't use geo addresses. Instead they use the existing non-geo v6 addresses. The idea of geo addressing is all about creating choices that can be use to solve the PI addressing problem for the majority of end networks. It is not necessary for every ISP to offer geo addressing services for this to work. It really comes down to business demand in each individual area. Maybe businesses in Sacramento will demand geo addressing services because PI is important to them, but businesses in San Francisco don't care about PI and don't use geo addressing. I'm just saying that it is the responsibility of the RIRs and the IETF to provide the possibility of geo addressing so that those end networks who want to buy PI-supporting connectivity can find ISPs who offer it. At this point in time, it seems that the IPv6 Internet will be the one single network interconnecting everything on the planet, public and private, by the end of the 21st century. We cannot architect this in the same way as IPv4. We need to offer more flexibility. --Michael Dillon From rdasilva at va.rr.com Thu Dec 9 10:23:39 2004 From: rdasilva at va.rr.com (da Silva, Ron) Date: Thu, 9 Dec 2004 10:23:39 -0500 Subject: [ppml] Proposed Policy: PI assignments for V6 Message-ID: <5D200A6BB92BB54F8E2FED8E4A28D7630177B940@RRMAILER.rr.com> > so, i guess that the right thing to do would be to assign a /48 to each > mobile phone, right? > > since RFC 3177 states that: > - /48 in the general case, except for very large subscribers. > - /64 when it is known that one and only one subnet is needed by > design. > - /128 when it is absolutely known that one and only one device > is connecting. > > and since we cannot be sure that a mobile phone will have a single > subnetwork behind, i guess that the /48 would be the proper choice > > I am sorry but i think this is a huge waste. > For the time being, most of mobile phones will not have a manet behind, > not one not many subnetworks. I think there must be something very > wrong if we assign a /48 to each mobile phone >From a wireline connectivity perspective, the /48 would be assigned to the provider gateway (e.g. DSL/Cable router). Any subnets downstream of that connection would be allocated from the /48 pool. If there was a device within the home (say a multi-modal handset with 802.11x, GSM and bluetooth) that needed a prefix (or two) for additional subnetting then there should be a mechanism to allocate multiple /64's to that device from the /48. For consistency, can someone extend that concept to a GSM/CDMA connectivity model? Where is the /48 assigned? Presumably, whatever gateway device is being employed for assigning IPv6 addresses to handsets would be assigned the /48 and then any further delegation would be accomplished with downstream /64 assignments. Anyone have any URL's that detail current IPv4/IPv6 addressing plans for GSM/CDMA architectures? -ron From randy at psg.com Thu Dec 9 10:38:29 2004 From: randy at psg.com (Randy Bush) Date: Thu, 9 Dec 2004 07:38:29 -0800 Subject: [ppml] Provider Independence??? References: <16823.20003.73136.218327@ran.psg.com> <6.0.1.1.2.20041209065129.023bfec0@kahuna.telstra.net> Message-ID: <16824.29045.942047.128246@ran.psg.com> >> the geographic allocation of address space is so completely >> ops-clueless and brain-dead that discussing it at all is >> a red herring to getting useful work done. > > Unfortunately others appear to have latched onto this as the foundation of > a 'competitive' approach to address distribution mechanism (see the ITU > paper at > http://www.itu.int/ITU-T/tsb-director/itut-wsis/files/zhao-netgov02.doc > (yes, its a word file)). in the name of the digital divide. brought to you by the folk who brought you the analog divide and help maintain it today. rahdy From marcelo at it.uc3m.es Thu Dec 9 10:42:03 2004 From: marcelo at it.uc3m.es (marcelo bagnulo braun) Date: Thu, 9 Dec 2004 16:42:03 +0100 Subject: [ppml] Proposed Policy: PI assignments for V6 In-Reply-To: <03b001c4dd87$ce53ac10$6801a8c0@stephen> References: <81464318-47BA-11D9-97A6-000D93ACD0FE@it> <2147483647.1102335801@imac-en0.delong.sj.ca.us> <9D4297F2-483D-11D9-97A6-000D93ACD0FE@it.uc3m.es> <2147483647.1102413506@imac-en0.delong.sj.ca.us> <03b001c4dd87$ce53ac10$6801a8c0@stephen> Message-ID: Hi Stephen, just a comment... El 09/12/2004, a las 1:15, Stephen Sprunk escribi?: >> That said. There are a few things I think is being forgotten in this >> discussion, and I really, really didn't want to point this out, but I >> guess I have to. PI space have the property that you can take it with >> you when you change providers, and really only solves renumbering. It >> does not give you anything wrt provider independence you do not >> already have. Why? Because you can today already either get multiple >> PAs, which won't help the problem with surviving TCP flows, but >> honestly, PI won't help you with that either. > > Please explain how connections using PI addresses do not survive when > a site's link to the respective provider goes down, either > intentionally or otherwise. > i don't know what Kurtis had in mind when he made this comments, if you pretend to obtain tcp connection survivability with current size of the bgp global routing table, you will find the probelms described in C. Labovitz, A. Ahuja, A. Bose, ?Delayed Internet Routing Convergence?, 2000, SIGCOMM 2000. in addition you probably have to deal with default BGP keepalive timer which in widely deployed commercial routers is 180 seconds. This means that some failures modes that are only detected through bgp keepalives, it will take 3 minutes to detect the failre which is probably longer that most apps using tcp connections are willing to wait. So the question is how much of this feature of established connection preservation through BGP reconvergence is actually a myth (in ipv4)... (clearly for now in ipv6 i guess we don't have delayed reconvergence, for now) regards, marcelo >> The multiple PAs help with migration. So, why else do you want PA >> space, redundancy? Sure, as an end-site you will today get a /48. >> There is nothing in the world to prevent you from advertising your >> /48 to several upstreams, except filtering by the upstreams. Will PI >> space help you there? Not if the PI space is /48.... > > If there is a PI block with a minimum assignment/allocation of /48, > then presumably providers will relax their filters for that block. > This has been the case when RIRs have changed allocation policies for > IPv4. There is strong historical record to show that most will NOT > accept a route longer than the minimum allocation size in a particular > block. > > S > > Stephen Sprunk "God does not play dice." --Albert Einstein > CCIE #3723 "God is an inveterate gambler, and He throws the > K5SSS dice at every possible opportunity." --Stephen Hawking From marcelo at it.uc3m.es Thu Dec 9 10:57:35 2004 From: marcelo at it.uc3m.es (marcelo bagnulo braun) Date: Thu, 9 Dec 2004 16:57:35 +0100 Subject: [ppml] Proposed Policy: PI assignments for V6 In-Reply-To: <5D200A6BB92BB54F8E2FED8E4A28D7630177B940@RRMAILER.rr.com> References: <5D200A6BB92BB54F8E2FED8E4A28D7630177B940@RRMAILER.rr.com> Message-ID: <0B55D090-49FB-11D9-9194-000D93ACD0FE@it> Hi Ron, That makes more sense to me, but the question is how is this considered when applying for address space on a rir? if a mobile operator claims that he needs a /48 for each handset, does he get the address space requested? regards, marcelo El 09/12/2004, a las 16:23, da Silva, Ron escribi?: >> so, i guess that the right thing to do would be to assign a /48 to > each >> mobile phone, right? >> >> since RFC 3177 states that: >> - /48 in the general case, except for very large subscribers. >> - /64 when it is known that one and only one subnet is needed > by >> design. >> - /128 when it is absolutely known that one and only one > device >> is connecting. >> >> and since we cannot be sure that a mobile phone will have a single >> subnetwork behind, i guess that the /48 would be the proper choice >> >> I am sorry but i think this is a huge waste. >> For the time being, most of mobile phones will not have a manet > behind, >> not one not many subnetworks. I think there must be something very >> wrong if we assign a /48 to each mobile phone > > From a wireline connectivity perspective, the /48 would be assigned to > the provider gateway (e.g. DSL/Cable router). Any subnets downstream > of > that connection would be allocated from the /48 pool. If there was a > device within the home (say a multi-modal handset with 802.11x, GSM and > bluetooth) that needed a prefix (or two) for additional subnetting then > there should be a mechanism to allocate multiple /64's to that device > from the /48. > > For consistency, can someone extend that concept to a GSM/CDMA > connectivity model? Where is the /48 assigned? Presumably, whatever > gateway device is being employed for assigning IPv6 addresses to > handsets would be assigned the /48 and then any further delegation > would > be accomplished with downstream /64 assignments. > > Anyone have any URL's that detail current IPv4/IPv6 addressing plans > for > GSM/CDMA architectures? > > -ron > From kurtis at kurtis.pp.se Thu Dec 9 10:54:02 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 9 Dec 2004 16:54:02 +0100 Subject: [ppml] Provider Independence??? In-Reply-To: References: Message-ID: <8C468CA1-49FA-11D9-8D27-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-12-08, at 16.12, Michael.Dillon at radianz.com wrote: > So the business case is clear, as it was back in the > early 90's. Everybody needs to carry competitor's > traffic in order to create the "network effect" which > makes the network valuable to customers. And any > imbalances are worked out in peering and transit agreements. > > In fact, I think the real leaders in this will > not be the ISPs but the exchange points, especially > the larger operations like Equinix. If geo addressing > is accepted in v6, then this allows for the v6 network > to be built as a network of exchange points. I believe > that this will provide better resiliency and seperacy > than v6 networks and that, in the end, will drive the > mass migration to v6 networks. I fail to see where anyone would make money in this model. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQbh1IaarNKXTPFCVEQIDowCguZW9oZn4azuQ7odd5tmvwZEij1IAoK5c 85rpMcumhWu6eh4BB3HrZTf+ =AVGY -----END PGP SIGNATURE----- From marcelo at it.uc3m.es Thu Dec 9 11:05:15 2004 From: marcelo at it.uc3m.es (marcelo bagnulo braun) Date: Thu, 9 Dec 2004 17:05:15 +0100 Subject: [ppml] Provider Independence??? In-Reply-To: References: Message-ID: <1D323615-49FC-11D9-9194-000D93ACD0FE@it> [i don't know if this discussion is off topic for this list, so if it is, i would appreciate that a chair or someone similar let me know so i can shut up (i know Randy's opinion, and it would be probably wiser to follow his advice, but anyway...)] El 09/12/2004, a las 16:15, Michael.Dillon at radianz.com escribi?: >> but what happens if a ISP don't want to accept the peering conditions >> of the other ISPs in the region, what happens then? > > Then they don't use geo addresses. i am really not following... what do you mean? do you mean that they are not allowed to get geo addresses? How would that work? in the geo address block application the requesting ISP will have to agree that he is willing to peer and accept the peering agreements with all the ISPs that are currently providing service in the region? And who is the first operator that gets PI addresses? i mean this is important since all the other will only have two choices: or they do peering with this first operator or they don't get geo addresses, right? i don't think this is the way internet works, moreover, i don't think this the way we want the internet to work regards, marcelo > Instead they use the > existing non-geo v6 addresses. The idea of geo addressing > is all about creating choices that can be use to solve > the PI addressing problem for the majority of end > networks. It is not necessary for every ISP to offer > geo addressing services for this to work. It really > comes down to business demand in each individual area. > Maybe businesses in Sacramento will demand geo addressing > services because PI is important to them, but businesses > in San Francisco don't care about PI and don't use geo > addressing. > > I'm just saying that it is the responsibility of > the RIRs and the IETF to provide the possibility > of geo addressing so that those end networks who > want to buy PI-supporting connectivity can find > ISPs who offer it. > > At this point in time, it seems that the IPv6 > Internet will be the one single network interconnecting > everything on the planet, public and private, > by the end of the 21st century. We cannot architect > this in the same way as IPv4. We need to offer more > flexibility. > > --Michael Dillon > From rdasilva at va.rr.com Thu Dec 9 11:10:24 2004 From: rdasilva at va.rr.com (da Silva, Ron) Date: Thu, 9 Dec 2004 11:10:24 -0500 Subject: [ppml] Proposed Policy: PI assignments for V6 Message-ID: <5D200A6BB92BB54F8E2FED8E4A28D763020FB36A@RRMAILER.rr.com> > That makes more sense to me, but the question is how is this considered > when applying for address space on a rir? if a mobile operator claims > that he needs a /48 for each handset, does he get the address space > requested? I don't think I was advocating a /48 for each handset. What entity on the mobile network does the address allocation? That component could be assigned the /48 and then in turn the handset is assigned a) /128 from a /64 segment on the assigning device b) /64 subnet from the /48 block or c) multiple /64's from the /48 block from the assigning device. -ron From marcelo at it.uc3m.es Thu Dec 9 11:17:49 2004 From: marcelo at it.uc3m.es (marcelo bagnulo braun) Date: Thu, 9 Dec 2004 17:17:49 +0100 Subject: [ppml] Proposed Policy: PI assignments for V6 In-Reply-To: <5D200A6BB92BB54F8E2FED8E4A28D763020FB36A@RRMAILER.rr.com> References: <5D200A6BB92BB54F8E2FED8E4A28D763020FB36A@RRMAILER.rr.com> Message-ID: El 09/12/2004, a las 17:10, da Silva, Ron escribi?: >> That makes more sense to me, but the question is how is this > considered >> when applying for address space on a rir? if a mobile operator claims >> that he needs a /48 for each handset, does he get the address space >> requested? > > I don't think I was advocating a /48 for each handset. I didn't thought you were... sorry for the misunderstanding. My comment was: i agree with you p.o.v. and what if a mobile operator is trying to assign a /48 to each handset? how does the rirs evaluate such request? is is acceptable and he will get the address space that he needs to assign a /48 to each handset? is this out of the scope of a policy? regards, marcelo > What entity on > the mobile network does the address allocation? That component could > be > assigned the /48 and then in turn the handset is assigned a) /128 from > a > /64 segment on the assigning device b) /64 subnet from the /48 block or > c) multiple /64's from the /48 block from the assigning device. > > -ron > From rdasilva at va.rr.com Thu Dec 9 11:47:06 2004 From: rdasilva at va.rr.com (da Silva, Ron) Date: Thu, 9 Dec 2004 11:47:06 -0500 Subject: [ppml] Proposed Policy: PI assignments for V6 Message-ID: <5D200A6BB92BB54F8E2FED8E4A28D7630177B941@RRMAILER.rr.com> > I didn't thought you were... sorry for the misunderstanding. > My comment was: i agree with you p.o.v. and what if a mobile operator > is trying to assign a /48 to each handset? how does the rirs evaluate > such request? is is acceptable and he will get the address space that > he needs to assign a /48 to each handset? is this out of the scope of > a policy? That would be in scope for RIR policy or an RFC. Presently, I don't think the guidance in either RIR policy or RFC's supports this though. Arguably though, considering 3G (EV-DV, UMTS, MIMO) developments in mobile, perhaps some GSM/CDMA/iDEN device might be considered as a "home" gateway and thus would follow the /48 assignment guidance from the IETF. That distinction hasn't been fully vetted in the community as far as I know. -ron From Michael.Dillon at radianz.com Thu Dec 9 12:09:04 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 9 Dec 2004 17:09:04 +0000 Subject: [ppml] Provider Independence??? In-Reply-To: <16824.29045.942047.128246@ran.psg.com> Message-ID: > > http://www.itu.int/ITU-T/tsb-director/itut-wsis/files/zhao-netgov02.doc > > (yes, its a word file)). > > in the name of the digital divide. brought to you by the folk > who brought you the analog divide and help maintain it today. Thank you for your succint, uninformed knee-jerk opinion. Those who have read the ITU document will know that it is not proposing any form of geographic addressing. It is suggesting that some IPv6 addresses should be allocated according to national political boundaries. On the other hand, I am suggesting that the geographic addresses allowed for in the IPv6 RFCs should be allocated in a way that ignores political boundaries but does take into account the physical topology of network connections. Disagree with this if you will, but please do not mix it up with unrelated activities. --Michael Dillon From Michael.Dillon at radianz.com Thu Dec 9 12:32:10 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 9 Dec 2004 17:32:10 +0000 Subject: [ppml] Provider Independence??? In-Reply-To: <1D323615-49FC-11D9-9194-000D93ACD0FE@it> Message-ID: > >> but what happens if a ISP don't want to accept the peering conditions > >> of the other ISPs in the region, what happens then? > > > > Then they don't use geo addresses. > > i am really not following... Geo addresses are just ordinary IPv6 addresses that work the same as any other IPv6 addresses. They differ from the current IPv6 addresses in only two ways. One is that they come from a well-known prefix so that anyone who chooses to can apply different policies to these addresses. The other difference is that the RIRs allocate these addresses according to a geographical hierarchy and pass on the requirement to XPs to maintain this geographical hierarchy. This means that the allocation to an endpoint does not come from their provider. It is provider independent. Instead, the allocation comes from the local exchange point operator. At this point, these addresses are usable through any provider connected to the XP and the routing announcements for these addresses can be aggregated globally to a very small number of entries in the so-called global routing table. This doesn't prevent anyone from continuing to use provider allocated IPv6 addresses in the same way that they are used in the v4 Internet. The ITU can make credible arguments that the existing random allocation of IPv4 addresses will not scale in IPv6 and therefore an alternative is needed. If the Internet community does not provide some type of geographic addressing that as an alternative to the ITU's proposal, then the ITU's position can easily win by default. We can no longer ignore the phone network because in the 21st century, the Internet *IS* the phone network. I disagree with the ITU position. --Michael Dillon From owen at delong.com Thu Dec 9 12:31:18 2004 From: owen at delong.com (Owen DeLong) Date: Thu, 09 Dec 2004 09:31:18 -0800 Subject: [ppml] Provider Independence??? In-Reply-To: References: Message-ID: <2147483647.1102584678@imac-en0.delong.sj.ca.us> Michael, I do not believe that GEO addressing is the only way to solve the PI problem. Claiming that RIRs have a responsibility to provide something that a significant portion of the community doesn't see as viable and then asserting that it is necessary in order to solve a particular problem which appears to have other solutions is, in my opinion, counterproductive. The RIRs responsibility is to allocate and assign numbering resources in their region according to the policies determined by the consensus of their constituency as judged by the advisory council and the board of trustees elected by the membership. I have not seen anything approaching consensus around geo-based addressing. As such, I don't think the RIRs have a responsibility to provide it. I do think that the community has an obligation to try and address the needs for PI space. I think there is consensus around that. I think that the task now is to build consensus around the best way to achieve that. I have offered one concrete policy proposal, which, I believe is a better solution than geo-based addressing for the time being. I think that there are too many changes required (economic, topologic, behavioral, and perceptual) before geo-based addressing can provide any substantive benefit. 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 owen at delong.com Thu Dec 9 12:33:14 2004 From: owen at delong.com (Owen DeLong) Date: Thu, 09 Dec 2004 09:33:14 -0800 Subject: [ppml] Proposed Policy: PI assignments for V6 In-Reply-To: <5D200A6BB92BB54F8E2FED8E4A28D7630177B940@RRMAILER.rr.com> References: <5D200A6BB92BB54F8E2FED8E4A28D7630177B940@RRMAILER.rr.com> Message-ID: <2147483647.1102584794@imac-en0.delong.sj.ca.us> That isn't how I read the RFC. As I read it, if I have a need for multiple subnets in my home, SOHO, business, etc., and I request it, my LIR should issue me a /48, not a batch of /64s. I'm not saying this is good, nor am I saying it is bad, but, as I read the RFC, that is what it says. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Thu Dec 9 12:41:12 2004 From: owen at delong.com (Owen DeLong) Date: Thu, 09 Dec 2004 09:41:12 -0800 Subject: [ppml] Proposed Policy: PI assignments for V6 In-Reply-To: References: <81464318-47BA-11D9-97A6-000D93ACD0FE@it> <2147483647.1102335801@imac-en0.delong.sj.ca.us> <9D4297F2-483D-11D9-97A6-000D93ACD0FE@it.uc3m.es> <2147483647.1102413506@imac-en0.delong.sj.ca.us> <03b001c4dd87$ce53ac10$6801a8c0@stephen> Message-ID: <2147483647.1102585272@imac-en0.delong.sj.ca.us> --On Thursday, December 9, 2004 4:42 PM +0100 marcelo bagnulo braun wrote: > Hi Stephen, > > just a comment... > > El 09/12/2004, a las 1:15, Stephen Sprunk escribi?: >>> That said. There are a few things I think is being forgotten in this >>> discussion, and I really, really didn't want to point this out, but I >>> guess I have to. PI space have the property that you can take it with >>> you when you change providers, and really only solves renumbering. It >>> does not give you anything wrt provider independence you do not >>> already have. Why? Because you can today already either get multiple >>> PAs, which won't help the problem with surviving TCP flows, but >>> honestly, PI won't help you with that either. >> >> Please explain how connections using PI addresses do not survive when >> a site's link to the respective provider goes down, either >> intentionally or otherwise. >> > > i don't know what Kurtis had in mind when he made this comments, if you > pretend to obtain tcp connection survivability with current size of the > bgp global routing table, you will find the problems described in C. > Labovitz, A. Ahuja, A. Bose, ?Delayed Internet Routing Convergence?, > 2000, SIGCOMM 2000. > Much of that has been somewhat mitigated with recent advances in router software. Withdrawls now happen quite a bit faster than they did in 2000, and, the fact that table insertions take longer is generally not as harmful as the slow withdrawls used to be. In my experience recently having been running routers at multi-homed end-sites, we saw relatively good TCP session survivability across provider outage events with restoration times in the 15-30 second range and full convergence taking on the order of 2-4 minutes. YMMV, but, those are my recent real world observations. > in addition you probably have to deal with default BGP keepalive timer > which in widely deployed commercial routers is 180 seconds. This means > that some failures modes that are only detected through bgp keepalives, > it will take 3 minutes to detect the failre which is probably longer that > most apps using tcp connections are willing to wait. So the question is > how much of this feature of established connection preservation through > BGP reconvergence is actually a myth (in ipv4)... (clearly for now in > ipv6 i guess we don't have delayed reconvergence, for now) > You only have to deal with default BGP keepalive timers if you don't know how to configure them differently on your router. In most EBGP sessions, I have found that 10 second keepalives with 30 second fallovers do not provide a significant additional load on the routers and provide much faster failover. Additionally, in my recent experience, this particular type of failure is less common than other failure modes. In fact, my recent experience has been that circuit failures are most likely, followed by link-affecting router failures (e.g. the connection drops due to link state detection rather than waiting for BGP timer). Undetected failures that wait for the BGP timer are, in my experience, quite rare except in the instance of multihop sessions. Again, YMMV, but, this has been my experience in this situation within the last 6 months. As such, I'd say it's fact, not myth. 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 david.kessens at nokia.com Thu Dec 9 12:41:33 2004 From: david.kessens at nokia.com (David Kessens) Date: Thu, 9 Dec 2004 09:41:33 -0800 Subject: [ppml] Proposed Policy: PI assignments for V6 In-Reply-To: <5D200A6BB92BB54F8E2FED8E4A28D7630177B940@RRMAILER.rr.com> References: <5D200A6BB92BB54F8E2FED8E4A28D7630177B940@RRMAILER.rr.com> Message-ID: <20041209174133.GE4901@nokia.com> Ron, On Thu, Dec 09, 2004 at 10:23:39AM -0500, da Silva, Ron wrote: > > so, i guess that the right thing to do would be to assign a /48 to > each > > mobile phone, right? > > > > since RFC 3177 states that: > > - /48 in the general case, except for very large subscribers. > > - /64 when it is known that one and only one subnet is needed > by > > design. > > - /128 when it is absolutely known that one and only one > device > > is connecting. > > > > and since we cannot be sure that a mobile phone will have a single > > subnetwork behind, i guess that the /48 would be the proper choice > > > > I am sorry but i think this is a huge waste. > > For the time being, most of mobile phones will not have a manet > behind, > > not one not many subnetworks. I think there must be something very > > wrong if we assign a /48 to each mobile phone > > From a wireline connectivity perspective, the /48 would be assigned to > the provider gateway (e.g. DSL/Cable router). Any subnets downstream of > that connection would be allocated from the /48 pool. If there was a > device within the home (say a multi-modal handset with 802.11x, GSM and > bluetooth) that needed a prefix (or two) for additional subnetting then > there should be a mechanism to allocate multiple /64's to that device > from the /48. > > For consistency, can someone extend that concept to a GSM/CDMA > connectivity model? Where is the /48 assigned? Presumably, whatever > gateway device is being employed for assigning IPv6 addresses to > handsets would be assigned the /48 and then any further delegation would > be accomplished with downstream /64 assignments. Your assumptions are pretty close to what the current thinking is (from a 10 mile view, I don't think it contributes a lot to go into the details here). > Anyone have any URL's that detail current IPv4/IPv6 addressing plans for > GSM/CDMA architectures? I don't have anything available. I am actually trying to get materials on this topic and can post it if I get some (but please be patient - I haven't found anyhting useful yet). On Thu, Dec 09, 2004 at 11:10:24AM -0500, da Silva, Ron wrote: > > That makes more sense to me, but the question is how is this > considered > > when applying for address space on a rir? if a mobile operator > > claims > > that he needs a /48 for each handset, does he get the address > > space > > requested? > > I don't think I was advocating a /48 for each handset. What entity > on > the mobile network does the address allocation? That component > could be > assigned the /48 and then in turn the handset is assigned a) /128 > from a > /64 segment on the assigning device b) /64 subnet from the /48 block > /or > c) multiple /64's from the /48 block from the assigning device. b) & c) is what I have heard about, while /48 might be the way to go if we get real mobile Internet access devices that connect a lot more than a few devices. Note that there are also other mobile systems than the 3GPP case, and that implementations/operational details can vary, so don't take my words as 'all mobiles will work like this'. David Kessens --- From michel at arneill-py.sacramento.ca.us Thu Dec 9 13:11:06 2004 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 9 Dec 2004 10:11:06 -0800 Subject: [ppml] Proposed Policy: PI assignments for V6 Message-ID: > Policy Proposal Name: PI assignments for V6 > Author: Owen DeLong > Policy term: permanent After long consideration and despite the fact that I have previously opposed PI assignments for v6 I decided to support Owen's proposal; the predicted availability of ULAs made me reverse my former position. I still don't like the idea, and this leaves me with the uncomfortable feeling of choosing the lesser of two evils, but I feel it is the right thing to do now. In the past, I have opposed PI assignments on the ground that it would be opening the floodgates. I regret to report that the choice left before us today is not to flood or not to flood anymore, but whether we want a controlled flood or an uncontrolled one. It's only a matter of time before an illegitimate registry such as http://www.wiana.org/ pops up for ULAs. This would have been fine for locally-scoped addresses but not for global addresses, and ULAs are global. I vote to keep control of IPv6 PI assignments within the RIR system. Picking the right fees is going to be tricky. Contrary to popular belief, I don't think that the debate along the lines of a $100/yr maintenance fee vs. a $1,000/yr maintenance fee is relevant. The question is not if an organization that needs a PI prefix can or cannot afford a $1,000/yr fee; we're not talking about doing what's right anymore but about damage control: the name of the game here is to keep the number of small shops that think they need a PI block go the ULA way below critical mass. My personal preference would be a low one-time fee. The fee needs to be low for the reason mentioned above, and I don't think that a yearly maintenance fee is appropriate for the following reason: what happens if an organization stops paying the fee? Unlike v4, there is no incentive to reclaim the block to assign it to someone else (because unlike IPv4 there is no shortage of IPv6 addresses) which means that an IPv6 PI block that has been assigned once will unfortunately become a de-facto lifetime assignment. I fully realize that what I wrote above is basically a support to create the IPv6 swamp. My point here is that we are choosing the lesser of two evils: do we want an uncontrolled swamp formed of ULAs that might not even be registered anywhere (and that don't bring any money to the RIRs) or do we prefer a more controlled swamp? > Owen DeLong wrote: > That isn't how I read the RFC. As I read it, if I have a need > for multiple subnets in my home, SOHO, business, etc., and I > request it, my LIR should issue me a /48, not a batch of /64s. > I'm not saying this is good, nor am I saying it is bad, but, > as I read the RFC, that is what it says. Indeed. We have settled this a long time ago, but some people still want to use /127s on PTP links, likely the same that want to avoid "wasting" a resource that is not constrained. Although a single /64 would likely be fine for most home/SOHO, I do expect the "geek" home to request and get a /48, even if 64k subnets are un-necessary. Allocating a /56 might be less a waste than a /48 but is a futile exercise. Michel. From owen at delong.com Thu Dec 9 13:12:31 2004 From: owen at delong.com (Owen DeLong) Date: Thu, 09 Dec 2004 10:12:31 -0800 Subject: [ppml] Provider Independence??? In-Reply-To: References: Message-ID: <2147483647.1102587151@imac-en0.delong.sj.ca.us> --On Thursday, December 9, 2004 5:09 PM +0000 Michael.Dillon at radianz.com wrote: >> > > http://www.itu.int/ITU-T/tsb-director/itut-wsis/files/zhao-netgov02.doc >> > (yes, its a word file)). >> >> in the name of the digital divide. brought to you by the folk >> who brought you the analog divide and help maintain it today. > > Thank you for your succint, uninformed knee-jerk opinion. > Those who have read the ITU document will know that it is > not proposing any form of geographic addressing. It is suggesting > that some IPv6 addresses should be allocated according to > national political boundaries. > I hate to break it to you, Michael, but, generally, this is effectively a form of geographic addressing. For the most part, national political boundaries are, despite rumors to the contrary, geographic in nature. I didn't see anything in the ITU document that proposed allocating a chunk of addresses to the Cherokee nation, for example, so, apparently, nations without geographic boundaries do not count. While Randy's curmudgeonly response may have been a bit knee-jerk, I don't think it was all that uninformed. I think that the tendency to dismiss the issues Randy is attempting to point out (most of which are out of scope for this list) because of the way Randy presents them (I'm not defending his methods here) is problematic. > On the other hand, I am suggesting that the geographic > addresses allowed for in the IPv6 RFCs should be allocated > in a way that ignores political boundaries but does take > into account the physical topology of network connections. > I am very confused by this statement. A moment ago, I was reading email from you that suggested that the addressing be based on geographic regions which have no relationship to network topology based on some claim that boiled down to "if we build it, they will come". Now, you're saying you want to allocate addresses topologically regardless of geography. It appears to me that you are disagreeing with yourself. > Disagree with this if you will, but please do not mix > it up with unrelated activities. > I don't see how I can do a better job of disagreeing with it than you already have. 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 owen at delong.com Thu Dec 9 13:14:59 2004 From: owen at delong.com (Owen DeLong) Date: Thu, 09 Dec 2004 10:14:59 -0800 Subject: [ppml] Provider Independence??? In-Reply-To: References: Message-ID: <2147483647.1102587299@imac-en0.delong.sj.ca.us> The ITU position only wins if a large quantity of someones allow the ITU to usurp some level of authority over the internet. I think that is not as likely as some would like to believe. If it is that likely, then, we deserve the ITU as just punishment for our failure to act in the best interests of the community. Owen --On Thursday, December 9, 2004 5:32 PM +0000 Michael.Dillon at radianz.com wrote: >> >> but what happens if a ISP don't want to accept the peering conditions >> >> of the other ISPs in the region, what happens then? >> > >> > Then they don't use geo addresses. >> >> i am really not following... > > Geo addresses are just ordinary IPv6 addresses that > work the same as any other IPv6 addresses. They differ > from the current IPv6 addresses in only two ways. One > is that they come from a well-known prefix so that > anyone who chooses to can apply different policies > to these addresses. The other difference is that the > RIRs allocate these addresses according to a geographical > hierarchy and pass on the requirement to XPs to maintain > this geographical hierarchy. > > This means that the allocation to an endpoint does not > come from their provider. It is provider independent. > Instead, the allocation comes from the local exchange > point operator. At this point, these addresses are > usable through any provider connected to the XP > and the routing announcements for these addresses > can be aggregated globally to a very small number > of entries in the so-called global routing table. > > This doesn't prevent anyone from continuing to > use provider allocated IPv6 addresses in the same > way that they are used in the v4 Internet. > > The ITU can make credible arguments that the > existing random allocation of IPv4 addresses > will not scale in IPv6 and therefore an alternative > is needed. If the Internet community does not > provide some type of geographic addressing that > as an alternative to the ITU's proposal, then > the ITU's position can easily win by default. > We can no longer ignore the phone network because > in the 21st century, the Internet *IS* the phone > network. I disagree with the ITU position. > > --Michael Dillon -- 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 marcelo at it.uc3m.es Thu Dec 9 13:51:50 2004 From: marcelo at it.uc3m.es (marcelo bagnulo braun) Date: Thu, 9 Dec 2004 19:51:50 +0100 Subject: [ppml] Provider Independence??? In-Reply-To: References: Message-ID: <62CCA890-4A13-11D9-9194-000D93ACD0FE@it> I think we are mixing stuff here, that are slightly different. I think that we have different approaches here: one thing is geo addressing as in Tony Hain's PI proposal. In this case, the address block you get depends on your GPS location another different thing is IX based addressing, that can be considered a form of geo addressing but with additional constraints. In this case, the address block is assigned to the IX, and a site can use it as long as its ISP is in the IX. If the site changes to another provider that is not in the IX, it needs to change addresses (even though the site haven't moved geographically) I thought we were talking about the first one, but now it seems we are considering the second one. Could you confirm what are we talking about here? In IX based addressing there is no problem with topology matching geography since this is the case by definition. At this point, the sites would obtain an address block directly from the IX and the ISP of the IX that want to provide service to one of such users need to advertise the whole IX address block. So all isps announcing the address block will receive traffic to any of the sites that are using IX addresses. It is up to the ISPs to decide whether they want to serve such sites or not. I still think that this approach doesn't make business sense. But i think that we repeating ourselves by now, so i will shut up now. regards, marcelo El 09/12/2004, a las 18:32, Michael.Dillon at radianz.com escribi?: >>>> but what happens if a ISP don't want to accept the peering >>>> conditions >>>> of the other ISPs in the region, what happens then? >>> >>> Then they don't use geo addresses. >> >> i am really not following... > > Geo addresses are just ordinary IPv6 addresses that > work the same as any other IPv6 addresses. They differ > from the current IPv6 addresses in only two ways. One > is that they come from a well-known prefix so that > anyone who chooses to can apply different policies > to these addresses. The other difference is that the > RIRs allocate these addresses according to a geographical > hierarchy and pass on the requirement to XPs to maintain > this geographical hierarchy. > > This means that the allocation to an endpoint does not > come from their provider. It is provider independent. > Instead, the allocation comes from the local exchange > point operator. At this point, these addresses are > usable through any provider connected to the XP > and the routing announcements for these addresses > can be aggregated globally to a very small number > of entries in the so-called global routing table. > > This doesn't prevent anyone from continuing to > use provider allocated IPv6 addresses in the same > way that they are used in the v4 Internet. > > The ITU can make credible arguments that the > existing random allocation of IPv4 addresses > will not scale in IPv6 and therefore an alternative > is needed. If the Internet community does not > provide some type of geographic addressing that > as an alternative to the ITU's proposal, then > the ITU's position can easily win by default. > We can no longer ignore the phone network because > in the 21st century, the Internet *IS* the phone > network. I disagree with the ITU position. > > --Michael Dillon > From rdasilva at va.rr.com Thu Dec 9 14:12:03 2004 From: rdasilva at va.rr.com (da Silva, Ron) Date: Thu, 9 Dec 2004 14:12:03 -0500 Subject: [ppml] Proposed Policy: PI assignments for V6 Message-ID: <5D200A6BB92BB54F8E2FED8E4A28D7630177B943@RRMAILER.rr.com> > That isn't how I read the RFC. As I read it, if I have a need for > multiple > subnets in my home, SOHO, business, etc., and I request it, my LIR should > issue me a /48, not a batch of /64s. > > I'm not saying this is good, nor am I saying it is bad, but, as I read the > RFC, that is what it says. Owen - I agree. I was additionally (trying) to point out that mobile endpoints (e.g. a cellphone) were not necessarily considered routers (gateways, whatever) when the draft was developed. Thus, I was soliciting some help on how mobile operations map (or don't map) to the /48 allocation assumptions (a la DSL/Cable) advanced in the RFC. - Should every phone get a /48 because it might be a router? - Should every phone get a /48 because it has an attached Bluetooth subnet that additionally needs IPv6 addressing? - How is this accomplished in the IMS/MMD/MIMO/whatever architectures? Some of the motivations and details are out of scope for ppml, but any policies derived from these discussions are definitely related. -ron From Michael.Dillon at radianz.com Thu Dec 9 15:14:01 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 9 Dec 2004 20:14:01 +0000 Subject: [ppml] Proposed Policy: PI assignments for V6 In-Reply-To: <20041209174133.GE4901@nokia.com> Message-ID: > > Anyone have any URL's that detail current IPv4/IPv6 addressing plans for > > GSM/CDMA architectures? Have you read RFC 3314? Also, these standards are generally worked out by ETSI (and their partners) so http://www.etsi.org may be useful. I found this via their site: http://www.3gpp.org/ftp/tsg_sa/wg2_arch/draft_new_versions_after%20sa%20plenary/sa_25/23.060%20(GPRS%20doimain%20stage%202)/New%20spec/23060-590.doc Here's an APNIC presentation http://www.apnic.net/meetings/10/programme/presentations/APNIC_Intro_for_GPRS.ppt And something from Apricot http://www.apricot.net/apricot2004/doc/cd_content/24th%20February%202004/01%20-%20TTA-3G%20Data%20Networks%20-%20Design%20Issues%20&%20Case%20Studies%20-Simon%20Newstead/Juniper_3G_Data_Network.ppt And this overview does actually talk about prefix lengths and points to various http://www.ipv6.org.tw/seminar/itri/3G%20and%20IPv6%20(tsao).pdf If you don't know what GGSN, UE and PDP contexts are then you will find it tough work reading these documents. And we still don't know just how Wi-Fi is going to evolve. --Michael Dillon From Michael.Dillon at radianz.com Thu Dec 9 15:33:02 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 9 Dec 2004 20:33:02 +0000 Subject: [ppml] Proposed Policy: PI assignments for V6 In-Reply-To: <5D200A6BB92BB54F8E2FED8E4A28D7630177B943@RRMAILER.rr.com> Message-ID: > Some of the motivations and details are out of scope for ppml, but any > policies derived from these discussions are definitely related. And one wonders what good is it to make policies for IPv6 addressing without involving the stakeholders who are building IPv6 networks. There seems to be an underlying assumption that IPv6 is just another protocol that v4 network operators will use when they find some customer demand. But, in fact, cellphone operators are the ones who are building operational v6 networks today using a VERY different architectural model from the v4 Internet. --Michael Dillon From stelarlink at netzero.net Fri Dec 10 12:11:26 2004 From: stelarlink at netzero.net (E. Deally) Date: Fri, 10 Dec 2004 17:11:26 GMT Subject: [ppml] Proposed Policy: PI assignments for V6 Message-ID: <20041210.091214.19838.169671@webmail25.nyc.untd.com> DON'T SEND YOUR RESPONSE TO STELARLINK, WE ARE NOT A MEMBER E.Deally Stelarlink Communications Inc Ph:321-946-5381 Fax:270-918-0120 Email:stelarlink at netzero.net ________________________________________________________________ NetZero Gift Certificates Give the gift of Internet access this holiday season. http://www.netzero.com/give From memsvcs at arin.net Fri Dec 10 17:44:18 2004 From: memsvcs at arin.net (Member Services) Date: Fri, 10 Dec 2004 17:44:18 -0500 (EST) Subject: [ppml] Policy Proposal 2004-3: Global Addresses for Private Network Inter-Connectivity - to be revised Message-ID: The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed policy proposal 2004-3: Global Addresses for Private Network Inter-Connectivity and has determined that while there is no community consensus in favor of the proposal there is consensus that the proposal should be revised and discussed further. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting in October, 2004. Minutes of this meeting are available at http://www.arin.net/library/minutes/ac/ac2004_1021.html. The AC will work with the author of the proposal to make the community suggested revisions and return the proposal to the ppml for further discussion. The current policy proposal text is provided below and is also available at http://www.arin.net/policy/2004_3.html. The ARIN Internet Resource Policy Evaluation Process can be found at http://www.arin.net/policy/ipep.html. Regards, Member Services American Registry for Internet Numbers (ARIN) ##### Policy Proposal 2004-3: Global Addresses for Private Network Inter-Connectivity Policy statement: Private networks may obtain global addresses for private network usage. Hosts within the administrative control of a single organization should still use private address space in accordance with RFC-1918 and RFC-2050. Private networks may receive global IP's for private Interconnectivity if they have already used private IP space in accordance with RFC-1918 and RFC-2050 and any further use of private IP space would result in network conflicts. From memsvcs at arin.net Fri Dec 10 17:46:26 2004 From: memsvcs at arin.net (Member Services) Date: Fri, 10 Dec 2004 17:46:26 -0500 (EST) Subject: [ppml] Policy Proposal 2004-5: Address Space for Multiple Discrete Networks - to be revised Message-ID: The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed policy proposal 2004-5: Address Space for Multiple Discrete Networks and has determined that there is community consensus in favor of the proposal to move it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting in October, 2004. Minutes of this meeting are available at http://www.arin.net/library/minutes/ac/ac2004_1021.html. The policy proposal text is provided below and is also available at http://www.arin.net/policy/2004_5.html. Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 12:00 Noon, Eastern Time, December 29, 2004. The ARIN Internet Resource Policy Evaluation Process can be found at http://www.arin.net/policy/ipep.html. Regards, Member Services American Registry for Internet Numbers (ARIN) ##### Policy Proposal 2004-5: Address Space for Multiple Discrete Networks Author: Bill Darte Policy statement: Organizations with multiple discrete networks desiring to request new or additional address space under a single Organization ID must meet the following criteria: (1) The organization shall be a single entity and not a consortium of smaller independent entities. (2) The organization must have compelling criteria for creating discrete networks. Examples of a discrete network might include: * Regulatory restrictions for data transmission, * Geographic distance and diversity between networks, * Autonomous multi-homed discrete networks. (3) The organization must keep detailed records on how it has allocated space to each location, including the date of each allocation. (4) When applying for additional space from ARIN, the organization must show greater than 50% utilization for both the last block allocated by ARIN, and their allocations from ARIN as a whole. If an organization is unable to meet this 50% criteria, the organization must not have address space available equal to ARIN's minimum allocation when requesting additional space. (5) The organization may not allocate additional address space to a location until each of that location's address blocks are 80% utilized. (6) The organization should notify ARIN at the time of the request their desire to apply this policy to their account. This policy supersedes section 4.5 of the ARIN Number Resource Policy Manual. Rationale: a. Contradictions contained within policy 2001-6 have been removed and replaced with clear, concise text. b. Much of the procedural language contained in 2001-6 has been removed and replaced with policy language. c. 2001-6 made it difficult for smaller organizations to qualify as they were frequently unable to meet the 50% criteria before needing additional space for existing or new locations. The new policy utilization structure now allows both smaller and larger organizations to qualify. From memsvcs at arin.net Fri Dec 10 17:48:46 2004 From: memsvcs at arin.net (Member Services) Date: Fri, 10 Dec 2004 17:48:46 -0500 (EST) Subject: [ppml] Policy Proposal 2004-6: Privacy of Reassignment Information - abandoned Message-ID: The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed policy proposal Policy Proposal 2004-6: Privacy of Reassignment Information and has determined that there is no community consensus in favor of the proposal and should thus be abandoned. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting in October, 2004. Minutes of this meeting are available at http://www.arin.net/library/minutes/ac/ac2004_1021.html. In order for this proposal to be further considered the author must use the last call petition process as defined in the ARIN Internet Resource Policy Evaluation Process. This policy will be considered to be abandoned if the author of the proposal does not initiate a last call petition by 12:00 Noon, Eastern Time, December 20, 2004. The current policy proposal text is provided below and is also available at http://www.arin.net/policy/2004_6.html. The ARIN Internet Resource Policy Evaluation Process can be found at http://www.arin.net/policy/ipep.html. Regards, Member Services American Registry for Internet Numbers (ARIN) ##### Policy Proposal 2004-6: Privacy of Reassignment Information Author: Sanford George Policy Statement: ISPs may choose whether or not to designate reassignment information 'public'. Reassignment information that is not designated 'public' will be available only to ARIN, the entity that created it, and that entity's upstream organizations. The maintenance of the accuracy of the data that is submitted whether it is public or private is the responsibility of the submitting ISP. Rationale: Increasing concern about protection of private information on the Internet has been expressed by many parts of the community. There have been numerous policy proposals over the last several years attempting to protect various portions of the displayed information. Concern has been expressed specifically about the requirement to publicly register customer assignments, which are often regarded by ISPs and customers as private information. By publicly displaying reassignment information, the ISP is in some respects displaying its customer lists and other information that may be considered of a proprietary business interest. From memsvcs at arin.net Fri Dec 10 17:49:48 2004 From: memsvcs at arin.net (Member Services) Date: Fri, 10 Dec 2004 17:49:48 -0500 (EST) Subject: [ppml] Policy Proposal 2004-7: Residential Customer Privacy Policy - abandoned Message-ID: The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed policy proposal 2004-7: Residential Customer Privacy Policy and has determined that there is no community consensus in favor of the proposal and should thus be abandoned. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting in October, 2004. Minutes of this meeting are available at http://www.arin.net/library/minutes/ac/ac2004_1021.html. In order for this proposal to be further considered the author must use the last call petition process as defined in the ARIN Internet Resource Policy Evaluation Process. This policy will be considered to be abandoned if the author of the proposal does not initiate a last call petition by 12:00 Noon, Eastern Time, December 20, 2004. The current policy proposal text is provided below and is also available at http://www.arin.net/policy/2004_7.html. The ARIN Internet Resource Policy Evaluation Process can be found at http://www.arin.net/policy/ipep.html. Regards, Member Services American Registry for Internet Numbers (ARIN) ##### Policy Proposal 2004-7: Residential Customer Privacy Policy Author: William Leibzon Policy statement: An organization with downstream residential customer who is not engaged in business activities may substitute that organization's name for the customer's name, e.g. 'Private customer - XYZ Network', and the customer's street address may read 'Private Residence'. Each private downstream residential reassignment must be less then or equal to 128 ips and have accurate upstream Abuse and Technical POCs visible on the WHOIS record for that block. Rationale: The intent of residential customer privacy was to allow private citizens to have privacy and safety in their personal life while being able to request and use more then 8 ip addresses with residenial dsl line. However soon after implementation it became clear that some of the ip blocks being designated as "Private customer" are being used for business purposes which is clearly seen by size of such reassignments as 69.111.160.0/22. While it is not unexpected that some people may run business (including internet businesses) from their home, the laws regard such activity as being similar to running business from small office and usually require such businesses to receive a license from appropriate local or state agency and to disclose the activity to the public, as such different privacy rules apply in these situations. This policy replaces current residential customer privacy 2003-3 and requires that ISPs only designate reassignment whois data as "Private Customer" if no business activity is involved with use of the ip block. The limit for the reassignment is set to 128 ips as larger number of computers in one residence is likely an indication of business activity (as an example currently telephone companies allow up to 4 residential telephone lines and if somebody needs larger number of telephone lines to his home, those must be purchased as business telephone lines). Additionally the amendment fixes small grammer error in current policy text that involves incorrect use of plural and singular tenses. From memsvcs at arin.net Fri Dec 10 17:50:50 2004 From: memsvcs at arin.net (Member Services) Date: Fri, 10 Dec 2004 17:50:50 -0500 (EST) Subject: [ppml] Policy Proposal 2004-8: Allocation of IPv6 Address Space by the Internet Assigned Numbers Authority (IANA) Policy to Regional Internet Registries - to be revised Message-ID: The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed policy proposal 2004-8: Allocation of IPv6 Address Space by the Internet Assigned Numbers Authority (IANA) Policy to Regional Internet Registries and has determined that while there is no community consensus in favor of the proposal there is consensus that the proposal should be revised and discussed further. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting in October, 2004. Minutes of this meeting are available at http://www.arin.net/library/minutes/ac/ac2004_1021.html. The AC will work with the author of the proposal to make the community suggested revisions and return the proposal to the ppml for further discussion. The current policy proposal text is provided below and is also available at http://www.arin.net/policy/2004_8.html. The ARIN Internet Resource Policy Evaluation Process can be found at http://www.arin.net/policy/ipep.html. Regards, Member Services American Registry for Internet Numbers (ARIN) ##### Policy Proposal 2004-8: Allocation of IPv6 Address Space by the Internet Assigned Numbers Authority (IANA) Policy to Regional Internet Registries Author: John Sweeting Policy statement: 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 the policy. Such requirements should be specified by appropriate agreements among the RIRs and ICANN. 1. Allocation principles --------------------------- - The minimum and initial IPv6 allocation from IANA to an RIR in a /12; - The IANA will allocate sufficient IPv6 address space to each RIR to support its registration needs for at least a 18 month period; - The IANA will allow each RIR to apply its own respective chosen allocation and reservation strategies in order to ensure the efficiency and efficacy of its work. 2. Initial allocations ------------------------- On inception of this policy, each current RIR shall be allocated a new /12 by the IANA. Also, a new RIR shall, on recognition by ICANN, be allocated a new /12 by the IANA. 3. Additional allocations --------------------------- 3.1 Eligibility for additional allocations A RIR is eligible to receive additional IPv6 address space from the IANA when it has utilized (allocated or reserved) more than 50% of its total IPv6 address space holdings. 3.2 Size of additional allocations Each additional allocation to an RIR will be a number (one or more) of /12 blocks, sufficient to ensure that the RIR holds at least 18 months' supply of IPv6 address space. 4. Announcement of IANA allocations to the RIRs -------------------------------------------------- When address space is allocated to a RIR, the IANA will send a detailed announcement to the receiving RIR. The IANA will also make announcements to all other RIRs, informing them of the recent allocation. The RIRs will coordinate announcements to their respective membership lists and any other lists they deem necessary. The IANA will make appropriate modifications to the "Internet Protocol V6 Address Space" page of the IANA website and may make announcements to its own appropriate announcement lists. The IANA announcements will be limited to which address ranges, the time of allocation and to which Registry they have been allocated. From owen at delong.com Fri Dec 10 18:38:31 2004 From: owen at delong.com (Owen DeLong) Date: Fri, 10 Dec 2004 15:38:31 -0800 Subject: [ppml] Support for 2004-5 last call Message-ID: <2147483647.1102693111@[172.17.1.152]> I fully support the policy as currently shown at and urge the board to adopt it as ARIN policy. I applaud Bill for his continued efforts on behalf of the less represented portions of the ARIN constituency. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From ejay.hire at isdn.net Fri Dec 10 18:43:06 2004 From: ejay.hire at isdn.net (Ejay Hire) Date: Fri, 10 Dec 2004 17:43:06 -0600 Subject: [ppml] Support for 2004-5 last call In-Reply-To: <2147483647.1102693111@[172.17.1.152]> Message-ID: <200412102345.iBANjnqu016616@rex.isdn.net> I fully support the policy as currently shown at 2004_5. From jim at tgasolutions.com Sat Dec 11 22:30:27 2004 From: jim at tgasolutions.com (Jim McBurnett) Date: Sat, 11 Dec 2004 22:30:27 -0500 Subject: [ppml] Support for 2004-5 last call Message-ID: <5432D045DAFD8040BCE549749263BD0023B064@testsystem2.tga.local> I agree... I have a customer right now that may fit this policy, so this is of importance to me. Jim -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Friday, December 10, 2004 6:39 PM To: ppml at arin.net Subject: [ppml] Support for 2004-5 last call I fully support the policy as currently shown at and urge the board to adopt it as ARIN policy. I applaud Bill for his continued efforts on behalf of the less represented portions of the ARIN constituency. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. From kurtis at kurtis.pp.se Fri Dec 10 09:41:26 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Fri, 10 Dec 2004 15:41:26 +0100 Subject: [ppml] Proposed Policy: PI assignments for V6 In-Reply-To: <6.0.1.1.2.20041209063828.022d96f0@kahuna.telstra.net> References: <81464318-47BA-11D9-97A6-000D93ACD0FE@it> <2147483647.1102335801@imac-en0.delong.sj.ca.us> <9D4297F2-483D-11D9-97A6-000D93ACD0FE@it.uc3m.es> <2147483647.1102413506@imac-en0.delong.sj.ca.us> <20041208144324.GC8738@nokia.com> <9EF2431C-4948-11D9-9194-000D93ACD0FE@it.uc3m.es> <00e901c4dd59$9125fbf0$6801a8c0@stephen> <6.0.1.1.2.20041209063828.022d96f0@kahuna.telstra.net> Message-ID: <91D80602-4AB9-11D9-9E81-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-12-08, at 20.49, Geoff Huston wrote: >>> I am sorry but i think this is a huge waste. >>> For the time being, most of mobile phones will not have a manet >>> behind, not one not many subnetworks. I think there must be >>> something very wrong if we assign a /48 to each mobile phone >> >> Do mobile phones even count as an "assignment"? > > > > Would personal LANs such as Bluetooth alter this perspective in any > way? The challenge here is to craft policies that look forward and > attempt to anticipate some of the more obvious near term technologies. > > Its also worth bearing in mind the larger picture of the total address > space - even if there was to be a /48 for each mobile handset, what's > the total address consumption. 1 billion handsets is 30 bits. Allowing > for an HD ration of 0.8 there is a further 8 bits - i.e. this is a > /10, or 1/1000th of the total address space. > > Of course this arithmetic allows 16 bits for a personal lAN. Maybe its > worth considering a slightly smaller subnet size - an 8 bit subnet > would imply that the total consumption would be a /18, for the entire > deployment across 1 billion such devices . So perhaps a /56 per > customer allocation in such context may represent a possible balance > between total consumption and recognition of this emerging personal > lan technology. Its worth considering in any case. I think you numbers above are interesting. I have for some time been struggling to convince my self that a fixed /48 boundary for a "site" makes sense. I am less and less convinced. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQbm1mqarNKXTPFCVEQLasACfUwjRpteunwUXoQM6DAgd2bJ+aCEAnRoU HuRVkDAgvK0gTktnAMI0d647 =CsbV -----END PGP SIGNATURE----- From kurtis at kurtis.pp.se Fri Dec 10 09:53:50 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Fri, 10 Dec 2004 15:53:50 +0100 Subject: [ppml] Proposed Policy: PI assignments for V6 In-Reply-To: <03b001c4dd87$ce53ac10$6801a8c0@stephen> References: <81464318-47BA-11D9-97A6-000D93ACD0FE@it> <2147483647.1102335801@imac-en0.delong.sj.ca.us> <9D4297F2-483D-11D9-97A6-000D93ACD0FE@it.uc3m.es> <2147483647.1102413506@imac-en0.delong.sj.ca.us> <03b001c4dd87$ce53ac10$6801a8c0@stephen> Message-ID: <4DC3628E-4ABB-11D9-9E81-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-12-09, at 01.15, Stephen Sprunk wrote: > No, but having PI space makes the process less painful. Only the > border routers need to be updated, and it can be done as quickly as > BGP convergence can be completed (twice). > > A PA site would add a second PA prefix to all of their routers/hosts, > wait a few days, switch all the addresses in DNS, wait another few > days, then remove the first PA prefix. This kills any active > connections during the last step, but that's arguably minor. > Depending on the number of routers/hosts, this does require extensive > effort on the admins' part. So the PI proposal will only address the renumbering pain? >> Do we? How much of these problems are really just covered up with >> NAT? And how many enterprises that you argue would like your >> PI+multihoming capability would much rather that their NAT boxes >> worked with v6 so they didn't have to learn about that comples >> routing stuff? > > It's not the "comples [sic] routing stuff" that sites are avoiding -- > it's the renumbering of routers/hosts. Some also consider NAT to be a > security feature because individual hosts or general topology can't be > determined if there's a single IP visible externally; there is a > strong belief that security by obscurity is necessary even if the > people involved _know_ that it doesn't provide real security. I think people use NAT as an abstraction layer. It's just that they never had to realise it as there was no option. >> Marcelo already pointed this out but I think you really ought to >> catch up with the work in multi6. > > Consensus is that multi6's proposals are not viable today nor will > they be in the near future. The possibility of progress a decade from > now should not hold up people trying to deploy real networks today. So you are saying that the proposal out of multi6 really would be the best way to go, but as someone somewhere has reached consensus that this will take 10 years to deploy we are going to do PI space anyway? What interests me is that I haven't actually seen anyone discuss the multi6 proposals, I've just seen people saying that they haven't studied it. >> I have no problem with the v4 swamp that is not advertised and no >> longer in use. I have a problem with the v4 swamp that IS advertised >> and IS being used.... > > This is also a considerable portion of the v4 swamp that is being used > but not advertised globally. > > However, none of that is relevant to the proposal at hand, since ARIN > can revoke or reclaim any IPv6 assignments in the future if necessary. "Seeing is believing". >>> I don't think your proposed solution is better for the community or >>> for >>> any of the individuals it claims to serve. I think it is an inferior >>> solution that does not provide important elements that are available >>> with PI space. It's only better for the ISPs. >> >> I think PI for v6 is fine coupled with smd's old suggestion of >> transit providers charging per announced prefix. That is AFAIk the >> only model with give away PI that works. And PI+ASN = give away PI >> today. > > That model is infeasible today for a variety of human and technical > reasons. No, it's just that noone want's to be first. >> That said. There are a few things I think is being forgotten in this >> discussion, and I really, really didn't want to point this out, but I >> guess I have to. PI space have the property that you can take it with >> you when you change providers, and really only solves renumbering. It >> does not give you anything wrt provider independence you do not >> already have. Why? Because you can today already either get multiple >> PAs, which won't help the problem with surviving TCP flows, but >> honestly, PI won't help you with that either. > > Please explain how connections using PI addresses do not survive when > a site's link to the respective provider goes down, either > intentionally or otherwise. It will depend on the TCP session being fault tolerant for a BGP timeout+BGP convergence. A VoIP session most likely will be useful. A SSH might not. Survive and being useful are two very different things. YMMV. > If there is a PI block with a minimum assignment/allocation of /48, > then presumably providers will relax their filters for that block. > This has been the case when RIRs have changed allocation policies for > IPv4. There is strong historical record to show that most will NOT > accept a route longer than the minimum allocation size in a particular > block. I know people that have 80k routes less in their DFZ that most people do. Filtering vary a lot. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQbm4g6arNKXTPFCVEQIRGQCg0Mk93FQdjXsok+dwnGjXCICFavUAoOei XiYdUbudKUSxfYbJ77dY1K2k =I4R7 -----END PGP SIGNATURE----- From kurtis at kurtis.pp.se Fri Dec 10 10:07:24 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Fri, 10 Dec 2004 16:07:24 +0100 Subject: [ppml] Provider Independence??? In-Reply-To: <62CCA890-4A13-11D9-9194-000D93ACD0FE@it> References: <62CCA890-4A13-11D9-9194-000D93ACD0FE@it> Message-ID: <330A75A2-4ABD-11D9-9E81-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-12-09, at 19.51, marcelo bagnulo braun wrote: > In IX based addressing there is no problem with topology matching > geography since this is the case by definition. At this point, the > sites would obtain an address block directly from the IX and the ISP > of the IX that want to provide service to one of such users need to > advertise the whole IX address block. So all isps announcing the > address block will receive traffic to any of the sites that are using > IX addresses. It is up to the ISPs to decide whether they want to > serve such sites or not. I still think that this approach doesn't make > business sense. But i think that we repeating ourselves by now, so i > will shut up now. So called IX based addressing is the same as buying transit from an ISP, so IX=ISP in that case. I wrote a small essay on that to the v6ops list and brought it up in San Diego, both at the microphone and in private with the I-D authors. And I am amazed everytime I see that this is till alive. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQbm7saarNKXTPFCVEQIDTwCg7x521/MN2WMzAMPBYsTY7yS55sgAoJ/5 yWWc2ZyqL5PO9JG7riu2vK1M =Kxow -----END PGP SIGNATURE----- From kurtis at kurtis.pp.se Fri Dec 10 09:44:00 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Fri, 10 Dec 2004 15:44:00 +0100 Subject: [ppml] Provider Independence??? In-Reply-To: <028b01c4dd79$869a7fb0$6801a8c0@stephen> References: <028b01c4dd79$869a7fb0$6801a8c0@stephen> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-12-08, at 23.51, Stephen Sprunk wrote: > In that light, it appears necessary to provide PI prefixes in the > immediate future, and we should be debating the current proposal in > comparison to the proposed alternatives (none) and to doing nothing. > If/when a viable alternative is developed, ARIN can modify or repeal > the PI policy based on community discussion. Unlike v4 swamp > assignments, ARIN also has clear authority to reclaim _all_ v6 > assignments if necessary. > > Today, there are about 16k origin-only ASes; that is the number of new > IPv6 routes that one would expect this policy to generate and is > clearly within the capabilities of today's hardware. If demand is > significantly stronger than expected, the community can revisit > whether it is necessary to modify or repeal the policy to address > operational concerns even if no viable alternative has presented > itself yet. _*IF*_ this proposal was to be adopted (and I think there are alternatives), I would suggest you explicitly note that a) That any assignment made under it can be recalled b) With what notice the assignment can be recalled c) Under what conditions this assignment will be recalled - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQbm2NaarNKXTPFCVEQI+ZACePAuaR4TivtA2kUbVBvSxyMcYOocAn2E5 k83mUixKTlfHIO3Qqio65BP6 =UgO+ -----END PGP SIGNATURE----- From owen at delong.com Sun Dec 12 13:53:01 2004 From: owen at delong.com (Owen DeLong) Date: Sun, 12 Dec 2004 10:53:01 -0800 Subject: [ppml] Proposed Policy: PI assignments for V6 In-Reply-To: <4DC3628E-4ABB-11D9-9E81-000A95928574@kurtis.pp.se> References: <81464318-47BA-11D9-97A6-000D93ACD0FE@it> <2147483647.1102335801@imac-en0.delong.sj.ca.us> <9D4297F2-483D-11D9-97A6-000D93ACD0FE@it.uc3m.es> <2147483647.1102413506@imac-en0.delong.sj.ca.us> <03b001c4dd87$ce53ac10$6801a8c0@stephen> <4DC3628E-4ABB-11D9-9E81-000A95928574@kurtis.pp.se> Message-ID: <1608226182.1102848781@imac-en0.delong.sj.ca.us> > So the PI proposal will only address the renumbering pain? > No. it also addresses transition pain, choose your own destiny rather than be at the mercy of an ISP pain, multihoming pain, and, a host of other problems that we have been living with to some extent or other in the v4 world. > I think people use NAT as an abstraction layer. It's just that they > never had to realise it as there was no option. > There's probably some truth to this. However, the abstraction layer does come at some cost, and, I know of a number of organizations that would really rather not use NAT. They've accepted it in a v4 world because they didn't see any alternative. They will not accept it in a v6 world. > So you are saying that the proposal out of multi6 really would be the > best way to go, but as someone somewhere has reached consensus that > this will take 10 years to deploy we are going to do PI space anyway? > What interests me is that I haven't actually seen anyone discuss the > multi6 proposals, I've just seen people saying that they haven't > studied it. > No... We're saying that even _IF_ it were the best way to go, of which we aren't convinced because there is no operational experience and not enough data to make that judgment, it's at least several years away and requires dependent implementation at both sides in order to work. I can deploy PI space on my side and it works generally. For multi6, not only do I have to support its requirements, but, it has to be implemented at virtually every site I'm trying to talk to as well. >> However, none of that is relevant to the proposal at hand, since ARIN >> can revoke or reclaim any IPv6 assignments in the future if necessary. > > "Seeing is believing". > That's a tautology. You're saying you don't want to issue PI space in v6 because you don't want a swamp, but, you say the only way to believe that a swamp can be prevented is to see PI space issued and reclaimed without creating a swamp. So, I will take your statement "Seeing is believing" as an endorsement for at least conducting the experiment. >> That model is infeasible today for a variety of human and technical >> reasons. > > No, it's just that noone want's to be first. > No. That's one of a variety of reasons. It's a human one. >> Please explain how connections using PI addresses do not survive when >> a site's link to the respective provider goes down, either >> intentionally or otherwise. > > It will depend on the TCP session being fault tolerant for a BGP > timeout+BGP convergence. A VoIP session most likely will be useful. A > SSH might not. Survive and being useful are two very different things. > YMMV. > I think you got those backwards. VOIP is unlikely to usefully survive convergence time in some cases (note, with BFD and fast convergence available in some circumstances, BGP convergence is not as slow as you think for most failures and I have seen VOIP usefully survive.). SSH will almost always usefully survive. I think that the capabilities of BFD and fast convergence will be incrementally improved over time, making PI space more useful in this regard. History so far has shown that I am correct. >> If there is a PI block with a minimum assignment/allocation of /48, >> then presumably providers will relax their filters for that block. >> This has been the case when RIRs have changed allocation policies for >> IPv4. There is strong historical record to show that most will NOT >> accept a route longer than the minimum allocation size in a particular >> block. > > I know people that have 80k routes less in their DFZ that most people > do. Filtering vary a lot. > And this counters the above statement how? Technically, I could run a DFZ with two routes if I really wanted to. 0.0.0.0/1 -> ISP 128.0.0.0/1 -> ISP Heavy filtering indeed. However, MOST of the real DFZs aren't filtering that heavily. The ones that do probably can't reach a variety of sites on the internet or aren't as effectively default free as they think. Over time, any site which filters more aggressively than the RIR MAU boundary will be able to reach fewer and fewer sites. I don't think this small minority of sites justifies preserving a larger boundary. 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 owen at delong.com Sun Dec 12 13:56:00 2004 From: owen at delong.com (Owen DeLong) Date: Sun, 12 Dec 2004 10:56:00 -0800 Subject: [ppml] Provider Independence??? In-Reply-To: References: <028b01c4dd79$869a7fb0$6801a8c0@stephen> Message-ID: <1786507415.1102848960@imac-en0.delong.sj.ca.us> It is already generally noted in both ARIN policies and in the contract signed by each and every person receiving resource allocations from ARIN that the resource assignment can be revoked. Under what circumstances and in what time frame would be something I would rather leave to the people crafting the policy to address the circumstances that lead to consensus among the ARIN community that it was necessary. Absent such consensus, I do not believe that they should be withdrawn. Owen --On Friday, December 10, 2004 3:44 PM +0100 Kurt Erik Lindqvist wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 2004-12-08, at 23.51, Stephen Sprunk wrote: > >> In that light, it appears necessary to provide PI prefixes in the >> immediate future, and we should be debating the current proposal in >> comparison to the proposed alternatives (none) and to doing nothing. >> If/when a viable alternative is developed, ARIN can modify or repeal >> the PI policy based on community discussion. Unlike v4 swamp >> assignments, ARIN also has clear authority to reclaim _all_ v6 >> assignments if necessary. >> >> Today, there are about 16k origin-only ASes; that is the number of new >> IPv6 routes that one would expect this policy to generate and is >> clearly within the capabilities of today's hardware. If demand is >> significantly stronger than expected, the community can revisit >> whether it is necessary to modify or repeal the policy to address >> operational concerns even if no viable alternative has presented >> itself yet. > > _*IF*_ this proposal was to be adopted (and I think there are > alternatives), I would suggest you explicitly note that > > a) That any assignment made under it can be recalled > b) With what notice the assignment can be recalled > c) Under what conditions this assignment will be recalled > > - - kurtis - > > -----BEGIN PGP SIGNATURE----- > Version: PGP 8.1 > > iQA/AwUBQbm2NaarNKXTPFCVEQI+ZACePAuaR4TivtA2kUbVBvSxyMcYOocAn2E5 > k83mUixKTlfHIO3Qqio65BP6 > =UgO+ > -----END PGP SIGNATURE----- > -- 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 michel at arneill-py.sacramento.ca.us Sun Dec 12 14:32:30 2004 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Sun, 12 Dec 2004 11:32:30 -0800 Subject: [ppml] Proposed Policy: PI assignments for V6 Message-ID: > Kurt Erik Lindqvist wrote: > So you are saying that the proposal out of multi6 really > would be the best way to go, but as someone somewhere has > reached consensus that this will take 10 years to deploy > we are going to do PI space anyway? What interests me is > that I haven't actually seen anyone discuss the multi6 > proposals, I've just seen people saying that they haven't > studied it. Kurtis, The work you have done as co-chair of multi6 is a credit to you (I could not say the same for your predecessors). Nevertheless, your WG still hasn't produced anything yet and it's been 10 years. Contrary to what you think lots of people actually looked at the proposals and lots of people think none is deployable. The blame largely comes from before you were appointed but the bottom line is that you missed the launch windows by 4 years at best. I will remind you the words of Randy Bush, then-AD when he appointed you: "Shuffling desk chairs on the Titanic". There are enough people that have followed this story over the last 10 years, are you trying to say that your ship floats now? Please, you don't even have a single proposal as a WG document. Come back to us when you actually have something. Michel. From memsvcs at arin.net Mon Dec 13 10:37:54 2004 From: memsvcs at arin.net (Member Services) Date: Mon, 13 Dec 2004 10:37:54 -0500 (EST) Subject: [ppml] Policy Proposal 2004-5: Address Space for Multiple Discrete Networks - last call Message-ID: Resending this announcement with correct subject line. The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed policy proposal 2004-5: Address Space for Multiple Discrete Networks and has determined that there is community consensus in favor of the proposal to move it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting in October, 2004. Minutes of this meeting are available at http://www.arin.net/library/minutes/ac/ac2004_1021.html. The policy proposal text is provided below and is also available at http://www.arin.net/policy/2004_5.html. Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 12:00 Noon, Eastern Time, December 29, 2004. The ARIN Internet Resource Policy Evaluation Process can be found at http://www.arin.net/policy/ipep.html. Regards, Member Services American Registry for Internet Numbers (ARIN) ##### Policy Proposal 2004-5: Address Space for Multiple Discrete Networks Author: Bill Darte Policy statement: Organizations with multiple discrete networks desiring to request new or additional address space under a single Organization ID must meet the following criteria: (1) The organization shall be a single entity and not a consortium of smaller independent entities. (2) The organization must have compelling criteria for creating discrete networks. Examples of a discrete network might include: * Regulatory restrictions for data transmission, * Geographic distance and diversity between networks, * Autonomous multi-homed discrete networks. (3) The organization must keep detailed records on how it has allocated space to each location, including the date of each allocation. (4) When applying for additional space from ARIN, the organization must show greater than 50% utilization for both the last block allocated by ARIN, and their allocations from ARIN as a whole. If an organization is unable to meet this 50% criteria, the organization must not have address space available equal to ARIN's minimum allocation when requesting additional space. (5) The organization may not allocate additional address space to a location until each of that location's address blocks are 80% utilized. (6) The organization should notify ARIN at the time of the request their desire to apply this policy to their account. This policy supersedes section 4.5 of the ARIN Number Resource Policy Manual. Rationale: a. Contradictions contained within policy 2001-6 have been removed and replaced with clear, concise text. b. Much of the procedural language contained in 2001-6 has been removed and replaced with policy language. c. 2001-6 made it difficult for smaller organizations to qualify as they were frequently unable to meet the 50% criteria before needing additional space for existing or new locations. The new policy utilization structure now allows both smaller and larger organizations to qualify. From L.Howard at stanleyassociates.com Mon Dec 13 12:59:37 2004 From: L.Howard at stanleyassociates.com (Howard, W. Lee) Date: Mon, 13 Dec 2004 12:59:37 -0500 Subject: [ppml] Reclamation (Was: Proposed Policy: PI assignments for V6) Message-ID: > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Owen DeLong > Sent: Wednesday, December 08, 2004 11:56 AM > To: Michael.Dillon at radianz.com; ppml at arin.net > Subject: Re: [ppml] Proposed Policy: PI assignments for V6 > > --On Wednesday, December 8, 2004 12:07 PM +0000 > Michael.Dillon at radianz.com > wrote: > > >> Right... The v4 swamp was assigned before CIDR. The v4 swamp also > >> has absolutely no right of reclamation or annual renewal. > Addresses > >> issued prior to the RIR system CAN NOT be taken away from > the people > >> that have them. Those people do not pay annual fees for > them. That > >> is a very different case from what would happen under this policy > >> with v6. Earlier this year, the Board agreed to begin billing the annual maintenance fee to organizations holding numbers assigned before ARIN, if and when that organization requested service from ARIN (like IN ADDR or WHOIS changes). Implementation has been delayed while some integration projects are completed. This was my idea--I'm the villain. > > I disagree. If there is ever a real crunch on the IPv4 > address space > > then we most certainly will impose annual fees on the swamp and/or > > reclaim and reissue those addresses. This is no different > from domain > > names which once were free and now are not. IP addresses are not > > property. Nobody owns them. The right to use IP addresses > derives from > > the community of Internet users and is coordinated by those users > > through the RIR system. > > Under what authority? You have no right. Those addresses > were assigned under an agreement that said they were assigned > in perpetuity. Any attempt by any collection of ISPs or > others to prevent them reasonable access to the internet > under terms available to any other RIR/ICANN/NIC assigned > block would be a violation of law, at least in the US. It could be an interesting legal battle. I haven't seen contracts for assignments made before ARIN, so I can't say whether they were made in perpetuity. But I don't believe ARIN is required to provide IN-ADDR delegations or WHOIS services for organizations with which is has no relationship. Other than cessation of those services, what would reclaimation look like? > The v4 swamp is the v4 swamp. Draining it would require voluntary > cooperation > of the address owners. You might or might not get that. > Certainly, you > will > meet rather fierce opposition if you attempt to simply impose it. If ARIN reclaimed all unused address space, (since I'm sure nobody proposed reclaiming address space that's being used) how much would we prolong the life of IPv4? I suspect it would be less than a year. Lee > > Owen > From randy at psg.com Mon Dec 13 14:25:24 2004 From: randy at psg.com (Randy Bush) Date: Mon, 13 Dec 2004 11:25:24 -0800 Subject: [ppml] Reclamation (Was: Proposed Policy: PI assignments for V6) References: Message-ID: <16829.60580.285611.518136@ran.psg.com> > It could be an interesting legal battle. I haven't seen > contracts for assignments made before ARIN, so I can't say > whether they were made in perpetuity. But I don't believe ARIN > is required to provide IN-ADDR delegations or WHOIS services for > organizations with which is has no relationship. actually, that committment was made to the fnc, nsf, and others in order to get permission to form arin. > If ARIN reclaimed all unused address space, (since I'm sure > nobody proposed reclaiming address space that's being used) how > much would we prolong the life of IPv4? I suspect it would be > less than a year. i suggest you're off by a decimal order of magnitude. if the book is too difficult, see george's and geoff's movie. randy From randy at psg.com Mon Dec 13 14:33:57 2004 From: randy at psg.com (Randy Bush) Date: Mon, 13 Dec 2004 11:33:57 -0800 Subject: [ppml] Reclamation (Was: Proposed Policy: PI assignments for V6) References: <16829.60580.285611.518136@ran.psg.com> Message-ID: <16829.61093.961286.50407@ran.psg.com> btw, some of us remember when the most optimistic predictions of ipv4 address space lifetime was 2005. maybe we should have a wake? randy From randy at psg.com Mon Dec 13 14:59:59 2004 From: randy at psg.com (Randy Bush) Date: Mon, 13 Dec 2004 11:59:59 -0800 Subject: [ppml] broken subscriber Message-ID: <16829.62655.184350.317485@ran.psg.com> everyone who posts to the ppml list is blessed with one of these responses. From: null at ait.com To: randy at psg.com Subject: Inactive Email Recipient Date: Mon, 13 Dec 2004 14:54:20 -0500 =========================================================================== You have reached an email address that is no longer in use. If you need to contact Advanced Internet Technologies, please visit our website for contact information. =========================================================================== i have whined at the arin postmaster to no avail. perhaps a more public whine will work. randy From L.Howard at stanleyassociates.com Mon Dec 13 16:46:46 2004 From: L.Howard at stanleyassociates.com (Howard, W. Lee) Date: Mon, 13 Dec 2004 16:46:46 -0500 Subject: [ppml] Reclamation (Was: Proposed Policy: PI assignments for V6) Message-ID: Please cite your sources. Since 0.1 years is less than a year, you must be suggesting that reclamation would save less than ten years, which would not be consistent with the references you almost give. Lee > -----Original Message----- > From: Randy Bush [mailto:randy at psg.com] > Sent: Monday, December 13, 2004 2:25 PM > To: Howard, W. Lee > Cc: ppml at arin.net > Subject: RE: [ppml] Reclamation (Was: Proposed Policy: PI > assignments for V6) > > > > It could be an interesting legal battle. I haven't seen > contracts for > > assignments made before ARIN, so I can't say whether they > were made in > > perpetuity. But I don't believe ARIN is required to > provide IN-ADDR > > delegations or WHOIS services for organizations with which > is has no > > relationship. > > actually, that committment was made to the fnc, nsf, and > others in order to get permission to form arin. > > > If ARIN reclaimed all unused address space, (since I'm sure nobody > > proposed reclaiming address space that's being used) how > much would we > > prolong the life of IPv4? I suspect it would be less than a year. > > i suggest you're off by a decimal order of magnitude. if the > book is too difficult, see george's and geoff's movie. > > randy > From randy at psg.com Mon Dec 13 16:54:29 2004 From: randy at psg.com (Randy Bush) Date: Mon, 13 Dec 2004 13:54:29 -0800 Subject: [ppml] Reclamation (Was: Proposed Policy: PI assignments for V6) References: Message-ID: <16830.3989.830215.218566@ran.psg.com> > Please cite your sources. perhaps you could do your homework _before_ posting arithmetic assertions, not after? i saw george's and geoff's presentation in the apnic routing sig, see . i believe it was also shown at a recent nanog, and should have been shown at the recent arin meeting, but i don't know if it was. randy From owen at delong.com Mon Dec 13 16:59:31 2004 From: owen at delong.com (Owen DeLong) Date: Mon, 13 Dec 2004 13:59:31 -0800 Subject: [ppml] Reclamation (Was: Proposed Policy: PI assignments for V6) In-Reply-To: References: Message-ID: <2147483647.1102946371@[172.17.1.152]> > Earlier this year, the Board agreed to begin billing the annual > maintenance fee to organizations holding numbers assigned before ARIN, if > and when that organization requested service from ARIN (like IN ADDR or > WHOIS changes). Implementation has been delayed while some integration > projects are completed. > Right, but, if they don't need any changes by ARIN, they have no requirement or inducement to sign an ARIN contract and, thus, still it would be difficult if not impossible to reclaim that space other than by voluntary cooperation from the address holders. > This was my idea--I'm the villain. > I supported it. I still do. I think it was a good compromise between ARIN's needs to get paid for services rendered (changes) and the community desire that they not have some contract foisted on them that they never agreed to just to keep a resource that they, to the best of their knowledge, already owned. > It could be an interesting legal battle. I haven't seen contracts for > assignments made before ARIN, so I can't say whether they were made in > perpetuity. But I don't believe ARIN is required to provide IN-ADDR > delegations or WHOIS services for organizations with which is has no > relationship. Other than cessation of those services, what would > reclaimation look like? > There weren't contracts. Literally, you sent an email to SRI and they said "These numbers are yours." in an email back. You are correct, ARIN has no need to provide those services. However, if ARIN started allocating/assigning those addresses to other entities, and, if more than one ISP agreed to give preferential treatment to the party to whom ARIN had now assigned/allocated those numbers instead of to the party who originally received them from SRI or NetSol InterNIC, then, those ISPs and ARIN could face some interesting anti-trust concerns. > >> The v4 swamp is the v4 swamp. Draining it would require voluntary >> cooperation >> of the address owners. You might or might not get that. >> Certainly, you >> will >> meet rather fierce opposition if you attempt to simply impose it. > > If ARIN reclaimed all unused address space, (since I'm sure nobody > proposed reclaiming address space that's being used) how much would we > prolong the life of IPv4? I suspect it would be less than a year. > Agreed. The gains from reclaiming v4 aren't in the freeing the space, the big theoretical gain from draining the swamp is forcing people into an aggregable block instead of the /24s that exist there now. Personally, I don't think there's much to be gained there, either, but, that's the theory advanced by many of the same people that fear the PI v6 proposal. BTW, congratulations on your appointment to ASO AC. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From gih at apnic.net Mon Dec 13 18:27:56 2004 From: gih at apnic.net (Geoff Huston) Date: Tue, 14 Dec 2004 10:27:56 +1100 Subject: [ppml] Reclamation (Was: Proposed Policy: PI assignments for V6) In-Reply-To: References: Message-ID: <6.0.1.1.2.20041214101128.02494b78@localhost> Lee, There are two sources of data that allow some estimates of this form to be made. The first is the analysis of the IPv4 address space in terms of what is unused or not One source of this data is at: http://bgp.potaroo.net/ipv4/stats/allocated-all.html Here I'll use the /8 notation meaning "16.7M addresses", rather than "a contiguous block of addresses mapped by a /8 address prefix". 143/8s are 'in play' right now (the other 93 /8s are either ietf reserved in various states or with IANA) 81/8s are advertised on the public global Internet. 62 /8s are 'unused' using this broad categorization At a finer level 20 /8s are currently unallocated - in that there is no visible RIR information about its allocation. 10 /8s are in the historical address space (old B's mainly), which appear to be legacy unallocated addresses and the other 10 /8s are in the working pools of rir-managed address space (expansion windows, yet-to-be-allocated, etc) The other 42 /8s are allocated, but have no visibility in the public routed Internet. They may or may not be in use in private contexts. The other piece of data is a model about address consumption. One source of data about consumption can be found at: http://bgp.potaroo.net/ipv4/ Considering that the amount of RIR allocated space these days that finds its way in the public routing table is close to 100% (see figure 2.4), and has been like this for the past 8 years or so, then the guiding metric is the growth of the amount of advertised space in the BGP table. Taking the first order differential of this series of data shows that the 4 year trend in address consumption is some 4 /8s per year, while the more recent data over the past 6 months reveals a consumption rate of up to 6 /8s per year. 62 /8s at a rate of 6 /8s per year would be 10 years of consumption. Usual caveats - this is, like any predictive exercise, replete with many assumptions about the future. Taking a more conservative view of using the 10 /8s that are unallocated in the legacy B space, at current consumption rates this still looks like a pool of addresses that would provide some 20 months of allocations. The analysis of the level of fragmentation of this space is also shown at the second URL - there are some 1100 /24 windows in this space, but also some 350 /16 blocks and a smaller number of larger blocks (Figure 3.11) Hope this helps, regards, Geoff At 08:46 AM 14/12/2004, Howard, W. Lee wrote: >Please cite your sources. > >Since 0.1 years is less than a year, you must be suggesting that reclamation >would save less than ten years, which would not be consistent with the >references you almost give. > >Lee > > > -----Original Message----- > > From: Randy Bush [mailto:randy at psg.com] > > Sent: Monday, December 13, 2004 2:25 PM > > To: Howard, W. Lee > > Cc: ppml at arin.net > > Subject: RE: [ppml] Reclamation (Was: Proposed Policy: PI > > assignments for V6) > > > > > > > It could be an interesting legal battle. I haven't seen > > contracts for > > > assignments made before ARIN, so I can't say whether they > > were made in > > > perpetuity. But I don't believe ARIN is required to > > provide IN-ADDR > > > delegations or WHOIS services for organizations with which > > is has no > > > relationship. > > > > actually, that committment was made to the fnc, nsf, and > > others in order to get permission to form arin. > > > > > If ARIN reclaimed all unused address space, (since I'm sure nobody > > > proposed reclaiming address space that's being used) how > > much would we > > > prolong the life of IPv4? I suspect it would be less than a year. > > > > i suggest you're off by a decimal order of magnitude. if the > > book is too difficult, see george's and geoff's movie. > > > > randy > > From easmith at beatrice.rutgers.edu Mon Dec 13 20:42:36 2004 From: easmith at beatrice.rutgers.edu (Ed Allen Smith) Date: Mon, 13 Dec 2004 20:42:36 -0500 Subject: [ppml] broken subscriber In-Reply-To: <16829.62655.184350.317485@ran.psg.com> References: <16829.62655.184350.317485@ran.psg.com> Message-ID: In message <16829.62655.184350.317485 at ran.psg.com> (on 13 December 2004 11:59:59 -0800), randy at psg.com (Randy Bush) wrote: >everyone who posts to the ppml list is blessed with one of these >responses. > > From: null at ait.com > To: randy at psg.com > Subject: Inactive Email Recipient > Date: Mon, 13 Dec 2004 14:54:20 -0500 > > > ========================================================================= > > You have reached an email address that is no longer in use. > If you need to contact Advanced Internet Technologies, > please visit our website for contact information. > > ========================================================================= > >i have whined at the arin postmaster to no avail. perhaps a >more public whine will work. Perhaps the proper answer is for AIT to stop using a receive-then-bounce technique, which will also be generating bounces to addresses forged by spammers (including viruses) et al? (Indeed, such "backscatter" from various servers is currently the largest component of the junk email attempting to come into our local mailserver.) Mailing list software also has a much higher likelihood of dealing with that automatically. -Allen -- Allen Smith http://cesario.rutgers.edu/easmith/ September 11, 2001 A Day That Shall Live In Infamy II "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin From kurtis at kurtis.pp.se Mon Dec 13 14:26:26 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Mon, 13 Dec 2004 20:26:26 +0100 Subject: [ppml] Proposed Policy: PI assignments for V6 In-Reply-To: <1608226182.1102848781@imac-en0.delong.sj.ca.us> References: <81464318-47BA-11D9-97A6-000D93ACD0FE@it> <2147483647.1102335801@imac-en0.delong.sj.ca.us> <9D4297F2-483D-11D9-97A6-000D93ACD0FE@it.uc3m.es> <2147483647.1102413506@imac-en0.delong.sj.ca.us> <03b001c4dd87$ce53ac10$6801a8c0@stephen> <4DC3628E-4ABB-11D9-9E81-000A95928574@kurtis.pp.se> <1608226182.1102848781@imac-en0.delong.sj.ca.us> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-12-12, at 19.53, Owen DeLong wrote: >> So the PI proposal will only address the renumbering pain? >> > No. it also addresses transition pain, choose your own destiny rather > than > be at the mercy of an ISP pain, multihoming pain, and, a host of other > problems > that we have been living with to some extent or other in the v4 world. Well, if you have, why didn't you get PI space in v4? >> I think people use NAT as an abstraction layer. It's just that they >> never had to realise it as there was no option. >> > There's probably some truth to this. However, the abstraction layer > does > come at some cost, and, I know of a number of organizations that would > really > rather not use NAT. They've accepted it in a v4 world because they > didn't > see any alternative. They will not accept it in a v6 world. I think they are very few. Extremely few actually. > For multi6, not only do I have > to support its requirements, but, it has to be implemented at virtually > every site I'm trying to talk to as well. In order for you to take full advantage - yes. But not for it to work in general. >>> However, none of that is relevant to the proposal at hand, since ARIN >>> can revoke or reclaim any IPv6 assignments in the future if >>> necessary. >> >> "Seeing is believing". >> > That's a tautology. You're saying you don't want to issue PI space in > v6 > because you don't want a swamp, but, you say the only way to believe > that > a swamp can be prevented is to see PI space issued and reclaimed > without > creating a swamp. So, I will take your statement "Seeing is > believing" as > an endorsement for at least conducting the experiment. You are arguing that ULAs can't be traced if they are leaked, but that we could reclaim PI space. I think you can trace ULAs, I am not as convinced we can reclaim PI space. But I really hope I would be wrong on that one. >> It will depend on the TCP session being fault tolerant for a BGP >> timeout+BGP convergence. A VoIP session most likely will be useful. A >> SSH might not. Survive and being useful are two very different things. >> YMMV. >> > I think you got those backwards. I did, sorry. >>> If there is a PI block with a minimum assignment/allocation of /48, >>> then presumably providers will relax their filters for that block. >>> This has been the case when RIRs have changed allocation policies for >>> IPv4. There is strong historical record to show that most will NOT >>> accept a route longer than the minimum allocation size in a >>> particular >>> block. >> >> I know people that have 80k routes less in their DFZ that most people >> do. Filtering vary a lot. >> > And this counters the above statement how? Technically, I could run a > DFZ > with two routes if I really wanted to. > 0.0.0.0/1 -> ISP > 128.0.0.0/1 -> ISP > > Heavy filtering indeed. However, MOST of the real DFZs aren't > filtering that > heavily. The ones that do probably can't reach a variety of sites on > the > internet or aren't as effectively default free as they think. > > Over time, any site which filters more aggressively than the RIR MAU > boundary > will be able to reach fewer and fewer sites. I don't think this small > minority > of sites justifies preserving a larger boundary. In v4 they have seen more and more scenic routing, not less reachability. My point was that we have no effective control over the filtering polices with ISPs. And the larger the ISP, the less influence. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQb3s5qarNKXTPFCVEQJyMwCg9f/mJVG00KYAYIu4wEm1Uw/L7eAAoMEO pel7hbiKLiQY3UBr5BFxMcFN =1dqJ -----END PGP SIGNATURE----- From kurtis at kurtis.pp.se Mon Dec 13 14:34:09 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Mon, 13 Dec 2004 20:34:09 +0100 Subject: [ppml] Proposed Policy: PI assignments for V6 In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-12-12, at 20.32, Michel Py wrote: >> Kurt Erik Lindqvist wrote: >> So you are saying that the proposal out of multi6 really >> would be the best way to go, but as someone somewhere has >> reached consensus that this will take 10 years to deploy >> we are going to do PI space anyway? What interests me is >> that I haven't actually seen anyone discuss the multi6 >> proposals, I've just seen people saying that they haven't >> studied it. > > Kurtis, > > The work you have done as co-chair of multi6 is a credit to you (I > could > not say the same for your predecessors). Well, I think credit should go to the design-teams, but thanks! > Nevertheless, your WG still > hasn't produced anything yet and it's been 10 years. It's been 10 years for IPv6, and 4 years (or 3.5 of whatever) for multi6. > Contrary to what > you think lots of people actually looked at the proposals and lots of > people think none is deployable. The blame largely comes from before > you > were appointed but the bottom line is that you missed the launch > windows > by 4 years at best. The problem is that we didn't address routing scalability when IPv6 was designed. And that we (for some definition of we, but let's accept the consensus model) actively choose not to deal with this for a long time. Now we are trying to catch up. I don't think a discussion of why we are here, how long it took us, and how long we have left is all that useful. We have a problem. We have recognised, now let's deal with it. > I will remind you the words of Randy Bush, then-AD when he appointed > you: "Shuffling desk chairs on the Titanic". You have cited Randy on this pretty frequently, I can't speak for Randy, but (claiming) knowing Randy I could never figure out if he meant multi6 or IPv6. Never mind. > There are enough people > that have followed this story over the last 10 years, are you trying to > say that your ship floats now? Please, you don't even have a single > proposal as a WG document. Come back to us when you actually have > something. We do have a single proposal since D.C. It's not a protocol yet, as that is left to another area. It's not a WG document yet, as we are waiting for people to submit the changes. As for coming back, I rather see the operational community provide some input rather than second guessing the work. The mailinglist is and has always been open. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQb3utaarNKXTPFCVEQKM1gCgg2w7lr/Um3wgZln1a0AhHASVhNcAnjQd gj3s07Vs1aQUGBdjgKnnkC5L =8/vx -----END PGP SIGNATURE----- From L.Howard at stanleyassociates.com Tue Dec 14 09:32:51 2004 From: L.Howard at stanleyassociates.com (Howard, W. Lee) Date: Tue, 14 Dec 2004 09:32:51 -0500 Subject: [ppml] Reclamation (Was: Proposed Policy: PI assignments for V6) Message-ID: > -----Original Message----- > From: Randy Bush [mailto:randy at psg.com] > Sent: Monday, December 13, 2004 4:54 PM > To: Howard, W. Lee > Cc: ppml at arin.net > Subject: RE: [ppml] Reclamation (Was: Proposed Policy: PI > assignments for V6) > > > Please cite your sources. > > perhaps you could do your homework _before_ posting > arithmetic assertions, not after? But gee, Randy, if I hadn't said anything, I wouldn't have had the pleasure of this dialogue. I looked at http://www.iana.org/assignments/ipv4-address-space and compared allocated to announced, a while back. My result was about 10% reclaimable. I was looking at addresses, not prefixes. > i saw george's and geoff's presentation in the apnic routing > sig, see . > i believe it was also shown at a recent nanog, and should have been > shown at the recent arin meeting, but i don't know if it was. Thank you. In fact, I hadn't seen that presentation (and still haven't, but I've read the transcript). The relevant line: If we used [unmanaged allocated space] as well I think you'd buy about another ten years out of this space if you actively managed the As rather than shut your eyes and hoped they went away. -- Geoff Huston Also, the discussion of how much life IPv4 has is available at http://www.arin.net/newsletter/2003_Third_Qtr.pdf among other places. Lee > randy From owen at delong.com Tue Dec 14 10:51:35 2004 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Dec 2004 07:51:35 -0800 Subject: [ppml] Proposed Policy: PI assignments for V6 In-Reply-To: References: <81464318-47BA-11D9-97A6-000D93ACD0FE@it> <2147483647.1102335801@imac-en0.delong.sj.ca.us> <9D4297F2-483D-11D9-97A6-000D93ACD0FE@it.uc3m.es> <2147483647.1102413506@imac-en0.delong.sj.ca.us> <03b001c4dd87$ce53ac10$6801a8c0@stephen> <4DC3628E-4ABB-11D9-9E81-000A95928574@kurtis.pp.se> <1608226182.1102848781@imac-en0.delong.sj.ca.us> Message-ID: <2147483647.1103010695@imac-en0.delong.sj.ca.us> >>> So the PI proposal will only address the renumbering pain? >>> >> No. it also addresses transition pain, choose your own destiny rather >> than >> be at the mercy of an ISP pain, multihoming pain, and, a host of other >> problems >> that we have been living with to some extent or other in the v4 world. > > Well, if you have, why didn't you get PI space in v4? > I did, but, many other organizations did not. It basically depended on when you got into v4 as to whether you could or not. This is starting to become more reasonable again in v4 (2002-3, 2003-15). However, in v6, it is still problematic. As such, the current policy proposal is an attempt to bring similar sanity and capabilities to the v6 addressing policy. >>> I think people use NAT as an abstraction layer. It's just that they >>> never had to realise it as there was no option. >>> >> There's probably some truth to this. However, the abstraction layer >> does >> come at some cost, and, I know of a number of organizations that would >> really >> rather not use NAT. They've accepted it in a v4 world because they >> didn't >> see any alternative. They will not accept it in a v6 world. > > I think they are very few. Extremely few actually. > Then we can agree to disagree here. Unfortunately, you may be right, afterall, lots of enterprises have accepted an Operating system so thoroughly insecure that CPU manufacturers are now advertising on-chip virus protection as if it were a feature. >> For multi6, not only do I have >> to support its requirements, but, it has to be implemented at virtually >> every site I'm trying to talk to as well. > > In order for you to take full advantage - yes. But not for it to work > in general. > I guess that depends on your definition of work. As near as I could tell, for any of the flow survivability features to work, it required implementation at both ends. >>>> However, none of that is relevant to the proposal at hand, since ARIN >>>> can revoke or reclaim any IPv6 assignments in the future if >>>> necessary. >>> >>> "Seeing is believing". >>> >> That's a tautology. You're saying you don't want to issue PI space in >> v6 >> because you don't want a swamp, but, you say the only way to believe >> that >> a swamp can be prevented is to see PI space issued and reclaimed >> without >> creating a swamp. So, I will take your statement "Seeing is >> believing" as >> an endorsement for at least conducting the experiment. > > You are arguing that ULAs can't be traced if they are leaked, but that > we could reclaim PI space. I think you can trace ULAs, I am not as > convinced we can reclaim PI space. But I really hope I would be wrong > on that one. > I didn't argue they couldn't be traced. I argued that it would be difficult to impossible to identify ownership on non-registered ULA. I argued that registered ULA would be de facto PI. I stand by both of these statements. I believe if there were community consensus around reclaiming v6 PI allocations under this policy, it could easily be done. Perhaps not as quickly as you would like, but, it can be done. >> Over time, any site which filters more aggressively than the RIR MAU >> boundary >> will be able to reach fewer and fewer sites. I don't think this small >> minority >> of sites justifies preserving a larger boundary. > > In v4 they have seen more and more scenic routing, not less > reachability. My point was that we have no effective control over the > filtering polices with ISPs. And the larger the ISP, the less > influence. > Agreed... Nothing in my proposal claims otherwise or attempts to address this in any way. Orgs that are concerned about ISPs filtering more aggressively than the RIR MAU are welcome to use PA space and accept all the headaches that implies. Orgs that are less concerned should be able to use this policy to get PI space. It's all about giving the Org the choice about what best meets their need. 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 michel at arneill-py.sacramento.ca.us Tue Dec 14 20:50:34 2004 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 14 Dec 2004 17:50:34 -0800 Subject: [ppml] Proposed Policy: PI assignments for V6 Message-ID: >> Michel Py wrote: >> Nevertheless, your WG still >> hasn't produced anything yet and it's been 10 years. > Kurt Erik Lindqvist wrote: > It's been 10 years for IPv6, and 4 years (or 3.5 of > whatever) for multi6. Kurtis, [I hope you do not take this personally as this is absolutely not the intent] You know as well as I do that the multi6 work has started _way_ before the multi6 WG (in the then-named IPNG WG) and the politics behind it. The multi6 work _has indeed_ started some 10 years ago, as proof there are IETF IPv6 documents dating back to 1996 such as: http://www.watersprings.org/pub/id/draft-shand-ipv6-multi-homing-01.txt There also is some non-IETF work from even earlier (see below) As of actual proposals, Mike O'Dell's GSE is 1997 (for the record, it has been said that MHAP was a son of GSE, it's not) http://arneill-py.sacramento.ca.us/ipv6mh/draft-ipng-gseaddr-00.txt http://www.watersprings.org/pub/id/draft-durand-gse+-00.txt Other stuff such as: http://playground.sun.com/pub/ipng/html/presentations/Sep99/PDF/deering- multihome.PDF can be found here: http://arneill-py.sacramento.ca.us/ipv6mh Somehow related note to Geoff Huston: as I dug into the historical dept. below are some docs possibly relevant to what you are looking for (if you don't have them already): http://arneill-py.sacramento.ca.us/ipv6mh/francis94comparison.pdf http://arneill-py.sacramento.ca.us/ipv6mh/map-n-encap.pdf http://arneill-py.sacramento.ca.us/ipv6mh/metro-addr-slides-jul95.pdf > Kurt Erik Lindqvist wrote: > We have a problem. We have recognised, now let's deal with it. Kurtis, we heard this song for the last 10 years as demonstrated above and below. > We do have a single proposal since D.C. It's not > a protocol yet, as that is left to another area. > It's not a WG document yet, as we are waiting for > people to submit the changes. Translation: another 4 years at best before initial publication, another x years at best before initial tests. What? 4 years? YES, FOUR #%^$@ YEARS. Want proof? It's in the pudding, look below! > IPv4 Multihoming Motivation, Practices and Limitations > draft-ietf-multi6-v4-multihoming-02 This has been on the since the original charter for ~4 years, still not published. I know it was already 2 years overdue when you inherited it but nevertheless it's a WG doc for the WG you co-chair. So please don't tell me my time lines are unrealistic. Kurtis, the following are facts: You don't even have a -00 as of today, a -00 has never been a solution anyway. Multi6 and previous works have not produced anything in the last 10 years, and will not produce anything before the next x+ years. _FACTS_. Asking for some extra years _more_ is not an option available to you anymore. Not after 10 years. IF you ever produce something, then we'll be eager to look at it when you ACTUALLY have it. Michel. From kurtis at kurtis.pp.se Thu Dec 16 02:18:18 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 16 Dec 2004 08:18:18 +0100 Subject: [ppml] Proposed Policy: PI assignments for V6 In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-12-15, at 02.50, Michel Py wrote: >>> Michel Py wrote: >>> Nevertheless, your WG still >>> hasn't produced anything yet and it's been 10 years. > >> Kurt Erik Lindqvist wrote: >> It's been 10 years for IPv6, and 4 years (or 3.5 of >> whatever) for multi6. > > Kurtis, > > [I hope you do not take this personally as this is absolutely not the > intent] I am not. But I think you are bashing the IETF efforts for the sake of bashing the IETF efforts. > The multi6 work _has indeed_ started some 10 years ago, as proof there > are IETF IPv6 documents dating back to 1996 such as: > http://www.watersprings.org/pub/id/draft-shand-ipv6-multi-homing-01.txt > There also is some non-IETF work from even earlier (see below) That multihoming for IPv6 was discussed even before we had IPv6, I will agree to. But for me the term multi6 refers explicitly to a WG in the IETF. >> We do have a single proposal since D.C. It's not >> a protocol yet, as that is left to another area. >> It's not a WG document yet, as we are waiting for >> people to submit the changes. > > Translation: another 4 years at best before initial publication, > another > x years at best before initial tests. > > What? 4 years? YES, FOUR #%^$@ YEARS. Want proof? It's in the pudding, > look below! This is pure guess work. I think you will have publication faster than 4 years. >> IPv4 Multihoming Motivation, Practices and Limitations >> draft-ietf-multi6-v4-multihoming-02 > > This has been on the since the original charter for ~4 years, still not > published. I know it was already 2 years overdue when you inherited it > but nevertheless it's a WG doc for the WG you co-chair. So please don't > tell me my time lines are unrealistic. A document will only move as fast as it's editors works on it. It was decided that I take over as editor, and the final version would have been posted next week, but I will be on vacation so look for this during the holidays. Besides, this document is documenting history and have nothing to do with a solution out of multi6. > Kurtis, the following are facts: You don't even have a -00 as of today, > a -00 has never been a solution anyway. Multi6 and previous works have > not produced anything in the last 10 years, and will not produce > anything before the next x+ years. _FACTS_. > > Asking for some extra years _more_ is not an option available to you > anymore. Not after 10 years. IF you ever produce something, then we'll > be eager to look at it when you ACTUALLY have it. This is nonsense. I suspect you haven't been following the multi6 list or work being done. Will there be working implementations tomorrow? No. Will it take time? Yes. How long? Don't know. Noone does. So Michel, either you can sit around, complain and be bitter - or you can take part in the discussions, and help shape the outcome. You have for quite some time chosen the first. I am sorry for that. I hope you don't take this personal, but I think your comments are not reflecting the true state of work in the multi6 WG. As for implementations, neither you or me knows the timeline. - - kurtis - / Who is now going off-line for 10 days and won't be able to reply. -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQcE2waarNKXTPFCVEQIeTgCcDH/AH1EOGcU9eHN4VTzhA3s+go4AoKX1 /XpxexZbF/EPw3AYcdoHt1jo =SB+0 -----END PGP SIGNATURE----- From kurtis at kurtis.pp.se Thu Dec 16 02:08:28 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 16 Dec 2004 08:08:28 +0100 Subject: [ppml] Proposed Policy: PI assignments for V6 In-Reply-To: <2147483647.1103010695@imac-en0.delong.sj.ca.us> References: <81464318-47BA-11D9-97A6-000D93ACD0FE@it> <2147483647.1102335801@imac-en0.delong.sj.ca.us> <9D4297F2-483D-11D9-97A6-000D93ACD0FE@it.uc3m.es> <2147483647.1102413506@imac-en0.delong.sj.ca.us> <03b001c4dd87$ce53ac10$6801a8c0@stephen> <4DC3628E-4ABB-11D9-9E81-000A95928574@kurtis.pp.se> <1608226182.1102848781@imac-en0.delong.sj.ca.us> <2147483647.1103010695@imac-en0.delong.sj.ca.us> Message-ID: <493A7A50-4F31-11D9-B94E-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (As I am going to be off-line for 10 days after this, I will leave the rest of the points and just pick this one up) On 2004-12-14, at 16.51, Owen DeLong wrote: >> You are arguing that ULAs can't be traced if they are leaked, but that >> we could reclaim PI space. I think you can trace ULAs, I am not as >> convinced we can reclaim PI space. But I really hope I would be wrong >> on that one. >> > I didn't argue they couldn't be traced. I argued that it would be > difficult > to impossible to identify ownership on non-registered ULA. I argued > that > registered ULA would be de facto PI. I stand by both of these > statements. > I believe if there were community consensus around reclaiming v6 PI > allocations under this policy, it could easily be done. Perhaps not as > quickly as you would like, but, it can be done. As I said in an earlier note, if (and I still hope not) this proposal gets support, it really need to address the reclaiming policy, when, how, and why. Saying "it can be done", and then leaving that for the future will get us down the IPv4 road. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQcE0eKarNKXTPFCVEQLSMwCgjTC4YKcjeCIRhPmMoU7JlL1uLO8An0rX +MVavkmlJv4+k78aFpY73IEc =HPWd -----END PGP SIGNATURE----- From randy at psg.com Thu Dec 16 07:30:53 2004 From: randy at psg.com (Randy Bush) Date: Thu, 16 Dec 2004 04:30:53 -0800 Subject: [ppml] Proposed Policy: PI assignments for V6 References: Message-ID: <16833.32765.814376.380794@ran.psg.com> > That multihoming for IPv6 was discussed even before we had IPv6, I will > agree to. obviously not well enough randy From memsvcs at arin.net Thu Dec 16 17:30:59 2004 From: memsvcs at arin.net (Member Services) Date: Thu, 16 Dec 2004 17:30:59 -0500 (EST) Subject: [ppml] Policy Proposal 2002-2 Experimental Internet Resource Allocations - implemented Message-ID: The following policy proposal has been adopted in the ARIN region and takes effect today, December 16, 2004: Policy Proposal 2002-2: Experimental Internet Resource Allocations http://www.arin.net/policy/2002_2.html As part of the implementation of this policy, the ARIN Fee Schedule has been updated with an Experimental Allocations section. The ARIN Fee Schedule can be found at http://www.arin.net/registration/fee_schedule.html. A new template has been created, the Experimental Allocation Template, which can be found at http://www.arin.net/library/templates/experimental.txt. Regards, Member Services American Registry for Internet Numbers (ARIN) From memsvcs at arin.net Thu Dec 16 17:33:37 2004 From: memsvcs at arin.net (Member Services) Date: Thu, 16 Dec 2004 17:33:37 -0500 (EST) Subject: [ppml] Policy Proposal 2003-4 IPv6 Policy Changes - implemented Message-ID: The following policy proposal has been adopted in the ARIN region and takes effect today, December 16, 2004: Policy Proposal 2003-4: IPv6 Policy Changes http://www.arin.net/policy/2003_4.html Regards, Member Services American Registry for Internet Numbers (ARIN) From memsvcs at arin.net Thu Dec 16 17:38:42 2004 From: memsvcs at arin.net (Member Services) Date: Thu, 16 Dec 2004 17:38:42 -0500 (EST) Subject: [ppml] Number Resource Policy Manual - version 2004.2 Message-ID: The ARIN Number Resource Policy Manual (NRPM), version 2004.2, is effective as of today, December 16, 2004. This version supersedes all previous versions. See Appendix A of the NRPM for detailed information regarding changes to the manual. The NRPM can be found at: http://www.arin.net/policy/index.html Appendix A can be found at: http://www.arin.net/policy/nrpm_changelog.html Regards, Member Services American Registry for Internet Numbers (ARIN) From memsvcs at arin.net Thu Dec 16 17:45:11 2004 From: memsvcs at arin.net (Member Services) Date: Thu, 16 Dec 2004 17:45:11 -0500 (EST) Subject: [ppml] Policy Proposal 2004-3: Global Addresses for Private Network Inter-Connectivity - revised Message-ID: This policy proposal was previously discussed on this mailing list and at the ARIN XIII and XIV Public Policy Meetings. Based on the feedback received from those discussions, the language of this policy proposal has been revised. This proposal is open for discussion on this mailing list and will be on the agenda at the Public Policy Meeting in April, 2005. The current policy proposal text is provided below and is also available at http://www.arin.net/policy/2004_3.html. Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2004-3: Global Addresses for Private Network Inter-Connectivity Policy statement: End-users not currently connected to an ISP and/or not planning to be connected to the Internet are encouraged to use private IP address numbers reserved for non-connected networks (see RFC 1918). When private, non-connected networks require interconnectivity and the private IP address numbers are ineffective, globally unique addresses may be requested and used to provide this interconnectivity. This text supersedes section 4.3.5 Non-connected Networks. Rationale: In order to provide clarification for current ARIN practice concerning the use of Global Addresses for private network interconnectivity, the change above to the ARIN Number Resource Policy Manual is proposed. Current wording of Section 4.3.5 Non-connected Networks: End-users not currently connected to an ISP and/or plan not to be connected to the Internet are encouraged to use private IP numbers reserved for non-connected networks (see RFC 1918 ). From Michael.Dillon at radianz.com Fri Dec 17 05:50:38 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Fri, 17 Dec 2004 10:50:38 +0000 Subject: [ppml] Policy Proposal 2004-3: Global Addresses for Private Network Inter-Connectivity - revised In-Reply-To: Message-ID: > In order to provide clarification for current ARIN practice concerning the > use of Global Addresses for private network interconnectivity, the change > above to the ARIN Number Resource Policy Manual is proposed. Just to clarify your clarification... It appears to be saying that the proposed policy does not make any change in the way in which ARIN evaluates address applications, it merely clarifies the policy which has been in place since RFC 2050 [section 3 a)] so that people are not confused. Right? --Michael Dillon From billd at cait.wustl.edu Fri Dec 17 08:32:31 2004 From: billd at cait.wustl.edu (Bill Darte) Date: Fri, 17 Dec 2004 07:32:31 -0600 Subject: [ppml] Policy Proposal 2004-3: Global Addresses for Private N etwork Inter-Connectivity - revised Message-ID: <50C9C45A7E8DCE41A19F7A94715BABFD02A61A@kronos.cait.wustl.edu> Michael, It makes an explicit statement that global IP addresses have been and can be used for private network connectivity when private addresses fail to satisfy the need. As such, it is NOT new policy, but a proposal to change the policy statement to reflect an aspect of current policy that has caused misinterpretation/confusion. All current ARIN process/practice for request analysis/approvals are still place with no change. Bill Darte ARIN Advisory Council 314 935-7575 > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Michael.Dillon at radianz.com > Sent: Friday, December 17, 2004 4:51 AM > To: ppml at arin.net > Subject: Re: [ppml] Policy Proposal 2004-3: Global Addresses > for Private Network Inter-Connectivity - revised > > > > In order to provide clarification for current ARIN practice > concerning > the > > use of Global Addresses for private network interconnectivity, the > change > > above to the ARIN Number Resource Policy Manual is proposed. > > Just to clarify your clarification... > > It appears to be saying that the proposed policy > does not make any change in the way in which > ARIN evaluates address applications, it merely > clarifies the policy which has been in place > since RFC 2050 [section 3 a)] so that people are > not confused. > > Right? > > --Michael Dillon > >