RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
John Stracke wrote: Jeroen Massar wrote: Ad-hoc networks are another similar case, where two machines are connected via ad-hoc wireless, bluetooth, firewire, or similar. In any other way do you like remembering and typing over 128bit addresses?? :) :: is your friend. If you're building an ad hoc, point-to-point network, you can pick convenient addresses. :: as in all 0's which corresponds to 'not bound'? I don't see how you are going to communicate between two hosts with a unbound IP. Especially in a ad-hoc network where everything should be configured automatically. Most OS's require a (unique) hostname to be entered/automatically generated on install False. And is there any reasoned argument instead of the simple 'false'? Greets, Jeroen
Re: Thinking differently about the site local problem (was: RE:site local addresses (was Re: Fw: Welcome to the InterNAT...))
Jeroen Massar wrote: John Stracke wrote: Jeroen Massar wrote: Ad-hoc networks are another similar case, where two machines are connected via ad-hoc wireless, bluetooth, firewire, or similar. In any other way do you like remembering and typing over 128bit addresses?? :) :: is your friend. If you're building an ad hoc, point-to-point network, you can pick convenient addresses. :: as in all 0's which corresponds to 'not bound'? No, as in a string of 0s. If you set up your own isolated network, you can make one host be 1::1 and the other 1::2. Most OS's require a (unique) hostname to be entered/automatically generated on install False. And is there any reasoned argument instead of the simple 'false'? It seems pretty obvious: no OS can require a unique hostname at install time, because it has no way of checking uniqueness. The Unices I've installed (various versions of Solaris and Linux), even if they prompt for a hostname, will accept the default of localhost.localdomain. In addition, many, many machines (especially those bought preinstalled) are installed from standardized images, and have standardized hostnames. -- /\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |God does not play games with His loyal servants. Whoo-ee,| |where have you *been*? --_Good Omens_ | \/
Re: Thinking differently about the site local problem (was: RE: sitelocal addresses (was Re: Fw: Welcome to the InterNAT...))
Keith Moore wrote: Then there's the problem that when a 800-pound gorilla ships code, that code largely defines expectations for what will and will not work in practice - often moreso than the standards themselves. Strange as I feel defending Microsoft, I actually think it's commendable that they implemented IPv6 at all; it's not as if there's a lot of market demand for it yet. From that viewpoint, it's not surprising that they gave IPv6 address literals a low priority. (Personally, I would've implemented address literals *first*, so that, if I ran into a bug, I could isolate whether it was in DNS lookup or not. Would've saved time in the long run, since debugging takes longer than coding.) -- /\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |God does not play games with His loyal servants. Whoo-ee,| |where have you *been*? --_Good Omens_ | \/
v6 support (was Re: Thinking differently about the site localproblem (was: RE: site local addresses (was Re: Fw: Welcome to theInterNAT...)))
Then there's the problem that when a 800-pound gorilla ships code, that code largely defines expectations for what will and will not work in practice- often moreso than the standards themselves. Strange as I feel defending Microsoft, I actually think it's commendable that they implemented IPv6 at all; it's not as if there's a lot of market demand for it yet. I'm certainly glad that they've done so; however most of their competitors are shipping v6 also, and some have been doing so for considerably longer than MS. About the only major vendor that isn't shipping v6 seems to be Palm (shame on them!).
Re: v6 support (was Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)))
In message [EMAIL PROTECTED], Keith Moore writes: Then there's the problem that when a 800-pound gorilla ships code, that code largely defines expectations for what will and will not work in practice- often moreso than the standards themselves. Strange as I feel defending Microsoft, I actually think it's commendable that they implemented IPv6 at all; it's not as if there's a lot of market demand for it yet. I'm certainly glad that they've done so; however most of their competitors are shipping v6 also, and some have been doing so for considerably longer than MS. About the only major vendor that isn't shipping v6 seems to be Palm (shame on them!). Keith, I can't get upset about Microsoft declining to ship poorly-tested code. Given how many security holes are due to buggy, poorly-tested programs, I applaud anyone who takes that seriously. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of Firewalls book)
Re: v6 support (was Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)))
Steve I can't get upset about Microsoft declining to ship poorly-tested Steve code. Given how many security holes are due to buggy, poorly-tested Steve programs, I applaud anyone who takes that seriously. Well, suppose they were to ship IPv6 without IPsec, on the grounds that they didn't have the testing resources for IPsec. Would you still be applauding them? Or would you be questioning whether they have their priorities right? Features always fall off due to the inability to allocate sufficient testing resources, but a vendor does have some choice over which features those are.
Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
On 2 Apr 2003 at 18:10, Keith Moore wrote: The lack of IPv6 literal address support in the version of wininet.dll that shipped with Windows XP was for reasons of engineering expediency, in other words, MS deliberately shipped a broken product. Oh, look, release notes, known issue statements, bugtracker entries... Seems like everybody is deliberately shipping broken products... -- Fredrik Nyman PacketFront Sweden AB http://www.packetfront.com/
Re: Thinking differently about the site local problem (was: RE:site local addresses (was Re: Fw: Welcome to the InterNAT...))
The lack of IPv6 literal address support in the version of wininet.dll that shipped with Windows XP was for reasons of engineering expediency, in other words, MS deliberately shipped a broken product. Oh, look, release notes, known issue statements, bugtracker entries... Seems like everybody is deliberately shipping broken products... Yeah, I was chastised in private mail for shooting the messenger, and appropriately so. It is a bit difficult for me to understand how support for address literals could be considered such a low priority that it could be omitted from a shipping product. Recently when I wrote an app that used v6 and urls, the first routine I wrote was one that would take either an address literal or a DNS name, plus a port number, and return a properly filled-in sockaddr structure (no, getaddrinfo by itself isn't sufficient), and the second one I wrote was one that would parse a URL and extract either a DNS name or address literal from that. Writing both routines, and the test cases, and testing the routines on several different platforms took about 2 hours. Admittedly I'm a bit biased. I've measured the percentage of email delivery failures due to various reasons and discovered that DNS misconfiguration was high on the list (MTA miscnfiguration was also high). I've also attempted to measure the amount of delay caused by DNS lookups. So I understand better than most why it's important - for both diagnostic and performance reasons - to support address literals. That and I suspect there's a philosophical difference in writing APIs. I believe in thinking hard about what an API needs to do before writing it, so that the API once implemented will be able to be used for a wide set of purposes. That and I try hard to only have to implement the API once, because the overhead in context switching my brain back to the API when I need to add functionality to it is almost certainly larger that the effort required to completely implement the API the first time. If it's too difficult to implement it completely, there's probably something wrong with the design. I do understand and use stubbing, but I regard that as a technique to be used for quick prototypes that are going to be discarded anyway. I also understand the notion of biasing the testing toward the most frequently-used features on the assumption that such testing will uncover the most common bugs. But there are important features that are not frequently used, and there are bugs that are important to fix even though they are in seldom-used code. Features used for diagnostics, and security bugs are good examples of these. Then there's the problem that when a 800-pound gorilla ships code, that code largely defines expectations for what will and will not work in practice - often moreso than the standards themselves. So if MS ships code that doesn't support address literals, then nobody will attempt to use address literals unless they can detect that the client isn't using MS code. For this and other reasons, I believe that 800-pound gorillas have a greater responsibility than their competitors to ship code that works properly. OTOH, servers that take the trouble to recognize that the client isn't a MS client can provide their clients with significantly better response time by giving those clients address literals in internal references (either in HTTP referrals or in HTML).
