- Test - lists.nanog.org

RE: DECNet over IP?
by Stillman, Kevin 14 Mar '01

14 Mar '01

Thank you all for your advise. Unfortunately I am working with a Bay/NortelNetwork environment. Nortel's implementation of GRE tunneling does not support DECNet Phase IV. The kludge of a solution that has been proposed to me by Nortel is transitioning the native DECNet phase IV communication to DECNet phase V, which works in OSI, then tunnel the OSI using GRE. I'm going to try it in a lab, but I have serious doubts about how well it will work. It is a scary proposition. If anyone has actually seen this work I love to hear from you. The solution that I need to create is one that will not require the DEC administrators on LANs using our WAN for DECNet interconnectivity to make any changes on their VAXes, printers... etc. That means Compaq or third party software on the VAX cannot be part of the solution. Basically it needs to be transparent to the LAN. If Cisco is capable of tunneling DECNet phase IV right out of the box, then I think I may have my solution. This would mean the router would run DECNet on the ethernet and run a GRE tunnel over the IP network on the sync port(s). Does this sound like the right idea? Thanks again! Kevin

1 0

Re: Statements against new.net?
by Simon Higgs 14 Mar '01

14 Mar '01

At 01:23 PM 3/13/01 -0500, you wrote: >To be >precise, what is your response to this, the second paragraph of the >document? > > Put simply, deploying multiple public DNS roots would raise a very > strong possibility that users of different ISPs who click on the same > link on a web page could end up at different destinations, against > the will of the web page designers. Here it is, a proposed supplement to RFC2826: http://www.ietf.org/internet-drafts/draft-higgs-root-defs-00.txt It's called "cat herding". :-) The short answer is that there's a far better chance of coordinating the alt.roots into a single unified root, than suffering the consequences of a permanent and very real root fragmentation by ignoring them. Best Regards, Simon -- DNS is not a sacred cow that cannot be replaced by something better.

1 0

Re: Statements against new.net?
by Simon Higgs 14 Mar '01

14 Mar '01

Hank, We tell them to use the ORSC root as it is the most comprehensive one out there. Once the collisions from New.net have been ironed out, the non-colliding new TLDs will be put in the ORSC root if they are not already there. FYI, there's an IETF draft on the guidelines for avoiding multiple-root collisions here: http://www.ietf.org/internet-drafts/draft-higgs-root-defs-00.txt Feedback welcome. >Do any ISPs or web hosting companies have publically available statements >on their web sites stating that they will not support the new new.net >domains and why they won't? I am getting more requests from users to >change our DNS root servers to support this and wanted to see what others >tell their users. Any IETF/ICANN statement available? > >Thanks, >Hank Best Regards, Simon -- DNS is not a sacred cow that cannot be replaced by something better.

1 0

RE: Statements against new.net?
by Roeland Meyer 14 Mar '01

14 Mar '01

> From: Valdis.Kletnieks(a)vt.edu [mailto:Valdis.Kletnieks@vt.edu] > Sent: Tuesday, March 13, 2001 12:03 PM > I fail to see how RFC2826 is in any way "political". Upon > careful re-reading > it boils down to: > > If you use one root, everybody agrees what things look like. > > If you use multiple roots, what people will see depends on > which root they ask. > > How is this political? By the sheer fact that they included a non-technical value-judgment.

8 10

RE: Statements against new.net?
by Mathew Butler 14 Mar '01

14 Mar '01

Y'know, I upon reading this again, I have to point something out: The current set of root servers is not administered by a unique naming authority. The root zone itself is administered by the unique naming authority. The zone needs to have a Single Point of Contact. The root servers themselves need to have a unique PoC for each, and it is much more desirable to the Internet at large to each root server administered by a separate entity -- be it vix.com, isi.edu, APNIC, whatever and whoever has the bandwidth, knowledge, expertise, and money to support it. But the zone itself needs to have an entity who is ultimately responsible for what goes into the zone and what doesn't. Now, I'm going to say something here (and these are my own opinions): In the context of Certifying Authorities for SSL certificates, we have multiple, unique roots. Lots of them. In Internet Explorer alone, there are more than 80 that are embedded upon installation, and my set of CA roots is different from your set of CA roots [this is a fact, since I run a CA internal to my company]. This is roughly akin to the idea of including a root.zone on each client, that makes it almost impossible to determine which roots each client trusts. [PLEASE do not say anything about 'barrier to entry' or 'a trusted root can't sign an intermediate root' -- the first is high indeed, and the second is patently false. I'm only bringing this up to explain a concept.] Now, in the case a website has a CA that doesn't match anything that's in the browser, there's an interactive dialog to determine which action to take -- whether to accept it anyway, or to cancel the connection. In the event of multiple, conflicting TLDs, though, there's no way for that interactive exchange with the user to occur. Say I have an email address of 'winged(a)wolf.animal-lover', and someone doesn't like the way the 'animal-lover.' TLD is being run, so they set another root up with the 'animal-lover.' TLD and assign it to someone else. And one of my friends is on an ISP that uses this alternate root. And my friend tries to send me an email. So, where will mail to my mail address 'winged(a)wolf.animal-lover' go to? The client on my friend's system will send it to the ISP's mail server, which will look up MX wolf.animal-lover on the conflicting root. Which will almost certainly not be the MX wolf.animal-lover that I use. So at best it gets bounced, at worst it goes to a completely uninvolved third party -- and my friend would never even know. (And neither would I.) And the next time my friend saw me, he'd ask me about it, and I'd have to say "it works for me", and then we'd spend a lot of time figuring out where the problem was. And then we'd yell and scream and curse and swear at the anarchy that led to Usenet being what it is today... and most likely create our own little VPN for the exchange of mail between our sites. Do we really -want- more VPN traffic flowing over the backbone? An implicit assumption made on the Internet today is that "e-mail addresses will be unique and will route to the proper person unless there is a technical reason that that is impossible". (Don't laugh, this is the view of everyone I've ever talked with -- they don't think it's possible that someone could take over their email account.) So 'mbutler(a)tonbu.com' will always route to me, unless the MX is wrong or my mail server's down. However, if we have conflicting zones, we'll never be able to guarantee communication is going to work properly across the Internet, and we'll be forced back to phone or pen&paper for REALLY important stuff. (Which will also have the effect of completely removing the trust essential for e-commerce to occur, since it'll never be truly possible to determine which TLD root you're going through.) It may be possible for larger corporations to buy through ALL registries for a given TLD... but that is inefficient, and if someone set up a registry for net. or com. or org. or mil., and then set up an alternate root for it, and someone else used that root... can you imagine the carnage? (Especially given ~$20/year per registry.) Name hijacking would be what it is, and there are laws against it (all the trademark laws, much less the fraud, malfeasance, misrepresentation, and many others) all around the world. Personally, I hope that the ICANN files a misrepresentation/fraud suit against new.net, and soon... though ICANN's way of doing things must not be condoned, at this moment the new.net system is NOT the correct way to fix the issue. -Mat Butler Speaking for himself, not his company -----Original Message----- From: Patrick Greenwell [mailto:patrick@cybernothing.org] Sent: Tuesday, March 13, 2001 8:40 PM To: Valdis.Kletnieks(a)vt.edu Cc: nanog(a)merit.edu Subject: Re: Statements against new.net? "...That one root must be supported by a set of coordinated root servers administered by a unique naming authority."

1 0

FW: DECNet over IP?
by Timothy R. McKee 14 Mar '01

14 Mar '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -----Original Message----- From: Timothy R. McKee [mailto:trm3@nuvox.net] Sent: Wednesday, March 14, 2001 12:12 To: Simon Lockhart Subject: RE: DECNet over IP? - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Back a few years ago the Multinet stack for VMS supported DECNet/TCP interworking... Don't know who has the product now... If it is truly VAX and not alpha, the old CMU implementation had a DECNet driver. Tim - - -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Simon Lockhart Sent: Wednesday, March 14, 2001 11:30 To: Stillman, Kevin Cc: 'nanog(a)merit.edu' Subject: Re: DECNet over IP? >Has anyone had any experience successfully getting native DECNet packets >encapsulated in an IP packet and transmitted over an IP network? The >solution I am trying to create will allow VAXes to continue to talk DECNet >on their LANs and have the ability to communicate with DECNet areas on a WAN >via IP. Essentially we are try to remove the DECNet protocol from our >intranet while not disrupting location's DECNet configurations. I've not tried it, but my gut reaction would be to use GRE tunnels. Have you looked on cisco.com for sample configs? Simon - - -- Simon Lockhart | Tel: +44 (0)1737 839676 Internet Engineering Manager | Fax: +44 (0)1737 839516 BBC Internet Services | Email: Simon.Lockhart(a)bbc.co.uk Kingswood Warren,Tadworth,Surrey,UK | URL: http://support.bbc.co.uk/ - -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com> iQA/AwUBOq+mWhRIXzEQLahvEQK+6ACgqYZoc23CJoKBBTnOhwYhS8cdczIAoKR5 euFqSHT+jko90sZNE8Q5Bk2W =Ncri - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com> iQA/AwUBOq+uWBRIXzEQLahvEQIyMwCcCJmFrXtcln3VrXumw+wzDUSzrC4An0Oh GN6mImDsbwExEqfzqqJDrgSW =O+xu -----END PGP SIGNATURE-----

2 1

Re: DECNet over IP?
by CARL.P.HIRSCH＠sargentlundy.com 14 Mar '01

14 Mar '01

http://www.cisco.com/univercd/cc/td/doc/cisintwk/idg4/nd2002.htm#xtocid2292… grep GRE "Cisco's Generic Routing Encapsulation (GRE) multiprotocol carrier protocol encapsulates IP, CLNP, IPX, AppleTalk, DECnet Phase IV, XNS, VINES, and Apollo packets inside IP tunnels."... assuming you're running Cisco gear, anyhow. -carl hirsch network analyst sargent & lundy llc

1 0

RE: Statements against new.net?
by Daryl G. Jurbala 14 Mar '01

14 Mar '01

The last thing we need is DNS functioning like IRC, which has much of the same types of problems that a thing like new.net introduces. While I would like to think that their intentions are nothing other than to force progress, and possibly make a buck or two at it, intellectually I have to believe that it is much more sinister than that, and it's simply the equivalent of a land grab. I think I'm going to start my own fake TLD provider, with the same TLDs and new.net. I'm going to be r00thack.org, and team up with all of the ISP's that operate out of their garages. Anybody with a nameserver running on a 486 over a 28.8k dialup want in on this? Daryl G. Jurbala Manager of IT Infrastructure Tel 215.823.5077 Fax 215.823.5062 http://www.Antiphony.com -----Original Message----- From: Scott Francis [mailto:scott@virtualis.com] Sent: Wednesday, March 14, 2001 2:13 AM To: Patrick Greenwell Cc: Scott Francis; Stephen J. Wilcox; Randy Bush; Hank Nussbacher; nanog(a)merit.edu Subject: Re: Statements against new.net? [...] This whole matter boils down to one question - that being, what way is the Right Way to operate DNS or its equivalent? It seems to me (and a few others) that, logically, any hierarchical system _must_ have an ultimate authority - not 2 or 3 or 27, which is essentially what new.net is trying to do: create an alternate ultimate authority. How exactly will a user know which site foo.com takes them to, if new.net's response and the rest of the Internet's response a la *.root-servers.net don't jibe? The concept of unique and separate domains breaks down when you have conflicting responses to the question, "Where does this domain actually point?" [...]

1 0

Re: Statements against new.net?
by Sean Donelan 14 Mar '01

14 Mar '01

On Tue, 13 March 2001, "Brett Frankenberger" wrote: > > On Tue, 13 March 2001, "Steven M. Bellovin" wrote: > > > Put simply, deploying multiple public DNS roots would raise a very > > > strong possibility that users of different ISPs who click on the same > > > link on a web page could end up at different destinations, against > > > the will of the web page designers. > > > > Its not really the "will of the web page designers." If this becomes > > popular, I suspect most web page designers will start using dotted-quad > > addresses inside their HTML URLs on their web pages. So clicking on a > > link on a web page will go to were the web page designer directs you. > > Except for NAT strangeness, IP Address are mostly globally unique. > > Fine. Then we have a technical issue associated with "all the links > break when a web server is moved to a different IP address because > whoever was hosting it had to renumber", and it's companion "I can fix > the links because there's no way to know what the new IP address is". > > Since the reason renumbering is a reality are technical -- or, are at > least presented that way -- the need for a single DNS root remains > technical. Generally the web page author is nominally in charge of moving a web page from one IP server address to a different IP server address. If this happens, they could change (perhaps through a script) all the links on the page to use the new IP address just like they currently renumber all the other things which must change when moving. In general, people clicking on URL's have no idea what the anchor URL is. Unless you look at the HTML source, you see the text not the URL. Of all the protocols which use DNS, HTTP/HTML seems to be the easiest for users to use something else. TELNET, FTP, and SMTP have much more user-visible DNS names, and are therefor much more difficult to change. There are several inter-related issues (as always): - Long-term stability of the identifier - Global uniqueness (within the relevant domain) - Easy for humans to remember - Simple for machines to process

1 0

Re: Statements against new.net?
by Steven M. Bellovin 14 Mar '01

14 Mar '01

In message <Pine.BSF.4.21.0103131010030.41040-100000@localhost>, Patrick Greenw ell writes: > >On Tue, 13 Mar 2001, Randy Bush wrote: > >> >> > Do any ISPs or web hosting companies have publically available statements >> > on their web sites stating that they will not support the new new.net >> > domains and why they won't? I am getting more requests from users to >> > change our DNS root servers to support this and wanted to see what others >> > tell their users. Any IETF/ICANN statement available? >> >> RFC 2826 IAB Technical Comment on the Unique DNS Root > >It would better be termed "IAB Political Comment on the Unique DNS Root." > As someone who was on the IAB at the time that RFC was written, I disagree -- there were *no* political discussions. But that's an unverifiable assertion. Instead, could you point at anything in the document you perceive as "political" rather than technical? To be precise, what is your response to this, the second paragraph of the document? Put simply, deploying multiple public DNS roots would raise a very strong possibility that users of different ISPs who click on the same link on a web page could end up at different destinations, against the will of the web page designers. --Steve Bellovin, http://www.research.att.com/~smb

8 11