Re: can I ask mtu question
Which standard are you referring to? AFAIK, nothing above 1500 is standardised I've had two different kinds of customer requests for jumbo frames - customers that want very large frames for performance reasons; Many ethernet switches support 9000 or more, some don't, and some technologies like ATM support ~4470. Sometimes the ability to provide them depends on tunnel modes. - customers that want frames that are at least ~1700-1800 bytes so that a few layers of IPSEC or VLAN headers or whatever won't break the 1500-byte packets inside them. -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: can I ask mtu question
Ricky Beam wrote: On Fri, 30 Jan 2009 17:00:00 -0500, Saku Ytti saku+na...@ytti.fi wrote: Which standard are you referring to? AFAIK, nothing above 1500 is standardised None that have ever been accepted. From a quick google for manufacturer support, 9216 looks like the most popular number. But, as I said, it boils down to the largest frame *every* device on the LAN will accept. If there is a single device that only supports 9000, then that's your limit. And if there's a single non-JF device in the LAN, it throws a wrench into the whole thing. (This appears to be one of the sticking points as to why IEEE won't accept the addition of JF to any specs.) --Ricky PS: The topic pops up again with super-jumbo frames in 10G networks. For what it's worth, TCP will negiogate MSS and will work with mismatched MTU in a single LAN segment. Other protocols (e.g. UDP) will be borked though. S
Re: Peer Filtering
That was one of our biggest worries people make mistakes and route leaks happen. They do. And it's not just mom+pop providers who occasionally leak an entire table. Big operators do it too. The unfortunate part we're faced with now is that we have several downstream customers who are multihomed. Because we're filtering out some of the prefixes that are not in an IRR, those routes are not nearly as attractive downstream giving the other carrier involved an advantage. I can see this is where convenience/economics start to kick in ;( One way or another, if you're providing transit, you absolutely need some means of filtering your downstreams using prefix filtering, and also preferable ASN filtering. Otherwise, your downstreams can inject any sort of crap into your table and you're opening yourself up to I-can't-believe-it's-not-youtube-hijacking-again situations. This is really bad and harmful for the internet. Max-prefixes are fine for peering exchanges, where you can just depeer if there's a problem, but they will not protect you against customers doing stupid stuff. The only issue for customers is not whether you do prefix filtering but whether you use IRR information or maintain your own internal database. The latter is re-inventing the wheel, imo. But lots of companies do it anyway. If your peering exchange doesn't provide multilateral peering, ask them to do so. This provides a natural platform for using route server client IRR prefix filtering, and route servers (despite a lot of well known and understood problems associated with them) can be very useful in this regard. Nick
Re: Private use of non-RFC1918 IP space
On Feb 3, 2009, at 1:01 AM, Stephen Sprunk wrote: Patrick W. Gilmore wrote: Except the RIRs won't give you another /48 when you have only used one trillion IP addresses. Are you sure? According to ARIN staff, current implementation of policy is that all requests are approved since there are no defined criteria that would allow them to deny any. So far, nobody's shown interest in plugging that hole in the policy because it'd be a major step forward if IPv6 were popular enough for anyone to bother wasting it... Touché. I assumed if you had an allocation and came back for a second, they would say no. Hrmm, time for me to go get another (or another 1000?) v6 allocations. :) -- TTFN, patrick
Re: can I ask mtu question
* sam_mailingli...@spacething.org (Sam Stickland) [Tue 03 Feb 2009, 13:04 CET]: For what it's worth, TCP will negiogate MSS and will work with mismatched MTU in a single LAN segment. No Machine 1 -- switch with 1500 byte MTU -- switch with smaller MTU -- switch with 1500 byte MTU -- machine 2 Same situation as when you have IP routers with smaller MTUs in the path that also do not send ICMP Fragmentation Needed errors (or those are dropped on the way to you) If you configure one of those machines with an MTU equal to or smaller than the smallest MTU in the path then yes TCP (assuming MSS option is used) won't send packets that happen to be too big, but again, same story as for routers vs on a LAN. The problem isn't that machine 1 and 2 in the above example disagree on MTU, the problem is that equipment in the path disagrees on the MTU and cannot (in the case of switches) send notifications of such, or those will not arrive (in the case of stupid firewall admins in control of networks). -- Niels.
Re: can I ask mtu question
Niels Bakker wrote: * sam_mailingli...@spacething.org (Sam Stickland) [Tue 03 Feb 2009, 13:04 CET]: For what it's worth, TCP will negiogate MSS and will work with mismatched MTU in a single LAN segment. No Machine 1 -- switch with 1500 byte MTU -- switch with smaller MTU -- switch with 1500 byte MTU -- machine 2 Same situation as when you have IP routers with smaller MTUs in the path that also do not send ICMP Fragmentation Needed errors (or those are dropped on the way to you) If you configure one of those machines with an MTU equal to or smaller than the smallest MTU in the path then yes TCP (assuming MSS option is used) won't send packets that happen to be too big, but again, same story as for routers vs on a LAN. The problem isn't that machine 1 and 2 in the above example disagree on MTU, the problem is that equipment in the path disagrees on the MTU and cannot (in the case of switches) send notifications of such, or those will not arrive (in the case of stupid firewall admins in control of networks). Sorry, I should had clarified. I meant mismatched host MTUs within a jumbo MTU supporting L2 domain. Sam
Re: Private use of non-RFC1918 IP space
Stephen Sprunk wrote: Patrick W. Gilmore wrote: Except the RIRs won't give you another /48 when you have only used one trillion IP addresses. Are you sure? According to ARIN staff, current implementation of policy is that all requests are approved since there are no defined criteria that would allow them to deny any. So far, nobody's shown interest in plugging that hole in the policy because it'd be a major step forward if IPv6 were popular enough for anyone to bother wasting it... Catch 22? From my experience IPv6 is unlikely to become popular until it fully supports NAT. Much as network providers love the thought of owning all of your address space, and ARIN of billing for it, and RFCs like 4864 of providing rhetorical but technically flawed arguments against it, the lack of NAT only pushes adoption of IPv6 further into the future. Roger Marquis
Re: Private use of non-RFC1918 IP space
I don't consider IPv6 a popularity contest. It's about the motivation and the willingness to. Technical issues can be resolved if you and people around you are motivated to do so. I think there are some hard facts that need to be addressed when it comes to IPv6. Facts like 1. How do we migrate to a IPv6 stack on all servers and I am talking about the thousands of servers that exist on peoples network that run SaaS, Financial/Banking systems. 2. How do we make old applications speak IPv6? There are some old back-end systems that run core functions for many businesses out there that don't really have any upgrade path and I don't think people are thinking about this. From a network perspective IPv6 adoption is just about doing it and executing with your fellow AS neighbors. The elephant in the room is the applications that ride on your network. Zaid - Original Message - From: Roger Marquis marq...@roble.com To: nanog@nanog.org Sent: Tuesday, February 3, 2009 9:39:33 AM GMT -08:00 US/Canada Pacific Subject: Re: Private use of non-RFC1918 IP space Stephen Sprunk wrote: Patrick W. Gilmore wrote: Except the RIRs won't give you another /48 when you have only used one trillion IP addresses. Are you sure? According to ARIN staff, current implementation of policy is that all requests are approved since there are no defined criteria that would allow them to deny any. So far, nobody's shown interest in plugging that hole in the policy because it'd be a major step forward if IPv6 were popular enough for anyone to bother wasting it... Catch 22? From my experience IPv6 is unlikely to become popular until it fully supports NAT. Much as network providers love the thought of owning all of your address space, and ARIN of billing for it, and RFCs like 4864 of providing rhetorical but technically flawed arguments against it, the lack of NAT only pushes adoption of IPv6 further into the future. Roger Marquis
Re: Private use of non-RFC1918 IP space
Zaid Ali wrote: I don't consider IPv6 a popularity contest. It's about the motivation and the willingness to. Technical issues can be resolved if you and people around you are motivated to do so. I think there are some hard facts that need to be addressed when it comes to IPv6. Facts like 1. How do we migrate to a IPv6 stack on all servers and I am talking about the thousands of servers that exist on peoples network that run SaaS, Financial/Banking systems. Just upgrade your load balancer (or request a feature from your load balancer company) to map an external IPv6 address to a pool of IPv4 servers. Problem solved. 2. How do we make old applications speak IPv6? There are some old back-end systems that run core functions for many businesses out there that don't really have any upgrade path and I don't think people are thinking about this. Continue to run IPv4 internally for this application. There's no logical reason that IPv4 can't continue to coexist for decades. Heck, people still run IPX, right? -Paul
RE: Private use of non-RFC1918 IP space
It's not just technical. Companies are reluctant to migrate to an IP address owned by an ISP. We are one of those companies. If and when it is easy for us to apply and receive our own Ipv6 address space, we will look at deploying ipv6, but not until then. That's not a technical issue, but rather a business decision, and it's not going to change. We aren't depending our network resources on an external third-party, especially given their track record. Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 -Original Message- From: Zaid Ali [mailto:z...@zaidali.com] Sent: Tuesday, February 03, 2009 1:19 PM To: Roger Marquis Cc: nanog@nanog.org Subject: Re: Private use of non-RFC1918 IP space I don't consider IPv6 a popularity contest. It's about the motivation and the willingness to. Technical issues can be resolved if you and people around you are motivated to do so. I think there are some hard facts that need to be addressed when it comes to IPv6. Facts like 1. How do we migrate to a IPv6 stack on all servers and I am talking about the thousands of servers that exist on peoples network that run SaaS, Financial/Banking systems. 2. How do we make old applications speak IPv6? There are some old back- end systems that run core functions for many businesses out there that don't really have any upgrade path and I don't think people are thinking about this. From a network perspective IPv6 adoption is just about doing it and executing with your fellow AS neighbors. The elephant in the room is the applications that ride on your network. Zaid - Original Message - From: Roger Marquis marq...@roble.com To: nanog@nanog.org Sent: Tuesday, February 3, 2009 9:39:33 AM GMT -08:00 US/Canada Pacific Subject: Re: Private use of non-RFC1918 IP space Stephen Sprunk wrote: Patrick W. Gilmore wrote: Except the RIRs won't give you another /48 when you have only used one trillion IP addresses. Are you sure? According to ARIN staff, current implementation of policy is that all requests are approved since there are no defined criteria that would allow them to deny any. So far, nobody's shown interest in plugging that hole in the policy because it'd be a major step forward if IPv6 were popular enough for anyone to bother wasting it... Catch 22? From my experience IPv6 is unlikely to become popular until it fully supports NAT. Much as network providers love the thought of owning all of your address space, and ARIN of billing for it, and RFCs like 4864 of providing rhetorical but technically flawed arguments against it, the lack of NAT only pushes adoption of IPv6 further into the future. Roger Marquis Matthew Huff.vcf Description: Binary data smime.p7s Description: S/MIME cryptographic signature
Re: Private use of non-RFC1918 IP space
Yes we all go to NANOG meetings and talk about these solutions but the change has to come from within. its not just a technical solution. There has to be motivation and incentive for people to make this change. Zaid - Original Message - From: Paul Timmins p...@telcodata.us To: Zaid Ali z...@zaidali.com Cc: Roger Marquis marq...@roble.com, nanog@nanog.org Sent: Tuesday, February 3, 2009 10:22:16 AM GMT -08:00 US/Canada Pacific Subject: Re: Private use of non-RFC1918 IP space Zaid Ali wrote: I don't consider IPv6 a popularity contest. It's about the motivation and the willingness to. Technical issues can be resolved if you and people around you are motivated to do so. I think there are some hard facts that need to be addressed when it comes to IPv6. Facts like 1. How do we migrate to a IPv6 stack on all servers and I am talking about the thousands of servers that exist on peoples network that run SaaS, Financial/Banking systems. Just upgrade your load balancer (or request a feature from your load balancer company) to map an external IPv6 address to a pool of IPv4 servers. Problem solved. 2. How do we make old applications speak IPv6? There are some old back-end systems that run core functions for many businesses out there that don't really have any upgrade path and I don't think people are thinking about this. Continue to run IPv4 internally for this application. There's no logical reason that IPv4 can't continue to coexist for decades. Heck, people still run IPX, right? -Paul
Re: Private use of non-RFC1918 IP space
Matthew Huff wrote: It's not just technical. Companies are reluctant to migrate to an IP address owned by an ISP. We are one of those companies. If and when it is easy for us to apply and receive our own Ipv6 address space, [..] Because like, ARIN wasn't the first RIR to provide that possibility. http://www.arin.net/registration/guidelines/ipv6_assignment.html I assume you will have IPv6 next week now? Greets, Jeroen signature.asc Description: OpenPGP digital signature
RE: Private use of non-RFC1918 IP space
DNS is great, but there is plenty of stuff to change that doesn't use DNS (ACLS, etc...). The point is, why should we go through the pain of renumbering, and have to do it everytime our relationship with our ISP changes? We aren't going to go there. It isn't renumbering that's the problem, the problem is that it being tied to an external company. Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 -Original Message- From: Måns Nilsson [mailto:mansa...@besserwisser.org] Sent: Tuesday, February 03, 2009 4:19 PM To: Matthew Huff; 'Zaid Ali'; 'Roger Marquis' Cc: 'nanog@nanog.org' Subject: RE: Private use of non-RFC1918 IP space --On tisdag, tisdag 3 feb 2009 13.24.59 -0500 Matthew Huff mh...@ox.com wrote: It's not just technical. Companies are reluctant to migrate to an IP address owned by an ISP. We are one of those companies. If and when it is easy for us to apply and receive our own Ipv6 address space, we will look at deploying ipv6, but not until then. That's not a technical issue, but rather a business decision, and it's not going to change. We aren't depending our network resources on an external third-party, especially given their track record. Renumbering will happen. Be prepared or cry louder when it happens. DNS was invented for this, and v4 PA space is functionally equivalent to v6 here. Getting PI space only pushes the inevitable a bit, while lessening the incentives to DTRT wrt IP address mobility. -- Måns Nilsson M A C H I N A YOW!!! I am having fun!!! Matthew Huff.vcf Description: Binary data smime.p7s Description: S/MIME cryptographic signature
RE: Private use of non-RFC1918 IP space
With new dual-stack border devices people will be able to move bit by bit, and there is no real reason to have to run around and change everything that you have internally. These will change and update over time. These internal applications aren't running on public IP addresses anyway. ...Skeeve -Original Message- From: Zaid Ali [mailto:z...@zaidali.com] Sent: Wednesday, 4 February 2009 5:19 AM To: Roger Marquis Cc: nanog@nanog.org Subject: Re: Private use of non-RFC1918 IP space I don't consider IPv6 a popularity contest. It's about the motivation and the willingness to. Technical issues can be resolved if you and people around you are motivated to do so. I think there are some hard facts that need to be addressed when it comes to IPv6. Facts like 1. How do we migrate to a IPv6 stack on all servers and I am talking about the thousands of servers that exist on peoples network that run SaaS, Financial/Banking systems. 2. How do we make old applications speak IPv6? There are some old back-end systems that run core functions for many businesses out there that don't really have any upgrade path and I don't think people are thinking about this. From a network perspective IPv6 adoption is just about doing it and executing with your fellow AS neighbors. The elephant in the room is the applications that ride on your network. Zaid - Original Message - From: Roger Marquis marq...@roble.com To: nanog@nanog.org Sent: Tuesday, February 3, 2009 9:39:33 AM GMT -08:00 US/Canada Pacific Subject: Re: Private use of non-RFC1918 IP space Stephen Sprunk wrote: Patrick W. Gilmore wrote: Except the RIRs won't give you another /48 when you have only used one trillion IP addresses. Are you sure? According to ARIN staff, current implementation of policy is that all requests are approved since there are no defined criteria that would allow them to deny any. So far, nobody's shown interest in plugging that hole in the policy because it'd be a major step forward if IPv6 were popular enough for anyone to bother wasting it... Catch 22? From my experience IPv6 is unlikely to become popular until it fully supports NAT. Much as network providers love the thought of owning all of your address space, and ARIN of billing for it, and RFCs like 4864 of providing rhetorical but technically flawed arguments against it, the lack of NAT only pushes adoption of IPv6 further into the future. Roger Marquis
RE: Private use of non-RFC1918 IP space
Owned by an ISP? It isn't much different than it is now. As long as you are multi-homed you can get a small allocation (/48), APNIC and ARIN have procedures for this. Yes, you have to pay for it, but the addresses will be yours, unlike the RFC1918 ranges which is akin to 2.4Ghz wireless.. lets just share and hope we never interconnect/overlap. I can't find a RFC1918 equivalent for v6 with the exception of 2001:0DB8::/32# which is the ranges that has been assigned for documentation use and is considered to NEVER be routable. In that /32 are 65536 /48's... way more than the RFC1918 we have now. If I was going to build a v6 network right now, that was purely private and never* going to hit the internet, and I could not afford to be a NIC member or pay the fees... then I would be using the ranges above I wonder if that will start a flame war *puts on fire suit*. ...Skeeve * never say never! # http://www.iana.org/assignments/ipv6-unicast-address-assignments -Original Message- From: Matthew Huff [mailto:mh...@ox.com] Sent: Wednesday, 4 February 2009 5:25 AM To: 'Zaid Ali'; 'Roger Marquis' Cc: 'nanog@nanog.org' Subject: RE: Private use of non-RFC1918 IP space It's not just technical. Companies are reluctant to migrate to an IP address owned by an ISP. We are one of those companies. If and when it is easy for us to apply and receive our own Ipv6 address space, we will look at deploying ipv6, but not until then. That's not a technical issue, but rather a business decision, and it's not going to change. We aren't depending our network resources on an external third-party, especially given their track record. Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 -Original Message- From: Zaid Ali [mailto:z...@zaidali.com] Sent: Tuesday, February 03, 2009 1:19 PM To: Roger Marquis Cc: nanog@nanog.org Subject: Re: Private use of non-RFC1918 IP space I don't consider IPv6 a popularity contest. It's about the motivation and the willingness to. Technical issues can be resolved if you and people around you are motivated to do so. I think there are some hard facts that need to be addressed when it comes to IPv6. Facts like 1. How do we migrate to a IPv6 stack on all servers and I am talking about the thousands of servers that exist on peoples network that run SaaS, Financial/Banking systems. 2. How do we make old applications speak IPv6? There are some old back- end systems that run core functions for many businesses out there that don't really have any upgrade path and I don't think people are thinking about this. From a network perspective IPv6 adoption is just about doing it and executing with your fellow AS neighbors. The elephant in the room is the applications that ride on your network. Zaid - Original Message - From: Roger Marquis marq...@roble.com To: nanog@nanog.org Sent: Tuesday, February 3, 2009 9:39:33 AM GMT -08:00 US/Canada Pacific Subject: Re: Private use of non-RFC1918 IP space Stephen Sprunk wrote: Patrick W. Gilmore wrote: Except the RIRs won't give you another /48 when you have only used one trillion IP addresses. Are you sure? According to ARIN staff, current implementation of policy is that all requests are approved since there are no defined criteria that would allow them to deny any. So far, nobody's shown interest in plugging that hole in the policy because it'd be a major step forward if IPv6 were popular enough for anyone to bother wasting it... Catch 22? From my experience IPv6 is unlikely to become popular until it fully supports NAT. Much as network providers love the thought of owning all of your address space, and ARIN of billing for it, and RFCs like 4864 of providing rhetorical but technically flawed arguments against it, the lack of NAT only pushes adoption of IPv6 further into the future. Roger Marquis
RE: Private use of non-RFC1918 IP space
See my other email. You don't need to use a providers range. ...Skeeve -Original Message- From: Matthew Huff [mailto:mh...@ox.com] Sent: Wednesday, 4 February 2009 8:35 AM To: 'Måns Nilsson'; 'Zaid Ali'; 'Roger Marquis' Cc: 'nanog@nanog.org' Subject: RE: Private use of non-RFC1918 IP space DNS is great, but there is plenty of stuff to change that doesn't use DNS (ACLS, etc...). The point is, why should we go through the pain of renumbering, and have to do it everytime our relationship with our ISP changes? We aren't going to go there. It isn't renumbering that's the problem, the problem is that it being tied to an external company. Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 -Original Message- From: Måns Nilsson [mailto:mansa...@besserwisser.org] Sent: Tuesday, February 03, 2009 4:19 PM To: Matthew Huff; 'Zaid Ali'; 'Roger Marquis' Cc: 'nanog@nanog.org' Subject: RE: Private use of non-RFC1918 IP space --On tisdag, tisdag 3 feb 2009 13.24.59 -0500 Matthew Huff mh...@ox.com wrote: It's not just technical. Companies are reluctant to migrate to an IP address owned by an ISP. We are one of those companies. If and when it is easy for us to apply and receive our own Ipv6 address space, we will look at deploying ipv6, but not until then. That's not a technical issue, but rather a business decision, and it's not going to change. We aren't depending our network resources on an external third-party, especially given their track record. Renumbering will happen. Be prepared or cry louder when it happens. DNS was invented for this, and v4 PA space is functionally equivalent to v6 here. Getting PI space only pushes the inevitable a bit, while lessening the incentives to DTRT wrt IP address mobility. -- Måns Nilsson M A C H I N A YOW!!! I am having fun!!!
RE: Private use of non-RFC1918 IP space
OK, I will make an (what looks to this list) embarrassing admission. We use 1.0.0.0/8 for our internal ranges, but this is on a small scale. We do it because of the kind of business we do... we manage many other much larger networks which already use every possible overlapping RFC1918 network you can imagine... we have half a dozen networks using 192.168.0, and even more using many varied masks in the 10.0.0.0/8. We already have issues with the overlapping networks as is, without making it worse for us by using on of them. I chose to go the 1.0.0.0 path because: - It wont conflict with my customers and us doing our business - As long as it is not APNIC who gets it, the chances of it conflicting will be extremely minimal (rolls dice) - We don't design customer networks with non-RFC1918 ranges unless there is some extreme reason - Yes it is potentially allocate-able in the future, but if it happens I will deal with it then - just renumber or see the next point - We will be fully IPv6 within 6-9 months with a separate VLAN which will support legacy equipment with NAT-PT... this will still be an issue interconnecting to customer networks, but we will think of something. ..Skeeve -Original Message- From: David Conrad [mailto:d...@virtualized.org] Sent: Tuesday, 3 February 2009 6:48 AM To: Bruce Grobler Cc: NANOG list Subject: Re: Private use of non-RFC1918 IP space On Feb 2, 2009, at 8:10 AM, Bruce Grobler wrote: Most ISP's, if not all, null route 1.0.0.0/8 therefore you shouldn't encounter any problems using it in a private network. Is this true? This will cause endless entertainment when IANA allocates 1.0.0.0/8 sometime within the next two or three years... Regards, -drc
Re: Private use of non-RFC1918 IP space
Stephen Sprunk wrote: Patrick W. Gilmore wrote: Except the RIRs won't give you another /48 when you have only used one trillion IP addresses. Keyword: *Another* Are you sure? According to ARIN staff, current implementation of policy is that all requests are approved since there are no defined criteria that would allow them to deny any. So far, nobody's shown interest in plugging that hole in the policy because it'd be a major step forward if IPv6 were popular enough for anyone to bother wasting it... S I believe Stephen is thinking of initial allocation policy - because a subsequent allocation policy in the ARIN region exists: (and it's been modified atleast once in the last few years) Justification to obtain another netblock is .94 HD-Ratio in the current allocation Endusers (minimum allocation is a /48) For a /48 that's about 72% utilization or 184 /56's assigned/used ISP's (minimum allocation is a /32) For a /32 that's about 37% utilization or 6,183,533 /56's assigned ARIN provides a handy chart: http://www.arin.net/policy/nrpm.html#six7
IPv6 space (was: RE: Private use of non-RFC1918 IP space )
Which is exactly what they should do - actually before that one would hope. This is not the $200/hour chcklehead consultant's fault, that is the design. Don't you love the idea of using 18446744073709551616 IP addresses to number a point-to-point link? Let's not ignore that all IPv6 allocations are basically charged-for, so my expectation is that there will be fewer idle allocations that can't be recovered running around (when an org has to justify $36,000 per year [after 2012], forever, some bean counter may ask why... especially if they can get a sensibly sized allocation from their provider for a fraction of that cost). I'm not sure if that is cynical, or optimistic, but since the allocations are not free, there seems to be less incentive to squat. Deepak Jain AiNET
Re: Private use of non-RFC1918 IP space
Skeeve Stevens wrote: Owned by an ISP? It isn't much different than it is now. As long as you are multi-homed you can get a small allocation (/48), APNIC and ARIN have procedures for this. Yes, you have to pay for it, but the addresses will be yours, unlike the RFC1918 ranges which is akin to 2.4Ghz wireless.. lets just share and hope we never interconnect/overlap. I can't find a RFC1918 equivalent for v6 with the exception of 2001:0DB8::/32# which is the ranges that has been assigned for documentation use and is considered to NEVER be routable. In that /32 are 65536 /48's... way more than the RFC1918 we have now. RFC4193 - Unique Local IPv6 Unicast Addresses http://www.iana.org/assignments/ipv6-address-space FC00::/7 Unique Local Unicast[RFC4193] ..maybe they should have called it RFC1918 for IPv6. FWIW, 2001:0DB8::/32 was allocated by APNIC. Not quite the same as being an RFC/IANA delegated/reserved netblock. --heather Heather Schiller Verizon Business Customer Security 1.800.900.0241 IP Address Management hel...@verizonbusiness.com =
Re: Private use of non-RFC1918 IP space
Skeeve Stevens wrote: [please fix your line length, my screen is still not a 100] Owned by an ISP? It isn't much different than it is now. As long as you are multi-homed you can get a small allocation (/48), APNIC and ARIN have procedures for this. Yes, you have to pay for it, but the addresses will be yours, unlike the RFC1918 ranges which is akin to 2.4Ghz wireless.. lets just share and hope we never interconnect/overlap. I can't find a RFC1918 equivalent for v6 with the exception of 2001:0DB8::/32# which is the ranges that has been assigned for documentation use and is considered to NEVER be routable. In that /32 are 65536 /48's... way more than the RFC1918 we have now. Documentation is exactly that: Documentation. Do not EVER use that in a real box. If you need 'RFC1918 alike' space then go for ULA (RFC4193). Also see http://www.sixxs.net/tools/grh/ula/ for a semi-registered version of that. If you want guaranteed unique then go to a RIR. If I was going to build a v6 network right now, that was purely private and never* going to hit the internet, and I could not afford to be a NIC member or pay the fees... then I would be using the ranges above I wonder if that will start a flame war *puts on fire suit*. Google goes straight through that suit, I suggest you use it and read up on IPv6. Even the Wikipedia entry contains this information. google(rfc1918 ipv6) or http://en.wikipedia.org/wiki/Private_network Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: Private use of non-RFC1918 IP space
On 4/02/2009, at 12:25 PM, Owen DeLong wrote: There is the ULA-Random space, but, I'm not sure if that got ratified or was rescinded. I really don't see a need for RFC-1918 in the IPv6 world. RFC-1918 was intended to solve a problem with a shortage of address space by allowing disparate private networks to recycle the same numbers behind NAT or for use on non-connected networks. There is no such shortage in IPv6. I think it is wiser to number non-connected IPv6 networks from valid unique addresses since there is no shortage. ULA is useful for organisations that cannot get an RIR allocation/ assignment, so are likely to need to re-number. If they number on ULA *in addition to* whatever space their ISP gives them, they do not need to alter any internal DNS, ACLs, etc. etc. if/ when they re-number. An easy example of a good use for ULA might be the internal recursive DNS server addresses that the DHCPv6 server hands out. If they are so inclined, they might even re-number dynamically if they get their prefix using PD. -- Nathan Ward
RE: Private use of non-RFC1918 IP space
And for those kinds of applications, yell at your vendors to come up with a solution. They say that there is about 2 years of ipv4 left. Then we’re screwed. If people sit with their thumbs up their asses now, and are not out planning budgets and migration strategies, they will be caught when they want to do network expansions. Note… the running out of IPv4 will NOT effect your current operations in any way. Your providers transit will (or already has) become dual stack, and you will continue to be able to talk to the internet as a whole unless native v6 only content starts to appear, which it will and then problems will appear. This situation will be able to go on for years without your changing anything….. unless you want these applications to keep communicating with the ever growing internet on ipv6… and if you do, plan for it… decide if you’re going to do it now, in a year, or in 10 years and how you want to look to your shareholders or stakeholders… because eventually, they will ask… they may not want to pay for it just now… but there is a lot of things you can do before you have to start paying real money for things. - Getting your assignment/allocation - Developing your documentation/plan of how it will be assigned internally - Start to identify what parts of your infrastructure will not cope (everyone will need to use NAT-PT internally for some 10 years or more) - Start talking to your hardware and software vendors about v6 and understanding their product roadmaps, timelines and so on. With all this, when it becomes inevitable you won’t have to suddenly do a ton of work…. Or you could buy ‘Migrating my corporate network to IPv6 for Dummies’ …Skeeve From: Dave Temkin [mailto:dav...@gmail.com] Sent: Wednesday, 4 February 2009 9:06 AM To: ske...@skeeve.org Cc: 'Zaid Ali'; 'Roger Marquis'; nanog@nanog.org Subject: Re: Private use of non-RFC1918 IP space The problem with that solution mainly being that the application itself still needs some sort of intelligence as well as the border device potentially doing L7 operations (header insertion/etc.) - unless you're OK with generally losing all information about the source of incoming traffic at the backend (except for looking at NAT tables...) -Dave Skeeve Stevens wrote: With new dual-stack border devices people will be able to move bit by bit, and there is no real reason to have to run around and change everything that you have internally. These will change and update over time. These internal applications aren't running on public IP addresses anyway. ...Skeeve -Original Message- From: Zaid Ali [mailto:z...@zaidali.com] Sent: Wednesday, 4 February 2009 5:19 AM To: Roger Marquis Cc: nanog@nanog.org Subject: Re: Private use of non-RFC1918 IP space I don't consider IPv6 a popularity contest. It's about the motivation and the willingness to. Technical issues can be resolved if you and people around you are motivated to do so. I think there are some hard facts that need to be addressed when it comes to IPv6. Facts like 1. How do we migrate to a IPv6 stack on all servers and I am talking about the thousands of servers that exist on peoples network that run SaaS, Financial/Banking systems. 2. How do we make old applications speak IPv6? There are some old back-end systems that run core functions for many businesses out there that don't really have any upgrade path and I don't think people are thinking about this. From a network perspective IPv6 adoption is just about doing it and executing with your fellow AS neighbors. The elephant in the room is the applications that ride on your network. Zaid - Original Message - From: Roger Marquis mailto:marq...@roble.com marq...@roble.com To: nanog@nanog.org Sent: Tuesday, February 3, 2009 9:39:33 AM GMT -08:00 US/Canada Pacific Subject: Re: Private use of non-RFC1918 IP space Stephen Sprunk wrote: Patrick W. Gilmore wrote: Except the RIRs won't give you another /48 when you have only used one trillion IP addresses. Are you sure? According to ARIN staff, current implementation of policy is that all requests are approved since there are no defined criteria that would allow them to deny any. So far, nobody's shown interest in plugging that hole in the policy because it'd be a major step forward if IPv6 were popular enough for anyone to bother wasting it... Catch 22? From my experience IPv6 is unlikely to become popular until it fully supports NAT. Much as network providers love the thought of owning all of your address space, and ARIN of billing for it, and RFCs like 4864 of providing rhetorical but technically flawed arguments against it, the lack of NAT only pushes adoption of IPv6 further into the future. Roger Marquis
Re: Private use of non-RFC1918 IP space
Owen DeLong wrote: ... I don't know what the APNIC fees and membership requirements are. A succinct summary, see below ! However, in the ARIN region, you do not need to be a member to get address space. The renewal fee for end-user space is $100/year. If you can't afford $100/year, how are you staying connected to the network or paying to power your equipment? APNIC fees are an order of magnitude (or more) higher ! http://www.apnic.net/member/feesinfo.html#non_mem_fee ftp://ftp.apnic.net/apnic/docs/non-member-fees-2008 (APNIC-118) I quote from APNIC-118 : A host address in IPv4 is defined as a /32 and a site address in IPv6 is defined a /48. The initial fee for an assignment or allocation of IP addresses is AU$1.27 per host or site address, with a minimum fee of AU$10,384. After the first year of the initial assignment or allocation, there is an annual registration fee is AU$0.127 per host or site address, with a minimum fee of AU$1,038.40.
Re: Private use of non-RFC1918 IP space
On Feb 3, 2009, at 2:18 PM, Skeeve Stevens wrote: Owned by an ISP? It isn't much different than it is now. As long as you are multi-homed you can get a small allocation (/48), APNIC and ARIN have procedures for this. To clarify, you can get whatever size assignment you need, but, the default unless you request larger and can justify it is a /48. To put this in perspective, a /48 is 65536*4billion*the total IPv4 address space. Further, it's enough space for 65,536 subnets with 64 bit host addresses. Likely, this is enough for most end-user organizations, but, if you are part of an organization that needs more, you can get it simply by justifying your additional needs. Yes, you have to pay for it, but the addresses will be yours, unlike the RFC1918 ranges which is akin to 2.4Ghz wireless.. lets just share and hope we never interconnect/overlap. In the ARIN region, the end-user annual fees are quite low. I don't see this as a significant barrier to entry to most end-user organizations. I can't find a RFC1918 equivalent for v6 with the exception of 2001:0DB8::/32# which is the ranges that has been assigned for documentation use and is considered to NEVER be routable. In that / 32 are 65536 /48's... way more than the RFC1918 we have now. There is the ULA-Random space, but, I'm not sure if that got ratified or was rescinded. I really don't see a need for RFC-1918 in the IPv6 world. RFC-1918 was intended to solve a problem with a shortage of address space by allowing disparate private networks to recycle the same numbers behind NAT or for use on non-connected networks. There is no such shortage in IPv6. I think it is wiser to number non-connected IPv6 networks from valid unique addresses since there is no shortage. If I was going to build a v6 network right now, that was purely private and never* going to hit the internet, and I could not afford to be a NIC member or pay the fees... then I would be using the ranges above I wonder if that will start a flame war *puts on fire suit*. I don't know what the APNIC fees and membership requirements are. However, in the ARIN region, you do not need to be a member to get address space. The renewal fee for end-user space is $100/year. If you can't afford $100/year, how are you staying connected to the network or paying to power your equipment? Owen ...Skeeve * never say never! # http://www.iana.org/assignments/ipv6-unicast-address-assignments -Original Message- From: Matthew Huff [mailto:mh...@ox.com] Sent: Wednesday, 4 February 2009 5:25 AM To: 'Zaid Ali'; 'Roger Marquis' Cc: 'nanog@nanog.org' Subject: RE: Private use of non-RFC1918 IP space It's not just technical. Companies are reluctant to migrate to an IP address owned by an ISP. We are one of those companies. If and when it is easy for us to apply and receive our own Ipv6 address space, we will look at deploying ipv6, but not until then. That's not a technical issue, but rather a business decision, and it's not going to change. We aren't depending our network resources on an external third-party, especially given their track record. Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 -Original Message- From: Zaid Ali [mailto:z...@zaidali.com] Sent: Tuesday, February 03, 2009 1:19 PM To: Roger Marquis Cc: nanog@nanog.org Subject: Re: Private use of non-RFC1918 IP space I don't consider IPv6 a popularity contest. It's about the motivation and the willingness to. Technical issues can be resolved if you and people around you are motivated to do so. I think there are some hard facts that need to be addressed when it comes to IPv6. Facts like 1. How do we migrate to a IPv6 stack on all servers and I am talking about the thousands of servers that exist on peoples network that run SaaS, Financial/Banking systems. 2. How do we make old applications speak IPv6? There are some old back- end systems that run core functions for many businesses out there that don't really have any upgrade path and I don't think people are thinking about this. From a network perspective IPv6 adoption is just about doing it and executing with your fellow AS neighbors. The elephant in the room is the applications that ride on your network. Zaid - Original Message - From: Roger Marquis marq...@roble.com To: nanog@nanog.org Sent: Tuesday, February 3, 2009 9:39:33 AM GMT -08:00 US/Canada Pacific Subject: Re: Private use of non-RFC1918 IP space Stephen Sprunk wrote: Patrick W. Gilmore wrote: Except the RIRs won't give you another /48 when you have only used one trillion IP addresses. Are you sure? According to ARIN staff, current implementation of policy is that all requests are approved since there are no defined criteria that would allow them to deny any. So far, nobody's shown
FW: News Delivery Report (Failure)
Broken? ...Skeeve -Original Message- From: mail [mailto:postmas...@mail.theyscrewedusagain.com] Sent: Wednesday, 4 February 2009 9:05 AM To: ske...@skeeve.org Subject: News Delivery Report (Failure) Your Article RE: Private use of non-RFC1918 IP space (Wed, 4 Feb 2009 09:03:06 +1100) could not be successfully delivered to the following news groups :- homeless.security News Server: news.barkto.com Response: 441 Faulty message ID format Your message is quoted below :- From: Skeeve Stevens ske...@skeeve.org Newsgroups: homeless.security Path: mail.theyscrewedusagain.com To: 'Zaid Ali' z...@zaidali.com, 'Roger Marquis' marq...@roble.com References: 16474135.451233684880488.javamail.z...@turing-2.local 10812089.471233685164238.javamail.z...@turing-2.local In-Reply-To: 10812089.471233685164238.javamail.z...@turing-2.local Subject: RE: Private use of non-RFC1918 IP space Date: Wed, 4 Feb 2009 09:03:06 +1100 Lines: 71 Organization: eintellego Message-ID: !!AAAYAN5U5OuspydJheQZRk7Gfl7CgAAAEHeeRJOLMjdAuUKTBGjm njmba...@skeeve.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmGLAntiH4eXFtJRiuUjFBXl6Hk+QAHrz0w Content-Language: en-au Cc: nanog@nanog.org X-BeenThere: nanog@nanog.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ske...@skeeve.org List-Id: North American Network Operators Group nanog.nanog.org Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.com)
RE: Private use of non-RFC1918 IP space
Exactly. So.. do I have to be in the US to get ARIN space? Technically space you get is announceable anywhere in the world... Can I just have a /32 from ARIN please and not pay the ton of money that APNIC ask for? I can setup a POBOX in New York if that will help? ;-) Actually, that is an interesting question... If I have a network I am building in the US/other locale, but I am based here, can I become an ARIN/RIPE/etc member and get a range out of them? ...Skeeve -Original Message- From: Peter J. Cherny [mailto:pet...@luddite.com.au] Sent: Wednesday, 4 February 2009 11:06 AM To: nanog@nanog.org Subject: Re: Private use of non-RFC1918 IP space Owen DeLong wrote: ... I don't know what the APNIC fees and membership requirements are. A succinct summary, see below ! However, in the ARIN region, you do not need to be a member to get address space. The renewal fee for end-user space is $100/year. If you can't afford $100/year, how are you staying connected to the network or paying to power your equipment? APNIC fees are an order of magnitude (or more) higher ! http://www.apnic.net/member/feesinfo.html#non_mem_fee ftp://ftp.apnic.net/apnic/docs/non-member-fees-2008 (APNIC-118) I quote from APNIC-118 : A host address in IPv4 is defined as a /32 and a site address in IPv6 is defined a /48. The initial fee for an assignment or allocation of IP addresses is AU$1.27 per host or site address, with a minimum fee of AU$10,384. After the first year of the initial assignment or allocation, there is an annual registration fee is AU$0.127 per host or site address, with a minimum fee of AU$1,038.40.
RE: Private use of non-RFC1918 IP space
--On tisdag, tisdag 3 feb 2009 13.24.59 -0500 Matthew Huff mh...@ox.com wrote: It's not just technical. Companies are reluctant to migrate to an IP address owned by an ISP. We are one of those companies. If and when it is easy for us to apply and receive our own Ipv6 address space, we will look at deploying ipv6, but not until then. That's not a technical issue, but rather a business decision, and it's not going to change. We aren't depending our network resources on an external third-party, especially given their track record. Renumbering will happen. Be prepared or cry louder when it happens. DNS was invented for this, and v4 PA space is functionally equivalent to v6 here. Getting PI space only pushes the inevitable a bit, while lessening the incentives to DTRT wrt IP address mobility. -- Måns NilssonM A C H I N A YOW!!! I am having fun!!! pgprwXVH3KEIw.pgp Description: PGP signature
Re: Private use of non-RFC1918 IP space
The problem with that solution mainly being that the application itself still needs some sort of intelligence as well as the border device potentially doing L7 operations (header insertion/etc.) - unless you're OK with generally losing all information about the source of incoming traffic at the backend (except for looking at NAT tables...) -Dave Skeeve Stevens wrote: With new dual-stack border devices people will be able to move bit by bit, and t here is no real reason to have to run around and change everything that you have internally. These will change and update over time. These internal applicatio ns aren't running on public IP addresses anyway. ...Skeeve -Original Message- From: Zaid Ali [[1]mailto:z...@zaidali.com] Sent: Wednesday, 4 February 2009 5:19 AM To: Roger Marquis Cc: [2]na...@nanog.org Subject: Re: Private use of non-RFC1918 IP space I don't consider IPv6 a popularity contest. It's about the motivation and the wi llingness to. Technical issues can be resolved if you and people around you are motivated to do so. I think there are some hard facts that need to be addressed when it comes to IPv6. Facts like 1. How do we migrate to a IPv6 stack on all servers and I am talking about the thousands of servers that exist on peoples network that run SaaS, Financial/Banking systems. 2. How do we make old applications speak IPv6? There are some old back-end syste ms that run core functions for many businesses out there that don't really have any upgrade path and I don't think people are thinking about this. From a network perspective IPv6 adoption is just about doing it and executing w ith your fellow AS neighbors. The elephant in the room is the applications that ride on your network. Zaid - Original Message - From: Roger Marquis [3]marq...@roble.com To: [4]na...@nanog.org Sent: Tuesday, February 3, 2009 9:39:33 AM GMT -08:00 US/Canada Pacific Subject: Re: Private use of non-RFC1918 IP space Stephen Sprunk wrote: Patrick W. Gilmore wrote: Except the RIRs won't give you another /48 when you have only used one trillion IP addresses. Are you sure? According to ARIN staff, current implementation of policy is that all requests are approved since there are no defined criteria that would allow them to deny any. So far, nobody's shown interest in plugging that hole in the policy because it'd be a major step forward if IPv6 were popular enough for anyone to bother wasting it... Catch 22? From my experience IPv6 is unlikely to become popular until it fully supports NAT. Much as network providers love the thought of owning all of your address space, and ARIN of billing for it, and RFCs like 4864 of providing rhetorical but technically flawed arguments against it, the lack of NAT only pushes adoption of IPv6 further into the future. Roger Marquis References 1. mailto:z...@zaidali.com 2. mailto:nanog@nanog.org 3. mailto:marq...@roble.com 4. mailto:nanog@nanog.org
RE: Private use of non-RFC1918 IP space
It isn't ipv6 that needs to support NAT, it is the devices doing dual-stack. This is where NAT-PT (v6-v4 NAT) will come in. My opinion is that we only aren't further along because the hardware vendors are slackers, mostly the low end guys like D-Link, Belkin, Netgear and so on who provide most of the home networking equipment. The big boys have supported v6 NAT and NAT-PT for ages. ...Skeeve -Original Message- From: Roger Marquis [mailto:marq...@roble.com] Sent: Wednesday, 4 February 2009 4:40 AM To: nanog@nanog.org Subject: Re: Private use of non-RFC1918 IP space Stephen Sprunk wrote: Patrick W. Gilmore wrote: Except the RIRs won't give you another /48 when you have only used one trillion IP addresses. Are you sure? According to ARIN staff, current implementation of policy is that all requests are approved since there are no defined criteria that would allow them to deny any. So far, nobody's shown interest in plugging that hole in the policy because it'd be a major step forward if IPv6 were popular enough for anyone to bother wasting it... Catch 22? From my experience IPv6 is unlikely to become popular until it fully supports NAT. Much as network providers love the thought of owning all of your address space, and ARIN of billing for it, and RFCs like 4864 of providing rhetorical but technically flawed arguments against it, the lack of NAT only pushes adoption of IPv6 further into the future. Roger Marquis
RE: Private use of non-RFC1918 IP space
OK. Following myself up, and referencing a link someone else gave me in regards to IPv6 http://en.wikipedia.org/wiki/Private_network Has the entry: Private use of other reserved addresses Several other address ranges, in addition to the official private ranges, are reserved for other or future uses, including 1.0.0.0/8 and 2.0.0.0/8[1]. In recent years, large companies have begun to use this address space internally. Though discouraged, it appears to have become an accepted practice among larger companies to use these reserved address spaces when connecting two private networks, to eliminate the chance of address conflicts when using standards-based private ranges. --- Now I'm not using this as justification just interesting to see people have put it up there, and comment that a lot of large companies are using 1/8 and 2/8 for private networking. ...Skeeve -Original Message- From: Skeeve Stevens [mailto:ske...@skeeve.org] Sent: Wednesday, 4 February 2009 9:48 AM To: 'David Conrad'; 'Bruce Grobler' Cc: 'NANOG list' Subject: RE: Private use of non-RFC1918 IP space OK, I will make an (what looks to this list) embarrassing admission. We use 1.0.0.0/8 for our internal ranges, but this is on a small scale. We do it because of the kind of business we do... we manage many other much larger networks which already use every possible overlapping RFC1918 network you can imagine... we have half a dozen networks using 192.168.0, and even more using many varied masks in the 10.0.0.0/8. We already have issues with the overlapping networks as is, without making it worse for us by using on of them. I chose to go the 1.0.0.0 path because: - It wont conflict with my customers and us doing our business - As long as it is not APNIC who gets it, the chances of it conflicting will be extremely minimal (rolls dice) - We don't design customer networks with non-RFC1918 ranges unless there is some extreme reason - Yes it is potentially allocate-able in the future, but if it happens I will deal with it then - just renumber or see the next point - We will be fully IPv6 within 6-9 months with a separate VLAN which will support legacy equipment with NAT-PT... this will still be an issue interconnecting to customer networks, but we will think of something. ..Skeeve -Original Message- From: David Conrad [mailto:d...@virtualized.org] Sent: Tuesday, 3 February 2009 6:48 AM To: Bruce Grobler Cc: NANOG list Subject: Re: Private use of non-RFC1918 IP space On Feb 2, 2009, at 8:10 AM, Bruce Grobler wrote: Most ISP's, if not all, null route 1.0.0.0/8 therefore you shouldn't encounter any problems using it in a private network. Is this true? This will cause endless entertainment when IANA allocates 1.0.0.0/8 sometime within the next two or three years... Regards, -drc
Re: Private use of non-RFC1918 IP space
On Wed, Feb 04, 2009 at 11:57:36AM +1100, Skeeve Stevens wrote: OK. Following myself up, and referencing a link someone else gave me in regards to IPv6 http://en.wikipedia.org/wiki/Private_network Has the entry: Private use of other reserved addresses Several other address ranges, in addition to the official private ranges, are reserved for other or future uses, including 1.0.0.0/8 and 2.0.0.0/8[1]. In recent years, large companies have begun to use this address space internally. [citation required] - Matt
RE: Private use of non-RFC1918 IP space
I agree... I'd love to know where they got that from... who even wrote it? ...Skeeve -Original Message- From: Matthew Palmer [mailto:mpal...@hezmatt.org] Sent: Wednesday, 4 February 2009 12:26 PM To: nanog@nanog.org Subject: Re: Private use of non-RFC1918 IP space On Wed, Feb 04, 2009 at 11:57:36AM +1100, Skeeve Stevens wrote: OK. Following myself up, and referencing a link someone else gave me in regards to IPv6 http://en.wikipedia.org/wiki/Private_network Has the entry: Private use of other reserved addresses Several other address ranges, in addition to the official private ranges, are reserved for other or future uses, including 1.0.0.0/8 and 2.0.0.0/8[1]. In recent years, large companies have begun to use this address space internally. [citation required] - Matt
[Update] Re: New ISP to market, BCP 38, and new tactics
For all the kind folk who have been asking how my project is going, I'll summarize here. - I've enabled strict uRPF filtering on all interfaces that I am certain what the source will be. - I've implemented a mix of loose uRPF combined with ACL's on interfaces that I know have multi-homed clients - On all interfaces that run the risk of blocking traffic by accident, I've implemented strict inbound ACL's for known-bad (combined always with Team Cymru BGP learnt bogons), and with logging counter ACLs for all other traffic. After a couple more days, I should be able to focus more strictly on these interfaces - I've made significant changes to my 'core', moving from static routes to an iBGP mesh over OSPF learnt loopbacks. This will allow me to implement a couple of host-based routing daemon boxes for the easy insertion of sinkhole routes in the event of significantly bad behaviour. With my scripting knowledge, preparing a recommended sinkhole route for insertion, ready for admin approval will be easy, and so will having the route removed automatically (or manually) if the attack has ceased. I like the idea of traffic flowing to a host-based machine to null as opposed to null'ing it on the router, as (from what I can tell) it will make it easier to track the flow of the problem ingress and egress - Currently, (as I write), I'm migrating my entire core from IPv4 to IPv6. I've got the space, and I love to learn, so I'm just lab-ing it up now to see how things will flow with all iBGP v4 routes being advertised/routed over v6. The division of the v6 space still overwhelms me, so I guess I'll do what someone else stated in another thread if I mess this one up: go to ARIN for another 1000 /32's :) (no, I'll learn from my mistake, and be ready for next one) Cheers, and thanks! Steve
Re: [Update] Re: New ISP to market, BCP 38, and new tactics
On 4/02/2009, at 2:33 PM, Steve Bertrand wrote: - Currently, (as I write), I'm migrating my entire core from IPv4 to IPv6. I've got the space, and I love to learn, so I'm just lab-ing it up now to see how things will flow with all iBGP v4 routes being advertised/routed over v6. Don't advertise v4 prefixes in v6 sessions, keep them separate. If you do, you have to do set next-hops with route maps and things, it's kind of nasty. Better to just run a v4 BGP mesh and a v6 BGP mesh. -- Nathan Ward
Re: [Update] Re: New ISP to market, BCP 38, and new tactics
Nathan Ward wrote: On 4/02/2009, at 2:33 PM, Steve Bertrand wrote: - Currently, (as I write), I'm migrating my entire core from IPv4 to IPv6. I've got the space, and I love to learn, so I'm just lab-ing it up now to see how things will flow with all iBGP v4 routes being advertised/routed over v6. Don't advertise v4 prefixes in v6 sessions, keep them separate. If you do, you have to do set next-hops with route maps and things, it's kind of nasty. Better to just run a v4 BGP mesh and a v6 BGP mesh. Ok. I've been having problems with this. What I was hoping for (even though I'm testing something that I know won't work) is that I can break something so I could push v4 traffic over a v6-only core. Is there _any_ way to do this (other than NAT/tunnel etc)? Steve
RE: [Update] Re: New ISP to market, BCP 38, and new tactics
Agreed. Keeping it separate works very well. Can be the same interface sure... but do it as a separate session. ...Skeeve -Original Message- From: Nathan Ward [mailto:na...@daork.net] Sent: Wednesday, 4 February 2009 12:40 PM To: nanog list Subject: Re: [Update] Re: New ISP to market, BCP 38, and new tactics On 4/02/2009, at 2:33 PM, Steve Bertrand wrote: - Currently, (as I write), I'm migrating my entire core from IPv4 to IPv6. I've got the space, and I love to learn, so I'm just lab-ing it up now to see how things will flow with all iBGP v4 routes being advertised/routed over v6. Don't advertise v4 prefixes in v6 sessions, keep them separate. If you do, you have to do set next-hops with route maps and things, it's kind of nasty. Better to just run a v4 BGP mesh and a v6 BGP mesh. -- Nathan Ward
Re: [Update] Re: New ISP to market, BCP 38, and new tactics
On 4/02/2009, at 2:43 PM, Steve Bertrand wrote: Nathan Ward wrote: On 4/02/2009, at 2:33 PM, Steve Bertrand wrote: - Currently, (as I write), I'm migrating my entire core from IPv4 to IPv6. I've got the space, and I love to learn, so I'm just lab-ing it up now to see how things will flow with all iBGP v4 routes being advertised/routed over v6. Don't advertise v4 prefixes in v6 sessions, keep them separate. If you do, you have to do set next-hops with route maps and things, it's kind of nasty. Better to just run a v4 BGP mesh and a v6 BGP mesh. Ok. I've been having problems with this. What I was hoping for (even though I'm testing something that I know won't work) is that I can break something so I could push v4 traffic over a v6-only core. Is there _any_ way to do this (other than NAT/tunnel etc)? MPLS - The MP is for Multi Protocol! Otherwise, no, you don't get to use IPv6 addresses as next hops for IPv4 routes, which I think is what you're asking to do. Run IPv4 and IPv6 in parallel, iBGP for v4, iBGP for v6. Same for eBGP to peers/customers. Running v4 and v6 in one BGP session is weird and is asking for confusion, IMHO. You get the same with OSPF - you run OSPFv2 and OSPFv3 in parallel. -- Nathan Ward
Re: Private use of non-RFC1918 IP space
On Feb 3, 2009, at 5:25 PM, Matthew Palmer wrote: On Wed, Feb 04, 2009 at 11:57:36AM +1100, Skeeve Stevens wrote: OK. Following myself up, and referencing a link someone else gave me in regards to IPv6 http://en.wikipedia.org/wiki/Private_network Has the entry: Private use of other reserved addresses Several other address ranges, in addition to the official private ranges, are reserved for other or future uses, including 1.0.0.0/8 and 2.0.0.0/8[1]. In recent years, large companies have begun to use this address space internally. [citation required] - Matt I've added a blurb to this page expressing the risks associated with such use. Owen
Re: [Update] Re: New ISP to market, BCP 38, and new tactics
Skeeve Stevens wrote: Agreed. Keeping it separate works very well. Can be the same interface sure... but do it as a separate session. Yeah, that's what I thought, and that is exactly what I've been doing thus far. I was hoping to have a v6-only core, but in order to get the current project done, I'll have to stay with your (and Nathan's) recommendation. I'm not ready for MPLS (but I am interested in the theory of it's purpose), so when I'm done what I'm doing now, I'll look at it. At that time, if implemented, I'll be the most complex, smallest ISP in Canada ;) This has been an awesome journey, and I've learnt an immense amount via all of the recommendations, reading and exercising. Thanks guys, Steve
outblaze contact
Hi, I'm looking to chat to someone from outblaze. If anyone works at outblaze or has a contact there can you chat to me offlist. Regards --jm
Database backed DNS Management Solutions
Dear NANOG: I hope I can solicit some feedback from this venerable group. :-) Currently, my group operates 16 BIND servers across 5 datacenters, handling internal and external namespace duties. These servers are responsible for both internal and external forward and reverse name and IP spaces. There are also a number of Windows AD servers that hold their own namespaces, that the BIND servers slave from this info from, so names resolve between these domains. Windows AD forwards queries for internal zones it does not own to the appropriate namespace holder. So Windows DNS server interoperability is a business requirement. Some of these zones are dynamic, some are static. None of the dynamic zones are populated via DHCP, but by self-registration. We have heretofore used some in-house scripts for managing this, but obviously, the thought of keeping and managing this data in something other than its current form has caught on in our minds, and so therefore we are looking at a proposal put forth, to replace all of our BIND servers with a PowerDNS infrastructure. BIND has been the backbone of the Internet, and so many of us are wary of replacing BIND, when in essence, BIND itself is not the issue, nor is it broken. Has anyone done any in house comparance of PowerDNS versus BIND-DLZ? Googling has led to some useful info but no useful side by side comparances that are not obviously partisan. I favor something like ProBIND2, that keeps the data in the DB, but does not tie the serving of the data, etc to anything other than BIND. Any success/horror stories from implementing BIND management solutions is very welcome. If anyone has any success/horror stories about PowerDNS, BIND-DLZ, or a system like ProBind2 or NetDB (from Stanford) to manage BIND and its configurations in a DB, I would be very interested in hearing them. :-) Thank you. Best Regards, Ross S. Dmochowski Sr. Linux Administrator IGN/Gamespy/Fox Interactive Media r...@ign.com
Re: Database backed DNS Management Solutions
At the last place I worked at we had an installation of NicTool v1.2. We pushed out DNS updates for our hosting company over 4 servers, two local and two off-site. It was very nice to work with, but I havent used it in the 2.x iteration. http://www.nictool.com/ - Give it a look-over. Supports BIND, TinyDNS, and PowerDNS. -Israel Ross Dmochowski wrote: Dear NANOG: I hope I can solicit some feedback from this venerable group. :-) Currently, my group operates 16 BIND servers across 5 datacenters, handling internal and external namespace duties. These servers are responsible for both internal and external forward and reverse name and IP spaces. There are also a number of Windows AD servers that hold their own namespaces, that the BIND servers slave from this info from, so names resolve between these domains. Windows AD forwards queries for internal zones it does not own to the appropriate namespace holder. So Windows DNS server interoperability is a business requirement. Some of these zones are dynamic, some are static. None of the dynamic zones are populated via DHCP, but by self-registration. We have heretofore used some in-house scripts for managing this, but obviously, the thought of keeping and managing this data in something other than its current form has caught on in our minds, and so therefore we are looking at a proposal put forth, to replace all of our BIND servers with a PowerDNS infrastructure. BIND has been the backbone of the Internet, and so many of us are wary of replacing BIND, when in essence, BIND itself is not the issue, nor is it broken. Has anyone done any in house comparance of PowerDNS versus BIND-DLZ? Googling has led to some useful info but no useful side by side comparances that are not obviously partisan. I favor something like ProBIND2, that keeps the data in the DB, but does not tie the serving of the data, etc to anything other than BIND. Any success/horror stories from implementing BIND management solutions is very welcome. If anyone has any success/horror stories about PowerDNS, BIND-DLZ, or a system like ProBind2 or NetDB (from Stanford) to manage BIND and its configurations in a DB, I would be very interested in hearing them. :-) Thank you. Best Regards, Ross S. Dmochowski Sr. Linux Administrator IGN/Gamespy/Fox Interactive Media r...@ign.com
Re: Database backed DNS Management Solutions
I use a PowerDNS setup with mysql backend. It works really well for our 5 dns server setup. Things to watch out for are replication breaks in the mysql database. On Tue, Feb 3, 2009 at 9:19 PM, Israel Lopez - Lists ilopezli...@sandboxitsolutions.com wrote: At the last place I worked at we had an installation of NicTool v1.2. We pushed out DNS updates for our hosting company over 4 servers, two local and two off-site. It was very nice to work with, but I havent used it in the 2.x iteration. http://www.nictool.com/ - Give it a look-over. Supports BIND, TinyDNS, and PowerDNS. -Israel Ross Dmochowski wrote: Dear NANOG: I hope I can solicit some feedback from this venerable group. :-) Currently, my group operates 16 BIND servers across 5 datacenters, handling internal and external namespace duties. These servers are responsible for both internal and external forward and reverse name and IP spaces. There are also a number of Windows AD servers that hold their own namespaces, that the BIND servers slave from this info from, so names resolve between these domains. Windows AD forwards queries for internal zones it does not own to the appropriate namespace holder. So Windows DNS server interoperability is a business requirement. Some of these zones are dynamic, some are static. None of the dynamic zones are populated via DHCP, but by self-registration. We have heretofore used some in-house scripts for managing this, but obviously, the thought of keeping and managing this data in something other than its current form has caught on in our minds, and so therefore we are looking at a proposal put forth, to replace all of our BIND servers with a PowerDNS infrastructure. BIND has been the backbone of the Internet, and so many of us are wary of replacing BIND, when in essence, BIND itself is not the issue, nor is it broken. Has anyone done any in house comparance of PowerDNS versus BIND-DLZ? Googling has led to some useful info but no useful side by side comparances that are not obviously partisan. I favor something like ProBIND2, that keeps the data in the DB, but does not tie the serving of the data, etc to anything other than BIND. Any success/horror stories from implementing BIND management solutions is very welcome. If anyone has any success/horror stories about PowerDNS, BIND-DLZ, or a system like ProBind2 or NetDB (from Stanford) to manage BIND and its configurations in a DB, I would be very interested in hearing them. :-) Thank you. Best Regards, Ross S. Dmochowski Sr. Linux Administrator IGN/Gamespy/Fox Interactive Media r...@ign.com
