Re: BCP38 exceptions for RFC1918 space
On Mon, Aug 16, 2010 at 1:49 AM, Marco Hogewoning mar...@marcoh.net wrote: On 15 aug 2010, at 20:05, Randy Bush wrote: rfc1918 packets are not supposed to reach the public internet. once you start accommodating their doing so, the downward slope gets pretty steep and does not end in a nice place. I cannot agree more with this. If you want PMTU use non-private space, there is enough really :) And saving a /24 by renumbering your core into RFC 1918 won't save you from the coming run out. I once suggested something along the lines of: interface Loopback0 ip address 1.2.3.4 255.255.255.255 interface GigabitEthernet0/0 ip address 192.168.0.1 255.255.255.0 icmp errors-from Loopback0 But I was yelled at for trying to break traceroute. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Numbering nameservers and resolvers
Hi Folks, I am needing to renumber some core infrastructure - namely, my nameservers and my resolvers - and I was wondering if the collective wisdom still says heck yes keep this stuff all on seperate subnets away from eachother? Anyone got advice either way? Should I try to give sequential numbers to my resolvers for the benefit of consultants ... like .11, .22 and .33 for my server ips? Mike-
Re: Numbering nameservers and resolvers
Composed on a virtual keyboard, please forgive typos. On Aug 16, 2010, at 7:49, Mike mike-na...@tiedyenetworks.com wrote: Hi Folks, I am needing to renumber some core infrastructure - namely, my nameservers and my resolvers - and I was wondering if the collective wisdom still says heck yes keep this stuff all on seperate subnets away from eachother? Anyone got advice either way? Should I try to give sequential numbers to my resolvers for the benefit of consultants ... like .11, .22 and .33 for my server ips? 1) Use different prefixes. A single prefix going down should not kill your entire network. (Nameservers and resolvers being unreachable breaks the whole Internet as far as users are concerned.) 2) Consider trading secondary NS with another AS. This is for authorities only, recursive NSes should be on-net only. 3) Try not to use the first /24 in a large prefix. See as7007 incident for why, although that is probably less likely today. 4) Using easily memorized numbers for at least one authority one resolved will help your NOC, but should not override other considerations. That's a start, I'm sure others will have more suggestions. -- TTFN, patrick
Re: Numbering nameservers and resolvers
On Aug 16, 2010, at 12:49 AM, Mike wrote: Hi Folks, I am needing to renumber some core infrastructure - namely, my nameservers and my resolvers - and I was wondering if the collective wisdom still says heck yes keep this stuff all on seperate subnets away from eachother? Anyone got advice either way? Should I try to give sequential numbers to my resolvers for the benefit of consultants ... like .11, .22 and .33 for my server ips? Resolvers being easily memorable is nice, since they get keyed in by IP. Authority servers are referred to by name, so IP matters less. Definitely keep an authority server in another prefix if you can, and resolvers in different prefixes is also nice -- but that's more a question of redundancy, not numbering. Other than that, go dense. Addresses are starting to get scarce. Aria Stewart
Re: Numbering nameservers and resolvers
On Sun, 15 Aug 2010 23:49:05 PDT, Mike said: I am needing to renumber some core infrastructure - namely, my nameservers and my resolvers - and I was wondering if the collective wisdom still says heck yes keep this stuff all on seperate subnets away from eachother? Anyone got advice either way Microsoft used to have all their DNS servers on one /24. Nine years later, you can still use Google on just 'microsoft dns server failure subnet' and find this on the second page of over a million hits: http://www.wired.com/techbiz/media/news/2001/01/41423 (OK, so our local resolvers are in one /24, but it's a bridged VLAN across our entire campus, the servers are physically in buildings several miles apart, and if you can't reach at least one of them, it probably means our campus core network is hosed enough that you're not going to do anything with a DNS response anyhow... Our authoritative servers are split across 2 different AS's in 2 different states.) Whatever gave you the idea that collective wisdom could *possibly* have moved away from spread it out as far as you can to avoid single points of failure? pgpkapCX4BnWZ.pgp Description: PGP signature
Re: Numbering nameservers and resolvers
On 8/16/2010 2:49 AM, Mike wrote: from eachother? Anyone got advice either way? Should I try to give If you have a dedicated subnet for /32s (e.g., router loopback interfaces), i'd pick from there. if you eventually require geo-redundancy or want to load balance your queries, it's much neater injecting them into your igp rather than having a few /32's injected from an otherwise nice clean /24. I am also a fan of keeping your recursive and authoritative ip addresses separate. Not only is this much more modular, it can be more secure; see http://cr.yp.to/djbdns/separation.html -- Jeremy Kister http://jeremy.kister.net./
Re: Numbering nameservers and resolvers
for authoritatuve servers, i try to have one on a very different backbone on a distant continent. i make deals with friends. there have been just too many failures where servers were in the same facility, or behind the same routing, or on a single backbone. see rfc 2182. for customer- and infrastructure-facing caches, i try for as different routing domains and peering/x-stream exits as i can while keeping them easily reachable by their clients. randy
Re: Numbering nameservers and resolvers
For resolvers, I guess it would make sense to advertise them as /32s as dynamic prefixes coming from some SLB device... You can have multiple VIPs, each representing a different POP/network domain... Arie On Mon, Aug 16, 2010 at 9:49 AM, Mike mike-na...@tiedyenetworks.com wrote: Hi Folks, I am needing to renumber some core infrastructure - namely, my nameservers and my resolvers - and I was wondering if the collective wisdom still says heck yes keep this stuff all on seperate subnets away from eachother? Anyone got advice either way? Should I try to give sequential numbers to my resolvers for the benefit of consultants ... like .11, .22 and .33 for my server ips? Mike-
Re: Numbering nameservers and resolvers
On 2010-08-16 08:49, Mike wrote: Hi Folks, I am needing to renumber some core infrastructure - namely, my nameservers and my resolvers - and I was wondering if the collective wisdom still says heck yes keep this stuff all on seperate subnets away from eachother? Anyone got advice either way? Should I try to give sequential numbers to my resolvers for the benefit of consultants ... like .11, .22 and .33 for my server ips? Take a IPv4 /24, /28, whatever size you might think you need and an IPv6 /64 and make it your 'service prefix', then anycast this inside your network and do the standard 'bgp daemon on the box, monitor the local service' trick and kill the announcement when the service does not work, presto. As for the actually numbers, just keep them simple. Using port-numbers (53 = DNS, 25 = SMTP etc etc etc) where possible is easy for at least the more technical folks, of course IPv4 only goes up to 255, IPv6 does not have that issue. Greets, Jeroen
Re: Lightly used IP addresses
On Aug 16, 2010, at 1:44 AM, William Herrin wrote: ... The retort you want to make is that ARIN just wouldn't do that. That's not the kind of people they are. Fine. So update the LRSA so it doesn't carefully and pervasively establish ARIN's legal right to behave that way. Bill - Divide and conquer... I will confirm with the Board that that is the intent of the LRSA (which would then allow us to initiate the task of changing the language accordingly); can you submit this as a suggestion so that this request is not accidentally lost or overlooked? Thanks! /John John Curran President and CEO ARIN
Re: BCP38 exceptions for RFC1918 space
Florian Weimer wrote: What's the current consensus on exempting private network space from source address validation? Is it recommended? Discouraged? (One argument in favor of exceptions is that it makes PMTUD work if transfer networks use private address space.) IMHO, operators who number infrastructure out of RFC1918 and then permit internet traceroutes over it are misguided and should consider avoiding TTL decrement (i.e using mpls without internet TTL propagation) as a less stressful (for us) alternative to simply filtering. Dave. -- David Freedman Group Network Engineering Claranet Group
Geolocation tools - IPv6 style
Hello NANOG, first time writing to here. My inquiry for you is on the subject of IPv6 Geolocation tools; or better yet, the lack accuracy in them. My main problem comes from YouTube.com and other Google Geolocation required tools (Google Voice, being an example). I must set network.dns.disableIPv6 to true just to access a lot of videos on YouTube, and to access my Google voice and similar services. I am unsure what country it thinks I am from when I access via IPv6, but it sure thinks I am foreign to the US. I understand that all Geolocation can, at most, point to the local routing station of that person's ISP. The current progress in the IPv6 field of geolocation is mostly pointing at countries, not even states or cities unlike IPv4. Is there something majorly different about the ability to track IPs in v6, than there was in v4? Or are the main producers of this data just busy / do not see IPv6 as being profitable / not worth their time? Another problem I have (which isn't really relevant to the subject, but if anyone has the same problem when loading via IPv6 I would be interested in hearing about it), would be the loading of YouTube content. Pages will seemingly load partially, and always be Waiting on s.ytimg.com. http://s.ytimg.com/ loads instantly for me via IPv6, but not via videos. Has anyone else experenced the same problem? If I use v4 to load YouTube, the video instantly loads. There could be heavy load from my broker (he.net), but all other sites load instantly. Thanks for your time.
Re: BCP38 exceptions for RFC1918 space
On Sun, 15 Aug 2010 19:02:50 +0200, Florian Weimer said: * Valdis Kletnieks: On Sun, 15 Aug 2010 18:46:49 +0200, Florian Weimer said: And that connection that's trying to use PMTU got established across the commodity internet, how, exactly? ;) ICMP fragmentation needed, but DF set messages carry the a addresses of intermediate routers which generate them (potentially in response to MTU drops) as source addresses, not the IP addresses of the peers in a connection. If any long-haul carriers are originating ICMP packets for other people's consumption from 1918 addresses rather than addresses in their address space, it's time to name-n-shame so the rest of us can vote with our feet and checkbooks. There's no excuse for that in this day and age. What does originating mean? Creating the packets? Or forwarding them? Either way, there's no excuse. First off, remember that BCP38 and 1918 don't apply on your set of interconnected private networks, no matter how big a net it is. You want to filter between two of your private nets, go ahead. You don't want to, that's OK to. The fun starts when those packets leave your network(s) and hit the public Internet. Now that we have that squared away... Either that intermediate router originated the ICMP 'frag needed' packet, in which case somebody needs to be smacked for originating a 1918-addressed packet on the public internet, or it's forwarding the packet. And if it's forwarding the packet, then somebody *else* needs to be smacked for injecting that packet into the public internet. What *possible* use case would require a 1918-sourced packet to be traversing the public internet? We're all waiting with bated breath to hear this one. ;) pgpqXo6NLfzKs.pgp Description: PGP signature
Re: Lightly used IP addresses
On Aug 15, 2010, at 11:31 PM, Jeffrey Lyon wrote: Would the policy process be an appropriate venue for a proposition to change the ARIN mission, restricting it's activities exclusively to registration services while requiring a reduction in fees and budget? Jeffrey - Some historical perspective: ARIN not raised fees to my knowledge, but has actually lowered them 4 or 5 times over its 12 year history. ARIN's mission is set by the Board of Trustees, and lies within the purposes of the articles of incorporation of ARIN. I'll note that the articles encompass remarkable breadth, so the setting the mission turns out to be fairly important to keep ARIN focused appropriately. We have added initiatives in the past (e.g. this years extensive education and outreach regarding IPv4/IPv6) based on input received (predominantly at the Public Policy and Members meeting) and can remove them just as easily, but setting mission does not lie per se within the Policy process; it is a Board function to review and update the mission periodically. (Two minor notes: if you want an *ongoing* restraint on mission scope, it would really need be placed by the Board into the Bylaws with an significant hurdle precluding future revision, and should have some specificity, e.g. exclusively registration services could easily be read as either including or excluding abuse/fraud investigation, depending on the particular reader's inclination) /John John Curran President and CEO ARIN
Re: Geolocation tools - IPv6 style
On 2010-08-16 13:01, Harry Strongburg wrote: Hello NANOG, first time writing to here. My inquiry for you is on the subject of IPv6 Geolocation tools; or better yet, the lack accuracy in them. My main problem comes from YouTube.com and other Google Geolocation required tools (Google Voice, being an example). I must set network.dns.disableIPv6 to true just to access a lot of videos on YouTube, and to access my Google voice and similar services. I am unsure what country it thinks I am from when I access via IPv6, but it sure thinks I am foreign to the US. [Well. you do have a .lu domain in your email address] The moment you have the ability to go to amazon/ebay/$onlineshop and order all kinds of random junk and give your address to the retailers in question and this has been done enough all the geolocation database will be nicely filled after a while. Thus don't forget to provide all your private details in as many places as possible, the more they know about you, the better they can serve you. Just wait a few years and all will be fine, when IPv4 just started to be used there was none if this geolocation stuff either. Geolocation for restricting based on 'copyright regions' or similar things is the worst idea ever btw, especially as one can simply get a VPS with some VPN in the location that you need it and voila, you get around these silly restrictions, just like getting a .lu domain. Of course everybody knowsunderstands this except for layer 8 and up. Greets, Jeroen
Re: BCP38 exceptions for RFC1918 space
What does originating mean? Creating the packets? Or forwarding them? Either way, there's no excuse. First off, remember that BCP38 and 1918 don't apply on your set of interconnected private networks, no matter how big a net it is. You want to filter between two of your private nets, go ahead. You don't want to, that's OK to. The fun starts when those packets leave your network(s) and hit the public Internet. Now that we have that squared away... Either that intermediate router originated the ICMP 'frag needed' packet, in which case somebody needs to be smacked for originating a 1918-addressed packet on the public internet, or it's forwarding the packet. And if it's forwarding the packet, then somebody *else* needs to be smacked for injecting that packet into the public internet. What *possible* use case would require a 1918-sourced packet to be traversing the public internet? We're all waiting with bated breath to hear this one. ;) It's great for showing in traceroutes who the heel is. Do I win a prize? ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: Lightly used IP addresses
John, That was just the elevator speech, I wouldn't go off and write an entire proposal without a better understanding on how the community at large feels about the issue and exactly where the boundary would be drawn. My intent was not primarily cost, the registration fees are indeed low. I was just musing that limiting scope would have the ripple effect of reducing budget and thus putting more money in the hands of operators. It would be like a stimulus that doesn't cost any tax payer money ;). Best regards, Jeff On Mon, Aug 16, 2010 at 3:32 PM, John Curran jcur...@arin.net wrote: On Aug 15, 2010, at 11:31 PM, Jeffrey Lyon wrote: Would the policy process be an appropriate venue for a proposition to change the ARIN mission, restricting it's activities exclusively to registration services while requiring a reduction in fees and budget? Jeffrey - Some historical perspective: ARIN not raised fees to my knowledge, but has actually lowered them 4 or 5 times over its 12 year history. ARIN's mission is set by the Board of Trustees, and lies within the purposes of the articles of incorporation of ARIN. I'll note that the articles encompass remarkable breadth, so the setting the mission turns out to be fairly important to keep ARIN focused appropriately. We have added initiatives in the past (e.g. this years extensive education and outreach regarding IPv4/IPv6) based on input received (predominantly at the Public Policy and Members meeting) and can remove them just as easily, but setting mission does not lie per se within the Policy process; it is a Board function to review and update the mission periodically. (Two minor notes: if you want an *ongoing* restraint on mission scope, it would really need be placed by the Board into the Bylaws with an significant hurdle precluding future revision, and should have some specificity, e.g. exclusively registration services could easily be read as either including or excluding abuse/fraud investigation, depending on the particular reader's inclination) /John John Curran President and CEO ARIN -- Jeffrey Lyon, Leadership Team jeffrey.l...@blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Follow us on Twitter at http://twitter.com/ddosprotection to find out about news, promotions, and (gasp!) system outages which are updated in real time. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to protect your booty.
Re: Lightly used IP addresses
The retort you want to make is that ARIN just wouldn't do that. That's not the kind of people they are. Fine. So update the LRSA so it doesn't carefully and pervasively establish ARIN's legal right to behave that way. John/Steve, Bill makes a reasonable point here. Is there a way to, in the next round of LRSA mods, include something to the effect of: Under the ARIN Policy Development Process, the board will not ratify any policy which exclusively affects LRSA signatories in a manner inconsistent with its effect on other resource holders. === That's probably not ideal wording, but, I hope it conveys the general idea and I hope smarter people can find better language. It does seem to me to be a reasonable request and consistent with the intent of the LRSA. If you prefer that I submit this via ACSP I will do so. However, it seems to me it could fall within the same scope as the other clarification John offered earlier. Owen
Re: Lightly used IP addresses
On Aug 16, 2010, at 8:04 AM, Owen DeLong wrote: John/Steve, Just me (we don't pay Steve to read Nanog, although I do forward him legalistic emails depending on content :-) Bill makes a reasonable point here. Is there a way to, in the next round of LRSA mods, include something to the effect of: Under the ARIN Policy Development Process, the board will not ratify any policy which exclusively affects LRSA signatories in a manner inconsistent with its effect on other resource holders. === That's probably not ideal wording, but, I hope it conveys the general idea and I hope smarter people can find better language. It does seem to me to be a reasonable request and consistent with the intent of the LRSA. If you prefer that I submit this via ACSP I will do so. However, it seems to me it could fall within the same scope as the other clarification John offered earlier. I'll run with it, but would ask you send in to the suggestion process so that it doesn't get lost given our level of activity nowadays. Thanks! /John John Curran President and CEO ARIN
Re: Geolocation tools - IPv6 style
On Aug 16, 2010, at 4:41 AM, Jeroen Massar wrote: On 2010-08-16 13:01, Harry Strongburg wrote: Hello NANOG, first time writing to here. My inquiry for you is on the subject of IPv6 Geolocation tools; or better yet, the lack accuracy in them. My main problem comes from YouTube.com and other Google Geolocation required tools (Google Voice, being an example). I must set network.dns.disableIPv6 to true just to access a lot of videos on YouTube, and to access my Google voice and similar services. I am unsure what country it thinks I am from when I access via IPv6, but it sure thinks I am foreign to the US. [Well. you do have a .lu domain in your email address] The moment you have the ability to go to amazon/ebay/$onlineshop and order all kinds of random junk and give your address to the retailers in question and this has been done enough all the geolocation database will be nicely filled after a while. Thus don't forget to provide all your private details in as many places as possible, the more they know about you, the better they can serve you. Wow... That's pretty absurd. I order stuff from Amazon/etc. from IP addresses all over the world to be shipped to my office or my home in California. Does that mean that the Geolocation things are getting confused about all of these IP addresses I use at random and moving them to California? If that's the case, no wonder Geolocation by IP is such a quagmire of inaccuracy. Just wait a few years and all will be fine, when IPv4 just started to be used there was none if this geolocation stuff either. And even in IPv4 it's still wrong as often as not. Geolocation for restricting based on 'copyright regions' or similar things is the worst idea ever btw, especially as one can simply get a VPS with some VPN in the location that you need it and voila, you get around these silly restrictions, just like getting a .lu domain. Of course everybody knowsunderstands this except for layer 8 and up. For once, Jeroen, I happen to agree with you, although I think you'd be surprised at the number of layer 4-7 people who actually don't get it. Owen
Re: Numbering nameservers and resolvers
Once upon a time, Patrick W. Gilmore patr...@ianai.net said: 1) Use different prefixes. A single prefix going down should not kill your entire network. (Nameservers and resolvers being unreachable breaks the whole Internet as far as users are concerned.) How do you do this in the IPv6 world, where I get a single /32? Will others accept announcements of two /33s to better handle things like this? -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: Numbering nameservers and resolvers
On Aug 16, 2010, at 6:03 AM, Chris Adams wrote: Once upon a time, Patrick W. Gilmore patr...@ianai.net said: 1) Use different prefixes. A single prefix going down should not kill your entire network. (Nameservers and resolvers being unreachable breaks the whole Internet as far as users are concerned.) How do you do this in the IPv6 world, where I get a single /32? Will others accept announcements of two /33s to better handle things like this? The better solution is to trade secondary services with some other provider. Sure, it's a bit of a pain keeping up with the new zones to be added and old zones to be removed back and forth, but, it's a great way to have your authoritative servers truly diverse and independent. Owen
Re: Numbering nameservers and resolvers
On Aug 16, 2010, at 9:03 AM, Chris Adams wrote: Once upon a time, Patrick W. Gilmore patr...@ianai.net said: 1) Use different prefixes. A single prefix going down should not kill your entire network. (Nameservers and resolvers being unreachable breaks the whole Internet as far as users are concerned.) How do you do this in the IPv6 world, where I get a single /32? Will others accept announcements of two /33s to better handle things like this? Oobviously I was not thinking clearly, since I was only considering v4. =) But you do what you can. Some people have only a single v4 prefixes as well. If you can't use more than one prefix, then don't. Other good suggestions were things like ensuring the default exit point for each NS was a different vector. If you have only one exit point, that is not possible. But it does not mean the suggestion is bad. -- TTFN, patrick
Re: Numbering nameservers and resolvers
In IPv6 you should be able to advertise up to /48 with no problem... Arie On Mon, Aug 16, 2010 at 4:03 PM, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Patrick W. Gilmore patr...@ianai.net said: 1) Use different prefixes. A single prefix going down should not kill your entire network. (Nameservers and resolvers being unreachable breaks the whole Internet as far as users are concerned.) How do you do this in the IPv6 world, where I get a single /32? Will others accept announcements of two /33s to better handle things like this? -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: BCP38 exceptions for RFC1918 space
On Mon, 16 Aug 2010 06:50:00 CDT, Joe Greco said: What *possible* use case would require a 1918-sourced packet to be traversing the public internet? We're all waiting with bated breath to hear this one. ;) It's great for showing in traceroutes who the heel is. Like I said, at that point it's name-n-shame time. pgpuIXgUVU1aq.pgp Description: PGP signature
Re: Geolocation tools - IPv6 style
I have the feeling that the systems is not able to understand at all IPv6 for geolocation therefore default to foreign. I'm not aware of anyone providing IPv6 geolocation at the moment? Anyone has pointers? - Original Message - From: Harry Strongburg harry.na...@harry.lu To: nanog@nanog.org Sent: Monday, 16 August, 2010 11:01:01 PM Subject: Geolocation tools - IPv6 style Hello NANOG, first time writing to here. My inquiry for you is on the subject of IPv6 Geolocation tools; or better yet, the lack accuracy in them. My main problem comes from YouTube.com and other Google Geolocation required tools (Google Voice, being an example). I must set network.dns.disableIPv6 to true just to access a lot of videos on YouTube, and to access my Google voice and similar services. I am unsure what country it thinks I am from when I access via IPv6, but it sure thinks I am foreign to the US. I understand that all Geolocation can, at most, point to the local routing station of that person's ISP. The current progress in the IPv6 field of geolocation is mostly pointing at countries, not even states or cities unlike IPv4. Is there something majorly different about the ability to track IPs in v6, than there was in v4? Or are the main producers of this data just busy / do not see IPv6 as being profitable / not worth their time? Another problem I have (which isn't really relevant to the subject, but if anyone has the same problem when loading via IPv6 I would be interested in hearing about it), would be the loading of YouTube content. Pages will seemingly load partially, and always be Waiting on s.ytimg.com. http://s.ytimg.com/ loads instantly for me via IPv6, but not via videos. Has anyone else experenced the same problem? If I use v4 to load YouTube, the video instantly loads. There could be heavy load from my broker (he.net), but all other sites load instantly. Thanks for your time.
Re: Geolocation tools - IPv6 style
On 2010-08-16 14:52, Owen DeLong wrote: [..] Thus don't forget to provide all your private details in as many places as possible, the more they know about you, the better they can serve you. Wow... That's pretty absurd. I order stuff from Amazon/etc. from IP addresses all over the world to be shipped to my office or my home in California. Does that mean that the Geolocation things are getting confused about all of these IP addresses I use at random and moving them to California? If that's the case, no wonder Geolocation by IP is such a quagmire of inaccuracy. If you where actually running a larger site then you would know that having millions upon millions of customers returning from a certain range of addresses and providing their details which then match up give you a confidence factor, then just set that at factor X you locate that address down another level etc. Thus that one time that you go and order from some site and ship it home won't influence it all that much, as a hundred/thousand other people will have provided a more 'local' address to where that IP is used. Indeed, those systems cannot be 100% accurate, so what, if you tunnel it won't matter anyway. There are always ways around, it does work for most cases and that is what it is good enough for. [..] For once, Jeroen, I happen to agree with you, although I think you'd be surprised at the number of layer 4-7 people who actually don't get it. Let alone the supposed layer 3 people... Greets, Jeroen
Re: Lightly used IP addresses
Randy Bush wrote: and why in hell would i trust these organizations with any control of my routing via rpki certification? they have always said thay would never be involved in routing, but if they control the certification chain, they have a direct stranglehold they can use to extort fees. Kind of interesting to consider how a successful implementation of RPKI might change the rules of this game we all play in. I tried talking about that at ARIN in Toronto, not certain I was clear enough. Joe
Re: Lightly used IP addresses
Randy Bush wrote: Yet most of the bad ideas in the past 15 years have actually come from the IETF (TLA's, no end site multihoming, RA religion), some of which have actually been fixed by the RIR's. no, they were fixed within the ietf. that's my blood you are taking about, and i know where and by whom it was spent. the fracking rirs, in the name of marla and and lee, actually went to the ietf last month with a proposal to push address policy back to the ietf from the ops. and they just did not get thomas's proposal to move more policy from ietf back to ops. randy I would appreciate it greatly if you could elaborate a bit more, perhaps with some links. Joe
Re: Geolocation tools - IPv6 style
On Tue, 17 Aug 2010 01:39:47 +1200 (FJT), Franck Martin fra...@genius.com wrote: I have the feeling that the systems is not able to understand at all IPv6 for geolocation therefore default to foreign. I'm not aware of anyone providing IPv6 geolocation at the moment? Anyone has pointers? Maxmind has an IPv6 database at http://www.maxmind.com/app/geolitecountry It is very rudimentary. Given that the number of native IPv6 connections on the residential market is still very limited, it will, at best, return the location of your tunnel provider. Not very useful right now, especially of your tunnel provider is not local to you. Patrick Vande Walle
Re: Lightly used IP addresses
Joe - Excellent question, and one which I know is getting some public policy attention. There is a session at upcoming Internet Governance Forum (IGF) in Vilnius http://www.intgovforum.org/cms/index.php/component/chronocontact/?chronoformname=WSProposals2010Viewwspid=158 specifically covering some of these issues. I also believe that some of the IETF sidr working group folks have noted the need for local policy support so that ISPs can decide to trust routes, even if not verifiable from their configured Trust Anchor. This is probably an essential control for most ISPs to have, even if never needed. /John John Curran President and CEO ARIN On Aug 16, 2010, at 9:57 AM, Joe Maimon jmai...@ttec.com wrote: ... Kind of interesting to consider how a successful implementation of RPKI might change the rules of this game we all play in. I tried talking about that at ARIN in Toronto, not certain I was clear enough. Joe
RE: Lightly used IP addresses
-Original Message- From: Randy Bush [mailto:ra...@psg.com] Sent: Friday, August 13, 2010 10:13 PM To: Kevin Loch Cc: North American Network Operators Group Subject: Re: Lightly used IP addresses the fracking rirs, in the name of marla and and lee, actually went to the ietf last month with a proposal to push address policy back to the ietf from the ops. and they just did not get thomas's proposal to move more policy from ietf back to ops. You mischaracterize my position. Check the minutes when posted. Check the names on the draft. and, to continue the red herring with jc, i bet you 500 yen that arin paid their travel expenses to go to maastricht nl to do this stupid thing. You lose your bet. Lee randy
One Wilshire Radio Room
Hello all, I'm looking for someone with space in the One Wilshire Radio Room. Please contact me off list. Thanks Max (310) 906-0296 max.cl...@gmail.com
Re: Lightly used IP addresses
On Mon, 16 Aug 2010 09:57:51 EDT, Joe Maimon said: Kind of interesting to consider how a successful implementation of RPKI might change the rules of this game we all play in. I tried talking about that at ARIN in Toronto, not certain I was clear enough. I'm not at all convinced this would help all that much. A PKI would allow better verification of authentication - but how many providers currently have doubts about who the other end of their BGP session is? I'm sure most of the ones who care have already set up TCPMD5 and/or TTL hacks, and the rest wouldn't deploy an RPKI. The real problem is authorization - and the same people who don't currently apply filtering of BGP announcements won't deploy a PKI. So the people who care already have other tools to do most of the work, and the ones who don't care won't deploy. Sure it may be nice and allow automation of some parts of the mess, but I'm not seeing a big window here for it being a game-changer. If somebody has a good case for how it *will* be a game-changer, I'm all ears. pgppboS8H7CGA.pgp Description: PGP signature
RE: Lightly used IP addresses
On Sat, 14 Aug 2010, Frank Bulk wrote: This week I was told by my sales person at Red Condor that I'm the only one of his customers that is asking for IPv6. He sounded annoyed and it seemed like he was trying to make me feel bad for being the only oddball pushing the IPv6 feature requirement. FWIW, I asked the same question. My guy was polite, but w/o info. John Springer
Re: Lightly used IP addresses
valdis.kletni...@vt.edu wrote: On Mon, 16 Aug 2010 09:57:51 EDT, Joe Maimon said: Kind of interesting to consider how a successful implementation of RPKI might change the rules of this game we all play in. I tried talking about that at ARIN in Toronto, not certain I was clear enough. I'm not at all convinced this would help all that much. A PKI would allow better verification of authentication - but how many providers currently have doubts about who the other end of their BGP session is? I'm sure most of the ones who care have already set up TCPMD5 and/or TTL hacks, and the rest wouldn't deploy an RPKI. The real problem is authorization - and the same people who don't currently apply filtering of BGP announcements won't deploy a PKI. So the people who care already have other tools to do most of the work, and the ones who don't care won't deploy. Sure it may be nice and allow automation of some parts of the mess, but I'm not seeing a big window here for it being a game-changer. What you are saying is that you have doubts that there will be a successful implementation of RPKI that will properly secure BGP. If somebody has a good case for how it *will* be a game-changer, I'm all ears. However, Randy's point seemed me to be one I had brought up before. Can the RiR's still pass the theoretical fork test if RPKI were to be successfully and globally deployed? I am glad to hear that others who are likely far more competent than I are seriously examining the issue and seem to have similar concerns. The topic of this sub-thread isnt about the technological challenge of securing BGP and the routing of prefixes, it is about the political implications of successfully doing so and what the resulting impact on operations may be. Joe
Re: Lightly used IP addresses
On 16/08/10 09:47 -0700, John Springer wrote: On Sat, 14 Aug 2010, Frank Bulk wrote: This week I was told by my sales person at Red Condor that I'm the only one of his customers that is asking for IPv6. He sounded annoyed and it seemed like he was trying to make me feel bad for being the only oddball pushing the IPv6 feature requirement. FWIW, I asked the same question. My guy was polite, but w/o info. John Springer Hi Frank, I was actually told that there was some demand for it, and that they were targeting 2011 for support, which was acknowledged when I brought it up again in a difference conference call. I'll note that they just got bought out, which may change their priorities, for better or worse. -- Dan White
Re: Lightly used IP addresses
and, to continue the red herring with jc, i bet you 500 yen that arin paid their travel expenses to go to maastricht nl to do this stupid thing. You lose your bet. then owe you 500Y. paypal? randy
Re: Lightly used IP addresses
Kind of interesting to consider how a successful implementation of RPKI might change the rules of this game we all play in. I tried talking about that at ARIN in Toronto, not certain I was clear enough. first, let's remember that the rpki is a distributed database which has a number of possible applications. the first technical application on the horizon is route origin validation. I'm not at all convinced this would help all that much. A PKI would allow better verification of authentication - but how many providers currently have doubts about who the other end of their BGP session is? I'm sure most of the ones who care have already set up TCPMD5 and/or TTL hacks, and the rest wouldn't deploy an RPKI. route origin validation is not about authenticating your neighbor. it is about being able to base your routing policy on whether the origin asn of an announcement is authorized to originate a particular prefix. it is stopping fat fingers such as pk/youtube, 7007, and the every day accidental mis-announcements of others' prefixes. randy
Fiber Cut in the DC Area
Is anyone aware of a fiber cut that could be affecting the Washington DC area? Just opened a ticket with Verizon and heard of a fiber cut through some side conversations. -- Mike Gatti
Re: Lightly used IP addresses
On 16/08/2010 21:46, Randy Bush wrote: it is stopping fat fingers such as pk/youtube, 7007, and the every day accidental mis-announcements of others' prefixes. I am dying to hear the explanation of why the people who didn't bother with irrdb filters are going to latch on en-masse to rpki thereby preventing a repeat of the 7007/youtube incidents. Nick
Re: Lightly used IP addresses
In message 4c69cb8d.4000...@foobar.org, Nick Hilliard writes: On 16/08/2010 21:46, Randy Bush wrote: it is stopping fat fingers such as pk/youtube, 7007, and the every day accidental mis-announcements of others' prefixes. I am dying to hear the explanation of why the people who didn't bother with irrdb filters are going to latch on en-masse to rpki thereby preventing a repeat of the 7007/youtube incidents. More people will be willing to trust the databases if they know that they can be verified as (mostly) correct rather than hoping that they are correct. Nick -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
