Re: GUPI/GUSLs and DNS
I do not believe it is either necessary or appropriate to have DNS provide only addresses that are reachable by the party making the query. The question in my mind is whether it is appropriate to put addresses that are by design not globally reachable in the DNS. Nor should DNS be used as a mechanism for trying to communicate policy. It is not reasonable to assume that the party making the query is the one that will be using the results of that query. Nor is DNS capable of keeping track of who can talk to whom. And for that matter, applications expect consistent behavior from DNS. The results of DNS queries should be consistent everywhere. I agree with that sentence. If DNS returns addresses for a service that are not reachable, then the client will find that out when it is unable to reach that service (hopefully via an ICMP prohibited response rather than via a timeout). The now expired draft-ietf-dnsop-dontpublish-unreachable-03.txt recommends against this. Intentionally putting IP addresses that are not globally reachable in the DNS means that there will be delays due to timeouts, since there isn't an ICMP prohibited that makes TCP immediately give up. Sure, we could define one and think about the security issues. But worse, the interaction between MX and A* records can cause more spectacular failures. Assume a MX for *.example.com with points at mail.example.com for mail.example.com has both global and GUPI addresses. Works so far, perhaps with timeouts. But when server.example.com has that is just GUPI then mail delivery to [EMAIL PROTECTED] will fail when the GUPI is not reachable, right? Erik IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: unique enough [RE: globally unique site local addresses]
Michel Py wrote: Erik Nordmark wrote: On the enterprise side I can see that folks have been bitting or are concerned about renumbering costs if they were to use PA addresses. But I don't have any data on how many consider having one PA prefix per ISP good enough since it allows some graceful cutover when changing ISPs. Not many. We have had many contributions that multiple addresses are a no-go to begin with. Er, multiple addresses are part of the IPv6 architecture. And SCTP deals with them, even if TCP doesn't. It may be something new and different, but there's no way you can declare it a no-go. Brian IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: comments on draft-hinden-ipv6-global-site-local-00
Pekka Savola wrote: Hello, A few quick comments on the draft. Sorry for lack of content. Substantial: This document proposes an approach to allocating IPv6 Site-Local address so they are globally unique and routable only inside of a site. == it would be good to go a bit more in depth to how this is actually a problem. For some it surely isn't; if they don't need to prepare for site-mergers, for example. Can you define the class of sites that absolutely, definitely, until the end of time, are guaranteed not to merge? Brian IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: unique enough [RE: globally unique site local addresses]
On Thu, Jan 23, 2003 at 10:04:13AM +0100, Brian E Carpenter wrote: Er, multiple addresses are part of the IPv6 architecture. And SCTP deals with them, even if TCP doesn't. It may be something new and different, but there's no way you can declare it a no-go. And we also have many different classes of multihoming scenario (just as we do with transition). There's unlikely to be one single shoehorn solution. Tim IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Proposal for site-local clean-up
This does not answer the question of why you assume that ISPs will change their business models under v6. I said: |The ISPs business model is about service differentiation. And I agree that they most likely will continue with service differentiation. But I think they can change the *realization* of service differentiation from using IP addresses to using something else, just as long as the new mechanism provides what they need. Erik IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: comments on draft-hinden-ipv6-global-site-local-00
On Thu, 23 Jan 2003, Brian E Carpenter wrote: Substantial: This document proposes an approach to allocating IPv6 Site-Local address so they are globally unique and routable only inside of a site. == it would be good to go a bit more in depth to how this is actually a problem. For some it surely isn't; if they don't need to prepare for site-mergers, for example. Can you define the class of sites that absolutely, definitely, until the end of time, are guaranteed not to merge? Well, it depends on quite a bit about which is the usage model for site-locals. For example, home nets probably don't merge if we would mandate that site-locals should not cross home-to-office VPN's. But of course, there can be not absolute guarantee. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: GUPI/GUSLs and DNS
On Thu, 23 Jan 2003 09:10:08 +0100 (CET) Erik Nordmark [EMAIL PROTECTED] wrote: I do not believe it is either necessary or appropriate to have DNS provide only addresses that are reachable by the party making the query. The question in my mind is whether it is appropriate to put addresses that are by design not globally reachable in the DNS. As long as the addresses are unambiguous, I don't think this causes much harm. Putting a name-to-address binding in the DNS is a statement of fact - address A is associated with name N for length of time T - not an assurance that anyone who can lookup the DNS name can use the service associated with that name. The latter depends on several things - not only being able to reach the address but having permission to use the service, being able to authenticate to the service, being able to speak the appropriate protocols, etc. But worse, the interaction between MX and A* records can cause more spectacular failures. Assume a MX for *.example.com with points at mail.example.com for mail.example.com has both global and GUPI addresses. Works so far, perhaps with timeouts. But when server.example.com has that is just GUPI then mail delivery to [EMAIL PROTECTED] will fail when the GUPI is not reachable, right? Yes it will. But not because you listed a GUPI in the DNS, but because you failed to provide and advertise a server that was reachable by somebody who wanted to send you mail. Even then, you're not under any obligation to accept mail from anyone who wishes to send it to you (RFC 2821 is quite clear on this - though indefinitely returning temporary failure would be considered antisocial). Let's put the question in a different light. In a sense, both v4 and v6 addresses are scoped - you cannot generally expect that a v4 host can communicate with a v6 host or vice versa. Attempts to provide general-purpose conversion between the two have fallen into some degree of disfavor because they introduce problems similar to those of NAT, and for various reasons it's not reasonable to expect all apps to support both kinds of addresses. So should we discourage sites from associating A or records with names because they're not globally reachable? It certainly makes sense to me to say avoid using or advertising GUPIs when you have globals. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: comments on draft-hinden-ipv6-global-site-local-00
Pekka Savola wrote: On Thu, 23 Jan 2003, Brian E Carpenter wrote: Substantial: This document proposes an approach to allocating IPv6 Site-Local address so they are globally unique and routable only inside of a site. == it would be good to go a bit more in depth to how this is actually a problem. For some it surely isn't; if they don't need to prepare for site-mergers, for example. Can you define the class of sites that absolutely, definitely, until the end of time, are guaranteed not to merge? Well, it depends on quite a bit about which is the usage model for site-locals. For example, home nets probably don't merge if we would mandate that site-locals should not cross home-to-office VPN's. Let me be provocative. With proper e2e security, VPNs will become historic. And one of the benefits of IPv6 is supposd to be proper e2e security, as a result of having proper e2e addressing. But of course, there can be not absolute guarantee. Yes. Scenario: Mum and Dad share a LAN. One day they discover that young Johnny has set up his own LAN in his bedroom. They connect them together, and both of them have printers on FEC0::0002. Brian IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: please reply I am posting 3rd time : Web Server addresses : Unicast, Multicast , Anycast
[EMAIL PROTECTED] wrote: Yes that is what the spec says, but reality is always somewhat different. There is no technical reason that an anycast address could not be assigned to any group of hosts. The issue that must be dealt with there are technical reasons why anycast addresses can only be assigned to routers, and why anycast can be used with limited number of cases (like for instance it shouldn't be used as TCP endpoint address). draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt Itojun's analysis draft does a good job of describing the issues today. Of course, I hope draft-haberman-ipv6-anycast-rr-00.txt helps to remove some of those issues. Brian IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Proposal for site-local clean-up
Erik Nordmark [EMAIL PROTECTED] wrote: | This does not answer the question of why you assume that ISPs will change | their business models under v6. | |I said: | |The ISPs business model is about service differentiation. | |And I agree that they most likely will continue with service differentiation. | | |But I think they can change the *realization* of service differentiation |from using IP addresses to using something else, just as long as the |new mechanism provides what they need. In general, businesses do not like to change from known/understood models to new ones unless they believe that the new model will bring some significant new benefit. But this is all rather abstract. Limiting the number and stability of IP addresses works very well for providers now. We agree that providers use this as a means of service differentiation. Previously, you (and other contributors) have dismissed with some certainty my concern that providers will continue to limit addresses under v6. This has been the basis for claiming that site local addresses are unnecessary to answer the simple question: how does my internet-connected PC talk to my network printer without my paying my provider for a second address? Please explain *specifically* what new mechanism v6 supports for providers to realize their service differentiation without limiting IP addresses, and show why providers will be inclined to make the switch. Dan Lanciani ddl@danlan.*com IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: comments on draft-hinden-ipv6-global-site-local-00
Brian, Brian E Carpenter wrote: Pekka Savola wrote: On Thu, 23 Jan 2003, Brian E Carpenter wrote: Substantial: This document proposes an approach to allocating IPv6 Site-Local address so they are globally unique and routable only inside of a site. == it would be good to go a bit more in depth to how this is actually a problem. For some it surely isn't; if they don't need to prepare for site-mergers, for example. Can you define the class of sites that absolutely, definitely, until the end of time, are guaranteed not to merge? Well, it depends on quite a bit about which is the usage model for site-locals. For example, home nets probably don't merge if we would mandate that site-locals should not cross home-to-office VPN's. Let me be provocative. With proper e2e security, VPNs will become historic. And one of the benefits of IPv6 is supposd to be proper e2e security, as a result of having proper e2e addressing. But of course, there can be not absolute guarantee. Yes. Scenario: Mum and Dad share a LAN. One day they discover that young Johnny has set up his own LAN in his bedroom. They connect them together, and both of them have printers on FEC0::0002. Forgetting for the moment that the LANs in your example are probably flat topologies and could instead be using link-local addresses, how do you propose to prevent such duplicate assignments when disconnected/intermittently connected sites merge? Use global addresses always? If so, how can the global allocations be procured and/or maintained when the sites rarely (if ever) connect to the global Internet? Thanks, Fred [EMAIL PROTECTED] IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: unique enough [RE: globally unique site local addresses]
Brian, Erik Nordmark wrote: On the enterprise side I can see that folks have been bitting or are concerned about renumbering costs if they were to use PA addresses. But I don't have any data on how many consider having one PA prefix per ISP good enough since it allows some graceful cutover when changing ISPs. Michel Py wrote: Not many. We have had many contributions that multiple addresses are a no-go to begin with. Brian E Carpenter wrote: Er, multiple addresses are part of the IPv6 architecture. And SCTP deals with them, even if TCP doesn't. It may be something new and different, but there's no way you can declare it a no-go. This coin has two sides. One side is what you say above, which is very true. To set the record straight: contrary to multi6, ipv6mh has acknowledged since the beginning that multi-address host solutions are part of the big picture. They are in the charter and are being discussed. In Atlanta, we had a 1hr+ presentation from Lode Coene about SCTP, another by Christian Huitema about his solution. I'm not saying that multi-address solutions are bad, I'm the one that made them part of the big multihoming picture. That being said, the other side of the coin is that most enterprise network managers don't want multi-address schemes, and for good reasons. A large organization implements, on one form or another: - Defense in depth. - Internal firewalling. - Policy routing. - Some model like core/distribution/access. - Traffic engineering. That means several hundreds or several thousands access-lists, firewall policies, route-maps, etc. If you have three addresses per host, you triple the configuration and double the complexity, not to mention troubleshooting nightmares because you will now have to figure out which address is being used before beginning to troubleshoot. Not good. In many large organizations, there is a split between the Systems manager that could be open to a multi-address solution and the Network manager that does not want it. They might be office buddies, but they also are mortal enemies because they compete for the same scarce budget dollars. Bottom line is that in most situations, the network administrator is the one that calls the shots in terms of addressing. 3 times the complexity is effectively a no-go. In short: multiple addresses on hosts are half of the solution, but the other half is a globally unique address used as an identifier in a dual-space system. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: GUPI/GUSLs and DNS
But when server.example.com has that is just GUPI then mail delivery to [EMAIL PROTECTED] will fail when the GUPI is not reachable, right? Yes it will. But not because you listed a GUPI in the DNS, but because you failed to provide and advertise a server that was reachable by somebody who wanted to send you mail. GUPI addresses in the DNS definitely adds more ways for folks to produce bad configurations. And if we want to have GUPI instead of site-local this might be a common configuration in conjunction with MX records. And I wouldn't be surprised if this type of interaction is limited to MX records. Anything which looks at multiple records in the DNS is potentially at risk. It certainly makes sense to me to say avoid using or advertising GUPIs when you have globals. But by example can easily follow that advice and the problem remain. mail.example.com can have a with just a global. But server.example.com only has a GUPI assigned because it is a host internal to the site that doesn't use external connectivity. The with a GUPI for server.example.com takes precedence over the MX. Erik IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: GUPI/GUSLs and DNS
On Thu, 23 Jan 2003 20:09:41 +0100 (CET) Erik Nordmark [EMAIL PROTECTED] wrote: But when server.example.com has that is just GUPI then mail delivery to [EMAIL PROTECTED] will fail when the GUPI is not reachable, right? Yes it will. But not because you listed a GUPI in the DNS, but because you failed to provide and advertise a server that was reachable by somebody who wanted to send you mail. GUPI addresses in the DNS definitely adds more ways for folks to produce bad configurations. And if we want to have GUPI instead of site-local this might be a common configuration in conjunction with MX records. And I wouldn't be surprised if this type of interaction is limited to MX records. Anything which looks at multiple records in the DNS is potentially at risk. What does multiple records have to do with it? For that matter, what does DNS have to do with it? The issue is that host A wants to contact host B and cannot do so. Does it really matter much whether the reason is that host A cannot look up B's DNS record, or that host A gets a timeout, or that host A gets an ICMP prohibited message when trying to reach host B? (Yes, it does matter, but the differences are subtle. If A can't look up B's name in the DNS then A will be inclined to believe that B does not exist. If A times out when trying to contact B then A will be inclined to believe that there is a network outage. The only thing we currently have that comes close to giving a correct indication is ICMP.) And this issue isn't even specific to GUPIs - it exists for any address for which policy dictates cannot exchange packets with arbitrary hosts on the Internet. This is and will continue to be a very common occurance. And in some sense, the decision to not connect to the public Internet and connect only via private agreement to other networks (and therefore to use GUPIs rather than aggregatable addresses) is a policy decision. Of course if an enterprise doesn't want to advertise all of its DNS zones to the outside world that's its own business. But we shouldn't get hung up on trying to make the set of information that DNS can return to a particular host closely reflect the set of services that the host can reach. It's not terribly useful, and it's misleading. It certainly makes sense to me to say avoid using or advertising GUPIs when you have globals. But by example can easily follow that advice and the problem remain. mail.example.com can have a with just a global. But server.example.com only has a GUPI assigned because it is a host internal to the site that doesn't use external connectivity. The with a GUPI for server.example.com takes precedence over the MX. Huh? If there's an MX and an address record for the same domain, the MX always takes precedence over the address record. -- I tried enlightenment but it kept crashing. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
