- Test - lists.nanog.org

Re: [Operational] Internet Police
by Michael Smith 09 Dec '10

09 Dec '10

Was it the original IANA? ----- Original Message ----- From: Randy Bush <randy(a)psg.com> To: Suresh Ramasubramanian <ops.lists(a)gmail.com> Cc: North American Network Operators Group <nanog(a)nanog.org> Sent: Thu Dec 09 14:12:41 2010 Subject: Re: [Operational] Internet Police > And if I ever find the genius who came up with the "we are not the > internet police" meme ... he died over a decade ago

1 0

Start accepting longer prefixes as IPv4 depletes?
by Iljitsch van Beijnum 09 Dec '10

09 Dec '10

(My apologies if this has been discussed before, I haven't been keeping up with NANOG as well as I should lately.) As the IPv4 address space depletes, various types of use that requires IPv4 addresses will get harder. In some cases, this is unavoidable: if you want to connect a million broadband users you need a million addresses. But for hosting activities you don't need that much space. In fact, often people have to be very creative to qualify for a /24 (/20 even in ARIN-land?) just so they have a large enough assignment that they can announce it in BGP and expect it to be reachable. But you really don't need a /20 or even a /24 to host websites or the like. Why not move away from that /24 requirement and start allowing /28s or a prefix length like that in the global routing table? This will allow content people to stay on IPv4 longer with fewer compromises, so we don't have to start thinking about NAT46 solutions in the near future. (NAT46 is really best avoided.) There are two issues: 1. Growth of the routing table. My answer to this is: although a smaller table would be good, we've been living with 16% or so growth for a decade before the IPv4 crunch, if going to < /28 instead of < /24 allows this growth to continue some more years there is no additional harm. And there is no evidence that /28s will create more growth than unconstrained /24s like we had before the IPv4 crunch. 2. People who think it's neat to deaggregate their /16 into 256 /24 will now go for 4096 /28s. To avoid this, the new /28s should come from separate ranges to be identified by the RIRs. So /28 would only be allowed for this new space that is given out as /28, not for anything that already exists and was thus given out as much bigger blocks. Thoughts? I'm hoping to get some modest support here before jumping into the RIR policy shark tanks.

17 32

West coast collos - ones that are VoIP friendly
by Graham Wooden 09 Dec '10

09 Dec '10

Hi there, I am not familiar with the west coast collocation facilities that are VoIP friendly (either by QoS or good upstreams/peering). Something in the Los Angeles area; been looking at IX2 on Wilshire. Right now looking to collocate a few boxes, switch and a router... Any recommendations? Quality over cost, at this moment. Thanks, -graham

1 0

Re: Are you ready for RPKI in your BGP?
by Arturo Servin 09 Dec '10

09 Dec '10

There are some pieces in the RPKI puzzle. One is the definitions of protocols, that one is very advanced in the SIDR WG in the IETF. Not RFCs yet but I am sure we will se some soon. Another piece are repositories of CA's and ROAs and Trust Anchors. RIRs have they implementations or you could create your own if you want to keep your private keys. IMHO one piece missing (not the only one, but one important in this stage) is RTR (RPKI/Router Protocol) working in routers. May be is too soon to see it in production routers but I am only aware of one big vendor with testing code. Also open-source implementations (Quagga, Xorp, Bird, etc.) are not actively (or at all) working in RPKI, I would imagine that one first step for many operators is to test RPKI with these implementations. Regards, -as On 9 Dec 2010, at 06:37, nanog-request(a)nanog.org wrote: > Date: Wed, 8 Dec 2010 22:56:08 -0500 > From: Jared Mauch <jared(a)puck.nether.net> > Subject: Are you ready for RPKI in your BGP? > To: North American Network Operators Group <nanog(a)nanog.org> > Message-ID: <15FF52BA-388A-48E8-BDDE-A151E694E9AC(a)puck.nether.net> > Content-Type: text/plain; charset=us-ascii > > Are you ready for RPKI in your network? > > While there's some dubious hyperbole in the article, the work that has been undertaken in SIDR wg re: RPKI is moving along. > > http://www.networkworld.com/cgi-bin/mailto/x.cgi?pagetosend=/news/2010/1207… > > For those of you preparing to assign 2011 goals to your employees, or something to self-assign, this should be in the top-5 or top-10 if you configure routers for BGP. > > - Jared

2 1

Are you ready for RPKI in your BGP?
by Jared Mauch 09 Dec '10

09 Dec '10

Are you ready for RPKI in your network? While there's some dubious hyperbole in the article, the work that has been undertaken in SIDR wg re: RPKI is moving along. http://www.networkworld.com/cgi-bin/mailto/x.cgi?pagetosend=/news/2010/1207… For those of you preparing to assign 2011 goals to your employees, or something to self-assign, this should be in the top-5 or top-10 if you configure routers for BGP. - Jared

4 3

SONET and MAC address
by Jay Nakamura 09 Dec '10

09 Dec '10

We have a Gigabit Ethernet transport between cities by a vendor. We found that when there are identical MAC address that are on different VLANs on different side of the circuit, one of the VLAN looses packets. This situation came up because two different networks that travel over the Ethernet were using HSRP with the same virtual MAC address. The vendor says both sides are directly connected to Fujitsu SONET gear and the equipment doesn't even look at the MAC address so it's not their circuit. All I know is, I can't recreate the problem if this circuit is not in the path. I haven't worked with Fujitsu SONET gear so I don't know if their claim is true or not. I vaguely remember someone talking about some equipment actually having a builtin switch on the SONET port and that was messing up the forwarding. Also, on one side of the circuit, there is a copper to fiber media converter. I am going to find out what model this is and see if that could be the cause. Anyone have any thoughts on what I should look into or have the vendor look into? Anyone run into this situation? Thanks!

4 4

ALT-DB Question
by Chadwick Sorrell 09 Dec '10

09 Dec '10

Hello, I'm sending a new MAINT-AS object to the db-admin(a)altdb.net, but it doesn't appear to be in the database after a few weeks. Are there any requirements that I may be missing on my new request, or some sort of way I can help get it processed? Basically wondering if I'm just not waiting long enough, or if I've done something wrong. Thanks, -chad

3 2

who dis
by Randy Bush 09 Dec '10

09 Dec '10

whois don't work * i2.78.64.0/18 144.232.9.61 1555 100 0 1239 3216 6854 35104 35104 35104 35104 29355 29355 29355 29355 29355 29355 29355 29355 29355 29355 i *> 199.238.113.9 374 0 2914 9002 6854 35104 35104 35104 35104 29355 29355 29355 29355 29355 29355 29355 29355 29355 29355 i * 129.250.11.41 379 0 2914 9002 6854 35104 35104 35104 35104 29355 29355 29355 29355 29355 29355 29355 29355 29355 29355 i * i2.78.128.0/17 144.232.9.61 1555 100 0 1239 3216 6854 35104 35104 35104 35104 29355 29355 29355 29355 29355 29355 29355 29355 29355 29355 i *> 199.238.113.9 374 0 2914 9002 6854 35104 35104 35104 35104 29355 29355 29355 29355 29355 29355 29355 29355 29355 29355 i * 129.250.11.41 379 0 2914 9002 6854 35104 35104 35104 35104 29355 29355 29355 29355 29355 29355 29355 29355 29355 29355 i * i2.79.0.0/16 144.232.9.61 1555 100 0 1239 3216 6854 35104 35104 35104 35104 29355 29355 29355 29355 29355 29355 29355 29355 29355 29355 i *> 199.238.113.9 374 0 2914 9002 6854 35104 35104 35104 35104 29355 29355 29355 29355 29355 29355 29355 29355 29355 29355 i * 129.250.11.41 379 0 2914 9002 6854 35104 35104 35104 35104 29355 29355 29355 29355 29355 29355 29355 29355 29355 29355 i so who is announcing this space that i can not find in ripe (or arin) whois? randy

2 1

Re: who dis
by Randy Bush 09 Dec '10

09 Dec '10

> I got both the as and the block from ripe's whois. now i do, before i did not. my apologies. randy

1 0

MasterCard problems
by Kiriki Delany 09 Dec '10

09 Dec '10

It's a national security issue that the federal and state governments cannot temporarily accept payment from visa/mc? Really? Is this because cash or checks are not viable solutions? This is the result of privatization of government. Pay close to attention to what privatization means. It's a loss of critical accountability. Demand government not rely on a private payment provider. It's a gross neglect of national security for payment processing to be beholden to visa/mc. They have no responsibility to the citizens of the US. I don't think is actually the case, as mc/visa take fee's of all transactions they process. Most vendors prefer cash or a check, I would assume the feds do as well. Of course if you have no actual cash anymore, and can only finance your debts on credit, well..... yet more evidence the lack of regulation of credit card companies is a national security risk. -Kiriki -----Original Message----- From: Matthew Black [mailto:black@csulb.edu] Sent: Wednesday, December 08, 2010 3:20 PM To: nanog(a)nanog.org Subject: Re: Mastercard problems O> ----- Original Message ----- >From:James Downs <egon(a)egon.cc> > To:andrew.wallace <andrew.wallace(a)rocketmail.com> > Cc:Christopher Morrow <morrowc.lists(a)gmail.com>; "nanog(a)nanog.org" ><nanog(a)nanog.org> > Sent:Wednesday, 8 December 2010, 21:30:20 > Subject:Re: Mastercard problems [snip] > Yikes.. you consider a private company's business to be the financial and >payment system of the United States? Yes, I do. Especially when government agencies accept payments through MasterCard, et al. matthew black comments reflect my opinions and may not represent those of my employer.

1 0