October 2005 - Test - lists.nanog.org

fleet.navy.mil DNS / network ops contact please
by Suresh Ramasubramanian 28 Oct '05

28 Oct '05

Could a dns ops contact for any of these hosts please email me offlist to help troubleshoot a network reachablity / dns lookup issue from our servers. thanks -srs ccsg3.navy.mil. 30M IN NS ns2.fleet.navy.mil. ccsg3.navy.mil. 30M IN NS dnsmail.uar.navy.mil. ccsg3.navy.mil. 30M IN NS ns1.fleet.navy.mil. -- Suresh Ramasubramanian (ops.lists(a)gmail.com)

2 2

gao contact
by Rick Wesson 27 Oct '05

27 Oct '05

I lost the contact details of the GAO rep, i believe his name is Vijay D'Souza of the U.S. Govt. Accountability Office, if anyone has is contact details could you drop them to me off list. thanks, -rick

1 0

Scalability issues in the Internet routing system
by Andre Oppermann 27 Oct '05

27 Oct '05

I guess it's time to have a look at the actual scalability issues we face in the Internet routing system. Maybe the area of action becomes a bit more clear with such an assessment. In the current Internet routing system we face two distinctive scalability issues: 1. The number of prefixes*paths in the routing table and interdomain routing system (BGP) This problem scales with the number of prefixes and available paths to a particlar router/network in addition to constant churn in the reachablility state. The required capacity for a routers control plane is: capacity = prefix * path * churnfactor / second I think it is safe, even with projected AS and IP uptake, to assume Moore's law can cope with this. 2. The number of longest match prefixes in the forwarding table This problem scales with the number of prefixes and the number of packets per second the router has to process under full or expected load. The required capacity for a routers forwarding plane is: capacity = prefixes * packets / second This one is much harder to cope with as the number of prefixes and the link speeds are rising. Thus the problem is multiplicative to quadratic. Here I think Moore's law doesn't cope with the increase in projected growth in longest prefix match prefixes and link speed. Doing longest prefix matches in hardware is relatively complex. Even more so for the additional bits in IPv6. Doing perfect matches in hardware is much easier though... -- Andre

24 51

ICANN and Verisign settle over SiteFinder
by Chris Woodfield 27 Oct '05

27 Oct '05

Said the flowerpot: "Oh no, not again..." http://www.businessweek.com/ap/financialnews/D8DEL2TO7.htm? campaign_id=apn_tech_down&chan=tc -C

6 6

Verizon DNS/NOC Operator please contact offlist.
by Ryan Dewalt 27 Oct '05

27 Oct '05

I'm having a few minor issues with DNS, and telephone channels are giving inconsistent information. Nutshell: Looking for a copy of our zone file (Or equivalent) for auditing purposes. Thanks. -Ryan Dewalt -- rdewalt(a)gmail.com - rdewalt(a)meridianksi.com pgp thumbprint: 8D75 08AA FECB D60E 5968 A3C4 1B82 3637 ECB0 EFB7

1 0

open jabber server and conference room for nanog-arin meeting
by Paul Vixie 26 Oct '05

26 Oct '05

in an unusual fit of effacacy, i brought up an open jabber server today and created a persistent conference room. i'm not a fan of the monolithic public jabber.org server. if you have a jabber account somewhere, you can join the conference room: nanog-arin(a)conference.jabber.tisf.net if you don't have a jabber account somewhere, you can register one at: jabber.tisf.net if you don't have a jabber client, my recommendations are: mac/os/x adium-x or psi windows pandion or psi bsd or linux psi or tkabber i've been told that srh might monitor this jabber room during tuesday's meeting, in case questions come in from folks listening to the broadcast.

3 3

Re: What is multihoming was (design of a real routing v. endpoint id seperation)
by Robert Bonomi 26 Oct '05

26 Oct '05

> From owner-nanog(a)merit.edu Mon Oct 24 15:33:02 2005 > Date: Mon, 24 Oct 2005 13:31:17 -0700 > Subject: Re: What is multihoming was (design of a real routing v. endpoint id > seperation) > > Stephen Sprunk wrote: > [snip] > > >> Other people use this term in very different ways. To some people > >> it means using having multiple IP addresses bound to a single > >> network interface. To others it means multiple websites on one > >> server. > > > > > > That is virtual hosting in a NANOG context. Some undereducated MCSEs > > might call it multihoming, but let's not endorse that here. > > Unfortunately, this is a common and "standards blessed" way to refer to > any host with multiple interfaces/addresses (real or virtual). For example, > from the "Terminology" section, 1.1.3, of RFC1122, "Requirements for > Internet Hosts -- Communication Layers," says, > > Multihomed > A host is said to be multihomed if it has multiple IP > addresses. For a discussion of multihoming, see Section > 3.3.4 below. > *sigh* Multi-homing simply means 'having external connections to more than one network' -- be it a network with multiple, disjoint, ingress/egress paths, or a host with interfaces (real or virtual) on distinct LAN subnets (even if those subnets are agregated into a single net somewhere upstream. A host with multiple adresses utilizing the _same_ netblock/netmask _should_ _not_ be called multi-homed (because there is only one path to that host), it is simply a single-homed host with multiple identities. might be called "poly-ip-any" or some such. <grin>

4 3

IRR Coordination mailing list
by Larry Blunk 25 Oct '05

25 Oct '05

This IRR Coordination mailing list was mentioned this morning during the BGP Filtering talk. We'd like to invite anyone interested in improving the trust, consistency, and coordination of IRR's to join. The archive and subscription details can be found at http://www.merit.edu/mail.archives/irrc/ -Larry Blunk Merit

1 0

Re: design of a real routing v. endpoint id seperation
by Joe Maimon 25 Oct '05

25 Oct '05

(apologies to Owen for CC'ng list, his points are valid concerns that I hadnt addressed or considered properly) Owen DeLong wrote: >> > c) Carry a much larger table on a vastly more expensive set of routers > in order to play. > >> ISPs who dont wish to connect these customers should feel free not to, >> and that will have no bearing on the rest of those who do. >> > Somehow, given C) above, I am betting that most providers will be in this > latter category. Considering that most people who are in favor of multihoming for ipv6 believe that there is customer demand for it, the market forces would decide this one. Additionally, until there are a few hundred thousand routes in the multihoming table, I dont see any more expense than today, merely an extra box in the pop. It could be years away that the doomsday table growth the anti-multihoming crowd predicts could occur. Only at that point would expensive seperate routers be needed. In fact seperate routers makes the multihoming table very small, at least to start with. It would be an implementation detail. An ISP could easily start off by simply not announcing the more specifics in the prefix space, without the new router systems. The point is, that the scaling problems multihoming brings would be limited to a) ISP's who want to offer service to customers who want to multihome b) The system that the ISP runs to provide this service. This is in contrast to todays mechanism, where customers who want to multihome affect everyone who accepts a full BGP feed. At the time customer demand worldwide demanded seperate routing tables, would be the time that ISPs would be able to decide whether the roi would be sufficient or not for them to keep their investment. Such a scheme would be a "money where your mouth is". You say there is customer demand for multihoming? Well here it is. Lets see which ISPs want to implement it and which customers want to pay extra (FSVO extra) for it. In fact, customers who multihome in this way, need not use the same ASN space as the rest of the world, just unique to the multihoming table (that might not work well if ISP's "faked" it by simply not advertising the more specifics they carried internally) This concept brings true hierarchy, and thus scalability, to the routing table. > >> If you are referring to the affect that this will attract "unwanted" >> traffic, that would be considered a COB. >> > That too, but, primarily, c). There are simple ways to minimize this. 1) standard BGP tricks....anti-social to be sure, such as prepending, meds...... 2) "Transit"-multihoming peering, where you depend more on external parties who peer with you on the multihoming plane more "popular" advertisement to bring you a higher ratio of traffic you are interested in. A small multihoming-table-carrying ISP would want to arrange things so that he pays a bit mer per (Mn|Gb) from his multihoming-table-peer, but does not have to attract large quantities of unwanted traffic from his non-multihoming-table peer. > >> In essence, the previous discussion about LNP suggested that telco's must >> do the same thing, attract unwanted traffic, traffic they must switch >> right back out of their network. >> > Except they don't. My formerly AT&T number does not go through AT&Ts > network to reach me just because it was ported. Read up on how SS7 > actually works before you make statements like this that simply aren't > true. > So I have been told....apparently I mistook the "conslusions" of the relevant threads. apologies. > Owen >

16 23

VoIP Security Threat Taxonomy: Request for Comments
by David Endler 24 Oct '05

24 Oct '05

The Voice over IP Security Alliance (VOIPSA) is pleased to announce the first draft release of the VoIP Security Threat Taxonomy. The draft is available at http://www.voipsa.org/Activities/taxonomy.php and your comments are greatly appreciated. In fact, we've opened up the online wiki specifically for collecting your feedback. Many thanks to the project leader Jonathan Zar and all of the volunteers who dedicated their time and energy to this first release. -dave David Endler VOIPSA Chairman ABOUT VOIPSA: The Voice over IP Security Alliance (VOIPSA) aims to fill the void of VoIP security related resources through a unique collaboration of VoIP and Information Security vendors, providers, thought leaders, and users. VOIPSA's mission is to drive adoption of VoIP by promoting the current state of VoIP security research, VoIP security education and awareness, and free VoIP testing methodologies and tools. Get involved at http://www.voipsa.org

1 0