Proposal for change to the IPv4 PI allocation policy
Hello. Following a discussion between some people and the resulting request to bring the discussion here I would like to propose a change to allocation policy for small PI blocks. Today it's a problem that the ISP industry BCP involves filtering all announcements smaller than /24 from BGP, this meaning that a smaller allocation from RIPE is pretty much unusual in the "real world" if you want to be on the public internet. I would therefore like to see a discussion about making it an option to actually get a /24 for routing reasons, disregarding current policy of disallowing routing problems as justification to request an allocation bigger than you might be able to justify from address usage alone. I know I ran into this problem when I first started in the ISP business around 1995, and it's still there, so might it be time to change? People with enough experience will creatively "enhance" (ie lie) address requests to actually reach the /24 size today, and people without experience will make an honest request and then run into practical problems with their newly allocated space when they want to use it in real life, due to it being filtered because it's too small according to industry BCP. This is of course a bad situation either way and I hope it can be rectified. Thanks for your attention. -- Mikael Abrahamsson email: swmike@swm.pp.se
Hello! On Mon, Aug 21, 2006 at 02:31:38PM +0200, Mikael Abrahamsson wrote:
Hello.
Following a discussion between some people and the resulting request to bring the discussion here I would like to propose a change to allocation policy for small PI blocks.
Today it's a problem that the ISP industry BCP involves filtering all announcements smaller than /24 from BGP, this meaning that a smaller allocation from RIPE is pretty much unusual in the "real world" if you want to be on the public internet.
I would therefore like to see a discussion about making it an option to actually get a /24 for routing reasons, disregarding current policy of disallowing routing problems as justification to request an allocation bigger than you might be able to justify from address usage alone.
I know I ran into this problem when I first started in the ISP business around 1995, and it's still there, so might it be time to change? People with enough experience will creatively "enhance" (ie lie) address requests to actually reach the /24 size today, and people without experience will make an honest request and then run into practical problems with their newly allocated space when they want to use it in real life, due to it being filtered because it's too small according to industry BCP. This is of course a bad situation either way and I hope it can be rectified.
Thanks for your attention.
Do You mean PI *ASSIGNMENT*? According to ripe-368, no new PI allocations are allowed. -- Dmitry Kiselev
Hi! Dmitry Kiselev wrote:
Hello!
On Mon, Aug 21, 2006 at 02:31:38PM +0200, Mikael Abrahamsson wrote:
Hello.
Following a discussion between some people and the resulting request to bring the discussion here I would like to propose a change to allocation policy for small PI blocks.
Today it's a problem that the ISP industry BCP involves filtering all announcements smaller than /24 from BGP, this meaning that a smaller allocation from RIPE is pretty much unusual in the "real world" if you want to be on the public internet.
I would therefore like to see a discussion about making it an option to actually get a /24 for routing reasons, disregarding current policy of disallowing routing problems as justification to request an allocation bigger than you might be able to justify from address usage alone.
I know I ran into this problem when I first started in the ISP business around 1995, and it's still there, so might it be time to change? People with enough experience will creatively "enhance" (ie lie) address requests to actually reach the /24 size today, and people without experience will make an honest request and then run into practical problems with their newly allocated space when they want to use it in real life, due to it being filtered because it's too small according to industry BCP. This is of course a bad situation either way and I hope it can be rectified.
Thanks for your attention.
Do You mean PI *ASSIGNMENT*? According to ripe-368, no new PI allocations are allowed.
Yes, it seems to be about assignments. As many persons like to write in blogs and forums - "+1" from me ;) It is a good idea to set formalities as close to real life as possible, and also prevent unexperienced people from troubles. Another good idea is to remove user scaring story about PI is worse routeable than PA from RIPE documents. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
Hi, On Mon, Aug 21, 2006 at 04:54:42PM +0000, Max Tulyev wrote:
Another good idea is to remove user scaring story about PI is worse routeable than PA from RIPE documents.
Well - that won't tell the truth. PI *is* worse to debug if some targets can't be reached (if only because you normally can't run traceroutes from inside customer PI networks). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 94488 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
Hi, Gert Doering wrote:
Hi,
On Mon, Aug 21, 2006 at 04:54:42PM +0000, Max Tulyev wrote:
Another good idea is to remove user scaring story about PI is worse routeable than PA from RIPE documents.
Well - that won't tell the truth.
PI *is* worse to debug if some targets can't be reached (if only because you normally can't run traceroutes from inside customer PI networks).
But what exactly (versus PA) is worse? Same ping and traceroute, same bgp debug, so on. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
Hi, On Wed, Aug 23, 2006 at 06:16:49PM +0000, Max Tulyev wrote:
PI *is* worse to debug if some targets can't be reached (if only because you normally can't run traceroutes from inside customer PI networks).
But what exactly (versus PA) is worse? Same ping and traceroute, same bgp debug, so on.
With PA, you can debug from *your* network - with customer's PI, you can't (normally) run probes (traceroute, ping) from *their* IP addresses - and if your PA works, but their PI is filtered, this makes it harder to debug. Furthermore, /24s tend to be damped more quickly and for longer times than /16... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 94488 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
Max Tulyev wrote:
Hi,
Gert Doering wrote:
Hi,
On Mon, Aug 21, 2006 at 04:54:42PM +0000, Max Tulyev wrote:
Another good idea is to remove user scaring story about PI is worse routeable than PA from RIPE documents. Well - that won't tell the truth.
PI *is* worse to debug if some targets can't be reached (if only because you normally can't run traceroutes from inside customer PI networks).
But what exactly (versus PA) is worse? Same ping and traceroute, same bgp debug, so on.
There is a possibility of people being tight on memory and filtering something like /24 or /23, and then not being able to reach or be reached by a /24 PI, because they also neglected to have a default route to their uplink ... Apart from that, I have not been informed of any problems with /24 or larger PI networks ... But then, RIPE policies would allow for (or even enforce) PI networks smaller than /24 to be assigned - which will most likely NOT be reachable from the Internet ... -gg
Garry Glendown wrote
There is a possibility of people being tight on memory and filtering something like /24 or /23, and then not being able to reach or be reached by a /24 PI, because they also neglected to have a default route to their uplink ... Apart from that, I have not been informed of any problems with /24 or larger PI networks ...
I got near hundred of PIs for my clients at almost all RIPE region, and never hear about any problems with reachability. So it is just scare tale in fact ;)
But then, RIPE policies would allow for (or even enforce) PI networks smaller than /24 to be assigned - which will most likely NOT be reachable from the Internet ...
It is very simple: don't ask PI smaller /24 if you want to announce it worldwide. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
Hi, Mikael Abrahamsson wrote:
Hello.
Following a discussion between some people and the resulting request to bring the discussion here I would like to propose a change to allocation policy for small PI blocks.
Today it's a problem that the ISP industry BCP involves filtering all announcements smaller than /24 from BGP, this meaning that a smaller allocation from RIPE is pretty much unusual in the "real world" if you want to be on the public internet.
I would therefore like to see a discussion about making it an option to actually get a /24 for routing reasons, disregarding current policy of disallowing routing problems as justification to request an allocation bigger than you might be able to justify from address usage alone.
I know I ran into this problem when I first started in the ISP business around 1995, and it's still there, so might it be time to change? People with enough experience will creatively "enhance" (ie lie) address requests to actually reach the /24 size today, and people without experience will make an honest request and then run into practical problems with their newly allocated space when they want to use it in real life, due to it being filtered because it's too small according to industry BCP. This is of course a bad situation either way and I hope it can be rectified.
[...i assume you mean PI _Assignments_...] The problem is, there is no way to tell anyone what prefixes they "have to accept" or not, and i see "the common /24 filter" coming up soon in my crystal ball (once again due to RAM/TCAM restrictions). Filtering everything longer than /24 is just what the majority of ASs do today. Hence, no real way to put such an abitrary number in a policy document. I have no problem with wasting IPv4 space at all, so i won't object any change of the policy to allow people to get a /24 or /23 PI as minimum. But what comes next? Same for IPv6? Let's assign /32 due to routing reasons? (yes, yes, yes! stubborn /32-/35 filter-guys die die die :-) ) Probably we just should keep the policy, but put some more stress on the routing issue in the supporting documents/FAQs, so "new" people don't waste their time requesting 100 IPv4 PI Addresses or so and rant about it after they started realizing that this probably isn't what they wanted in the first place. Though, that doesn't solve the "lieing" problem. ...just my 0.02EUR without thinking about the issue in deep since IPv4 is legacy anyways :-) -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================
On Mon, 21 Aug 2006, Sascha Lenz wrote:
The problem is, there is no way to tell anyone what prefixes they "have to accept" or not, and i see "the common /24 filter" coming up soon in my crystal ball (once again due to RAM/TCAM restrictions). Filtering everything longer than /24 is just what the majority of ASs do today.
Yes, so if you want to use your assignment (excuse me for not understanding the difference) in real life internet, you need /24 or bigger.
Hence, no real way to put such an abitrary number in a policy document.
Well, if you remove the "you cannot use routing reasons for requesting a certain size"-part of the policy, the requesting party can try to justify their request from all aspects that they need to take into account. If the space is not going to be routed, they can use smaller than /24, if they want to multihome and have good justification, then they can request a /24 even if they cannot justify it from a pure IP usage aspect.
I have no problem with wasting IPv4 space at all, so i won't object any
Well, I am not sure it's wasting IPv4 space anyway, as people still get /24 today, but they get it by falsifying information. A lot of people know in practice how to get what they want, but they need to be creative with the truth to get there.
But what comes next? Same for IPv6? Let's assign /32 due to routing reasons? (yes, yes, yes! stubborn /32-/35 filter-guys die die die :-) )
Could we please look at each proposed change on its own merit without expanding the scope to other protocols? I am not sure there is a BCP on IPv6 yet? If there is, I am sure it's much more flexible and can be more easily changed than current IPv4 implementation.
Probably we just should keep the policy, but put some more stress on the routing issue in the supporting documents/FAQs, so "new" people don't waste their time requesting 100 IPv4 PI Addresses or so and rant about it after they started realizing that this probably isn't what they wanted in the first place. Though, that doesn't solve the "lieing" problem.
Exactly. My view is that if you need to multihome on the public internet today you need a /24 in real life to get it to work. If you cannot get that /24, you might as well not get anything at all. Assigning a /27 to them will not solve their problem. I think it's very important to make RIPE, ARIN, AP-NIC et al, who assign addresses to work together with the people doing the routing BCPs. Addresses are nothing without routing, and we need to look at the big picture. People want to communicate. -- Mikael Abrahamsson email: swmike@swm.pp.se
participants (6)
-
Dmitry Kiselev -
Garry Glendown -
Gert Doering -
Max Tulyev -
Mikael Abrahamsson -
Sascha Lenz