- NANOG - lists.nanog.org

Re: "Leasing" of space via non-connectivity providers
by John Curran 11 Feb '11

11 Feb '11

On Feb 5, 2011, at 8:40 PM, bmanning(a)vacation.karoshi.com wrote: > On Sat, Feb 05, 2011 at 09:12:53PM +0000, John Curran wrote: >> RFC 2050 is the document which provides the registry system framework. Jon Postel is an author of same, as well as a founder of ARIN. > > yup.. i was there when it was written. Excellent; it could prove helpful in clarifying things. > It does not talk to address space allocated to entities from the IANA or other > registries prior to the RIRs existance. Is it your belief that Jon did not intend RFC 2050 to apply to the existing allocations maintained by the three regional registries in existence at the time (InterNIC, RIPE NCC and APNIC)? I imagine that is plausible, but it would run contrary to the language which states that assignments should be viewed as loans and "to this end, ISPs should have documented justification available for each assignment. The regional registry may, at any time, ask for this information. If the information is not available, future allocations may be impacted. In extreme cases, existing loans may be impacted." I'm having trouble understanding how *existing* allocations could be impacted if existing registry allocations were not covered. Or are you suggesting that RFC 2050 applies, but there is a select set of ISP allocations that were outside of InterNIC, APNIC, and RIPE NCC to which special handling is applied? Further, RFC 2050 states "The transfer of IP addresses from one party to another must be approved by the regional registries. The party trying to obtain the IP address must meet the same criteria as if they were requesting an IP address directly from the IR." Even one were to hypothecate some type of address space that could be the *source* of a transfer due to a mystical handling status, how could any party be the *recipient* of such without demonstrating need to one of the regional registries per the second referenced text? Is this also a case where it was meant to exclude some special parties but just did not get stated in the actual RFC 2050 text? Thanks! /John John Curran President and CEO ARIN

13 32

Re: Failure modes: NAT vs SPI
by Iljitsch van Beijnum 11 Feb '11

11 Feb '11

On 4 feb 2011, at 22:02, Dave Cardwell wrote: > Without wanting to get into whether NAT provides security to hosts > that exist on the inside. I am curious if the potential to overflow > ND caches with incomplete* entries exists on currently shipping CPE > hardware and if NAT helps prevent this? > e.g. > In v4 with a /24 on the inside an attacker can send a single packet to > each consecutive address causing at most 254 arp requests to be sent > on the lan segment and upto 253 incomplete entries, until they > timeout. > In v6 with a /64 on the inside it seems like the same tactic would > lead to more outstanding ND requests than any realistically sized > cache would support. Ok, I had a hard time making up my mind whether a sarcastic or a factual response was in order... This is of course a very big problem, and one of the reasons why everyone who's tried IPv6 immediately turns it off again: script kiddies are continuously scanning the entire IPv6 address space so this happens to regular IPv6 users all the time. Since this is a problem that is inherent to the ND protocol that is impossible to fix without modifying the IPv6 standards significantly, the easiest way to solve this with the least amount of impact to applications, the ability to host services and the end-to-end model in particular is to use a single public IPv6 address and NAT all local stuff behind it. (BTW, there have been some discussions on NAT66 in the IETF, but that wouldn't be a port overloading 1-to-many NAT, but rather a 1-to-1 NAT, because with IPv6, there obviously isn't any reason to use address sharing. The thinking is that such a 1-to-1 NAT is less harmful than a port overloading 1-to-many NAT so it would be beneficial to specify the former to avoid the latter. But many people within the IETF don't support that strategy.)

7 8

Semi-Annual 'System Status Page' solicitation
by Jay Ashworth 11 Feb '11

11 Feb '11

If you work for a backbone, content, access, or service provider, and you know that your company has a publicly accessible System/Service/Network Status Page available on the web, we'd love it if you'd add it to the Outages Dashboard, at http://wiki.outages.org/index.php/Dashboard If you have an account on the wiki, you can add it directly; if not, you can add it to the associated Talk page, or email it to me off list, and I'll be happy to add it for you. You're perfectly welcome to add any other pages we don't have listed as well, as long as they're publicly accessible. This was a recording. Cheers, -- jra

1 0

BCP38 considerations in IPv6
by Ryan Rawdon 10 Feb '11

10 Feb '11

Hello NANOGers - What considerations should be made with respect to implementing egress filtering based on source IPv6 addresses? Things like allowing traffic sourced from fe80::/10 in said filters for on-link communication (for the interface that the filter is applied to). Is there anything else that should be taken into account while implementing BCP38 egress filtering in IPv6? Ryan

5 4

Re: Is your ASN advertising v6 prefixes?
by Scott Weeks 10 Feb '11

10 Feb '11

--- mpetach(a)netflight.com wrote: From: Matthew Petach <mpetach(a)netflight.com> On Wed, Feb 9, 2011 at 6:21 PM, Fred Richards <fredr(a)geexology.org> wrote: > Mine is. eh...not many. http://bgp.he.net/AS10310 ---------------------------------------- Prefixes Originated (v6): 4 Why 4? scott

3 2

ARIN and IPv6 Requests
by ADWebb＠dstsystems.com 10 Feb '11

10 Feb '11

Why does ARIN require detailed usage of IPv4 space when requesting IPv6 space? Seems completely irrelevant to me. -- Adam Webb EN & ES Team desk: 816.737.9717 cell: 916.949.1345 --------------------------------------- The biggest secret of innovation is that anyone can do it. --------------------------------------- ----------------------------------------- Please consider the environment before printing this email and any attachments. This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system.

3 2

Self-referential whois queries
by Rubens Kuhl 10 Feb '11

10 Feb '11

I'm noticing an increase in getting "query rate exceeded" at whois services that might be connected to a symptom described by ARIN at NANOG 48/ARIN XXV and ARIN XXVI where machines ask for the whois record of their own IP address. Are there any clues of what is causing this ? Rubens

2 2

10GBASE-T Switches
by Roberts, Brent 10 Feb '11

10 Feb '11

Looking for feedback/recommendations on higher density Switch’s in the 10GBASE-T arena. Preferably TOR switches if possible. Minimum 16 ports usable for Rack Server connectivity + Uplinks to Collapsed Twin Distro/Core setup. Found the Arista 7X00 family to have the density I am looking for but others of similar spec would be appreciated. Any Thoughts and/or suggestions would be greatly appreciated. ________________________________ This email and any attached files may contain confidential and/or privileged material and is intended solely for the use of the person to whom it is addressed. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender immediately and delete it and all attachments from your computer. Progressive Solutions is not liable for any errors or omissions in the content or transmission of this email.

6 7

box.net network engineer
by Andrew Matthews 10 Feb '11

10 Feb '11

Can someone with the box.net engineering group email me off list. I have a peering issue with you guys at any2 in socal. Thanks, Drew

2 1

Comcast BGP issue?
by Wallace Keith 10 Feb '11

10 Feb '11

Not quite sure what the issue is, but I suspect Comcast announcements are not quite right? Trying to get from Verizon Business to a Comcast address in NH (on 75.15.64.0/18), and it's going through San Jose. Anyone else having similar issues or suggestions? Opened a ticket with Comcast, but they want to check the cable modem (sigh) 6 6 ms 6 ms 6 ms 0.so-3-2-0.XL3.BOS4.ALTER.NET [152.63.22.178] 7 13 ms 14 ms 13 ms 0.xe-6-1-2.XL3.NYC4.ALTER.NET [152.63.0.166] 8 14 ms 46 ms 13 ms 0.ae3.BR3.NYC4.ALTER.NET [152.63.16.181] 9 14 ms 14 ms 13 ms te-7-0-0.edge2.NewYork2.level3.net [4.68.110.69] 10 13 ms 13 ms 14 ms vlan52.ebr2.NewYork2.Level3.net [4.69.138.254] 11 14 ms 14 ms 14 ms ae-6-6.ebr2.NewYork1.Level3.net [4.69.141.21] 12 85 ms 88 ms 90 ms ae-2-2.ebr4.SanJose1.Level3.net [4.69.135.185] 13 85 ms 85 ms 89 ms ae-94-94.csw4.SanJose1.Level3.net [4.69.134.254] 14 83 ms 83 ms 84 ms ae-4-99.edge1.SanJose1.Level3.net [4.68.18.206] 15 97 ms 95 ms 95 ms COMCAST-IP.edge1.SanJose1.Level3.net [4.79.43.134] 16 125 ms 125 ms 124 ms pos-0-14-0-0-cr01.denver.co.ibone.comcast.net [68.86.85.129] 17 135 ms 129 ms 125 ms pos-0-14-0-0-cr01.chicago.il.ibone.comcast.net [68.86.85.117] 18 122 ms 121 ms 121 ms pos-1-15-0-0-ar01.woburn.ma.boston.comcast.net [68.86.93.122] 19 128 ms 127 ms 127 ms po-66-ur02.manchester.nh.boston.comcast.net [68.85.69.170] 20 123 ms 121 ms 121 ms 68.85.161.226 21 116 ms 118 ms 119 ms x-x-x-x-newengland.hfc.comcastbusiness.net [75.150.80.x] -Keith

1 1