Re: IPv6 Default Allocation - What size allocation are you giving out
On (2014-10-09 15:25 +1100), Mark Andrews wrote: Hi, Because /64 only allows for a single subnet running SLAAC with currently defined specifications. I fully agree that larger than 64 must be allocation, in mobile internet, residental DSL, everywhere. I don't think it will happen, but I think it should and I'm happy to say that I was able to impact the national regulatory authority to include this in their recommendation for how IPv6 should be provided. Having routable network is only benefit of IPv6 over IPv4, and if we just give customers connected /64 network, without routing /56 there, then customers will need NAT. However, technically SLAAC is happy with arbitrarily small network, and some kit support this (like Cisco). You're going to have to do DAD anyhow, because uniqueness is not guaranteed. -- ++ytti
Re: IPv6 Default Allocation - What size allocation are you giving out
On Wed, Oct 8, 2014 at 10:48 PM, James R Cutler james.cut...@consultant.com wrote: On Oct 8, 2014, at 9:18 PM, Erik Sundberg esundb...@nitelusa.com wrote: I am planning out our IPv6 deployment right now and I am trying to figure out our default allocation for customer LAN blocks. So what is everyone giving for a default LAN allocation for IPv6 Customers. I guess the idea of handing a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me cringe at the waste. Especially when you know 90% of customers will never have more than 2 or 3 subnets. As I see it the customer can always ask for more IPv6 Space. /64 /60 /56 /48 Hi Erik, You're asking the right question and you understand the divisible-by-four rule for prefix delegation, which is good. The answer I recommend is: 1. Nothing smaller than /56 unless you know enough about the situation to be sure /56 is unnecessary. In particular, never provide a /64 to a customer... delegate nothing between /61 and /123, ever. You'll just be making mess that you have to clean up later when it turns out they needed 3 LANs after all. 2. Suggest /56 for residential and /48 for business customers as default, didn't ask for something else sizes. 3. /48 for anyone who makes the effort to ask, including residential customers. 99% won't ask and won't care any time in the foreseeable future. 4. Referral to ARIN for anyone who requests more than a /48. If they have a good reason for needing more than 65,000 LANs that reason is likely good enough to justify a direct ARIN assignment. If they don't have a good reason, the experience will teach them that without needing to get them mad at you. Selection of a default prefix is easy. Here are the steps. 4. Keeping in mind 4.1 Prefixes longer than somewhere around /48 to /56 may be excluded from the global routing table 4.1a Prefix cutouts of any size (including /48) from inside your /32 or larger block may be excluded from the global routing table. Folks who are multihomed and thus need to advertise their own block with BGP should be referred to ARIN for a direct assignment. Folks who aren't multihomed, well, until given evidence otherwise I claim there are no single-homed entities who will use 65,000 LANs, let alone more. 4.2 Your customers want working Internet connections 4.3 You want income at a minimum of ongoing expense make a sensible business decision. IPv6 is large but not infinite. No need to be conservative, but profligate consumption is equally without merit. Regards, Bill Herrin -- William Herrin her...@dirtside.com b...@herrin.us Owner, Dirtside Systems . Web: http://www.dirtside.com/ May I solve your unusual networking challenges?
Re: wifi blocking [was Re: Marriott wifi blocking]
On Oct 8, 2014, at 2:11 PM, William Herrin b...@herrin.us wrote: On Wed, Oct 8, 2014 at 4:37 PM, joel jaeggli joe...@bogus.com wrote: On 10/8/14 1:29 PM, Larry Sheldon wrote: On 10/8/2014 08:47, William Herrin wrote: BART would not have had an FCC license. They'd have had contracts with the various phone companies to co-locate equipment and provide wired backhaul out of the tunnels. The only thing they'd be guilty of is breach of contract, and that only if the cell phone companies decided their behavior was inconsistent with the SLA.. OK that makes more sense than the private answer I got from Roy. I wondered why the FCC didn't take action if there was a license violation. http://www.nytimes.com/2012/03/03/technology/fcc-reviews-need-for-rules-to-interrupt-wireless-service.html?_r=0 From the article: Among the issues on which the F.C.C. is seeking comment is whether it even has authority over the issue. Also: The BART system owns the wireless transmitters and receivers that allow for cellphone reception within its network.” I’m not sure that statement is accurate. However, there is no prohibition against owning a Microcell or other cellular station which is operated by a third party under said third party’s license. I'm not entirely clear how that works. If that were truly the case (and I don’t think it is, given BART statements that “...the cellular providers are basically tenants and are as such subject to…”), I’m pretty sure it would be operated by the cellular carrier under their license as a non-owner of the equipment. Owen
Re: wifi blocking [was Re: Marriott wifi blocking]
As I recall, BART does not permit anything on their trains--water, baby bottles, and I thought radios. How do they get the authority to do that? They do not permit eating or drinking. You can carry water, baby bottles, etc. on BART trains. You can carry a radio. You can operate a radio. You are prohibited from operating a radio in a manner that is disruptive to other passengers just as on almost any other form of public transit. If you’ve got headphones/earbuds/whatever and use them in a way that doesn’t subject the people around you to the noise coming out of your electronics, then rock out to your heart’s content. Owen
Re: wifi blocking [was Re: Marriott wifi blocking]
On 10/9/2014 02:03, Owen DeLong wrote: On Oct 8, 2014, at 2:11 PM, William Herrin b...@herrin.us wrote: On Wed, Oct 8, 2014 at 4:37 PM, joel jaeggli joe...@bogus.com wrote: On 10/8/14 1:29 PM, Larry Sheldon wrote: On 10/8/2014 08:47, William Herrin wrote: BART would not have had an FCC license. They'd have had contracts with the various phone companies to co-locate equipment and provide wired backhaul out of the tunnels. The only thing they'd be guilty of is breach of contract, and that only if the cell phone companies decided their behavior was inconsistent with the SLA.. OK that makes more sense than the private answer I got from Roy. I wondered why the FCC didn't take action if there was a license violation. http://www.nytimes.com/2012/03/03/technology/fcc-reviews-need-for-rules-to-interrupt-wireless-service.html?_r=0 From the article: Among the issues on which the F.C.C. is seeking comment is whether it even has authority over the issue. Also: The BART system owns the wireless transmitters and receivers that allow for cellphone reception within its network.” I’m not sure that statement is accurate. However, there is no prohibition against owning a Microcell or other cellular station which is operated by a third party under said third party’s license. I'm not entirely clear how that works. If that were truly the case (and I don’t think it is, given BART statements that “...the cellular providers are basically tenants and are as such subject to…”), I’m pretty sure it would be operated by the cellular carrier under their license as a non-owner of the equipment. What where the laws and practices in the Olde Days of over-the-air TV when somebody in a small town installed a translator to repeat Big-Cities-TV-Station into a small town? -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes
Re: IPv6 Default Allocation - What size allocation are you giving out
Stop cringing and give them /48s. It’s really not going to harm anything. Really. Look at the math. That scale of waste is a very very pale glimmer compared to the LAN side of things where you have 18,000,000,000,000,000,000 (and then some) addresses left over after you put a few hundred thousand hosts on the segment. Also, claiming that 90% will never have more than 2 or 3 subnets simply displays a complete lack of imagination. Household networks will continue to gain sophistication and with automated topologies developed through more advanced applications of DHCP-PD, you will, in fact, start seeing things like WLAN+GuestWLAN+LAN on separate segments, entertainment systems which generate their own segment(s), appliance networks which have separate routed segments, etc. Unfortunately, most of these future applications don’t stand a chance while we’re still mired in IPv4 and IPv4-think about how to allocate addresses. Owen On Oct 8, 2014, at 6:18 PM, Erik Sundberg esundb...@nitelusa.com wrote: I am planning out our IPv6 deployment right now and I am trying to figure out our default allocation for customer LAN blocks. So what is everyone giving for a default LAN allocation for IPv6 Customers. I guess the idea of handing a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me cringe at the waste. Especially when you know 90% of customers will never have more than 2 or 3 subnets. As I see it the customer can always ask for more IPv6 Space. /64 /60 /56 /48 Small Customer? Medium Customer? Large Customer? Thanks Erik CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you.
Re: wifi blocking [was Re: Marriott wifi blocking]
On 10/9/2014 02:06, Owen DeLong wrote: As I recall, BART does not permit anything on their trains--water, baby bottles, and I thought radios. How do they get the authority to do that? They do not permit eating or drinking. You can carry water, baby bottles, etc. on BART trains. You can carry a radio. You can operate a radio. You are prohibited from operating a radio in a manner that is disruptive to other passengers just as on almost any other form of public transit. If you’ve got headphones/earbuds/whatever and use them in a way that doesn’t subject the people around you to the noise coming out of your electronics, then rock out to your heart’s content. OK. Not relevant to the discussion then. (I was once told not to drink from what I was carrying. And told I could take a cup of coffee aboard. But the was long ago.) -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes
Re: wifi blocking [was Re: Marriott wifi blocking]
On 10/9/2014 02:16, Larry Sheldon wrote: On 10/9/2014 02:03, Owen DeLong wrote: On Oct 8, 2014, at 2:11 PM, William Herrin b...@herrin.us wrote: On Wed, Oct 8, 2014 at 4:37 PM, joel jaeggli joe...@bogus.com wrote: On 10/8/14 1:29 PM, Larry Sheldon wrote: On 10/8/2014 08:47, William Herrin wrote: BART would not have had an FCC license. They'd have had contracts with the various phone companies to co-locate equipment and provide wired backhaul out of the tunnels. The only thing they'd be guilty of is breach of contract, and that only if the cell phone companies decided their behavior was inconsistent with the SLA.. OK that makes more sense than the private answer I got from Roy. I wondered why the FCC didn't take action if there was a license violation. http://www.nytimes.com/2012/03/03/technology/fcc-reviews-need-for-rules-to-interrupt-wireless-service.html?_r=0 From the article: Among the issues on which the F.C.C. is seeking comment is whether it even has authority over the issue. Also: The BART system owns the wireless transmitters and receivers that allow for cellphone reception within its network.” I’m not sure that statement is accurate. However, there is no prohibition against owning a Microcell or other cellular station which is operated by a third party under said third party’s license. I'm not entirely clear how that works. If that were truly the case (and I don’t think it is, given BART statements that “...the cellular providers are basically tenants and are as such subject to…”), I’m pretty sure it would be operated by the cellular carrier under their license as a non-owner of the equipment. What where the laws and practices in the Olde Days of over-the-air TV when somebody in a small town installed a translator to repeat Big-Cities-TV-Station into a small town? -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes
Re: IPv6 Default Allocation - What size allocation are you giving out
I’ll go a step further… If you give a residential customer the /48 that they should be getting, then as DHCP-PD and automatic topologies become more widespread, you have enabled flexibility in the breadth and depth of the bit patterns used to facilitate such hierarchies in the home network environment. If you limit them to 8 bits of subnetting, you are very limited in the constructs (1x8, 2x4, 4x2, or 8x1) which can be achieved. Further, there’s really no advantage to keeping so much extra IPv6 address space on the shelves long past the expiration of the protocol’s useful life. I guarantee you that unless we start doing really stupid things (like using IPv6 /48s as serial numbers for cars), giving /48s to residential customers will not exhaust the current /3 (1/8th of the total IPv6 space) before we hit some other limitation of the protocol. Owen On Oct 8, 2014, at 9:07 PM, Faisal Imtiaz fai...@snappytelecom.net wrote: Like I said, this was my understanding I am glad that it is being pointed out to be in-correct I don't have a reason for why a /64 as much as I also don't have any reason Why NOT So, let me ask the question in a different manner... What is the wisdom / reasoning behind needing to give a /56 to a Residential customer (vs a /64). Regards. Faisal Imtiaz Snappy Internet Telecom - Original Message - From: Sam Silvester sam.silves...@gmail.com To: Faisal Imtiaz fai...@snappytelecom.net Cc: Erik Sundberg esundb...@nitelusa.com, NANOG nanog@nanog.org Sent: Wednesday, October 8, 2014 11:47:01 PM Subject: Re: IPv6 Default Allocation - What size allocation are you giving out Why would you only allocate a residential customer a single /64? That's totally short sighted in my view. On Thu, Oct 9, 2014 at 2:07 PM, Faisal Imtiaz fai...@snappytelecom.net wrote: We are going thru a similar process.. from all of my reading, best practice discussions etc.. Here is what i have understood so far:- Residential Customers: /64 Small Medium size Business Customers: /56 Large Business size or a multi-location Business Customer: /48 Don't skimp on allocating the subnets like we do on IPv4 Better to be 'wasteful' than have to come back to re-number or re-allocate . Regards Faisal Imtiaz Snappy Internet Telecom - Original Message - From: Erik Sundberg esundb...@nitelusa.com To: nanog@nanog.org Sent: Wednesday, October 8, 2014 9:18:16 PM Subject: IPv6 Default Allocation - What size allocation are you giving out I am planning out our IPv6 deployment right now and I am trying to figure out our default allocation for customer LAN blocks. So what is everyone giving for a default LAN allocation for IPv6 Customers. I guess the idea of handing a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me cringe at the waste. Especially when you know 90% of customers will never have more than 2 or 3 subnets. As I see it the customer can always ask for more IPv6 Space. /64 /60 /56 /48 Small Customer? Medium Customer? Large Customer? Thanks Erik CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you.
Re: IPv6 Default Allocation - What size allocation are you giving out
On Oct 8, 2014, at 11:54 PM, Saku Ytti s...@ytti.fi wrote: On (2014-10-09 15:25 +1100), Mark Andrews wrote: Hi, Because /64 only allows for a single subnet running SLAAC with currently defined specifications. I fully agree that larger than 64 must be allocation, in mobile internet, residental DSL, everywhere. I don't think it will happen, but I think it should and I'm happy to say that I was able to impact the national regulatory authority to include this in their recommendation for how IPv6 should be provided. Sadly there are pieces of 3GPP that limit LTE to single /64 already. These should, IMHO, be fixed. Having routable network is only benefit of IPv6 over IPv4, and if we just give customers connected /64 network, without routing /56 there, then customers will need NAT. It’s not the only benefit, it is one of many benefits. Owen
Re: IPv6 Default Allocation - What size allocation are you giving out
On Oct 8, 2014, at 10:06 PM, Hugo Slabbert h...@slabnet.com wrote: Mark, Only short sighted ISP's hand out /56's to residential customers. I am curious as to why you say it is short sighted? what is the technical or otherwise any other reasoning for such statement ? 256 is *not* a big number of subnets. By restricting the number of subnets residences get you restrict what developers will design for. Subnets don't need to be scares resource. ISP's that default to /56 are making them a scares resource. The excerpt Royce quoted from RFC6177 (requoted below) seems to back away from /48s by default to all resi users and land in a somewhat vague more than a /64 please, but we're not specifically recommending /48s across the board for residential before specifically mentioning /56 assignments. Yes, but if you review the record as 6177 was rammed through against somewhat vociferous objection to this part, you should realize that that part really didn’t achieve near the level of consensus that should have been required for it to be accepted. The general push in the community is towards /48 across the board. Any comments on why the RFC backs away from that? Is this just throwing a bone to the masses complaining about waste”? It was a political maneuver to appease the IPv4 thinkers that were prevalent in that part of the IETF at the time. (Just my opinion). Owen
Re: wifi blocking [was Re: Marriott wifi blocking]
On Oct 9, 2014, at 12:16 AM, Larry Sheldon larryshel...@cox.net wrote: On 10/9/2014 02:03, Owen DeLong wrote: On Oct 8, 2014, at 2:11 PM, William Herrin b...@herrin.us wrote: On Wed, Oct 8, 2014 at 4:37 PM, joel jaeggli joe...@bogus.com wrote: On 10/8/14 1:29 PM, Larry Sheldon wrote: On 10/8/2014 08:47, William Herrin wrote: BART would not have had an FCC license. They'd have had contracts with the various phone companies to co-locate equipment and provide wired backhaul out of the tunnels. The only thing they'd be guilty of is breach of contract, and that only if the cell phone companies decided their behavior was inconsistent with the SLA.. OK that makes more sense than the private answer I got from Roy. I wondered why the FCC didn't take action if there was a license violation. http://www.nytimes.com/2012/03/03/technology/fcc-reviews-need-for-rules-to-interrupt-wireless-service.html?_r=0 From the article: Among the issues on which the F.C.C. is seeking comment is whether it even has authority over the issue. Also: The BART system owns the wireless transmitters and receivers that allow for cellphone reception within its network.” I’m not sure that statement is accurate. However, there is no prohibition against owning a Microcell or other cellular station which is operated by a third party under said third party’s license. I'm not entirely clear how that works. If that were truly the case (and I don’t think it is, given BART statements that “...the cellular providers are basically tenants and are as such subject to…”), I’m pretty sure it would be operated by the cellular carrier under their license as a non-owner of the equipment. What where the laws and practices in the Olde Days of over-the-air TV when somebody in a small town installed a translator to repeat Big-Cities-TV-Station into a small town? The translator had to be operated by a holder of an FCC license for that translator. Operator and Owner are not necessarily linked in any way shape or form, though they usually were one and the same. Owen
Re: IPv6 Default Allocation - What size allocation are you giving out
On (2014-10-09 00:37 -0700), Owen DeLong wrote: Sadly there are pieces of 3GPP that limit LTE to single /64 already. These should, IMHO, be fixed. According to the national IPv6 residential recommendation 3GPP release 10 offers prefix delegation, which will facilitate this. Having routable network is only benefit of IPv6 over IPv4, and if we just give customers connected /64 network, without routing /56 there, then customers will need NAT. It’s not the only benefit, it is one of many benefits. Yeah mailing list volume is the other one. -- ++ytti
Re: IPv6 Default Allocation - What size allocation are you giving out
On Thu, 2014-10-09 at 04:59 +, Peter Rocca wrote: To paraphrase a post on this list a while ago (my apologies for lack of reference). There are two kinds of waste: - the first kind of waste is providing 'too many' subnets for someone; - the second kind of waste is leaving the space unallocated forever. Good point. But I maintain that too many is exactly the right number, and not a waste at all :-) There are only three amounts of any scarce resource - too little, enough, and I don't know. In an ideal world nobody knows how much disk space, RAM, bandwidth or address space they have - they never run into their limits. IPv6 has ticked the box for address space - why are so many people intent on unticking it? In my courses on IPv6, wasted address space *always* comes up. I define waste as spending some finite resource for no benefit. With IPv6, the resource is extremely abundant, though admittedly not infinite. And the benefits from handing out big allocations are numerous: - never resize an allocation - never have to add an allocation - never have to take a phone call asking to resize an allocation - all prefixes are the same length - easier, faster, simpler to allocate, manage, filter, firewall, document... ... and that's just to start with. It all translates into cheaper, easier, less error-prone. And the benefits are reaped by both parties - the provider and the customer. There's a case to be made, also, that simpler is more secure, because simpler and more homogeneous networks are easier to understand, easier to manage, and this suffer less from human error and so on. This is what you are buying with short prefixes. There are clear benefits, so it's not waste. There's another point though, that I may have made before in this forum, and that is that whether you have 2, 200 or 2000 nodes in a /64, you are still using, to many decimal places, zero percent of the available address space. The number of live nodes is barely even statistical noise. So worrying about *addresses* in IPv6 is completely pointless. Thinking about subnets, on the other hand, does make sense - and 256 subnets (in a /56) is not very many. It's trivially easy to dream up an entirely plausible scenario where an ordinary household chews through that many subnets before breakfast. Give them a /48! Give everyone a /48. There is *enough address space* for goodness sake. All you are doing by saving space is putting a completely unnecessary brake on the future - yours and theirs. Give them more subnets, literally, than they or you know what to do with. So many that we can't even conceive of anyone using that many. That way subnets, like addresses, cease to be a limitation. How many subnets do you have? I don't know - does it matter? That's where you want to be. Don't let your limited vision limit other people. Even if YOU can't see the point, rest assured that some bright young thing just leaving high school will dream up something world-changingly wonderful that needs ten thousand subnets per household... Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 Old fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A
Re: IPv6 Default Allocation - What size allocation are you giving out
On Thu, 9 Oct 2014, Owen DeLong wrote: Sadly there are pieces of 3GPP that limit LTE to single /64 already. These should, IMHO, be fixed. DHCPv6-PD is already standardized in 3GPP several years ago, it just hasn't made it widely into equipment out there yet. That's why current best way to do this is to share the /64 between the PDP context and the LAN. This of course is quite limiting, but it wouldn't surprise me if we'll see differentiation here between mobile Internet and regular handset Internet subscriptions unfortunately. I fully support giving all devices whatever they request, stop differentiating between different kinds of devices, and just charge where the costs are, ie on packets moved. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: wifi blocking [was Re: Marriott wifi blocking]
On 10/9/2014 02:40, Owen DeLong wrote: What where the laws and practices in the Olde Days of over-the-air TV when somebody in a small town installed a translator to repeat Big-Cities-TV-Station into a small town? The translator had to be operated by a holder of an FCC license for that translator. Operator and Owner are not necessarily linked in any way shape or form, though they usually were one and the same. Was the translator operator obligated to carry everything from the source station, or could they turn the translator off if they wanted to? -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes
Re: IPv6 Default Allocation - What size allocation are you giving out
We assign a /128 by DHCPv6 (*). And then we assign a /48 by DHCPv6-PD prefix delegation. To everyone no matter what class of customer they are. You are thinking about it wrong. It is not about what the customer need but about what you need. Do you really have a need to use more than 48 bits for your routing? Do we need more than 48 bits for the global routing table? Do we need more than 48 bits to conserve enough address space for any conceivable future setting? The answer is no to all of these, so why are you trying to decide what a user could be doing with the remaining address bits? What if IPv6 had been designed with a variable address length, such that you could do 2048 bits addresses if you wanted. What prefix length would you choose if that was the case? Where do you stop? Would you really be giving out /1024 because otherwise it would be wasteful? No, I believe you would be giving out /48s. (*) using /128 on the subscriber link solves a security issue and makes deployments on asymmetric links easier. Again we are doing it because of operational issues and not because we are trying to conserve address space. Regrads, Baldur On 9 October 2014 03:18, Erik Sundberg esundb...@nitelusa.com wrote: I am planning out our IPv6 deployment right now and I am trying to figure out our default allocation for customer LAN blocks. So what is everyone giving for a default LAN allocation for IPv6 Customers. I guess the idea of handing a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me cringe at the waste. Especially when you know 90% of customers will never have more than 2 or 3 subnets. As I see it the customer can always ask for more IPv6 Space. /64 /60 /56 /48 Small Customer? Medium Customer? Large Customer? Thanks Erik CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you.
Re: IPv6 Default Allocation - What size allocation are you giving out
On 9 October 2014 05:40, Mark Andrews ma...@isc.org wrote: In message 482678376.131852.1412829159356.javamail.zim...@snappytelecom.net, Faisal Imtiaz writes: Only short sighted ISP's hand out /56's to residential customers. I am curious as to why you say it is short sighted? what is the technical or otherwise any other reasoning for such statement ? 256 is *not* a big number of subnets. By restricting the number of subnets residences get you restrict what developers will design for. Subnets don't need to be scares resource. ISP's that default to /56 are making them a scares resource. My moment of clarity came when I got a /56 routed to my house and started using it. I started off thinking that 256 was a huge number of subnets, more than I could ever need. What I realised was that (sticking to best practices) a /56 only allows you one further level of delegation, and I found that to be more of a barrier than the number of subnets. In the same way that you stop thinking /64 is a lot of addresses and start thinking /64 is a network I find it helps to stop thinking /48 is 65536 subnets and start thinking /48 allows you up to 4 levels of delegation. Dan
Re: IPv6 Default Allocation - What size allocation are you giving out
On Thu, 2014-10-09 at 09:46 +0100, Daniel Ankers wrote: What I realised was that (sticking to best practices) You mean subnet only on 4-bit boundaries? Nibble boundaries are nice for human readability, but if there is a good technical reason for other boundaries, you shouldn't shy away from them. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 Old fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A
Re: IPv6 Default Allocation - What size allocation are you giving out
yes! by ALL means, hand out /48s. There is huge benefit to announcing all that dark space, esp. when virtually no one practices BCP-38, esp in IPv6 land. /bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 8October2014Wednesday, at 18:31, Mark Andrews ma...@isc.org wrote: Give them a /48. This is IPv6 not IPv4. Take the IPv4 glasses off and put on the IPv6 glasses. Stop constraining your customers because you feel that it is a waste. It is not a waste It will also reduce the number of exceptions you need to process and make over all administration easier. As for only two subnets, I expect lots of equipment to request prefixes in the future not just traditional routers. It will have descrete internal components which communicate using IPv6 and those components need to talk to each other and the world. In a IPv4 world they would be NAT'd. In a IPv6 world the router requests a prefix. Mark In message 495d0934da46854a9ca758393724d5906da...@ni-mail02.nii.ads, Erik Sun dberg writes: I am planning out our IPv6 deployment right now and I am trying to figure o= ut our default allocation for customer LAN blocks. So what is everyone givi= ng for a default LAN allocation for IPv6 Customers. I guess the idea of ha= nding a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me cring= e at the waste. Especially when you know 90% of customers will never have m= ore than 2 or 3 subnets. As I see it the customer can always ask for more I= Pv6 Space. /64 /60 /56 /48 Small Customer? Medium Customer? Large Customer? Thanks Erik CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files = or previous e-mail messages attached to it may contain confidential informa= tion that is legally privileged. If you are not the intended recipient, or = a person responsible for delivering it to the intended recipient, you are h= ereby notified that any disclosure, copying, distribution or use of any of = the information contained in or attached to this transmission is STRICTLY P= ROHIBITED. If you have received this transmission in error please notify th= e sender immediately by replying to this e-mail. You must destroy the origi= nal transmission and its attachments without reading or saving in any manne= r. Thank you. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 Default Allocation - What size allocation are you giving out
In message 1aa6f1a9-d63b-4066-903d-0e8690c7c...@isi.edu, manning bill writes: yes! by ALL means, hand out /48s. There is huge benefit to announcing = all that dark space, esp. when virtually no one practices BCP-38, esp in IPv6 land. /bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102 and if everyone hands out /48's you just filter /48's. With a mix of /56 and /48 you need to filter at the /56 level. Given enterpises are getting /48's it will be simpler overall for everyone to get /48's. On 8October2014Wednesday, at 18:31, Mark Andrews ma...@isc.org wrote: =20 Give them a /48. This is IPv6 not IPv4. Take the IPv4 glasses off and put on the IPv6 glasses. Stop constraining your customers because you feel that it is a waste. It is not a waste It will also reduce the number of exceptions you need to process and make over all administration easier. =20 As for only two subnets, I expect lots of equipment to request prefixes in the future not just traditional routers. It will have descrete internal components which communicate using IPv6 and those components need to talk to each other and the world. In a IPv4 world they would be NAT'd. In a IPv6 world the router requests a prefix. =20 Mark =20 In message 495d0934da46854a9ca758393724d5906da...@ni-mail02.nii.ads, = Erik Sun dberg writes: I am planning out our IPv6 deployment right now and I am trying to = figure o=3D ut our default allocation for customer LAN blocks. So what is = everyone givi=3D ng for a default LAN allocation for IPv6 Customers. I guess the idea = of ha=3D nding a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me = cring=3D e at the waste. Especially when you know 90% of customers will never = have m=3D ore than 2 or 3 subnets. As I see it the customer can always ask for = more I=3D Pv6 Space. =20 /64 /60 /56 /48 =20 Small Customer? Medium Customer? Large Customer? =20 Thanks =20 Erik =20 =20 CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, = files =3D or previous e-mail messages attached to it may contain confidential = informa=3D tion that is legally privileged. If you are not the intended = recipient, or =3D a person responsible for delivering it to the intended recipient, you = are h=3D ereby notified that any disclosure, copying, distribution or use of = any of =3D the information contained in or attached to this transmission is = STRICTLY P=3D ROHIBITED. If you have received this transmission in error please = notify th=3D e sender immediately by replying to this e-mail. You must destroy the = origi=3D nal transmission and its attachments without reading or saving in any = manne=3D r. Thank you. --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
OT: A certain WISP operator puts Sir Tim in his place
Noted, with some amusement, in the comments to a NY Times piece in which Sir Tim Berners-Lee speaks out for net neutrality: http://bits.blogs.nytimes.com/2014/10/08/tim-berners-lee-web-creator-defends-net-neutrality/ --quote-- Brett Glass Laramie, WY 16 hours ago http://bits.blogs.nytimes.com/2014/10/08/tim-berners-lee-web-creator-defends-net-neutrality/#permid=13003978 Berners-Lee is an Internet application developer (he developed an early one that was never commercially successful -- in fact, no Web browser has been commercially successful -- but important nonetheless). He thus has the biases of one. He has never worked as an ISP, operated an ISP, or managed an Internet service. [snip] --end quote
Re: IPv6 Default Allocation - What size allocation are you giving out
makes more sense to hand out /48s imho. theres only a mere 65k /48s per /32 (or something like that), though. On 10/09/14 12:29, Mark Andrews wrote: In message 1aa6f1a9-d63b-4066-903d-0e8690c7c...@isi.edu, manning bill writes: yes! by ALL means, hand out /48s. There is huge benefit to announcing = all that dark space, esp. when virtually no one practices BCP-38, esp in IPv6 land. /bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102 and if everyone hands out /48's you just filter /48's. With a mix of /56 and /48 you need to filter at the /56 level. Given enterpises are getting /48's it will be simpler overall for everyone to get /48's. On 8October2014Wednesday, at 18:31, Mark Andrews ma...@isc.org wrote: =20 Give them a /48. This is IPv6 not IPv4. Take the IPv4 glasses off and put on the IPv6 glasses. Stop constraining your customers because you feel that it is a waste. It is not a waste It will also reduce the number of exceptions you need to process and make over all administration easier. =20 As for only two subnets, I expect lots of equipment to request prefixes in the future not just traditional routers. It will have descrete internal components which communicate using IPv6 and those components need to talk to each other and the world. In a IPv4 world they would be NAT'd. In a IPv6 world the router requests a prefix. =20 Mark =20 In message 495d0934da46854a9ca758393724d5906da...@ni-mail02.nii.ads, = Erik Sun dberg writes: I am planning out our IPv6 deployment right now and I am trying to = figure o=3D ut our default allocation for customer LAN blocks. So what is = everyone givi=3D ng for a default LAN allocation for IPv6 Customers. I guess the idea = of ha=3D nding a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me = cring=3D e at the waste. Especially when you know 90% of customers will never = have m=3D ore than 2 or 3 subnets. As I see it the customer can always ask for = more I=3D Pv6 Space. =20 /64 /60 /56 /48 =20 Small Customer? Medium Customer? Large Customer? =20 Thanks =20 Erik =20 =20 CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, = files =3D or previous e-mail messages attached to it may contain confidential = informa=3D tion that is legally privileged. If you are not the intended = recipient, or =3D a person responsible for delivering it to the intended recipient, you = are h=3D ereby notified that any disclosure, copying, distribution or use of = any of =3D the information contained in or attached to this transmission is = STRICTLY P=3D ROHIBITED. If you have received this transmission in error please = notify th=3D e sender immediately by replying to this e-mail. You must destroy the = origi=3D nal transmission and its attachments without reading or saving in any = manne=3D r. Thank you. --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 Default Allocation - What size allocation are you giving out
On Oct 9, 2014, at 12:07 AM, Faisal Imtiaz fai...@snappytelecom.net wrote: So, let me ask the question in a different manner... What is the wisdom / reasoning behind needing to give a /56 to a Residential customer (vs a /64). The wisdom/reasoning behind larger allocations is to control the cost of doing business. Things change. Customer requirements change. Arrange your network so that customers can do what they need without configuration costs on your part. Follow the money. Then keep it. James R. Cutler james.cut...@consultant.com PGP keys at http://pgp.mit.edu signature.asc Description: Message signed with OpenPGP using GPGMail
Re: IPv6 Default Allocation - What size allocation are you giving out
In message 54366ab9.3040...@gmail.com, Paige Thompson writes: makes more sense to hand out /48s imho. theres only a mere 65k /48s per /32 (or something like that), though. A /32 is the minimum allocation to a ISP. If you have more customers or will have more customers request a bigger block from the RIRs. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Paetech Routing Loop
Is there a Paetech/Windstream tech that could help me with a routing loop in New Hampshire? Thanks, Nathaniel -- http://www.aciworldwide.com This email message and any attachments may contain confidential, proprietary or non-public information. The information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this email, please notify the sender immediately and destroy this email. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this email are those of the author personally.
Re: wifi blocking [was Re: Marriott wifi blocking]
On Oct 9, 2014, at 03:57, Larry Sheldon larryshel...@cox.net wrote: On 10/9/2014 02:40, Owen DeLong wrote: What where the laws and practices in the Olde Days of over-the-air TV when somebody in a small town installed a translator to repeat Big-Cities-TV-Station into a small town? The translator had to be operated by a holder of an FCC license for that translator. Operator and Owner are not necessarily linked in any way shape or form, though they usually were one and the same. Was the translator operator obligated to carry everything from the source station, or could they turn the translator off if they wanted to? I honestly don't know what the license terms were. I am also not aware of any circumstances where that issue was at all likely to come up. Owen -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes
Re: IPv6 Default Allocation - What size allocation are you giving out
Mark Andrews ma...@isc.org writes: In message 54366ab9.3040...@gmail.com, Paige Thompson writes: makes more sense to hand out /48s imho. theres only a mere 65k /48s per /32 (or something like that), though. A /32 is the minimum allocation to a ISP. If you have more customers or will have more customers request a bigger block from the RIRs. Mark Has anyone successfully gotten a RIR to assign anything bigger than a /32? I seem to recall in recent history someone tried to obtain a /31 through ARIN and got smacked down. Even if you're assigning a /56 to every end user, that's still on the order of 16 million allocations. I can't imagine anyone but the truly behemoth access network operators being able to justify a larger allocation with a straight face.
Re: IPv6 Default Allocation - What size allocation are you giving out
Policy allows any ISP (LIR) with need greater than /32 to easily qualify for what they need up to /12. I know of at least two entities that have applied for and with minimal effort and appropriate justification, received /24 allocations and many with /28s. Owen On Oct 9, 2014, at 07:00, Paige Thompson paigead...@gmail.com wrote: makes more sense to hand out /48s imho. theres only a mere 65k /48s per /32 (or something like that), though. On 10/09/14 12:29, Mark Andrews wrote: In message 1aa6f1a9-d63b-4066-903d-0e8690c7c...@isi.edu, manning bill writes: yes! by ALL means, hand out /48s. There is huge benefit to announcing = all that dark space, esp. when virtually no one practices BCP-38, esp in IPv6 land. /bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102 and if everyone hands out /48's you just filter /48's. With a mix of /56 and /48 you need to filter at the /56 level. Given enterpises are getting /48's it will be simpler overall for everyone to get /48's. On 8October2014Wednesday, at 18:31, Mark Andrews ma...@isc.org wrote: =20 Give them a /48. This is IPv6 not IPv4. Take the IPv4 glasses off and put on the IPv6 glasses. Stop constraining your customers because you feel that it is a waste. It is not a waste It will also reduce the number of exceptions you need to process and make over all administration easier. =20 As for only two subnets, I expect lots of equipment to request prefixes in the future not just traditional routers. It will have descrete internal components which communicate using IPv6 and those components need to talk to each other and the world. In a IPv4 world they would be NAT'd. In a IPv6 world the router requests a prefix. =20 Mark =20 In message 495d0934da46854a9ca758393724d5906da...@ni-mail02.nii.ads, = Erik Sun dberg writes: I am planning out our IPv6 deployment right now and I am trying to = figure o=3D ut our default allocation for customer LAN blocks. So what is = everyone givi=3D ng for a default LAN allocation for IPv6 Customers. I guess the idea = of ha=3D nding a customer /56 (256 /64s) or a /48 (65,536 /64s) just makes me = cring=3D e at the waste. Especially when you know 90% of customers will never = have m=3D ore than 2 or 3 subnets. As I see it the customer can always ask for = more I=3D Pv6 Space. =20 /64 /60 /56 /48 =20 Small Customer? Medium Customer? Large Customer? =20 Thanks =20 Erik =20 =20 CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, = files =3D or previous e-mail messages attached to it may contain confidential = informa=3D tion that is legally privileged. If you are not the intended = recipient, or =3D a person responsible for delivering it to the intended recipient, you = are h=3D ereby notified that any disclosure, copying, distribution or use of = any of =3D the information contained in or attached to this transmission is = STRICTLY P=3D ROHIBITED. If you have received this transmission in error please = notify th=3D e sender immediately by replying to this e-mail. You must destroy the = origi=3D nal transmission and its attachments without reading or saving in any = manne=3D r. Thank you. --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 Default Allocation - What size allocation are you giving out
Selection of a default prefix is easy. Here are the steps. 4. Keeping in mind 4.1 Prefixes longer than somewhere around /48 to /56 may be excluded from the global routing table 4.1a Prefix cutouts of any size (including /48) from inside your /32 or larger block may be excluded from the global routing table. Folks who are multihomed and thus need to advertise their own block with BGP should be referred to ARIN for a direct assignment. Folks who aren't multihomed, well, until given evidence otherwise I claim there are no single-homed entities who will use 65,000 LANs, let alone more. = This brings up another interesting question... We operate Two separate networks in two geographical locations (Two ASN), we have a single /32 allocation from ARIN. Question: Should we be asking ARIN for another /32 so that each network has it's own /32 or should be break out the /32 into /36 and use these in each of the geographies ? Regards Faisal Imtiaz Snappy Internet Telecom
Re: IPv6 Default Allocation - What size allocation are you giving out
2014-10-09 16:22 GMT+02:00 Daniel Corbe co...@corbe.net: Has anyone successfully gotten a RIR to assign anything bigger than a /32? I seem to recall in recent history someone tried to obtain a /31 through ARIN and got smacked down. Even if you're assigning a /56 to every end user, that's still on the order of 16 million allocations. I can't imagine anyone but the truly behemoth access network operators being able to justify a larger allocation with a straight face. Ripe is handing out /29 without any additional documentation current IPv4 usage documentation should do the trick to request larger blocks for deployment of /48 to customers
Re: IPv6 Default Allocation - What size allocation are you giving out
On Oct 9, 2014, at 8:31 AM, Mark Andrews ma...@isc.org wrote: As for only two subnets, I expect lots of equipment to request prefixes in the future not just traditional routers. I'm expecting every molecule in every compound to have an embedded IPv6 address which can be read via NFC or some similar technology; and every nanomachine which is pumped into every heart patient to clear out arterial plaque to have one; and every windowblind in every window in every house and apartment and condominium and so forth to have one; etc. And for the vast majority of those addresses to be limited-duration, one-time-use addresses, and for their address space never to be recovered and resubmitted back into the free address pool. Which is one reason why I think that this trend of encouraging overly profligate allocation of IPv6 addresses is ill-considered. We've already seen the folly of /64s for point-to-point links in terms of turning routers and layer-3 switches into sinkholes. Do we really want to turn each and every network, no matter how small, into a 'strange attractor' for potentially significant amounts of irrelevant and undesirable traffic? Yes, I fully understand how huge the IPv6 address space really is - but I also believe that the general conception of what will constitute a node is extremely shortsighted, even by those who are evangelizing the so-called 'Internet of Things', and that a huge proportion of the IPv6 address space will eventually end up being allocated for limited-duration, one-time use in applications such as those cited above. I also believe that we need to drastically expand our projected timescales for the utility of IPv6, while keeping those address-hungry potential applications in mind. -- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Equo ne credite, Teucri. -- Laocoön
Re: IPv6 Default Allocation - What size allocation are you giving out
On Oct 9, 2014, at 2:15 PM, Owen DeLong o...@delong.com wrote: Also, claiming that 90% will never have more than 2 or 3 subnets simply displays a complete lack of imagination. On the contrary, I believe that the increase in the potential address pool size will lead to much flatter, less hierarchical networks - while at the same time leading to most nodes being highly multi-homed into various virtual topologies, thereby leading to significant increases of addresses per node. A 'node' being things like molecules, nanites, window blinds, soda cans, etc. -- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Equo ne credite, Teucri. -- Laocoön
Re: IPv6 Default Allocation - What size allocation are you giving out
I've been using /36s per location, but hm -- great question. How easy is it to get a larger allocation anyway? In RIPE, i.e: you just ask and get a /29 with no questions asked. On 10/9/2014 午後 11:31, Faisal Imtiaz wrote: Selection of a default prefix is easy. Here are the steps. 4. Keeping in mind 4.1 Prefixes longer than somewhere around /48 to /56 may be excluded from the global routing table 4.1a Prefix cutouts of any size (including /48) from inside your /32 or larger block may be excluded from the global routing table. Folks who are multihomed and thus need to advertise their own block with BGP should be referred to ARIN for a direct assignment. Folks who aren't multihomed, well, until given evidence otherwise I claim there are no single-homed entities who will use 65,000 LANs, let alone more. = This brings up another interesting question... We operate Two separate networks in two geographical locations (Two ASN), we have a single /32 allocation from ARIN. Question: Should we be asking ARIN for another /32 so that each network has it's own /32 or should be break out the /32 into /36 and use these in each of the geographies ? Regards Faisal Imtiaz Snappy Internet Telecom
Re: IPv6 Default Allocation - What size allocation are you giving out
On Thu, 2014-10-09 at 10:22 -0400, Daniel Corbe wrote: Has anyone successfully gotten a RIR to assign anything bigger than a /32? I seem to recall in recent history someone tried to obtain a /31 through ARIN and got smacked down. Legend has it that the US DOD applied for a /8 - and got smacked down :-) Even if you're assigning a /56 to every end user, that's still on the order of 16 million allocations. If, as you should be, you are assigning /48s, it's only 65536. Not that big. That's why it's the *minimum* allocation. Larger allocations are possible and I suspect quite common. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 Old fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A
Re: NANOG Digest, Vol 81, Issue 7
www.socialsecurity.gov still down on ipv6. Still looping. wget -6 -T 5 www.socialsecurity.gov --2014-10-09 08:07:23-- http://www.socialsecurity.gov/ Resolving www.socialsecurity.gov (www.socialsecurity.gov)... 2001:1930:c01::, 2001:1930:e03:: Connecting to www.socialsecurity.gov (www.socialsecurity.gov)|2001:1930:c01::|:80... failed: Operation timed out. Connecting to www.socialsecurity.gov (www.socialsecurity.gov)|2001:1930:e03::|:80... failed: Operation timed out. Retrying. traceroute6 2001:1930:c01:: traceroute6 to 2001:1930:c01:: (2001:1930:c01::) from 2607:f2f8:a8e0::2, 64 hops max, 12 byte packets 1 2607:f2f8:a8e0::1 5.481 ms 4.120 ms 0.888 ms 2 ge-0-7-0-24.r04.lsanca03.us.bb.gin.ntt.net 1.328 ms 1.191 ms 0.971 ms 3 2001:428:201:8::1 0.730 ms 0.972 ms 0.965 ms 4 2001:428::205:171:3:171 74.438 ms 73.648 ms 73.578 ms 5 2001:428:a202::2:0:2 82.113 ms 81.696 ms 82.507 ms 6 www.socialsecurity.gov 76.489 ms 75.912 ms 76.092 ms 7 2001:1930:c01::2 77.230 ms 77.517 ms 77.573 ms 8 www.socialsecurity.gov 76.595 ms 76.783 ms 76.536 ms 9 2001:1930:c01::2 77.330 ms 77.325 ms 76.834 ms 10 www.socialsecurity.gov 76.028 ms 76.094 ms 76.156 ms 11 2001:1930:c01::2 77.089 ms 77.477 ms 77.358 ms 12 www.socialsecurity.gov 77.186 ms 76.257 ms 76.257 ms 13 2001:1930:c01::2 77.438 ms 77.671 ms 77.424 ms 14 www.socialsecurity.gov 76.345 ms 75.991 ms 76.521 ms 15 2001:1930:c01::2 77.219 ms 77.347 ms 77.293 ms 16 www.socialsecurity.gov 76.209 ms 76.082 ms 76.115 ms 17 2001:1930:c01::2 77.138 ms 77.717 ms 77.285 ms 18 www.socialsecurity.gov 76.459 ms 76.266 ms 76.355 ms 19 2001:1930:c01::2 77.425 ms 77.231 ms 77.310 ms 20 www.socialsecurity.gov 76.473 ms 76.557 ms 76.285 ms 21 2001:1930:c01::2 77.579 ms 77.708 ms 77.680 ms 22 www.socialsecurity.gov 76.474 ms 76.767 ms 76.532 ms 23 2001:1930:c01::2 106.244 ms 78.282 ms 77.578 ms 24 www.socialsecurity.gov 76.476 ms 76.617 ms 77.532 ms 25 2001:1930:c01::2 77.810 ms 77.645 ms 77.950 ms 26 www.socialsecurity.gov 77.590 ms 76.605 ms 76.981 ms 27 2001:1930:c01::2 77.710 ms 77.766 ms 78.306 ms On Tue, Oct 7, 2014 at 9:50 AM, Ralph Wallace wallac...@verizon.net wrote: Message: 25 Date: Mon, 6 Oct 2014 14:27:48 -0700 From: Ca By cb.li...@gmail.com To: nanog@nanog.org nanog@nanog.org Subject: socialsecurity.gov ipv6 routing loop Message-ID: cad6ajgqhhrbzifrnwh+_dy1woe8hxxhernq0ct-pw+iqvvu...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 in case anyone can help resolve ~Attempting to work this through the Federal IPv6 Task Force and the SSA IPv6 Transition Manager~
Re: IPv6 Default Allocation - What size allocation are you giving out
On Thu, 2014-10-09 at 10:22 -0400, Daniel Corbe wrote: Has anyone successfully gotten a RIR to assign anything bigger than a /32? I seem to recall in recent history someone tried to obtain a /31 through ARIN and got smacked down. Yes; ISTR several /20s and even a /19 were the largest ... until the US DoD got the equivalent of a /13. Quick looks: https://www.sixxs.net/tools/grh/dfp/ http://www.nanog.org/mailinglist/mailarchives/old_archive/2008-05/msg00276.html /TJ
Re: IPv6 Default Allocation - What size allocation are you giving out
On Thu, Oct 9, 2014 at 10:34 AM, Karsten Elfenbein karsten.elfenb...@gmail.com wrote: Ripe is handing out /29 without any additional documentation current IPv4 usage documentation should do the trick to request larger blocks for deployment of /48 to customers And /19s with documentation. Europe will by God not end up with fewer IPv6 addresses than the U.S. like has happened with IPv4. -Bill Herrin -- William Herrin her...@dirtside.com b...@herrin.us Owner, Dirtside Systems . Web: http://www.dirtside.com/ May I solve your unusual networking challenges?
Re: IPv6 Default Allocation - What size allocation are you giving out
On Oct 9, 2014, at 7:22 AM, Daniel Corbe co...@corbe.net wrote: Mark Andrews ma...@isc.org writes: In message 54366ab9.3040...@gmail.com, Paige Thompson writes: makes more sense to hand out /48s imho. theres only a mere 65k /48s per /32 (or something like that), though. A /32 is the minimum allocation to a ISP. If you have more customers or will have more customers request a bigger block from the RIRs. Mark Has anyone successfully gotten a RIR to assign anything bigger than a /32? I seem to recall in recent history someone tried to obtain a /31 through ARIN and got smacked down. I think I answered this before you asked it, but yes,easily on multiple occasions. The largest two allocations I have worked on were /24s, but I’m sure those are not ARIN’s largest allocations. Even if you're assigning a /56 to every end user, that's still on the order of 16 million allocations. I can't imagine anyone but the truly behemoth access network operators being able to justify a larger allocation with a straight face. You should, however, be assigning a /48 to every end user and that’s only 65,536 allocations. Further, you want to be able to aggregate at least one level in your network, so you may not be able to get anything close to 100% efficiency in that distribution. ARIN policy, for example, defines what is known as a Provider Allocation Unit (PAU). Your PAU is the smallest allocation you give to your customers, so if you’re giving out /64s, then your PAU becomes /64. If you’re giving out /56s, then your PAU is /56. As such, you’re better off to give /48s to everyone because that sets your PAU at /48. All of your utilization is measured in terms of PAUs. You then pick an aggregation level in your network to use as your “serving center” definition. It could be the POP, or some higher level of aggregation containing multiple POPs. Look at the number of end sites served by the largest of those “serving centers” and round that up to a power of 16 (a nibble boundary, e.g. 16, 256, 4096, 65536) such that the number of end sites is not more than 75% of the chosen poser of 16. Then take the number of “serving centers” you expect to have in ~5 years (though the exact forward looking time is not actually specified in policy) and round that up to a nibble boundary as well. That is the size of allocation you can get from ARIN. So, for example, if you have 800,000 end-sites served from your largest POP and you have 400 POPs, then, 800,000 would be rounded up to 16,777,216 (24 bits) and your 400 POPs would be rounded up to 4096 (12 bits) so you would end up needing 36 bits. If your PAU is /48, you would apply for and receive a /12. Obviously this is an unusually large example. At a more realistic large ISP scale, let’s say you’ve got 5,000,000 subscribers in your largest serving center, but only 25 serving centers. This would, again, round up to 16,777,216 (24 bits) subscribers per serving center. But your 25 serving centers would round up to 256 (8 bits). That’s 32 bits, so instead of a /12, you’d get a /16. I hope that clarifies things for people. Owen
Re: IPv6 Default Allocation - What size allocation are you giving out
On Oct 9, 2014, at 7:31 AM, Faisal Imtiaz fai...@snappytelecom.net wrote: Selection of a default prefix is easy. Here are the steps. 4. Keeping in mind 4.1 Prefixes longer than somewhere around /48 to /56 may be excluded from the global routing table 4.1a Prefix cutouts of any size (including /48) from inside your /32 or larger block may be excluded from the global routing table. Folks who are multihomed and thus need to advertise their own block with BGP should be referred to ARIN for a direct assignment. Folks who aren't multihomed, well, until given evidence otherwise I claim there are no single-homed entities who will use 65,000 LANs, let alone more. = This brings up another interesting question... We operate Two separate networks in two geographical locations (Two ASN), we have a single /32 allocation from ARIN. Question: Should we be asking ARIN for another /32 so that each network has it's own /32 or should be break out the /32 into /36 and use these in each of the geographies ? Depends on your needs… Either is a viable solution, depending on your circumstances. ARIN has an MDN policy which would facilitate your acquisition of a second /32. Owen
Re: IPv6 Default Allocation - What size allocation are you giving out
Sixty replies and no one linked to the BCOP? Is there a reason we are ignoring it? http://bcop.nanog.org/index.php/IPv6_Subnetting As we recently discovered ARIN is handing out IPv6 allocations on nibble boundaries. Either a /32 or /28 for service providers. A justification and utilization plan is need to get a /28. It is also double the cost per year. On Thu, Oct 9, 2014 at 9:01 AM, Owen DeLong o...@delong.com wrote: On Oct 9, 2014, at 7:22 AM, Daniel Corbe co...@corbe.net wrote: Mark Andrews ma...@isc.org writes: In message 54366ab9.3040...@gmail.com, Paige Thompson writes: makes more sense to hand out /48s imho. theres only a mere 65k /48s per /32 (or something like that), though. A /32 is the minimum allocation to a ISP. If you have more customers or will have more customers request a bigger block from the RIRs. Mark Has anyone successfully gotten a RIR to assign anything bigger than a /32? I seem to recall in recent history someone tried to obtain a /31 through ARIN and got smacked down. I think I answered this before you asked it, but yes,easily on multiple occasions. The largest two allocations I have worked on were /24s, but I’m sure those are not ARIN’s largest allocations. Even if you're assigning a /56 to every end user, that's still on the order of 16 million allocations. I can't imagine anyone but the truly behemoth access network operators being able to justify a larger allocation with a straight face. You should, however, be assigning a /48 to every end user and that’s only 65,536 allocations. Further, you want to be able to aggregate at least one level in your network, so you may not be able to get anything close to 100% efficiency in that distribution. ARIN policy, for example, defines what is known as a Provider Allocation Unit (PAU). Your PAU is the smallest allocation you give to your customers, so if you’re giving out /64s, then your PAU becomes /64. If you’re giving out /56s, then your PAU is /56. As such, you’re better off to give /48s to everyone because that sets your PAU at /48. All of your utilization is measured in terms of PAUs. You then pick an aggregation level in your network to use as your “serving center” definition. It could be the POP, or some higher level of aggregation containing multiple POPs. Look at the number of end sites served by the largest of those “serving centers” and round that up to a power of 16 (a nibble boundary, e.g. 16, 256, 4096, 65536) such that the number of end sites is not more than 75% of the chosen poser of 16. Then take the number of “serving centers” you expect to have in ~5 years (though the exact forward looking time is not actually specified in policy) and round that up to a nibble boundary as well. That is the size of allocation you can get from ARIN. So, for example, if you have 800,000 end-sites served from your largest POP and you have 400 POPs, then, 800,000 would be rounded up to 16,777,216 (24 bits) and your 400 POPs would be rounded up to 4096 (12 bits) so you would end up needing 36 bits. If your PAU is /48, you would apply for and receive a /12. Obviously this is an unusually large example. At a more realistic large ISP scale, let’s say you’ve got 5,000,000 subscribers in your largest serving center, but only 25 serving centers. This would, again, round up to 16,777,216 (24 bits) subscribers per serving center. But your 25 serving centers would round up to 256 (8 bits). That’s 32 bits, so instead of a /12, you’d get a /16. I hope that clarifies things for people. Owen
Re: IPv6 Default Allocation - What size allocation are you giving out
On 10/9/14 8:45 AM, TJ wrote: On Thu, 2014-10-09 at 10:22 -0400, Daniel Corbe wrote: Has anyone successfully gotten a RIR to assign anything bigger than a /32? I seem to recall in recent history someone tried to obtain a /31 through ARIN and got smacked down. Yes; ISTR several /20s and even a /19 were the largest ... until the US DoD got the equivalent of a /13. Quick looks: https://www.sixxs.net/tools/grh/dfp/ http://www.nanog.org/mailinglist/mailarchives/old_archive/2008-05/msg00276.html Many lir / provider assignments are shorter than a 32 you see them in bgp... http://bgp.he.net/AS701#_prefixes6 http://bgp.he.net/AS7922#_prefixes6 http://bgp.he.net/AS1299#_prefixes6 /TJ signature.asc Description: OpenPGP digital signature
Re: IPv6 Default Allocation - What size allocation are you giving out
Nanites, window blinds, and soda cans, I can believe. Molecules, I tend to doubt. I think we will see larger network segments, but I think we will also see greater separation of networks into segments along various administrative and/or automatic aggregation boundaries. The virtual topologies you describe will likely also have related prefix consequences. Owen On Oct 9, 2014, at 7:39 AM, Roland Dobbins rdobb...@arbor.net wrote: On Oct 9, 2014, at 2:15 PM, Owen DeLong o...@delong.com wrote: Also, claiming that 90% will never have more than 2 or 3 subnets simply displays a complete lack of imagination. On the contrary, I believe that the increase in the potential address pool size will lead to much flatter, less hierarchical networks - while at the same time leading to most nodes being highly multi-homed into various virtual topologies, thereby leading to significant increases of addresses per node. A 'node' being things like molecules, nanites, window blinds, soda cans, etc. -- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Equo ne credite, Teucri. -- Laocoön
Re: IPv6 Default Allocation - What size allocation are you giving out
It’s entirely likely that someone attempted to get a /31 from ARIN recently and they most definitely would have been smacked down, but not because they couldn’t get more than a /32. ARIN will not issue a /31 under current policy, but if you need more than ~48,000 end-sites, you easily qualify for a /28. Owen On Oct 9, 2014, at 7:47 AM, Karl Auer ka...@biplane.com.au wrote: On Thu, 2014-10-09 at 10:22 -0400, Daniel Corbe wrote: Has anyone successfully gotten a RIR to assign anything bigger than a /32? I seem to recall in recent history someone tried to obtain a /31 through ARIN and got smacked down. Legend has it that the US DOD applied for a /8 - and got smacked down :-) Even if you're assigning a /56 to every end user, that's still on the order of 16 million allocations. If, as you should be, you are assigning /48s, it's only 65536. Not that big. That's why it's the *minimum* allocation. Larger allocations are possible and I suspect quite common. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 Old fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A
Re: IPv6 Default Allocation - What size allocation are you giving out
On Oct 9, 2014, at 11:31 PM, Owen DeLong o...@delong.com wrote: Nanites, window blinds, and soda cans, I can believe. Molecules, I tend to doubt. Various controlled compounds have been chemically tagged for years. NFC or something similar is the logical next step (it also holds a lot of promise and implications for supply-chains in general, physical security applications, transportation, etc.). I think we will see larger network segments, but I think we will also see greater separation of networks into segments along various administrative and/or automatic aggregation boundaries. The virtual topologies you describe will likely also have related prefix consequences. Concur, but my guess is that they will be essentially superimposed, without any increase in hierarchy - in fact, quite the opposite. -- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Equo ne credite, Teucri. -- Laocoön
Re: IPv6 Default Allocation - What size allocation are you giving out
Question: Should we be asking ARIN for another /32 so that each network has it's own /32 or should be break out the /32 into /36 and use these in each of the geographies ? Depends on your needs… Either is a viable solution, depending on your circumstances. ARIN has an MDN policy which would facilitate your acquisition of a second /32. Thank you Owen, just got off the phone with ARIN, it should be a fairly simple process for us, and we will follow the advice of using a /32 for each geographical location. The overall discussion has been a very interesting one, and it would appear that the majority of the forward looking opinion is to allocate /48 to customers, and don't do any smaller subnet allocation. We will take this advice and re-evaluate our policies. Regards. Faisal Imtiaz Snappy Internet Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net - Original Message - From: Owen DeLong o...@delong.com To: Faisal Imtiaz fai...@snappytelecom.net Cc: William Herrin b...@herrin.us, nanog@nanog.org Sent: Thursday, October 9, 2014 12:20:14 PM Subject: Re: IPv6 Default Allocation - What size allocation are you giving out On Oct 9, 2014, at 7:31 AM, Faisal Imtiaz fai...@snappytelecom.net wrote: Selection of a default prefix is easy. Here are the steps. 4. Keeping in mind 4.1 Prefixes longer than somewhere around /48 to /56 may be excluded from the global routing table 4.1a Prefix cutouts of any size (including /48) from inside your /32 or larger block may be excluded from the global routing table. Folks who are multihomed and thus need to advertise their own block with BGP should be referred to ARIN for a direct assignment. Folks who aren't multihomed, well, until given evidence otherwise I claim there are no single-homed entities who will use 65,000 LANs, let alone more. = This brings up another interesting question... We operate Two separate networks in two geographical locations (Two ASN), we have a single /32 allocation from ARIN. Question: Should we be asking ARIN for another /32 so that each network has it's own /32 or should be break out the /32 into /36 and use these in each of the geographies ? Depends on your needs… Either is a viable solution, depending on your circumstances. ARIN has an MDN policy which would facilitate your acquisition of a second /32. Owen
another cogent oddity
you may remember me from the weird cogent route retention / loop
problem i brought up last week. it remains unsolved by cogent to date.
also remembering i'm a relatively new cogent customer, i recently
noticed some packets floating into my network that had cos and ipp
markings on them. i figured i'd try to find where they were coming
from, so i crafted up something like this and placed it inbound on my
two transits (cogent and xo), excluding network control markings.
from {
dscp [ af11 af12 af13 af21 af22 af23 af31 af32 af33 af41 af42
af43 cs1 cs2 cs3 cs4 cs5 ef ];
precedence [ 1 2 3 4 5 ];
}
all of it is coming in from cogent:
COGENT-NOT-BE - 4217788987
XO-NOT-BE - 0
i shifted all traffic to XO just to make sure. the XO counter doesn't budge.
seems like one transit is remarking everything to best effort before
sending to me (which is preferred), and the other is not.
am i odd to think that this is... odd?
i also get a remarkable amount of hits against these destinations
coming in on the cogent side, whereas i get none on the XO side.
show policy-options prefix-list PUBLIC-BAD-NETS
10.0.0.0/8;
169.254.0.0/16;
172.16.0.0/12;
192.168.0.0/16;
224.0.0.0/4;
ryan
Re: IPv6 Default Allocation - What size allocation are you giving out
Sixty replies and no one linked to the BCOP? Is there a reason we are ignoring it? http://bcop.nanog.org/index.php/IPv6_Subnetting Speaking for myself, I did review that doc, and had some confusion about allocating /64 to Resi-Subscribers. However the broader discussion seems to evolved into a /48 vs /56 discussion, and looks like there is a decent compelling case being made for /48 and not to bother with /56's ... :) Faisal Imtiaz Snappy Internet Telecom - Original Message - From: Richard Hicks richard.hi...@gmail.com To: nanog@nanog.org Sent: Thursday, October 9, 2014 12:29:21 PM Subject: Re: IPv6 Default Allocation - What size allocation are you giving out Sixty replies and no one linked to the BCOP? Is there a reason we are ignoring it? http://bcop.nanog.org/index.php/IPv6_Subnetting As we recently discovered ARIN is handing out IPv6 allocations on nibble boundaries. Either a /32 or /28 for service providers. A justification and utilization plan is need to get a /28. It is also double the cost per year. On Thu, Oct 9, 2014 at 9:01 AM, Owen DeLong o...@delong.com wrote: On Oct 9, 2014, at 7:22 AM, Daniel Corbe co...@corbe.net wrote: Mark Andrews ma...@isc.org writes: In message 54366ab9.3040...@gmail.com, Paige Thompson writes: makes more sense to hand out /48s imho. theres only a mere 65k /48s per /32 (or something like that), though. A /32 is the minimum allocation to a ISP. If you have more customers or will have more customers request a bigger block from the RIRs. Mark Has anyone successfully gotten a RIR to assign anything bigger than a /32? I seem to recall in recent history someone tried to obtain a /31 through ARIN and got smacked down. I think I answered this before you asked it, but yes,easily on multiple occasions. The largest two allocations I have worked on were /24s, but I’m sure those are not ARIN’s largest allocations. Even if you're assigning a /56 to every end user, that's still on the order of 16 million allocations. I can't imagine anyone but the truly behemoth access network operators being able to justify a larger allocation with a straight face. You should, however, be assigning a /48 to every end user and that’s only 65,536 allocations. Further, you want to be able to aggregate at least one level in your network, so you may not be able to get anything close to 100% efficiency in that distribution. ARIN policy, for example, defines what is known as a Provider Allocation Unit (PAU). Your PAU is the smallest allocation you give to your customers, so if you’re giving out /64s, then your PAU becomes /64. If you’re giving out /56s, then your PAU is /56. As such, you’re better off to give /48s to everyone because that sets your PAU at /48. All of your utilization is measured in terms of PAUs. You then pick an aggregation level in your network to use as your “serving center” definition. It could be the POP, or some higher level of aggregation containing multiple POPs. Look at the number of end sites served by the largest of those “serving centers” and round that up to a power of 16 (a nibble boundary, e.g. 16, 256, 4096, 65536) such that the number of end sites is not more than 75% of the chosen poser of 16. Then take the number of “serving centers” you expect to have in ~5 years (though the exact forward looking time is not actually specified in policy) and round that up to a nibble boundary as well. That is the size of allocation you can get from ARIN. So, for example, if you have 800,000 end-sites served from your largest POP and you have 400 POPs, then, 800,000 would be rounded up to 16,777,216 (24 bits) and your 400 POPs would be rounded up to 4096 (12 bits) so you would end up needing 36 bits. If your PAU is /48, you would apply for and receive a /12. Obviously this is an unusually large example. At a more realistic large ISP scale, let’s say you’ve got 5,000,000 subscribers in your largest serving center, but only 25 serving centers. This would, again, round up to 16,777,216 (24 bits) subscribers per serving center. But your 25 serving centers would round up to 256 (8 bits). That’s 32 bits, so instead of a /12, you’d get a /16. I hope that clarifies things for people. Owen
RE: another cogent oddity
cogent is well known not to filter in any useful way... in terms of sources
that should not be there, we see the same thing (or did the last time I looked).
John van Oppen
Spectrum Networks
Direct: 206-973-8302
Main: 206-973-8300
From: NANOG [nanog-bounces+jvanoppen=spectrumnet...@nanog.org] on behalf of
ryanL [ryan.lan...@gmail.com]
Sent: Thursday, October 09, 2014 10:35 AM
To: North American Network Operators Group
Subject: another cogent oddity
you may remember me from the weird cogent route retention / loop
problem i brought up last week. it remains unsolved by cogent to date.
also remembering i'm a relatively new cogent customer, i recently
noticed some packets floating into my network that had cos and ipp
markings on them. i figured i'd try to find where they were coming
from, so i crafted up something like this and placed it inbound on my
two transits (cogent and xo), excluding network control markings.
from {
dscp [ af11 af12 af13 af21 af22 af23 af31 af32 af33 af41 af42
af43 cs1 cs2 cs3 cs4 cs5 ef ];
precedence [ 1 2 3 4 5 ];
}
all of it is coming in from cogent:
COGENT-NOT-BE - 4217788987
XO-NOT-BE - 0
i shifted all traffic to XO just to make sure. the XO counter doesn't budge.
seems like one transit is remarking everything to best effort before
sending to me (which is preferred), and the other is not.
am i odd to think that this is... odd?
i also get a remarkable amount of hits against these destinations
coming in on the cogent side, whereas i get none on the XO side.
show policy-options prefix-list PUBLIC-BAD-NETS
10.0.0.0/8;
169.254.0.0/16;
172.16.0.0/12;
192.168.0.0/16;
224.0.0.0/4;
ryan
Re: IPv6 Default Allocation - What size allocation are you giving out
On Thu, Oct 9, 2014 at 12:29 PM, Richard Hicks richard.hi...@gmail.com wrote: Sixty replies and no one linked to the BCOP? Is there a reason we are ignoring it? Hi Richard, It's dated (a *lot* about IPv6 has changed since 2011) and a we've learned enough to know some of the things in there are dubious. For example: Regardless of the number of hosts on an individual LAN or WAN segment, every multi-access network (non-point-to-point) requires at least one /64 prefix. But using /64s on WAN links invites needless problems with neighbor discovery when an attacker decides to send one ping each to half a million adresses all of which happen to land on that WAN link. WAN links should really use something whose size is much closer to the number of routers on the link, in the same order of magnitude anyway. So /64s for LANs, sure, but size the WAN links small to make them less vulnerable to attack. And: Only subnet on nibble boundaries is not reasonable. When I need two LANs in a building I should burn 14 more to get to a nibble boundary? Really? Only delegate on nibble boundaries is a more reasonable statement. When you assign addresses to your customer or to a different internal team's control, THAT should be on a nibble boundary for the customer's convenience understanding the written-down version of what network is theirs and for your convenience when it comes time to delegate reverse DNS. Inside your network under control of the same engineers, subnet and route just as you would with IPv4. Regards, Bill Herrin -- William Herrin her...@dirtside.com b...@herrin.us Owner, Dirtside Systems . Web: http://www.dirtside.com/ May I solve your unusual networking challenges?
Re: IPv6 Default Allocation - What size allocation are you giving out
On Oct 9, 2014, at 8:45 AM, TJ trej...@gmail.com wrote: On Thu, 2014-10-09 at 10:22 -0400, Daniel Corbe wrote: Has anyone successfully gotten a RIR to assign anything bigger than a /32? I seem to recall in recent history someone tried to obtain a /31 through ARIN and got smacked down. Yes; ISTR several /20s and even a /19 were the largest ... until the US DoD got the equivalent of a /13. Quick looks: https://www.sixxs.net/tools/grh/dfp/ http://www.nanog.org/mailinglist/mailarchives/old_archive/2008-05/msg00276.html /TJ What DoD actually got as AIUI was a slew of allocations throughout a /13, but not an actual /13. Owen
Re: another cogent oddity
On 10/9/14 10:35 AM, ryanL wrote:
you may remember me from the weird cogent route retention / loop
problem i brought up last week. it remains unsolved by cogent to date.
also remembering i'm a relatively new cogent customer, i recently
noticed some packets floating into my network that had cos and ipp
markings on them. i figured i'd try to find where they were coming
from, so i crafted up something like this and placed it inbound on my
two transits (cogent and xo), excluding network control markings.
from {
dscp [ af11 af12 af13 af21 af22 af23 af31 af32 af33 af41 af42
af43 cs1 cs2 cs3 cs4 cs5 ef ];
precedence [ 1 2 3 4 5 ];
}
all of it is coming in from cogent:
COGENT-NOT-BE - 4217788987
XO-NOT-BE - 0
i shifted all traffic to XO just to make sure. the XO counter doesn't budge.
seems like one transit is remarking everything to best effort before
sending to me (which is preferred), and the other is not.
am i odd to think that this is... odd?
It's not that uncommon, but it's one of the reasons to sanitize on
ingress if you don't want to see that (and absolutely if you're reusing
them).
i also get a remarkable amount of hits against these destinations
coming in on the cogent side, whereas i get none on the XO side.
show policy-options prefix-list PUBLIC-BAD-NETS
10.0.0.0/8;
169.254.0.0/16;
172.16.0.0/12;
192.168.0.0/16;
224.0.0.0/4;
you can add
100.64.0.0/10 to that list. ;)
ryan
signature.asc
Description: OpenPGP digital signature
Re: IPv6 Default Allocation - What size allocation are you giving out
On Thu, Oct 9, 2014 at 10:40 AM, William Herrin b...@herrin.us wrote: On Thu, Oct 9, 2014 at 12:29 PM, Richard Hicks richard.hi...@gmail.com wrote: Sixty replies and no one linked to the BCOP? Is there a reason we are ignoring it? Hi Richard, It's dated (a *lot* about IPv6 has changed since 2011) and a we've learned enough to know some of the things in there are dubious. For example: Regardless of the number of hosts on an individual LAN or WAN segment, every multi-access network (non-point-to-point) requires at least one /64 prefix. But using /64s on WAN links invites needless problems with neighbor discovery when an attacker decides to send one ping each to half a million adresses all of which happen to land on that WAN link. WAN links should really use something whose size is much closer to the number of routers on the link, in the same order of magnitude anyway. So /64s for LANs, sure, but size the WAN links small to make them less vulnerable to attack. The BCOP specfically addresses this in 4b: *b. Point-to-point links should be allocated a /64 and configured with a /126 or /127* And: Only subnet on nibble boundaries is not reasonable. When I need two LANs in a building I should burn 14 more to get to a nibble boundary? Really? Only delegate on nibble boundaries is a more reasonable statement. When you assign addresses to your customer or to a different internal team's control, THAT should be on a nibble boundary for the customer's convenience understanding the written-down version of what network is theirs and for your convenience when it comes time to delegate reverse DNS. Inside your network under control of the same engineers, subnet and route just as you would with IPv4. Regards, Bill Herrin -- William Herrin her...@dirtside.com b...@herrin.us Owner, Dirtside Systems . Web: http://www.dirtside.com/ May I solve your unusual networking challenges?
Re: IPv6 Default Allocation - What size allocation are you giving out
On Thu, Oct 9, 2014 at 1:55 PM, Richard Hicks richard.hi...@gmail.com wrote: On Thu, Oct 9, 2014 at 10:40 AM, William Herrin b...@herrin.us wrote: Regardless of the number of hosts on an individual LAN or WAN segment, every multi-access network (non-point-to-point) requires at least one /64 prefix. But using /64s on WAN links invites needless problems with neighbor discovery when an attacker decides to send one ping each to half a million adresses all of which happen to land on that WAN link. The BCOP specfically addresses this in 4b: b. Point-to-point links should be allocated a /64 and configured with a /126 or /127 It says, effectively, that a WAN link involving 3 or 4 routers (a common redundancy design) should use a /64. I think that's nuts. It creates a needlessly wide attack surface. Use a /124 for that. And if our subnets should be on nibble boundaries, /126 and /127 on ptp links aren't so wise either. Use a /124 for that too. -Bill -- William Herrin her...@dirtside.com b...@herrin.us Owner, Dirtside Systems . Web: http://www.dirtside.com/ May I solve your unusual networking challenges?
Re: another cogent oddity
i retract the blurb about the bad destinations coming in from cogent, as that obviously doesn't make a lot of sense. the spoofed traffic is actually arriving on my connection into an ix fabric. thx to john frazier for tickling my brain on that one. the upped markings, however, are definitely coming in from cogent.
Re: IPv6 Default Allocation - What size allocation are you giving out
On Oct 9, 2014, at 10:04 AM, Roland Dobbins rdobb...@arbor.net wrote: On Oct 9, 2014, at 11:31 PM, Owen DeLong o...@delong.com wrote: Nanites, window blinds, and soda cans, I can believe. Molecules, I tend to doubt. Various controlled compounds have been chemically tagged for years. NFC or something similar is the logical next step (it also holds a lot of promise and implications for supply-chains in general, physical security applications, transportation, etc.). But those chemical tags are generally multiple, not single molecules. NFC still requires something with a unique radiographic property, so not likely in a single molecule. I think we will see larger network segments, but I think we will also see greater separation of networks into segments along various administrative and/or automatic aggregation boundaries. The virtual topologies you describe will likely also have related prefix consequences. Concur, but my guess is that they will be essentially superimposed, without any increase in hierarchy - in fact, quite the opposite. Indeed, I think we will end up agreeing to disagree about this, but it will be interesting to see what happens over years to come. I suspect that the answer to which way this goes will be somewhat context sensitive. In some cases, hierarchies will be collapsed. In others, they will expand. Owen
Re: IPv6 Default Allocation - What size allocation are you giving out
On 9 October 2014 19:55, Richard Hicks richard.hi...@gmail.com wrote: The BCOP specfically addresses this in 4b: *b. Point-to-point links should be allocated a /64 and configured with a /126 or /127* Why do people assign addresses to point-to-point links at all? You can just use a host /128 route to the loopback address of the peer. Saves you the hassle of coming up with new addresses for every link. Same trick works for IPv4 too. Regards, Baldur
Re: Marriott wifi blocking
On Oct 5, 2014, at 4:13 PM, Brett Frankenberger rbf+na...@panix.com wrote: On Sat, Oct 04, 2014 at 11:19:57PM -0700, Owen DeLong wrote: There's a lot of amateur lawyering ogain on in this thread, in an area where there's a lot of ambiguity. We don't even know for sure that what Marriott did is illegal -- all we know is that the FCC asserted it was and Mariott decided to settle rather than litigate the matter. And that was an extreme case -- Marriott was making transmissions for the *sole purpose of preventing others from using the spectrum*. I don't see a lot of ambiguity in a plain text reading of part 15. Could you please read part 15 and tell me what you think is ambiguous? Marriott was actually accused of violating 47 USC 333: No person shall willfully or maliciously interfere with or cause interference to any radio communications of any station licensed or authorized by or under this chapter or operated by the United States Government. In cases like the Marriott case, where the sole purpose of the transmission is to interfere with other usage of the transmission, there's not much ambiguity. But other cases aren't clear from the text. For example, you've asserted that if I've been using ABCD as my SSID for two years, and then I move, and my new neighbor is already using that, that I have to change. But that if, instead of duplicating my new neighbor's pre-existing SSID, I operate with a different SSID but on the same channel, I don't have to change. I'm not saying your position is wrong, but it's certainly not clear from the text above that that's where the line is. That's what I meant by ambiguity. True, but if you read the rest of Part 15, you’ll also find these gems: (From http://www.ecfr.gov/cgi-bin/text-idx?node=47:1.0.1.1.16) §15.3 Definitions. ... (m) Harmful interference. Any emission, radiation or induction that endangers the functioning of a radio navigation service or of other safety services or seriously degrades, obstructs or repeatedly interrupts a radiocommunications service operating in accordance with this chapter. §15.5 General conditions of operation. (a) Persons operating intentional or unintentional radiators shall not be deemed to have any vested or recognizable right to continued use of any given frequency by virtue of prior registration or certification of equipment, or, for power line carrier systems, on the basis of prior notification of use pursuant to §90.35(g) of this chapter. (b) Operation of an intentional, unintentional, or incidental radiator is subject to the conditions that no harmful interference is caused and that interference must be accepted that may be caused by the operation of an authorized radio station, by another intentional or unintentional radiator, by industrial, scientific and medical (ISM) equipment, or by an incidental radiator. (c) The operator of a radio frequency device shall be required to cease operating the device upon notification by a Commission representative that the device is causing harmful interference. Operation shall not resume until the condition causing the harmful interference has been corrected. (d) Intentional radiators that produce Class B emissions (damped wave) are prohibited. [54 FR 17714, Apr. 25, 1989, as amended at 75 FR 63031, Oct. 13, 2010] It seems to me that if you deploy something new in such a way that it causes harmful interference to an operating service, you’ve run afoul of 15.5 as defined in 15.3. (What's your position on a case where someone puts up, say, a continuous carrier point-to-point system on the same channel as an existing WiFi system that is now rendered useless by the p-to-p system that won't share the spectrum? Illegal or Legal? And do you think the text above is unambiguous on that point?) -- Brett
Re: IPv6 Default Allocation - What size allocation are you giving out
On Thu, Oct 9, 2014 at 2:34 PM, Baldur Norddahl baldur.nordd...@gmail.com wrote: Why do people assign addresses to point-to-point links at all? It makes remote detection of carrier on the interface as simple as ping -Bill -- William Herrin her...@dirtside.com b...@herrin.us Owner, Dirtside Systems . Web: http://www.dirtside.com/ May I solve your unusual networking challenges?
Re: Marriott wifi blocking
On Sun, Oct 5, 2014 at 7:13 PM, Brett Frankenberger rbf+na...@panix.com wrote: (What's your position on a case where someone puts up, say, a continuous carrier point-to-point system on the same channel as an existing WiFi system that is now rendered useless by the p-to-p system that won't share the spectrum? Illegal or Legal? And do you think the text above is unambiguous on that point?) Not how 802.11 works. Put up another transmitter on a different SSID and it raises the noise floor for everybody. It doesn't render the frequency useless. Remember, we got 2.4ghz in the first place because the huge signal interference from microwave ovens and -rain- had already rendered it useless. Until spread spectrum came along. Regards, Bill Herrin -- William Herrin her...@dirtside.com b...@herrin.us Owner, Dirtside Systems . Web: http://www.dirtside.com/ May I solve your unusual networking challenges?
Re: Marriott wifi blocking
So is the main factor here in all the FCC verbage become that the WiFi spectrum is NOT a licensed band and therefore does not fall under the interference regulations unless they are interfering with a licensed band? I think the first sentence below says a lot to that. The basic premise of all Part 15 unlicensed operation is that unlicensed devices cannot cause interference to licensed operations nor are they protected from any interference received. The operational parameters for unlicensed operation are set forth in Section 15.5 of the rules, as follows: (a) Persons operating intentional or unintentional radiators shall not be deemed to have any vested or recognizable right to continued use of any given frequency by virtue of prior registration or certification of equipment, (b) Operation of an intentional, unintentional, or incidental radiator is subject to the conditions that no harmful interference is caused and that interference must be accepted that may be caused by the operation of an authorized radio station, by another intentional or unintentional radiator, by industrial, scientific and medical (ISM) equipment, or by an incidental radiator. (c) The operator of a radio frequency device shall be required to cease operating the device upon notification by a Commission representative that the device is causing harmful interference. Operation shall not resume until the condition causing the harmful interference has been corrected. http://transition.fcc.gov/sptf/files/EUWGFinalReport.doc On Thu, 9 Oct 2014 11:34:40 -0700 Owen DeLong o...@delong.com wrote: On Oct 5, 2014, at 4:13 PM, Brett Frankenberger rbf+na...@panix.com wrote: On Sat, Oct 04, 2014 at 11:19:57PM -0700, Owen DeLong wrote: There's a lot of amateur lawyering ogain on in this thread, in an area where there's a lot of ambiguity. We don't even know for sure that what Marriott did is illegal -- all we know is that the FCC asserted it was and Mariott decided to settle rather than litigate the matter. And that was an extreme case -- Marriott was making transmissions for the *sole purpose of preventing others from using the spectrum*. I don't see a lot of ambiguity in a plain text reading of part 15. Could you please read part 15 and tell me what you think is ambiguous? Marriott was actually accused of violating 47 USC 333: No person shall willfully or maliciously interfere with or cause interference to any radio communications of any station licensed or authorized by or under this chapter or operated by the United States Government. In cases like the Marriott case, where the sole purpose of the transmission is to interfere with other usage of the transmission, there's not much ambiguity. But other cases aren't clear from the text. For example, you've asserted that if I've been using ABCD as my SSID for two years, and then I move, and my new neighbor is already using that, that I have to change. But that if, instead of duplicating my new neighbor's pre-existing SSID, I operate with a different SSID but on the same channel, I don't have to change. I'm not saying your position is wrong, but it's certainly not clear from the text above that that's where the line is. That's what I meant by ambiguity. True, but if you read the rest of Part 15, you’ll also find these gems: (From http://www.ecfr.gov/cgi-bin/text-idx?node=47:1.0.1.1.16) §15.3 Definitions. ... (m) Harmful interference. Any emission, radiation or induction that endangers the functioning of a radio navigation service or of other safety services or seriously degrades, obstructs or repeatedly interrupts a radiocommunications service operating in accordance with this chapter. §15.5 General conditions of operation. (a) Persons operating intentional or unintentional radiators shall not be deemed to have any vested or recognizable right to continued use of any given frequency by virtue of prior registration or certification of equipment, or, for power line carrier systems, on the basis of prior notification of use pursuant to §90.35(g) of this chapter. (b) Operation of an intentional, unintentional, or incidental radiator is subject to the conditions that no harmful interference is caused and that interference must be accepted that may be caused by the operation of an authorized radio station, by another intentional or unintentional radiator, by industrial, scientific and medical (ISM) equipment, or by an incidental radiator. (c) The operator of a radio frequency device shall be required to cease operating the device upon notification by a Commission representative that the device is causing harmful interference. Operation shall not resume until the condition causing the harmful interference has been corrected. (d) Intentional radiators that produce Class B emissions (damped wave) are prohibited. [54 FR 17714, Apr. 25, 1989, as amended at 75 FR 63031, Oct. 13, 2010] It seems to me
RE: Marriott wifi blocking
I don't read it that way at all. It is illegal to intentionally interfere (meaning intending to prevent others from effectively using the resource) with any licensed or unlicensed frequency. That is long standing law. It says in (b) that you must accept interference caused by operation of an AUTHORIZED station or intentional or unintentional radiator (like a microwave oven which serves a purpose, or a amateur radio operator messing up your TV once in awhile (as long as he is operating within his license), not a jammer that has no purpose other than to prevent others from using an authorized spectrum). To me that looks like as long as the other guy is using the frequency band in an authorized manner (i.e. not purposely stopping others from using it, but using it for their own authorized purpose) you have to deal with it. So another guy using your channel (which is not really yours) for his network would be fine but if he is purposely camped on your SSID and deauthing your clients is not using it legally. As far as who owns an SSID, I don't think there is any law on that unless it is a trademarked name but the FCC rules in general give the incumbent user the right of way. If two licensed systems interfere with each other (common in licensed microwave), the older system usually gets to stay and the new system has to change. I think they would be unlikely to get involved in the whole SSID dispute (because they don't regulate SSIDs or the 802.11 standards) they would most likely tell you it's a civil matter and walk away. Now, if you are using someone else's SSID for the purpose of intruding, you are violating Part 15 because that is not authorized spectrum usage. That they will probably address. I don't think the FCC would classify a wifi router operating normally as interference, but a device purposely bouncing clients off of the clients own network would be. I have worked with them a lot as a frequency coordinator with the Air Force and find that the enforcement guys have quite a bit of common sense and apply a good measure of it to deciding what to enforce or not enforce. My guess (you would have to ask them) is that an entity defending their SSID from unauthorized access is an acceptable security feature but someone using a different SSID and not trying to connect to the entities network should not be active messed with. If my SSID is there first and you show up and try to kick my clients off so you can use it, you will appear to be the aggressor and I will appear to be the defender. In the same way that it is not legal for me to punch you in the face unless of course you punched me in the face first and I'm defending myself. It gets messy when you get into the cellular world. I don't think you would be within the law jamming or blocking cell phones even within your building (even though the government is known to do so). You could however have a policy that prevents people from bringing a cell phone into your building. The public has no right of access to your property so you are free to make rules about what can and can't come within your building. I do know that the areas I have worked in that had cellular jammers for security purposes are already areas where they are prohibited by regulation. National security trumps a lot of other laws. Remember, a lot of law is about intent and it is clear that the intent of this law is to allow everyone access to use the ISM spectrum for useful purposes and to prevent people from interfering with your right to do so. Any case has to take that into account. In the Marriott case, I think it would be a tough argument for them to show anything other than stopping people from using anything other than their wifi service when it is clear that someone could use their own network services without causing undue harm to Marriott. In my own environment, there are tons of clients running around with their devices wifi tethered to phones and searching for their home wifi networks. As long as they stay off my SSIDs, they will not be harmed. If they try to connect to my SSID they better authenticate or they get denied. If they keep trying, they will get ACL'd out. If you set up an AP and try to plug it into my wired infrastructure that's when the active stuff comes into effect because you have no right to add a device to my wired network. Steve Naslund Chicago IL -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Robert Webb Sent: Thursday, October 09, 2014 2:05 PM To: Owen DeLong; Brett Frankenberger Cc: nanog@nanog.org; Brandon Ross Subject: Re: Marriott wifi blocking So is the main factor here in all the FCC verbage become that the WiFi spectrum is NOT a licensed band and therefore does not fall under the interference regulations unless they are interfering with a licensed band? I think the first sentence below says a lot to that. The basic premise of
Re: IPv6 Default Allocation - What size allocation are you giving out
On Oct 9, 2014, at 11:34 AM, Baldur Norddahl baldur.nordd...@gmail.com wrote: On 9 October 2014 19:55, Richard Hicks richard.hi...@gmail.com wrote: The BCOP specfically addresses this in 4b: *b. Point-to-point links should be allocated a /64 and configured with a /126 or /127* Why do people assign addresses to point-to-point links at all? You can just use a host /128 route to the loopback address of the peer. Saves you the hassle of coming up with new addresses for every link. Same trick works for IPv4 too. Regards, Baldur SARCASM And it makes your trace-routes across parallel links oh so easy to identify which of them is at fault for the packet loss, too. /SARCASM There are a number of good technical reasons to want distinct addresses on point to point links. Owen
Re: IPv6 Default Allocation - What size allocation are you giving out
On 9 October 2014 22:01, Owen DeLong o...@delong.com wrote: Why do people assign addresses to point-to-point links at all? You can just use a host /128 route to the loopback address of the peer. Saves you the hassle of coming up with new addresses for every link. Same trick works for IPv4 too. Regards, Baldur SARCASM And it makes your trace-routes across parallel links oh so easy to identify which of them is at fault for the packet loss, too. /SARCASM There are a ton of other technologies with the same problem. Do you never use link aggregation? My parallel links are all link aggregations, so I would not have a way to identify links by traceroute anyway. There are a number of good technical reasons to want distinct addresses on point to point links. I am sure there are. Tell me about them. I am not disputing that there are many reasons to sometimes use link addresses. My question is why do you do it by default? So far we have heard two arguments: 1) You can ping the link address. I assume his equipment will down the address if the link is down. My equipment does not do this, I can ping it as long it is administrative up no matter link status. So this test is useless to me. I am monitoring links by SNMP anyway. 2) Parallel links. I don't have many of those, and the ones I have are link aggregations. MPLS interferes with this too. On the other hand not using link addresses has some advantages: 1) You don't need to assign and document them. 2) It is easy to think about: Router A talks to Router B on link AB. Every router has only one address so you don't need to remember which address to use. 3) You avoid having a lot of addresses configured on your router. 4) You are immune to all the NDP attacks. 5) You are immune to the monthly NANOG debate about using /127 vs /126 vs /124 vs /64. The correct answer is clearly use /128 :-). Regards, Baldur
Re: Marriott wifi blocking
On Oct 9, 2014, at 12:41 PM, Naslund, Steve snasl...@medline.com wrote:
I don't read it that way at all. It is illegal to intentionally interfere
(meaning intending to prevent others from effectively using the resource)
with any licensed or unlicensed frequency. That is long standing law.
Indeed… this is 47CFR333. It’s not limited to Part 15 (47CFR15).
It says in (b) that you must accept interference caused by operation of an
AUTHORIZED station or intentional or unintentional radiator (like a microwave
oven which serves a purpose, or a amateur radio operator messing up your TV
once in awhile (as long as he is operating within his license), not a jammer
that has no purpose other than to prevent others from using an authorized
spectrum). To me that looks like as long as the other guy is using the
frequency band in an authorized manner (i.e. not purposely stopping others
from using it, but using it for their own authorized purpose) you have to
deal with it. So another guy using your channel (which is not really
yours) for his network would be fine but if he is purposely camped on your
SSID and deauthing your clients is not using it legally.
Now you’re talking about 47CFR15 (Part 15) and more specifically about 15.5(b).
Otherwise, yes, you are exactly right.
As far as who owns an SSID, I don't think there is any law on that unless it
is a trademarked name but the FCC rules in general give the incumbent user
the right of way. If two licensed systems interfere with each other (common
in licensed microwave), the older system usually gets to stay and the new
system has to change. I think they would be unlikely to get involved in the
whole SSID dispute (because they don't regulate SSIDs or the 802.11
standards) they would most likely tell you it's a civil matter and walk away.
Now, if you are using someone else's SSID for the purpose of intruding, you
are violating Part 15 because that is not authorized spectrum usage. That
they will probably address.
I don’t believe that there is any such thing as “Owning an SSID”. One might be
able to try and claim that ownership of a *mark (where * = one or more of
{trade,service,etc.}) extends to use of that name in an SSID, but generally
speaking, I think the most likely outcome would be to treat an SSID as an
address and declare that addresses are not subject to those limitations.
I don't think the FCC would classify a wifi router operating normally as
interference, but a device purposely bouncing clients off of the clients own
network would be. I have worked with them a lot as a frequency coordinator
with the Air Force and find that the enforcement guys have quite a bit of
common sense and apply a good measure of it to deciding what to enforce or
not enforce. My guess (you would have to ask them) is that an entity
defending their SSID from unauthorized access is an acceptable security
feature but someone using a different SSID and not trying to connect to the
entities network should not be active messed with. If my SSID is there first
and you show up and try to kick my clients off so you can use it, you will
appear to be the aggressor and I will appear to be the defender. In the same
way that it is not legal for me to punch you in the face unless of course you
punched me in the face first and I'm defending myself.
I think the FCC would, likely, classify two neighbors in adjacent apartments
arguing over the same SSID and unwilling to move either one of them would
likely both get told to cease and desist until they picked different SSIDs,
though it’s hard for me to believe that this would get elevated to the FCC very
often. More often one person or the other will change their SSID and move on.
It gets messy when you get into the cellular world. I don't think you would
be within the law jamming or blocking cell phones even within your building
(even though the government is known to do so). You could however have a
policy that prevents people from bringing a cell phone into your building.
The public has no right of access to your property so you are free to make
rules about what can and can't come within your building. I do know that the
areas I have worked in that had cellular jammers for security purposes are
already areas where they are prohibited by regulation. National security
trumps a lot of other laws.
In fact, movie theaters tried this briefly and got a pretty strong smack from
the FCC as a result.
http://www.fcc.gov/encyclopedia/cell-phone-and-gps-jamming
However, that’s not what was being discussed in the BART example. In this case,
repeaters with unclear ownership operated by cellular providers were shut down
by BART authorities to try and disrupt a protest. That’s not active jamming, so
most likely, not an FCC issue. There are other areas of concern, however, such
as 1st amendment violations, abuse of authority, potential civil
Re: IPv6 Default Allocation - What size allocation are you giving out
On Oct 10, 2014, at 3:25 AM, Baldur Norddahl baldur.nordd...@gmail.com wrote: I am sure there are. Tell me about them. This issue has been discussed on all the various operational lists many, many times over the years. http://tools.ietf.org/html/rfc6752 -- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Equo ne credite, Teucri. -- Laocoön
Re: IPv6 Default Allocation - What size allocation are you giving out
On Oct 9, 2014, at 1:25 PM, Baldur Norddahl baldur.nordd...@gmail.com wrote: On 9 October 2014 22:01, Owen DeLong o...@delong.com wrote: Why do people assign addresses to point-to-point links at all? You can just use a host /128 route to the loopback address of the peer. Saves you the hassle of coming up with new addresses for every link. Same trick works for IPv4 too. Regards, Baldur SARCASM And it makes your trace-routes across parallel links oh so easy to identify which of them is at fault for the packet loss, too. /SARCASM There are a ton of other technologies with the same problem. Do you never use link aggregation? My parallel links are all link aggregations, so I would not have a way to identify links by traceroute anyway. Your design problems don’t have to be mine. Just because you have created that problem through another mechanism doesn’t pose a reason anyone else should accept the same problem in a different circumstance. There are a number of good technical reasons to want distinct addresses on point to point links. I am sure there are. Tell me about them. I gave you one. You decided to dismiss it on the basis of “it wouldn’t help me anyway because I use this other thing that is broken that way regardless.” Some others (not a conclusive list by any means): Having public addresses in trace-routes, ideally with good reverse DNS is actually useful. Clarity is almost always an advantage over obscurity when one is troubleshooting something. Being able to ping the link address is useful for troubleshooting. Being able to source packets from a particular link address can be useful for troubleshooting. I am not disputing that there are many reasons to sometimes use link addresses. My question is why do you do it by default? So far we have heard two arguments: 1) You can ping the link address. I assume his equipment will down the address if the link is down. My equipment does not do this, I can ping it as long it is administrative up no matter link status. So this test is useless to me. I am monitoring links by SNMP anyway. I can’t help that your equipment is ill-behaved at best. Perhaps you should consider alternatives. I certainly don’t think that designing everyone else’s network to the level of brokenness in your particular environment is particularly valid. 2) Parallel links. I don't have many of those, and the ones I have are link aggregations. MPLS interferes with this too. On the other hand not using link addresses has some advantages: 1) You don't need to assign and document them. Sure you do, it’s just harder. You’re now using essentially an “unnumbered interface” which needs to be documented as such so that people know that when a given loopback shows up, it’s not a unique identifier, but ambiguous across several interfaces. 2) It is easy to think about: Router A talks to Router B on link AB. Every router has only one address so you don't need to remember which address to use. I don’t have to remember which address to use normally. This is not an advantage. I can always use the loopback address to talk to a router if my environment is correctly functioning. If it is not, removing the ambiguity of unnumbered link addresses is more helpful than being able to use one address for each router while unable to know how traffic is actually flowing as a result. 3) You avoid having a lot of addresses configured on your router. I don’t see this as an advantage. For a number of reasons (some of which I have expressed above) it is, in fact, a disadvantage. 4) You are immune to all the NDP attacks. No you aren’t. You just change the nature of those attacks. 5) You are immune to the monthly NANOG debate about using /127 vs /126 vs /124 vs /64. The correct answer is clearly use /128 :-). Except that it’s clearly an incorrect answer, IMHO. Owen
Re: IPv6 Default Allocation - What size allocation are you giving out
On 9 October 2014 22:32, Roland Dobbins rdobb...@arbor.net wrote: On Oct 10, 2014, at 3:25 AM, Baldur Norddahl baldur.nordd...@gmail.com wrote: I am sure there are. Tell me about them. This issue has been discussed on all the various operational lists many, many times over the years. http://tools.ietf.org/html/rfc6752 The linked document talks about issues with using private IP addresses. I am not suggesting that you do that. I am suggesting that you use _no_ IP addresses on the links. Generally the devices will use the loopback IP, which will be public, for your traceroutes and for ICMP. None of the issues in RFC 6752 are applicable to the concept of using host routes to peer loopback address instead of assigning link specific addressing. Regards, Baldur
Re: IPv6 Default Allocation - What size allocation are you giving out
On Thu, Oct 9, 2014 at 4:32 PM, Roland Dobbins rdobb...@arbor.net wrote: On Oct 10, 2014, at 3:25 AM, Baldur Norddahl baldur.nordd...@gmail.com wrote: I am sure there are. Tell me about them. This issue has been discussed on all the various operational lists many, many times over the years. http://tools.ietf.org/html/rfc6752 Hi Roland, 6752 isn't germane; it has to do with using private IP addresses on routers, which borks things up when the router has to generate an ICMP type 3. Baldur want's to know: why not just use one public IP address per router and use it on all interfaces? Baldur, one IP per router can work just as well as one subnet per interface. But there are some gotchas: Your router has one IP. Your customer has a subnet. Do you add an extra deaggregated single IP to your routing table for his router? There are more routers than links, so if you assign subnets to routers instead of links you'll have to carry more routes. If you borrow the customer LAN-side IP for the WAN side you'll get grief when his equipment is one of those that doesn't respond if the LAN-side interface is down (e.g. Cisco). That gets kind of nasty when troubleshooting and remediating problems. And of course the more knowledge you can gather from diagnostic tools like traceroute, the more quickly you can identify the problem when something doesn't work right.. In my own networks... I want to keep as many IPv4 addresses as I can, so my router interfaces borrow their ip from loop0. In IPv6 where I can have a functionally infinite number of /124's I want to put one on each interface and gain the mild extra benefit. Regards, Bill Herrin -- William Herrin her...@dirtside.com b...@herrin.us Owner, Dirtside Systems . Web: http://www.dirtside.com/ May I solve your unusual networking challenges?
Re: IPv6 Default Allocation - What size allocation are you giving out
I am sorry if I stepped on something sore. I am not dismissing any arguments, and I am genuinely interested in any advantages and disadvantages to the approach. There is more than one way to design a network and all I am saying is this far it is working great for me. The two disadvantages put forward so far have not been of any consequences in my network. But I am concerned that you say that I am still vulnerable to NDP attacks. Could you elaborate on that please? About loopback not being an unique identifier, please remember that none of the IP addresses on a host is that. An IP address belongs to the host, not the interface. Creating addresses on interfaces is just an alias for creating the same address as loopback and adding a net route on the interface. Don't believe me? Try it out! I can’t help that your equipment is ill-behaved at best. That is not ill-behaved. It is the correct behavior. Try unplugging the netcable from your computer - you will NOT lose the IP-address unless you have a DHCP daemon that takes it away. Regards, Baldur On 9 October 2014 22:38, Owen DeLong o...@delong.com wrote: On Oct 9, 2014, at 1:25 PM, Baldur Norddahl baldur.nordd...@gmail.com wrote: On 9 October 2014 22:01, Owen DeLong o...@delong.com wrote: Why do people assign addresses to point-to-point links at all? You can just use a host /128 route to the loopback address of the peer. Saves you the hassle of coming up with new addresses for every link. Same trick works for IPv4 too. Regards, Baldur SARCASM And it makes your trace-routes across parallel links oh so easy to identify which of them is at fault for the packet loss, too. /SARCASM There are a ton of other technologies with the same problem. Do you never use link aggregation? My parallel links are all link aggregations, so I would not have a way to identify links by traceroute anyway. Your design problems don’t have to be mine. Just because you have created that problem through another mechanism doesn’t pose a reason anyone else should accept the same problem in a different circumstance. There are a number of good technical reasons to want distinct addresses on point to point links. I am sure there are. Tell me about them. I gave you one. You decided to dismiss it on the basis of “it wouldn’t help me anyway because I use this other thing that is broken that way regardless.” Some others (not a conclusive list by any means): Having public addresses in trace-routes, ideally with good reverse DNS is actually useful. Clarity is almost always an advantage over obscurity when one is troubleshooting something. Being able to ping the link address is useful for troubleshooting. Being able to source packets from a particular link address can be useful for troubleshooting. I am not disputing that there are many reasons to sometimes use link addresses. My question is why do you do it by default? So far we have heard two arguments: 1) You can ping the link address. I assume his equipment will down the address if the link is down. My equipment does not do this, I can ping it as long it is administrative up no matter link status. So this test is useless to me. I am monitoring links by SNMP anyway. I can’t help that your equipment is ill-behaved at best. Perhaps you should consider alternatives. I certainly don’t think that designing everyone else’s network to the level of brokenness in your particular environment is particularly valid. 2) Parallel links. I don't have many of those, and the ones I have are link aggregations. MPLS interferes with this too. On the other hand not using link addresses has some advantages: 1) You don't need to assign and document them. Sure you do, it’s just harder. You’re now using essentially an “unnumbered interface” which needs to be documented as such so that people know that when a given loopback shows up, it’s not a unique identifier, but ambiguous across several interfaces. 2) It is easy to think about: Router A talks to Router B on link AB. Every router has only one address so you don't need to remember which address to use. I don’t have to remember which address to use normally. This is not an advantage. I can always use the loopback address to talk to a router if my environment is correctly functioning. If it is not, removing the ambiguity of unnumbered link addresses is more helpful than being able to use one address for each router while unable to know how traffic is actually flowing as a result. 3) You avoid having a lot of addresses configured on your router. I don’t see this as an advantage. For a number of reasons (some of which I have expressed above) it is, in fact, a disadvantage. 4) You are immune to all the NDP attacks. No you aren’t. You just change the nature of those attacks. 5) You are immune to the monthly NANOG debate
Strategies for migrating lots of customers into L3VPN / route-leaking [x-post from j-nsp]
[apologies for the x-post-- I didn't get any responses from the j-nsp list, so I thought I'd try a larger audience- edited to remove some juniper jargon] Hi all, I'm working on virtualizing a regional network with about 500 customer sites into an L3VPN. All of my customer routes (plus our internet routes) currently exist in the global table on our routers. The end-state I’d like to achieve is to have our provider's Internet routes isolated into a VRF and our customers isolated into their own VRF with vrf-import policies leaking the routes between the two. Before someone asks “why?” I’ll just stop that and say that it’s likely that in the near future I’ll have different customer classes demanding different upstream providers on the same physical gear but still wanting the same path/latency to the other customer classes we provide today. So- I’d like to move our customer routes piecemeal into a VRF in as controlled a way as possible without causing network segmentation or having to constrain traffic through specific paths. That way we could move reasonable sections of the network into the L3VPN over a period of a few weeks. My first thought was to set up route leaking between the VRFs and the global table, but looking back at listserv threads as well as Juniper docs, I realize it's not possible to export MP-BGP learned routes into the global table using Juniper rib groups. I'm currently looking into using BGP between logical tunnel interfaces on the global table and a vrf to accomplish the route sharing, and that seems like a good possibility, but I’m curious about a few things: 1) Does anyone run production traffic through logical tunnel interfaces between the global table and routing instances? (we’re using fairly lightly-loaded MX480s) 2) Does any one have a smarter strategy that I could borrow to accomplish this transition? It all feels so kludge-y and brittle. -Dan
Re: IPv6 Default Allocation - What size allocation are you giving out
On Oct 10, 2014, at 3:49 AM, William Herrin b...@herrin.us wrote: 6752 isn't germane; it has to do with using private IP addresses on routers, which borks things up when the router has to generate an ICMP type 3. I beg to differ, as noted by Owen DeLong in this same thread: On 9 October 2014 22:01, Owen DeLong o...@delong.com wrote: Having public addresses in trace-routes, ideally with good reverse DNS is actually useful. Clarity is almost always an advantage over obscurity when one is troubleshooting something. Being able to ping the link address is useful for troubleshooting. Being able to source packets from a particular link address can be useful for troubleshooting. Several of the very same caveats apply - that's why I cited the informational RFC with regards to private IP addressing, rather than re-typing the same things all over again. -- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Equo ne credite, Teucri. -- Laocoön
Re: IPv6 Default Allocation - What size allocation are you giving out
On Oct 10, 2014, at 3:53 AM, Baldur Norddahl baldur.nordd...@gmail.com wrote: I am not dismissing any arguments, and I am genuinely interested in any advantages and disadvantages to the approach. My prediction is that you will remain an advocate of unnumbered links until such time as you have to troubleshoot issues hop-by-hop in a network of any non-trivial size/complexity. Then, your views on this topic will likely change. Many of the same caveats noted in RFC6752 apply to unnumbered interfaces, as well. That's why I cited it. -- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Equo ne credite, Teucri. -- Laocoön
Re: Unwanted Traffic Removal Service (UTRS)
Hi Christian, On Thu, Oct 09, 2014 at 10:58:05PM +0200, Christian Seitz wrote: snip Why is there no validation required when this is done by an IXP? All peers are my customers and I do trust them? What about private peerings via PNIs? Validation is not required because the requester can only affect his or her own peering ports. Conceptually the IXP participant sets an ACL, just not on their own ingress routerport but on the egress port just across the crossconnect, this prevents congestion of said crossconnect. Modern switching/routing equipment used in IXPs can do far more then mere L2 switching. Lots of chipsets these days allow you to apply combined layer-3 + layer-2 ACLs, an example would be Discard traffic if (destination IP is A destination MAC is B). The blackhole route is announced to a special network component which I dub the ACL Server. The ACL Server is operated by the IXP (exabgp + customizations?). The ACL Server takes the prefix and associated origin (origin is a static lookup table based on source IP or ASN, IXPs know who their members are) and then inserts a layer3+layer2 ACL into their switching fabric. If the IXP, on every ingress port, have a ACL that says drop traffic to this IP if the dest MAC address corresponds with the originator of the ACL request, the ddos traffic doesn't even hit the IXPs backbone, and only affects the peering participant who requested the ACL to be inserted. So the blackhole route only lives inside the IXP's switching fabric so to speak, as an ACL only applicable to the participant itself. Regarding implementation: some IXPs might have to screenscrape/expect to apply ACLs on their switches with clogin, others will just convert the announcement and insert flowspec or sdn rules in the fabric. It is the IXP's job to sanitize the ACL trigger in such a way that it only applies to the peering ports of the participant requesting it. I hope this clarifies a bit. Kind regards, Job
Re: IPv6 Default Allocation - What size allocation are you giving out
On Thu, Oct 9, 2014 at 5:13 PM, Baldur Norddahl baldur.nordd...@gmail.com wrote: But all this are customer facing interfaces, which do not really qualify for point to point links. I might consider adding interface addressing for IPv6, but for me IPv4 was the primary design parameter. Having IPv6 mirror the IPv4 setup means I have to think less about the setup. And we are really constrained to use as few IPv4 addresses as possible. We only got 1024 from RIPE and have to buy any additional at great expense. Hi Baldur, If that's convenient, more power to you. I can think of nothing which breaks doing it that way, just a couple things that might be easier if you do it the other way. My colleges wanted to completely drop using public IP addressing in the infrastructure. This, however, is positively 100% broken. Do not use private IPs on your routers. The TCP protocol depends on receiving ICMP type 3 (destination unreachable) messages from your router. Without ICMP messages needed for path MTU detection, TCP connections somewhat randomly drop into a black hole. Have a customer who connects to your web server but never receives the web page? Look for the firewall blocking ICMP. If those ICMP messages originate from private IP addresses, they will not reach their destination. Private IPs tend to be dropped at multiple locations out on the public Internet. So don't use private IPs on routers. Routers must be able to generate ICMP destination unreachables with the expectation that they _will_ get through. Regards, Bill Herrin -- William Herrin her...@dirtside.com b...@herrin.us Owner, Dirtside Systems . Web: http://www.dirtside.com/ May I solve your unusual networking challenges?
Re: Unwanted Traffic Removal Service (UTRS)
On Thu, 09 Oct 2014 22:58:05 +0200 Christian Seitz ch...@in-berlin.de wrote: What I do not like at this UTRS idea is that I cannot announce a prefix via BGP. Somebody has to inject it for me. I would like to announce it in real time and not with delay because of manual approval. While true today, it might not be true for long. It requires code to be written in order to perform the desired verification we want before blindly passing along an announcement. Code we're not motivated to write if there is insufficient interest in UTRS. Interest is looking good, so the code may soon follow. In other words, this a valid complaint, but it may have a limited life span. One problem that I also see here is that this single entity could be forced by someone (eg. government) to blackhole some prefix. If this ever happens such a project will have to be terminated. I've heard this once before too. I admit we probably can't provide a satisfactory answer to some who will be so distrustful of government or influence peddling to win them over, but I'll try to offer a response that I hope is fairly reasonable and satisfies the majority, and presumably any of the actual participants. There are legal questions, maneuvers and responses that might be interesting to speculate on, but I'll say simply this. Team Cymru, while established and operated within the U.S., is a global organization with team members outside of the U.S. and we rely heavily on the cooperation of global partners to do what we do. If we could be compelled to announce a black hole by someone, government or otherwise, the cooperation and inherent trust we might have with the Internet community is probably gone and we are likely finished as an organization. It would be counter to our very existence and so on that basis I hope most would agree is extremely unlikely to occur. Now if someone came up to me with a gun to my head and said type the equivalent of ip route foonet mask 192.0.2.1 or die, I might just type it out of self preservation. We also had some DDoS attacks via IPv6. I think it's important to also have such a service for IPv6. Starting with IPv4 is ok and better than nothing, but IPv6 should not be on the roadmap for 2018 ;-) You are only the second person I've heard from to explicitly state as such. This is actually not terribly hard to do and I'm pretty certain could be done way before 2018. Simple to start, careful and necessary improvements as we go. Thanks for your comments Chris, John
RE: Marriott wifi blocking
Yes, the BART case is different because we are talking about a public safety functionality. It really does not even matter who owns the repeaters. Let's say one of the carriers suddenly shuts down their very own cell sites to purposely deny public service.You can almost guarantee that an FCC enforcement action will result because carriers have a public safety responsibility. The state communications commission could even pull your license for that and the FCC could ultimately pull your spectrum licenses for using a public resource in a way not beneficial to the public. BART disrupting cell repeaters is tantamount to you doing anything to disrupt 911 service which is illegal whether you own the gear or not. I don't know what the exact rule currently is but I'm sure it would take someone like Homeland Security to shut down a cellular network for national security reasons. For example, interrupting a cellular bomb detonator or a coordinated terrorist attack. The legal concept of greater good comes into effect at that point. As a common carrier, I know I would not shut down anything that affects 911 service deliberately without either the proper notifications taking place or a federal court order in my hand (and it better be federal because those are the laws you are asking me to throw out here). The funny thing about cell service (or repeaters in this case) is that there isn't usually a mandate to provide coverage in any particular area but once you provide it you are on the hook to maintain it and not purposely disrupt it. Again, it is the intent in this case that matters. If BART had a maintenance problem or the equipment was damaged, they would be off the hook but they purposely interrupted the service to deny communications services to a group of users. Cell sites go down all the time for maintenance scheduled or otherwise but if you are doing it to purposely deny service, it's another story. Again, intent matters...a lot. I definitely see abuse of authority (not really a criminal act in itself, but not nice for sure) and for sure civil liability, not so much a 1st Amendment issue since the government is under no real obligation to give you the means to communicate (like repeaters). It's the 911 service disruption that is most criminal here. Steve However, that's not what was being discussed in the BART example. In this case, repeaters with unclear ownership operated by cellular providers were shut down by BART authorities to try and disrupt a protest. That's not active jamming, so most likely, not an FCC issue. There are other areas of concern, however, such as 1st amendment violations, abuse of authority, potential civil liability if anyone was unable to reach 911 in an expected manner, etc. Owen
Re: IPv6 Default Allocation - What size allocation are you giving out
On 9 October 2014 23:18, Roland Dobbins rdobb...@arbor.net wrote: On Oct 10, 2014, at 4:13 AM, Baldur Norddahl baldur.nordd...@gmail.com wrote: My colleges wanted to completely drop using public IP addressing in the infrastructure. Your colleagues are wrong. Again, see RFC6752. Yes, for using private IP addressing RFC 6752 applies and it is why we are not doing it. But you seem to completely fail to understand that RFC 6752 does not apply to the proposed solution. NONE of the problems listed in RFC 6752 are a problem with using unnumbered interfaces. Traceroute works. ICMP works. There are no private IP addresses that gets filtered. I am wondering if all the nay sayers would not agree that is it better to have a single public loopback address shared between all my interfaces, than to go with private addressing completely? This is a false dichotomy. Because frankly, that is the alternative. It isn't the only alternative. The *optimal* alternative is to use publicly-routable link addresses, and then protect your infrastructure using iACLs, GTSM, CoPP, et. al. I will as soon as you send me the check to buy addresses for all my links. I got a few. But it appears you do not realize that we ARE using public IPs for our infrastructure. And we ARE using ACLs for protecting it. We are not using addresses for LINKS, neither public nor private. And it is not for security but to conserve expensive address space. The thing is that we will only use ONE public address for a router. And the router will be using that address for traceroute, ICMP et al. And therefore RFC 6752 does not apply. What started this thread was the simple observation that you can do the same with IPv6. In that case I am doing it because it is simpler to do the same thing on both protocols. And frankly I am not seeing the disadvantages put fourth so far as being anything worth taking extra management work for. What I am mostly getting from the responses here are not much useful, other than a lot of people screaming he his doing something different so he must be an idiot :-(. Well aside from Bill, which is apparently doing the same thing for the same reason (cost). Regards, Baldur
RE: Unwanted Traffic Removal Service (UTRS)
I understand the concerns but it seems to me that there are already plenty of ways for any large government to black hole whatever they want and they do not need UTRS to do so. The only thing stopping (most) governments from doing this regularly are fears of turning the Internet into another arms race. It's a stigma thing like the different between launching the first nuke vs. being the responder. We all know they do a lot of cyber stuff out there but it is mostly behind a veil of deniability. First, if they have access to a tier 1 carrier (or at least enough carriers to make an impact) in their jurisdiction they could just order that carrier to do it with whatever court system (or not) is required. Most large governments also have enough connectivity to bury a route by brute force. The only thing stopping (most) governments from doing this regularly are fears of turning the Internet into another arms race and possibly losing easy access to that resource. We all know they do a lot of cyber crime stuff out there but it is mostly behind a veil of deniability. There has actually been more black hole events that occur by accident or as part of denial of service attacks than government launched. The global routing structure of the Internet has always been highly cooperative and vulnerable to a bad actor at a lot of points. My only real concern with UTRS is designing a system that cannot be gamed or exploited to turn it into a very effective DoS weapon system. I admit that I don't know enough about how it works to make that decision yet. Steven Naslund Chicago IL Subject: Re: Unwanted Traffic Removal Service (UTRS) On Thu, 09 Oct 2014 22:58:05 +0200 Christian Seitz ch...@in-berlin.de wrote: What I do not like at this UTRS idea is that I cannot announce a prefix via BGP. Somebody has to inject it for me. I would like to announce it in real time and not with delay because of manual approval. While true today, it might not be true for long. It requires code to be written in order to perform the desired verification we want before blindly passing along an announcement. Code we're not motivated to write if there is insufficient interest in UTRS. Interest is looking good, so the code may soon follow. In other words, this a valid complaint, but it may have a limited life span. One problem that I also see here is that this single entity could be forced by someone (eg. government) to blackhole some prefix. If this ever happens such a project will have to be terminated. I've heard this once before too. I admit we probably can't provide a satisfactory answer to some who will be so distrustful of government or influence peddling to win them over, but I'll try to offer a response that I hope is fairly reasonable and satisfies the majority, and presumably any of the actual participants. There are legal questions, maneuvers and responses that might be interesting to speculate on, but I'll say simply this. Team Cymru, while established and operated within the U.S., is a global organization with team members outside of the U.S. and we rely heavily on the cooperation of global partners to do what we do. If we could be compelled to announce a black hole by someone, government or otherwise, the cooperation and inherent trust we might have with the Internet community is probably gone and we are likely finished as an organization. It would be counter to our very existence and so on that basis I hope most would agree is extremely unlikely to occur. Now if someone came up to me with a gun to my head and said type the equivalent of ip route foonet mask 192.0.2.1 or die, I might just type it out of self preservation. We also had some DDoS attacks via IPv6. I think it's important to also have such a service for IPv6. Starting with IPv4 is ok and better than nothing, but IPv6 should not be on the roadmap for 2018 ;-) You are only the second person I've heard from to explicitly state as such. This is actually not terribly hard to do and I'm pretty certain could be done way before 2018. Simple to start, careful and necessary improvements as we go. Thanks for your comments Chris, John
Bounce action notifications - NANOG mailing list changes yahoo.com users
Hello Colleagues, The NANOG mailing list had a discussion several months back regarding changes that Yahoo made to their DMARC settings. Over the past day, the NANOG mailing list has received a number of posts from yahoo.com mail users. This triggered bounce action on nearly 300 NANOG mailing list subscriptions as the receiving mail systems were complying with the DMARC settings that Yahoo has set. All subscriptions that had been disabled have been re-enabled at this time. To correct this moving forward, selective rewriting of the from header has been recommended, but requires an upgrade to the Mailman software. While we would like to have no impact to our subscribers, the selective rewrite and upgrade are not immediately available. An expeditious implementation of the upgrade is being worked on. As a temporary measure, the NANOG mailing list will be holding posts that come from yahoo.com users. We are not wishing to restrict posting, however posts from yahoo.com accounts are causing operational issues with the mailing list. Once a final timeline for the upgrade procedure and selective rewrite are available, we will let you know. Best Regards, Andrew Koch NANOG Communications Committee
Re: IPv6 Default Allocation - What size allocation are you giving out
On Oct 10, 2014, at 5:04 AM, Baldur Norddahl baldur.nordd...@gmail.com wrote: NONE of the problems listed in RFC 6752 are a problem with using unnumbered interfaces. As far as Section 8 goes, you're even worse off than if you were using private IP addresses. And see Section 9. My point is that *analogous* issues arise with unnumbered interfaces. Loopback-only addressing isn't sufficient for troubleshooting purposes and other routine operational activities. The thing is that we will only use ONE public address for a router. And the router will be using that address for traceroute, ICMP et al. And therefore RFC 6752 does not apply. Again, see Section 9. *Analogous* issues arise in networks with unnumbered interfaces. I'm aware that PMTU-D will work with the setup you propose. You might want to take a look at Appendix A, too. It sounds as if there is an unfortunate shortfall in the budget for your organization. Personally, I wouldn't attempt to build and operate a network which required more funding than was made available in order to implement it optimally. Doing things the suboptimal way in IPv4 isn't a valid reason replicate those suboptimalities in IPv6. I wish you luck in troubleshooting an infrastructure full of unnumbered links - I've done it, and it isn't fun. What I am mostly getting from the responses here are not much useful, other than a lot of people screaming he his doing something different so he must be an idiot That is incorrect. You've been told repeatedly that troubleshooting unnumbered links is highly suboptimal; you've merely dismissed those arguments for reasons best known to yourself. -- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Equo ne credite, Teucri. -- Laocoön
GApps admin = rogered
Just a heads up to our friends at Google Apps. Despite the status page saying all is peachy: http://www.google.com/appsstatus#hl=env=status ...the administration page for any Google Apps for domains is totally rogered. It's either an endless redirect loop or a deluge of errors. I'd call for premium support, but I can't even see that. Again, a friendly heads up and nudge that perhaps the status page should at least be updated to reflect the fact that it's non-operational.
Re: Marriott wifi blocking
On 10/10/14 01:02, Naslund, Steve wrote: Yes, the BART case is different because we are talking about a public safety functionality. It really does not even matter who owns the repeaters. Let's say one of the carriers suddenly shuts down their very own cell sites to purposely deny public service.You can almost guarantee that an FCC enforcement action will result because carriers have a public safety responsibility. The state communications commission could even pull your license for that and the FCC could ultimately pull your spectrum licenses for using a public resource in a way not beneficial to the public. BART disrupting cell repeaters is tantamount to you doing anything to disrupt 911 service which is illegal whether you own the gear or not. I don't know what the exact rule currently is but I'm sure it would take someone like Homeland Security to shut down a cellular network for national security reasons. For example, interrupting a cellular bomb detonator or a coordinated terrorist attack. The legal concept of greater good comes into effect at that point. As a common carrier, I know I would not shut down anything that affects 911 service deliberately without either the proper notifications taking place or a federal court order in my hand (and it better be federal because those are the laws you are asking me to throw out here). The funny thing about cell service (or repeaters in this case) is that there isn't usually a mandate to provide coverage in any particular area but once you provide it you are on the hook to maintain it and not purposely disrupt it. Again, it is the intent in this case that matters. If BART had a maintenance problem or the equipment was damaged, they would be off the hook but they purposely interrupted the service to deny communications services to a group of users. Cell sites go down all the time for maintenance scheduled or otherwise but if you are doing it to purposely deny service, it's another story. Again, intent matters...a lot. I definitely see abuse of authority (not really a criminal act in itself, but not nice for sure) and for sure civil liability, not so much a 1st Amendment issue since the government is under no real obligation to give you the means to communicate (like repeaters). It's the 911 service disruption that is most criminal here. Steve However, that's not what was being discussed in the BART example. In this case, repeaters with unclear ownership operated by cellular providers were shut down by BART authorities to try and disrupt a protest. That's not active jamming, so most likely, not an FCC issue. There are other areas of concern, however, such as 1st amendment violations, abuse of authority, potential civil liability if anyone was unable to reach 911 in an expected manner, etc. Owen see if you can get tor browser to work... download it from torproject.org
Re: [outages] GApps admin = rogered
Was not there at the time I sent the email. I was thorough in checking. 100% sure. On Thu, Oct 9, 2014 at 6:22 PM, Mitch Patterson mitpatter...@gmail.com wrote: Shows an issue to me TimeDescription 10/9/14 7:11 PM We're investigating reports of an issue with Admin console. We will provide more information shortly. Users are seeing the Admin console refresh continuously on loading. On Thu, Oct 9, 2014 at 7:07 PM, Blair Trosper via Outages outa...@outages.org wrote: Just a heads up to our friends at Google Apps. Despite the status page saying all is peachy: http://www.google.com/appsstatus#hl=env=status ...the administration page for any Google Apps for domains is totally rogered. It's either an endless redirect loop or a deluge of errors. I'd call for premium support, but I can't even see that. Again, a friendly heads up and nudge that perhaps the status page should at least be updated to reflect the fact that it's non-operational. ___ Outages mailing list outa...@outages.org https://puck.nether.net/mailman/listinfo/outages
Re: [outages] GApps admin = rogered
i confirm this issue is apparent for us as well.
Re: GApps admin = rogered
This is 4-5 minutes after the OP emailed On Thursday, October 9, 2014, Mitch Patterson via Outages outa...@outages.org wrote: Shows an issue to me TimeDescription 10/9/14 7:11 PM We're investigating reports of an issue with Admin console. We will provide more information shortly. Users are seeing the Admin console refresh continuously on loading. On Thu, Oct 9, 2014 at 7:07 PM, Blair Trosper via Outages outa...@outages.org javascript:_e(%7B%7D,'cvml','outa...@outages.org'); wrote: Just a heads up to our friends at Google Apps. Despite the status page saying all is peachy: http://www.google.com/appsstatus#hl=env=status ...the administration page for any Google Apps for domains is totally rogered. It's either an endless redirect loop or a deluge of errors. I'd call for premium support, but I can't even see that. Again, a friendly heads up and nudge that perhaps the status page should at least be updated to reflect the fact that it's non-operational. ___ Outages mailing list outa...@outages.org javascript:_e(%7B%7D,'cvml','outa...@outages.org'); https://puck.nether.net/mailman/listinfo/outages -- Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds. -- Samuel Butler
Re: IPv6 Default Allocation - What size allocation are you giving out
On 10 October 2014 00:37, Roland Dobbins rdobb...@arbor.net wrote: On Oct 10, 2014, at 5:04 AM, Baldur Norddahl baldur.nordd...@gmail.com wrote: NONE of the problems listed in RFC 6752 are a problem with using unnumbered interfaces. As far as Section 8 goes, you're even worse off than if you were using private IP addresses. I see nothing in section 8 that is broken in my network. My public loopback address is in DNS and reverse DNS works fine too. And see Section 9. I see nothing in section 9 that is broken in my network. Traceroute works perfectly. You do not get a string of * * * back. You get the IP of the loopback which in turn goes through reverse DNS to tell you what router is processing that step. The only difference between a traceroute using unnumbered interfaces and using numbered interfaces, is that you only get information about the router and not the link. My point is that *analogous* issues arise with unnumbered interfaces. Loopback-only addressing isn't sufficient for troubleshooting purposes and other routine operational activities. That is really up to me? 99% of my interfaces are unnumbered by the virtue of being on access switches that simply have no layer 3 capability other than management. Nobody is crazy enough to assign /30s to end users anymore anyway. It is not my business to sell backbone links. I sell end user links and those are unnumbered in my network and everyone else too. I claim this argument is mostly BS. Information about link in traceroute is nice to have. It is not need to have. I have never been in doubt of what traceroute was telling me. Besides I have more effective methods to troubleshoot my links. The thing is that we will only use ONE public address for a router. And the router will be using that address for traceroute, ICMP et al. And therefore RFC 6752 does not apply. Again, see Section 9. *Analogous* issues arise in networks with unnumbered interfaces. I'm aware that PMTU-D will work with the setup you propose. That is not the only thing that works. Everything works. The only problem anyone has been able to point to is that you lose link information in traceroute and get host information in its stead. It is a small loss. You might want to take a look at Appendix A, too. What about it? That is incorrect. You've been told repeatedly that troubleshooting unnumbered links is highly suboptimal; you've merely dismissed those arguments for reasons best known to yourself. Maybe because on that one topic I am more an expert than you: I have experience troubleshooting my network, you don't. Regards, Baldur
Re: Bounce action notifications - NANOG mailing list changes yahoo.com users
On Thu, Oct 9, 2014 at 2:20 PM, Andrew Koch a...@gawul.net wrote: To correct this moving forward, selective rewriting of the from header has been recommended, but requires an upgrade to the Mailman software. If the admins have settled on a best practice, it could help other Mailman operators like myself. Two questions spring to mind: 1. With the planned method, how will reply behavior be affected? 2. Will this be an upgrade to 2.1.16, or a pre-release version of 2.1.18, or something else? From http://wiki.list.org/display/DEV/DMARC : In 2.1 16 a from_is_list feature was implemented which if enabled by a site configuration option would offer a list admin the ability to either: * Rewrite (Munge) the From: header with the posters name 'via the list' and the list's address and merge the poster's address into Reply-To: or * Wrap the message as a message/rfc822 sub-part in a MIME format outer message with From: and Reply-To: as above. Implemented now for release in 2.1.18 are the following: * The from_is_list feature from 2.1.16 is always available. * There are new settings in Privacy options - Sender filters: ** dmarc_moderaction_action is a five valued setting with values *** Accept - accept the post without rewriting From: or wrapping the message *** Munge From - rewrite the From: and Reply-To: as in from_is_list *** Wrap Message - wrap the message as in from_is_list *** Reject - reject the post *** Discard - Discard the post ** dmarc_moderaction_notice is a custom reject message to replace the default Reject message. * The above options other than Accept override the from_is_list setting for messages whose original From: domain publishes a DMARC policy of p=reject or p=quarantine. A per-list option is available to limit this to just p=reject or to apply it to either p=reject or p=quarantine. If the option is Accept, the from_is_list setting applies. * There is a site option to set the default for dmarc_moderaction_action and list admins may not set the action to a setting which is above the site default in the above list. E.g., if the site default is Reject, list admins can only set Reject or Discard; if the site default is Munge From, list admins can select anything but Accept. Royce
Re: GApps admin = rogered
On 10/9/2014 18:07, Blair Trosper wrote: Just a heads up to our friends at Google Apps. Despite the status page saying all is peachy: http://www.google.com/appsstatus#hl=env=status ...the administration page for any Google Apps for domains is totally rogered. It's either an endless redirect loop or a deluge of errors. For me and any others here in the F row, a question about the use and meaning and implication of the use of the word rogered. Until this very moment that word has ALWAYS (correctly used) meant received or receipt acknowledged and OCCASIONALLY (under the influence of [H|B]ollywood) incorrectly I agree. What does it mean here? -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes
Re: GApps admin = rogered
On 10/9/2014 20:51, Harald Koch wrote: http://lmgtfy.com/?q=rogered The first entries are all 'correct' for the intended slang use, in this case. I have lived a very sheltered life. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes
Re: IPv6 Default Allocation - What size allocation are you giving out
* Baldur Norddahl Why do people assign addresses to point-to-point links at all? You can just use a host /128 route to the loopback address of the peer. Saves you the hassle of coming up with new addresses for every link. Why do you need those host routes? Most IPv6 IGPs work just fine without global addresses or host routes. https://tools.ietf.org/html/draft-ietf-opsec-lla-only-11 Tore
