Re: Enhancing automation with network growth
On 26/01/2010 00:48, Steve Bertrand wrote: My original post was completely concerned on automating the process of spinning traffic throughput graphs. Are there any software packages that stand out that have the ability to differentiate throughput between v4/v6, as opposed to the aggregate of the interface? (I will continue reading docs of all recommendations, but this may expedite the process a bit). That's a feature of the switch you are probing, not the monitoring suite per se. e.g. I have Cisco CPE that does count the difference : bcliffe-gw#sh int accounting | b Vlan1 Vlan1 Wired network VLAN ProtocolPkts In Chars In Pkts Out Chars Out IP4587251 11371742684757409 3669014365 ARP 12595 755700 524093144540 IPv6 188872 20699030 223349 131947020 but these numbers can not be polled via SNMP, so the only way to graph this device is with an expect script and telnet access. Nice. :-) There is an ipv6MIB, with some interface stats defined under 1.3.6.1.2.1.55.1.6.1, but I do not know of a family of devices which supports this for sure. If your devices support Netflow9, then this -- whilst an extremely heavy/kitchen sink approach -- will give you any degree of granularity that you like. Not long term reliable, but if your v6 is presented via a tunnel, you could graph that tunnel interface ? Yuck, yuck (but we did measure some ipv6 traffic use (more than we expected actually) at a recent operational meeting in the UK) Please let us all know if you find something with good v6 snmp support. Andy
Re: Using /126 for IPv6 router links
On Mon, 25 Jan 2010 22:34:46 -0500 Christopher Morrow morrowc.li...@gmail.com wrote: On Mon, Jan 25, 2010 at 7:33 PM, Owen DeLong o...@delong.com wrote: On Jan 25, 2010, at 8:14 AM, Mathias Seiler wrote: Ok let's summarize: /64: + Sticks to the way IPv6 was designed (64 bits host part) + Probability of renumbering very low + simpler for ACLs and the like + rDNS on a bit boundary You can give your peers funny names, like 2001:db8::dead:beef ;) - Prone to attacks (scans, router CPU load) Unless of course you just block nonexistent addresses in the /64 at each end. uhm, how sensible is this? Use s^64 address, block all but the first 2 I'm confused by the goal of using a /64 on a ptp link that never will have more than 2 addresses on it? I get that 'years ago' understanding what a /30 or a /31 is was 'hard' for people but seriously, this is 2010... And therefore life should be getting easier, not harder. If there is no need for variable length node addresses, why make life harder by using them? This discussion isn't about what's hard or not to understand, it's about whether variable length node addresses are necessary or not. In IPv6 they're not. Why can't IPv6 node addressing be as easy to understand and work with as Ethernet addresses? They were designed in the early 1980s*. 28 years or so years later, it's time for layer 3 addressing to catch up. * 48-bit Absolute Internet and Ethernet Host Numbers http://ethernethistory.typepad.com/papers/HostNumbers.pdf (well worth a read - did you know that Ethernet addresses were supposed to be per host, not per interface?) - Waste of addresses - Peer address needs to be known, impossible to guess with 2^64 addresses Most of us use ::1 for the assigning side and ::2 for the non-assigning side of the connection. On multipoints, such as exchanges, the popular alternative is to use either the BCD of the ASN or the hex of the ASN for your first connection and something like ::1:AS:N for subsequent connections. multipoint exchanges are out of scope of the discission, or so I had counted earlier. /126 + Only 4 addresses possible (memorable, not so error-prone at configuration-time and while debugging) + Not prone to scan-like attacks Equally prone to scan like attacks, but, no ACL required to reduce vulnerability. how so? How do you reduce this without an acl or some sort somewhere that needs to be maintained? (I think I'm asking for some config snippets with explanations, perhaps it's documented somewhere already even? :) ) -Chris - Not on a bit boundary, so more complicated for ACLs and … - … rDNS - Perhaps need to renumber into /64 some time. - No 64 bits for hosts /127 Like /126 but there's an RFC not recommending it and an RFC (draft) which revises that non-recommendation. On 25 Jan 2010, at 10:14, Matthew Petach wrote: On Sat, Jan 23, 2010 at 4:52 AM, Mathias Seiler mathias.sei...@mironet.ch wrote: Hi In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard. I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong. So what do you think? Good? Bad? Ugly? /127 ? ;) Cheers Mathias Seiler MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel T +41 61 201 30 90, F +41 61 201 30 99 mathias.sei...@mironet.ch www.mironet.ch As I mentioned in my lightning talk at the last NANOG, we reserved a /64 for each PtP link, but configured it as the first /126 out of the /64. That gives us the most flexibility for expanding to the full /64 later if necessary, but prevents us from being victim of the classic v6 neighbor discovery attack that you're prone to if you configure the entire /64 on the link. I think I will go this way. Since we've got the usual /32 assignment I have plenty of /64 to waste. If I continue assigning a /48 to every customer I can set apart a /64 for each PtP link and still have room to grow for a very long time (I'm not taking into account the assignment of IPv6 addresses to high amounts of MMs so far ;) ) This way the configuration and addressing plan is simple and understandable to anyone. All someone out on the 'net needs to do is scan up through your address space on the link as quickly as possible, sending single packets at all the non-existent addresses on the link, and watch as your router CPU starts to churn keeping track of all the neighbor discovery messages, state table updates, and incomplete age-outs. Well I could filter that in hardware with an interface ACL but a /126 seems much easier to maintain. With the link configured as a /126,
DDoS mitigation recommendations
With Guard appliance and 65xx module being EoL'd, and Cisco's desire to exist the DDoS mitigation market, I'd like to get some recommendations of what other products people are having good success with. We are looking for something that can support 3Gbps - 10Gbps, multi-tenancy, seamless integration, and many of the basic features you'd see on the Guard. Thank you, -- Tom Sands Chief Network Engineer Rackspace Hosting Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated.
Re: DDoS mitigation recommendations
Arbor stuff comes to mind and works very well in our experiences Paul -- Paul Stewart Senior Network Administrator Nexicom Inc. http://www.nexicom.net/ - Original Message - From: Tom Sands tsa...@rackspace.com To: nanog na...@merit.edu Sent: Tue Jan 26 07:40:35 2010 Subject: DDoS mitigation recommendations With Guard appliance and 65xx module being EoL'd, and Cisco's desire to exist the DDoS mitigation market, I'd like to get some recommendations of what other products people are having good success with. We are looking for something that can support 3Gbps - 10Gbps, multi-tenancy, seamless integration, and many of the basic features you'd see on the Guard. Thank you, -- Tom Sands Chief Network Engineer Rackspace Hosting Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you.
Fusion Splicers
Anyone here with any experience with Jilong fusion splicers ? Our old Fujikura has died and I have to at least consider the Jilong.
RE: Using /126 for IPv6 router links
-Original Message- From: Christopher Morrow [mailto:morrowc.li...@gmail.com] Sent: Monday, January 25, 2010 22:38 To: Owen DeLong Cc: nanog@nanog.org Subject: Re: Using /126 for IPv6 router links On Mon, Jan 25, 2010 at 8:01 PM, Owen DeLong o...@delong.com wrote: Once you start planning a practical address plan, IPv6 isn't as big as everybody keeps saying... It's more than big enough for any deployment I've seen so far with plenty of room to spare. Oh good! so the us-DoD's /10 request is getting filled when? The US DoD has the equivalent of a /13 ... what is the question? /TJ
RE: Using /126 for IPv6 router links
-Original Message- From: Mark Smith [mailto:na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org] Sent: Monday, January 25, 2010 23:07 To: TJ Cc: nanog@nanog.org Subject: Re: Using /126 for IPv6 router links SNIP I didn't realize human friendly was even a nominal design consideration, especially as different humans have different tolerances for defining friendly :) This from people who can probably do decimal to binary conversion and back again for IPv4 subnetting in their head and are proud of it. Surely IPv6 hex to binary and back again can be the new party trick? :-) Hex-Binary-Decimal, and permutations thereof - always a great party trick ... if you hang out at the right parties! /TJ
RE: DDoS mitigation recommendations
One more for Arbor. -Original Message- From: David Freedman [mailto:david.freed...@uk.clara.net] Sent: Tuesday, January 26, 2010 8:17 AM To: nanog@nanog.org Subject: Re: DDoS mitigation recommendations Arbor stuff comes to mind and works very well in our experiences Arbor++ This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
Re: Using /126 for IPv6 router links
On 26/01/2010 13:35, TJ wrote: The US DoD has the equivalent of a /13 ... what is the question? In fact, they have a little less than a /18. This is still the largest block when aggregated - France Telecom comes second with a single /19. http://www.mail-archive.com/nanog@nanog.org/msg01876.html It may be time to retire this myth. Nick
Re: DDoS mitigation recommendations
There was an interesting thread on this topic a few weeks back. I really liked the Guards, it's too bad Cisco decided to pull this from the marketplace - it was as close to a panacea as it gets. As alternatives, I've worked with the Riorey boxes as well as Arbor gear. They are both very good boxes, but as your requirements state that you require Multi-tenancy that only really leaves the Arbor. Unfortunately, the Riorey boxes only support a one-size fits all approach as they do not allow unique filtering parameters on a per-prefix basis. Arbor on the other hand supports a full range of Managed Objects and Mitigation Templates which can be applied to individual prefixes, etc. Sorry for the top post, I'm on my Blackberry. Stefan Fouant --Original Message-- From: Korten, Sean To: nanog@nanog.org To: tsa...@rackspace.com Subject: RE: DDoS mitigation recommendations Sent: Jan 26, 2010 9:16 AM One more for Arbor. -Original Message- From: David Freedman [mailto:david.freed...@uk.clara.net] Sent: Tuesday, January 26, 2010 8:17 AM To: nanog@nanog.org Subject: Re: DDoS mitigation recommendations Arbor stuff comes to mind and works very well in our experiences Arbor++ This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. Sent from my Verizon Wireless BlackBerry
Re: Using /126 for IPv6 router links
From: Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org
Why can't IPv6 node addressing be as easy to understand and work with
as Ethernet addresses? They were designed in the early 1980s*. 28 years
or so years later, it's time for layer 3 addressing to catch up.
Becase Ethernet addresses are only locally significant, are not manually
assigned in the vast majority of cases, and changing a MAC by replacing a NIC
has no bearing on the configuration of a { server | router ACL | etc }.
Layer 3 addressing is globally significant, and the case we're discussing is
addresses which are human-assigned rather than automatically configured.
Link-local autoconfiguration in IPv6 works like a champ, and behaves pretty
much the way I would want it to. Global addressing approaches, on the other
hand, are highly optimized in directions which make them less flexible or have
surprising consequences (hence this thread).
David Barak
Need Geek Rock? Try The Franchise:
http://www.listentothefranchise.com
Re: Using /126 for IPv6 router links
Owen DeLong wrote: No, they're not impossible to exhaust, just pretty difficult. However, If we see exhaustion coming too soon in this /3, we can always apply a more conservative numbering policy to the next /3. (And still have 5 /3s left to innovate and try other alternatives). Owen Owen, We have had this conversation before, but I just wanted to put my two cents out there again. I dont view /3 as a safety valve. I view it as a possible escape pod from a sinking ship. If it needs to be utilized, the entire world has been dealt a large disservice - something great pains should be taken to avoid. I doubt it would be an oops, ime sorry, no harm done. It should not be a factor to add risk into allocation design. Furthermore, any allocation holder trying the same trick of reserving a greater than half of their block for the safety valve in their numbering scheme might quickly discover that their block is a bit more cramped than they thought it would be. For me, the entire debate boils down to this question. What should the objective be, decades or centuries? Joe
Re: Using /126 for IPv6 router links
On Jan 26, 2010, at 9:54 AM, Joe Maimon wrote: For me, the entire debate boils down to this question. What should the objective be, decades or centuries? If centuries, how many planets and moons will the address space cover? (If we as a species manages to spread beyond this world before we destroy it). Will separate /3's, or subdivisions of subsequent /3's, be the best approach to deploying a large-scale IPv6 network on Mars? (and yes, a bit of work would be required to make the round-trip times fall within TCP's windows).
Re: DDoS mitigation recommendations
The RioRey per prefix issue is fixed although the patch they released to us had a lot of bugs. Were still waiting on a working appliance with the new code. IntruGuard fits the bill and is probably 1/5th the cost of Arbor pound for pound. We use both RR and IG, each having their pros and cons. Jeff On Jan 26, 2010 9:39 AM, Stefan Fouant sfou...@shortestpathfirst.net wrote: There was an interesting thread on this topic a few weeks back. I really liked the Guards, it's too bad Cisco decided to pull this from the marketplace - it was as close to a panacea as it gets. As alternatives, I've worked with the Riorey boxes as well as Arbor gear. They are both very good boxes, but as your requirements state that you require Multi-tenancy that only really leaves the Arbor. Unfortunately, the Riorey boxes only support a one-size fits all approach as they do not allow unique filtering parameters on a per-prefix basis. Arbor on the other hand supports a full range of Managed Objects and Mitigation Templates which can be applied to individual prefixes, etc. Sorry for the top post, I'm on my Blackberry. Stefan Fouant --Original Message-- From: Korten, Sean To: nanog@nanog.org To: tsa...@rackspace.com Subject... Sent from my Verizon Wireless BlackBerry
Re: Using /126 for IPv6 router links
Daniel Senie wrote: On Jan 26, 2010, at 9:54 AM, Joe Maimon wrote: For me, the entire debate boils down to this question. What should the objective be, decades or centuries? If centuries, how many planets and moons will the address space cover? (If we as a species manages to spread beyond this world before we destroy it). Will separate /3's, or subdivisions of subsequent /3's, be the best approach to deploying a large-scale IPv6 network on Mars? (and yes, a bit of work would be required to make the round-trip times fall within TCP's windows). We already have numbering systems that are showing their age as they are hitting their late decades or even older. Now if decades are good enough for you, how many of them? IPv4 is 3 and nearly certain to hit 4 and possibly 5. Wouldnt you like to do at least twice as well? So calling for a system that should work for at least a 100 years is not as laughable as it may seem on the face of it -- in fact thats what the original promise of ipv6 was. You make another excellent point. There may be other needs for the rest of the /3's that will take them out of the escape pod role. Joe
Re: Using /126 for IPv6 router links
On Mon, Jan 25, 2010 at 6:20 PM, Nathan Ward na...@daork.net wrote: Why do you force POP infrastructure to be a /48? That allows you only 16 POPs which is pretty restrictive IMO. Why not simply take say 4 /48s and sparsely allocate /56s to each POP and then grow the /56s if you require more networks at each POP. You only have a need for 4 /64s at each POP right now, so the 256 that a /56 gives you sounds like more than enough, and up to 1024 POPs (assuming you don't outgrow any of the /56s). NRPM says: 6.5.4.3. Assignment to operator's infrastructure An organization (ISP/LIR) may assign a /48 per PoP as the service infrastructure of an IPv6 service operator. Each assignment to a PoP is regarded as one assignment regardless of the number of users using the PoP. A separate assignment can be obtained for the in-house operations of the operator. Currently living with mixed infrastructure/customer address space, so I'm quite happy to separate this out. We will also have a /48 per-pop for service we provide, such as DHCP/DNS/Web etc. Essentially we will be a customer of our own infrastructure. I believe the above wording allows for that. Also I'd strongly recommend not stuffing decimal numbers in to a hexadecimal field. It might seem like a good idea right now to make the learning curve easier, but it's going to make stuff annoying long term. You don't have anything in IPv4 that's big enough to indicate the VLAN number and you've lived just fine for years, so forcing it to be decimal like that isn't really needed. You're much better off giving your staff the tools to translate between the two, rather than burn networks in order to fudge some kind of human readability out of it and sacrificing your address space to get it. % printf %04x\n 4095 0fff % printf %d\n 0x0fff 4095 -- Nathan Ward Maybe so. Right now we convert VLAN IDs to IPv4 3rd octet. Every access switch gets a dedicated set of VLANs along these lines: 48, 348, 648, 1048 etc. That leaves space for 128 access switches per POP, without having to think about anything. The not having to think part is significant, as it trades human engineering for address space. That is also one of our goals for IPv6 deployment. -- Tim:
Re: Using /126 for IPv6 router links
On Mon, Jan 25, 2010 at 10:55 PM, Christopher Morrow morrowc.li...@gmail.com wrote: some of what you're saying (tim) here is that you could: (one of these) 1) go to all your remote-office ISP's and get a /48 from each 2) go to *RIR's and get /something to cover the number of remote sites you have in their region(s) 3) keep on keepin' on until something better comes along? This isn't really for remote offices, just our large campus sites. 2) o justification in light of 'unclear' policies for an address block of the right size. NOTE:I don't think the policies is unclear, but that could be my misreading of the policies. For me, this seems unclear: 6.5.4.2. Assignment of multiple /48s to a single end site When a single end site requires an additional /48 address block, it must request the assignment with documentation or materials that justify the request. Requests for multiple or additional /48s will be processed and reviewed (i.e., evaluation of justification) at the RIR level. Note: There is no experience at the present time with the assignment of multiple /48s to the same end site. Having the RIR review all such assignments is intended to be a temporary measure until some experience has been gained and some common policies can be developed. In addition, additional work at defining policies in this space will likely be carried out in the near future. o will your remote-office's ISP's accept the /48's per site? (vz/vzb is a standout example here) Not too worried about VZ. Given that large content providers are getting end-site address space, I think they will have to adjust their stance. o will your remote-office's have full reachability to the parts of the network they need access to? (remote ISP's filtering at/above the /48 boundary) Remote offices aren't included in this plan. For the Enterprise still used to v4-land ipv6 isn't a win yet... for an ISP it's relatively[0] simple. -Chris 0: address interfaces, turn up protocols, add 'security' assign customers /48's...(yes fight bugs/problems/'why is there a colon in my ip address? (what if you do have 200 offices in the US which aren't connected on a private network today?) -- Tim: Sent from Brooklyn, NY, United States
unreachable Sites
I have been notified this morning by several people that there is some websites that are unreachable from Haiti: http://www.hostcentric.com, http://www.gama.ht those are examples. It happens with different ISP. When we change th DNS using the google one 8.8.8.8 it's ok for some but some others still remain unreachable. Can some of you from the Nanog list check and advise? Thank you -- === Reynold Guerrier IT Consultant 509-3446-0099 IM: rey...@hotmail.com Skype: reygji
Re: Using /126 for IPv6 router links
On 2010-01-26 at 10:05:29 -0500, Daniel Senie wrote: If centuries, how many planets and moons will the address space cover? (If we as a species manages to spread beyond this world before we destroy it). Will separate /3's, or subdivisions of subsequent /3's, be the best approach to deploying a large-scale IPv6 network on Mars? (and yes, a bit of work would be required to make the round-trip times fall within TCP's windows). Someone's going to have to update RFC2549 to address 'IP over Ansible'? ;) -A
Re: unreachable Sites
It's Ok Now. Thanks for your replies. reynold On Tue, Jan 26, 2010 at 11:32 AM, Scott Berkman sc...@sberkman.net wrote: I was able to reach both of these from where I sit in Atlanta. -Scott -Original Message- From: Reynold Guerrier [mailto:rey...@gmail.com] Sent: Tuesday, January 26, 2010 11:09 AM To: NANOG list Subject: unreachable Sites I have been notified this morning by several people that there is some websites that are unreachable from Haiti: http://www.hostcentric.com, http://www.gama.ht those are examples. It happens with different ISP. When we change th DNS using the google one 8.8.8.8 it's ok for some but some others still remain unreachable. Can some of you from the Nanog list check and advise? Thank you -- === Reynold Guerrier IT Consultant 509-3446-0099 IM: rey...@hotmail.com Skype: reygji -- === Reynold Guerrier IT Consultant 509-3446-0099 IM: rey...@hotmail.com Skype: reygji
Re: Using /126 for IPv6 router links
Chris, Discussion of draft-kohno-ipv6-prefixlen-p2p is on the IETF 6man WG mailing list. But please do chime in. Operator input very welcomed. Ron Christopher Morrow wrote: On Sat, Jan 23, 2010 at 7:52 AM, Mathias Seiler mathias.sei...@mironet.ch wrote: Hi In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard. I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong. So what do you think? Good? Bad? Ugly? /127 ? ;) coughdraft-kohno-ipv6-prefixlen-p2p-00.txt/cough (http://tools.ietf.org/id/draft-kohno-ipv6-prefixlen-p2p-00.txt) why not just ping your vendors to support this, and perhaps chime in on v6ops about wanting to do something sane with ptp link addressing? :) -Chris
Re: Using /126 for IPv6 router links
On 1/26/10 7:43 AM, Tim Durack wrote: o will your remote-office's ISP's accept the /48's per site? (vz/vzb is a standout example here) Not too worried about VZ. Given that large content providers are getting end-site address space, I think they will have to adjust their stance. However, they are claiming their own size (i.e. we're bigger) as one reason not to allow anything smaller than a /32. ~Seth
Re: Using /126 for IPv6 router links
On Tue, Jan 26, 2010 at 11:50 AM, Ron Bonica rbon...@juniper.net wrote: Chris, Discussion of draft-kohno-ipv6-prefixlen-p2p is on the IETF 6man WG mailing list. But please do chime in. Operator input very welcomed. oh damned it! almost as many v6 ietf mailing lists as there are v6 addresses :( subscribe info: https://www.ietf.org/mailman/listinfo/ipv6 Thanks! -Chris Christopher Morrow wrote: On Sat, Jan 23, 2010 at 7:52 AM, Mathias Seiler mathias.sei...@mironet.ch wrote: Hi In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard. I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong. So what do you think? Good? Bad? Ugly? /127 ? ;) coughdraft-kohno-ipv6-prefixlen-p2p-00.txt/cough (http://tools.ietf.org/id/draft-kohno-ipv6-prefixlen-p2p-00.txt) why not just ping your vendors to support this, and perhaps chime in on v6ops about wanting to do something sane with ptp link addressing? :) -Chris
Re: Using /126 for IPv6 router links
On 26-1-2010 1:33, Owen DeLong wrote: - Waste of addresses - Peer address needs to be known, impossible to guess with 2^64 addresses Most of us use ::1 for the assigning side and ::2 for the non-assigning side of the connection. On multipoints, such as exchanges, the popular alternative is to use either the BCD of the ASN or the hex of the ASN for your first connection and something like ::1:AS:N for subsequent connections. If you have shared racks with different customers within, you can use 16 or 32 bits out of 64 as customer ID, allowing the customer to use the rest, so in fact giving him trillions (possible) IP's for one server. It can be use with autoconfiguration which always has FF:FE in the middle - you just use some other bits here for your customer assignments. Thus you identify a customer just by looking at the IP address. -- Grzegorz Janoszka
Re: Using /126 for IPv6 router links
On Tue, Jan 26, 2010 at 10:43 AM, Tim Durack tdur...@gmail.com wrote: On Mon, Jan 25, 2010 at 10:55 PM, Christopher Morrow morrowc.li...@gmail.com wrote: some of what you're saying (tim) here is that you could: (one of these) 1) go to all your remote-office ISP's and get a /48 from each 2) go to *RIR's and get /something to cover the number of remote sites you have in their region(s) 3) keep on keepin' on until something better comes along? This isn't really for remote offices, just our large campus sites. ok, cool... but they'll need to connect to remote offices? or is that just not something you all do? 2) o justification in light of 'unclear' policies for an address block of the right size. NOTE:I don't think the policies is unclear, but that could be my misreading of the policies. For me, this seems unclear: 6.5.4.2. Assignment of multiple /48s to a single end site When a single end site requires an additional /48 address block, it must request the assignment with documentation or materials that justify the request. Requests for multiple or additional /48s will be processed and reviewed (i.e., evaluation of justification) at the RIR level. Note: There is no experience at the present time with the assignment of multiple /48s to the same end site. Having the RIR review all such assignments is intended to be a temporary measure until some experience has been gained and some common policies can be developed. In addition, additional work at defining policies in this space will likely be carried out in the near future. I always read this as 'end site' == 'street address'. So, if you have an office at 123 any st, elbonia, IN. and that gets large enough that you have 66k subnets and thus need another /48... you'd have to document the reasoning for that. If you have 12 sites though, each at different locations and were applying for PI space, it seems you'd ask for a /44 or something like that... (assuming no growth) o will your remote-office's ISP's accept the /48's per site? (vz/vzb is a standout example here) Not too worried about VZ. Given that large content providers are getting end-site address space, I think they will have to adjust their stance. most of the large content folks just got +/32 not PI /48's... or 'yahoo and google'. I'm not sure what Akamai's plan is, they often seem, in the v4 world, to use PA space so maybe that model works for them in v6 as well. I agree that eventually vz will most likely change their stance, but until then, and for the sites who don't have an incentive to change... o will your remote-office's have full reachability to the parts of the network they need access to? (remote ISP's filtering at/above the /48 boundary) Remote offices aren't included in this plan. ok... don't have them or don't plan on having them? -Chris For the Enterprise still used to v4-land ipv6 isn't a win yet... for an ISP it's relatively[0] simple. -Chris 0: address interfaces, turn up protocols, add 'security' assign customers /48's...(yes fight bugs/problems/'why is there a colon in my ip address? (what if you do have 200 offices in the US which aren't connected on a private network today?) -- Tim: Sent from Brooklyn, NY, United States
RE: DDoS mitigation recommendations
I am new to this mailing list - this should be a response to an already started thread that I cannot see: IntelliguardIT has a new class of network appliance that installs inline (layer 2 appliance). It has no impact on current network capacity and automatically manages flash crowds gracefully. To date the company has over-invested in technology and under-invested in sales and marketing. That is changing now: the company is moving to The Bay Area. As a testament to this over-investment we have a few customers in Asia who had CiscoGuard and/or Arbor Network solutions deployed - they were failing! IntelliGuard's solution solved their DDoS problems. If you would like to learn more please contact me directly (the IntelliGuardIT website is quite dated at this stage. Thanks, ..Gerald
Re: DDoS mitigation recommendations
On 1/26/10 11:56 AM, Gerald Wluka wrote: I am new to this mailing list We can tell. - this should be a response to an already started thread that I cannot see: ad deleted
Re: Using /126 for IPv6 router links
On Jan 26, 2010, at 6:54 AM, Joe Maimon wrote: Owen DeLong wrote: No, they're not impossible to exhaust, just pretty difficult. However, If we see exhaustion coming too soon in this /3, we can always apply a more conservative numbering policy to the next /3. (And still have 5 /3s left to innovate and try other alternatives). Owen Owen, We have had this conversation before, but I just wanted to put my two cents out there again. I dont view /3 as a safety valve. I view it as a possible escape pod from a sinking ship. If it needs to be utilized, the entire world has been dealt a large disservice - something great pains should be taken to avoid. I doubt it would be an oops, ime sorry, no harm done. It should not be a factor to add risk into allocation design. Furthermore, any allocation holder trying the same trick of reserving a greater than half of their block for the safety valve in their numbering scheme might quickly discover that their block is a bit more cramped than they thought it would be. For me, the entire debate boils down to this question. What should the objective be, decades or centuries? Joe Decades... I think that a combination of other factors will likely conspire within decades to render the current IPv6 protocol obsolete and drive adoption of a replacement protocol. I don't know what those factors are, but, historically, few things in technology have stood the test of decades. Almost nothing has stood the test of centuries. Owen
Re: Using /126 for IPv6 router links
On Jan 26, 2010, at 7:43 AM, Tim Durack wrote: On Mon, Jan 25, 2010 at 10:55 PM, Christopher Morrow morrowc.li...@gmail.com wrote: some of what you're saying (tim) here is that you could: (one of these) 1) go to all your remote-office ISP's and get a /48 from each 2) go to *RIR's and get /something to cover the number of remote sites you have in their region(s) 3) keep on keepin' on until something better comes along? This isn't really for remote offices, just our large campus sites. 2) o justification in light of 'unclear' policies for an address block of the right size. NOTE:I don't think the policies is unclear, but that could be my misreading of the policies. For me, this seems unclear: 6.5.4.2. Assignment of multiple /48s to a single end site When a single end site requires an additional /48 address block, it must request the assignment with documentation or materials that justify the request. Requests for multiple or additional /48s will be processed and reviewed (i.e., evaluation of justification) at the RIR level. Note: There is no experience at the present time with the assignment of multiple /48s to the same end site. Having the RIR review all such assignments is intended to be a temporary measure until some experience has been gained and some common policies can be developed. In addition, additional work at defining policies in this space will likely be carried out in the near future. I think that is one of the things that is likely to get significantly clarified (and largely eliminated) if any of several current policy proposals are adopted. Anyone here who has an opinion on this should probably subscribe to the ARIN PPML and review the policy proposals under discussion. Your comments would be most useful in determining the best course of action. o will your remote-office's ISP's accept the /48's per site? (vz/vzb is a standout example here) Not too worried about VZ. Given that large content providers are getting end-site address space, I think they will have to adjust their stance. :-) o will your remote-office's have full reachability to the parts of the network they need access to? (remote ISP's filtering at/above the /48 boundary) Remote offices aren't included in this plan. If you have them, they should be. Owen
Re: Using /126 for IPv6 router links
On Jan 26, 2010, at 9:22 AM, Grzegorz Janoszka wrote: On 26-1-2010 1:33, Owen DeLong wrote: - Waste of addresses - Peer address needs to be known, impossible to guess with 2^64 addresses Most of us use ::1 for the assigning side and ::2 for the non-assigning side of the connection. On multipoints, such as exchanges, the popular alternative is to use either the BCD of the ASN or the hex of the ASN for your first connection and something like ::1:AS:N for subsequent connections. If you have shared racks with different customers within, you can use 16 or 32 bits out of 64 as customer ID, allowing the customer to use the rest, so in fact giving him trillions (possible) IP's for one server. It can be use with autoconfiguration which always has FF:FE in the middle - you just use some other bits here for your customer assignments. Thus you identify a customer just by looking at the IP address. Even with shared racks, I'd never implement shared network segments between customers. That's just asking for terrible problems. It can't be used with autoconfiguration because the other 48 bits in the autoconf address are the customer's MAC address, and won't be the customer ID. Owen -- Grzegorz Janoszka
Re: Enhancing automation with network growth
Steve Bertrand wrote: Can anyone offer up ideas on how you manage any automation in this regard for their infrastructure gear traffic graphs? (Commercial options welcome, off-list, but we're as small as our budget is). By popular request, a list of the most suggested software packages. Some were more related to network management in general as opposed to traffic graphic, but - netdisco which I've already got up and running. Although I've only added a few of our devices so far, I can see already how this will be an extremely valuable multi-purpose tool - rancid which I've been using for quite some time already for config management - cacti which I'm strongly considering installing/testing - opennms which appears that it will duplicate many functions I already have deployed on the network (and that I'm happy with), but I may give it a try anyway. If I don't use it, I've got a few 'on the side' clients that could benefit from this all-inclusive package - snmpstat which I may install and test, if only to look at a replacement for my custom BGP peering alerting system - MRTG, with a custom cfgmaker. This was my original idea. If those who recommended this could/are allowed to share their code, please let me know - netflow v9 the majority of my devices don't support this (unfortunately) - bandwidthd already in use for protocol based statistics. This doesn't run full-time in our network, I usually only drop it into place on a span port if I see sustained extreme increases of traffic on a link - IPPlan been using it for a few years Some software supports IPv6, others don't (or have limited capability). Polling IPv6 accounting isn't possible via SNMP, so using scripts with SSH/Telnet access is the only way around that problem for a lot of gear. Cheers, and thanks! Steve
Re: DDoS mitigation recommendations
Sorry but RTFM http://mailman.nanog.org/pipermail/nanog/2010-January/thread.html#16675 Best regards
Re: DDoS mitigation recommendations
On Tuesday 26 January 2010, Ryan Brooks wrote: On 1/26/10 11:56 AM, Gerald Wluka wrote: I am new to this mailing list We can tell. - this should be a response to an already started thread that I cannot see: ad deleted Ha, that's great. When will vendors learn that blatant and subtle ads tick this group of people off and make us want to NOT buy their products. I don't mind vendors hanging out on this list as some of them are useful posters, but cut out all the marketing junk and present just the facts. It is interesting to see Cisco dropping this product though since all their CCDA materials seem to push a loaded 6500 with these options. -- -- Brian Raaen Network Engineer bra...@zcorum.com
IOS family naming
Hi List, Anyone recalls ever seeing the IOS naming convention document. In particular I'm interested in differences between families and trains. This is all I found: http://www.cisco.com/warp/public/620/1.html#topic1 But im looking for something a bit more recent maybe? Can figure out differences between say SG, SGA, EW and EWA. A link to the cipher would certainly help. - Andrey Gordon [andrey.gor...@gmail.com]
Re: IOS family naming
Andrey, I could not find a good link, but let me give you some info on SG, SGA, EW and EWA. All these trains are for the 4500 family (including 4900). They are just different generations. The EW (and then EWA) were the older trains for 4500, which were replaced by the SG trains. If I am not too wrong EW/EWA was new around 2004. SGA was the 1st release for the SG train, but later releases are not called SGB/SGC, but are just marked SG, so you get 12.2(31)SGA as the first release (with 12.2(31)SGA1, 12.2(31)SGA2 etc being maintenance releases, with SGA11 scheduled to be released in a few weeks). The later SG releases are numbered as 12.2(37)SG, 12.2(40)SG, etc - and we have 12.2(53)SG as the latest one. Each such release brings in new features, and has its own maintenance releases (so it would be 12.2(53)SG1, 12.2(53)SG2 etc, with 12.2(53)GS2 being scheduled for the Q2CY10) Hope this gives you a better view. Arie On Tue, Jan 26, 2010 at 10:35 PM, Andrey Gordon andrey.gor...@gmail.comwrote: Hi List, Anyone recalls ever seeing the IOS naming convention document. In particular I'm interested in differences between families and trains. This is all I found: http://www.cisco.com/warp/public/620/1.html#topic1 But im looking for something a bit more recent maybe? Can figure out differences between say SG, SGA, EW and EWA. A link to the cipher would certainly help. - Andrey Gordon [andrey.gor...@gmail.com]
Re: IOS family naming
Not sure how relevant this still is, but it explains some of the older ones. http://www.cisco.com/en/US/products/sw/iosswrel/ps1818/products_tech_note09186a0080101cda.shtml On 1/26/2010 4:21 PM, Arie Vayner wrote: Andrey, I could not find a good link, but let me give you some info on SG, SGA, EW and EWA. All these trains are for the 4500 family (including 4900). They are just different generations. The EW (and then EWA) were the older trains for 4500, which were replaced by the SG trains. If I am not too wrong EW/EWA was new around 2004. SGA was the 1st release for the SG train, but later releases are not called SGB/SGC, but are just marked SG, so you get 12.2(31)SGA as the first release (with 12.2(31)SGA1, 12.2(31)SGA2 etc being maintenance releases, with SGA11 scheduled to be released in a few weeks). The later SG releases are numbered as 12.2(37)SG, 12.2(40)SG, etc - and we have 12.2(53)SG as the latest one. Each such release brings in new features, and has its own maintenance releases (so it would be 12.2(53)SG1, 12.2(53)SG2 etc, with 12.2(53)GS2 being scheduled for the Q2CY10) Hope this gives you a better view. Arie On Tue, Jan 26, 2010 at 10:35 PM, Andrey Gordon andrey.gor...@gmail.comwrote: Hi List, Anyone recalls ever seeing the IOS naming convention document. In particular I'm interested in differences between families and trains. This is all I found: http://www.cisco.com/warp/public/620/1.html#topic1 But im looking for something a bit more recent maybe? Can figure out differences between say SG, SGA, EW and EWA. A link to the cipher would certainly help. - Andrey Gordon [andrey.gor...@gmail.com] -- Philip Davis Systems Administrator I-2000 Inc. (616) 532-8425 888-234-4254
Re: IOS family naming
Have you checked out the IOS Feature Navigator? http://tools.cisco.com/ITDIT/CFN/jsp/index.jsp On Tue, Jan 26, 2010 at 4:27 PM, Philip Davis pda...@i2k.com wrote: Not sure how relevant this still is, but it explains some of the older ones. http://www.cisco.com/en/US/products/sw/iosswrel/ps1818/products_tech_note09186a0080101cda.shtml On 1/26/2010 4:21 PM, Arie Vayner wrote: Andrey, I could not find a good link, but let me give you some info on SG, SGA, EW and EWA. All these trains are for the 4500 family (including 4900). They are just different generations. The EW (and then EWA) were the older trains for 4500, which were replaced by the SG trains. If I am not too wrong EW/EWA was new around 2004. SGA was the 1st release for the SG train, but later releases are not called SGB/SGC, but are just marked SG, so you get 12.2(31)SGA as the first release (with 12.2(31)SGA1, 12.2(31)SGA2 etc being maintenance releases, with SGA11 scheduled to be released in a few weeks). The later SG releases are numbered as 12.2(37)SG, 12.2(40)SG, etc - and we have 12.2(53)SG as the latest one. Each such release brings in new features, and has its own maintenance releases (so it would be 12.2(53)SG1, 12.2(53)SG2 etc, with 12.2(53)GS2 being scheduled for the Q2CY10) Hope this gives you a better view. Arie On Tue, Jan 26, 2010 at 10:35 PM, Andrey Gordon andrey.gor...@gmail.comwrote: Hi List, Anyone recalls ever seeing the IOS naming convention document. In particular I'm interested in differences between families and trains. This is all I found: http://www.cisco.com/warp/public/620/1.html#topic1 But im looking for something a bit more recent maybe? Can figure out differences between say SG, SGA, EW and EWA. A link to the cipher would certainly help. - Andrey Gordon [andrey.gor...@gmail.com] -- Philip Davis Systems Administrator I-2000 Inc. (616) 532-8425 888-234-4254 -- LITTLE GIRL: But which cookie will you eat FIRST? COOKIE MONSTER: Me think you have misconception of cookie-eating process.
Re: unreachable Sites
On Tue, Jan 26, 2010 at 11:08 AM, Reynold Guerrier rey...@gmail.com wrote: I have been notified this morning by several people that there is some websites that are unreachable from Haiti: http://www.hostcentric.com, http://www.gama.ht those are examples. It happens with different ISP. When we change th DNS using the google one 8.8.8.8 it's ok for some but some others still remain unreachable. Can some of you from the Nanog list check and advise? You could always use OpenDNS as an alternative, especially to debug a problem with the service. I don't know their resolver addresses off of the top of my head (sorry David), but I'm sure that it's easy to find them either here, https://store.opendns.com/get/basic or perhaps someone could email them to you offline. Best Regards, -M -- Martin Hannigan mar...@theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants
RE: Using /126 for IPv6 router links
On Mon, 25 Jan 2010, Matt Addison wrote: :: You're forgetting Matthew Petach's suggestion- reserve/assign a /64 for :: each PtP link, but only configure the first /126 (or whatever /126 you :: need to get an amusing peer address) on the link. Matt meant reserve/assign a /64 for each PtP link, but only configure the first */127* of the link, as that's the only way to fully mitigate the scanning-type attacks (with a /126, there is still the possibility of ping-pong on a p-t-p interface) w/o using extensive ACLs.. Anyways, that's what worked for us, and, as always, YMMV... -igor
Re: Using /126 for IPv6 router links
Igor Gashinsky wrote: On Mon, 25 Jan 2010, Matt Addison wrote: :: You're forgetting Matthew Petach's suggestion- reserve/assign a /64 for :: each PtP link, but only configure the first /126 (or whatever /126 you :: need to get an amusing peer address) on the link. Matt meant reserve/assign a /64 for each PtP link, but only configure the first */127* of the link, as that's the only way to fully mitigate the scanning-type attacks (with a /126, there is still the possibility of ping-pong on a p-t-p interface) w/o using extensive ACLs.. Anyways, that's what worked for us, and, as always, YMMV... As always, I'm looking for better ways to do things. I've been using /64 eui-64 on P-PE PtP Ethernet links (and /64 static on PE-CE) since I first delved into IPv6, as (for me) it makes hardware replacement/link relocation very easy, and documentation simple. ip address x.x.x.x 255.255.255.252 ipv6 address 2607:F118:x:x::/64 eui-64 ipv6 nd suppress-ra ipv6 ospf 1 area 0.0.0.0 I've found that this setup, in conjunction with iBGP peering between loopback /128's works well. I don't think I'm quite grasping the entire security concern here. Actually, I'd like to re-word that... I do grasp the attack vector to a certain degree, but there *must* be a way to use entire /64's on ptp links without having to use manual ACL management. Personally, I am all for using /64s for this purpose, as that's how I understand the intention of the protocol. Whether I use a complete /64 within a ptp (particularly Ethernet), or lob off a /127 (or /126) for the purpose, I'll always keep that entire /64 'specifically reserved for that purpose' either way. Would be interesting to hear ideas on how this particular /64 on ptp attack vector could be nullified by using existing known solutions. I'm thinking blackhole, but can't (at this time) think how that could be done by default with existing configuration within the scope of a ptp link. Steve
Re: Using /126 for IPv6 router links
On Tue, 26 Jan 2010 06:38:43 -0800 (PST)
David Barak thegame...@yahoo.com wrote:
From: Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org
Why can't IPv6 node addressing be as easy to understand and work with
as Ethernet addresses? They were designed in the early 1980s*. 28 years
or so years later, it's time for layer 3 addressing to catch up.
Becase Ethernet addresses are only locally significant, are not manually
assigned in the vast majority of cases,
That makes them globally significant - and that's what makes them
'plug-and-play'. Ethernet addresses are bigger than they operationally
need to be, and the 'plug-and-play' nature of them is what we got for
that price.
That being said, my comment is not specifically about how Ethernet
addressing works, it is about how easy Ethernet addressing is to use.
It was a rhetorical question.
I think it'd be a tragedy if IPv6 addressing is harder to work with
than than Ethernet, Appletalk, IPX and a number of other protocols
designed at least 10 years or more before it. I really don't understand
why people seem so keen on making IPv6 addressing's model look like
IPv4's when the primary reason for IPv4's addressing models was the
severe lack of address space.
btw, did you read the paper I linked too?
and changing a MAC by replacing a NIC has no bearing on the
configuration of a { server | router ACL | etc }.
Layer 3 addressing is globally significant, and the case we're discussing is
addresses which are human-assigned rather than automatically configured.
Link-local autoconfiguration in IPv6 works like a champ, and behaves pretty
much the way I would want it to. Global addressing approaches, on the other
hand, are highly optimized in directions which make them less flexible or
have surprising consequences (hence this thread).
David Barak
Need Geek Rock? Try The Franchise:
http://www.listentothefranchise.com
Re: Using /126 for IPv6 router links
On Tue, 26 Jan 2010 11:13:22 -0500 Tim Durack tdur...@gmail.com wrote: On Mon, Jan 25, 2010 at 11:06 PM, Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote: On Mon, 25 Jan 2010 15:15:55 -0500 TJ trej...@gmail.com wrote: I didn't realize human friendly was even a nominal design consideration, especially as different humans have different tolerances for defining friendly :) This from people who can probably do decimal to binary conversion and back again for IPv4 subnetting in their head and are proud of it. Surely IPv6 hex to binary and back again can be the new party trick? :-) Maybe we can all do this stuff in our head, but I have found removing unnecessary thinking from the equation is useful for those 3am moments. Given that I am assigning a /48 to a site anyway, and 65k /64s is more than I will ever need, does it really matter if the site-specific numbering plan isn't ruthlessly efficient? The general intent of the /48 allocation is that it is large enough for nearly everybody, with nearly everybody including all but the largest of organisations. IOW, it's meant to be nearly one-size-fits-all, to try to ensure almost everybody gets as much address space as they'll ever need at the time of their first request. An addressing plan for anything less than the largest organsation that doesn't fit within a /48 or will exceed it fairly rapidly is probably too inefficent. ps. Remember that I'm one of the ones advocating using /64s everywhere, so what ever you do, don't use ruthlessly efficient to describe my position - use that for the /126 or /127 crowd ;-) Regards, Mark.
Re: Using /126 for IPv6 router links
On Tue, Jan 26, 2010 at 11:53 PM, Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote: The general intent of the /48 allocation is that it is large enough for nearly everybody, with nearly everybody including all but the largest 'nearly everybody with a single site' sure. I know of more than a few VPN deployments (enterprises with remote offices) that have +1k remote sites. For these you're quickly talking about: 1) get PA (maybe, maybe not a good plan, see renumbering headaches) 2) get a large number of /48's (assume median size is 2048 - 1 /36) I know of one vpn deployment with +12k sites: a /34 I agree that a large majority of 'end sites' (enterprises) will be services with a single /48 from PA space, unless they want to multihome, or have more than 1 site and want some convenience. of organisations. IOW, it's meant to be nearly one-size-fits-all, to try to ensure almost everybody gets as much address space as they'll ever need at the time of their first request. An addressing plan for anything less than the largest organsation that doesn't fit within a /48 or will exceed it fairly rapidly is probably too inefficent. ps. Remember that I'm one of the ones advocating using /64s everywhere, so what ever you do, don't use ruthlessly efficient to describe my position - use that for the /126 or /127 crowd ;-) I'd note I'm not a 'ruthless efficiency' guy either, just 'how ops is done today' and 'there be dragons, be aware what you step into'. I think, and I'll start a fresh copy of this thread to articulate it, there have been 4-5 different issue conflated in this discussion, which is making things complicated. -Chris Regards, Mark.
Re: Using /126 for IPv6 router links
On Wed, 27 Jan 2010 00:11:41 -0500 Christopher Morrow morrowc.li...@gmail.com wrote: On Tue, Jan 26, 2010 at 11:53 PM, Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote: The general intent of the /48 allocation is that it is large enough for nearly everybody, with nearly everybody including all but the largest 'nearly everybody with a single site' sure. I know of more than a few VPN deployments (enterprises with remote offices) that have +1k remote sites. For these you're quickly talking about: 1) get PA (maybe, maybe not a good plan, see renumbering headaches) 2) get a large number of /48's (assume median size is 2048 - 1 /36) I know of one vpn deployment with +12k sites: a /34 If it's in the US, I might have worked on the product that was used to build it about 10 years ago - that had 10K sites. I agree that a large majority of 'end sites' (enterprises) will be services with a single /48 from PA space, unless they want to multihome, or have more than 1 site and want some convenience. A 'site' is intended to not specifically be geographic. In some respects, it's meant to be a more generic version of IPv4's Autonomous System. A geographic location might suit the boundary in some cases, where as a single large organisation, who may have many internal geographic sites in it's WAN, dual homed to a single ISP, would also qualify as a single /48 site. of organisations. IOW, it's meant to be nearly one-size-fits-all, to try to ensure almost everybody gets as much address space as they'll ever need at the time of their first request. An addressing plan for anything less than the largest organsation that doesn't fit within a /48 or will exceed it fairly rapidly is probably too inefficent. ps. Remember that I'm one of the ones advocating using /64s everywhere, so what ever you do, don't use ruthlessly efficient to describe my position - use that for the /126 or /127 crowd ;-) I'd note I'm not a 'ruthless efficiency' guy either, just 'how ops is done today' and 'there be dragons, be aware what you step into'. Sure. However I think people are treating IPv6 as just IPv4 with larger addresses, yet not even thinking about what capabilities that larger addressing is giving them that don't or haven't existed in IPv4 for a very long time. People seem to be even ignoring the maths of how big a single /48 is, just in terms subnets. I've never worked on an individual network with 65K subnets (with the Internet being a network of networks), and I doubt many people on this list have. Yet people seem to treating a /48 as though all networks will have 65K subnets, and therefore they'd better start of using longer than /64s because they might run out of subnets. I care about this because I don't want to see people have to change their addressing in the future to /64s, because of that will typically involve a lot of out of hours work (which could include me if I inherit a network that has had longer than /64s deployed (there's my bias)). I'd prefer to see people go the other way - deploy /64s everywhere, as per the IPv6 Addressing Architecture, and if that proves to be the wrong case, then go to the effort of deploying longer prefixes. I think going from /64s to longer prefixes is far less likely going to be needed than the other way around. I think, and I'll start a fresh copy of this thread to articulate it, there have been 4-5 different issue conflated in this discussion, which is making things complicated. -Chris Regards, Mark.
RE: Using /126 for IPv6 router links
On Tue, 26 Jan 2010, Igor Gashinsky wrote: Matt meant reserve/assign a /64 for each PtP link, but only configure the first */127* of the link, as that's the only way to fully mitigate the scanning-type attacks (with a /126, there is still the possibility of ping-pong on a p-t-p interface) w/o using extensive ACLs.. Anyways, that's what worked for us, and, as always, YMMV... That's still relying on the fact that your vendor won't implement subnet-router anycast address and turn it on by default. That would mess up the first address of the link. But I suppose those would be pretty big ifs. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: Using /126 for IPv6 router links
In message 20100127160401.1a963...@opy.nosense.org, Mark Smith writes: Sure. However I think people are treating IPv6 as just IPv4 with larger addresses, yet not even thinking about what capabilities that larger addressing is giving them that don't or haven't existed in IPv4 for a very long time. People seem to be even ignoring the maths of how big a single /48 is, just in terms subnets. I've never worked on an individual network with 65K subnets (with the Internet being a network of networks), and I doubt many people on this list have. Yet people seem to treating a /48 as though all networks will have 65K subnets, and therefore they'd better start of using longer than /64s because they might run out of subnets. I care about this because I don't want to see people have to change their addressing in the future to /64s, because of that will typically involve a lot of out of hours work (which could include me if I inherit a network that has had longer than /64s deployed (there's my bias)). I'd prefer to see people go the other way - deploy /64s everywhere, as per the IPv6 Addressing Architecture, and if that proves to be the wrong case, then go to the effort of deploying longer prefixes. I think going from /64s to longer prefixes is far less likely going to be needed than the other way around. And if you have more than 65K networks you have the justification for a second /48 at which time you can decide whether to request a /47 and renumber into it or just use two non-contiguous /48's. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Ethernet Services cards types queue values
Hello, There is different types for the Cisco 7600 Series Ethernet Services cards. ( More expensive cards with high queue values and less expensive cards with low queue values.) http://www.cisco.com/en/US/prod/collateral/routers/ps368/data_sheet_c78-549419.html Hardware queues ES Plus XT 40G line cards • 128,000 ingress queues • 256,000 egress queues ES Plus XT 20G line cards *• 64,000 ingress queues* • 128,000 egress queues Hierarchical QoS (H-QoS) http://www.cisco.com/en/US/prod/collateral/routers/ps368/data_sheet_c78-570730.html Hardware queues Cisco 7600 Series ES Plus Transport 40G and 20G Line Cards *Supporting up to 16 level 4 queues per physical port* Hierarchical QoS (H-QoS) Low queue cards have got only 4 queues per physical port. High queue cards have got minimum 64.000 queue. This is very huge difference. In what kind of scenario do we have to use the High queue cards ? Could you give some examples please ? Kind Regards. Burak
Re: Using /126 for IPv6 router links
On Wed, 27 Jan 2010 07:47:35 +0200 (EET) Pekka Savola pek...@netcore.fi wrote: On Tue, 26 Jan 2010, Igor Gashinsky wrote: Matt meant reserve/assign a /64 for each PtP link, but only configure the first */127* of the link, as that's the only way to fully mitigate the scanning-type attacks (with a /126, there is still the possibility of ping-pong on a p-t-p interface) w/o using extensive ACLs.. Anyways, that's what worked for us, and, as always, YMMV... That's still relying on the fact that your vendor won't implement subnet-router anycast address and turn it on by default. That would mess up the first address of the link. But I suppose those would be pretty big ifs. A minor data point to this, Linux looks to be implementing the subnet-router anycast address when IPv6 forwarding is enabled, as it's specifying Solicited-Node multicast address membership for the all zeros node address in it's MLD announcements when an interface comes up. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
