Re: US-Asia Peering
Rearranged slightly. What are the technical issue with extreme long distance (transoceanic) peering? In particular, what are the issues interconnecting layer 2 switches across the ocean for the purposes of providing a global peering cloud using: In the generic sense, the issues are largely the same as interconnecting to the L2 switch in the customer's cage (operated by the customer as an aggregation device) or the L2 switch implementing another exchange fabric in the same building or metro. Complex L2 topologies are hard to manage, especially when the devices that implement that topology are not all managed by the same entity. L2 has poor policy knobs for implementing administrative boundaries; if such a boundary is involved, the events that you need to anticipate are largely the same whether the switches are separated by a cage wall or an ocean. The auto-configuring properties of L2 fabrics (like MAC learning, or spanning tree) that make it an attractive edge technology can be very detrimental to smooth operation when more than one set of hands operates the controls. An exchange point is, quite literally, an implementation of an administrative boundary; the desire of customers to use L2 devices themselves (for aggregation of cheap copper interfaces toward expensive optical ones, use of combined L2/L3 gear, or whatever other reason) means that the L2 fabric of any Ethernet-based exchange has potentially as many hands on the controls as there are customers. So, good operational sense for the exchange point operator means exercising as much control over those auto-configuring properties as is possible; turning them off or turning automatic functions into manual ones. Did I mention that L2 has lousy knobs for policy control? (They're getting a little better, so perhaps whatever is a notch better than lousy is appropriate). One of the ones that you have to turn off is spanning tree (read the thread from a few months back on the hospital network that melted down for background material). That means that you have to build a loop-free topology out of reliable links, which you can get with all three of the technologies you mention, but you have to build a loop-free topology. In order to use inter-metro connectivity efficiently, you are limited to building L2 patches that each implement pairwise connectivity between two metros. That makes this: 0) vanilla circuit transport to interconnect the switches hard, because your interior connectivity is dedicated to one of those pairwise combinations (hard, but not impossible, assuming you have some capex to throw at the problem). The pairwise limitation also, indirectly, puts the kibosh on using this fabric as a means to pretend that a network has a backbone in order to qualify for peering that it wouldn't get otherwise. That leaves these two: 1) MPLS framed ethernet service to interconnect the switches 2) tunnelled transport over transit to interconnect the switches which will carry the exchange point traffic over an L3 (okay, so MPLS is L2.5) network; in addition, you get the benefit of being able to have all the L3 knobs available in the interior to do traffic engineering. Both options perform better when the interior MTU can accomodate the encapsulation protocol plus payload without fragmenting, so someone is operating routers with SONET interfaces in this equation. Qui bene? - The operator of the L3 network that carries the inter-EP fabric gets revenue. - The people who peer using this L2 fabric get to avoid some transit, but I would argue that it is only to reach providers that are similarly desirous of avoiding transit, since this won't help the upwardly mobile with the geographic diversity component of getting to the next tier. Who loses? - Transit providers who came to the exchange point for the purpose of picking up transit sales. - If the exchange point operator is the one carrying the traffic, they lose for competing with their customers in the previous bullet; they will have taken the first steps on the path from being an exchange point operator to being a network-plus-colo provider (where they'll compete with the network-plus-colo providers just coming out of bankruptcy with all their debt scraped off). So far, there has been an assumption that the provider of inter-EP connectivity is willing to portion it out in a manner that is usage-insensitive for the participants. I don't believe that the glut of capacity or the other expenses that come with operating an L3 network has driven the costs so low that the resulting product is too cheap to meter. If that is the case, then delivering robust, auditable service is better implemented by connecting the customers up to the L3 gear and implementing their L2 connections as pairwise virtual circuits between customers (so you can be sure you're not paying remote rates to talk to a local customer, or billing local rates to traffic that a customer exchanges over the
The Cidr Report
This report has been generated at Fri Jan 3 21:45:27 2003 AEST.
The report analyses the BGP Routing Table of an AS4637 (Reach) router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/as4637 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
27-12-02117120 84759
28-12-02117172 84857
29-12-02117391 84760
30-12-02117247 84955
31-12-02117450 85024
01-01-03117552 85059
02-01-03117648 85132
03-01-03117672 85168
AS Summary
14290 Number of ASes in routing system
5618 Number of ASes announcing only one prefix
1610 Largest number of prefixes announced by an AS
AS701 : ALTERNET-AS UUNET Technologies, Inc.
73047040 Largest address span announced by an AS (/32s)
AS568 : SUMNET-AS DISO-UNRRA
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 03Jan03 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 117812851553265727.7% All ASes
AS3908 1173 689 48441.3% SUPERNETASBLK SuperNet, Inc.
AS701 1610 1195 41525.8% ALTERNET-AS UUNET
Technologies, Inc.
AS18566 4145 40998.8% COVAD Covad Communications
AS7018 1430 1029 40128.0% ATT-INTERNET4 ATT WorldNet
Services
AS4323 532 188 34464.7% TW-COMM Time Warner
Communications, Inc.
AS7843 622 301 32151.6% ADELPHIA-AS Adelphia Corp.
AS1221 1146 829 31727.7% ASN-TELSTRA Telstra Pty Ltd
AS6197 455 150 30567.0% BATI-ATL BellSouth Network
Solutions, Inc
AS1239 976 687 28929.6% SPRINTLINK Sprint
AS6347 368 85 28376.9% DIAMOND SAVVIS Communications
Corporation
AS4355 407 136 27166.6% ERMS-EARTHLNK EARTHLINK, INC
AS22927 289 22 26792.4% AR-TEAR2-LACNIC TELEFONICA DE
ARGENTINA
AS7046 552 291 26147.3% UUNET-CUSTOMER UUNET
Technologies, Inc.
AS705422 188 23455.5% ASN-ALTERNET UUNET
Technologies, Inc.
AS4814 246 15 23193.9% CHINANET-BEIJING-AP China
Telecom (Group)
AS6198 423 200 22352.7% BATI-MIA BellSouth Network
Solutions, Inc
AS1 659 437 22233.7% GNTY-1 Genuity
AS17676 231 26 20588.7% GIGAINFRA XTAGE CORPORATION
AS22291 226 29 19787.2% CHARTER-LA Charter
Communications
AS690513 319 19437.8% MERIT-AS-27 Merit Network Inc.
AS4151 325 134 19158.8% USDA-1 USDA
AS6140 315 125 19060.3% IMPSAT-USA ImpSat
AS209517 335 18235.2% ASN-QWEST Qwest
AS4134 290 108 18262.8% ERX-CHINALINK Data
Communications Bureau
AS852627 446 18128.9% ASN852 Telus Advanced
Communications
AS2048 254 84 17066.9% LANET-1 State of Louisiana
AS2386 387 229 15840.8% INS-AS ATT Data
Communications Services
AS6327 185 34 15181.6% SHAWFIBER Shaw Fiberlink
Limited
AS17557 324 179 14544.8% PKTELECOM-AS-AP Pakistan
Telecom
AS3215 313 174 13944.4% AS3215 France Telecom
Transpac
Total 16231 8669 756246.6% Top 30 total
Please see http://www.cidr-report.org for the full report
Copies of this report are mailed to:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Re: US-Asia Peering
- Transit providers who came to the exchange point for the purpose of picking up transit sales. - If the exchange point operator is the one carrying the traffic, they lose for competing with their customers in the previous bullet; they will have taken the first steps on the path from being an exchange point operator to being a network-plus-colo provider (where they'll compete with the network-plus-colo providers just coming out of bankruptcy with all their debt scraped off). i'm still amazed that nobody has brought up the fact that a couple of the larger colo/exchange operators that claimed they wouldn't compete with their IP customers are indeed selling IP transit-- intentionally undercutting the prices of the providers that colo'd there to sell transit partly because the colo/exchange operator kept telling the world that they would never compete with their customers in the IP transit space. clearly, interconnecting their exchange points to create a richly- connected Internet 'core' is a natural progression if their customers don't complain too loudly. not that it's a bad long-term plan-- but I do agree with Stephen in that it'll be tough for them to survive against the debt-free big boys if they emerge as clear network-plus-colo competitors and lose the few remaining bits of their 'neutral' facade. - jsb -- Jeff Barrows, President Firefly Networks http://FireflyNetworks.net +1 703 287 4221 Voice +1 703 288 4003 Facsimile An Advanced Internet Engineering Professional Services Organization
Re: US-Asia Peering
Both Stephen and Jeff and correct. And Im not sure it would be in the best interests of the colo company to be a jack of all trades. Where I do see a benefit are where an exch pt company wants to start a new one in a new city. It's the classic chicken and the egg. Where I have promoted allowing a beta group of peers to jump in for little or no charge till say peer #6, another solution is to connect that new exch pt to a successful one at another location. Allowing the benefit of new peers at location B to see old peers at location A. This would allow a critical mass of peers immediately, and would allow customer 1 to see benefit. Some restrictions might have to be in place. 1) Limiting the traffic levels for distance peering. 100meg or 1 Gig would do it 2) Perhaps a time limit Also, instead of competing with carriers at this new location B, you would actually prove there is business there. Most companies are in a wait and see mode before deploying, or a wait and get an order 1st mode. By jump starting the peering with transport, you then have the data the carrier engineers need to justify a build. This IS one way to get more successful peering points started. At 10:05 -0500 1/3/03, Jeff Barrows wrote: - Transit providers who came to the exchange point for the purpose of picking up transit sales. - If the exchange point operator is the one carrying the traffic, they lose for competing with their customers in the previous bullet; they will have taken the first steps on the path from being an exchange point operator to being a network-plus-colo provider (where they'll compete with the network-plus-colo providers just coming out of bankruptcy with all their debt scraped off). i'm still amazed that nobody has brought up the fact that a couple of the larger colo/exchange operators that claimed they wouldn't compete with their IP customers are indeed selling IP transit-- intentionally undercutting the prices of the providers that colo'd there to sell transit partly because the colo/exchange operator kept telling the world that they would never compete with their customers in the IP transit space. clearly, interconnecting their exchange points to create a richly- connected Internet 'core' is a natural progression if their customers don't complain too loudly. not that it's a bad long-term plan-- but I do agree with Stephen in that it'll be tough for them to survive against the debt-free big boys if they emerge as clear network-plus-colo competitors and lose the few remaining bits of their 'neutral' facade. - jsb -- Jeff Barrows, President Firefly Networks http://FireflyNetworks.net +1 703 287 4221 Voice +1 703 288 4003 Facsimile An Advanced Internet Engineering Professional Services Organization -- David Diaz [EMAIL PROTECTED] [Email] [EMAIL PROTECTED] [Pager] www.smoton.net [Peering Site under development] Smotons (Smart Photons) trump dumb photons
Google Crawler
We are a domain registrar and we host/park over 750,000 domain names. Every now and then the Google Crawler decides to bury the machines that host our 'parked' domain pages. We use robots.txt but that doesn't help under these circumstances. I have tried sending a message to Google using their web site. They don't have a NOC entry on puck.nether.net either. Our only alternative right now is to block the crawler at the router level. Does anbody have a contact at Google or is anyone at Google listening? Thanks! Andy Ellifson
RE: Google Crawler
http://www.google.com/bot.html for issues with the crawler. mailto:[EMAIL PROTECTED] will get you a human bean to talk to. Normally when there is a problem with their robot, they are pretty responsive. -Mike --- Michael Damm, MIS Department, Irwin Research Development V: 509.457.5080 x298 F: 509.577.0301 E: [EMAIL PROTECTED] -Original Message- From: Andy Ellifson [mailto:[EMAIL PROTECTED]] Sent: Friday, January 03, 2003 8:45 AM To: [EMAIL PROTECTED] Subject: Google Crawler We are a domain registrar and we host/park over 750,000 domain names. Every now and then the Google Crawler decides to bury the machines that host our 'parked' domain pages. We use robots.txt but that doesn't help under these circumstances. I have tried sending a message to Google using their web site. They don't have a NOC entry on puck.nether.net either. Our only alternative right now is to block the crawler at the router level. Does anbody have a contact at Google or is anyone at Google listening? Thanks! Andy Ellifson
RE: Google Crawler
Thank you! --- Mike Damm [EMAIL PROTECTED] wrote: http://www.google.com/bot.html for issues with the crawler. mailto:[EMAIL PROTECTED] will get you a human bean to talk to. Normally when there is a problem with their robot, they are pretty responsive. -Mike --- Michael Damm, MIS Department, Irwin Research Development V: 509.457.5080 x298 F: 509.577.0301 E: [EMAIL PROTECTED] -Original Message- From: Andy Ellifson [mailto:[EMAIL PROTECTED]] Sent: Friday, January 03, 2003 8:45 AM To: [EMAIL PROTECTED] Subject: Google Crawler We are a domain registrar and we host/park over 750,000 domain names. Every now and then the Google Crawler decides to bury the machines that host our 'parked' domain pages. We use robots.txt but that doesn't help under these circumstances. I have tried sending a message to Google using their web site. They don't have a NOC entry on puck.nether.net either. Our only alternative right now is to block the crawler at the router level. Does anbody have a contact at Google or is anyone at Google listening? Thanks! Andy Ellifson
COM/NET informational message
-BEGIN PGP SIGNED MESSAGE- This message explains an upcoming change in certain behavior of the com and net authoritative name servers related to internationalized domain names (IDNs). VeriSign Global Registry Services (VGRS) has been a longtime advocate of IDNs. Our IDN Test Bed has been active for over two years and we have followed and supported IETF developments in the IDN area. The protocol for IDNs developed by the IETF's IDN Working Group has been approved by the IESG and we anticipate that RFCs will be published soon. That protocol, Internationalizing Domain Names in Applications (IDNA), calls for changes to individual applications to support IDNs. VGRS has developed a plug-in, called i-Nav, for Microsoft's Internet Explorer browser to support IDNs in a manner consistent with IDNA. i-Nav is free and more information about it is available at http://www.idnnow.com. Before IDNA, some application developers had developed proprietary mechanisms designed to support IDNs. The Internet Explorer browser, for example, sends a DNS query in UTF-8 or another, local encoding when a user types a domain name with characters other than letters, digits and the hypen in the address bar. These efforts, however, were not entirely successful. For example, if such a domain name ends in com or net these queries reach the com/net name servers and fail. Our research indicates that the average user expects IDNs to work but does not understand the need for additional software to support this functionality. Such users attempt to enter IDNs in their browsers, but when the queries fail, they become frustrated and do not know what action to take to enable IDNs. They are unaware that downloading a browser plug-in such as i-Nav would enable IDN resolution. To improve this user experience and to encourage the adoption of an application that supports IDNA, VGRS is announcing a measure intended to stimulate widespread distribution of the i-Nav plug-in. Starting on January 3, 2003, some queries to the com/net name servers that previously failed with a DNS Name Error (NXDOMAIN) response will instead return an address (A) record. Any queries for A records with at least one octet greater than decimal 127 in the second-level label will trigger this A record response. For example, a query for the A record for foo?.com, where ? represents an octet with a value greater than 127, would return an A record rather than NXDOMAIN response. The goal is to match unrecognized domain names generated by browsers attempting to resolve IDNs. Since browsers construct DNS queries for such IDNs using UTF-8 or a local encoding, and since these encodings use octets with all possible values (i.e., from 0 through 255), the presence of octets with values greater than 127 as described above can indicate a web browser's failed IDN resolution attempt. The A record that will be returned by VGRS points to a farm of web servers that will attempt to resolve the query. The browser that sent the original DNS query will connect to one of these web servers and its HTTP request will contain a Host header with the representation of the IDN originally entered by the user in the address bar. The web servers will attempt to interpret the contents of the Host header. If the Host header corresponds to an IDN registered in VeriSign's IDN Test Bed, the web server will return a page that gives the user an opportunity to download the free i-Nav plug-in. The page will also allow the user to navigate to the corresponding IDN web site via an HTTP redirect. If the contents of the Host header cannot be matched to an IDN registered in the Testbed, the web server will return an HTTP 404 response. If a user downloads and installs the i-Nav plug-in, his or her browser will convert any IDNs entered to ASCII compatible encoding (ACE) format, according to the method described in IDNA. As a result, subsequent DNS queries will use ASCII characters only. The user experience for web browsing will change only slightly from the current experience if the contents of the Host header cannot be interpreted. If the web farm cannot match the Host header to an IDN, the user will see an error page resulting from the HTTP 404 error returned, rather than an error page resulting from a DNS NXDOMAIN response. The web servers refuse connections on all other UDP and TCP ports, so other network services are minimally affected. The overriding goal is to improve Internet navigation by encouraging widespread adoption of software supporting the emerging IETF standards for IDNs. These measures allow distribution of such software. - Brad Verd Resolution Systems Operations Manager VeriSign Global Registry Services http://www.verisign-grs.com Email: [EMAIL PROTECTED] - -BEGIN PGP SIGNATURE- Version: PGP 7.1 iQEVAwUBPhXOL/Al8hAO5uPhAQFASQgAuu9y0LF5/2SuddtdRNDbyUd9ccNkPwnw fip2bSh1EW7+b2jykw2tDxIAl2iejg2GVwhXmMiGOdm+FBOyBPtbQaM/DMCXHJ3r
Re: COM/NET informational message
BV Date: Fri, 3 Jan 2003 12:49:06 -0500 BV From: Verd, Brad [ At the risk of going OT... ] BV Before IDNA, some application developers had developed BV proprietary mechanisms designed to support IDNs. The Internet UTF-8 is a standard. MS products have used two-octet chars to support Unicode for a long time. Any reason to add yet another encoding? BV The A record that will be returned by VGRS points to a farm BV of web servers that will attempt to resolve the query. Going to proxy SMTP as well? BV If a user downloads and installs the i-Nav plug-in, his or BV her browser will convert any IDNs entered to ASCII compatible BV encoding (ACE) format, according to the method described in BV IDNA. As a result, subsequent DNS queries will use ASCII BV characters only. Why? Programmers already are (or should be) supporting UTF-8. Searching RFC1035 for binary indicates a nameserver should be able to handle chars = 0x80. All that's left is deciding on an encoding and handling case. BV The web servers refuse connections on all other UDP and TCP BV ports, so other network services are minimally affected. U more like the ugly kludge only addresses HTTP, and other network services just won't work. BV The overriding goal is to improve Internet navigation by BV encouraging widespread adoption of software supporting the BV emerging IETF standards for IDNs. These measures allow BV distribution of such software. How about encouraging widespread adoption of EXISTING standards instead of adding more cruft? UTF-8 is standard. Proper DNS implementations are eight-bit safe. People upgraded browsers due to SSL, Year 2000, Javascript... Eddy -- Brotsman Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~ Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked.
Re: US-Asia Peering
clearly, interconnecting their exchange points to create a richly- connected Internet 'core' is a natural progression if their customers don't complain too loudly. not that it's a bad long-term plan... Actually, it is. It's failed in every prior instance. It's one of the many, many ways in which exchange points commit suicide. -Bill
Re: COM/NET informational message
At 18:31 + 1/3/03, E.B. Dreger wrote: UTF-8 is a standard. MS products have used two-octet chars to support Unicode for a long time. Any reason to add yet another encoding? Sounds like a question to ask of the IETF. How about encouraging widespread adoption of EXISTING standards instead of adding more cruft? UTF-8 is standard. Proper DNS implementations are eight-bit safe. People upgraded browsers due to SSL, Year 2000, Javascript... The DNS protocol is not 8-bit safe, much less any implementations of it. This is because ASCII upper case characters are down cased in comparisons. I.e., the following are equivalent label values in DNS: ABCDEF and abcdef and AbCdEf. Each has distinct binary encodings, but DNS comparisons treat them as equal. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer
Re: US-Asia Peering
On Fri, Jan 03, 2003 at 10:11:09AM -0500, David Diaz wrote: 2) Perhaps a time limit who is still connected to mae-w fddi? i know there are people there. time limits don't work well. -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: COM/NET informational message
EL Date: Fri, 3 Jan 2003 13:44:53 -0500 EL From: Edward Lewis EL The DNS protocol is not 8-bit safe, much less any EL implementations of it. This is because ASCII upper case EL characters are down cased in comparisons. I.e., the My point is there's no need to force chars = 0x7f if DNS servers are properly implemented. If they're not properly implemented, why not, and whose fault is that? Catering to bad or broken implementations instead of following standards is not a good way to ensure interoperability. DNS labels are encoded by a one-octet length representation followed by that number of octets, with no restrictions on the content of the octets. Show me where an RFC says something to the extent of labels and any type of RR MUST NOT contain characters = 0x7f that rescinds 1035. Yes, comparisons are case-insensitive. So what? strcasecmp() works on ASCII strings. Now it must work on new encoding x. Why not let new encoding x be UTF-8, something programmers should support already? Maybe MS-style Unicode encoding? Why add yet another encoding?! I fear I may be straying OT, for this is layers 6/7... Eddy -- Brotsman Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita Network Working Group P. Mockapetris Request for Comments: 1035 ISI November 1987 2.3.3. Character Case For all parts of the DNS that are part of the official protocol, all comparisons between character strings (e.g., labels, domain names, etc.) are done in a case-insensitive manner. At present, this rule is in force throughout the domain system without exception. However, future additions beyond current usage may need to use the full binary octet capabilities in names, so attempts to store domain names in 7-bit ASCII or use of special bytes to terminate labels, etc., should be avoided. When data enters the domain system, its original case should be preserved whenever possible. In certain circumstances this cannot be done. For example, if two RRs are stored in a database, one at x.y and one at X.Y, they are actually stored at the same place in the database, and hence only one casing would be preserved. The basic rule is that case can be discarded only when data is used to define structure in a database, and two names are identical when compared in a case insensitive manner. 3.3. Standard RRs The following RR definitions are expected to occur, at least potentially, in all classes. In particular, NS, SOA, CNAME, and PTR will be used in all classes, and have the same format in all classes. Because their RDATA format is known, all domain names in the RDATA section of these RRs may be compressed. domain-name is a domain name represented as a series of labels, and terminated by a label with zero length. character-string is a single length octet followed by that number of characters. character-string is treated as binary information, and can be up to 256 characters in length (including the length octet). ~ Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked.
Re: Dutch translation needed
On Wed, Jan 01, 2003 at 05:32:36PM -0700, James-lists wrote: I am not getting through to speed.planet.nl in English, can anyone give me a decent translation of in Dutch (The Netherlands): Everybody here speaks English. If they are ignoring you, they will ignore you in Dutch too. Regards, bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing Traffic Control HOWTO http://netherlabs.nl Consulting
Re: COM/NET informational message
From: E.B. Dreger [EMAIL PROTECTED] BV Before IDNA, some application developers had developed BV proprietary mechanisms designed to support IDNs. The Internet UTF-8 is a standard. MS products have used two-octet chars to support Unicode for a long time. Any reason to add yet another encoding? UTF-8 is a character encoding standard, not a DNS-standard. DNS is not, and has not ever been 8-bit clean, despite the fact that many, if not most, implementations will survive UTF-8 labels. IDN(A) is an effort to encode unicode into 7-bit DNS-labels, without breaking backward compatibility (too hard). While there originally were a few voices arguing for UTF-8 over the wire, they were few and the consensus today is that IDN(A) is a Good Way to Go(tm). How about encouraging widespread adoption of EXISTING standards instead of adding more cruft? UTF-8 is standard. Proper DNS implementations are eight-bit safe. People upgraded browsers due to SSL, Year 2000, Javascript... Or, how about encouringing widespread adoption of upcoming standards, such as IDN? http://www.ietf.org/html.charters/idn-charter.html Remember, DNS implementations may be 8-bit safe, but that doesn't prevent anything else from not being so. Domains are used in so much more than DNS, you know. =) Best regards, Kandra Nygards
Re: COM/NET informational message
On Fri, Jan 03, 2003 at 07:15:43PM +, E.B. Dreger wrote: Yes, comparisons are case-insensitive. So what? strcasecmp() works on ASCII strings. Now it must work on new encoding x. Why not let new encoding x be UTF-8, something programmers should support already? Maybe MS-style Unicode encoding? Why add yet another encoding?! Even the current MS encoding does not work. Check out 130.161.180.1, which I think runs VMS. It does not even pass 127 characters to the root-servers. It is the nameserver for a /16. dig www.abcþ.com A @130.161.180.1 - www.abc\xfe.com I fear I may be straying OT, for this is layers 6/7... Hoping for all nameservers to magically break RFC compliance because you think a 'properly coded nameserver' should behave is naive to say the least. PowerDNS may well lowercase your query using functions not guaranteed to do anything useful on 127 characters. Perhaps they are being helpful and change capital-U-umlaut to lowercase-U-umlaut. Who knows. Regards, bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing Traffic Control HOWTO http://netherlabs.nl Consulting
Re: COM/NET informational message
This message explains an upcoming change in certain behavior of the com and net authoritative name servers related to internationalized domain names (IDNs). Put your support people on overtime warnings!
Re: COM/NET informational message
In message [EMAIL PROTECTED], E.B. Dreger writes: EL Date: Fri, 3 Jan 2003 13:44:53 -0500 EL From: Edward Lewis EL The DNS protocol is not 8-bit safe, much less any EL implementations of it. This is because ASCII upper case EL characters are down cased in comparisons. I.e., the My point is there's no need to force chars = 0x7f if DNS servers are properly implemented. If they're not properly implemented, why not, and whose fault is that? Catering to bad or broken implementations instead of following standards is not a good way to ensure interoperability. DNS labels are encoded by a one-octet length representation followed by that number of octets, with no restrictions on the content of the octets. Show me where an RFC says something to the extent of labels and any type of RR MUST NOT contain characters = 0x7f that rescinds 1035. Yes, comparisons are case-insensitive. So what? strcasecmp() works on ASCII strings. Now it must work on new encoding x. Why not let new encoding x be UTF-8, something programmers should support already? Maybe MS-style Unicode encoding? Why add yet another encoding?! I'm sorry, but this is incorrect in many different dimensions. The subject was discussed exhaustively in the IETF's IDN working group; I refer you to its archive for detailed discussions. Among many other things, your assertion about the simplicity of name comparisons is wrong; see draft-hoffman-stringprep-07.txt for a discussion of that issue. As for 8-bit clean DNS -- well, apart from the many possible ways to encode things, there's the issue of the many applications that aren't 8-bit clean, including (per the RFC 822 spec) SMTP. If just use 8-bit clean DNS were sufficient, we'd have been there several years ago. See http://www.ietf.org/html.charters/idn-charter.html for many more pointers. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of Firewalls book)
Re: COM/NET informational message
In a message written on Fri, Jan 03, 2003 at 08:22:11PM +0100, Kandra Nygårds wrote: IDN(A) is an effort to encode unicode into 7-bit DNS-labels, without breaking backward compatibility (too hard). While there originally were a few voices arguing for UTF-8 over the wire, they were few and the consensus today is that IDN(A) is a Good Way to Go(tm). The problem here is that the working groups for different services are going different directions. E-mail base64 encodes Unicode in MIME. Usenet seems to be moving to UTF-8 directly. DNS is using IDN. Woe be the ISP who must provide all these services to their customers, and who's perl scripts must now be able to convert base64-UTF-8-IDN-whatever else is out there just to be able to cobble together all the simple things we do everyday. Most (all?) RFC type standards today specify US-ASCII and/or ISO-8859-1 encoding. This is part of what has made the Internet so popular. I understand the need to support more characters, but let's do that by supporting some base encoding scheme and layering everything on top of that, rather than creating hundreds new encoding schemes, one for each higher level application. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org msg07723/pgp0.pgp Description: PGP signature
Re: US-Asia Peering
I find the interesting that there were immediate assumptions by all the followup posters that the hypothectical mesh wbn suggested would be run by an exchange point operator. Perhaps no public statements were sent by anyone in using similar trans-atlantic services (that are not run by the affected EP operator[s]). It isn't a new solution, and there isn't only one company offering the service. I think exploring any technical issues/experiences in the differing existing deploys and how they would relate to a trans- pacific deploy is quite worthwhile. If anyone using one of the trans-atlantic services wanted to send comments but didn't have enough desire to get a throwaway account subscribed to nanog-post, I'll happily anonomize and repost for you. Just no guarentees on timliness. Cheers, Joe
Re: US-Asia Peering
[EMAIL PROTECTED] (Simon Lockhart) writes: But, given that peering costs are more than just the circuit cost (once you include Exchange Point costs, and colo, etc), why would anyone do this when you can just buy transit for $100/Mbps or less? Because peering is better. There's no way to become DDoS attack-resistant if you buy transit, since no matter how strong you are, your provider will ultimately be weaker. Whether that's because high splay is required to be strong, or because your provider's security team isn't on a two-minute call back, or because your provider has a larger set of things to invest their capital in than your particular path out, doesn't matter. The fact is, no cost-effective transit will ever be as good as the best high-splay peering. I'm going through this at work at the moment, and am having problems justifying staying at the West Coast, having only just justified the East Coast, so going to AP (although it's what I'd want to do), is just way out of the question... OPN (other people's networks) are the second most frequent root cause of connectivity failure. (Network engineers are the most frequent cause, per Vijay's excellent talk in Eugene.) The most reliable access you can get is when you connect to other networks directly rather than using intermediaries. Naturally, with a high number of other networks and of places to meet them, it's only cost effective to peer globally if you have enough traffic and if that traffic's reliability bears directly on your top-line revenue. -- Paul Vixie
Re: COM/NET informational message
SMB Date: Fri, 03 Jan 2003 14:41:45 -0500 SMB From: Steven M. Bellovin SMB I'm sorry, but this is incorrect in many different dimensions. The SMB subject was discussed exhaustively in the IETF's IDN working group; I SMB refer you to its archive for detailed discussions. Among many other SMB things, your assertion about the simplicity of name comparisons is SMB wrong; see draft-hoffman-stringprep-07.txt for a discussion of that Will check these. SMB issue. As for 8-bit clean DNS -- well, apart from the many possible SMB ways to encode things, there's the issue of the many applications that SMB aren't 8-bit clean, including (per the RFC 822 spec) SMTP. If just Good point. SMB use 8-bit clean DNS were sufficient, we'd have been there several SMB years ago. See http://www.ietf.org/html.charters/idn-charter.html SMB for many more pointers. So, if I understand correctly: * RFC 2045/2047 for MIME-aware apps (SMTP, etc.) * UTF-8 for SNMP * IDNA for DNS and the FQHN part of a HTTP request? Yuck. Oh well. I guess this is just another encoding to implement. It would be a shame to try using the same encoding for everything... I'll check out the IDNA spec. Hopefully it at least encodes extended characters in a manner that strcasecmp() works without modification, i.e., upper- and lowercase chars are mapped to 'A' through 'Z' and 'a'-'z'... Eddy -- Brotsman Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~ Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked.
Re: COM/NET informational message
Am I the only one that finds this perversion of the DNS protocol abhorrent and scary? This is straight up hijacking. On Fri, 3 Jan 2003, Verd, Brad wrote: To improve this user experience and to encourage the adoption of an application that supports IDNA, VGRS is announcing a measure intended to stimulate widespread distribution of the i-Nav plug-in. Starting on January 3, 2003, some queries to the com/net name servers that previously failed with a DNS Name Error (NXDOMAIN) response will instead return an address (A) record. Any queries for A records with at least one octet greater than decimal 127 in the second-level label will trigger this A record response. For example, a query for the A record for foo?.com, where ? represents an octet with a value greater than 127, would return an A record rather than NXDOMAIN response. The goal is to match unrecognized domain names generated by browsers attempting to resolve IDNs. Since browsers construct DNS queries for such IDNs using UTF-8 or a local encoding, and since these encodings use octets with all possible values (i.e., from 0 through 255), the presence of octets with values greater than 127 as described above can indicate a web browser's failed IDN resolution attempt. [EMAIL PROTECTED]darwin Flowers on the razor wire/I know you're here/We are few/And far between/I was thinking about her skin/Love is a many splintered thing/Don't be afraid now/Just walk on in. #include disclaim.h
Re: US-Asia Peering
I find the interesting that there were immediate assumptions by all the followup posters that the hypothectical mesh wbn suggested would be run by an exchange point operator. I beg to differ. I said if the exchange-point operator is the one carrying the traffic, at the point where the subsequent comment depended on that assumption. The preceding comments, particularly the ones regarding administrative boundaries and who benefits, do not assume that the exchange point operator carries the traffic: - the message regarding the fact that more administrative boundaries make like more difficult at layer 2 is generic; (stated explicitly for you now) a system with three parties and two administrative boundaries (two EP switch fabrics and a carrier between them) has a *lot* of operational complexity and (I would argue) too many hands on the knobs - when what you are doing is collecting switch *fabrics* together. - the operator of the L3 network that carries inter-EP fabric does not have to be either of the connected EP operators, which is why I called them by the name operator of the L3 network and not EP operator. Perhaps no public statements were sent by anyone in using similar trans-atlantic services (that are not run by the affected EP operator[s]). It isn't a new solution, and there isn't only one company offering the service. That is, as you say, not a new solution. I think exploring any technical issues/experiences in the differing existing deploys and how they would relate to a trans- pacific deploy is quite worthwhile. If anyone using one of the trans-atlantic services wanted to send comments but didn't have enough desire to get a throwaway account subscribed to nanog-post, I'll happily anonomize and repost for you. Just no guarentees on timliness. PAIX has a segment of its existing customer base that use Ethernet extend-o-technology to carry L2 frames between them and the port they have leased on the PAIX switch with an ocean between them. With respect to the exchange point layer 2 fabric, this is no different than connecting a customer switch to the switch fabric (operationally, we see no difference). Certainly some impressions from the folks at the far end of those links would be of interest. Stephen
Re: COM/NET informational message
On Fri, 3 Jan 2003, just me wrote: Am I the only one that finds this perversion of the DNS protocol abhorrent and scary? This is straight up hijacking. It is quite disturbing, you would think that the folks responsible for two of the biggest TLDs on the net would appreciate that not everything is about people typing things into web browsers and that their smart-assed scheme has a variety of possible nasty consequences. It is presumably all about them being able to market a whole bunch of internationalized variants of domain names to earn more $$$, regardless of the technical consequences. And the plugin for IE they are peddling... take a look at the license agreement. http://www.idnnow.com/license.jsp No use for commercial purposes? Automatic updates to allow them to take even more control from users for their own commercial purposes at a later date? No thanks.
Re: COM/NET informational message
At 12:26 -0800 1/3/03, just me wrote: Am I the only one that finds this perversion of the DNS protocol abhorrent and scary? This is straight up hijacking. It's scary but I'm not sure it's abhorrent. The DNS is hit by a lot of bad traffic. E.g., a presentation at the previous nanog (http://www.nanog.org/mtg-0210/wessels.html) mentioned that just about 2% of traffic at the roots is healthy traffic. Over the years, there have been servers for 10.in-addr.arpa just to suck up queries that should have never leaked out the source networks. It's encouraging that there is an effort to try to clean up the reasons for bad traffic. It's scary because in some sense the response is not true (I wouldn't call it hijacking), but when you are trying to cull out incompatible older editions of software, there's no safe route (no 'fail safe' method). And yes, the approach mentioned is optimized for DNS resolution for web access. Hopefully this doesn't trap, for example, unwary SSH connections. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer
Re: COM/NET informational message
On Fri, 3 Jan 2003, just me wrote: Am I the only one that finds this perversion of the DNS protocol abhorrent and scary? This is straight up hijacking. And you find this unusual for Verisign/Network Solutions?
Re: COM/NET informational message
Am I the only one that finds this perversion of the DNS protocol abhorrent and scary? Sounds like a fine interweb kludge It'll just be annoying until other applications aquire similar bodgery as the users will not understand why they can't use it for mail and all brandon
Re: COM/NET informational message
On Fri, Jan 03, 2003 at 12:26:05PM -0800, just me wrote: Am I the only one that finds this perversion of the DNS protocol abhorrent and scary? This is straight up hijacking. I find Microsoft blatantly sending out UTF-8 and 'another local encoding' to nameservers interesting too. The real question is why they don't move to the proposed 7-bit clean mappings themselves. Microsoft are supposed to have quite warm relations with Verisign, even after the certificate spat. Wrt to the stunt that Verisign has employed today, well, they are in this thing to make money, we all know that, and it isn't that bad. They capture wrong queries and fix them up so they can sell more domains. Sure, it looks suspicous and like something that should've been discussed more (I really like announcements about something that will happen on January 3rd on January 3rd). But downright evil? Any query with a 127 character in it is bogus after all. Furthermore, it is a query for '.COM' which they host anyhow. It's not like this is about queries that would otherwise have not ended up at them. No new.net-style tricks. Evil would've been to just start selling UTF-8 domains and force flag day upon the nameserver and mailserver world. Reiterating, the real issue is that this needs a plugin. What happens in that plugin is also very interesting. I suspect source isn't available, who knows what is going on in there. Potentially, the i-Nav plugin hands Verisign the keys of the internet, or at least the keys of Internet Explorer, which is a slightly different thing. Regards, bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing Traffic Control HOWTO http://netherlabs.nl Consulting
Re: COM/NET informational message
At 04:24 PM 1/3/2003, Brandon Butterworth wrote: Am I the only one that finds this perversion of the DNS protocol abhorrent and scary? Sounds like a fine interweb kludge It'll just be annoying until other applications aquire similar bodgery as the users will not understand why they can't use it for mail and all The Internet Explorer plug-in approach they're using is quite reminicent of the new.net folks' methods. The Internet is more than just the web, just as there are many more browsers out there than just Microsoft's. It's so nice Verisign is pushing a solution for COM/NET. I have to wonder if we'll have a different solution in .ORG, another in .BIZ, etc. Folks, this is why we cooperate with competitors and produce standards.
Re: COM/NET informational message
At 17:15 -0500 1/3/03, Daniel Senie wrote: It's so nice Verisign is pushing a solution for COM/NET. I have to wonder if we'll have a different solution in .ORG, another in .BIZ, etc. Folks, this is why we cooperate with competitors and produce standards. Well, the way I look at this is: I hope it's temporary (for everyone's sake) and perhaps most of the problem cases will be in web look ups for names under com and net, so maybe this will knock a lot of the problem cases out. Hopefully. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer
