We were recently assigned a 72.244/16 allocation from ARIN. Friendly reminder that ARIN started allocating 72/8 since Aug. If you have a static bogon filters, can you please make sure they are updated. Thank You Sincerely, Ka Lun Chan (KC) COVAD Communications <http://www.voipthemovie.com> www.voipthemovie.com
We were recently assigned a 72.244/16 allocation from ARIN. Friendly reminder that ARIN started allocating 72/8 since Aug. If you have a static bogon filters, can you please make sure they are updated. Thank
if you are really worried about this, and i can understand your being so, then make it easy for the busy folk here (not those pontificating on law and morals in the rocky mountains) to test. give us an address we can ping. randy
On Wed, 23 Mar 2005, Randy Bush wrote:
We were recently assigned a 72.244/16 allocation from ARIN. Friendly reminder that ARIN started allocating 72/8 since Aug. If you have a static bogon filters, can you please make sure they are updated. Thank
if you are really worried about this, and i can understand your being so, then make it easy for the busy folk here (not those pontificating on law and morals in the rocky mountains) to test. give us an address we can ping.
UUNET has a customer (several probably, just one 'vocal') with this same problem :( We are investigating getting a /32 from their space for use as a 'proxy test' box similar to Mr. Lewis's 69/8 box was... If there is some interest once we have it in place we could probably say: "ip BLAH" and permit folks, in some controlled manner, to use it for browser testing of sites?
We were recently assigned a 72.244/16 allocation from ARIN. Friendly reminder that ARIN started allocating 72/8 since Aug. If you have a static bogon filters, can you please make sure they are updated. Thank if you are really worried about this, and i can understand your being so, then make it easy for the busy folk here (not those pontificating on law and morals in the rocky mountains) to test. give us an address we can ping.
a bit more coffee made me realize that what might best occur would be for the rir, some weeks BEFORE assigning from a new block issued by the iana, put up a pingable for that space and announce it on the lists so we can all test BEFORE someone uses space from that block. randy
Randy Bush wrote:
a bit more coffee made me realize that what might best occur would be for the rir, some weeks BEFORE assigning from a new block issued by the iana, put up a pingable for that space and announce it on the lists so we can all test BEFORE someone uses space from that block.
Or maybe people should actually have systems to look at what hits their filters and from where and look at the summaries once a month or so? Pete
a bit more coffee made me realize that what might best occur would be for the rir, some weeks BEFORE assigning from a new block issued by the iana, put up a pingable for that space and announce it on the lists so we can all test BEFORE someone uses space from that block. Or maybe people should actually have systems to look at what hits their filters and from where and look at the summaries once a month or so?
that is what happens now. and it takes months for maria to be able to get to the entire net. randy
In message <16961.47792.567033.407015@roam.psg.com>, Randy Bush writes:
We were recently assigned a 72.244/16 allocation from ARIN. Friendly reminder that ARIN started allocating 72/8 since Aug. If you have a static bogon filters, can you please make sure they are updated. Thank if you are really worried about this, and i can understand your being so, then make it easy for the busy folk here (not those pontificating on law and morals in the rocky mountains) to test. give us an address we can ping.
a bit more coffee made me realize that what might best occur would be for the rir, some weeks BEFORE assigning from a new block issued by the iana, put up a pingable for that space and announce it on the lists so we can all test BEFORE someone uses space from that block.
That's a good idea. Maybe we can take it a step further: let each AS owner register an IP address with IANA or their RIR, and use this test box to ping the AS owner. It should be scalable -- there are only about 20k ASs, as I recall. The real expense, other than the single box per RIR, is developing the software that lets each AS register an IP address and an email address to contact if the pings fail. --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb
let each AS owner register an IP address with IANA or their RIR, and use this test box to ping the AS owner.
i do not understand what you are proposing. ahhh. you mean o each asn register a pingable address within its normal space, maybe in their irr route object o the rirs set up a routing island with only the new prefix in it o from a box with that new prefix, the rir pings all asn's registered pingable addresses from the first step o whine about any which are not pingable interesting modulo issues of reachability at any one time. and places more of a routing policing burden on the rirs. though some at least one rir is just dying to become net police, so it might sell. randy
--On 23 March 2005 11:15 -0800 Randy Bush <randy@psg.com> wrote:
at least one rir is just dying to become net police,
you don't need any mandatory aspect. Just publish which AS's have addresses that can be pinged from old netblocks, but not from new ones. No more "net police"-like than all the other project stuff which monitors reachability. If people want to filter on odd numbered first octet of IP address, well, more power to them. (yes I know it was partly tongue in cheek). Alex
Randy Bush wrote:
i do not understand what you are proposing. ahhh. you mean o each asn register a pingable address within its normal space, maybe in their irr route object o the rirs set up a routing island with only the new prefix in it o from a box with that new prefix, the rir pings all asn's registered pingable addresses from the first step o whine about any which are not pingable
interesting modulo issues of reachability at any one time. and places more of a routing policing burden on the rirs. though some at least one rir is just dying to become net police, so it might sell.
We can set this up and provide the results for public consumption given the IP's and a minimum allocation from each one of the new blocks. (for the neccessary duration, unless permanent allocation for darkspace duty is acceptable) Pete
At 20:05 23/03/2005, Steven M. Bellovin wrote:
In message <16961.47792.567033.407015@roam.psg.com>, Randy Bush writes:
We were recently assigned a 72.244/16 allocation from ARIN. Friendly reminder that ARIN started allocating 72/8 since Aug. If you have a static bogon filters, can you please make sure they are updated. Thank if you are really worried about this, and i can understand your being so, then make it easy for the busy folk here (not those pontificating on law and morals in the rocky mountains) to test. give us an address we can ping.
a bit more coffee made me realize that what might best occur would be for the rir, some weeks BEFORE assigning from a new block issued by the iana, put up a pingable for that space and announce it on the lists so we can all test BEFORE someone uses space from that block.
That's a good idea. Maybe we can take it a step further: let each AS owner register an IP address with IANA or their RIR, and use this test box to ping the AS owner. It should be scalable -- there are only about 20k ASs, as I recall. The real expense, other than the single box per RIR, is developing the software that lets each AS register an IP address and an email address to contact if the pings fail.
You mean something like: http://www.ris.ripe.net/debogon/debogon.html? Addresses are for each /8 that the RIPE NCC gets from IANA, they are announced from the day we get them from IANA until the time we start allocating from this /8. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom Verlaine)
On Wed, 23 Mar 2005, Randy Bush wrote:
We were recently assigned a 72.244/16 allocation from ARIN. Friendly reminder that ARIN started allocating 72/8 since Aug. If you have a static bogon filters, can you please make sure they are updated. Thank if you are really worried about this, and i can understand your being so, then make it easy for the busy folk here (not those pontificating on law and morals in the rocky mountains) to test. give us an address we can ping.
a bit more coffee made me realize that what might best occur would be for the rir, some weeks BEFORE assigning from a new block issued by the iana, put up a pingable for that space and announce it on the lists so we can all test BEFORE someone uses space from that block.
So, it's probably a multifaceted problem: 1) acls (router) 2) firewalls (host) 3) route acceptance (routers) Some can be audited 'easily' some are 'set and forget' (or forgot :( ) Ping might just be dropped to destinations, before any idea of 'ip space' filters (think www.sun.com filters). You really have to test with the protocols your main user base might be using (http/https). -Chris
--On 23 March 2005 10:51 -0800 Randy Bush <randy@psg.com> wrote:
a bit more coffee made me realize that what might best occur would be for the rir, some weeks BEFORE assigning from a new block issued by the iana, put up a pingable for that space and announce it on the lists so we can all test BEFORE someone uses space from that block.
Hmmm.. or, if the RIRs are going to advertize the block anyway between IANA issue and space assignment (which would appear to be a necessary precondition for what you suggest to work), why not ping "a large collection of targets" using the new block, and various other IP addresses as source addresses, and see which addresses responded from the old block(s), but not from the new block. Sort by AS, and that would give you a list (correct to heuristic level) of AS's that need to update their filters. Then stick it on a web page. RIPE could (for instance) generate it's "large collection of targets" using a tiny sample of host-count data. (clearly RIPE needs to ping addresses from all RIRs, ditto ARIN, APNIC etc.) Alex
a bit more coffee made me realize that what might best occur would be for the rir, some weeks BEFORE assigning from a new block issued by the iana, put up a pingable for that space and announce it on the lists so we can all test BEFORE someone uses space from that block.
ARIN meeting happens in Orlando in about 1 month from now. There is at least one open mike session on the agenda and there is also a new policy workshop if folks think that this practice needs to be made into a formal policy. Also, on the ARIN website at http://www.arin.net/about_us/ab_org_bot.html you can find contact info for the Board of Trustees. These are the people who can decide that something makes perfect sense and instruct staff to just do it without going through the process of changing policies. Seems to me that this idea falls into the "just do it" category, i.e. it's operational best practice. So if you want this feature, tell ARIN about it! --Michael Dillon P.S. there is an upcoming RIPE meeting in Stockholm at the end of May. As above, tell them that this is important for them to be doing.
a bit more coffee made me realize that what might best occur would be for the rir, some weeks BEFORE assigning from a new block issued by the iana, put up a pingable for that space and announce it on the lists so we can all test BEFORE someone uses space from that block.
Based on what I've seen in last 2 years for all new IANA allocations to RIR, the assignments from the ip blocks do not happen on day one and in fact it takes RIR about 2-3 months before they start using that ip block. During that first couple months RIR makes announcements about the ip block (and we can possibly ask them to make additional announcement around week prior to when ip block first allocation is expected to be made) and some RIRs like RIPE use those 2 months to check reachability of the ips within the block. One of the problems for North America though is that ARIN does not seem to want to get involved in the operation aspects and so it does not do quite as much as for example RIPE. -- William Leibzon Elan Networks william@elan.net
a bit more coffee made me realize that what might best occur would be for the rir, some weeks BEFORE assigning from a new block issued by the iana, put up a pingable for that space and announce it on the lists so we can all test BEFORE someone uses space from that block. ARIN meeting happens in Orlando in about 1 month from now. There is at least one open mike session on the agenda and there is also a new policy workshop if folks think that this practice needs to be made into a formal policy.
it doesn't. it's not policy. it's a simple ops hack. let's not see how complex we can make it or how much bureaucrazy we can wrap around it. it seems that even bureaucrazy ripe managed to do it without holding policy discussions; see henk's posting. randy
it seems that even bureaucrazy ripe managed to do it without holding policy discussions; see henk's posting.
I believe that RIPE does these things BECAUSE it is more bureaucratic than ARIN. As a result, RIPE staff feel more empowered to do sensible projects outside of the policy process. In any case, it is not important how the message gets communicated to ARIN. What is important is for network operators to *TELL* ARIN what they need ARIN to do. One way to talk to ARIN is through the public meetings and another way is to email one of the trustees. --Michael Dillon
In any case, it is not important how the message gets communicated to ARIN. What is important is for network operators to *TELL* ARIN what they need ARIN to do. One way to talk to ARIN is through the public meetings and another way is to email one of the trustees.
and one is to send an email to arin's external relations or ops folk, which i did a while ago. i suspect they also read this list. you can now return to pontificating on law and morals in a mostly rural western us state, always a productive activity for ops folk. randy
On Thu, 24 Mar 2005 Michael.Dillon@radianz.com wrote:
In any case, it is not important how the message gets communicated to ARIN. What is important is for network operators to *TELL* ARIN what they need ARIN
is arin the problem here? or are 'lazy'/'dumb'/'mistaken'/'poorly informed' admins the problem?
On Thu, 24 Mar 2005, Christopher L. Morrow wrote:
On Thu, 24 Mar 2005 Michael.Dillon@radianz.com wrote:
In any case, it is not important how the message gets communicated to ARIN. What is important is for network operators to *TELL* ARIN what they need ARIN
is arin the problem here? or are 'lazy'/'dumb'/'mistaken'/'poorly informed' admins the problem?
Lazy/misguided/ex admins / downsized networks are the problem. ARIN is in a unique position to be able to do something to at least try to mitigate the problem without too much effort before handing "damaged IP space" out to members. The current situation frustrates those who don't know what to do, and encourages them to look elsewhere for the IP space they need. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
At 10:06 AM 3/24/2005, Jon Lewis wrote:
On Thu, 24 Mar 2005, Christopher L. Morrow wrote:
On Thu, 24 Mar 2005 Michael.Dillon@radianz.com wrote:
In any case, it is not important how the message gets communicated to ARIN. What is important is for network operators to *TELL* ARIN what they need ARIN
is arin the problem here? or are 'lazy'/'dumb'/'mistaken'/'poorly informed' admins the problem?
Lazy/misguided/ex admins / downsized networks are the problem. ARIN is in a unique position to be able to do something to at least try to mitigate the problem without too much effort before handing "damaged IP space" out to members. The current situation frustrates those who don't know what to do, and encourages them to look elsewhere for the IP space they need.
I think it's important to remember the "lazy/dumb/mistaken/poorly informed" folk alluded to above are NOT the ones receiving IP address space, but people elsewhere in (and all over) the world. ARIN does not provide any statement of suitability of the address space for any purpose. That's nice for the lawyers, but pretty useless from a customer satisfaction and network operations standpoint. The idea of ARIN temporarily lighting address space in any new block, and providing a test target is reasonable, relatively inexpensive and sensible. Paying members of ARIN are today negativelty impacted by receiving assignments that remain in filters. It clearly makes little sense for those receiving address space to each have to expend significant time and effort to turn the address space into usable space. As such, the paying customers & members should consider requesting this be a function that could be best handled centrally by ARIN.
On Thu, 24 Mar 2005, Daniel Senie wrote:
At 10:06 AM 3/24/2005, Jon Lewis wrote:
On Thu, 24 Mar 2005, Christopher L. Morrow wrote:
On Thu, 24 Mar 2005 Michael.Dillon@radianz.com wrote:
In any case, it is not important how the message gets communicated to ARIN. What is important is for network operators to *TELL* ARIN what they need ARIN
is arin the problem here? or are 'lazy'/'dumb'/'mistaken'/'poorly informed' admins the problem?
Lazy/misguided/ex admins / downsized networks are the problem. ARIN is in a unique position to be able to do something to at least try to mitigate the problem without too much effort before handing "damaged IP space" out to members. The current situation frustrates those who don't know what to do, and encourages them to look elsewhere for the IP space they need.
I think it's important to remember the "lazy/dumb/mistaken/poorly informed" folk alluded to above are NOT the ones receiving IP address space, but people elsewhere in (and all over) the world.
of course, I should have been more clear, sorry :)
The idea of ARIN temporarily lighting address space in any new block, and providing a test target is reasonable, relatively inexpensive and sensible.
this requires the above lazy/dumb/mistaken/poorly-informed masses to want to hit the targets as well, eh? :(
Paying members of ARIN are today negativelty impacted by receiving assignments that remain in filters. It clearly makes little sense for those receiving address space to each have to expend significant time and effort to turn the address space into usable space. As such, the paying customers & members should consider requesting this be a function that could be best handled centrally by ARIN.
I think I'm unclear how having arin/ripe/apnic/iana/god put up pingable/http-able/ftp-able ips from 'new' blocks is going to help, when the problem is at the far-end, and the 'user' or 'admin' there is one of the: "lazy/dumb/mistaken/poorly-informed" who already doesn't care enough to keep their filters up to date. Additionally, there is still the distinction between firewall/acl blocks and 'route filter' blocks. They may have the same effect in the end, but the target for who might have to repair that problem is likely different. -Chris
On Thu, 24 Mar 2005, Christopher L. Morrow wrote:
is arin the problem here? or are 'lazy'/'dumb'/'mistaken'/'poorly informed' admins the problem?
Lazy/misguided/ex admins / downsized networks are the problem. ARIN is in a unique position to be able to do something to at least try to mitigate the problem without too much effort before handing "damaged IP space" out to members. The current situation frustrates those who don't know what to do, and encourages them to look elsewhere for the IP space they need.
I think it's important to remember the "lazy/dumb/mistaken/poorly informed" folk alluded to above are NOT the ones receiving IP address space, but people elsewhere in (and all over) the world.
of course, I should have been more clear, sorry :)
That was totally clear to me. It's the people who set and forget about (or set and get laid off) bogon packet/route filters that have caused this problem. The unfortunate thing is that they don't seem to learn from their mistakes. Each time a new /8 goes from bogon to RIR assigned, the end users of those new allocations end up dealing with the same problems each former bogon /8 did before them. How many times does a network have to be contacted by users of 69/8, 70/8, 71/8, before they stop and think "hey, maybe these static bogon filters weren't such a great idea...how about we just scrap them?"...or maybe its just that new static bogon filters are being put in place and forgotten...so a network that didn't have bogon filters when 69/8 went into use does now.
The idea of ARIN temporarily lighting address space in any new block, and providing a test target is reasonable, relatively inexpensive and sensible.
this requires the above lazy/dumb/mistaken/poorly-informed masses to want to hit the targets as well, eh? :(
Exactly why even though it may help a little, it's not a solution. The solution has to be more active (vs passive). Setup something in that new IP space, and do reachability testing (or let others do it as RIPE has done). That's quite a bit more involved than just setting up a host and saying "hey, ping this", but how else are you going to know where the filters are? If ARIN did this, they could setup something very similar to what I did on 69box, and have a "hall of shame" page listing the networks (IPs) unreachable from the new space, but reachable from older space. At least then members given former bogon IP blocks could go to that page, see if there are any networks listed that they might care about reachability to, and try to make contact themselves with those networks they care about in order to get their bogon issues resolved. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
is arin the problem here? or are 'lazy'/'dumb'/'mistaken'/'poorly informed' admins the problem? Lazy/misguided/ex admins / downsized networks are the problem.
if aol is not worried enough to tell us an address to ping, perhaps you can see why we prospective pingers are not getting our undies in a knot. and, to carry it a step further, one might then infer why arin has not seen it as a priority. i suspect this discussion will change the latter. dunno what will change the former.
ARIN is in a unique position to be able to do something to at least try to mitigate the problem without too much effort before handing "damaged IP space" out to members.
damaged? so you will do your bit to undamage unused ip space by not bogon filtering on your network? randy
On Thu, 24 Mar 2005, Randy Bush wrote:
ARIN is in a unique position to be able to do something to at least try to mitigate the problem without too much effort before handing "damaged IP space" out to members.
damaged? so you will do your bit to undamage unused ip space by not bogon filtering on your network?
I don't do bogon filtering. I do take a bogon route feed from team cymru, but that won't stop me from reaching any announced subnets within "bogon space"[1]. And cymru has been pretty good about keeping up with the changes wrt what's a bogon and what's not. What I will do, next time we get space from ARIN (which I suspect isn't too far off) is setup 72box (or whatever /8 they're allocating from now) and repeat the exercise I did with 69/8 space so I have some idea where the idiot networks are (and try contacting them) before we start using or assigning IP's from that space. [1] at least not until cisco adds a feature allowing you to ignore new BGP routes for subnets of a bogon feed. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
Jon Lewis wrote:
On Thu, 24 Mar 2005, Randy Bush wrote:
<snip>
[1] at least not until cisco adds a feature allowing you to ignore new BGP routes for subnets of a bogon feed.
Last I understood from c-nsp this was a feature without much interest. Is such a feature expected to arrive anytime soon? From any other vendor?
In any case, it is not important how the message gets communicated to ARIN. What is important is for network operators to *TELL* ARIN what they need ARIN
is arin the problem here? or are 'lazy'/'dumb'/'mistaken'/'poorly informed' admins the problem?
ARIN is not part of the problem, but ARIN *IS* part of the solution. If ARIN was really a functional organization, i.e. driven by its members, then we wouldn't even be talking about this here. It would have been done long ago. However, ARIN today is a very dysfunctional organization. Most ARIN members seem to view ARIN as a distant regulatory agency to whom they must regularly burn incense and make sacrifices in order for the ARIN gods to bestow IP addresses upon the unworthy network operator. The result is that there is little participation by ARIN members in monitoring and governing ARIN. And therefore, ARIN does what it has always done without changing or innovating. Is this bad? Yes, it is bad that so many ARIN members remain at arms length. It is bad that so many ARIN members do not understand ARIN and do not drive ARIN towards better meeting the needs of the IP network operations industry. It is bad that so many network operators fear ARIN and think that ARIN carries a big stick like the FCC. The fault is not with the people involved in ARIN; the fault is with the majority of IP network operators who do not get involved with ARIN. --Michael Dillon
At 15:17 +0000 3/24/05, Michael.Dillon@radianz.com wrote: To begin with, nothing I have to say here has any bearing on the other IRR's. There is a reason there are 4-5 IRRs, each should be tuned to local sensibilities.
However, ARIN today is a very dysfunctional organization.
That is a very brash statement, one that is easily misinterpreted, one that may be simply wrong, or a statement that has an element of truth. The tone of this statement is why I am bothering to reply. First, distinguish between ARIN staff and ARIN membership. The staff at ARIN go to great lengths to respond to what the membership - and the public at large - ask ARIN to do. Note - NOT JUST membership. This is why there are open policy discussions, and open mics. (Sessions are webcast, the public policy mailing list is free to join.) Of course, membership does control the bounds of ARIN's response, including that of the staff, which is why there is also a member-only meeting on the last day of the conference. ARIN's staff is to fairly and equitably execute the policies that the membership organization has put into play. (I won't split hairs on the Advisory Council or the Board's roles, this can be learned by starting with ARIN's web site, http://www.arin.net.) This has two consequences. One is that it means the staff should not go and try to set the agenda for how ARIN operates. It it beneficial if the staff is involved to educate the members on the reality of running the registry. It the staff goes further, they are potentially disrupting an otherwise level playing field. The other consequence is that the membership takes on the responsibility for ARIN's actions. Not the staff's actions, but ARIN's actions. If there is any dysfunction in ARIN, I suspect that it lay here. I do not mean to infer that there is a problem, but I think this is where the largest misunderstanding of ARIN's role exists. I also do not demean the efforts of those who do take the time to participate, they are the ones heading in the "right" direction, no matter whether I agree with the opinions I hear. One question does haunt me about how the operations community views ARIN. Most ARIN policies are concerned with address allocation, reporting, and such. There are not many policies regarding the functional role ARIN plays in the Internet, the only one that leaps to mind is a lame delegation policy under discussion. The (haunting) question is whether the operations community feels that there should be operational policies put before ARIN. E.g., support for secure routing - when a concrete approach is defined that needs RIR input, should ARIN play? Is there a feeling within the operator community that ARIN is...
Most ARIN members seem to view ARIN as a distant regulatory agency to whom they must regularly burn incense and make sacrifices in order for the ARIN gods to bestow IP addresses upon the unworthy network operator. The result is that there is little participation by ARIN members in monitoring and governing ARIN. And therefore, ARIN does what it has always done without changing or innovating.
Oh, that's was where I was going. Is that the case? If so, then there is a dysfunction. I want to make it clear that any lack of change or innovation is not something that the staff has caused. (By design the staff is in reaction mode.) The lack of change or innovation is the motivation for the haunting question above.
that ARIN carries a big stick like the FCC. The fault is not with the people involved in ARIN; the fault is with the majority of IP network operators who do not get involved with ARIN.
I don't like "fault", it implies that there is something seriously broken. For the most part, things are working fairly well. Maybe at the operator level we see ways the world would be much better if we ruled things, but to the general public, the Internet is making things better. (Maybe for just some, but you have to admit overall things are better.) But, the point is taken that ARIN would be much more "useful" to the Internet if there was a change in participation. However, the improvement is not in the demographics of the participation, but in the content of the participation. If the content of the participation was well-balanced, then the demographics will follow. After all, if the policies ARIN membership were "perfect" now and into the future, there's no longer a need for the membership to steer the staff. The only thing the staff would have to do is execute the (benevolent, perfect) bureaucracy. ;) PS - I think my response to Michael is not so much an opposing view, but a slightly different emphasis in where improvements may lie. I really don't think Michael is trying to "stick it to the staff." (I hope he's not.) But a lot of times people confuse the ARIN staff with the ARIN membership organization. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss.
The other consequence is that the membership takes on the responsibility for ARIN's actions. Not the staff's actions, but ARIN's actions. If there is any dysfunction in ARIN, I suspect that it lay here.
Yes, this is what I believe. The ARIN membership is more passive than I think is healthy for the organization. Thus, the organization is dysfunctional.
I want to make it clear that any lack of change or innovation is not something that the staff has caused.
I'm not knocking the staff. And I'm also not suggesting that people should pester the staff if they want ARIN to act on something. The Board of Trustees is responsible for instructing the staff to act, and therefore, ARIN members and others should either communicate directly with the Trustees, or through the public policy process. However, this public policy process is itself suffering as the result of extremely low involvement by ARIN members and by other interested parties.
But, the point is taken that ARIN would be much more "useful" to the Internet if there was a change in participation.
Point taken. My goal is to see more participation so that more diverse viewpoints are involved in the discussion. When there are only a handful of people making all the decisions, then it is much easier to make mistakes, to misunderstand the situation, and to be blind to possibilities. Democractic oversight and review cannot happen when the number of people involved is very low.
But a lot of times people confuse the ARIN staff with the ARIN membership organization.
That's why I didn't mention the staff and repeatedly pointed the finger at the apathy of the IP network operators who form ARIN's membership. --Michael Dillon
One question does haunt me about how the operations community views ARIN. Most ARIN policies are concerned with address allocation, reporting, and such. There are not many policies regarding the functional role ARIN plays in the Internet, the only one that leaps to mind is a lame delegation policy under discussion.
The (haunting) question is whether the operations community feels that there should be operational policies put before ARIN. E.g., support for secure routing - when a concrete approach is defined that needs RIR input, should ARIN play?
NO. Operational specifications and routing are the domain of the IETF and _NOT_ ARIN. ARIN is responsible for the stewardship of assigned numbers within the ARIN region. This includes IP addresses, Autonomous System Numbers, and, DNS delegations for reverses on IP addresses. While ARIN should consider routing issues and the operational impact of ARIN stewardship policies, and, ARIN also has an educational role in helping the community to understand BCP including operational BCP as it relates to IP Addresses, ASNs, and DNS, ARIN has no role in dictating or driving operational practices.
Most ARIN members seem to view ARIN as a distant regulatory agency to whom they must regularly burn incense and make sacrifices in order for the ARIN gods to bestow IP addresses upon the unworthy network operator. The result is that there is little participation by ARIN members in monitoring and governing ARIN. And therefore, ARIN does what it has always done without changing or innovating.
Huh? I can accept that most ARIN non-members with direct assignments see ARIN in this way, but, I find it _VERY_ hard to believe that is the viewpoint of the majority of ARIN members. It certainly is not the viewpoint of the members who read any of the things they signed when they joined. It certainly is not the viewpoint of the members who participate on PPML or attend ARIN meetings. If that is the viewpoint of the members who do not participate, then, that is unfortunate, and, certainly a dysfunctional role for those members.
Oh, that's was where I was going. Is that the case? If so, then there is a dysfunction.
Yep. I'm not sure, however, what you can do to address the issue of misperception due to willful ignorance. If you can figure out how to solve that, perhaps we can next tackle the problems of the dysfunction in united States voting.
I want to make it clear that any lack of change or innovation is not something that the staff has caused. (By design the staff is in reaction mode.) The lack of change or innovation is the motivation for the haunting question above.
I'm not sure ARIN has a change or innovation role. It is not unlikely that responsible stewardship includes a minimum of change and a preservation of stability and consistency.
PS - I think my response to Michael is not so much an opposing view, but a slightly different emphasis in where improvements may lie. I really don't think Michael is trying to "stick it to the staff." (I hope he's not.) But a lot of times people confuse the ARIN staff with the ARIN membership organization.
I rarely agree with Michael, but, I do respect him. I am quite confident that his intent is not to "stick it" to the ARIN staff. I think he comes from a genuine desire to improve things. We don't differ on that. We differ on how. Owen -- If it wasn't crypto-signed, it probably didn't come from me.
At 12:53 -0800 3/24/05, Owen DeLong wrote:
NO. Operational specifications and routing are the domain of the IETF and _NOT_ ARIN. ARIN is responsible for the stewardship of assigned numbers within the ARIN region. This includes IP addresses, Autonomous System Numbers, and, DNS delegations for reverses on IP addresses. While ARIN should consider routing issues and the operational impact of ARIN stewardship policies, and, ARIN also has an educational role in helping the community to understand BCP including operational BCP as it relates to IP Addresses, ASNs, and DNS, ARIN has no role in dictating or driving operational practices.
My question is not related to specification development but operational requirements of ARIN itself providing a service based on specifications. E.g., picking something a bit more concrete that secure routing, should ARIN deploy DNSSEC support, once it is published (again), in 6 months? 12 months? 10 years? This will tell the staff what level of staffing is needed to accomplish the work. The policy discussion will let membership know whether it is willing to pay for this. (Open to the public or not, the membership determines what it pays.) Discretionary funding for supporting research within the IETF should exist too, to cover participation in development of specifications at an appropriate level of effort. Let's say DNSSEC is ready for deployment. Does the impetus come from the ARIN staff or from the membership? (Maybe it comes from outside, but does it need to be made into a policy before the staff implements it?)
I'm not sure ARIN has a change or innovation role. It is not unlikely that responsible stewardship includes a minimum of change and a preservation of stability and consistency.
ARIN has two definite roles when it comes to innovation. 1) Don't get in the way of innovation by the community and 2) provide expert advice when it comes to the development of specifications related to RIR functions. And ARIN ought to be wary of trends in the improvement of its internal operations. An example of role number 1 is providing DNS services over IPv6 transport. An example of role number 2 is contributing to the discussion of the IRIS definitions for address registries. In neither case is ARIN leading the charge, but is playing a part in innovation. To come back to secure routing, the reason ARIN would be involved is that ARIN would be asked to publish information on who is allocated number resources. Although this is done in WhoIs now, there is a need to do this via whatever format is required by "secure routing." I'm sure the specification of secure routing will describe how to operate the protocol, but not address the server capacity nor topology needed. Perhaps policies aren't the vehicle, but then how does the operational community get ARIN to supply services? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss.
--On Thursday, March 24, 2005 16:32 -0500 Edward Lewis <Ed.Lewis@neustar.biz> wrote:
At 12:53 -0800 3/24/05, Owen DeLong wrote:
NO. Operational specifications and routing are the domain of the IETF and _NOT_ ARIN. ARIN is responsible for the stewardship of assigned numbers within the ARIN region. This includes IP addresses, Autonomous System Numbers, and, DNS delegations for reverses on IP addresses. While ARIN should consider routing issues and the operational impact of ARIN stewardship policies, and, ARIN also has an educational role in helping the community to understand BCP including operational BCP as it relates to IP Addresses, ASNs, and DNS, ARIN has no role in dictating or driving operational practices.
My question is not related to specification development but operational requirements of ARIN itself providing a service based on specifications.
E.g., picking something a bit more concrete that secure routing, should ARIN deploy DNSSEC support, once it is published (again), in 6 months? 12 months? 10 years? This will tell the staff what level of staffing is needed to accomplish the work. The policy discussion will let membership know whether it is willing to pay for this. (Open to the public or not, the membership determines what it pays.)
When DNSSEC is released again (whenver that may be), if ARIN constituency wants ARIN to support it, at least one such person will make a policy proposal. In the policy proposal, there will be a proposed or intended timeframe for implementation. This is a requirement of the policy process. If ARIN staff does not feel it can meet that timeframe, that will be part of the discussion in the Staff Impact slide that is presented with each proposal at the ARIN meeting(s) where the proposal is discussed.
Discretionary funding for supporting research within the IETF should exist too, to cover participation in development of specifications at an appropriate level of effort.
ARIN has, so far, expressed a desire not to do this. Indeed, ARIN has specifically encouraged ARIN members to participate individually in IETF, but, feels that ARIN as a body has no role to play there.
Let's say DNSSEC is ready for deployment. Does the impetus come from the ARIN staff or from the membership? (Maybe it comes from outside, but does it need to be made into a policy before the staff implements it?)
Neither. It comes from the ARIN constituency, which is the entire community of IP consumers within the ARIN region. The imeptus would come from a policy proposal. Anyone who has an interest can submit a policy proposal to ARIN.
I'm not sure ARIN has a change or innovation role. It is not unlikely that responsible stewardship includes a minimum of change and a preservation of stability and consistency.
ARIN has two definite roles when it comes to innovation. 1) Don't get in the way of innovation by the community and 2) provide expert advice when it comes to the development of specifications related to RIR functions. And ARIN ought to be wary of trends in the improvement of its internal operations.
Agreed. However, this is different from the impression I received from the earlier comments that seemed to suggest that ARIN had a role as an innovator. Finally, as to 1, to a certain extent, ARIN does have a partial responsibility to stand in the way of some innovation if in ARIN's view said innovation might be harmful to existing services.
An example of role number 1 is providing DNS services over IPv6 transport. An example of role number 2 is contributing to the discussion of the IRIS definitions for address registries. In neither case is ARIN leading the charge, but is playing a part in innovation.
I don't believe ARIN had any delay between ARIN beginning to issue IPv6 allocations and ARIN providing DNS/v6 services. Until such time as ARIN had policy and responsibility for issuing IPv6 addresses, ARIN had no reason whatsoever to provide any DNS/v6 services.
To come back to secure routing, the reason ARIN would be involved is that ARIN would be asked to publish information on who is allocated number resources. Although this is done in WhoIs now, there is a need to do this via whatever format is required by "secure routing." I'm sure the specification of secure routing will describe how to operate the protocol, but not address the server capacity nor topology needed.
Again, if that feature is desired by anyone in ARIN constituency, then, a relevant policy proposal will be put forth, and, the issue will be debated and addressed according to community consensus. I do not see this as dysfunctional.
Perhaps policies aren't the vehicle, but then how does the operational community get ARIN to supply services?
Policies _ARE_ the vehicle, and, I guess I don't understand what it is you think is dysfunctional about the policy process, since from what I can see, it addresses exactly the issues you describe above. Owen
Jeeze... It seems there are all kinds of policy wonks ever so ready to errect fantastic edifices and structure all manner of procedure and organization in order to fix the problem of newly allocated address space being filtered that is largely caused by a highly visible attractive nuisance, and rather than persude the people that make the static filter configuration pages to responsibly remove the portion that isn't RFC 1918 or martians, you would rather tilt at windmills. Look, this situation is akin to a gun and ammo store (the security website in question) leaving a pile of hand grenades on display on a table in front of their store. You are busy arguing about who should clean up the mess made every time a less knowledgable member of the public blows themselves up. The fix is to not put hand grenades in a public place. Ergo, please don't make static filter configurations available that include unallocated address space, people will use them and leave them in place forever. Yes, they are doing something that will harm themselves. Yes, that is dumb. It's an "attractive nuisance", please fix it. Mike. ps. http://insurance.cch.com/rupps/attractive-nuisance-doctrine.htm On Thu, 24 Mar 2005 Michael.Dillon@radianz.com wrote:
a bit more coffee made me realize that what might best occur would be for the rir, some weeks BEFORE assigning from a new block issued by the iana, put up a pingable for that space and announce it on the lists so we can all test BEFORE someone uses space from that block.
ARIN meeting happens in Orlando in about 1 month from now. There is at least one open mike session on the agenda and there is also a new policy workshop if folks think that this practice needs to be made into a formal policy.
Also, on the ARIN website at http://www.arin.net/about_us/ab_org_bot.html you can find contact info for the Board of Trustees. These are the people who can decide that something makes perfect sense and instruct staff to just do it without going through the process of changing policies.
Seems to me that this idea falls into the "just do it" category, i.e. it's operational best practice. So if you want this feature, tell ARIN about it!
--Michael Dillon
P.S. there is an upcoming RIPE meeting in Stockholm at the end of May. As above, tell them that this is important for them to be doing.
+----------------- H U R R I C A N E - E L E C T R I C -----------------+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | mleber@he.net http://www.he.net | +-----------------------------------------------------------------------+
participants (15)
-
Alex Bligh -
Chan, KaLun -
Christopher L. Morrow -
Daniel Senie -
Edward Lewis -
Henk Uijterwaal -
Joe Maimon -
Jon Lewis -
Michael.Dillon＠radianz.com -
Mike Leber -
Owen DeLong -
Petri Helenius -
Randy Bush -
Steven M. Bellovin -
william(at)elan.net