Early versions of RFC 2298
I am looking for early drafts of RFC 2298 (dating to December of 1996 or earlier). Is there any archives of these drafts kept anywhere. I am particularly interested in the document draft-ietf-receipt-mdn-01.txt or some later (but not much later) version. Thanks, Kamal Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
RE: NAT traversal....????....Re: [Sip] Eating our own Dog Food...could the IAB and IESG use SIP for conference calls
I agree - much better if you don't have NAT. I'm not qualified to discuss the best way to accelerate the advantages that the Internet brings to everyone's lives while simultaneously encouraging people to move to IPv6. But if the powers-that-be wish there to be a VoIP solution that supports people who, through no fault of their own, find themselves behind NAT (ie: at hotels, etc.), then we're happy to provide the solution. If not, then at least we might all benefit from the resulting debate. Dan Dan Freedman, CEO, Jasomi Networks, Inc. 2033 Gateway Place, Suite 500, San Jose, CA, 95110 Phone +1.403.680.2351 Fax +1.403.269.2993 Email [EMAIL PROTECTED] Webwww.jasomi.com -Original Message- From: Jim Fleming [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 25, 2003 1:16 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] NAT traversal http://www.spectrum.ieee.org/select/1098/int.html NATs are a no-no HEATH: I was going to say that IEEE Spectrum should make it very clear that this group's consensus would appear to be: let's discourage NATs--I mean the manufacture of them at all--because there is a real need for IPv6. HUITEMA: It's more than that. There is a real need for security and you can't have security with NATs. CERF: NAT is a guaranteed spoofing box in effect. - Original Message - From: Dan Freedman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, March 25, 2003 9:43 AM Subject: RE: [Sip] Eating our own Dog Food...could the IAB and IESG use SIP for conference calls Agreed. To enable access from behind firewalls (ie: homes, hotels, conferences, airports, Asia, ...), we can donate a B2BUA-based NAT traversal solution for SIP (same one that Pulver's Free World Dialup uses). It sits near the proxy, with nothing needed on the client end. Bottom line: In addition to helping the IESG and IAB, it will help SIP to have more IETF participants gaining experience with it. -Dan Dan Freedman, CEO, Jasomi Networks, Inc. 2033 Gateway Place, Suite 500, San Jose, CA, 95110 Phone +1.403.680.2351 Fax +1.403.269.2993 Email [EMAIL PROTECTED] SIP [EMAIL PROTECTED] Web www.jasomi.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jiri Kuthan Sent: Tuesday, March 25, 2003 8:01 AM To: Henry Sinnreich; 'Richard Shockey'; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Scott Petrack; Christian Stredicke That's great idea. We can help with our free SIP server (www.iptel.org/ser/) and hosting the services. -Jiri At 03:46 PM 3/25/2003, Henry Sinnreich wrote: There are excellent SIP voice conferencing bridges available, such as from snom AG and eDial. They can be used with various soft clients such as the Windows Messenger, HotSIP Active Contacts or the Pingtel instant expressa, or any SIP phone. I have taken the liberty of copying here the contacts for snom AG and eDial, in case this will be pursued. I wonder if snom AG or eDial would just give the IESG and IAB access to their conference servers? Would there be interest to have access to a WorldCom SIP conference bridge? Thanks, Henry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Shockey Sent: Monday, March 24, 2003 6:04 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [Sip] Eating our own Dog Food...could the IAB and IESG use SIP for conference calls Like many of us I was moved my Harald's appeal for suggestions for helping to cut down costs in the IETF. I certainly endorse the idea of considering Canada or Mexico as possible sites for future IETF meetings, but I suspect that the weekly teleconferece calls that the IAB and IESG have represent a significant line item for the Secretariat. In case anyone has not heard, SIP is quite capable of handling this type of task and there are a variety of commercial as well as open source Client User Agents as well as commercial products and services that could help reduce this cost. I'm sure the SIP working group could help the Secretariat identify products and services that could make this essential function more productive and operate at less cost. Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 mailto:[EMAIL PROTECTED] or mailto:[EMAIL PROTECTED] http://www.neustar.biz ; http://www.enum.org ___ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip ___ Sip mailing list
Re: IPv6, interNAT, Wi-Fi (not mobile)
S Woodside wrote: In addition I recently had to cope with the hassles of setting up an H.323 connection (with ohphoneX) from behind a firewall at both ends and immediately concluded that people on any kind of wireless mesh that uses NAT are going to be severely limited since they aren't truly a part of the internet. Right. The problem is that what I've seen in the past is that wireless-mesh proponents want to be able to do massive multihoming, with all participants with external links sharing those links, and all the traffic from the outside finding the shortest way in. I won't say it's impossible, but last I heard nobody knew how to do it; the route flap would be horrible. -- /\ |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: Early versions of RFC 2298
www.watersprings.org is useful they have versions 0 through 7 of this draft. a shame the ietf doesn't archive like this! tim On Tue, Mar 25, 2003 at 04:25:39PM -0800, Kamal Jamali wrote: I am looking for early drafts of RFC 2298 (dating to December of 1996 or earlier). Is there any archives of these drafts kept anywhere. I am particularly interested in the document draft-ietf-receipt-mdn-01.txt or some later (but not much later) version. Thanks, Kamal - Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
Re: IPv6, interNAT, Wi-Fi (not mobile)
On Tuesday, March 25, 2003, at 06:03 PM, John Stracke wrote: S Woodside wrote: In addition I recently had to cope with the hassles of setting up an H.323 connection (with ohphoneX) from behind a firewall at both ends and immediately concluded that people on any kind of wireless mesh that uses NAT are going to be severely limited since they aren't truly a part of the internet. Right. The problem is that what I've seen in the past is that wireless-mesh proponents want to be able to do massive multihoming, with all participants with external links sharing those links, and all the traffic from the outside finding the shortest way in. I won't say it's impossible, but last I heard nobody knew how to do it; the route flap would be horrible. This is in fact one of the major goals, although I've never heard the community wireless networking (CWN) folks express it so precisely. The ability to be able to set up a wireless network and route internet traffic through the mesh is strongly desired. I think that beyond that, it is also desirable as well. Perhaps it is difficult but if solved and implemented it will allow these types of networks to be a part of the internet, not just on the internet ... creating a type of viral internet, in some sense, where any new node becomes a beachhead for propagation of the internet into new geographical areas. I understand that it's difficult, but it's also important. In addition, there is a strong demand for last-mile/rural broadband around the world. People are kludging together solutions that aren't scalable, and/or are fragile, and/or are proprietary (e.g. RoamAd, etc. and a lot of these so called solutions are really just vaporware right now). simon
Re: NAT traversal....????....Re: [Sip] Eating our own Dog Food...could the IAB and IESG use SIP for conference calls
To connect VoIP with my other email. One of the most interested user groups for fixed wireless networks is people with no telecomms infrastructure to speak of. That is to say, much of the developing world. In these places VoIP is a very popular application for a few reasons ... first because there might not be PSTN available, and even if it is, because it makes international calls affordable (e.g. to relatives in more affluent places), and finally because illiteracy prevents people from user email and other lower-bandwidth apps. simon On Tuesday, March 25, 2003, at 04:10 PM, Dan Freedman wrote: I'm not qualified to discuss the best way to accelerate the advantages that the Internet brings to everyone's lives while simultaneously encouraging people to move to IPv6. But if the powers-that-be wish there to be a VoIP solution that supports people who, through no fault of their own, find themselves behind NAT (ie: at hotels, etc.), then we're happy to provide the solution. If not, then at least we might all benefit from the resulting debate. -- www.simonwoodside.com -- 99% Devil, 1% Angel
RE: Fw: Welcome to the InterNAT...
Keith Moore wrote: your understanding is incorrect. the question posed at the meeting was quite clear. and yes, the plurality of opinions in the room was so overwhelmingly in favor of deprecating site local (even if it's something people are already using) that it is inconceivable that this is not indicative of WG consensus. This has not been discussed on the WG mail list, so despite your apparent limited ability to conceive of valid objections, they do exist. site local is broken. it creates far more problems than it solves, and it cannot be fixed. it's just taken people awhile to realize it. Trying to use SL for routing between sites is what is broken. The space identified in RFC 1918 was set aside because people were taking whatever addresses they could find in documentation. SL was set aside because there are people that either want unrouted space, or don't want to continuously pay a registry to use a disconnected network. It is far cheaper to train an app developer (though there may be an exception or two) to deal with it than it is to fix all the ad-hoc solutions that people will come up with to replace SL. of course, the SL prefix will not be re-allocated to other purposes, and nothing stops those who are already using SL from continuing to do so. but the idea that hosts, apps, routers, DNS, etc. should special-case site-local addresses is dead. and good riddance. Again, this is not a trival issue and there has been no discussion of it on the WG mail list. The decision has NOT been made. Tony
Re: IPv6, interNAT, Wi-Fi (not mobile)
At 05:50 PM 3/25/2003 -0500, S Woodside wrote: In addition I recently had to cope with the hassles of setting up an H.323 connection (with ohphoneX) from behind a firewall at both ends and immediately concluded that people on any kind of wireless mesh that uses NAT are going to be severely limited since they aren't truly a part of the internet. You are experiencing some of the issues of NATs. They work reasonably well in confined environments where the only thing behind them is a client with an external server. Putting the server behind the NAT, or a p2p application's peer, requires some magic in the firewall - eminently doable, but inflexible if it is managed by an IT organization other than you, and not the kind of thing a typical consumer wants to know anything about. This is one of the best arguments for a global address space that doesn't require a life-support system (e.g. NAT) to maintain it, IMHO. As to the massive multihoming issues that Strack comments on, and your reply, there are a set of considerations. If you want the network to have transit properties - if you want traffic from provider A to go to provider B across your network - you are offering the providers a transit service, and you might want to discuss with them what they might want to use it for. I suspect that the scaling and error properties of a wi-fi network will give them pause. If you want the network to multi-home to a variety of providers, it is not a transit network, it is an access network, which IMHO is a very reasonable way to use this kind of network. Using it as ad hoc, I think you want to not relay route flaps to your providers. Rather, you want to advertise your prefix (however obtained) to them en mass, and handle the routing issues internally. This may mean providing wired connectivity between your various points of attachment to your providers, to mask the internal motion.
Re: IPv6, interNAT, Wi-Fi (not mobile)
S Woodside wrote: On Tuesday, March 25, 2003, at 06:03 PM, John Stracke wrote: proponents want to be able to do massive multihoming, with all participants with external links sharing those links, and all the traffic from the outside finding the shortest way in. I won't say it's impossible, but last I heard nobody knew how to do it; the route flap would be horrible. I understand that it's difficult, but it's also important. Well, yeah. If you could solve it, the solution would be applicable to all networks, and would substantially improve the stability of the Internet. So obviously lots of people (not me; I'm not a routing expert) have thought about it; the fact that it hasn't been solved yet should discourage you from making plans that assume it will be solved. -- /\ |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: Fw: Welcome to the InterNAT...
Tony Hain wrote: Trying to use SL for routing between sites is what is broken. But that's not all... The space identified in RFC 1918 was set aside because people were taking whatever addresses they could find in documentation. Not as I recall. Jon Postel received several requests for extraordinarily large chunks of address space, particularly from Europe. I believe Daniel Karrenberg might have more information. This forced his hand. In addition, people such as Paul Vixie were trying to do the best they could to make random address space sork, which is admittedly a trick in a small name space. Recall at the time that CIDR was a new thing. You couldn't simply use a portion of network 10, for instance. The same cannot be said for IPv6. SL was set aside because there are people that either want unrouted space, or don't want to continuously pay a registry to use a disconnected network. Any address space can be unrouted address space. Fix the underlying problem, Tony. Making renumbering easy. If we don't do that, IPv6 is no better than Ipv4 (with the possible exception of MIPv6). It is far cheaper to train an app developer (though there may be an exception or two) to deal with it than it is to fix all the ad-hoc solutions that people will come up with to replace SL. Fix the renumbering problem and this isn't an issue. Eliot
RE: Fw: Welcome to the InterNAT...
Tony Hain wrote: Keith Moore wrote: your understanding is incorrect. the question posed at the meeting was quite clear. and yes, the plurality of opinions in the room was so overwhelmingly in favor of deprecating site local (even if it's something people are already using) that it is inconceivable that this is not indicative of WG consensus. This has not been discussed on the WG mail list, so despite your apparent limited ability to conceive of valid objections, they do exist. As you probably know, check http://playground.sun.com/ipng/ There are a couple of objections against deprecation/removal. But most of these IMHO simply boil down to having a place where it is possible to register globally unique address space which is not to be connected to the internet. Because it is globally unique it can be used to interconnect multiple sites though. Note also that if this space is available and those networks suddendly do want to connect to the internet one will see NAT for IPv6 and thus RFC1918 is born for IPv6 but with registration. If that happens I see little sense in actually giving those people IPv6 as they are not out for e2e connectivity at all. Most applications that work with IPv6 also work in IPv4... site local is broken. it creates far more problems than it solves, and it cannot be fixed. it's just taken people awhile to realize it. Trying to use SL for routing between sites is what is broken. The space identified in RFC 1918 was set aside because people were taking whatever addresses they could find in documentation. SL was set aside because there are people that either want unrouted space, or don't want to continuously pay a registry to use a disconnected network. It is far cheaper to train an app developer (though there may be an exception or two) to deal with it than it is to fix all the ad-hoc solutions that people will come up with to replace SL. And thus *every* application should suddenly be aware of the fact that some address space is not to be used in some certain currently non specified cases? Could this even be more fague? Either there is an address on the link or there isn't. Either it routes or it doesn't. There are numberous reasons why an address can't connect to another host. If an address on a link exists an application should be able to use it as an outgoing address. Currently we already have an exception here for fe80::/10 but that case has already been handled for quite some time and is quite logical as a link is a link and it's quite easy for the stack to detect that a host is not on the same link. Greets, Jeroen
site local addresses (was Re: Fw: Welcome to the InterNAT...)
Tony writes: The space identified in RFC 1918 was set aside because people were taking whatever addresses they could find in documentation. There is a long and interesting history here, but it isn't directly relevant to this discussion. I think it would be valuable to focus the discussion on Site Local, rather than on RFC 1918 space. SL was set aside because there are people that either want unrouted space, or don't want to continuously pay a registry to use a disconnected network. It is far cheaper to train an app developer (though there may be an exception or two) to deal with it than it is to fix all the ad-hoc solutions that people will come up with to replace SL. I think you may underestimate how much trouble this might cause in applications. As Dave Crocker noted in response to Margaret Wasserman's presentation to the APPs Open Area meeting, applications have been designed so that they do not know and don't need to know anything about network topology. If you require applications to understand the consequences of different unicast address scopes, you are changing a pretty fundamental assumption. While it is theoretically possible to change that assumption, it is a major piece of work, and I believe that the sense of the room was that the advantages of Site Local were not worth that amount of work. As you note, this is subject to discussion and confirmation on the mailing list and, ultimately, to the consensus of the IETF as a whole. Margaret's presentation, for those not at the APPs open area, was derived from her draft, found at http://www.ietf.org/internet-drafts/draft-wasserman-ipv6-sl-impact- 02.txt. See especially section 3.7. regards, Ted Hardie
RE: Fw: Welcome to the InterNAT...
Eliot Lear wrote: Tony Hain wrote: SNIP SL was set aside because there are people that either want unrouted space, or don't want to continuously pay a registry to use a disconnected network. Any address space can be unrouted address space. Fix the underlying problem, Tony. Making renumbering easy. If we don't do that, IPv6 is no better than Ipv4 (with the possible exception of MIPv6). How does TCP/IP renumber your DNS, administration databases, numberous applications, remote sites etc? Seeing that route filtering only gets done automaticaly for the last couple of years and the fact that that is only a route + ASN mapping I don't see why all of a sudden there will be some magical solution for renumbering complete networks. Though current IPv6 with RA's does make it simpler it unfortunatly isn't a complete solution :( Greets, Jeroen
RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Ted Hardie wrote: There is a long and interesting history here, but it isn't directly relevant to this discussion. I think it would be valuable to focus the discussion on Site Local, rather than on RFC 1918 space. The reason for bring 1918 into the discussion is that prior to NAT, there was a market demand for private address space. That demand hasn't gone away, and the non-NAT users of that space are completely disenfranchised in this discussion because they have seen no need to worry about it given there is a comparable space defined for IPv6. I think you may underestimate how much trouble this might cause in applications. As Dave Crocker noted in response to Margaret Wasserman's presentation to the APPs Open Area meeting, applications have been designed so that they do not know and don't need to know anything about network topology. If you require applications to understand the consequences of different unicast address scopes, you are changing a pretty fundamental assumption. While it is theoretically possible to change that assumption, it is a major piece of work, and I believe that the sense of the room was that the advantages of Site Local were not worth that amount of work. I am not arguing that every app need to know about topology. If this is such a big deal, we should simply fix the API so that by default it only returns global scope addresses, then add a new function for those apps that are interested in the limited scope. This doesn't sound like rocket science, and the arguments against it are coming across like 'we don't want to change because it is too much work'. Rather than argue that nobody can ever use a new feature, the basic approach should be that you don't have to unless you want to. As you note, this is subject to discussion and confirmation on the mailing list and, ultimately, to the consensus of the IETF as a whole. And it has yet to be formally raised by the chairs on the WG list, so if it gets to IETF last call, it will be ripe for an appeal. Tony Margaret's presentation, for those not at the APPs open area, was derived from her draft, found at http://www.ietf.org/internet-drafts/draft-wasserman-ipv6-sl-impact- 02.txt. See especially section 3.7.
Re: IPv6, interNAT, Wi-Fi (not mobile)
On Wed, 26 Mar 2003, S Woodside wrote: On Tuesday, March 25, 2003, at 06:03 PM, John Stracke wrote: S Woodside wrote: In addition I recently had to cope with the hassles of setting up an H.323 connection (with ohphoneX) from behind a firewall at both ends and immediately concluded that people on any kind of wireless mesh that uses NAT are going to be severely limited since they aren't truly a part of the internet. Right. The problem is that what I've seen in the past is that wireless-mesh proponents want to be able to do massive multihoming, with all participants with external links sharing those links, and all the traffic from the outside finding the shortest way in. I won't say it's impossible, but last I heard nobody knew how to do it; the route flap would be horrible. This is in fact one of the major goals, although I've never heard the community wireless networking (CWN) folks express it so precisely. The ability to be able to set up a wireless network and route internet traffic through the mesh is strongly desired. I think that beyond that, it is also desirable as well. Perhaps it is difficult but if solved and implemented it will allow these types of networks to be a part of the internet, not just on the internet ... creating a type of viral internet, in some sense, where any new node becomes a beachhead for propagation of the internet into new geographical areas. precisely... it spreads in a horizontal fashion. I understand that it's difficult, but it's also important. In addition, there is a strong demand for last-mile/rural broadband around the world. People are kludging together solutions that aren't scalable, and/or are fragile, and/or are proprietary (e.g. RoamAd, etc. and a lot of these so called solutions are really just vaporware right now). simon sleekfreak pirate broadcast world tour 2002-3 live from los angeles http://sleekfreak.ath.cx
RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)
On Wed, 2003-03-26 at 16:38, Tony Hain wrote: Ted Hardie wrote: I think you may underestimate how much trouble this might cause in applications. As Dave Crocker noted in response to Margaret Wasserman's presentation to the APPs Open Area meeting, applications have been designed so that they do not know and don't need to know anything about network topology. If you require applications to understand the consequences of different unicast address scopes, you are changing a pretty fundamental assumption. While it is theoretically possible to change that assumption, it is a major piece of work, and I believe that the sense of the room was that the advantages of Site Local were not worth that amount of work. I am not arguing that every app need to know about topology. If this is such a big deal, we should simply fix the API so that by default it only returns global scope addresses, then add a new function for those apps that are interested in the limited scope. This doesn't sound like rocket science, and the arguments against it are coming across like 'we don't want to change because it is too much work'. Rather than argue that nobody can ever use a new feature, the basic approach should be that you don't have to unless you want to. Its not that 'we don't want to change because its to much work'. Its that the Internet architecture assured us that the hour glass model applied, that the network topology would remain abstracted within what to us is an opaque address space. One of the number one reasons its so easy for new application layer technologies to be deployed is that a developer doesn't need to know or care about any layer below TCP (or, in rare cases, UDP). If the lower layers want to change that hour glass model then we're talking about a serious breach of contract with the layers above it and a dangerous blow to the hour glass model. -MM
RE: Fw: Welcome to the InterNAT...
At 10:14 PM 3/26/2003 +0100, Jeroen Massar wrote: Seeing that route filtering only gets done automaticaly for the last couple of years and the fact that that is only a route + ASN mapping I don't see why all of a sudden there will be some magical solution for renumbering complete networks. Really? I started to design such a procedure, and it's not terrifically hard if you set your sights correctly. The key concepts are: - IPv6 makes it easy to have multiple prefixes and addresses per interface - anything you have advertised in DNS etc has a lifetime, which you need to honor - the existing so-called renumber scheme mostly says how to make a new address come into existence So if you want to renumber from prefix A to prefix B, you have to: -1- start with all routers and hosts using prefix A -2- reconfigure all router interfaces to support both prefixes A and B, and preferring prefix A -3- as a side effect, you will also be starting to route for prefixes A and B. -4- as a side effect, hosts will develop addresses in both prefixes -5- Update DNS etc databases with prefix B addresses (presumably a side-effect of step 4) -6- at this point, there will be no new sessions opening using prefix A as destination addresses. Prefix A will be in use in source addresses. -7- reconfigure all router interfaces to support both prefixes A and B, and preferring prefix B -8- wait for all advertisements of prefix A addresses (DNS etc) to expire -9- at this point, there will be no new sessions opening using prefix A as destination addresses. Prefix A will be in use in source addresses in sessions that started before step 6. Continue waiting until they are no more (may be already complete, may take a month, YMMV) 10- when said sessions have all expired, prefix A is routed and usable but is no longer in active use. 10- reconfigure all routers to support only prefix B 11- as a side effect, routing and host use of prefix A will cease The hard parts are reconfigure all routers... and determining the duration of the delay in step 9. The rest actually works reasonably well today, I should think.
RE: Fw: Welcome to the InterNAT...
Jeroen Massar wrote: Seeing that route filtering only gets done automaticaly for the last couple of years and the fact that that is only a route + ASN mapping I don't see why all of a sudden there will be some magical solution for renumbering complete networks. Fred Baker wrote: Really? I started to design such a procedure, and it's not terrifically hard if you set your sights correctly. [SNIP] Really? What do you do for: - Route-maps. - Prefix-lists. - Access-lists. - Customers that are stupid enough to configure links to your EDI systems with a hard-coded IP instead of a FQDN? - Firewall configs. - Suppliers that have configured your systems in their hosts.allow. - etc. Michel.
RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)
At 1:38 PM -0800 3/26/03, Tony Hain wrote: I am not arguing that every app need to know about topology. If this is such a big deal, we should simply fix the API so that by default it only returns global scope addresses, then add a new function for those apps that are interested in the limited scope. Those two sentences don't line up. Either things that use addresses need to know about network topology, or they don't. And it's not just applications. Security services like IPsec are also equally affected by having to know that ah, I'm actually doing something site local, so I need to prompt the operator for a prefix and then use that prefix in many places in my security logic. It's not just an API question. --Paul Hoffman, Director --VPN Consortium
RE: Fw: Welcome to the InterNAT...
Michel Py [mailto:[EMAIL PROTECTED] wrote: Jeroen Massar wrote: Seeing that route filtering only gets done automaticaly for the last couple of years and the fact that that is only a route + ASN mapping I don't see why all of a sudden there will be some magical solution for renumbering complete networks. Fred Baker wrote: Really? I started to design such a procedure, and it's not terrifically hard if you set your sights correctly. [SNIP] Really? What do you do for: - Route-maps. - Prefix-lists. - Access-lists. - Customers that are stupid enough to configure links to your EDI systems with a hard-coded IP instead of a FQDN? - Firewall configs. - Suppliers that have configured your systems in their hosts.allow. - etc. Thanks Michel for listing the things that I once forgot too. I also had the idea that it 'was simple to renumber' untill someone pointed out to me that DNS + routers are not everything :( Especially But I do like Fred's point in making a procedure/document which at least documents all the points which one will come across when one is going to renumber. I think the identification of these points alone could be quite valuable. Thoug admittedly it all is quite based on which hard+software one is using and those can vary a lot. Greets, Jeroen
RE: Fw: Welcome to the InterNAT...
Jeroen Massar wrote: Thanks Michel for listing the things that I once forgot too. Let me guess: until you actually had to renumber a large one :-) with a flag day maybe :-D In my experience, the pain is not with your own network but with external partners such as supply chain and distribution. When these partners are large corporations or governments it's really fun to make the banana eaters in their NOCs change their access-lists and firewall configs. Michel.
RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Michael Mealling wrote: Its not that 'we don't want to change because its to much work'. Its that the Internet architecture assured us that the hour glass model applied, that the network topology would remain abstracted within what to us is an opaque address space. One of the number one reasons its so easy for new application layer technologies to be deployed is that a developer doesn't need to know or care about any layer below TCP (or, in rare cases, UDP). If the lower layers want to change that hour glass model then we're talking about a serious breach of contract with the layers above it and a dangerous blow to the hour glass model. You really don't want to go there, since it is in fact the violation of the layering by the apps that has created some of the mobility and renumbering challenges. Apps know all too much about what is going on below them, which is why the app developer sees any change as a lot of work. Tony
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
On Wednesday, March 26, 2003, at 01:38 PM, Tony Hain wrote: Ted Hardie wrote: There is a long and interesting history here, but it isn't directly relevant to this discussion. I think it would be valuable to focus the discussion on Site Local, rather than on RFC 1918 space. The reason for bring 1918 into the discussion is that prior to NAT, there was a market demand for private address space. That demand hasn't gone away, and the non-NAT users of that space are completely disenfranchised in this discussion because they have seen no need to worry about it given there is a comparable space defined for IPv6. I'm not sure I agree that there was ever a non-scarcity induced market demand for private address space in the pre-RFC 1918 days, but I'll concede it for the sake of argument. I think we then to consider whether the current need is for: non-routed globally unique space or for something else. If the answer is non-routed globally unique space, then the follow-on question is Why not get globally unique space and simply decide not to route it?. If the market demand is for something else, then I'd appreciate a concise statement of what it is. I am not arguing that every app need to know about topology. If this is such a big deal, we should simply fix the API so that by default it only returns global scope addresses, then add a new function for those apps that are interested in the limited scope. This doesn't sound like rocket science, and the arguments against it are coming across like 'we don't want to change because it is too much work'. Rather than argue that nobody can ever use a new feature, the basic approach should be that you don't have to unless you want to. I'm sorry that the arguments against it are coming across like we don't want to change because it is too much work. That is certainly a part of the reaction, but the underlying reason is actually that the model doesn't fit the Internet architecture as the apps understand it. As I tried to note in my first response, I agree that it is possible to *change* the assumptions about the app's layer knowledge of topology, but the reasons given for the need seem remarkably weak in the light of such a basic change. To put it bluntly, this is not a new feature that requires a tweak to some ur-API. This change requires apps to understand address scope, and to understand it in a totally new way. Again, I urge folks following the discussion to read Margaret's draft. regards, Ted Hardie Margaret's presentation, for those not at the APPs open area, was derived from her draft, found at http://www.ietf.org/internet-drafts/draft-wasserman-ipv6-sl-impact- 02.txt. See especially section 3.7.
RE: Fw: Welcome to the InterNAT...
Margaret Wasserman wrote: The WG chairs of the IPv6 WG did determine that there was consensus of those in the room to deprecate site-local addressing in IPv6. Like all consensus achieved at IETF meetings, this consensus will be checked on the list. BTW, I was at the meeting (Tony was not) and do not agree with his characterization of the discussion. The conversation did not focus on NAT and, IMO, was no more confused than typical WG discussions :-). Unfortunately I could not be there, so I can only go on the reports I have gotten, which show that at least some of the people in the room felt this was an anti-NAT discussion. Some have even suggested that there was no clear indication on what 'deprecating site-local' means. Is it the address range, or the concept of scopes? All the arguments seem to be targeting getting rid of the address range because a few app developers can't figure out how to deal with scopes. The range doesn't create the scope, the application of filtering does that. Since there will be filtering going on anyway, are we supposed to get rid of all addresses? Let's get real here. All SL amounts to is a well-known route filter. History shows people will use private address space for a variety of reasons. Getting rid of a published range for that purpose will only mean they use whatever random numbers they can find. This has also been shown to create operational problems, so we need to give them the tool they want to use in a way we can contain the fallout. Site local is defined to do that job, and we do not have WG concensus on depricating it. Tony Margaret At 05:16 PM 3/25/2003 -0800, Tony Hain wrote: Lloyd Wood wrote: spaking of which, Noel, where's the obIPv6 whinge on how, now that they've deprecated site-local addresses, IPv6 has no redeeming features left? I don't know who 'they' is, but the WG has not deprecated site-local addresses. As I understand it a completely confused discussion occurred in SF which equated SL with NAT, but that does not equate to a WG consensus to depricate something people are already using. Tony
RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Ted Hardie wrote: I think we then to consider whether the current need is for: non-routed globally unique space or for something else. If the answer is non-routed globally unique space, then the follow-on question is Why not get globally unique space and simply decide not to route it?. Because such thing does not exist, it's called PI and is not available to IPv6 end-sites. And if it ever is, it will cost money or other annoyances to obtain. Michel.
Re: Fw: Welcome to the InterNAT...
Tony Hain wrote: History shows people will use private address space for a variety of reasons. Getting rid of a published range for that purpose will only mean they use whatever random numbers they can find. This has also been shown to create operational problems, so we need to give them the tool they want to use in a way we can contain the fallout. Site local is defined to do that job, and we do not have WG concensus on depricating it. As I wrote previously, one must understand the history in order to understand its applicability to the future. The reason there was a problem at all was that there was a not just a non-zero chance of an address clash but that this percentage rose based based on the class of address chosen. If you took 80.1.4.6 you clashed with all of 80 because classless addressing had not made it into the base yet. The chance of this sort of clash in IPv6 is miniscule. Not that it's a good idea. Even so, if you used upper range class B or C address space the chance of a clash at the time was low (still is). And indeed in the case of a merger you were better off than using net 10 because the likelihood of clash with net 10 is high. Eliot
Re: Financial state of the IETF - to be presented Wednesday
John- Processing those applications would mean lots more work for the Secretariat. And then there'd be the time spent on people complaining because they were turned down. (And, there would be several well-known categories of folk who would be helped: academics, students, self-funded, folks from non-profits, whatever) Self-funded is problematic, though: how do you tell the difference between someone who really is paying his own way and someone who's going to expense it? And what about a consultant with his own small business; if he owns the business outright, and the business pays the way, is that self-funded or not? Maybe a bit -- but, if you're self funded then you have no affiliation on your badge. It would be a bit of extra work, I agree. How much, I have no idea... But, let's face it ... we're going to raise the meeting fee to get our finances in order. And, I was echoing Harald's point that this could be a Big Deal to some folk. A student I have worked with in the past funded his way to SF last week and I know was very grateful for the break in the meeting fee. I, for one, do not want to eliminate these sorts of people from attending the meetings because I think they add a different and useful perspective. So, I would be in favor of having some amount of wiggle room for folk who ask for it. I will not ask for it (in my current situation) and would be happy (for my funder) to subsidize the registration fee for these folk (as I am currently thrilled to do for students who attend IETF). I think other organizations make this kind of distinction work by giving more rights to people who pay more; that would be the opposite of what we want to do here. I was specifically thinking of SIGCOMM's student travel grant program -- in which the above is not the case. allman -- Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Michel, I don't think something needs to be provider independent to fit this bill. Getting a slice of the global address space from some provider and choosing not route a portion of it (even if that portion is 100%) seems to me to create non-routed globally unique space. Are you concerned that doing so has some impact on the routing system that needs to be considered? Money and other annoyances are certainly concerns we all face. In that spirit please understand that keeping site local costs different money and creates different annoyances. regards, Ted On Wednesday, March 26, 2003, at 03:51 PM, Michel Py wrote: Ted Hardie wrote: I think we then to consider whether the current need is for: non-routed globally unique space or for something else. If the answer is non-routed globally unique space, then the follow-on question is Why not get globally unique space and simply decide not to route it?. Because such thing does not exist, it's called PI and is not available to IPv6 end-sites. And if it ever is, it will cost money or other annoyances to obtain. Michel.
RE: site local addresses (was Re: Fw: Welcome to theInterNAT...)
--On Wednesday, 26 March, 2003 15:13 -0800 Tony Hain [EMAIL PROTECTED] wrote: Michael Mealling wrote: Its not that 'we don't want to change because its to much work'. Its that the Internet architecture assured us that the hour glass model applied, that the network topology would remain abstracted within what to us is an opaque address space. One of the number one reasons its so easy for new application layer technologies to be deployed is that a developer doesn't need to know or care about any layer below TCP (or, in rare cases, UDP). If the lower layers want to change that hour glass model then we're talking about a serious breach of contract with the layers above it and a dangerous blow to the hour glass model. You really don't want to go there, since it is in fact the violation of the layering by the apps that has created some of the mobility and renumbering challenges. Apps know all too much about what is going on below them, which is why the app developer sees any change as a lot of work. Tony, I am probably missing something, but I don't see this. Partially to aid transition to v6, we've been telling apps developers for several years that they should rely on DNS names, paying at little attention as possible to the format or content of addresses, their topology implications, etc. As an application-writer, I'm not supposed to know anything about prefixes, address-masks, or anything else about how addresses are put together. Yes, if I start doing tricky things about firewall or NAT-traversal, I can get myself into a lot of trouble, but that is part of why we have always considered those sorts of things to be layer-violating if not worse. Ignoring the format of addresses has worked well for 1918 addresses (loathsome as they might be) because the assumption is that filtering (so that they don't leak onto the public network) is the responsibility of anything that connects a 1918 network to the public Internet. And CIDR was deployable precisely because the applications themselves didn't know about classes. Now, if I correctly understood Margaret's presentation last week (and some other things), if there is a possibility that a particular address might be site-local but that the target might also be associated with publicly-routable prefixes, the application has to figure that out, figure out whether the target is local, and then do the right thing. That isn't a matter of filtering or masking external to the application: the application has to do the work, or the architecture that surrounds the applications has to change. That is a fairly big deal and, I think, involves more layering problems than what we are doing today. But, obviously, I'm not understanding something. Could you explain? john
RE: Fw: Welcome to the InterNAT...
At 02:37 PM 3/26/2003 -0800, Michel Py wrote: What do you do for: - Route-maps. - Prefix-lists. - Access-lists. Those fall under configure the router... Yes, things one does that use prefixes are going to have to be reconfigured using prefixes. - Firewall configs. A firewall is either an application gateway or a router depending on what it does; it at minimum receives packets and forwards them, and may translate them in some sense. configure the router... - Customers that are stupid enough... Someone else's stupidity is not my problem. - Suppliers that have configured your systems in their hosts.allow. hosts.allow, last I checked, uses names. But nonetheless, this is (ahem) not the world's most secure mechanism for much of anything (ahem).
Re: Fw: Welcome to the InterNAT...
Ultimately, as I wrote with others some nine years ago, some practices should not be codified. With IPv4 at least there was a plausible argument for network 10. I didn't like it, nor did I agree with it, but it was plausible. The same cannot be said for v6. Incidentally, Sun HP's use of default network numbers didn't really cause any great consternation or motivation for RFC 1597, so far as I could tell. Were that the case we wouldn't have needed either a /16 or a /8. Eliot
Re: Fw: Welcome to the InterNAT...
On Wed, Mar 26, 2003 at 04:22:55PM -0800, Fred Baker wrote: At 02:37 PM 3/26/2003 -0800, Michel Py wrote: What do you do for: - Route-maps. - Prefix-lists. - Access-lists. Those fall under configure the router... Yes, things one does that use prefixes are going to have to be reconfigured using prefixes. - Firewall configs. A firewall is either an application gateway or a router depending on what it does; it at minimum receives packets and forwards them, and may translate them in some sense. configure the router... Don't forget your IP addresses also often appear in other people's router configs and firewalls. Tim
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Ted, What happens when you change providers? Rgds, -drc On Wednesday, March 26, 2003, at 04:01 PM, Ted Hardie wrote: Michel, I don't think something needs to be provider independent to fit this bill. Getting a slice of the global address space from some provider and choosing not route a portion of it (even if that portion is 100%) seems to me to create non-routed globally unique space. Are you concerned that doing so has some impact on the routing system that needs to be considered? Money and other annoyances are certainly concerns we all face. In that spirit please understand that keeping site local costs different money and creates different annoyances. regards, Ted
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Hi David, Provider of what? Note that if a provider of address space is not routing the addresses involved, they have few or no performance responsibilities in the arena. They don't even need to polish and regrind the digits periodically; they just go. It seems unlikely to me personally that you would change providers for performance reasons. Back to money. If you are getting a slice of the globally unique address space from someone to whom it has been delegated, you may pay them for the privilege. Those fees could go up, and in that case, a network might decide to renumber into a cheaper provider's space to avoid costs. Given that they are all derived from the same sources and the lack of scarcity in the resource, though, its hard to see this as a major problem, unless scarcity is created artificially. That would be a matter for policy debate with the allocating agencies, though, not the IETF. If you were using some of an allocated portion as routable addresses and some as unrouted addresses, you might be forced to change the unrouted addresses as a consequences of choosing someone new to carry the traffic from the routed portions of your network. That would carry the same pain of renumbering it always does. regards, Ted On Wednesday, March 26, 2003, at 04:32 PM, David Conrad wrote: Ted, What happens when you change providers? Rgds, -drc On Wednesday, March 26, 2003, at 04:01 PM, Ted Hardie wrote: Michel, I don't think something needs to be provider independent to fit this bill. Getting a slice of the global address space from some provider and choosing not route a portion of it (even if that portion is 100%) seems to me to create non-routed globally unique space. Are you concerned that doing so has some impact on the routing system that needs to be considered? Money and other annoyances are certainly concerns we all face. In that spirit please understand that keeping site local costs different money and creates different annoyances. regards, Ted
RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)
John C Klensin wrote: ... For most of the cut section, consider that while 'good practice' says to use names, reality is that too many apps still grab the address for random reasons. But, obviously, I'm not understanding something. Could you explain? There is a lot of noise about treating SL special, but as you note an application can ignore that a 1918 address is somehow different from any other address. If an application were to do the same and just use a SL as any other address, it will work just fine until one of the participants is on the outside of the filtering router (also true for IPv4 w/1918). If one believes that a split-DNS is reasonable to build and deploy (since many exist it seems self evident), then an application should only see a SL in a DNS response if the query originates in the same private address region. This again will work fine and the existing sending rules might cause the stack to order that one first so that any long-lived internal connections would survive an external renumbering event. The place SL starts to have trouble is when a multi-party app does referrals based on obtained addresses rather than names. Since the app can't know which parties are on which side of the routing filter, it can't pass the correct addresses around. (One could argue that if it passed a name then the split-DNS would return the correct address to the querier based on his location, but that frequently gets shouted down based on unreliability of DNS) It is also possible that one of the participants is only accessible via the private address space, so there is a failure mode where some participants can see each other while others can't. This will always be true, and has nothing to do with the well-known prefix FEC0::. The other place SL is criticized is for it's intentional ambiguity. While this doesn't prevent random announcements into the global table, it does provide a clear bogon for the route filters. Again this is not a problem until two parties try to route between each other without coordinating. Since there are 58 bits allocated for local administration, one would hope that multiple organizations could find a way to interconnect private networks without conflict. The argument against this is that people won't do it so we have to force them to register for some yet to be defined public space that is not routable. Since we know that ISP's will do whatever the customer pays for, it is only a matter of time until 'unroutable' prefixes start showing up in the global table. The intentional ambiguity prevents that. One reason that some people like private space is that they don't have to expose to their competitors what internal networks they are deploying and which office is coordinating that. If they are suddenly required to register for public space for every internal use network, they are more likely to pick random numbers than tip of the competition. What they want is space that for all intents and purposes to apps looks like global space, but they don't have to expose it, know it will be filtered at the border, and backed up by a filter at the ISP. So for these purposes there is no need to treat SL as a special case. Others are looking for a well-known filter than can be embedded in appliances so they are easy to sell to Joe-sixpack and only accessable from the home network. There may be apps that want to leverage the well-known filter to simplfy the life of Joe-sixpack. Consider the case of file sharing between nodes on an intermittently connected network. If the mount dropped evertime there was a connect event, Joe-sixpack would find another product. In this case there may be a reason for the app to treat SL as a special case, but this is something the app developer wants to do and is willing to do the extra work to make it happen. There are complex proposals for RA options, but so far none of them work for the node that needs to be seen both internally and externally. We need to get past the arguments that private space == nat, because use of private space predates nat, and its only relationship is that it facilitated nat as an address preservation tool. No matter what the WG does, there will continue to be private space used in various parts of the network. There will also be filtering in the network, so app developers have to deal with scope no matter how badly they want to avoid it. By clearly defining the address range for limited scope use, applications have the opportunity to use or avoid it at will. If the app passes names and the split-DNS infrastructure is operating correctly, there is no need for the app to care about the filters. If there really is some magic in FEC0::, I am willing to refocus my drafts from a PI mechainsm to a globally unique address space with no need to register. Since it results in a /64 per cubic meter 1km deep, there is no real potential for conflict. Tony
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
On Wednesday, March 26, 2003, at 05:40 PM, David Conrad wrote: Ted, On Wednesday, March 26, 2003, at 05:03 PM, Ted Hardie wrote: If you were using some of an allocated portion as routable addresses and some as unrouted addresses, you might be forced to change the unrouted addresses as a consequences of choosing someone new to carry the traffic from the routed portions of your network. That would carry the same pain of renumbering it always does. Which, of course, implies NAT (where's there's pain, there's NAT? :-)). Anyhow, this is the wrong list for this discussion... Rgds, -drc where there's pain, there's NAT--are you sure you have these in the right order? :^) I'll respond further by private email, as I agree that we're now a bit far afield of the IETF main list's normal function. Ted
Re: Fw: Welcome to the InterNAT...
Thus spake Fred Baker [EMAIL PROTECTED] - Customers that are stupid enough... Someone else's stupidity is not my problem. As a vendor, every customer problem is your problem. Go visit some Fortune 500 customers and ask: . Are you aware you won't be able to get portable IPv6 addresses? . How would you like to renumber your entire network every year? . How would you like us to sell you IPv6 NATs so you'll never have to renumber again? S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Or what if there is no provider (as in default addresses used by a software vendor)? -andy David Conrad wrote: Ted, What happens when you change providers? Rgds, -drc On Wednesday, March 26, 2003, at 04:01 PM, Ted Hardie wrote: Michel, I don't think something needs to be provider independent to fit this bill. Getting a slice of the global address space from some provider and choosing not route a portion of it (even if that portion is 100%) seems to me to create non-routed globally unique space. Are you concerned that doing so has some impact on the routing system that needs to be considered? Money and other annoyances are certainly concerns we all face. In that spirit please understand that keeping site local costs different money and creates different annoyances. regards, Ted
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
From the reading of the draft, it would appear that much of the pain for applications with SL is caused because the apps violated the contract. Actually, its a wonder any of these would work in v6 at all given the description of the problem (address leaks). -andy Michael Mealling wrote: Its not that 'we don't want to change because its to much work'. Its that the Internet architecture assured us that the hour glass model applied, that the network topology would remain abstracted within what to us is an opaque address space. One of the number one reasons its so easy for new application layer technologies to be deployed is that a developer doesn't need to know or care about any layer below TCP (or, in rare cases, UDP). If the lower layers want to change that hour glass model then we're talking about a serious breach of contract with the layers above it and a dangerous blow to the hour glass model. -MM
Re: Fw: Welcome to the InterNAT...
--On Wednesday, March 26, 2003 20:05:11 -0600 Stephen Sprunk [EMAIL PROTECTED] wrote: Thus spake Fred Baker [EMAIL PROTECTED] - Customers that are stupid enough... Someone else's stupidity is not my problem. As a vendor, every customer problem is your problem. Go visit some Fortune 500 customers and ask: . Are you aware you won't be able to get portable IPv6 addresses? . How would you like to renumber your entire network every year? . How would you like us to sell you IPv6 NATs so you'll never have to renumber again? Most F500 customers or similar have their own AS numbers. They can easily become a LIR and get their own assignment. Most of the things making renumbering hard are issues with short-sighted optimisations, like host files instead of DNS, IP addresses in applications, and similar. These all can be taken away in time -- most of the applications that suggest this behaviour are v4-only today, and thus NOW is the time to act decisively to get the message out: Prepare to renumber. As Fred wrote; it is already today possible to build with caution to make renumbering easy. You as a vendor should, instead of making paint-oneself-into-corners misbehaviour possible, make it intuitive to DTRT. -- Måns Nilssonhttp://vvv.besserwisser.org pgp0.pgp Description: PGP signature
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
At 08:40 PM 3/26/2003, David Conrad wrote: Ted, On Wednesday, March 26, 2003, at 05:03 PM, Ted Hardie wrote: If you were using some of an allocated portion as routable addresses and some as unrouted addresses, you might be forced to change the unrouted addresses as a consequences of choosing someone new to carry the traffic from the routed portions of your network. That would carry the same pain of renumbering it always does. Which, of course, implies NAT (where's there's pain, there's NAT? :-)). No. It does not imply NAT. It implies traffic to hosts which are used for purposes which do not communicate to the public network. Could we PLEASE leave NAT out of the equation? Not all hosts in the world want or need to be connected outside of the corporate network they belong to. Today such hosts are numbered in RFC 1918 space WITHOUT NAT and are connected to corporate networks. It's likely, given the line of argument you're proposing, that many corporations will just laugh at the IETF, and continue to use IPv4 for their private network space.
RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Tony, The specifics of the site local issue should be debated on the IPv6 WG list, not on the global IETF list. Let me however respond to your point regarding the quality of the debate, as I was the note taker during that session. My notes record that 22 separate speakers took part to this debate, some coming to the microphone several time. It is also pretty clear from my notes that the consensus of the room is evolving as the discussion progresses, and as arguments are being exchange. Yes, there was mention of site local as a license to NAT, but there where many other arguments: leakage through IP, DNS or application; the lack of practicality of several restrictive models for site locals; the possibility or not to use other solutions for isolated sites; and the complexity of handling scoped addresses in applications. At the end, the tally shows 20 hands rising in support of site locals, 102 hands rising for their elimination. In short, it was not a hasty discussion, there was an informed debate, opinions evolved during the discussion, and a consensus was reached. I believe that if you had been in the room you would feel closer to that consensus. -- Christian Huitema
RE: Fw: Welcome to the InterNAT...
Fred / Stephen, Michel Py wrote: - Customers that are stupid enough... Fred Baker wrote: Someone else's stupidity is not my problem. Stephen Sprunk wrote: As a vendor, every customer problem is your problem. Go visit some Fortune 500 customers and ask: Are you aware you won't be able to get portable IPv6 addresses? How would you like to renumber your entire network every year? How would you like us to sell you IPv6 NATs so you'll never have to renumber again? Agree with Stephen (I think I'm going to create a startup that sells IPv6 NAT boxes soon; I will do like Linksys and allow Cisco to buy me for big bucks in a few years; who's in?), I will add something: even as a non-vendor company, every customer problem is your problem. If you renumber your network and customers can't send orders in anymore because their banana eaters don't know how to reconfigure an access-list on their end to allow their system to talk to your new IP, it's _your_ problem. And BTW most firewalls and access-list still work with IP and not FQDNs. This is besides the point anyway; no matter how stupid the customer is the customer is king. If Cisco was not big enough to have a global prefix in the routing table no matter what and you had to renumber your 60K subnets if you switched ISPs you would be singing another song. Michel.
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Thus spake Christian Huitema [EMAIL PROTECTED] The specifics of the site local issue should be debated on the IPv6 WG list, not on the global IETF list. Let me however respond to your point regarding the quality of the debate, as I was the note taker during that session. Issues most often move to the IETF list when a vocal minority object to a declaration of consensus by the WG chairs. If the WG chair would like to reopen the debate, I'm sure everyone will move back there. In short, it was not a hasty discussion, there was an informed debate, opinions evolved during the discussion, and a consensus was reached. I believe that if you had been in the room you would feel closer to that consensus. I haven't seen anyone argue in favor of site-local addressing for the purposes of having explicitly scoped addresses, so you are correct in one sense. What I am seeing is debate over private address space and NAT, which many of us had expected site-locals to be useful for -- this email thread (and the one on routing-discussion) belies any claims of consensus on that. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
Re: Fw: Welcome to the InterNAT...
On Thu, 27 Mar 2003, Måns Nilsson wrote: --On Wednesday, March 26, 2003 20:05:11 -0600 Stephen Sprunk [EMAIL PROTECTED] wrote: Thus spake Fred Baker [EMAIL PROTECTED] - Customers that are stupid enough... Someone else's stupidity is not my problem. As a vendor, every customer problem is your problem. Go visit some Fortune 500 customers and ask: . Are you aware you won't be able to get portable IPv6 addresses? . How would you like to renumber your entire network every year? . How would you like us to sell you IPv6 NATs so you'll never have to renumber again? Most F500 customers or similar have their own AS numbers. They can easily become a LIR and get their own assignment. You don't get a portable IPv6 address allocation only by being a LIR. Except by lying or having an interesting interpretation of the required 200 customers in the application, of course... -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: Fw: Welcome to the InterNAT...
--On Thursday, March 27, 2003 09:11:57 +0200 Pekka Savola [EMAIL PROTECTED] wrote: You don't get a portable IPv6 address allocation only by being a LIR. Except by lying or having an interesting interpretation of the required 200 customers in the application, of course... That is because the LIR communities haven't changed that yet. I think it should be changed to what was the intention of a RIPE meeting not long ago; give all who want some space, as long as they are a LIR. -- Måns Nilssonhttp://vvv.besserwisser.org pgp0.pgp Description: PGP signature
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
--On onsdag, mars 26, 2003 17:40:23 -0800 David Conrad [EMAIL PROTECTED] wrote: Ted, On Wednesday, March 26, 2003, at 05:03 PM, Ted Hardie wrote: If you were using some of an allocated portion as routable addresses and some as unrouted addresses, you might be forced to change the unrouted addresses as a consequences of choosing someone new to carry the traffic from the routed portions of your network. That would carry the same pain of renumbering it always does. Which, of course, implies NAT (where's there's pain, there's NAT? :-)). the more general aphorism is probably where there's pain people want painkillers painkillers don't cure the cause of pain painkillers have side effects not that this helps evaluate the issue (much); my personal take (which is largely irrelevant to this list) is that IPv6 applications will be cheaper and simpler when the code does not have to treat some addresses differently from others; the fewer special cases, the better. Special cases are pain; in this case, we were able to eliminate one source of this pain. In my opinion, of course. Harald
Re: Fw: Welcome to the InterNAT...
This has not been discussed on the WG mail list, so despite your apparent limited ability to conceive of valid objections, they do exist. actually it's the other way around. there are far more valid objections to the use of SL than there are to deprecating SL. Trying to use SL for routing between sites is what is broken. SL is broken whether or not you try to use it for routing between sites. It is far cheaper to train an app developer (though there may be an exception or two) to deal with it than it is to fix all the ad-hoc solutions that people will come up with to replace SL. no, you have it exactly opposite. you can't train an app developer to fix the problems caused by SL because in order to fix the problems caused by SL you have to deploy extra infrastructure and create a new network on top of the dysfunctional one that uses SL. and it's far cheaper and cleaner to solve those problems in other ways. SL is the ad hoc solution that didn't get sufficient scrutiny before being approved. Fortunately that mistake has finally been rectified. Again, this is not a trival issue and there has been no discussion of it on the WG mail list. The decision has NOT been made. a clear consensus of the WG has spoken. Keith
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
The reason for bring 1918 into the discussion is that prior to NAT, there was a market demand for private address space. sometimes the market is misled by vendors who want to sell planned obsolesence. NAT is the perfect example.
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
since it is in fact the violation of the layering by the apps that has created some of the mobility and renumbering challenges. uh, no. DNS is not a layer. it is a naming service. it's not the only way that an app can get an IP address, and never has been.
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Ignoring the format of addresses has worked well for 1918 addresses (loathsome as they might be) because the assumption is that filtering (so that they don't leak onto the public network) is the responsibility of anything that connects a 1918 network to the public Internet. but this assumption proved to be a false one. Keith
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
There is a lot of noise about treating SL special, but as you note an application can ignore that a 1918 address is somehow different from any other address. If an application were to do the same and just use a SL as any other address, it will work just fine until one of the participants is on the outside of the filtering router (also true for IPv4 w/1918). for multiparty apps, the probability that this will happen is within epsilon of 1. If one believes that a split-DNS is reasonable to build and deploy (since many exist it seems self evident) no. there are lots of unreasonable things in this world. split DNS is a hack that works only in limited situations, and even then it doesn't work well. it makes assumptions about application behavior that are not valid. , then an application should only see a SL in a DNS response if the query originates in the same private address region. DNS is irrelevant. you can't fix SLs by fixing DNS, even if you could fix DNS, which you can't. it's not reasonable for a DNS server to assume that the party making the query is the party that will use the address. actually DNS caching depends on DNS producing consistent results no matter who is making the query, and DNS caching is not don't exclusively by DNS servers. This again will work fine bzzzt. wrong again. The place SL starts to have trouble is when a multi-party app does referrals based on obtained addresses rather than names. which is a perfectly reasonable thing to do. it's how the Internet was designed to work. One reason that some people like private space is that they don't have to expose to their competitors what internal networks they are deploying and which office is coordinating that. there are far better ways to solve that problem than by crippling apps. We need to get past the arguments that private space == nat, no that's not the problem. the problem is that scoped addresses are dysfunctional. NAT has nothing to do with it.
RE: [Sip] Eating our own Dog Food...could the IAB and IESG use SIP forconference calls
So pure Internet SIP won't work for all of us any time soon. Glad to clear up the confusion on this point. People on the PSTN can dial in and can be called from the SIP conferencing server by using a service provider that has standard PSTN-SIP gateways. The typical SIP voice conference has both PSTN users and SIP users. Works quite well for everybody. IM can also be used at the same time, by those who prefer it to real time voice. Several SIP clients do both, actually video and data as well. Thanks, Henry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Harald Tveit Alvestrand Sent: Tuesday, March 25, 2003 1:14 PM To: Richard Shockey; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Sip] Eating our own Dog Food...could the IAB and IESG use SIP for conference calls Thanks for the idea! injecting a slight dash of cold water - the actual cost of Teleconferences and Long Distance charges in 2002 were USD 82.210 (unaudited) (vs 54.400 for 2001). A significant fraction of that, but far from all, is the IESG teleconferences. - we've already switched teleconference providers once to reduce costs, going from call-everyone to most-people-call-in. - the costliest part of the IESG teleconferences has been the callout: international participants (last year, France, the Netherlands, Norway and Sweden when they are at home, hotels literally anywhere in the world when they are travelling) are called rather than calling in. You don't want to discuss with your boss why you had to make a 2 1/2 hour international call at hotel room rates if you can avoid it.. - it's absolutely essential that one be able to participate in the IESG telecon from just about anything that one can dial from - we've had participants on cellphones from trains, in airport lounges, hotel rooms and other places. So SIP-only won't work for some time yet. - even at work, several of us have problems with firewalls; about half the IESG uses Jabber during sessions - the reason many of the others don't is that they can't get Jabber through their corporate firewalls. So pure Internet SIP won't work for all of us any time soon. So I think this is a good idea, PROVIDED THAT: - The SIP teleconference bridge provider is able to provide either 800-number access or callout services to normal telephones in most corners of the world - The voice quality, operator quality and call stability is competitive (yes, we've got the there's an echo on this conference - can you figure out who is echoing and fix it request down to a matter of routine) A normal teleconference provider that *also* allows SIP dialin over the Internet would probably be perfect. If you have one - send email to me - PRIVATELY - and I will forward to the relevant parties at the secretariat. Harald --On mandag, mars 24, 2003 19:04:17 -0500 Richard Shockey [EMAIL PROTECTED] wrote: Like many of us I was moved my Harald's appeal for suggestions for helping to cut down costs in the IETF. I certainly endorse the idea of considering Canada or Mexico as possible sites for future IETF meetings, but I suspect that the weekly teleconferece calls that the IAB and IESG have represent a significant line item for the Secretariat. In case anyone has not heard, SIP is quite capable of handling this type of task and there are a variety of commercial as well as open source Client User Agents as well as commercial products and services that could help reduce this cost. I'm sure the SIP working group could help the Secretariat identify products and services that could make this essential function more productive and operate at less cost. ___ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
