RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
Michael Richardson wrote: -BEGIN PGP SIGNED MESSAGE- Bill == Bill Manning [EMAIL PROTECTED] writes: Bill Are the apps for which IPv6 is enabled that -can not- Bill use address literals? If so, then Steve is wrong and yes. Both IPv4 and IPv6 web browsers behave differently if you do, for instance: http://192.139.46.2/ vs http://www.sandelman.ca/ A different Host: header is sent, and therefore one gets a different (virtual) web site. Configure your server better than :) (eg use _default_ ) HTTP goes by name, not by IP. Also there is a RFC which says to never use IPv6 IP's in URL's... That's also why IE in XP doesn't support it. Host is now an integral part of HTTP/1.1 and one can't even do without it anymore. Of course, we have no need of this in IPv6, since 2^64 web sites per LAN is plenty, but the protocol still exists to do it. Can we change this in IPv6? Maybe. I don't think many hosters will like configuring 2^64 addresses on their webservers, even though it is possible. One neat thing about this is HTTPS though, as there are now enough addresses for that. But fortunatly there are propositions for enabling the Host header for different SSL sites even while using the same IP (v4+v6 ofcourse). Greets, Jeroen
Re: Evolution in action (Re: Thinking differently)
--On Wednesday, 02 April, 2003 08:27 +0200 Harald Tveit Alvestrand [EMAIL PROTECTED] wrote: ... idiot isps who configured route filters but did not bother to maintain them. darwin at work. the subject is uninteresting, as the study of stupidity is an exceedingly target-rich environment. for those of us who are endlessly fascinated by watching evolution in action - what was the previous usage of 69/8 that led to those filters being installed? (parenthesis: similar things have reportedly happened to people using .info for email - there turns out to be a number of MTAs in the world who have hardcoded all the non-2-letter TLDs, assuming there will be no more, and routinely toss mail from/to the newer ones. They, too, deserve the pain they get; unfortunately they, like the route filterers, don't get all the pain they cause.) See draft-klensin-name-filters-00.txt for a longer explanation of this issue and some cases other than mail-tossing. I'm working on a version that fills in the empty sections and clarifies anything that I can find that isn't clear; comments and suggestions welcome. The evolutionary implications of this one are, however, somewhat less clear than those of the 69/8 case. In the 69/8 case, the ISPs who did the filtering were ultimately subject to attack by their own customers who, presumably, would sooner or later go elsewhere (or cause other harm to the ISP) if the problem wasn't fixed. An MTA-operator whom I'm paying to receive and deliver my mail is (or should be) subject to roughly the same pressures. But, in the TLD case, the victims are mostly those who have registered in the new domains and the help desks of registrars and unrelated servers, neither of whom have significant leverage on the offending ISPs in the non-MTA cases. It might also be part of a good case for not creating new gTLDs except where they are needed for technical reasons (pretty much a null set), but please hold any discussion on that subject on the whining-at-ICANN list of your choice. Spending excessive time on that one of course leads to another example of evolution in action :-(. john
RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
Hi, Jeroen, Are you talking about ftp://ftp.rfc-editor.org/in-notes/rfc2732.txt (PS)? My quick read of this RFC is that it says don't use IPv6 literals without enclosing them in brackets, as in host = hostname | IPv4address | IPv6reference ipv6reference = [ IPv6address ] But that's not quite the same thing you said: never use IPv6 IP's in URL's. If you're talking about another reference, could you provide it? A quick RFC search for IPv6 URL turned up only this RFC... Thanks, Spencer --- Jeroen Massar [EMAIL PROTECTED] wrote: Also there is a RFC which says to never use IPv6 IP's in URL's... That's also why IE in XP doesn't support it. Host is now an integral part of HTTP/1.1 and one can't even do without it anymore.
RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
Spencer Dawkins wrote: Hi, Jeroen, Are you talking about ftp://ftp.rfc-editor.org/in-notes/rfc2732.txt (PS)? My quick read of this RFC is that it says don't use IPv6 literals without enclosing them in brackets, as in host = hostname | IPv4address | IPv6reference ipv6reference = [ IPv6address ] But that's not quite the same thing you said: never use IPv6 IP's in URL's. If you're talking about another reference, could you provide it? A quick RFC search for IPv6 URL turned up only this RFC... Yes, though I can't seem to google up any references. Except for: http://www.microsoft.com/windowsxp/pro/techinfo/administration/ipv6/defa ult.asp Q: How can I force IPv6 connections using my Web browser? SNIP For applications other than Internet Explorer: Connect using a literal IPv6 address. URLs that use the format for literal IPv6 addresses described in RFC 2732, Format for Literal IPv6 Addresses in URLs, are not supported by the version of Internet Explorer provided with Windows XP. There was some discussion about this deprecation as the Techpreviews (Win2k/NT4) did support literal url's. The XP version and up though won't support it to overcome one major 'problem': website 'designers' embedding IP's inside websites to 'speed things up' (go figure). And there where a number of other reasons for deciding so. Unfortunatly I can't find the messages which where sent to a mailinglist about this discussion which also contained why they decided this. Note that wininet.dll doesn't support it that's why IE doesn't either... MS CC'd, they can best explain the rationale behind it. Greets, Jeroen PS: Is 'google' already an official english verb? :)
RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
Jeroen Massar wrote: ... That's also why IE in XP doesn't support it. Making claims that you know nothing about, only exposes your lack of clue. Tony
RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
At 10:18 AM 4/2/2003, Jeroen Massar wrote: Spencer Dawkins wrote: Hi, Jeroen, Are you talking about ftp://ftp.rfc-editor.org/in-notes/rfc2732.txt (PS)? My quick read of this RFC is that it says don't use IPv6 literals without enclosing them in brackets, as in host = hostname | IPv4address | IPv6reference ipv6reference = [ IPv6address ] But that's not quite the same thing you said: never use IPv6 IP's in URL's. If you're talking about another reference, could you provide it? A quick RFC search for IPv6 URL turned up only this RFC... Yes, though I can't seem to google up any references. Except for: http://www.microsoft.com/windowsxp/pro/techinfo/administration/ipv6/defa ult.asp Q: How can I force IPv6 connections using my Web browser? SNIP For applications other than Internet Explorer: Connect using a literal IPv6 address. URLs that use the format for literal IPv6 addresses described in RFC 2732, Format for Literal IPv6 Addresses in URLs, are not supported by the version of Internet Explorer provided with Windows XP. There was some discussion about this deprecation as the Techpreviews (Win2k/NT4) did support literal url's. The XP version and up though won't support it to overcome one major 'problem': website 'designers' embedding IP's inside websites to 'speed things up' (go figure). And there where a number of other reasons for deciding so. Unfortunatly I can't find the messages which where sent to a mailinglist about this discussion which also contained why they decided this. Note that wininet.dll doesn't support it that's why IE doesn't either... MS CC'd, they can best explain the rationale behind it. This line of reasoning troubles me. One of the ways in which numeric IP addresses are useful in URLs is for talking to systems which are not yet fully configured (e.g. configuring routers and such). I'm sure Microsoft's answer to this is Use UPNP but that may not be a universally sufficient answer. Others will say Use Zeroconf which may also not be sufficient. I guess I'm just really uncomfortable requiring name spaces in temporary and disconnected networks as an absolute requirement. Ad-hoc networks are another similar case, where two machines are connected via ad-hoc wireless, bluetooth, firewire, or similar. I'd think it might be useful to be able to serve web pages between two laptops on a train without requiring a naming service to be present. Perhaps that won't be an issue in the brave new world. It just seems to me there is some utility in having this capability (and others must have thought so since we have an RFC describing the formatting). Let's think hard before deciding we are sure there are no useful cases left.
RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
Tony Hain [mailto:[EMAIL PROTECTED] wrote: Jeroen Massar wrote: ... That's also why IE in XP doesn't support it. Making claims that you know nothing about, only exposes your lack of clue. Fortunatly I don't have to resolve to personal accusations to get my point across. I cc:'d the people who really know how the stuff works so they could comment on these statements. :) 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: Tony Hain [mailto:[EMAIL PROTECTED] wrote: Jeroen Massar wrote: ... That's also why IE in XP doesn't support it. Making claims that you know nothing about, only exposes your lack of clue. Fortunatly I don't have to resolve to personal accusations to get my point across. I cc:'d the people who really know how the stuff works so they could comment on these statements. :) I was the IPv6 program manager for what ended up shipping in XP, and literals in wininet didn't make it for lack of testing resources. Tony
Re: addresses in referrals (Re: Thinking differently about namesand addresses)
- ii) pass the other party both the identifier and a current, working address for that endpoint. thus requiring me to continue to use IP addresses in referrals. actually this is a fairly common tactic; indeed. or at least, this isn't the first time it's been seen (and my now-expired I-D describing the best way for apps to deal with NATs mentioned something similar). but it doesn't really solve the problems associated with ambiguous addresses. it still doesn't provide a reliable way to talk to that host in the presence of ambiguous addresses. it only keeps you from mistakenly talking to the wrong host when two hosts use the same address.
Re: Thinking differently about the site local problem (was: RE:site local addresses (was Re: Fw: Welcome to the InterNAT...))
Are the apps for which IPv6 is enabled that -can not- use address literals? If so, then Steve is wrong and the DNS has become critical infrastructure to the working of the Internet. anyone who believes that the DNS is not critical infrastructure for just about every single purpose the Internet is used for is either living in a fantasy world or has redefined the Internet to be something that's strictly at layer 3 and below. agreed. but there's a difference between saying that DNS is critical infrastructure and that it's appropriate to use DNS every time an address is needed. DNS is necessary, not sufficient. Keith
Re: Thinking differently about names and addresses
Keith Moore wrote: From: Keith Moore [EMAIL PROTECTED] HIP only solves part of the problem ... it doesn't provide any way of mapping between that identity and an address where you can reach the host. without a mechanism to map the endpoint identifier to an IP address, such identifiers are useless in referrals between application components. Not completely useless; they would prevent the problem of reaching the *wrong* endpoint. This isn't much help if you have only one address for the endpoint you want; but, if you have a global and a local address for it, and you get the wrong HIP from the host that answers when you use the local address, then you know not to use that one. -- /\ |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:site local addresses (was Re: Fw: Welcome to the InterNAT...))
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. Most OS's require a (unique) hostname to be entered/automatically generated on install False. -- /\ |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_ | \/
A plea for calm
Folks, the debate that was triggered by the site-local debate has touched on a lot of topics that are at the very heart of the design of the Internet, and for which we have to make important decisions in the near future. This is a good and proper discussion to have on this mailing list. The debate has also touched on the site-local decision of the IPv6 working group, a subject to which there are strong emotions attached. The technical debates on that specific topic belong in the IPv6 WG's mailing list; the larger architectural issues belong (IMHO) here. However, I must ask participants to try to remember the guidelines for conduct for the IETF, RFC 3184. In particular: 1. IETF participants extend respect and courtesy to their colleagues at all times. IETF participants come from diverse origins and backgrounds and are equipped with multiple capabilities and ideals. Regardless of these individual differences, participants treat their colleagues with respect as persons--especially when it is difficult to agree with them. 2. IETF participants develop and test ideas impartially, without finding fault with the colleague proposing the idea. We dispute ideas by using reasoned argument, rather than through intimidation or ad hominem attack. Or, said in a somewhat more IETF-like way: Reduce the heat and increase the light I'm sure we all want to. And I'm also sure we all find it hard to adhere to at times. But we need it in order to get work done. One more point: An argument does not become stronger by being repeated more often. Of the 175 senders to this list last month, 20 of us contributed more than half the list traffic. If we have made our position clear, the argument is, I think, stronger if it is not repeated - and silence allows other voices to be heard. Yours for a thoughtful debate, Harald Alvestrand
Re: Thinking differently about names and addresses
A system doesn't have to provide mechanisms to look up mappings fromany-name to any-other-name to be useful; agreed. but it does need to provide such mechanisms in order to provide useful endpoint identifiers. without a mechanism to map the endpoint identifier to an IP address, such identifiers are useless in referrals between application components. Correct, if you assume that there will be situations in which you only have the endpoint identifier and you need the IP address. That's not the only conceivable way of passing around a referal, it's just the one that's closest to being a drop-in replacement for a referal mechanism based on raw IP addresess. well, we've had people saying that you shouldn't pass around the IP address. obviously the new identifier doesn't help you avoid passing around the IP address if you can't get the IP address from the identifier.
Re: Thinking differently about names and addresses
without a mechanism to map the endpoint identifier to an IP address, such identifiers are useless in referrals between application components. Not completely useless; they would prevent the problem of reaching the *wrong* endpoint. This isn't much help if you have only one address for the endpoint you want; but, if you have a global and a local address for it, and you get the wrong HIP from the host that answers when you use the local address, then you know not to use that one. true. but requiring apps to determine which of several potentially ambiguous (or obsolete) addresses is the one that reaches the intended peer by trial-and-error does not strike me as an efficient or desirable strategy.
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. I do, however, also remember a discussion on one of the IPv6 mailing lists about this, and it seemed that there were several members of the IPv6 community at large who thought it was great that we weren't currently supporting them. Apparently there are those who think hard-coding IP addresses (of any version) in URLs is a bad idea. yes, there are those who think that it's desirable to force all apps to suffer the delays and unreliability of DNS every time a connection is established. they are deluded. Keith
Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
% Are the apps for which IPv6 is enabled that -can not- % use address literals? If so, then Steve is wrong and % the DNS has become critical infrastructure to the working % of the Internet. % % anyone who believes that the DNS is not critical infrastructure for just % about every single purpose the Internet is used for is either living in a % fantasy world or has redefined the Internet to be something that's % strictly at layer 3 and below. % % agreed. but there's a difference between saying that DNS is critical % infrastructure and that it's appropriate to use DNS every time an address is % needed. DNS is necessary, not sufficient. % % Keith to pass bits, in the IPv4 world, DNS is -NOT- critical. no application forbids address literals and every app will allow address literals to be used. Couple this with the fact that IPv4 addresses are within the scope of human comprehension, i.e. I can remember 128.9.160.160 with IPv6, the addresses are long enough to not be human friendly, e.g. 2001:0478:6: is about as much as I remember on my own... I must use the DNS or my little yellow sticky note to complete the address. And there are intimations that some applications now forbid the use of address literals, even if bracketed. Sounds like you both are arguing that the DNS has become embedded and the applications that use IP are unusable without a working DNS. This assertion, if true, has ramifcations beyond a simple requirement to have the latency of an extra lookup against a third party. (Can you say Death to e2e!... sure you can :) --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise).
Re: Thinking differently about the site local problem (was: RE:site local addresses (was Re: Fw: Welcome to the InterNAT...))
Sounds like you both are arguing that the DNS has become embedded and the applications that use IP are unusable without a working DNS. as a practical matter, this was true even in IPv4. yes, you can often use address literals in either v4 or v6 apps, but this isn't practical for ordinary users on an ordinary basis. and in both v4 and v6, several essential apps (e.g. email, the web) have explicit dependencies on DNS. yes you can use address literals in email addresses and URLs but there is no assurance that an email address or URL with an address literal is equivalent to the same address or URL with a domain instead of the address. Both email and the web define their resources in relation to a DNS name, not relative to a host or address. of course it is possible to write apps that do not use DNS, but this is rarely done. Keith
Re: Thinking differently about the site local problem (was: RE:site local addresses (was Re: Fw: Welcome to the InterNAT...))
There was some discussion about this deprecation as the Techpreviews (Win2k/NT4) did support literal url's. The XP version and up though won't support it to overcome one major 'problem': website 'designers' embedding IP's inside websites to 'speed things up' (go figure). perfectly reasonable thing to do. browsers that don't support it are broken.
RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
Keith Moore [mailto:[EMAIL PROTECTED] wrote: There was some discussion about this deprecation as the Techpreviews (Win2k/NT4) did support literal url's. The XP version and up though won't support it to overcome one major 'problem': website 'designers' embedding IP's inside websites to 'speed things up' (go figure). perfectly reasonable thing to do. browsers that don't support it are broken. It's perfectly reasonable to not support RFC2732? or? Greets, Jeroen
Re: Thinking differently about the site local problem (was: RE:site local addresses (was Re: Fw: Welcome to the InterNAT...))
There was some discussion about this deprecation as the Techpreviews (Win2k/NT4) did support literal url's. The XP version and up though won't support it to overcome one major 'problem': website 'designers' embedding IP's inside websites to 'speed things up' (go figure). perfectly reasonable thing to do. browsers that don't support it are broken. It's perfectly reasonable to not support RFC2732? or? it's perfectly reasonable for sites to use address literals in URLs referenced by their web pages.
Re: Thinking differently about the site local problem(was: RE: site local addresses (was Re: Fw: Welcome to theInterNAT...))
--On Wednesday, 02 April, 2003 11:23 -0500 Keith Moore [EMAIL PROTECTED] wrote: Sounds like you both are arguing that the DNS has become embedded and the applications that use IP are unusable without a working DNS. as a practical matter, this was true even in IPv4. yes, you can often use address literals in either v4 or v6 apps, but this isn't practical for ordinary users on an ordinary basis. and in both v4 and v6, several essential apps (e.g. email, the web) have explicit dependencies on DNS. yes you can use address literals in email addresses and URLs but there is no assurance that an email address or URL with an address literal is equivalent to the same address or URL with a domain instead of the address. Both email and the web define their resources in relation to a DNS name, not relative to a host or address. At least in the case of email, it is important to be precise about this, because we have a clear evolutionary trend: (i) RFC 2821 can be read (and was intended to be read) to prohibit the use of an address literal in a HELO or EHLO command unless the relevant host has no DNS name. (sections 3.6, 4.1.1.1, 4.1.4) (ii) The use of address literals is described as a mechanism to bypass a barrier, not one for normal use (RFC2821, section 4.1.3) (iii) On the other hand, the address literal should still be provided in the From clause of a Received field. Received field information is expected to not be picked up by other software and protocols, but the inclusion of address information there is very leak-friendly. Contrast this with RFC 821, which doesn't seem to strongly argue that explicit address use is undesirable. of course it is possible to write apps that do not use DNS, but this is rarely done. Yep. And as pointed out earlier, we have pushed back strongly against such protocol proposals and implementations. john
RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
Keith Moore wrote: Sounds like you both are arguing that the DNS has become embedded and the applications that use IP are unusable without a working DNS. as a practical matter, this was true even in IPv4. yes, you can often use address literals in either v4 or v6 apps, but this isn't practical for ordinary users on an ordinary basis. and in both v4 and v6, several essential apps (e.g. email, the web) have explicit dependencies on DNS. yes you can use address literals in email addresses and URLs but there is no assurance that an email address or URL with an address literal is equivalent to the same address or URL with a domain instead of the address. Both email and the web define their resources in relation to a DNS name, not relative to a host or address. of course it is possible to write apps that do not use DNS, but this is rarely done. Fortunatly we still all are humans and like names, not numbers :) We'll let the numbers to computers (big fast math machines) Our brains are more advanced and just can't cope with numbers any more ;) Greets, Jeroen
Re: Thinking differently about the site local problem (was: RE:site local addresses (was Re: Fw: Welcome to the InterNAT...))
(i) RFC 2821 can be read (and was intended to be read) to prohibit the use of an address literal in a HELO or EHLO command unless the relevant host has no DNS name. (sections 3.6, 4.1.1.1, 4.1.4) these days it's sort of odd to think that a host has a distinguished DNS name - hosts quite ordinarily have either an emphemeral DNS name, multiple DNS names, or no DNS name. (ii) The use of address literals is described as a mechanism to bypass a barrier, not one for normal use (RFC2821, section 4.1.3) right. about the only reasonable use of an address literal is for testing, or to reach the postmaster at a particular host associated with a particular address (since postmaster is the only address that is guaranteed to be valid when associated with an address literal - and even this is often not true in practice) (iii) On the other hand, the address literal should still be provided in the From clause of a Received field. Received field information is expected to not be picked up by other software and protocols, but the inclusion of address information there is very leak-friendly. this is different than using address literals in addresses. email addresses are defined relative to DNS names because you cannot properly send mail to an email address without an MX lookup. OTOH MTAs are still expected to be hosts with addresses. of course it is possible to write apps that do not use DNS, but this is rarely done. Yep. And as pointed out earlier, we have pushed back strongly against such protocol proposals and implementations. many apps that are used in practice are not standardized; we need to be careful about believing that what's good for standard apps is good for every app. I could certainly make a case for some apps to have their own naming systems and their own name-to-address lookup mechanisms independent of DNS, or more generally, for alternate means of mapping resource names (say URNs) to IP addresses that did not involve DNS names or DNS queries. But it's difficult to believe that such apps would not employ DNS names at all - if nothing else, for initial configuration.
Re: Thinking differently about the site local problem (was: RE:site local addresses (was Re: Fw: Welcome to the InterNAT...))
of course it is possible to write apps that do not use DNS, but this is rarely done. why not just embed the ip addresses in the data payloads? death to nats! :-)
