Coloc at Equinix Singapor
Hi We search a colocation at Equinix Singapore: 1/4 Rack with in option 1/2 Rack. anyone know of a company that offers this service ? Cordialy Olivier
Re: /128 IPv6 prefixs in the wild?
You'll still probably carry the /128 loopbacks in your IGP to deal with your iBGP mesh. Owen On Dec 14, 2011, at 9:54 PM, Glen Kent wrote: Hi, In the service provider networks, would we usually see a large number of /128 prefixs in the v6 FIB tables? In an IP/MPLS world, core routers in the service provider network learn the /32 loopback IPv4 addresses so that they can establish BGP/Targetted LDP sessions with those. They then establish LSPs and VPN tunnels. Since we dont have RSVP for IPv6 and LDP for IPv6 (not yet RFC) we cannot form MPLS tunnels in a pure IPv6 only network. GIven this, would v6 routers have large number of /128 prefixes? What are the scenarios when IPv6 routers would learn a large number of /128 prefixes? I would presume that most IPv6 prefixes that the routers have to install are less than /64, since the latter 64 is the host part. Is this correct? Glen
Re: Range using single-mode SFPs across multi-mode fiber
Some idiot jumpered runs that existed between 3 different buildings. That person did not know about the 550m limit that we also follow. Sent from my iPhone On Dec 14, 2011, at 22:38, Keegan Holley keegan.hol...@sungard.com wrote: 2011/12/14 oliver rothschild orothsch...@gmail.com Thanks to all who responded to my clumsy first question (both on matters of etiquette and technology). The group I work with (we are a small project acting as a last mile provider) was in the midst of deploying this solution when I posed the question. We put the single mode Juniper SFPs (LX) on to a run of approximately 1670 meters. How did you end up with a MM run this long? SX optics are only rated at 500 meters at best. Even with mode conditioning jumpers more the 1km is a risk. I'm glad it held up during testing though. Just out of curiosity did you purchase dark from a provider? Is it inside of a building?
RE: Multiple ISP Load Balancing
This is why I wish they would release it as open source or sell it to someone else, the product really did work well, the kernel in the underlying Linux is the biggest hurdle. Thanks, -Drew -Original Message- From: Rampley Jr, Jim F [mailto:jim.ramp...@chartercom.com] Sent: Wednesday, December 14, 2011 3:42 PM To: Justin M. Streiner; nanog@nanog.org Subject: RE: Multiple ISP Load Balancing We have specific situations where we have successfully used the Avaya CNA tool (old Route Science Patch Control). Not for load balancing, but for sub second failover from primary to a backup paths over MPLS VPN's. This is done on our internal network where we have MPLS VPN's sometimes over multiple carriers where normal convergence times are 30 seconds to 1 minute across an external provider. It's not easy to setup initially, but once you get it setup and the kinks worked out I've been impressed with its ability to test a path and move traffic at the first hint of trouble. Jim -Original Message- From: Justin M. Streiner [mailto:strei...@cluebyfour.org] Sent: Wednesday, December 14, 2011 2:10 PM To: nanog@nanog.org Subject: Re: Multiple ISP Load Balancing On Wed, 14 Dec 2011, Holmes,David A wrote: From time to time some have posted questions asking if BGP load balancers such as the old Routescience Pathcontrol device are still around, and if not what have others found to replace that function. I have used the Routescience device with much success 10 years ago when it first came on the market, but since then a full BGP feed has become much larger, Routescience has been bought by Avaya, then discontinued, and other competitors such as Sockeye, Netvmg have been acquired by other companies. It's important to keep in mind what load-balancing is and isn't in this case. The terminology gap can be important because load-balancing (more accurately, load-sharing) in the context of internetwork traffic engineering is very different from load-balancing pools of servers in a data center. Some people can (and sometimes do) confuse the two, which can cause unrealistic expectations to be set :) Achieving a perfect split of network traffic across two or more upstream links rarely happens in the real world. General good practice is to put bandwidth where the network traffic wants to go, but that can be a moving target, and executives and accountants don't like those :) Traffic engineering still has a place on many networks, for a veriety of reasons (technical, financial, political, some combination of these), but as other posters have mentioned, it's often done manually, i.e. looking at Netflow reports, seeing where your traffic is going/coming from, adjusting BGP policies accordingly. Repeat as needed. Since traffic profiles can change over time, any policy tweaks that are put in place need to be reviewed periodically. Depending on how much prep work and planning you're willing to do, you can put a fairly rich set of internal BGP communities in place to control things like localpref, MEDs, selective prepends, and tagging outbound advertisements with provider-specific communities. With that kind of structure, you could control many aspects of your traffic engineering from a route server, rather than having to tinker with route policies on each outside-facing router. One caveat: If your route server crashes or has to be taken down for maintenance, the traffic patterns that were being tweaked by your policy framework could start to revert to the way the traffic would flow in its un-altered state, which could cause you some unintended headaches. jms E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.
Re: Range using single-mode SFPs across multi-mode fiber
On Wed, 14 Dec 2011, Keegan Holley wrote: 2011/12/14 oliver rothschild orothsch...@gmail.com How did you end up with a MM run this long? SX optics are only rated at 500 meters at best. Even with mode conditioning jumpers more the 1km is a risk. I'm glad it held up during testing though. Just out of curiosity did you purchase dark from a provider? Is it inside of a building? Legacy 10baseFL/100baseFX/FDDI can run fairly long distances over OM1. In the past I've run 100baseFX over OM1 runs with multiple cross-connects, out to about 2 km. jms
RE: /128 IPv6 prefixes in the wild?
I think you will learn a lot of /128s from IGP, but not from eBGP. I consider the wild to be the DFZ or similar type of network and in that case, you should not see advertisements for anything longer than a /48. This is not hard and fast, but please correct me if I'm wrong. - Brian J. -Original Message- From: Mark Tinka [mailto:mti...@globaltransit.net] Sent: Thursday, December 15, 2011 12:30 AM To: nanog@nanog.org Subject: Re: /128 IPv6 prefixs in the wild? On Thursday, December 15, 2011 01:54:56 PM Glen Kent wrote: In an IP/MPLS world, core routers in the service provider network learn the /32 loopback IPv4 addresses so that they can establish BGP/Targetted LDP sessions with those. That's right - not sure how things would have been if 'draft-swallow-mpls-aggregate-fec-01' had gained some traction. They then establish LSPs and VPN tunnels. Indeed. Since we dont have RSVP for IPv6 and LDP for IPv6 (not yet RFC) we cannot form MPLS tunnels in a pure IPv6 only network. GIven this, would v6 routers have large number of /128 prefixes? What are the scenarios when IPv6 routers would learn a large number of /128 prefixes? I suspect ISP's that choose to assign broadband customers /128 addresses because they only ever need one address may be a situation where you see rise given to this. I would presume that most IPv6 prefixes that the routers have to install are less than /64, since the latter 64 is the host part. Is this correct? This is certainly going to re-open some wounds, but no, not all providers are assigning /64 to interfaces. Some (like us) are using longer prefix lengths such as /112 and /126. But as for /128 prefix lengths, aside from the fact that Loopbacks will be floating around the network, whether you're using them to signal MPLS LSP's or setup iBGP sessions, you will see them with ISP's that assign them to customers and choose not to aggregate them at specific edge routers. Cheers, Mark.
Is AS information useful for security?
Is a good knowledge of either origin-AS, or next-AS with respect to flows valuable in establishing, monitoring, or re-enforcing a security posture? In what ways? TIA, Joe
Re: De-bogon not possible via arin policy.
On Wed, 14 Dec 2011, David Conrad wrote: I'm confused. When justifying 'need' in an address allocation request, what difference does it make whether an address in use was allocated by an RIR or was squatted upon? Last I heard, renumbering out of (say) RFC 1918 space into public space was still a justification for address space. Has this changed? I tend to think of squatting in the sense of using a resource (could be an IP address block, could be an empty house, could be just about anything) that the person who is using it does not have permission to do so. I would think that definition holds up even when taking into account that people do not own their IP address allocations. An RIR or ISP assigning address space to a particular entity would establish a legitimate (but not irrevocable) claim to use a block of address space. Squatting is maybe one notch above hijacking in this sense. jms
Re: /128 IPv6 prefixs in the wild?
On Thu, 15 Dec 2011, Glen Kent wrote: In the service provider networks, would we usually see a large number of /128 prefixs in the v6 FIB tables? If you have /128s on the loopbacks of your routers, your other routers could learn the /128s for the loopbacks of your other routers through your IGP. What are the scenarios when IPv6 routers would learn a large number of /128 prefixes? Two questions: 1. What is a 'large number' in this case? 2. Are the addresses from your v6 range(s), or something else that wouldn't be coming from the outside world (link-local, etc)? I would presume that most IPv6 prefixes that the routers have to install are less than /64, since the latter 64 is the host part. Is this correct? Looking at the routing table on one of my lab routers, I only see the /64 for a remote network in its v6 routing table, along with the interface and link-local address of the router it wants to use to reach that destination. I do not see any separate entries for any smaller chunks of that /64. jms
Re: /128 IPv6 prefixs in the wild?
In a message written on Thu, Dec 15, 2011 at 11:24:56AM +0530, Glen Kent wrote: What are the scenarios when IPv6 routers would learn a large number of /128 prefixes? In addition to the loopback interfaces already mentioned, you may also see virtual addresses of several kinds. For instance an anycasted recursive resolver service may come in as a /128. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpOEvBZ5NRDw.pgp Description: PGP signature
Re: local_preference for transit traffic?
In a message written on Thu, Dec 15, 2011 at 02:24:13AM -0500, Keegan Holley wrote: I always assumed that taking in more traffic was a bad thing. I've heard about one sided peering agreements where one side is sending more traffic than the other needs them to transport. Am I missing something? Would this cause a shift in their favor allowing them to offload more customer traffic to their peers without complaint? It's one of many techniques used by peers to balance the ratio. However, there may be a simpler explanation. If you bill by the bit as a transit provider it's in your best interest to make sure your customer gets as many bits through you as possible. Plus if you can fill their pipe, they need to buy an upgrade to you. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgphT8XgPZ9yU.pgp Description: PGP signature
Re: Is AS information useful for security?
On Thu, 15 Dec 2011, Joe Loiacono wrote: Is a good knowledge of either origin-AS, or next-AS with respect to flows valuable in establishing, monitoring, or re-enforcing a security posture? In what ways? If I'm understanding your question correctly, I think it can be helpful, to a degree. It's always good to 'know your neighbors', but for the most part I don't think an organization's security posture would change very much, based strictly on next-AS. In the case of next-AS, you already know your neighbors somewhat, because you have some sort of a business relationship with them (your transit providers, peers, downstream BGP-speaking customers, etc). origin-AS could be another story. If you know of an AS that is being used by the bad guys for bad purposes, you can write a routing policy to dump all traffic to/from that AS into the bit bucket or take some other action that could be dictated by your security policy. In that case, a routing policy could be considered an extension of a security policy. jms
Re: De-bogon not possible via arin policy.
On 12/15/2011 09:07, Justin M. Streiner wrote: I tend to think of squatting in the sense of using a resource (could be an IP address block, could be an empty house, could be just about anything) that the person who is using it does not have permission to do so. I would think that definition holds up even when taking into account that people do not own their IP address allocations. An RIR or ISP assigning address space to a particular entity would establish a legitimate (but not irrevocable) claim to use a block of address space. Squatting is maybe one notch above hijacking in this sense. Well here's the thing about allocations. All an IP allocation is, is a entry in a data base saying an ORG has a right (from an RIR perspective) to use use an address range. Now a AS can actually use any IP space it wants internally, and if it gets another AS to accept their routes for that IP space and that AS's peers agree to accept those routes, the first AS can actually use that IP space. The RIR or IANA has zero legal authority to stop this as it's just a bunch of private networks agreeing on some one using IP space. Now this gets a lot more fun as we get closer to true IPv4 exhaustion. If there is a business case between two or more providers to side step a RIR process and recognize IP allocations that the RIR does not, who really has the power to stop them? Think about this, if you're a service provider in the US, and the big US networks agree to route your IP space that is actually registered to some network in Kazakhstan according to the RIR's, what will happen? from the service providers perspective the average user will have access to 99% of the US networks (which is really all people want :) and most likely half way decent connectivity to other AS's. Sure, this sucks, but 99% of the people don't care, and still provides better connectivity to services people want than IPv6 does. So follow the money and see how IPv4 exhaustion plays out ;) -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net
Re: De-bogon not possible via arin policy.
On 12/14/2011 11:14 PM, Jimmy Hess wrote: On Wed, Dec 14, 2011 at 10:47 PM, David Conradd...@virtualized.org wrote: [snip] I'm confused. When justifying 'need' in an address allocation request, what difference does it makewhether an address in use was allocated by an RIR or was squatted upon? Last I heard, renumberingout of (say) RFC 1918 space into public space was still a justification for address space. Has thischanged? It is a potential network change that could require additional address space, if an operator plans a complete and immediate renumbering, but the choice to renumber is not an automatic justification for the same number of non-RFC1918 IPs as the count of IPs available in their RFC1918 space networks. I'm sure the RIRs are not allowing that. A RFC1918 network is not a normal network; and this is not a renumbering in the same manner as a renumbering from public IP space to new public IP space. The operator might have to show why they shouldn't renumber their 1918 network partially, over time, in a manner compatible with the RIR policy for initial service provider allocations, instead of all at once. In other words: What is the technical justification that all those rfc1918 addressed hosts suddenly need to be moved immediately, and not over a normal allocation time frame for new public networks? Here's a simple one involving squat space: You have a network that internally is using *all* of 10.0.0.0/8 *and* 5.0.0.0/8 (because you have enough customers to fill two /8s). Now that 5.0.0.0/8 is being allocated, you need to move out of it (so that your users can reach the real 5.0.0.0/8 sites). Why wouldn't this be sufficient justification for a new /8 from ARIN? Matthew Kaufman
Re: De-bogon not possible via arin policy.
On Thu, 15 Dec 2011 07:42:40 PST, Matthew Kaufman said: Here's a simple one involving squat space: You have a network that internally is using *all* of 10.0.0.0/8 *and* 5.0.0.0/8 (because you have enough customers to fill two /8s). Now that 5.0.0.0/8 is being allocated, you need to move out of it (so that your users can reach the real 5.0.0.0/8 sites). Why wouldn't this be sufficient justification for a new /8 from ARIN? Because you can probably use the other two 10/8's you already have. And if thiose run out, a third 10/8 is cheap even on the secondary market. pgpNweTOlbLBh.pgp Description: PGP signature
Re: /128 IPv6 prefixes in the wild?
On Thursday, December 15, 2011 09:56:04 PM Brian Johnson wrote: I think you will learn a lot of /128s from IGP, but not from eBGP. I consider the wild to be the DFZ or similar type of network and in that case, you should not see advertisements for anything longer than a /48. This is not hard and fast, but please correct me if I'm wrong. Ideally, yes. Good filtering (against your peers, customers and upstreams) will ensure you keep anything longer than a /48 out of your AS. However, do note that if you provide customer-induced automated blackhole routing (where customers attach an evil community to an evil host route and send that to you in an eBGP update because you expect it), that's one other way to see /128's (or more appropriately, something longer than a /48) across eBGP sessions with customers. Also, if customers multi-home to you and they want to be able to load share traffic across the various links between their network and yours, you may be inclined to allow them to send longer subnets that have a NO_EXPORT community attached to them so that load sharing occurs within your network for their inbound traffic, but de-aggregated routes do not flood the rest of the Internet. This is another way you could get longer routes into your network, with the benefit of not polluting the global Internet. Among other scenarios... :-). Mark. signature.asc Description: This is a digitally signed message part.
Re: local_preference for transit traffic?
On Thursday, December 15, 2011 10:42:37 PM Leo Bicknell wrote: However, there may be a simpler explanation. If you bill by the bit as a transit provider it's in your best interest to make sure your customer gets as many bits through you as possible. Plus if you can fill their pipe, they need to buy an upgrade to you. Indeed. Mark. signature.asc Description: This is a digitally signed message part.
Re: De-bogon not possible via arin policy.
Jimmy, On Dec 14, 2011, at 11:14 PM, Jimmy Hess wrote: A RFC1918 network is not a normal network; and this is not a renumbering in the same manner as a renumbering from public IP space to new public IP space. I'll admit I haven't been following ARIN policy making for some time. Can you point to the ARIN policy that makes this distinction? In other words: What is the technical justification that all those rfc1918 addressed hosts suddenly need to be moved immediately, and not over a normal allocation time frame for new public networks? I used RFC 1918 space as an example. A more likely scenario is needing to renumber out of recently allocated squat space (particularly in situations where RFC 1918 is not an alternative). That means the RIR has to establish that the criterion is good enough. I have a rfc1918 /16 that I use, so give me a public /16, please is not good enough. That would essentially provide a backdoor around normal RIR justified need policy, if it were allowed.. Hmm. If one makes the assumption that the (1918/squat) address space is being used in an efficient manner and there is a business/technical requirement to renumber that space into public space, I would have thought the acceptance of justification would depend more on the business/technical requirement, not the fact that 1918/squat space is being used. Regards, -drc
Re: De-bogon not possible via arin policy.
On Dec 15, 2011, at 6:07 AM, Justin M. Streiner wrote: On Wed, 14 Dec 2011, David Conrad wrote: I'm confused. When justifying 'need' in an address allocation request, what difference does it make whether an address in use was allocated by an RIR or was squatted upon? Last I heard, renumbering out of (say) RFC 1918 space into public space was still a justification for address space. Has this changed? I tend to think of squatting in the sense of using a resource (could be an IP address block, could be an empty house, could be just about anything) that the person who is using it does not have permission to do so. Right, but how does that impact whether or not non-squat space is justified? From my perspective, the actual bit patterns associated with an address in use shouldn't have any impact on the whether or not it is deemed by our ARIN overlords to be needed to be in use. Regards, -drc
Re: local_preference for transit traffic?
2011/12/15 Mark Tinka mti...@globaltransit.net On Thursday, December 15, 2011 10:42:37 PM Leo Bicknell wrote: However, there may be a simpler explanation. If you bill by the bit as a transit provider it's in your best interest to make sure your customer gets as many bits through you as possible. Plus if you can fill their pipe, they need to buy an upgrade to you. Indeed. Forgive my ignorance, but are connections between ISP's normally billed by the bit? I'm a transit AS but not an ISP in the traditional sense, so I just have the normal monthly billing.
RE: Is AS information useful for security?
-Original Message- From: Justin M. Streiner [mailto:strei...@cluebyfour.org] Sent: Thursday, December 15, 2011 9:45 AM To: nanog@nanog.org Subject: Re: Is AS information useful for security? origin-AS could be another story. If you know of an AS that is being used by the bad guys for bad purposes, you can write a routing policy to dump all traffic to/from that AS into the bit bucket or take some other action that could be dictated by your security policy. In that case, a routing policy could be considered an extension of a security policy. I could be wrong here but I believe origin-AS uses a lookup from the routing table to figure out what the originAS for the source IP should be (and not what it explicitly IS) which means the information is unreliable. For example if someone is sending spoofed packets towards you the origin AS will always show up as the originator of the real route instead of the origin AS of the actual traffic. This is why it would be useful to have the originAS (from the actual origin) in the packet header. Thanks, -Drew
Re: local_preference for transit traffic?
On Friday, December 16, 2011 12:27:48 AM Keegan Holley wrote: Forgive my ignorance, but are connections between ISP's normally billed by the bit? I'm a transit AS but not an ISP in the traditional sense, so I just have the normal monthly billing. Per-bit billing, for us, is not a pre-requisite for us to encourage traffic toward our customers to use the transit link they purchase from us. Mark. signature.asc Description: This is a digitally signed message part.
Re: De-bogon not possible via arin policy.
In a message written on Wed, Dec 14, 2011 at 01:15:48PM -0800, Cameron Byrne wrote: But all I can qualify for is a /18, and then in 3 months maybe a /17. This is called slow start ? For an established business? https://www.arin.net/policy/nrpm.html#four216 You should be able to get a /16 under the immediate need policy if you can prove to ARIN you need it and can use it in 30 days or less. Otherwise, yes, the slow-start policies apply. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpBJfJyjezUh.pgp Description: PGP signature
Re: De-bogon not possible via arin policy.
On 12/15/2011 8:05 AM, valdis.kletni...@vt.edu wrote: On Thu, 15 Dec 2011 07:42:40 PST, Matthew Kaufman said: Here's a simple one involving squat space: You have a network that internally is using *all* of 10.0.0.0/8 *and* 5.0.0.0/8 (because you have enough customers to fill two /8s). Now that 5.0.0.0/8 is being allocated, you need to move out of it (so that your users can reach the real 5.0.0.0/8 sites). Why wouldn't this be sufficient justification for a new /8 from ARIN? Because you can probably use the other two 10/8's you already have. And if thiose run out, a third 10/8 is cheap even on the secondary market. You're assuming a network architecture which is not required by policy. Matthew Kaufman
Re: Is AS information useful for security?
On Thu, Dec 15, 2011 at 11:28:48AM -0500, Drew Weaver wrote: I could be wrong here but I believe origin-AS uses a lookup from the routing table to figure out what the originAS for the source IP should be (and not what it explicitly IS) which means the information is unreliable. Using a bit of Cisco jargon, i believe we speak of source peer-AS and asymmetric routing. True what you say but a more accurate information can be achieved by correlation, ie. against the input interface. This leaves open the case of input traffic from a shared medium ie. an IXP. If using sFlow, MAC layer information would be pretty much available for the job; if using NetFlow instead, NetFlow v9 (and IPFIX .. brrr) could come to the rescue .. if was not for lack of implementation of the MAC layer primitives for routed traffic (ie. not switched) by the vendors on the bigger pieces of iron (ie. no ASR1K, software routers, etc.). Cheers, Paolo
Re: De-bogon not possible via arin policy.
--- br...@bryanfields.net wrote: From: Bryan Fields br...@bryanfields.net Now this gets a lot more fun as we get closer to true IPv4 exhaustion. If there is a business case between two or more providers to side step a RIR process and recognize IP allocations that the RIR does not, who really has the power to stop them? -- The networking community in general. The usefulness of the space would be very limited. scott
RE: Range using single-mode SFPs across multi-mode fiber
The max limit for 100 base FX (100 Mbps Ethernet) is around 6600 feet. Many campus ductbank systems built in the 1990s when 10 and 100 Mbps Ethernet were the commodity speeds (before GiGE) used 62.5/125 MM fiber to connect buildings. It is not unusual to see long MM runs on campus facilities where 100 Mbps backbones once were the fastest speeds available. In those days, apart from longhaul telco use, singlemode fiber was usually only run for closed circuit TV (CCTV) use in the campus environment, and in places where 1990s SM was run for CCTV it can still be used for longhaul laser sfps, which to me shows that SM is future proof. SM even makes sense in short runs as attenuators can be placed on the send/receive strands to reduce the dB so the optical receiver is not saturated. -Original Message- From: Justin M. Streiner [mailto:strei...@cluebyfour.org] Sent: Thursday, December 15, 2011 5:53 AM To: Keegan Holley Cc: nanog@nanog.org; oliver rothschild Subject: Re: Range using single-mode SFPs across multi-mode fiber On Wed, 14 Dec 2011, Keegan Holley wrote: 2011/12/14 oliver rothschild orothsch...@gmail.com How did you end up with a MM run this long? SX optics are only rated at 500 meters at best. Even with mode conditioning jumpers more the 1km is a risk. I'm glad it held up during testing though. Just out of curiosity did you purchase dark from a provider? Is it inside of a building? Legacy 10baseFL/100baseFX/FDDI can run fairly long distances over OM1. In the past I've run 100baseFX over OM1 runs with multiple cross-connects, out to about 2 km. jms This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.
Re: De-bogon not possible via arin policy.
On Thu, Dec 15, 2011 at 10:53 AM, Matthew Kaufman matt...@matthew.at wrote: On 12/15/2011 8:05 AM, valdis.kletni...@vt.edu wrote: On Thu, 15 Dec 2011 07:42:40 PST, Matthew Kaufman said: Here's a simple one involving squat space: You have a network that internally is using *all* of 10.0.0.0/8 *and* 5.0.0.0/8 (because you have enough customers to fill two /8s). Now that 5.0.0.0/8 is being allocated, you need to move out of it (so that your users can reach the real 5.0.0.0/8 sites). Why wouldn't this be sufficient justification for a new /8 from ARIN? It is valid justification you may have available to obtain some additional address space from ARIN. Probably not a /8, however. With such a large request, you can be sure the RIR will want to vet it in great detail, and make sure everything is fully justified technically, to the letter and spirit of the policy. If it is, then you get a /8, providing it is available, and the policy is still justified need. If you don't immediately require an entire /8 equivalent, you can expect to get a smaller amount immediately. You are only allowed a 3 months supply, anyways, and you may not get to have the /8 as a single aggregate. The limitation is that Efficiently utilizing 10.0.0.0/8 or Efficiently utilizing 5.0.0.0/8 Cannot be used to obtain a /7 or another /8, because 10.0.0.0/8 and 5.0.0.0/8 are not your allocation. If the allocation is not yours, then you cannot apply the policy that says Efficient utilization of previous blocks assigned and requirement for more addresses as the justification for more IPs, because 10/8 wasn't assigned to you anyways. You are left having to justify based on number of simultaneous HOSTS on your network, not number of customers. The RIRs do not currently require you to utilize NAT or RFC1918 addresses for hosts on your network, so if you met the requirements, you can justify the allocations required to renumber your entire 10/8 and your entire 5/8 into public IP space, at the rate you intend to renumber them. You however don't get to say I have 10 million DSL customers, therefore, I get 10 million IPs, right now. Because you can probably use the other two 10/8's you already have. And if thiose run out, a third 10/8 is cheap even on the secondary market. You're assuming a network architecture which is not required by policy. Matthew Kaufman The RIRs do not require you to utilize NAT in the first place. It follows that they also don't require you to segment your network and re-use the same NAT ranges. But in utilizing NAT, you might be utilizing your address space inefficiently, because the pressure to utilize addresses efficiently is reduced by the large size of 1918 space. An example would be having 10 million dialup customers, with hosts that are only transiently connected to a network, and never 10 million simultaneously, each you addressed with a permanent IP. The problem with that, is you only get to assign addresses to addressable objects. When a device is not connected to your network, it is not an addressable object. In obtaining an allocation from an RIR, you can expect to be required to utilize your address space efficiently,which means that devices not connected to your network at any point in time are not hosts, and therefore do not have IP addresses assigned from you. And the number of IP addresses you can justify is related to the number of simultaneous connected devices. -- -JH
Re: De-bogon not possible via arin policy.
On Thu, 15 Dec 2011 10:42:40 -0500, Matthew Kaufman matt...@matthew.at wrote: Now that 5.0.0.0/8 is being allocated, you need to move out of it (so that your users can reach the real 5.0.0.0/8 sites). Why wouldn't this be sufficient justification for a new /8 from ARIN? Because it's not ARIN's job to clean up someone else's stupid. You chose to use address space that would eventually be allocated, thus creating a (future) mess for yourself; now you're left to live with it. (For the record, there's no easy way out of that mess now.)
Re: local_preference for transit traffic?
Jeff Wheeler writes: On Thu, Dec 15, 2011 at 1:07 AM, Keegan Holley keegan.hol...@sungard.com wrote: Had in interesting conversation with a transit AS on behalf of a customer where I found out they are using communities to raise the local preference That sounds like a disreputable practice. While not quite as obvious, some large transit ASes, like Level3, reset the origin to I (best) sometime between when they learn it and when they announce it to their customers and peers. This similarly causes them to suck in a bit more traffic than they might otherwise. Once upon a time, UUNET did the opposite by setting origin to unknown for peer routes, in an attempt to prefer customer routes over peer routes. We moved to local preference shortly thereafter as it became clear this was changing the routes in some meaningful way; if a customer was multihomed to us and another provider, this might affect path selection. (The original thought was that local pref might be too heavyweight, but of course later it became the standard.) Joe
Re: De-bogon not possible via arin policy.
On Dec 15, 2011, at 12:41 PM, Ricky Beam wrote: Because it's not ARIN's job to clean up someone else's stupid. ARIN's job (well, beyond the world travel, publishing comic books, handing out raffle prizes, etc.) is to allocate and register addresses according to community-defined documented policies. I had thought new allocations are based on demonstrated need. The fact that addresses are in use would seem to suggest they're needed. As I've said, I haven't been following ARIN's policy discussions -- can you point me to the policy that says allocations can be denied because you happened to have (demonstrably ill-advisedly) used the wrong bit patterns in setting up your network? Thanks, -drc
Re: De-bogon not possible via arin policy.
In a message written on Thu, Dec 15, 2011 at 01:36:32PM -0800, David Conrad wrote: ARIN's job (well, beyond the world travel, publishing comic books, handing out raffle prizes, etc.) is to allocate and register addresses according to community-defined documented policies. I had thought new allocations are based on demonstrated need. The fact that addresses are in use would seem to suggest they're needed. As I've said, I haven't been following ARIN's policy discussions -- can you point me to the policy that says allocations can be denied because you happened to have (demonstrably ill-advisedly) used the wrong bit patterns in setting up your network? The problem is that in use means different things to differnet folks. ifconfig em0 inet 10.0.0.1 255.0.0.0 I'm now using 16 million IP addresses at home. ARIN policy does not allow me to get 16 million public IP addresses as a result, based on the 1 machine I have configured at the moment. In the case at hand we don't know if the original poster configured up /16's on p2p links for two hosts each, or if they have an actual host up and pingable at every single IP address. ARIN has a duty to the community to ask these questions, because otherwise anyone could fabricate a need for as many addresses as they want. It would seem the original poster and ARIN have a disagrement in this case as to how many IP addresses are required to support their needs. Perhaps incomplete information was provided, perhaps ARIN staff got it wrong. No one on NANOG has enough information to know either way. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpS44ACx5Zz1.pgp Description: PGP signature
Re: De-bogon not possible via arin policy.
On 12/15/11 13:43 , Leo Bicknell wrote: In a message written on Thu, Dec 15, 2011 at 01:36:32PM -0800, David Conrad wrote: ARIN's job (well, beyond the world travel, publishing comic books, handing out raffle prizes, etc.) is to allocate and register addresses according to community-defined documented policies. I had thought new allocations are based on demonstrated need. The fact that addresses are in use would seem to suggest they're needed. As I've said, I haven't been following ARIN's policy discussions -- can you point me to the policy that says allocations can be denied because you happened to have (demonstrably ill-advisedly) used the wrong bit patterns in setting up your network? The problem is that in use means different things to differnet folks. ifconfig em0 inet 10.0.0.1 255.0.0.0 I'm now using 16 million IP addresses at home. ARIN policy does not allow me to get 16 million public IP addresses as a result, based on the 1 machine I have configured at the moment. In the case at hand we don't know if the original poster configured up /16's on p2p links for two hosts each, or if they have an actual host up and pingable at every single IP address. ARIN has a duty to the We know rather alot about the original posters' business, it has ~34 million wireless subscribers in north america. I think it's safe to assume that adequate docuementation could be provided. community to ask these questions, because otherwise anyone could fabricate a need for as many addresses as they want. It would seem the original poster and ARIN have a disagrement in this case as to how many IP addresses are required to support their needs. Perhaps incomplete information was provided, perhaps ARIN staff got it wrong. No one on NANOG has enough information to know either way.
Re: De-bogon not possible via arin policy.
On Thu, Dec 15, 2011 at 4:54 PM, Joel jaeggli joe...@bogus.com wrote: We know rather alot about the original posters' business, it has ~34 million wireless subscribers in north america. I think it's safe to assume that adequate docuementation could be provided. I missed the post where he supplied this information. I guess his company should have cheated the system, with full complicity of ARIN, like Verizon Wireless did a few years ago. http://marc.info/?l=nanogm=123406577704970w=4 -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts
Re: De-bogon not possible via arin policy.
On 15-Dec-11 15:54, Joel jaeggli wrote: On 12/15/11 13:43 , Leo Bicknell wrote: In a message written on Thu, Dec 15, 2011 at 01:36:32PM -0800, David Conrad wrote: ARIN's job (well, beyond the world travel, publishing comic books, handing out raffle prizes, etc.) is to allocate and register addresses according to community-defined documented policies. I had thought new allocations are based on demonstrated need. The fact that addresses are in use would seem to suggest they're needed. The problem is that in use means different things to differnet folks. ifconfig em0 inet 10.0.0.1 255.0.0.0 I'm now using 16 million IP addresses at home. ARIN policy does not allow me to get 16 million public IP addresses as a result, based on the 1 machine I have configured at the moment. We know rather alot about the original posters' business, it has ~34 million wireless subscribers in north america. For those that haven't bothered to look it up, folks appear to be referring to T-Mobile--a Cameron Byrne works there, and they fit the profile given. I think it's safe to assume that adequate docuementation could be provided. One might assume it /could/ be provided, but so far we have no evidence that it /has/ been provided or, if so, on what grounds ARIN rejected it as being adequate. Heck, so far we have no evidence that any request has even been filed or that the OP is who we think he is. All we have so far is the word of one person, using a Gmail address and the name of a T-Mobile employee, that such addresses were applied for and that ARIN denied the request. I'll also point out that, even if some of the above claims turn out to be true, T-Mobile almost certainly would have required ARIN to sign an NDA (as is customary for any almost any business dealings these days), so ARIN cannot defend itself against the ones that are not, leaving us only with the OP's obviously biased version of events and the ensuing speculation--and the OP probably knew that when he/she posted. Furthermore, it is a fact that not all of T-Mobile's ~34M customers are using IPv4-addressable devices, and they're certainly not all online at the same time, so a simple customer count does /not/ qualify as justification for getting that many addresses. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: De-bogon not possible via arin policy.
On Thu, 15 Dec 2011 16:36:32 -0500, David Conrad d...@virtualized.org wrote: ... I had thought new allocations are based on demonstrated need. The fact that addresses are in use would seem to suggest they're needed. That depends on how you see their demontrated need. The way I look at it, if you build your network squatting on someone elses addresses, that's a problem of your own making and does not equate to any immediate need on my (channeling ARIN) part. This is a mess they created for themselves and should have known was going to bite them in the ass sooner than later. Translation: they should have started working to resolve this a long time ago. (or never done it in the first place.) And if I may say, they've demonstrated no need at all for public address space. They simply need to stop using 5/8 as if it were 10/8 -- i.e. they need more private address space. They don't need *public* IPv4 space for that. They will need to re-engineer their network to handle the addressing overlaps (ala NAT444.)
Re: De-bogon not possible via arin policy.
In a message written on Thu, Dec 15, 2011 at 01:54:28PM -0800, Joel jaeggli wrote: We know rather alot about the original posters' business, it has ~34 million wireless subscribers in north america. I think it's safe to assume that adequate docuementation could be provided. As I suspect there are a few confused people here, the OP did not post that information. Google shows Cameron Byrne works at T-Moble USA, per his LinkedIn, and I believe Joel is citing that T-Moble has ~34 Million subscribers, which seems to match some recent info. It appears to me folks are _assuming_ his request to ARIN was for T-Moble, and covered all 34 Million users. Of course that still doesn't mean 34 million IP addresses are required. T-Moble sells phones today that can't do anything IP related (http://www.t-mobile.com/shop/Phones/cell-phone-detail.aspx?cell-phone=Samsung-t139, as an example), and even for the phones that can do IP not all of them are connected at once. I will repeat myself though, we don't know what was submitted to ARIN, or why they responded the way they did. Having the OP come whine to NANOG without us having that information is useless. ARIN's PPML list might be more helpful, or some AC members. Heck, even picking up the phone and talking to ARIN might work better. To bring this back on topic for NANOG though, they need to get it sorted quickly. ARIN shows an equivilent of 5.63 /8's in inventory right now. If 34 million addresses are needed, and can be used to 80% effiency that would require ~2.5 /8's worth of space. It would only take a couple of these sorts of requests and the free pool is gone. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpn3E5ssUUeh.pgp Description: PGP signature
Re: De-bogon not possible via arin policy.
On 12/15/2011 2:32 PM, Leo Bicknell wrote: It would only take a couple of these sorts of requests and the free pool is gone. Personally, I can't wait. Matthew Kaufman
Re: De-bogon not possible via arin policy.
On Thu, 15 Dec 2011 14:32:17 PST, Leo Bicknell said: 80% effiency that would require ~2.5 /8's worth of space. It would only take a couple of these sorts of requests and the free pool is gone. /me makes some popcorn. This could be fun. pgpCZOCgqbO2T.pgp Description: PGP signature
Re: De-bogon not possible via arin policy.
On 12/15/11 14:12 , Jeff Wheeler wrote: On Thu, Dec 15, 2011 at 4:54 PM, Joel jaeggli joe...@bogus.com wrote: We know rather alot about the original posters' business, it has ~34 million wireless subscribers in north america. I think it's safe to assume that adequate docuementation could be provided. I missed the post where he supplied this information. I imagine the NANOG community to be small enough that the regular participants should be known to each other. Possibly naive, I know. I guess his company should have cheated the system, with full complicity of ARIN, like Verizon Wireless did a few years ago. http://marc.info/?l=nanogm=123406577704970w=4 I figured the discussion was for illustrative purposes more than anything.
Re: De-bogon not possible via arin policy.
On 15-Dec-11 16:31, Ricky Beam wrote: On Thu, 15 Dec 2011 16:36:32 -0500, David Conrad d...@virtualized.org wrote: ... I had thought new allocations are based on demonstrated need. The fact that addresses are in use would seem to suggest they're needed. That depends on how you see their demontrated need. The way I look at it, if you build your network squatting on someone elses addresses, that's a problem of your own making and does not equate to any immediate need on my (channeling ARIN) part. However, if they actually have the number of hosts claimed, that justifies the space they're asking for. What addresses they're using today is irrelevant. ARIN policy only /suggests/ that they use RFC 1918 space; they are allowed to get public space if they want it. This is a mess they created for themselves and should have known was going to bite them in the ass sooner than later. Translation: they should have started working to resolve this a long time ago. (or never done it in the first place.) Agreed, but what's done is done. What /should/ have been done is now irrelevant. And if I may say, they've demonstrated no need at all for public address space. They simply need to stop using 5/8 as if it were 10/8 -- i.e. they need more private address space. They don't need *public* IPv4 space for that. They will need to re-engineer their network to handle the addressing overlaps (ala NAT444.) Presumably, they need to renumber out of 5/8 so that their customers can reach sites legitimately assigned addresses in 5/8. However, those customers seem to have gotten along okay for years without public addresses, so why not renumber them into a second instance of 10/8? When I was in the consulting world, I had one customer with eight instances of 10/8, so I know it's doable. If they want to give every customer a public address, IPv6 provides more than they could ever possibly use--and ~34M new IPv6 eyeballs would give the content industry a nice kick in the pants... S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: De-bogon not possible via arin policy.
On Dec 15, 2011 6:43 PM, Stephen Sprunk step...@sprunk.org wrote: On 15-Dec-11 16:31, Ricky Beam wrote: On Thu, 15 Dec 2011 16:36:32 -0500, David Conrad d...@virtualized.org wrote: ... I had thought new allocations are based on demonstrated need. The fact that addresses are in use would seem to suggest they're needed. That depends on how you see their demontrated need. The way I look at it, if you build your network squatting on someone elses addresses, that's a problem of your own making and does not equate to any immediate need on my (channeling ARIN) part. However, if they actually have the number of hosts claimed, that justifies the space they're asking for. What addresses they're using today is irrelevant. ARIN policy only /suggests/ that they use RFC 1918 space; they are allowed to get public space if they want it. Right. But actually getting the space seems to be the issue since the only way space comes out is slow start /18 or immediate need /16? Is that right ? This is a mess they created for themselves and should have known was going to bite them in the ass sooner than later. Translation: they should have started working to resolve this a long time ago. (or never done it in the first place.) Agreed, but what's done is done. What /should/ have been done is now irrelevant. Yes. Hind sight is 20/20... From bag phones to the iPhone, the evolution in cellular data has not been predictable. And if I may say, they've demonstrated no need at all for public address space. They simply need to stop using 5/8 as if it were 10/8 -- i.e. they need more private address space. They don't need *public* IPv4 space for that. They will need to re-engineer their network to handle the addressing overlaps (ala NAT444.) Presumably, they need to renumber out of 5/8 so that their customers can reach sites legitimately assigned addresses in 5/8. However, those customers seem to have gotten along okay for years without public addresses, so why not renumber them into a second instance of 10/8? When I was in the consulting world, I had one customer with eight instances of 10/8, so I know it's doable. Not always. Sometimes backend systems require customers use unique space, and that is really only the tip of that iceberg IMS does not work well with duplicate space. If they want to give every customer a public address, IPv6 provides more than they could ever possibly use--and ~34M new IPv6 eyeballs would give the content industry a nice kick in the pants... Yep. Sometimes I feel I personally preach and promote my ipv6 sermon too the point of being bothersome to the list. Apparently, my good word has not yet reached some. So, for all those that have considered ipv6 as the answer, I suggest you take the bold move of being part of the solution by ensuring your (and however you influence) phone does ipv6 on the cellular network. It is always good to lead by doing. On the T-Mobile USA network, the process is here https://sites.google.com/site/tmoipv6/lg-mytouch While I have not verified it myself, I hear the NEW gsm/umts galaxy nexus does ipv6 on 3g very well. http://www.newegg.com/Product/Product.aspx?Item=N82E16875176322 In all fairness, Verizon LTE has ipv6 as well. Regarding this thread in general, I asked a question about slow start and got a good answer about immediate need. Thanks ! Cb S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
Re: De-bogon not possible via arin policy.
In a message written on Thu, Dec 15, 2011 at 04:59:15PM -0800, Cameron Byrne wrote: Regarding this thread in general, I asked a question about slow start and got a good answer about immediate need. Thanks ! Note that the slow-start is not based on size (as far as I can remember) but on timeframe. That is, if you have a bunch of ARIN blocks you can request a 12 month supply based on past usage and best predictions. However, if your company has NO IPv4 space and you make your first request you get limited to 3 months worth of address space, 2nd request you get 6 months, and then 12 months with your 3rd and more requests. That's the slow-start. The feeling is that with no track record your predictions are, on average, less likely to be accurate. It's also my understanding that if you use all of the space you can immediately ask for more. Hypothetically, let's say ARIN gives a company with 34M subscribers a /18. Let's say said company can drop it in a DHCP server, and have 100% utilization in oh, a week. At the end of that week the company could submit documentation of 100% utilization to ARIN and get a second block, lather, since, repeat. It's part of the general chinese buffet model of ARIN, Take all you want, but eat all you take. They want to see the eating part. So no, they won't hand you a /8 up front as a new entrant, but if you really can deploy (and document it) that fast you could get a /8's worth of space in a couple of months time. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpZLaBnu1JvJ.pgp Description: PGP signature
Re: Is AS information useful for security?
It's useful in terms of remediation as it can help identify through which door packets entered your network. Though, as others will undoubtedly point out, it's trustworthiness will depend upon how you derive the AS mapping and upon other security features (e.g. uRPF) -- Eric :) On Thu, 15 Dec 2011, Joe Loiacono wrote: Is a good knowledge of either origin-AS, or next-AS with respect to flows valuable in establishing, monitoring, or re-enforcing a security posture? In what way?
Re: De-bogon not possible via arin policy.
On Thu, 15 Dec 2011 18:43:05 -0500, Stephen Sprunk step...@sprunk.org wrote: However, if they actually have the number of hosts claimed, that justifies the space they're asking for. What addresses they're using today is irrelevant. ARIN policy only /suggests/ that they use RFC 1918 space; they are allowed to get public space if they want it. Except they've tipped their hand already. If they've been NAT'ing 5/8 for who knows how long, it's clear they don't need public IPv4 space for their network. However, getting public space is easier than building multiple 10/8 private islands. (or so they thought :-)) However, those customers seem to have gotten along okay for years without public addresses, so why not renumber them into a second instance of 10/8? When I was in the consulting world, I had one customer with eight instances of 10/8, so I know it's doable. And that's my entire point. Thus how they've failed to demonstrate a legitimate need for what little IPv4 space is still available. Maybe they (tmo) should get their european arm to ask RIPE for the entire 5/8 :-) (well, the 3/4th they haven't allocated yet.) --Ricky
Re: De-bogon not possible via arin policy.
On 12/15/11 3:31 PM, Ricky Beam wrote: On Thu, 15 Dec 2011 16:36:32 -0500, David Conrad d...@virtualized.org wrote: ... I had thought new allocations are based on demonstrated need. The fact that addresses are in use would seem to suggest they're needed. That depends on how you see their demontrated need. The way I look at it, if you build your network squatting on someone elses addresses, that's a problem of your own making and does not equate to any immediate need on my (channeling ARIN) part. This is a mess they created for themselves and should have known was going to bite them in the ass sooner than later. Translation: they should have started working to resolve this a long time ago. (or never done it in the first place.) And if I may say, they've demonstrated no need at all for public address space. They simply need to stop using 5/8 as if it were 10/8 -- i.e. they need more private address space. They don't need *public* IPv4 space for that. They will need to re-engineer their network to handle the addressing overlaps (ala NAT444.) Heh, if this is about TMO, then they're squatting on alot more then just 5/8... My phone has an IP address in 22/8, and I've seen it get IPs in 25/8, 26/8 as well. I've always wondered what the deal was with the obviously squatted addresses that my device gets. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org/ http://www.ahbl.org
[sort of off topic] An Open Letter From Internet Engineers to the U.S. Congress
I wonder how this will go in the USA and what trickle effect it might have on us if Senator Conroy gets wind of it. An Open Letter From Internet Engineers to the U.S. Congress. https://www.eff.org/deeplinks/2011/12/internet-inventors-warn-against-sopa-a nd-pipa Ephesians 4:32 Cheers!!! Andy
