Re: BCP38.info
Jared Mauch wrote on 1/28/14 10:11 PM: 192.168.0.1 has a rule that says send UDP/53 packets I process to 172.16.0.1. Since i'm outside it's NAT, the rule ends up taking the source IP, which isn't part of it's NAT set, and ends up copying my source IP into the packet, then forwards it to the DNS server. This is really broken. Do you have any idea as to why such rule is implemented? I also heard that some CPE implement exactly the same logic if one spoof src IP inside their NAT. I think that the Spoofer project discards tests from the inside NAT, but maybe they track such cases? Andrei
Re: BCP38.info
Hi, Jared Mauch wrote on 1/28/14 9:03 PM: I'd rather share some data and how others can observe this to determine how we can approach a fix. Someone spoofing your IP address out some other carrier is something you may be interested to know about, even if you have a non-spoofing network. At the Internet Society we are flashing out an idea of an anti-spoofing movement, where ISPs can list themselves as not spoofing-capable on our website. The requirement is that they can demonstrate that they block spoofed packets, for instance by successfully running the Spoofer test. I think your, Jared, test can add to this picture. Sort of a positive spin on the name and shame technique. It is not ideal, as one test is not a real proof of such capability, but might help raising awareness, at least. Does this sound as something that can be useful and fly? Andrei
Re: Opensource tools for inventory and troubleticketing
On 14-01-28 11:08 AM, Alexander Bochmann wrote: ...on Fri, Jan 24, 2014 at 10:37:14AM +0100, Octavio Alfageme wrote: network, but we are starting to need a better inventory of services and network resources and better troubleticketing procedures. We can not afford acquiring For the inventory and documentation part, Netdot is pretty cool: https://osl.uoregon.edu/redmine/projects/netdot/wiki Netdot is awesome, single set of VLANs and address ranges aside. If your switches / devices support all the proper SNMP MIBs, it will draw your network topology for you. As for ticketing, around here quite a few people are using OTRS (http://otrs.org/) - but I have no experience with that myself. Something like Redmine should be more leightweight and will probably do the job too... I've heard good things about OTRS but my personal favorite is Request Tracker (http://www.bestpractical.com/rt/). It can be a bit daunting to get running the first time due to the sheer number of perl modules required, I'm always happy to help if anyone needs a hand getting it working. -- Looking for (employment|contract) work in the Internet industry, preferably working remotely. Building / Supporting the net since 2400 baud was the hot thing. Ask for a resume! ispbuil...@gmail.com
BGP multihoming with two address spaces
I am seeking some feedback/help with my BGP configuration. I am peering with two providers level3 and tw. Unfortunately all of my address spaces are preferring the route over tw rather than level3. I have tried Prepending my AS and the carriers AS to the path on the tw side and I see those update being accepted by internet routers, but everyone is still preferring to install the tw routes rather than level3. I was trying to advertise each provider's address space out their connections and then use the other for backup. Now however everything is coming in through tw and no one seems to like level3. Thanks in advance for any guidance or assistance. Joe
Re: BGP multihoming with two address spaces
How are you announcing your address space now? On Wed, Jan 29, 2014 at 12:32 PM, Joseph Jenkins j...@breathe-underwater.com wrote: I am seeking some feedback/help with my BGP configuration. I am peering with two providers level3 and tw. Unfortunately all of my address spaces are preferring the route over tw rather than level3. I have tried Prepending my AS and the carriers AS to the path on the tw side and I see those update being accepted by internet routers, but everyone is still preferring to install the tw routes rather than level3. I was trying to advertise each provider's address space out their connections and then use the other for backup. Now however everything is coming in through tw and no one seems to like level3. Thanks in advance for any guidance or assistance. Joe -- Ristic Sasa -- mob: +381652221123 fax: +381618208488 -- Molim Vas da ne štampate ovaj e-mail ukoliko Vam zaista nije potreban na papiru. Hvala!
Re: BGP multihoming with two address spaces
I am announcing two separate /24s. 8.37.93.0 and 207.114.212.0. Joe On Jan 29, 2014, at 4:21 AM, Sasa Ristic ristic.s...@gmail.com wrote: How are you announcing your address space now? On Wed, Jan 29, 2014 at 12:32 PM, Joseph Jenkins j...@breathe-underwater.com wrote: I am seeking some feedback/help with my BGP configuration. I am peering with two providers level3 and tw. Unfortunately all of my address spaces are preferring the route over tw rather than level3. I have tried Prepending my AS and the carriers AS to the path on the tw side and I see those update being accepted by internet routers, but everyone is still preferring to install the tw routes rather than level3. I was trying to advertise each provider's address space out their connections and then use the other for backup. Now however everything is coming in through tw and no one seems to like level3. Thanks in advance for any guidance or assistance. Joe -- Ristic Sasa -- mob: +381652221123 fax: +381618208488 -- Molim Vas da ne štampate ovaj e-mail ukoliko Vam zaista nije potreban na papiru. Hvala!
RE: BGP multihoming with two address spaces
Perhaps L3 is preferring the routes it hears from TW over the ones it hears from you. Perhaps there is a community string you can attach to your announcements to one or both providers which can help you further manipulate what they do with your routes ... -Original Message- From: Joseph Jenkins [mailto:j...@breathe-underwater.com] Sent: Wednesday, January 29, 2014 7:45 AM Cc: nanog@nanog.org Subject: Re: BGP multihoming with two address spaces I am announcing two separate /24s. 8.37.93.0 and 207.114.212.0. Joe On Jan 29, 2014, at 4:21 AM, Sasa Ristic ristic.s...@gmail.com wrote: How are you announcing your address space now? On Wed, Jan 29, 2014 at 12:32 PM, Joseph Jenkins j...@breathe-underwater.com wrote: I am seeking some feedback/help with my BGP configuration. I am peering with two providers level3 and tw. Unfortunately all of my address spaces are preferring the route over tw rather than level3. I have tried Prepending my AS and the carriers AS to the path on the tw side and I see those update being accepted by internet routers, but everyone is still preferring to install the tw routes rather than level3. I was trying to advertise each provider's address space out their connections and then use the other for backup. Now however everything is coming in through tw and no one seems to like level3. Thanks in advance for any guidance or assistance. Joe -- Ristic Sasa -- mob: +381652221123 fax: +381618208488 -- Molim Vas da ne štampate ovaj e-mail ukoliko Vam zaista nije potreban na papiru. Hvala!
Re: BGP multihoming with two address spaces
Another thing to keep in mind that some providers will use local pref. as well for traffic engineering, Looking at the TW Telecom Community strings, it would appear that they do... http://www.onesc.net/communities/as4323/ http://www.onesc.net/communities/as3356/ Try using the communities to influence your traffic engineering. BTW, I took a quick look at Routeviews looking glass for you ... Here is what I see 8.37.93.0/24 is only being advertised via your TW Telecom connection (Possible Filters issues with Level3 ?) 207.114.212.0/24 is being advertised via both TW Telecom and Level3.. and in case of Routeviews, it is preferring the Level3 connection. The above is for inbound traffic only... For outbound, if you want to use both connections, then you will have to create an ACL to change the Local Pref so that you can use one or the other provider as the preferred route. Regards. Faisal Imtiaz Snappy Internet Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net - Original Message - From: Adam Greene maill...@webjogger.net To: nanog@nanog.org Sent: Wednesday, January 29, 2014 9:20:32 AM Subject: RE: BGP multihoming with two address spaces Perhaps L3 is preferring the routes it hears from TW over the ones it hears from you. Perhaps there is a community string you can attach to your announcements to one or both providers which can help you further manipulate what they do with your routes ... -Original Message- From: Joseph Jenkins [mailto:j...@breathe-underwater.com] Sent: Wednesday, January 29, 2014 7:45 AM Cc: nanog@nanog.org Subject: Re: BGP multihoming with two address spaces I am announcing two separate /24s. 8.37.93.0 and 207.114.212.0. Joe On Jan 29, 2014, at 4:21 AM, Sasa Ristic ristic.s...@gmail.com wrote: How are you announcing your address space now? On Wed, Jan 29, 2014 at 12:32 PM, Joseph Jenkins j...@breathe-underwater.com wrote: I am seeking some feedback/help with my BGP configuration. I am peering with two providers level3 and tw. Unfortunately all of my address spaces are preferring the route over tw rather than level3. I have tried Prepending my AS and the carriers AS to the path on the tw side and I see those update being accepted by internet routers, but everyone is still preferring to install the tw routes rather than level3. I was trying to advertise each provider's address space out their connections and then use the other for backup. Now however everything is coming in through tw and no one seems to like level3. Thanks in advance for any guidance or assistance. Joe -- Ristic Sasa -- mob: +381652221123 fax: +381618208488 -- Molim Vas da ne štampate ovaj e-mail ukoliko Vam zaista nije potreban na papiru. Hvala!
Re: BGP multihoming with two address spaces
It is likely that level3 is aggregating your route, but tw can't. Longest match wins. -- Jakob Heitz. Date: Wed, 29 Jan 2014 03:32:17 -0800 From: Joseph Jenkins j...@breathe-underwater.com I am seeking some feedback/help with my BGP configuration. I am peering with two providers level3 and tw. Unfortunately all of my address spaces are preferring the route over tw rather than level3. I have tried Prepending my AS and the carriers AS to the path on the tw side and I see those update being accepted by internet routers, but everyone is still preferring to install the tw routes rather than level3. I was trying to advertise each provider's address space out their connections and then use the other for backup. Now however everything is coming in through tw and no one seems to like level3. Thanks in advance for any guidance or assistance. Joe
Re: BGP multihoming with two address spaces
According to telnet://route-server.twtelecom.net and http://lookingglass.level3.net/bgp/lg_bgp_main.php BGP is working as designed. Your single prepend on one prefix with TWTC causes a slight preference for LVL3. Add another prepend if you want to further balance your ingress load away from TWTC. Or for more coarse adjustment, use the TWTC feature communities to reduce their local preference below that of customer default (115 for TWTC). Use 4323:100 for transit default. ../C On Wed, Jan 29, 2014 at 3:32 AM, Joseph Jenkins j...@breathe-underwater.comwrote: I am seeking some feedback/help with my BGP configuration. I am peering with two providers level3 and tw. Unfortunately all of my address spaces are preferring the route over tw rather than level3. I have tried Prepending my AS and the carriers AS to the path on the tw side and I see those update being accepted by internet routers, but everyone is still preferring to install the tw routes rather than level3. I was trying to advertise each provider's address space out their connections and then use the other for backup. Now however everything is coming in through tw and no one seems to like level3. Thanks in advance for any guidance or assistance. Joe
Re: Fiber Bypass Switch
NTT-AT presented their optical bypass products at LINX81, seems like they might do what you want: http://www.ntt-at.com/product/optical-switch/ I haven't used them myself. Aled On 27 January 2014 19:26, Keyser, Philip pkey...@fibertech.com wrote: Looking for something similar to this. http://www.moxa.com/product/OBU-102_Series.htm -Original Message- From: Matthew Crocker [mailto:matt...@corp.crocker.com] Sent: Monday, January 27, 2014 2:16 PM To: Keyser, Philip Cc: nanog@nanog.org Subject: Re: Fiber Bypass Switch Something like this? http://www.alcon-tech.com/pdfs/Optical-Protection-Switch-FSXpert.pdf -- Matthew S. Crocker President Crocker Communications, Inc. PO BOX 710 Greenfield, MA 01302-0710 E: matt...@crocker.commailto:matt...@crocker.com P: (413) 746-2760 F: (413) 746-3704 W: http://www.crocker.com On Jan 27, 2014, at 1:40 PM, Keyser, Philip pkey...@fibertech.commailto: pkey...@fibertech.com wrote: Does anyone have any recommendations for a fiber bypass switch? I am looking for something capable of 10G that when there is a power hit will fail over to route traffic out the network ports and away from that site's with the customer handoff. Thanks, Phil Keyser __ This email has been scanned for spam and viruses by the MessageLabs Email Security System. For all email inquiries, please submit a ticket to the IT Helpdesk: ithelpd...@fibertech.commailto:ithelpd...@fibertech.com __
Fw: ipv6 newbie question
Is it best practice to have the internet facing BGP router's peering ip (or for that matter any key gateway or security appliance) use a statically configured address or use EUI-64 auto config? I have seen comments on both sides and am leaning to EUI-64 (except for the VIP's like the ASA's failover ip ) -Philip
Re: ipv6 newbie question
On Jan 29, 2014, at 12:35 PM, Philip Lavine source_ro...@yahoo.com wrote: Is it best practice to have the internet facing BGP router's peering ip (or for that matter any key gateway or security appliance) use a statically configured address or use EUI-64 auto config? I have seen comments on both sides and am leaning to EUI-64 (except for the VIP's like the ASA's failover ip ) We configure customers with a statically assigned IP address for BGP peering. They get the IP assigned to them as part of the turn-up process. The same process happens for IP Classic aka v4 as v6. - Jared (If you are a AS2914 customer and aren't doing IPv6 with us, don't hesitate to ping me and I will get your information over to that team).
Re: Fw: ipv6 newbie question
On 29/01/2014 17:35, Philip Lavine wrote: Is it best practice to have the internet facing BGP router's peering ip (or for that matter any key gateway or security appliance) use a statically configured address or use EUI-64 auto config? how are you going to set up the bgp session from the remote side to an eui-64 auto configured address on your side? best use static here. And make sure to disable RA (with fire, i.e. disable send + receive + answering solicited requests) and EUI64. If it's a point to point link, use a /126 or /127 netmask. Nick
Re: ipv6 newbie question
Hi, Is it best practice to have the internet facing BGP router's peering ip (or for that matter any key gateway or security appliance) use a statically configured address or use EUI-64 auto config? I have seen comments on both sides and am leaning to EUI-64 (except for the VIP's like the ASA's failover ip ) Static. You don't want to have to contact all of your peers when the EUI-64 address changes when you replace hardware. Cheers Sander
Re: Fw: ipv6 newbie question
On Wed, 29 Jan 2014, Nick Hilliard wrote: On 29/01/2014 17:35, Philip Lavine wrote: Is it best practice to have the internet facing BGP router's peering ip (or for that matter any key gateway or security appliance) use a statically configured address or use EUI-64 auto config? how are you going to set up the bgp session from the remote side to an eui-64 auto configured address on your side? best use static here. And make sure to disable RA (with fire, i.e. disable send + receive + answering solicited requests) and EUI64. If it's a point to point link, use a /126 or /127 netmask. +1. I've seem some providers do /64 on their point-to-point links. I don't have an issue with that, and the whole /64 vs /126 or /127 debate has been thoroughly beaten into the ground. No need to re-hash it. I have never seen a provider use a pseudo-dynamic address on an interface/BGP peer. Having to reconfigure a BGP session because a provider did a hardware upgrade or moved my link to a new interface would not make me happy. jms
RE: Fw: ipv6 newbie question
Agreed, We do a /64 allocation which is reserved for each point to point link, but then subnet it to a /126 for actual use. That way we've got a /64 available if it's ever needed, while keeping the broadcast domain small for now when we don't. JJ Stonebraker IP Network Engineering Grande Communications 512.878.5627 -Original Message- From: Justin M. Streiner [mailto:strei...@cluebyfour.org] Sent: Wednesday, January 29, 2014 8:44 AM To: NANOG list Subject: Re: Fw: ipv6 newbie question On Wed, 29 Jan 2014, Nick Hilliard wrote: On 29/01/2014 17:35, Philip Lavine wrote: Is it best practice to have the internet facing BGP router's peering ip (or for that matter any key gateway or security appliance) use a statically configured address or use EUI-64 auto config? how are you going to set up the bgp session from the remote side to an eui-64 auto configured address on your side? best use static here. And make sure to disable RA (with fire, i.e. disable send + receive + answering solicited requests) and EUI64. If it's a point to point link, use a /126 or /127 netmask. +1. I've seem some providers do /64 on their point-to-point links. I don't have an issue with that, and the whole /64 vs /126 or /127 debate has been thoroughly beaten into the ground. No need to re-hash it. I have never seen a provider use a pseudo-dynamic address on an interface/BGP peer. Having to reconfigure a BGP session because a provider did a hardware upgrade or moved my link to a new interface would not make me happy. jms
Re: ipv6 newbie question
There are tradeoffs in both directions.
Personally I think administrative simplicity wins over security through
obscurity, so I recommend each organization pick a random pair of static
addresses and use those two addresses for all of their point to point links.
e.g. If your prefix for a given link is 2001:db8::::/64, and you
randomly choose the suffixes dead:beef:cafe:babe and dead:beef:cafe:feed as
your end-point addresses, then the links would be numbered
2001:db8:::dead:beef:cafe:{babe,feed}.
YMMV and I don't recommend using my examples in practice.
Owen
On Jan 29, 2014, at 12:35 PM, Philip Lavine source_ro...@yahoo.com wrote:
Is it best practice to have the internet facing BGP router's peering ip (or
for that matter any key gateway or security appliance) use a statically
configured address or use EUI-64 auto config?
I have seen comments on both sides and am leaning to EUI-64 (except for the
VIP's like the ASA's failover ip )
-Philip
Re: Fw: ipv6 newbie question
If only there was a best practices doc to help here... Oh wait there is! http://bcop.nanog.org/index.php/IPv6_Subnetting It doesn't specifically mention BGP so as to be protocol agnostic but does recommend allocating a /64 and using a /126 or /127. On Wed, Jan 29, 2014 at 12:35 PM, Philip Lavine source_ro...@yahoo.com wrote: Is it best practice to have the internet facing BGP router's peering ip (or for that matter any key gateway or security appliance) use a statically configured address or use EUI-64 auto config? I have seen comments on both sides and am leaning to EUI-64 (except for the VIP's like the ASA's failover ip ) -Philip -- [stillwa...@gmail.com ~]$ cat .signature cat: .signature: No such file or directory [stillwa...@gmail.com ~]$
Re: BGP multihoming with two address spaces
On Wed, Jan 29, 2014 at 6:32 AM, Joseph Jenkins j...@breathe-underwater.com wrote: I am seeking some feedback/help with my BGP configuration. I am peering with two providers level3 and tw. Unfortunately all of my address spaces are preferring the route over tw rather than level3. Hi Joe, I had a situation like this a couple months ago but my two providers were: Centurylink and Centurylink. No matter how many prepends I added, the traffic preferred the slow link in one state to the fast link in another. It turned out that Centurylink (Embarq) gets to the Internet via Centurylink (Qwest). Unless modified by communities, Qwest has a local pref that delivers traffic to direct customers in preference to other ASes. And the folks in Embarq's support had no idea what Qwest was doing. This sort of local-pref default seems to be a common practice with backbones. It's very annoying. I wish they'd stop. 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
Tata communications issues
I am looking for a clueful networking contact at Tata communications as the IP noc is not being terribly helpful. When i turn up advertisements to you I suddenly become unreachable to large swaths of the Internet. Please contact me off-list Thanks in advance -Ryan
Re: BGP multihoming with two address spaces
This sort of local-pref default seems to be a common practice with backbones. It's very annoying. I wish they'd stop. Most of their customers would actually be very unhappy if they stopped. This local-pref default prevents many many problems and in the vast majority of cases provides the desired result. Yes, it's important to know what is going on and to be able to ask your providers to make necessary changes in circumstances where this is not optimal (either via community or ticket), but I assure you that if every backbone turned this off suddenly, most internet users would be very !HAPPY. Owen
Re: BGP multihoming with two address spaces
Le 29/01/2014 20:34, Owen DeLong a écrit : This sort of local-pref default seems to be a common practice with backbones. It's very annoying. I wish they'd stop. Most of their customers would actually be very unhappy if they stopped. This local-pref default prevents many many problems and in the vast majority of cases provides the desired result. Yes, it's important to know what is going on and to be able to ask your providers to make necessary changes in circumstances where this is not optimal (either via community or ticket), but I assure you that if every backbone turned this off suddenly, most internet users would be very !HAPPY. The underlying reason for this type of local preference has to do with an assumption of cost (which, given current transit prices, may be true or not): cost(customer) 0 cost(peer) cost(provider) ..., thus local_pref(customer) local_pref(peer) local_pref(provider), and as you say Owen, many actors sharing a policy simplifies our view of things a bit. Another way of assigning local preference of a route may factor in measured or perceived path quality, slightly more complex, but not a crime at all :-). Cheers, mh Owen
BGP multihoming
Apologies for a RIPE question on NANOG, although I believe this issue will soon enough to be relevant for the ARIN region as well. I had a customer ask if we could provide him with BGP such that he could be multihomed. He already has 128 IP addresses from another ISP. Obviously a /25 is a non go for multihoming as everyone are going to ignore his route. I would then need to help him with acquiring a /24 PI. Which appears to be impossible as RIPE does no longer assign PI space and PI can not be reassigned and thus be bought. Is assigning a /24 from my own PA space for the purpose of BGP multihoming considered sufficient need? Could he get some PI from another region, such as ARIN? How does others handle this situation? Regards, Baldur
Re: BGP multihoming
On Wed, 29 Jan 2014, Baldur Norddahl wrote: I had a customer ask if we could provide him with BGP such that he could be multihomed. He already has 128 IP addresses from another ISP. Obviously a /25 is a non go for multihoming as everyone are going to ignore his route. Not necessarily everyone, but a lot of providers will filter that. More headaches than it's worth. I would then need to help him with acquiring a /24 PI. Which appears to be impossible as RIPE does no longer assign PI space and PI can not be reassigned and thus be bought. Is assigning a /24 from my own PA space for the purpose of BGP multihoming considered sufficient need? I haven't looked at RIPE policies in a while, but I would imagine that assigning a customer a /24 of your space because they need to multihome is considered a justifiable use. Could he get some PI from another region, such as ARIN? How does others handle this situation? Most likely no, for two reasons. 1. Most RIRs don't assign IPv4 /24s to end-users except in very special cases, 2. The smallest PI block they would assign is usually something like a /21 or /22, so your customer would need to be justifiably using that much space before they could apply for a PI block, and 3, if the customer is in an area outside of $RIR's service area, they would direct them to contact the appropriate RIR. I also hope your customer is making plans for IPv6 deployment. jms
Re: BGP multihoming
Interesting question, and to add to that, I have another one. With the rapid depletion of IPv4 address space from ARIN, are there private end-user companies that are leasing off unused portions of their assigned address blocks to other private and unrelated end user companies? Does that cause any problems where address space is being advertised from a non-assigned AS? Thanks, Mike On 1/29/14 12:32 PM, Baldur Norddahl baldur.nordd...@gmail.com wrote: Apologies for a RIPE question on NANOG, although I believe this issue will soon enough to be relevant for the ARIN region as well. I had a customer ask if we could provide him with BGP such that he could be multihomed. He already has 128 IP addresses from another ISP. Obviously a /25 is a non go for multihoming as everyone are going to ignore his route. I would then need to help him with acquiring a /24 PI. Which appears to be impossible as RIPE does no longer assign PI space and PI can not be reassigned and thus be bought. Is assigning a /24 from my own PA space for the purpose of BGP multihoming considered sufficient need? Could he get some PI from another region, such as ARIN? How does others handle this situation? Regards, Baldur
Re: BGP multihoming
* Baldur Norddahl Apologies for a RIPE question on NANOG, although I believe this issue will soon enough to be relevant for the ARIN region as well. Relevant perhaps, but as the policies differ, so may the correct answers... I had a customer ask if we could provide him with BGP such that he could be multihomed. He already has 128 IP addresses from another ISP. Obviously a /25 is a non go for multihoming as everyone are going to ignore his route. I would then need to help him with acquiring a /24 PI. Which appears to be impossible as RIPE does no longer assign PI space and PI can not be reassigned and thus be bought. There is another option, namely if your customer becomes a RIPE NCC member (i.e., an LIR), he'll get a PA /22. (Of course, you could offer to perform all the administrative work is to start and operate an LIR on your customer's behalf, for a reasonable fee.) Is assigning a /24 from my own PA space for the purpose of BGP multihoming considered sufficient need? Not with current policies, no, as the multihoming clause only applied specifically to PI assignments, not pA. However, if you customer can show that he'll be using at least 128 addresses (i.e., 50% of a /24) within a year, he does qualify for an assignment of a /24. Plans to renumber out of his current /25 would count towards that. Tore
FW: Updated ARIN allocation information
ARIN would like to share two items of information that may be of interest to the community. First, ARIN has recently begun to issue address space from its last contiguous /8, 104.0.0.0 /8. The minimum allocation size for this /8 will be a /24. You may wish to adjust any filters you have in place accordingly. More information on the IP address space administered by ARIN can be found on our web site at: https://www.arin.net/knowledge/ip_blocks.html Additionally, ARIN has placed 23.128.0.0/10 in its reserves in accordance with the policy Dedicated IPv4 block to facilitate IPv6 Deployment (NRPM 4.10). There have been no allocations made from this block as of yet, however, once we do begin issuing from this block, the minimum allocation size for this /10 will be a /28 and the maximum allocation size will be a /24. You may wish to adjust any filters you have in place accordingly. More information on this policy can be found on our website here: https://www.arin.net/policy/nrpm.html#four10 Regards, Leslie Nobile Director, Registration Services American Registry for Internet Numbers (ARIN)
Re: FW: Updated ARIN allocation information
On 1/29/14, 14:01, Leslie Nobile wrote: Additionally, ARIN has placed 23.128.0.0/10 in its reserves in accordance with the policy Dedicated IPv4 block to facilitate IPv6 Deployment (NRPM 4.10). There have been no allocations made from this block as of yet, however, once we do begin issuing from this block, the minimum allocation size for this /10 will be a /28 and the maximum allocation size will be a /24. You may wish to adjust any filters you have in place accordingly. I know ARIN doesn't care about routability and all that, but good luck with those /28s. ~Seth
Re: Fw: ipv6 newbie question
rfc 6164
looking for good AU dedicated server providers..
Hello, Was wondering if anyone could share any experiences. Prerequsites: a.) reliable upstream provider with established peering. b.) relatively acessible support staff. c.) FreeBSD preferring but CentOS is ok... any help would greatly be appreciated. Cheers, Carlos.
Re: looking for good AU dedicated server providers..
On Wed, Jan 29, 2014 at 06:37:35PM -0500, Carlos Kamtha wrote: b.) relatively acessible support staff. Accessable for what? Hardware maintenance, or full-service outsourced sysadmin assistance? What timezones, and what communication method? (Also, there's AusNOG if you want to get local opinions)
[NANOG-announce] NANOG On The Road - San Diego
Colleagues: In partnership, the American Registry for Internet Numbers (ARIN) and the North American Network Operators Group (NANOG) will bring ARIN+NANOG on the Road to San Diego, CA on Tuesday, February 25, 2014. The one day event will be held at the Handerly Hotel Resort. Please pass along this information to those who would benefit from attending a free event featuring educational sessions, great discussions, and networking opportunities! Morning sessions will get attendees up to speed on Internet number resource management, ARIN technical services, current policy discussions and more. Afternoon sessions will feature NANOG Tutorials on Network Security, IPv6, Traceroutes, BGB, including an update on the NANOG Best Current Operational Practice (BCOP) project. Complete information and meeting links are available on the NANOG websitehttps://www.nanog.org/meetings/road2/home . Should you have any questions, please feel free to send them to nanog-supp...@nanog.org. Sincerely, Betty -- Betty Burke NANOG Executive Director 48377 Fremont Boulevard, Suite 117 Fremont, CA 94538 Tel: +1 510 492 4030 ___ NANOG-announce mailing list nanog-annou...@mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce
Re: FW: Updated ARIN allocation information
On Wed, Jan 29, 2014 at 5:16 PM, Seth Mattinen se...@rollernet.us wrote: On 1/29/14, 14:01, Leslie Nobile wrote: Additionally, ARIN has placed 23.128.0.0/10 in its reserves in accordance with the policy Dedicated IPv4 block to facilitate IPv6 Deployment (NRPM 4.10). There have been no allocations made from this block as of yet, however, once we do begin issuing from this block, the minimum allocation size for this /10 will be a /28 and the maximum allocation size will be a /24. You may wish to adjust any filters you have in place accordingly. I know ARIN doesn't care about routability and all that, but good luck with those /28s. maybe these weren't meant to be used outside the local ASN? :) I do wonder though what the purpose of this block is? If it's to be used inside the local ASN (as seems to be indicated based upon minimum allocation sizes) then why not use the IETF marked 100.64/10 space instead? Global-uniqueness? ok, sure... There will need to be popcorn though, for this event. -chris
Re: BGP multihoming
On Wed, Jan 29, 2014 at 3:45 PM, Michael Braun (michbrau) michb...@cisco.com wrote: Does that cause any problems where address space is being advertised from a non-assigned AS? how do you mean 'non-assigned' ? perhaps you have an example in the routing system today you could point at?
RE: looking for good AU dedicated server providers..
Carlos, Is this for Wan connectivity between where you're and Australia? Best, Nanda -Original Message- From: Carlos Kamtha [mailto:kam...@ak-labs.net] Sent: Thursday, January 30, 2014 5:08 AM To: nanog@nanog.org Subject: looking for good AU dedicated server providers.. Hello, Was wondering if anyone could share any experiences. Prerequsites: a.) reliable upstream provider with established peering. b.) relatively acessible support staff. c.) FreeBSD preferring but CentOS is ok... any help would greatly be appreciated. Cheers, Carlos.
Re: FW: Updated ARIN allocation information
In message CAL9jLabq=CSJSv4hufv+LSJ4d2JBhLQPukDcX3gxtc6-1PZA=a...@mail.gmail.com , Christopher Morrow writes: On Wed, Jan 29, 2014 at 5:16 PM, Seth Mattinen se...@rollernet.us wrote: On 1/29/14, 14:01, Leslie Nobile wrote: Additionally, ARIN has placed 23.128.0.0/10 in its reserves in accordance with the policy Dedicated IPv4 block to facilitate IPv6 Deployment (NRPM 4.10). There have been no allocations made from this block as of yet, however, once we do begin issuing from this block, the minimum allocation size for this /10 will be a /28 and the maximum allocation size will be a /24. You may wish to adjust any filters you have in place accordingly. I know ARIN doesn't care about routability and all that, but good luck with those /28s. maybe these weren't meant to be used outside the local ASN? :) I do wonder though what the purpose of this block is? If it's to be used inside the local ASN (as seems to be indicated based upon minimum allocation sizes) then why not use the IETF marked 100.64/10 space instead? Global-uniqueness? ok, sure... There will need to be popcorn though, for this event. -chris Or you could just accept that there needs to be more routing slots as the number of businesses on the net increases. I can see some interesting anti-cartel law suits happening if ISP's refuse to accept /28's from this block. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: FW: Updated ARIN allocation information
On Thursday, January 30, 2014 07:17:11 AM Mark Andrews wrote: Or you could just accept that there needs to be more routing slots as the number of businesses on the net increases. I can see some interesting anti-cartel law suits happening if ISP's refuse to accept /28's from this block. I understand the reasoning behind RIR's (and the community that supports them) not caring about routability, but if there is a lesson we can learn from IPv4, it is that perhaps that divorce is not entirely practical. It might be a good idea to think about how RIR's (and the community that supports them) could care about routability, so we don't end up in the same situation with IPv6, whenever that will be, or if any of us will be alive. It's definitely too late to do anything about it for IPv4, which means there will be even more lessons to learn in the coming months/years... I know it is a moving target (advances in FIB memory is not something an RIR [and the community that supports them] can depend on, for example), but I also don't think it makes complete sense for the RIR's (and the community that supports them) to be in a utopia about this - that it will all just sort itself out. Mark. signature.asc Description: This is a digitally signed message part.
