Re: [address-policy-wg] PA/PI unification PI Address Space
Hi, (subject changed and in-reply-to: removed, to make it clear that this is really a different thread) On Wed, Jun 26, 2013 at 11:34:56AM +0000, Sonderegger Olaf ABRAXAS INFORMATIK AG wrote:
It would be nice if Address Policy WG could continue with the idea about removing status "Provider Aggregatable" (PA) and "Provider Independent" (PI). Are there any plans?
For IPv4, let's wait until Tore's proposal has come to a conclusion, as it's very hard to do two large-scale changes to the same text at the same time. For IPv6, it's still sitting on my lap, and I need to restart the process - thanks for the reminder. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
On Wed, 26 Jun 2013, Gert Doering wrote:
Hi,
(subject changed and in-reply-to: removed, to make it clear that this is really a different thread)
On Wed, Jun 26, 2013 at 11:34:56AM +0000, Sonderegger Olaf ABRAXAS INFORMATIK AG wrote:
It would be nice if Address Policy WG could continue with the idea about removing status "Provider Aggregatable" (PA) and "Provider Independent" (PI). Are there any plans?
For IPv4, let's wait until Tore's proposal has come to a conclusion, as it's very hard to do two large-scale changes to the same text at the same time.
For IPv6, it's still sitting on my lap, and I need to restart the process - thanks for the reminder.
Just let us know if you need volonteers or cheering. Best Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm
1+ If i can, i will help. -----Original Message----- From: Daniel Stolpe [mailto:stolpe@resilans.se] Sent: Mittwoch, 26. Juni 2013 14:58 To: Gert Doering Cc: Sonderegger Olaf ABRAXAS INFORMATIK AG; address-policy-wg@ripe.net Subject: Re: [address-policy-wg] PA/PI unification PI Address Space On Wed, 26 Jun 2013, Gert Doering wrote:
Hi,
(subject changed and in-reply-to: removed, to make it clear that this is really a different thread)
On Wed, Jun 26, 2013 at 11:34:56AM +0000, Sonderegger Olaf ABRAXAS INFORMATIK AG wrote:
It would be nice if Address Policy WG could continue with the idea about removing status "Provider Aggregatable" (PA) and "Provider Independent" (PI). Are there any plans?
For IPv4, let's wait until Tore's proposal has come to a conclusion, as it's very hard to do two large-scale changes to the same text at the same time.
For IPv6, it's still sitting on my lap, and I need to restart the process - thanks for the reminder.
Just let us know if you need volonteers or cheering. Best Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm
Hi, On Wed, Jun 26, 2013 at 02:57:45PM +0200, Daniel Stolpe wrote:
[PA/PI unification proposal]
For IPv6, it's still sitting on my lap, and I need to restart the process - thanks for the reminder.
Just let us know if you need volonteers or cheering.
Since Sander already mentioned it, I now need to write down what I had in mind :-) The original proposal (text appended below) received quite positive feedback, so I think we want to go ahead with that. What is necessary next is to actually write this up in the form of a RIPE policy document - and since the secondary effects of this change are quite radical, I think it leads to "write a new policy document for the new IPv6 address policy in RIPE, after that change, taking into account most of the questions that have come up" (like: what are the rules for a LIR to receive multiple "blocks of addresses"?). I can't seem to find enough "undisturbed time" to actually get going with this, so my idea was to form a *small* editorial team, maybe 3-5 people, who would work together with Sander, me and Emilio to write this new policy document (you write, we review :) ), and if we all agree that "yes, this is good!" it will be presented as a formal policy proposal to the WG, possibly leading to further tweaks of the text. The group writing this should be people that have had first-hand experience with address requests, customer confusion about PA and PI, with the RIPE policy process - and who have nerves of steel, to actually fight for it in the ensueing arguments on the list... So... volunteers? :-) Gert Doering -- APWG chair ---------------------------------------------------------------------- Motivation: why? ---------------- - PA and PI are just different labels for "IPv6 addresses" ... but with different strings attached: - PI must not be used for 3rd party assignments (problem for hosting providers) - only single PA allocation for LIRs possible, even if multiple independent networks exist - network structure and operation is very different these days than at the time where the PA/PI distinction was made. The boundaries between networks, different operators and different services are not as clear as they used to be... - the classic distinction "PA is for ISPs and their access customers" "PI is for enterprises that do not do ISP-like business" has been overcome by reality, and there are no longer clear borders between "ISP", "enterprise" and "end-customer" networks - Network addresses are for *numbering network devices*. Limiting what someone is allowed to do with certain addresses creates confusion. Constantly having to tweak policy to work around this is the wrong solution. Goals and Caveats ----------------- - encourage IPv6 deployment - be flexible enough to accommodate both typical and non-typical network- and business models - do not encourage assignment of /64 or single addresses to end users - do not encourage excessive routing table growth - encourage proper documentation and discourage lying to the RIPE NCC to wiggle around policy restrictions The Proposal ------------ - abandon distinction between PA (allocation) and PI (assignment) - everything is just "numbers" - RIPE NCC hands out "block(s) of numbers" to "users of numbers" - see below for answers on the fine print... Who get's address space? ------------------------ - existing model is kept: LIRs as distribution point for address space - either to "the LIR organization" - classic model: "LIR is part of the Internet Provider business" - or via the LIR to "the entity that wants to use the space and take responsibility for it" (sponsoring LIR), keeping the contractual requirements of 2007-01 - "Direct Assignment Users" members could still be possible, but "every NCC member is an LIR" would simplify things further (see "Costs" section) Amount of space per "block of numbers"? --------------------------------------- - /48 (or larger with justification) by default - /32.../29 (or larger with justification) allowed when planning to assign to 3rd parties - multiple "blocks of numbers" to or via a single LIR allowed and expected to be a frequently seen usage case Allocation from well-known ranges for anything that people might want to treat specially in their routing policy (former "special case" and PI policies): - IXP - Root DNS - Anycast DNS - /33.../48 blocks Cost? ----- - determined by AGM, but we can discuss models here and provide recommendations to AGM and NCC board, e.g.: - base cost per year per LIR - yearly recurring cost "per block of numbers", independent of size(!), reflecting the cost of handling the address space request, documentation, RIPE database, etc., which increase if you need "many blocks" Multiple blocks per LIR? ------------------------ - since there would no longer be any difference between PA and PI, "more than one block going to a single LIR" would be a typical case - so it needs to be permitted - "get any number of blocks that people are asking for" is not likely to get consensus due to pressure on the routing system - proposal for compromise: ``one "block of numbers" per "network"'' - needs workable definition for "network": - interconnected network - operated by the same entity - operated as a layer 3 network - be flexible in allowing multiple blocks, but don't *require* anyone to actually ask for multiple number blocks if they are happy with using the same address block for multiple networks/sites/... - problem cases to keep in mind, leading to this definition - ISPs providing L3 services on top of other ISPs' Layer 2 infrastructure - single LIRs providing addresses to two independent Layer 3 networks that are not directly connected - e.g. due to political (commercial/NREN), legal or geographical reasons - "classical PI" type connections - end users with independent numbers - Multiple L3 providers providing address space to a single user must be allowed (multi-homing, special-purpose networks, etc.) -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Hi Gert, I have very limited experience of writing RIPE policy documents (but you have to start somewhere, right?) but I think I can check the other boxes. Hand up. On Thu, 27 Jun 2013, Gert Doering wrote:
Hi,
On Wed, Jun 26, 2013 at 02:57:45PM +0200, Daniel Stolpe wrote:
[PA/PI unification proposal]
For IPv6, it's still sitting on my lap, and I need to restart the process - thanks for the reminder.
Just let us know if you need volonteers or cheering.
Since Sander already mentioned it, I now need to write down what I had in mind :-)
The original proposal (text appended below) received quite positive feedback, so I think we want to go ahead with that.
What is necessary next is to actually write this up in the form of a RIPE policy document - and since the secondary effects of this change are quite radical, I think it leads to "write a new policy document for the new IPv6 address policy in RIPE, after that change, taking into account most of the questions that have come up" (like: what are the rules for a LIR to receive multiple "blocks of addresses"?).
I can't seem to find enough "undisturbed time" to actually get going with this, so my idea was to form a *small* editorial team, maybe 3-5 people, who would work together with Sander, me and Emilio to write this new policy document (you write, we review :) ), and if we all agree that "yes, this is good!" it will be presented as a formal policy proposal to the WG, possibly leading to further tweaks of the text.
The group writing this should be people that have had first-hand experience with address requests, customer confusion about PA and PI, with the RIPE policy process - and who have nerves of steel, to actually fight for it in the ensueing arguments on the list...
So... volunteers? :-)
Gert Doering -- APWG chair
---------------------------------------------------------------------- Motivation: why? ---------------- - PA and PI are just different labels for "IPv6 addresses" ... but with different strings attached: - PI must not be used for 3rd party assignments (problem for hosting providers) - only single PA allocation for LIRs possible, even if multiple independent networks exist - network structure and operation is very different these days than at the time where the PA/PI distinction was made. The boundaries between networks, different operators and different services are not as clear as they used to be... - the classic distinction "PA is for ISPs and their access customers" "PI is for enterprises that do not do ISP-like business" has been overcome by reality, and there are no longer clear borders between "ISP", "enterprise" and "end-customer" networks
- Network addresses are for *numbering network devices*. Limiting what someone is allowed to do with certain addresses creates confusion. Constantly having to tweak policy to work around this is the wrong solution.
Goals and Caveats ----------------- - encourage IPv6 deployment - be flexible enough to accommodate both typical and non-typical network- and business models - do not encourage assignment of /64 or single addresses to end users - do not encourage excessive routing table growth - encourage proper documentation and discourage lying to the RIPE NCC to wiggle around policy restrictions
The Proposal ------------ - abandon distinction between PA (allocation) and PI (assignment) - everything is just "numbers" - RIPE NCC hands out "block(s) of numbers" to "users of numbers" - see below for answers on the fine print...
Who get's address space? ------------------------ - existing model is kept: LIRs as distribution point for address space - either to "the LIR organization" - classic model: "LIR is part of the Internet Provider business" - or via the LIR to "the entity that wants to use the space and take responsibility for it" (sponsoring LIR), keeping the contractual requirements of 2007-01 - "Direct Assignment Users" members could still be possible, but "every NCC member is an LIR" would simplify things further (see "Costs" section)
Amount of space per "block of numbers"? --------------------------------------- - /48 (or larger with justification) by default - /32.../29 (or larger with justification) allowed when planning to assign to 3rd parties - multiple "blocks of numbers" to or via a single LIR allowed and expected to be a frequently seen usage case
Allocation from well-known ranges for anything that people might want to treat specially in their routing policy (former "special case" and PI policies): - IXP - Root DNS - Anycast DNS - /33.../48 blocks
Cost? ----- - determined by AGM, but we can discuss models here and provide recommendations to AGM and NCC board, e.g.: - base cost per year per LIR - yearly recurring cost "per block of numbers", independent of size(!), reflecting the cost of handling the address space request, documentation, RIPE database, etc., which increase if you need "many blocks"
Multiple blocks per LIR? ------------------------ - since there would no longer be any difference between PA and PI, "more than one block going to a single LIR" would be a typical case - so it needs to be permitted - "get any number of blocks that people are asking for" is not likely to get consensus due to pressure on the routing system - proposal for compromise: ``one "block of numbers" per "network"'' - needs workable definition for "network": - interconnected network - operated by the same entity - operated as a layer 3 network - be flexible in allowing multiple blocks, but don't *require* anyone to actually ask for multiple number blocks if they are happy with using the same address block for multiple networks/sites/...
- problem cases to keep in mind, leading to this definition - ISPs providing L3 services on top of other ISPs' Layer 2 infrastructure - single LIRs providing addresses to two independent Layer 3 networks that are not directly connected - e.g. due to political (commercial/NREN), legal or geographical reasons - "classical PI" type connections - end users with independent numbers - Multiple L3 providers providing address space to a single user must be allowed (multi-homing, special-purpose networks, etc.)
-- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Best Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm
Hi Daniel, Hi Gert, Hi Sander I have same experience level as Daniel, but I will support you as much as I can. Do you have any collaboration platform to write together this policy? Or how do you normally start? Olaf -----Original Message----- From: Daniel Stolpe [mailto:stolpe@resilans.se] Sent: Donnerstag, 27. Juni 2013 14:56 To: Gert Doering Cc: Sonderegger Olaf ABRAXAS INFORMATIK AG; address-policy-wg@ripe.net Subject: Re: [address-policy-wg] PA/PI unification IPv6 Address Space Hi Gert, I have very limited experience of writing RIPE policy documents (but you have to start somewhere, right?) but I think I can check the other boxes. Hand up. On Thu, 27 Jun 2013, Gert Doering wrote:
Hi,
On Wed, Jun 26, 2013 at 02:57:45PM +0200, Daniel Stolpe wrote:
[PA/PI unification proposal]
For IPv6, it's still sitting on my lap, and I need to restart the process - thanks for the reminder.
Just let us know if you need volonteers or cheering.
Since Sander already mentioned it, I now need to write down what I had in mind :-)
The original proposal (text appended below) received quite positive feedback, so I think we want to go ahead with that.
What is necessary next is to actually write this up in the form of a RIPE policy document - and since the secondary effects of this change are quite radical, I think it leads to "write a new policy document for the new IPv6 address policy in RIPE, after that change, taking into account most of the questions that have come up" (like: what are the rules for a LIR to receive multiple "blocks of addresses"?).
I can't seem to find enough "undisturbed time" to actually get going with this, so my idea was to form a *small* editorial team, maybe 3-5 people, who would work together with Sander, me and Emilio to write this new policy document (you write, we review :) ), and if we all agree that "yes, this is good!" it will be presented as a formal policy proposal to the WG, possibly leading to further tweaks of the text.
The group writing this should be people that have had first-hand experience with address requests, customer confusion about PA and PI, with the RIPE policy process - and who have nerves of steel, to actually fight for it in the ensueing arguments on the list...
So... volunteers? :-)
Gert Doering -- APWG chair
---------------------------------------------------------------------- Motivation: why? ---------------- - PA and PI are just different labels for "IPv6 addresses" ... but with different strings attached: - PI must not be used for 3rd party assignments (problem for hosting providers) - only single PA allocation for LIRs possible, even if multiple independent networks exist - network structure and operation is very different these days than at the time where the PA/PI distinction was made. The boundaries between networks, different operators and different services are not as clear as they used to be... - the classic distinction "PA is for ISPs and their access customers" "PI is for enterprises that do not do ISP-like business" has been overcome by reality, and there are no longer clear borders between "ISP", "enterprise" and "end-customer" networks
- Network addresses are for *numbering network devices*. Limiting what someone is allowed to do with certain addresses creates confusion. Constantly having to tweak policy to work around this is the wrong solution.
Goals and Caveats ----------------- - encourage IPv6 deployment - be flexible enough to accommodate both typical and non-typical network- and business models - do not encourage assignment of /64 or single addresses to end users - do not encourage excessive routing table growth - encourage proper documentation and discourage lying to the RIPE NCC to wiggle around policy restrictions
The Proposal ------------ - abandon distinction between PA (allocation) and PI (assignment) - everything is just "numbers" - RIPE NCC hands out "block(s) of numbers" to "users of numbers" - see below for answers on the fine print...
Who get's address space? ------------------------ - existing model is kept: LIRs as distribution point for address space - either to "the LIR organization" - classic model: "LIR is part of the Internet Provider business" - or via the LIR to "the entity that wants to use the space and take responsibility for it" (sponsoring LIR), keeping the contractual requirements of 2007-01 - "Direct Assignment Users" members could still be possible, but "every NCC member is an LIR" would simplify things further (see "Costs" section)
Amount of space per "block of numbers"? --------------------------------------- - /48 (or larger with justification) by default - /32.../29 (or larger with justification) allowed when planning to assign to 3rd parties - multiple "blocks of numbers" to or via a single LIR allowed and expected to be a frequently seen usage case
Allocation from well-known ranges for anything that people might want to treat specially in their routing policy (former "special case" and PI policies): - IXP - Root DNS - Anycast DNS - /33.../48 blocks
Cost? ----- - determined by AGM, but we can discuss models here and provide recommendations to AGM and NCC board, e.g.: - base cost per year per LIR - yearly recurring cost "per block of numbers", independent of size(!), reflecting the cost of handling the address space request, documentation, RIPE database, etc., which increase if you need "many blocks"
Multiple blocks per LIR? ------------------------ - since there would no longer be any difference between PA and PI, "more than one block going to a single LIR" would be a typical case - so it needs to be permitted - "get any number of blocks that people are asking for" is not likely to get consensus due to pressure on the routing system - proposal for compromise: ``one "block of numbers" per "network"'' - needs workable definition for "network": - interconnected network - operated by the same entity - operated as a layer 3 network - be flexible in allowing multiple blocks, but don't *require* anyone to actually ask for multiple number blocks if they are happy with using the same address block for multiple networks/sites/...
- problem cases to keep in mind, leading to this definition - ISPs providing L3 services on top of other ISPs' Layer 2 infrastructure - single LIRs providing addresses to two independent Layer 3 networks that are not directly connected - e.g. due to political (commercial/NREN), legal or geographical reasons - "classical PI" type connections - end users with independent numbers - Multiple L3 providers providing address space to a single user must be allowed (multi-homing, special-purpose networks, etc.)
-- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Best Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm
Hi Gert, everyone, I'd like to volunteer and join this editorial team. I used to be an IPRA so I've got first-hand experience with address requests and the whole process. Count on me, I hope we can get this policy proposal written by the next RIPE Meeting. cheers, Elvis On 6/27/13 4:32 PM, Sonderegger Olaf ABRAXAS INFORMATIK AG wrote:
Hi Daniel, Hi Gert, Hi Sander
I have same experience level as Daniel, but I will support you as much as I can.
Do you have any collaboration platform to write together this policy? Or how do you normally start?
Olaf
-----Original Message----- From: Daniel Stolpe [mailto:stolpe@resilans.se] Sent: Donnerstag, 27. Juni 2013 14:56 To: Gert Doering Cc: Sonderegger Olaf ABRAXAS INFORMATIK AG; address-policy-wg@ripe.net Subject: Re: [address-policy-wg] PA/PI unification IPv6 Address Space
Hi Gert,
I have very limited experience of writing RIPE policy documents (but you have to start somewhere, right?) but I think I can check the other boxes.
Hand up.
On Thu, 27 Jun 2013, Gert Doering wrote:
Hi,
On Wed, Jun 26, 2013 at 02:57:45PM +0200, Daniel Stolpe wrote:
[PA/PI unification proposal]
For IPv6, it's still sitting on my lap, and I need to restart the process - thanks for the reminder.
Just let us know if you need volonteers or cheering.
Since Sander already mentioned it, I now need to write down what I had in mind :-)
The original proposal (text appended below) received quite positive feedback, so I think we want to go ahead with that.
What is necessary next is to actually write this up in the form of a RIPE policy document - and since the secondary effects of this change are quite radical, I think it leads to "write a new policy document for the new IPv6 address policy in RIPE, after that change, taking into account most of the questions that have come up" (like: what are the rules for a LIR to receive multiple "blocks of addresses"?).
I can't seem to find enough "undisturbed time" to actually get going with this, so my idea was to form a *small* editorial team, maybe 3-5 people, who would work together with Sander, me and Emilio to write this new policy document (you write, we review :) ), and if we all agree that "yes, this is good!" it will be presented as a formal policy proposal to the WG, possibly leading to further tweaks of the text.
The group writing this should be people that have had first-hand experience with address requests, customer confusion about PA and PI, with the RIPE policy process - and who have nerves of steel, to actually fight for it in the ensueing arguments on the list...
So... volunteers? :-)
Gert Doering -- APWG chair
---------------------------------------------------------------------- Motivation: why? ---------------- - PA and PI are just different labels for "IPv6 addresses" ... but with different strings attached: - PI must not be used for 3rd party assignments (problem for hosting providers) - only single PA allocation for LIRs possible, even if multiple independent networks exist - network structure and operation is very different these days than at the time where the PA/PI distinction was made. The boundaries between networks, different operators and different services are not as clear as they used to be... - the classic distinction "PA is for ISPs and their access customers" "PI is for enterprises that do not do ISP-like business" has been overcome by reality, and there are no longer clear borders between "ISP", "enterprise" and "end-customer" networks
- Network addresses are for *numbering network devices*. Limiting what someone is allowed to do with certain addresses creates confusion. Constantly having to tweak policy to work around this is the wrong solution.
Goals and Caveats ----------------- - encourage IPv6 deployment - be flexible enough to accommodate both typical and non-typical network- and business models - do not encourage assignment of /64 or single addresses to end users - do not encourage excessive routing table growth - encourage proper documentation and discourage lying to the RIPE NCC to wiggle around policy restrictions
The Proposal ------------ - abandon distinction between PA (allocation) and PI (assignment) - everything is just "numbers" - RIPE NCC hands out "block(s) of numbers" to "users of numbers" - see below for answers on the fine print...
Who get's address space? ------------------------ - existing model is kept: LIRs as distribution point for address space - either to "the LIR organization" - classic model: "LIR is part of the Internet Provider business" - or via the LIR to "the entity that wants to use the space and take responsibility for it" (sponsoring LIR), keeping the contractual requirements of 2007-01 - "Direct Assignment Users" members could still be possible, but "every NCC member is an LIR" would simplify things further (see "Costs" section)
Amount of space per "block of numbers"? --------------------------------------- - /48 (or larger with justification) by default - /32.../29 (or larger with justification) allowed when planning to assign to 3rd parties - multiple "blocks of numbers" to or via a single LIR allowed and expected to be a frequently seen usage case
Allocation from well-known ranges for anything that people might want to treat specially in their routing policy (former "special case" and PI policies): - IXP - Root DNS - Anycast DNS - /33.../48 blocks
Cost? ----- - determined by AGM, but we can discuss models here and provide recommendations to AGM and NCC board, e.g.: - base cost per year per LIR - yearly recurring cost "per block of numbers", independent of size(!), reflecting the cost of handling the address space request, documentation, RIPE database, etc., which increase if you need "many blocks"
Multiple blocks per LIR? ------------------------ - since there would no longer be any difference between PA and PI, "more than one block going to a single LIR" would be a typical case - so it needs to be permitted - "get any number of blocks that people are asking for" is not likely to get consensus due to pressure on the routing system - proposal for compromise: ``one "block of numbers" per "network"'' - needs workable definition for "network": - interconnected network - operated by the same entity - operated as a layer 3 network - be flexible in allowing multiple blocks, but don't *require* anyone to actually ask for multiple number blocks if they are happy with using the same address block for multiple networks/sites/...
- problem cases to keep in mind, leading to this definition - ISPs providing L3 services on top of other ISPs' Layer 2 infrastructure - single LIRs providing addresses to two independent Layer 3 networks that are not directly connected - e.g. due to political (commercial/NREN), legal or geographical reasons - "classical PI" type connections - end users with independent numbers - Multiple L3 providers providing address space to a single user must be allowed (multi-homing, special-purpose networks, etc.)
-- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Best Regards,
Daniel Stolpe
_________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm
participants (4)
-
Daniel Stolpe -
Elvis Velea -
Gert Doering -
Sonderegger Olaf ABRAXAS INFORMATIK AG