What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.
Hi, I am hoping for a bit of advice. We are rolling out IPv6 en mass now to peers and I am finding that our strict IPv6 ingress prefix filter is meaning a lot of peers are sending me zero prefixes. Upon investigation I determine they have de-agregrated their /32 for routing reasons / non interconnected islands of address space and in consequence advertise no covering /32 route. The RIR block that the allocation is from is meant to have a minimum assignment of /32. From: http://www.space.net/~gert/RIPE/ipv6-filters.html We get: ipv6 prefix-list ipv6-ebgp-strict deny 3ffe::/16 le 128 ipv6 prefix-list ipv6-ebgp-strict permit 2001:500::/30 ge 48 le 48 ipv6 prefix-list ipv6-ebgp-strict deny 2001:db8::/32 le 128 ipv6 prefix-list ipv6-ebgp-strict permit 2001::/32 ipv6 prefix-list ipv6-ebgp-strict permit 2001::/16 ge 35 le 35 ipv6 prefix-list ipv6-ebgp-strict permit 2001::/16 ge 19 le 32 ipv6 prefix-list ipv6-ebgp-strict permit 2001:0678::/29 le 48 ipv6 prefix-list ipv6-ebgp-strict permit 2001:0c00::/23 ge 48 le 48 ipv6 prefix-list ipv6-ebgp-strict permit 2001:13c7:6000::/36 le 48 ipv6 prefix-list ipv6-ebgp-strict permit 2001:13c7:7000::/36 le 48 ipv6 prefix-list ipv6-ebgp-strict permit 2001:43f8::/29 ge 40 le 48 ipv6 prefix-list ipv6-ebgp-strict permit 2002::/16 ipv6 prefix-list ipv6-ebgp-strict permit 2003::/16 ge 19 le 32 ipv6 prefix-list ipv6-ebgp-strict permit 2400::/12 ge 19 le 32 ipv6 prefix-list ipv6-ebgp-strict permit 2600::/12 ge 19 le 32 ipv6 prefix-list ipv6-ebgp-strict permit 2610::/23 ge 24 le 32 ipv6 prefix-list ipv6-ebgp-strict permit 2620::/23 ge 40 le 48 ipv6 prefix-list ipv6-ebgp-strict permit 2800::/12 ge 19 le 32 ipv6 prefix-list ipv6-ebgp-strict permit 2a00::/12 ge 19 le 32 ipv6 prefix-list ipv6-ebgp-strict permit 2801:::/24 le 48 ipv6 prefix-list ipv6-ebgp-strict permit 2c00::/12 ge 19 le 32 ipv6 prefix-list ipv6-ebgp-strict deny 0::/0 le 128 I have peers in 2a00::/12 that are advertising me /48s without the /32 assigned to them. While this has been a problem in IPv4 land in the past with some people de-aggregating a /19 to regional /24s with no covering route because of no backbone. What should we be doing in IPv6 land as I suspect this may become a bigger problem than it ever was in IPv4. I can adopt the view, well you should, so I'm going to filter, and they can say well that's not practical, we have a /32 and we advertise a /48 at each individual internet exchange. RIRs policy wont allocate us a lot of separate /48s from an appropriate block. Aggregation argues you shouldn't de-aggregate. We might as well start off as we mean to go along and try not to pollute the v6 route table with all the rubbish that is in the v4 one. So what is the best answer. 1 Don't advertise islands of space under assignment minimum, without providing a covering aggregate route? 2 Don't use strict filters, they don't work well and de-agragegation with IPv6 is going to be a problem? 3 Don't use filters, generate it from an IRR? Given there is no right answer what is considered to be the best fit one? Kind Regards Ben
Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.
On Wed, Nov 14, 2012 at 6:40 PM, Ben S. Butler ben.but...@c2internet.netwrote: 3 Don't use filters, generate it from an IRR? Given there is no right answer what is considered to be the best fit one? This sounds like your best bet. Assuming you can find an IRR with comprehensive enough coverage. The other option is of course don't filter based solely on RIR minimum assignments .. I know at least some ISPs (like swisscom) do this for v4 too, but that simply means people who try to multihome with anything less than a /19 in level3 land aren't going to succeed. http://v-authoring.ip-plus.net/documents/BIS_TI_Router_Filter_Policy_EN.pdf ip prefix-list martians seq 8000 permit 8.0.0.0/7 le 19 [etc] Not so much of a problem in v4 but as you saw for yourself, you risk not seeing prefixes at all if you try this. -- Suresh Ramasubramanian (ops.li...@gmail.com)
RE: Eaton 9130 UPS feedback
I've had issues and experience with many types of UPSes, including HP (probably OEM'd from someone else), APC, EATON/Powerware, and Liebert/Emerson. I keep coming back to APC. Solid units, and are always slightly 'ahead' in technology. Sure, I've seen each model have failures and even faults (big boom style), but APC provides a solid product and supports their customers the best if you ask me. That being said, a very close second choice would be EATON/Powerware. - Erik -Original Message- From: Seth Mattinen [mailto:se...@rollernet.us] Sent: Tuesday, November 13, 2012 1:59 PM To: nanog@nanog.org Subject: Eaton 9130 UPS feedback Does anyone use Eaton 9130 series UPS for anything? I'm curious how they've worked out for you. I bought a 700VA model to give it a whirl versus the traditional APC since the Eaton is an online type with static bypass and also does some high efficiency thing where it normally stays on bypass, but the first thing it did on the bench was have the inverter/rectifier or bypass section catch on fire and destroy itself. ~Seth
RE: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.
Hi, Yes, but a multi-homing customer would have PI space from an appropriately filtered block allowing /24 PI v4 or /48 PI v6. An ISP would have their own RIR PA allocation /22 to /19 v4 or /29, /32 v6 block that are from blocks that follow along the lines of minimum assignment size for that block. This is not a problem created by the registries or by the filters. The problem comes with ASes that don’t have a backbone interconnecting all of their POPs / islands and are therefore unable to add a covering route and do not provide a route via any transit provide for the whole ip block at the RIR minimum boundary. In some ways whether people should: 1 Have a network of none interconnected islands that take IP space from the same IP block below RIR minimum? 2 Should we filter these networks? 3 Should the /32 be visible in the route table somewhere if the intention that component /48s are going to be visible on the Internet. I don’t like the IRR answer particularly as it requires a level of third party trust that I am not entirely comfortable with, nor configuring separate filters for each BGP peering session. Ben From: Suresh Ramasubramanian [mailto:ops.li...@gmail.com] Sent: 14 November 2012 13:25 To: Ben S. Butler Cc: NANOG Subject: Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums. On Wed, Nov 14, 2012 at 6:40 PM, Ben S. Butler ben.but...@c2internet.netmailto:ben.but...@c2internet.net wrote: 3 Don't use filters, generate it from an IRR? Given there is no right answer what is considered to be the best fit one? This sounds like your best bet. Assuming you can find an IRR with comprehensive enough coverage. The other option is of course don't filter based solely on RIR minimum assignments .. I know at least some ISPs (like swisscom) do this for v4 too, but that simply means people who try to multihome with anything less than a /19 in level3 land aren't going to succeed. http://v-authoring.ip-plus.net/documents/BIS_TI_Router_Filter_Policy_EN.pdf ip prefix-list martians seq 8000 permit 8.0.0.0/7http://8.0.0.0/7 le 19 [etc] Not so much of a problem in v4 but as you saw for yourself, you risk not seeing prefixes at all if you try this. -- Suresh Ramasubramanian (ops.li...@gmail.commailto:ops.li...@gmail.com)
Re: Eaton 9130 UPS feedback
Are these UPS units going inside the racks? Would it not be better to do something in the power room with an inverter on the circuits that feed the racks, such as a large Outback unit with sufficient battery capacity? http://www.amazon.com/OutBack-Inverter-3600-Watts-Volt/dp/B002MWAAYU With one device acting as your UPS you'd have only one point of failure (that may be a plus or minus), only one set of batteries to worry about, and those inverters are very well made. They have 120v and 240v units. There are other brands you could use but my experience with various brands is that Outback is the best in their class. Greg On Wed, Nov 14, 2012 at 8:38 AM, Erik Amundson erik.amund...@oati.netwrote: I've had issues and experience with many types of UPSes, including HP (probably OEM'd from someone else), APC, EATON/Powerware, and Liebert/Emerson. I keep coming back to APC. Solid units, and are always slightly 'ahead' in technology. Sure, I've seen each model have failures and even faults (big boom style), but APC provides a solid product and supports their customers the best if you ask me. That being said, a very close second choice would be EATON/Powerware. - Erik -Original Message- From: Seth Mattinen [mailto:se...@rollernet.us] Sent: Tuesday, November 13, 2012 1:59 PM To: nanog@nanog.org Subject: Eaton 9130 UPS feedback Does anyone use Eaton 9130 series UPS for anything? I'm curious how they've worked out for you. I bought a 700VA model to give it a whirl versus the traditional APC since the Eaton is an online type with static bypass and also does some high efficiency thing where it normally stays on bypass, but the first thing it did on the bench was have the inverter/rectifier or bypass section catch on fire and destroy itself. ~Seth
Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.
On Wed, Nov 14, 2012 at 8:10 AM, Ben S. Butler ben.but...@c2internet.net wrote: So what is the best answer. 1 Don't advertise islands of space under assignment minimum, without providing a covering aggregate route? 2 Don't use strict filters, they don't work well and de-agragegation with IPv6 is going to be a problem? 3 Don't use filters, generate it from an IRR? Given there is no right answer what is considered to be the best fit one? IMHO: 4) Use mild filters (e.g. allow a /32 to be disaggregated to /36's) and send a polite email to the POC to the effect of, Please beware that because you have not offered a covering route matching your allocation, your IPv6 network is not reachable from ours. IPv6 is not IPv4: end users requiring /48s for multihoming should get them directly from the RIR. For complete Internet connectivity, we strongly encourage you to offer a covering route. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.
On 11/14/2012 6:02 PM, William Herrin wrote: and send a polite email to the POC to the effect of, Please beware that because you have not offered a covering route matching your allocation, your IPv6 network is not reachable from ours. IPv6 is not IPv4: end users requiring /48s for multihoming should get them directly from the RIR. For complete Internet connectivity, we strongly encourage you to offer a covering route. like that. Frank
RE: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.
Hi, Yes, nice. But... It does not address the case when this is not the ISPs customers but the ISP (read content provider) that operates globally but without a network interconnecting their routers. They then advertise a /24 v4 and /48 v6 at each Internet exchange that they are connected to. That is fine for driving router. The problem with this design is that they cant announce their /32 as they are not running a iBGP mesh. I have seen a number of content providers doing this by design, and in the context of their business I can understand why and see it makes some sense. The only problem comes with the prefixes ending up under the minimum prefix size for the block they are in. Now when this is a large content provider and we all want the peering, then we relax the filters, fine, but why one rule for them and another for everyone else in the same /12 block. Would it not make sense for the RIRs to assign a /12 as issuable in /32, /29 to content providers who will specifically deagregate to /48 with no internal network. That solves the filtering problem, doesn't force these networks to put an iBGP network in place and lets everyone who does run a network properly to announce the proper aggregate blocks / covering routes with more specifics if we have to have them for routing purposes. A separate /12 for the island type networks would immediately make this problem disappear. Am I being overly simplistic? Ben -Original Message- From: Frank Habicht [mailto:ge...@geier.ne.tz] Sent: 14 November 2012 16:56 To: nanog@nanog.org Subject: Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums. On 11/14/2012 6:02 PM, William Herrin wrote: and send a polite email to the POC to the effect of, Please beware that because you have not offered a covering route matching your allocation, your IPv6 network is not reachable from ours. IPv6 is not IPv4: end users requiring /48s for multihoming should get them directly from the RIR. For complete Internet connectivity, we strongly encourage you to offer a covering route. like that. Frank
Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.
On 11/14/2012 8:08 PM, Ben S. Butler wrote: Hi, Yes, nice. But... It does not address the case when this is not the ISPs customers but the ISP (read content provider) that operates globally but without a network interconnecting their routers. They then advertise a /24 v4 and /48 v6 at each Internet exchange that they are connected to. That is fine for driving router. The problem with this design is that they cant announce their /32 as they are not running a iBGP mesh. I have seen a number of content providers doing this by design, and in the context of their business I can understand why and see it makes some sense. The only problem comes with the prefixes ending up under the minimum prefix size for the block they are in. Yep. Ack. For the filtering policies it'd be nice to use space from a special prefix - like for PI assignments. But that will drive global routing table size :-( But that's what content providers who create islands are bound to do - or is there a way around without real connectivity or tunnels? And the polluters apparently don't have enough incentives or pain to void islands... Frank Now when this is a large content provider and we all want the peering, then we relax the filters, fine, but why one rule for them and another for everyone else in the same /12 block. Would it not make sense for the RIRs to assign a /12 as issuable in /32, /29 to content providers who will specifically deagregate to /48 with no internal network. That solves the filtering problem, doesn't force these networks to put an iBGP network in place and lets everyone who does run a network properly to announce the proper aggregate blocks / covering routes with more specifics if we have to have them for routing purposes. A separate /12 for the island type networks would immediately make this problem disappear. Am I being overly simplistic? Ben -Original Message- From: Frank Habicht [mailto:ge...@geier.ne.tz] Sent: 14 November 2012 16:56 To: nanog@nanog.org Subject: Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums. On 11/14/2012 6:02 PM, William Herrin wrote: and send a polite email to the POC to the effect of, Please beware that because you have not offered a covering route matching your allocation, your IPv6 network is not reachable from ours. IPv6 is not IPv4: end users requiring /48s for multihoming should get them directly from the RIR. For complete Internet connectivity, we strongly encourage you to offer a covering route. like that. Frank
DHCPv6 and MAC addresses
Saw yet another attempt at a solution pop up to try and deal with the lack of a MAC address in DHCPv6 messages. I've been giving this some thought about how this should be best accomplished without requiring that host implementations of DHCPv6 be modified. Taking advantage of the relay-agent seems to be the most elegant solution: 1) Any DHCPv6 server on a local segment will already have access to the MAC address; but having a DHCPv6 server on each segment is not ideal. 2) Requests that are relayed flow through a relay-agent, which is on a device that also has access to the MAC address of the client system. Option A: RFC 6422 provides for Realy-Supplied DHCP Options, currently with one option code registered with IANA (OPTION_ERP_LOCAL_DOMAIN_NAME). You can see the list here: http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml I think the quickest solution would be: 1) Adding an RSOO for the client MAC address 2) Get vendors on board to draft and adopt a standard for it on routers, 3) Modify DHCPv6 servers to have support for MAC identification based on the MAC of the local request OR the MAC of the relayed request when the option is present. Option B: The current RELAY-FORW message already includes the link-local address of the client. Perhaps there should be a modification to the privacy extensions RFC to forbid the use of privacy addressing on the link-local scope; at this point we could modify DHCPv6 servers to be able to determine the MAC address for relayed requests based on their link-local address. Unfortunately, the cat is out of the bag on this one, so it would take time to get host implementations modified. I might be overlooking something critical... thoughts? -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net
Re: dhcpy6d - a MAC address aware DHCPv6 server
FWIW ISC DHCPd listens on raw sockets. On Tue, Nov 6, 2012 at 11:12 AM, George Herbert george.herb...@gmail.com wrote: Oh, horrors, part of my infrastructure needs raw socket data? We should ban that, for security. Who needs those pesky switches anyways? George William Herbert Sent from my iPhone On Nov 6, 2012, at 5:49 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote: On Tue, Nov 06, 2012 at 05:38:32AM -0800, Owen DeLong o...@delong.com wrote a message of 68 lines which said: If you're on local subnet, why not pull the MAC address out of the received packet? Because it requires access to raw sockets, which should not be necessary for DHCP? -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net
Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.
In a message written on Wed, Nov 14, 2012 at 01:10:57PM +, Ben S. Butler wrote: I am hoping for a bit of advice. We are rolling out IPv6 en mass now to peers and I am finding that our strict IPv6 ingress prefix filter is meaning a lot of peers are sending me zero prefixes. Upon investigation I determine they have de-agregrated their /32 for routing reasons / non interconnected islands of address space and in consequence advertise no covering /32 route. The RIR block that the allocation is from is meant to have a minimum assignment of /32. You are conflating two different issues, which are essentially toally unrelated. There is the smallest size block an RIR will allocate out of some chuck of address space, and then there is how people announce it on the Internet. In the real world they have almost nothing to do with each other, something folks understand today in IPv4 but seem to think IPv6 magically fixes, it doesn't. [Historically there were folks who maintained filters on IPv4 space, but they gradually disappeared as the filters became so long they were unmaintinable, and people discovered when your job is to connect people throwing away routes is a bad thing.] For instance, there are folks who could use the multiple discrete networks policy to get a /48 for each of their 5 sites. But instead they get on /32, use a /48 at each site, and announce them independantly. Same prefixes in the table, but filtering on the RIR /32 boundry means you won't hear them. I'll point out it's not just longer, but shorter prefixes as well: ipv6 prefix-list ipv6-ebgp-strict permit 2001:500::/30 ge 48 le 48 F-Root announces 2001:4f8:500:2e::/47. You're going to miss it. There are other servers in this block that are in /47's or /46's. If connectivity is what you value, here's the right filter: ipv6 prefix-list ipv6-ebgp-permissive 2001::/12 ge 13 le 48 Yes, the DOD has a /13, and yes, people expect to be able to announce down to a /48. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpMoWNXRMIDy.pgp Description: PGP signature
Re: DHCPv6 and MAC addresses
What about http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-03 ? -- Tim On 14 Nov 2012, at 17:46, Ray Soucy r...@maine.edu wrote: Saw yet another attempt at a solution pop up to try and deal with the lack of a MAC address in DHCPv6 messages. I've been giving this some thought about how this should be best accomplished without requiring that host implementations of DHCPv6 be modified. Taking advantage of the relay-agent seems to be the most elegant solution: 1) Any DHCPv6 server on a local segment will already have access to the MAC address; but having a DHCPv6 server on each segment is not ideal. 2) Requests that are relayed flow through a relay-agent, which is on a device that also has access to the MAC address of the client system. Option A: RFC 6422 provides for Realy-Supplied DHCP Options, currently with one option code registered with IANA (OPTION_ERP_LOCAL_DOMAIN_NAME). You can see the list here: http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml I think the quickest solution would be: 1) Adding an RSOO for the client MAC address 2) Get vendors on board to draft and adopt a standard for it on routers, 3) Modify DHCPv6 servers to have support for MAC identification based on the MAC of the local request OR the MAC of the relayed request when the option is present. Option B: The current RELAY-FORW message already includes the link-local address of the client. Perhaps there should be a modification to the privacy extensions RFC to forbid the use of privacy addressing on the link-local scope; at this point we could modify DHCPv6 servers to be able to determine the MAC address for relayed requests based on their link-local address. Unfortunately, the cat is out of the bag on this one, so it would take time to get host implementations modified. I might be overlooking something critical... thoughts? -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net
Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.
On Wed, Nov 14, 2012 at 12:08 PM, Ben S. Butler ben.but...@c2internet.net wrote: Yes, nice. But... It does not address the case when this is not the ISPs customers but the ISP (read content provider) that operates globally but without a network interconnecting their routers. Hi Ben, That case is covered by things like ARIN's multiple discrete networks policy which permit an ISP /32 or end-user /48 for _each_ distinct network. There are plenty of addresses in IPv6. You should be break up a /32 for traffic engineering purposes, not for the sake of handling multiple disconnected sites. And when exercising TE, you can offer a covering route and expect the network as a whole to still function regardless of other folks' suballocation filtering. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: DHCPv6 and MAC addresses
Well I guess someone is already working on it, +1 Since this is a relay-only message, though. I think it would be better as a sub-option of RFC 6422 with a requirement that relay-agents drop the option if the client tries to source it. But, I guess it's splitting hairs. On Wed, Nov 14, 2012 at 1:02 PM, Tim Chown t...@ecs.soton.ac.uk wrote: What about http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-03 ? -- Tim On 14 Nov 2012, at 17:46, Ray Soucy r...@maine.edu wrote: Saw yet another attempt at a solution pop up to try and deal with the lack of a MAC address in DHCPv6 messages. I've been giving this some thought about how this should be best accomplished without requiring that host implementations of DHCPv6 be modified. Taking advantage of the relay-agent seems to be the most elegant solution: 1) Any DHCPv6 server on a local segment will already have access to the MAC address; but having a DHCPv6 server on each segment is not ideal. 2) Requests that are relayed flow through a relay-agent, which is on a device that also has access to the MAC address of the client system. Option A: RFC 6422 provides for Realy-Supplied DHCP Options, currently with one option code registered with IANA (OPTION_ERP_LOCAL_DOMAIN_NAME). You can see the list here: http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml I think the quickest solution would be: 1) Adding an RSOO for the client MAC address 2) Get vendors on board to draft and adopt a standard for it on routers, 3) Modify DHCPv6 servers to have support for MAC identification based on the MAC of the local request OR the MAC of the relayed request when the option is present. Option B: The current RELAY-FORW message already includes the link-local address of the client. Perhaps there should be a modification to the privacy extensions RFC to forbid the use of privacy addressing on the link-local scope; at this point we could modify DHCPv6 servers to be able to determine the MAC address for relayed requests based on their link-local address. Unfortunately, the cat is out of the bag on this one, so it would take time to get host implementations modified. I might be overlooking something critical... thoughts? -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net
Ethernet NID plus POE+ (802.3at)... or POE+ injector with OAM...
Hi everyone, I'm looking for a gigabit ethernet media converter to go from SFP plugable optics to 802.3at POE+. The application involves wireless access points some distance from a central switch for a venue. Difficulty: in my old age, I've become allergic to installing completely unmanaged bump-in-the-wire devices that can't be monitored in some way. They make for a big nuisance when it comes time to debug the installation. The metro ethernet folks have brought us 802.1ag, 802.3ah, and Y.1731. Even the simplest of these - .1ag L2 ping (LBM/LBR) - is sufficient for my purposes of making sure that we're bidirectionally passing traffic. I'm aware of pluggable optics that do OAM (OEsolution Smart SFP) as well as some piggyback devices from other sources. I'd like to find a single box though that will do my media conversion, POE+ injection, and response to OAM packets all in one convenient tiny enclosure. Bonus points for well-thought-out details such as DIN rail mounting capability and cable retention tricks. Anyone got any pointers? -f
Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.
On Nov 14, 2012, at 10:06 AM, William Herrin b...@herrin.us wrote: On Wed, Nov 14, 2012 at 12:08 PM, Ben S. Butler ben.but...@c2internet.net wrote: Yes, nice. But... It does not address the case when this is not the ISPs customers but the ISP (read content provider) that operates globally but without a network interconnecting their routers. Hi Ben, That case is covered by things like ARIN's multiple discrete networks policy which permit an ISP /32 or end-user /48 for _each_ distinct network. There are plenty of addresses in IPv6. You should be break up a /32 for traffic engineering purposes, not for the sake of handling multiple disconnected sites. And when exercising TE, you can offer a covering route and expect the network as a whole to still function regardless of other folks' suballocation filtering. Regards, Bill Herrin I guess I'm confused. I have a /32 that I have broken up into /47's for my discrete POP locations. I don't have a network between them, by design. And, I won't announce the /32 covering route because there is no single POP that can take requests for the entire /32 - think regionalized anycast. So, how is it worse to announce the deaggregated /47's versus getting a /32 for every POP? In either case, I'm going to put the same number of routes into the DFZ. Mike
Re: Ethernet NID plus POE+ (802.3at)... or POE+ injector with OAM...
On Wed, 14 Nov 2012 14:57:06 -0500, Robert E. Seastrom r...@seastrom.com wrote: Hi everyone, I'm looking for a gigabit ethernet media converter to go from SFP plugable optics to 802.3at POE+. The application involves wireless access points some distance from a central switch for a venue. Difficulty: in my old age, I've become allergic to installing completely unmanaged bump-in-the-wire devices that can't be monitored in some way. They make for a big nuisance when it comes time to debug the installation. The metro ethernet folks have brought us 802.1ag, 802.3ah, and Y.1731. Even the simplest of these - .1ag L2 ping (LBM/LBR) - is sufficient for my purposes of making sure that we're bidirectionally passing traffic. I'm aware of pluggable optics that do OAM (OEsolution Smart SFP) as well as some piggyback devices from other sources. I'd like to find a single box though that will do my media conversion, POE+ injection, and response to OAM packets all in one convenient tiny enclosure. Bonus points for well-thought-out details such as DIN rail mounting capability and cable retention tricks. Anyone got any pointers? -f You'll probably have better luck looking for a switch. http://www.transition.com/TransitionNetworks/Products2/Family.aspx?Name=SISPM1040-384-LRT -scott
Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.
On Wed, Nov 14, 2012 at 3:10 PM, Michael Smith mksm...@mac.com wrote: I guess I'm confused. I have a /32 that I have broken up into /47's for my discrete POP locations. I don't have a network between them, by design. And, I won't announce the /32 covering route because there is no single POP that can take requests for the entire /32 - think regionalized anycast. So, how is it worse to announce the deaggregated /47's versus getting a /32 for every POP? In either case, I'm going to put the same number of routes into the DFZ. Hi Michael, If you announce an ISP /32 from each POP (or an end-user /48, /47, etc) then I know that a neutral third party has vetted your proposed network configuration and confirmed that the routes are disaggregated because the network architecture requires it. If you announce a /47 from your ISP space, for all I know you're trying to tweak utilization on your ISP uplinks. In the former case, the protocols are capable of what they're capable of. Discrete multihomed network, discrete announcement. Like it or lump it. In the latter case, I don't particularly need to burn resources on my router half a world away to facilitate your traffic tweaking. Let the ISPs you're paying for the privilege carry your more-specifics. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: authority to route?
On 2012-11-12, at 14:43, Jim Mercer j...@reptiles.org wrote: Is there a common practice of providers to vet / validate requests to advertise blocks? Yes, most providers whose customers request a particular route to be pointed towards them will ask for ambiguous instructions, written on letterhead with crayon, and signed illegibly by someone who may or may not have authority to do so but who in any case cannot be identified clearly by their scrawl. Ideally the letterhead should be crudely constructed in photoshop and then faxed across a noisy analogue line. Once you have one of those babies in your file, no lawyer can touch you. Joe
Re: authority to route?
On 11/14/12 2:40 PM, Joe Abley wrote: On 2012-11-12, at 14:43, Jim Mercer j...@reptiles.org wrote: Is there a common practice of providers to vet / validate requests to advertise blocks? Yes, most providers whose customers request a particular route to be pointed towards them will ask for ambiguous instructions, written on letterhead with crayon, and signed illegibly by someone who may or may not have authority to do so but who in any case cannot be identified clearly by their scrawl. Some providers ask for route objects and appropriate import/export policy in RADB. that fandamently no higher quality an attestation than a LOA but it's a lot easier to read. Ideally the letterhead should be crudely constructed in photoshop and then faxed across a noisy analogue line. Once you have one of those babies in your file, no lawyer can touch you. Joe
Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.
On Nov 14, 2012, at 1:50 PM, William Herrin b...@herrin.us wrote: On Wed, Nov 14, 2012 at 3:10 PM, Michael Smith mksm...@mac.com wrote: I guess I'm confused. I have a /32 that I have broken up into /47's for my discrete POP locations. I don't have a network between them, by design. And, I won't announce the /32 covering route because there is no single POP that can take requests for the entire /32 - think regionalized anycast. So, how is it worse to announce the deaggregated /47's versus getting a /32 for every POP? In either case, I'm going to put the same number of routes into the DFZ. Hi Michael, If you announce an ISP /32 from each POP (or an end-user /48, /47, etc) then I know that a neutral third party has vetted your proposed network configuration and confirmed that the routes are disaggregated because the network architecture requires it. If you announce a /47 from your ISP space, for all I know you're trying to tweak utilization on your ISP uplinks. Again, I thought the discussion was about PI, not PA. I don't announce any PA. In the former case, the protocols are capable of what they're capable of. Discrete multihomed network, discrete announcement. Like it or lump it. In the latter case, I don't particularly need to burn resources on my router half a world away to facilitate your traffic tweaking. Let the ISPs you're paying for the privilege carry your more-specifics. You have great confidence in the immutability of design and the description thereof. Mike
RE: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.
Hi, Again, I thought the discussion was about PI, not PA. I don't announce any PA. My point, which I feel may be getting lost, and for which ARIN may already have policies in place for, is that an IP assignment is made out of a block with a defined minimum assignment size. Now some people simply advertise the assignment that is made to them, some people chose to advertise more specifics with a covering route, I have no problem with any of this. What I am saying, is if people chose to deagregate to create islands, for which I can completely understand the commercial and networking reason and why it is then by extension impossible for them to advertise the covering route. Then in these specific cases of islands then these assignments should be made by the RIR from a block with a minimum prefix size of a /48. Then the application is submitted to the RIR it will justify as much space as it justifies, but at this point it should also be established - without any judgment positive or negative - if the intention is to advertise this unagregated or with a route for the aggregate. The RIR would then be empowered to assign the requested amount of address space from a block which can be labelled with a lower minimum prefix size. I am not judging any of these design practices. What I am pointing out is that the designs are being implemented in assignment blocks that do not reflect the recipients implementations intentions and this is neither helpful for them or other AS operators when it comes to filtering. If RIR policies establish this intention at the point of assignment then the island case will be catered for and we absolutely do not want to see an aggregate in the route table for assignments from that block. IF it is TE then it can be made from a conventional block with a cover router and more specifics. What I am seeing in the real world is island networks in address space with minimum /32 assigments. It is my choice if I filter your TE, it is a stupid choice if you don't advertise the cover route because you are doing TE. But what we need to facilitate are islands networks which for very sensible technical and commercial reasons are unable to advertise an aggregate. Policies may be in place to provide for this, however, what I am seeing in the route table is telling me that the policies are failing to identify people that want to implement their network in this fashion as they are coming from blocks with /32 min and they are advertising /48s. If these announcements came from and address block to which they were assigned with a minimum of a /48 because of their design intentions then everyone is happy and can announce and filer accordingly and end points are reachable. There is a reason that different blocks have different minimum sizes, I am advocating ensuring that we get assignments aligned with the blocks that are suit the intended implementation. It is not my place to judge your business, nor is it anyone elses to expect the rest of us to accept TE routes without a coverall and expect to be reachable. My 2c Ben -Original Message- From: Michael Smith [mailto:mksm...@mac.com] Sent: 14 November 2012 23:32 To: William Herrin Cc: nanog@nanog.org; Michael Smith Subject: Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums. On Nov 14, 2012, at 1:50 PM, William Herrin b...@herrin.us wrote: On Wed, Nov 14, 2012 at 3:10 PM, Michael Smith mksm...@mac.com wrote: I guess I'm confused. I have a /32 that I have broken up into /47's for my discrete POP locations. I don't have a network between them, by design. And, I won't announce the /32 covering route because there is no single POP that can take requests for the entire /32 - think regionalized anycast. So, how is it worse to announce the deaggregated /47's versus getting a /32 for every POP? In either case, I'm going to put the same number of routes into the DFZ. Hi Michael, If you announce an ISP /32 from each POP (or an end-user /48, /47, etc) then I know that a neutral third party has vetted your proposed network configuration and confirmed that the routes are disaggregated because the network architecture requires it. If you announce a /47 from your ISP space, for all I know you're trying to tweak utilization on your ISP uplinks. Again, I thought the discussion was about PI, not PA. I don't announce any PA. In the former case, the protocols are capable of what they're capable of. Discrete multihomed network, discrete announcement. Like it or lump it. In the latter case, I don't particularly need to burn resources on my router half a world away to facilitate your traffic tweaking. Let the ISPs you're paying for the privilege carry your more-specifics. You have great confidence in the immutability of design and the description thereof. Mike
Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.
On Wed, Nov 14, 2012 at 6:31 PM, Michael Smith mksm...@mac.com wrote: On Nov 14, 2012, at 1:50 PM, William Herrin b...@herrin.us wrote: On Wed, Nov 14, 2012 at 3:10 PM, Michael Smith mksm...@mac.com wrote: I guess I'm confused. I have a /32 that I have broken up into /47's for my discrete POP locations. I don't have a network between them, by design. And, I won't announce the /32 covering route because there is no single POP that can take requests for the entire /32 - think regionalized anycast. So, how is it worse to announce the deaggregated /47's versus getting a /32 for every POP? In either case, I'm going to put the same number of routes into the DFZ. If you announce an ISP /32 from each POP (or an end-user /48, /47, etc) then I know that a neutral third party has vetted your proposed network configuration and confirmed that the routes are disaggregated because the network architecture requires it. If you announce a /47 from your ISP space, for all I know you're trying to tweak utilization on your ISP uplinks. Again, I thought the discussion was about PI, not PA. I don't announce any PA. Hi Michael, PI and PA terminology is getting to be as obsolete as Class A, B and C. Your IPv6 addresses fall in to one of three categories: Allocation from RIR under ISP rules (/32 or more) Assignment from RIR under end-user rules (/48 or more) Reassignment from ISP (any size) You will find that you can successfully propagate announcements of allocations in units of /32 or shorter, assignments in units of /48 or shorter and reassignments in units of /32 or shorter. Longer prefix announcements won't be rejected by everybody, but they'll be rejected by enough folks to spoil your day. So, regardless of which of the three types of addresses you work with, you should make sure to get enough so that each of your discrete multihomed networks can announce a prefix as big as or bigger than the minimum. And as a purely pragmatic matter, you should never ever try to number a discrete multihomed IPv6 network using a reassignment. Go get an allocation or assignment (as appropriate) from the RIR instead. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: authority to route?
Careful though cause the crayons must be crayola approved Sent from my iPhone On 2012-11-14, at 5:28 PM, joel jaeggli joe...@bogus.com wrote: On 11/14/12 2:40 PM, Joe Abley wrote: On 2012-11-12, at 14:43, Jim Mercer j...@reptiles.org wrote: Is there a common practice of providers to vet / validate requests to advertise blocks? Yes, most providers whose customers request a particular route to be pointed towards them will ask for ambiguous instructions, written on letterhead with crayon, and signed illegibly by someone who may or may not have authority to do so but who in any case cannot be identified clearly by their scrawl. Some providers ask for route objects and appropriate import/export policy in RADB. that fandamently no higher quality an attestation than a LOA but it's a lot easier to read. Ideally the letterhead should be crudely constructed in photoshop and then faxed across a noisy analogue line. Once you have one of those babies in your file, no lawyer can touch you. Joe
Re: authority to route?
Another big-name-big-$$$ vendor whose name begins with C. Sounds like a conspiracy to me On 11/14/2012 5:09 PM, Mark Gauvin wrote: Careful though cause the crayons must be crayola approved Sent from my iPhone On 2012-11-14, at 5:28 PM, joel jaeggli joe...@bogus.com wrote: On 11/14/12 2:40 PM, Joe Abley wrote: On 2012-11-12, at 14:43, Jim Mercer j...@reptiles.org wrote: Is there a common practice of providers to vet / validate requests to advertise blocks? Yes, most providers whose customers request a particular route to be pointed towards them will ask for ambiguous instructions, written on letterhead with crayon, and signed illegibly by someone who may or may not have authority to do so but who in any case cannot be identified clearly by their scrawl. Some providers ask for route objects and appropriate import/export policy in RADB. that fandamently no higher quality an attestation than a LOA but it's a lot easier to read. Ideally the letterhead should be crudely constructed in photoshop and then faxed across a noisy analogue line. Once you have one of those babies in your file, no lawyer can touch you. Joe
Brasil/Mexico/Argentina connectivity
Hi I am search one or more carrier for connect 3 sites in Brasil, Mexico and Argentina to one of our pop in USA or Spain. if you have a name and contact ;=) best regards Olivier
