From owner-multi6@ops.ietf.org Fri Oct 12 07:12:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21737 for ; Fri, 12 Oct 2001 07:12:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15s0DF-000J3X-00 for multi6-data@psg.com; Fri, 12 Oct 2001 04:10:45 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.33 #1) id 15s0DE-000J3R-00 for multi6@ops.ietf.org; Fri, 12 Oct 2001 04:10:45 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21480; Fri, 12 Oct 2001 07:10:39 -0400 (EDT) Message-Id: <200110121110.HAA21480@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: multi6@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-huitema-multi6-hosts-00.txt Date: Fri, 12 Oct 2001 07:10:38 -0400 Sender: owner-multi6@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Host-Centric IPv6 Multihoming Author(s) : C. Huitema, R. Draves Filename : draft-huitema-multi6-hosts-00.txt Pages : 24 Date : 11-Oct-01 A way to solve the issue of site multihoming is to have a separate site prefix for each connection of the site, and to derive corresponding addresses for each host. This approach to multi- homing, which we call Host-Centric IPv6 Multihoming, has the advantage of minimal impact on the inter-domain routing fabric, since each site prefix can be aggregated within the larger prefix of a specific provider; however, it opens a number of issues. We analyze in detail the problem created by the interaction between ingress filtering and multihoming. We then propose a set of specific solutions that enable host centric multihoming, and we review how these solutions meet the requirements of IPv6 site multihoming. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-huitema-multi6-hosts-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-huitema-multi6-hosts-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-huitema-multi6-hosts-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011011132721.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-huitema-multi6-hosts-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-huitema-multi6-hosts-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011011132721.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-multi6@ops.ietf.org Fri Oct 12 11:38:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01713 for ; Fri, 12 Oct 2001 11:38:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15s4Gq-0002ED-00 for multi6-data@psg.com; Fri, 12 Oct 2001 08:30:44 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.33 #1) id 15s4Gp-0002DJ-00 for multi6@ops.ietf.org; Fri, 12 Oct 2001 08:30:43 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f9CFUeF07732 for ; Fri, 12 Oct 2001 18:30:40 +0300 Date: Fri, 12 Oct 2001 18:30:40 +0300 (EEST) From: Pekka Savola To: Subject: Re: I-D ACTION:draft-huitema-multi6-hosts-00.txt In-Reply-To: <200110121110.HAA21480@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 12 Oct 2001 Internet-Drafts@ietf.org wrote: > Title : Host-Centric IPv6 Multihoming > Author(s) : C. Huitema, R. Draves > Filename : draft-huitema-multi6-hosts-00.txt This could be a a rather simple and _natural_ way of doing multihoming. Comments below. A big issue, seen in very many places in the draft: Here it's very much assumed that ingress filtering is only performed at ISP-Customer border, by the ISP or possibly the site. This is often the case, but responsible sites (at least bigger sites) will do it internally too, e.g. between different site sub-parts. The strictest version of this would be it being done in every LAN connection, by ACL's or with RPF checks. Additional checking could also be done elsewhere, e.g. isp-bigISP or isp-transit border. If this method would restrict the scope of applicability of ingress filtering only to a few topological places ... doesn't sound good. In the draft, it should at least be considered where the filtering can be done and with which scope (e.g. if you allow both site prefixes, would it be okay). Another biggish issues that come to mind: - the reliance on DNS. - if you get two addresses from DNS, one which is unreachable (e.g. blackholed), how long does it _actually_ take to select the next one? this could take a _lot_ of time. If you try a tcp connection to an unanswering system, it's usually a _long_ time, in dozens of minutes in most implementations I've seen. More detailed comments... 2.2 Reference topology We assume that X, when it begins communicating with Y, has learned the addresses C:Y and D:Y, for example because they were published in the DNS. We do not assume that the DNS is dynamic: there will be situations in which both C:Y and D:Y are published, while in fact only one is reachable. ==> reachable from where? Depending on where the problems are, different people might have different opinions about the reachability. 4.1 [editorial] this means that the exit routers will have to obtain the right to use as source address a privileged IPv4 address ==> move 'as source address' to the end. Asking each potential end of the tunnel to relax its checks is not realistic; in practice, this means that the exit routers will have to obtain the right to use as source address a privileged IPv4 address, such as the 6to4 anycast address or the Shipworm anycast address; this will imply a negotiation with the provider of the IPv4 service. ==> you suggest a hack. IPv4 shipworm anycast address (and similarly proposed 6to4 address) was specifically allocated for _relays_, not to be used to get around IPv6 ingress filtering via this loophole. I oppose this. ==> General comment about 4.1: This very much assumes that ingress filtering is only done at one place, isp-site border. Responsible sites do it everywhere. ISP's might do it everywhere too (e.g. ISP-transit border). 4.2 Source address dependent routing Another solution to the site exit problem is to perform some kind of source routing within the site, so that the site exit is effectively a function of the source address in the packet. Current routers generally do not implement any kind of source address dependent routing ==> How is this different from IPv4 policy routing? (which is thought to be a very evil practise by many). 4.3 Source address selection by the host There will however be cases in which the prefix is learned after the source address is already selected. In these cases, the host could insert in the packet a "home address" option that carries the intended source address, as specified in [MOBILIP6]; the IPv6 source address will be set to the available interface address that matches the preferred source prefix. ==> Could you elaborate a bit on these cases (probably related to renumbering and/or the first stages of stateless address autoconfiguration)? ==> I'm not sure what you propose: the already selected address put in as a Home Address (probably), or as the real source address? If the address is already selected, and a new one will be used as the real source (assuming as above), what would be the disadvantage of re-selecting the first address too? ==> I do not like this tenuous connection to Mobile IPv6 at all; I do not consider random use of HA Option to be trusted by any means. As for path MTU discovery, source address discovery requires that the hosts receive some information from the network, presumably in the form of an "incorrect source address" ICMP error; the error message will have to contain information about the packet that triggered the error, and also information about the source address prefix that should be used to pass the source address check. In the absence of an explicit ICMP message, the hosts would have to rely on a trial-and-error process, noticing that packets get dropped and trying retransmissions with alternate source addresses; the experience of path MTU discovery shows that such processes are awkward and error prone. ==> I do not see why 'incorrect source address' ICMP message _without the accepted prefixes_ (which might be a security exposure, and difficult to implement), would not be sufficient. Usually a node would just have to try one or two packets with different source addresses to find one that matches. But I agress that an ICMP message, if we take this route, is a MUST. Another point: sending this kind of error messages should definitely be togglable. In this kind of scenario they make very much sense, but if the source address is spoofed, there is no sense in sending out ICMP messages to a forged address (possibly harassing someone innocent). A way here could be that the denied prefix would have to pass some ACL of "locally valid wrong source addresses" for the ICMP message to be sent, or the router should by some other means know the valid wrong source prefixes. 4.4 Packet rewriting at exit router ==> strong "eeevil!" on packet rewriting. Would break ESP/HA too, I suspect. ==> Tunneling is valid option but there is one additional problem: increased requirement for Path MTU. If node is already sending at the full MTU discovered, adding extra bytes may be physically impossible without fragmenting. One way to work around this might be to set the MTU of interfaces where you expect to do this so much lower that path MTU discovery will pick the lower value and leave room for encapsulation. Heavy to maintain. ==> promiscuous decapsulation is problematic as seen with 6to4 and shipworm and should definitely be avoided. 5.1.2 Site-exit redirection ICMP message ==> I believe the ICMP message must definitely contain as much as fits in 1280 bytes of the packet that triggered this message. It might be used as a weak form of "authentication" for the ICMP message. ==> I'm not sure if the 'preferred source address' is really that necessary (see above). 5.2.1 Use of "Router advertisements" In conformance with section 5.5.4 of [RFC2461], the hosts will deprecate the formerly preferred addresses when their preferred lifetime is set to zero. They will not use the deprecated addresses in new communication if an alternate (non-deprecated) address is available and has appropriate scope. ==> RFC2462, not 2461. We propose to use the "preferred" lifetime to indicate whether addresses derived from the prefix can be used as source address in multihomed networks. When a prefix is temporarily not available because the corresponding ISP connection is broken, routers SHOULD advertise a zero preferred lifetime for that prefix. ==> If I haven't misunderstood something, this scenario is unworkable if the RA is not authenticated due to checks in RFC2462 5.5.3.e 1-3). 6.1.6 Transport-Layer Survivability ==> I think more analysis of the solution is needed before this can be called TL survivable; you can achieve it with any method, I suppose, if you can assume on that MIPv6 can be used in the tight spot. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-multi6@ops.ietf.org Fri Oct 12 16:36:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09008 for ; Fri, 12 Oct 2001 16:36:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15s91X-000BNa-00 for multi6-data@psg.com; Fri, 12 Oct 2001 13:35:15 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15s91T-000BNQ-00 for multi6@ops.ietf.org; Fri, 12 Oct 2001 13:35:13 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f9CKaY035712; Fri, 12 Oct 2001 22:36:34 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 12 Oct 2001 22:36:34 +0200 (CEST) From: Iljitsch van Beijnum To: Pekka Savola cc: Subject: Re: I-D ACTION:draft-huitema-multi6-hosts-00.txt In-Reply-To: Message-ID: <20011012215647.G23624-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 12 Oct 2001, Pekka Savola wrote: > Here it's very much assumed that ingress filtering is only performed at > ISP-Customer border, by the ISP or possibly the site. This is often the > case, but responsible sites (at least bigger sites) will do it internally > too, e.g. between different site sub-parts. The strictest version of this > would be it being done in every LAN connection, by ACL's or with RPF > checks. That seems redundant. If you only accept valid addresses at the edges, how do packets with incorrect addresses get to the core? And aggressive filtering on source addresses is problematic with asymmetric routing, which is very common, so I would be surprised to hear that many ISPs do so. > Additional checking could also be done elsewhere, e.g. isp-bigISP or > isp-transit border. :-) Transit = default = the entire Internet = all packets from all sources are ok. > If this method would restrict the scope of applicability of ingress > filtering only to a few topological places ... doesn't sound good. If everybody filters at the edges that would be good enough. Many networks still don't. > Another biggish issues that come to mind: > - the reliance on DNS. This doesn't rely on the DNS any more than regular routing. > - if you get two addresses from DNS, one which is unreachable (e.g. > blackholed), how long does it _actually_ take to select the next one? > this could take a _lot_ of time. If you try a tcp connection to an > unanswering system, it's usually a _long_ time, in dozens of minutes in > most implementations I've seen. That is no good anyway. Do I have any use for a connection that is established after 119 seconds? Don't think so. One possible heuristic could be to expedite the timeout when there are still alternative addresses to try. What concerns me more is that the draft talks about sending multiple SYN packets at the same time. Is SYN flooding an offense yet under the new anti-terrorist laws? If this is going to happen there must be support to detect duplicate SYNs. This could be done by adding all the possible source addresses of the originating host and also an identifier that is unique at the source host. Then the receiving host could send back packets to all the addresses addresses of the originating host with all of its current source addresses in it. Then if a while later a duplicate packets start to come in, it can easily match those with the first one using the list of source addresses and the identifier. So if the first host sends packets from all of its source addresses to all of the destination host's addresses and the destination host replies with packets from all of its source addresses to all of the firs host's addresses, they would immediately know the best source/destination combo at each end and also fairly quickly learn what other source/destination combos work for the other end (when the duplicates arrive). But I think this should happen at the IP layer, for two reasons: - if these SYNs are processed by an unaware TCP, they will consume application resources (ie Apache process, serval MBs in core tied up waiting for a timeout) - TCP doesn't answer until the application answers. This can take a LONG time on busy servers - this information should survive sessions and also be available for other protocols than TCP > Another solution to the site exit problem is to perform some kind of > source routing within the site, so that the site exit is effectively > a function of the source address in the packet. Current routers > generally do not implement any kind of source address dependent > routing > ==> How is this different from IPv4 policy routing? (which is thought to > be a very evil practise by many). (raising hand) Policy routing is a more general mechanism in Cisco routers. A somewhat defendable way to do this would be to have different routing tables and have multiple "virtual routers" inside a real one. > ==> I do not see why 'incorrect source address' ICMP message _without the > accepted prefixes_ (which might be a security exposure, and difficult to > implement), would not be sufficient. Usually a node would just have to > try one or two packets with different source addresses to find one that > matches. Also, doesn't the "ICMP administratively prohibited" message effectively accomplish this? If a host has two source addresses, it just has to try a single other address when it receives such a message. Not nearly as bad as PMTU discovery. Also, when there is a TCP timeout it can retry with a different source address. I don't like messing around with Home Address options either. Shouldn't it be possible to just switch addresses during the session? If all source addresses associated with a session are known at the other end, there is no reason to impose that the source address can't change during the session. Or the destionation address, for that matter. If the other end restores all addresses to those needed in the TCP pseudo-header, there is no need to do any higher level (TCP checksum) processing and proxy agents can be permitted to rewrite both source and destination addresses, which will makes it possible for old-style hosts to use the new style multihoming. > 4.4 Packet rewriting at exit router > ==> strong "eeevil!" on packet rewriting. Would break ESP/HA too, I > suspect. There are worse things... Tunnels, for example. > ==> Tunneling is valid option but there is one additional problem: > increased requirement for Path MTU. If node is already sending at the > full MTU discovered, adding extra bytes may be physically impossible > without fragmenting. - more packet overhead - endpoint creation problems - scenic routing The PMTU discovery shouldn't be a problem, since it is mandatory in IPv6 so hopefully builders of stupid "security" products won't filter "packet too large" messages (or fail to generate them in the first place). But on the subject of tunnels: I don't see how tunneling to a site exit router does any good. Sure, the packets get out when everything works, but the whole point is that your sessions survive when something goes down. This means every exit router should be able to send out valid packets without any help from other routers. So if the source address is inconvenient for a certain border router, it should do something about that (rewrite, ICMP) and not send the packet to another router. > One way to work around this might be to set the MTU of interfaces where > you expect to do this so much lower that path MTU discovery will pick the > lower value and leave room for encapsulation. Heavy to maintain. It's better set the MTU of the output interfaces HIGHER. Shouldn't be a problem unless your uplink is <= 100 Mbps ether. From owner-multi6@ops.ietf.org Fri Oct 12 17:30:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10006 for ; Fri, 12 Oct 2001 17:30:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15s9rM-000CID-00 for multi6-data@psg.com; Fri, 12 Oct 2001 14:28:48 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.33 #1) id 15s9rL-000CI6-00 for multi6@ops.ietf.org; Fri, 12 Oct 2001 14:28:47 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f9CL3bf09558; Sat, 13 Oct 2001 00:03:37 +0300 Date: Sat, 13 Oct 2001 00:03:37 +0300 (EEST) From: Pekka Savola To: Iljitsch van Beijnum cc: Subject: Re: I-D ACTION:draft-huitema-multi6-hosts-00.txt In-Reply-To: <20011012215647.G23624-100000@sequoia.muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 12 Oct 2001, Iljitsch van Beijnum wrote: > On Fri, 12 Oct 2001, Pekka Savola wrote: > > > Here it's very much assumed that ingress filtering is only performed at > > ISP-Customer border, by the ISP or possibly the site. This is often the > > case, but responsible sites (at least bigger sites) will do it internally > > too, e.g. between different site sub-parts. The strictest version of this > > would be it being done in every LAN connection, by ACL's or with RPF > > checks. > > That seems redundant. If you only accept valid addresses at the edges, how > do packets with incorrect addresses get to the core? If you forget to do proper filtering at one edge point, mistype the command whatever, there's still some "safety net". It's good to have other kind of safeguards if you can. > And aggressive > filtering on source addresses is problematic with asymmetric routing, > which is very common, so I would be surprised to hear that many ISPs do > so. This is not being done for two reasons (at least): 1) it cannot be done by ISP with (most implementations of?) uRPF, most likely (your concern) 2) with IPv4, one big ISP may have hundreds/thousands of prefixes. Too big a list. With IPv6, they might only have one or a few prefix(es) to check. Easy. > > Additional checking could also be done elsewhere, e.g. isp-bigISP or > > isp-transit border. > > :-) Transit = default = the entire Internet = all packets from all > sources are ok. Transit, sure. But consider tranit-ISP border. ISP might want to check that source addresses of packets going to transit match its prefix(es). > > If this method would restrict the scope of applicability of ingress > > filtering only to a few topological places ... doesn't sound good. > > If everybody filters at the edges that would be good enough. Many networks > still don't. Sure, but filtering at the edges can fail if you do it in the "core" too. :-) > > Another biggish issues that come to mind: > > - the reliance on DNS. > > This doesn't rely on the DNS any more than regular routing. It relies on the DNS to get all the destination addresses. That is, if DNS doesn't work, or the destination is in the IP numeric form, and the destination networks other prefix is dead, you cannot talk to the destination's other address, as you can't find it in the DNS. The routing system itself doesn't rely on DNS, but hosts do. > > - if you get two addresses from DNS, one which is unreachable (e.g. > > blackholed), how long does it _actually_ take to select the next one? > > > this could take a _lot_ of time. If you try a tcp connection to an > > unanswering system, it's usually a _long_ time, in dozens of minutes in > > most implementations I've seen. > > That is no good anyway. Do I have any use for a connection that is > established after 119 seconds? Don't think so. One possible heuristic > could be to expedite the timeout when there are still alternative > addresses to try. True. > What concerns me more is that the draft talks about sending multiple SYN > packets at the same time. Is SYN flooding an offense yet under the new > anti-terrorist laws? I agree that multiple SYN's should not be sent; other connections should only be tried to be established after the first one fails. Unfortunately I don't think e.g. socket api has ways to do this, ie. specify that if the connection is not formed in 1sec, forget about it (or retry); you would have to do it with application, e.g. with non-blocking connect() and a timer. That is, this appears to be generally a no-go. > > ==> I do not see why 'incorrect source address' ICMP message _without the > > accepted prefixes_ (which might be a security exposure, and difficult to > > implement), would not be sufficient. Usually a node would just have to > > try one or two packets with different source addresses to find one that > > matches. > > Also, doesn't the "ICMP administratively prohibited" message effectively > accomplish this? You could get administratively prohibited message for a lot of different reasons; not necessarily a bad source address. But I agree that at least if one would like to test how this would work in practise, administratively prohibited wouldn't be too far off the mark. > > 4.4 Packet rewriting at exit router > > > ==> strong "eeevil!" on packet rewriting. Would break ESP/HA too, I > > suspect. > > There are worse things... Tunnels, for example. Open-ended tunnels (that were referred to in the draft) are bad, but I don't think configured p-t-p tunnels are always that bad. > > ==> Tunneling is valid option but there is one additional problem: > > increased requirement for Path MTU. If node is already sending at the > > full MTU discovered, adding extra bytes may be physically impossible > > without fragmenting. > > - more packet overhead > - endpoint creation problems > - scenic routing > > The PMTU discovery shouldn't be a problem, since it is mandatory in IPv6 > so hopefully builders of stupid "security" products won't filter "packet > too large" messages (or fail to generate them in the first place). Should not be, yes. I don't think if one packet sent lost by this would be noticeable. (host sends e.g. 1500B, 50ms away there is mtu 1480B, first packet delivery delayed at least 150ms unless the path MTU was cached). > But on the subject of tunnels: I don't see how tunneling to a site exit > router does any good. Sure, the packets get out when everything works, but > the whole point is that your sessions survive when something goes down. > This means every exit router should be able to send out valid packets > without any help from other routers. So if the source address is > inconvenient for a certain border router, it should do something about > that (rewrite, ICMP) and not send the packet to another router. I partially disagree. The most important thing is the system to "plain work". If one can avoid short or even longer breaks by doing something like tunneling, fine. I wouldn't advocate tunneling as a solution for load-balancing or the like though. But under a more-or-less emergency situation, everything is should be possible. > > One way to work around this might be to set the MTU of interfaces where > > you expect to do this so much lower that path MTU discovery will pick the > > lower value and leave room for encapsulation. Heavy to maintain. > > It's better set the MTU of the output interfaces HIGHER. Shouldn't be a > problem unless your uplink is <= 100 Mbps ether. Sure, so it would be better. But that is not always physically possible. And your clients could be connecting with POS, GE with jumbograms etc. or something else with an equally high MTU as your uplink too. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-multi6@ops.ietf.org Mon Oct 15 07:24:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23658 for ; Mon, 15 Oct 2001 07:24:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15t5lm-000PgK-00 for multi6-data@psg.com; Mon, 15 Oct 2001 04:18:54 -0700 Received: from [194.78.143.71] (helo=hrtades9.atea.be) by psg.com with esmtp (Exim 3.33 #1) id 15t5lj-000PgD-00 for multi6@ops.ietf.org; Mon, 15 Oct 2001 04:18:51 -0700 Received: from hrtades10.atea.be (siemens.atea.be [139.10.143.141]) by hrtades9.atea.be with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T8JBBA9P; Mon, 15 Oct 2001 13:18:25 +0200 Received: by siemens.atea.be with Internet Mail Service (5.5.2653.19) id <48L83DMX>; Mon, 15 Oct 2001 13:18:35 +0200 Message-ID: From: Coene Lode To: "'richdr@microsoft.com'" , "'huitema@microsoft.com'" Cc: multi6@ops.ietf.org Subject: comments on Host-Centric IPv6 Multihoming Date: Mon, 15 Oct 2001 13:17:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-multi6@ops.ietf.org Precedence: bulk Dear Christian & Richard A editorial nit first: chapter 3.3 on page 5, paragraph below figure: "...If the chosen exit router at Site X is RXB, the packet will flow freely to RYC; if the chosen exit router at Site X is RYC, the response will also flow freely. ..." The second "Site X" should be "Site Y", I think. Site X doesn't have a exit router called RYC, but Site Y has. On with the more serious stuff: chapter 3.1 on page 4: Destination address selection > >The destination address selection let hosts select an address from the list provided by names services such as the >DNS. Improving the address selection algorithm may result in address choices that provide improved performances; >however, if the selected address is in fact unreachable, the host will typically have to wait for a timer, notice the absence >of response, and try another address in the list. One may debate whether this is better or worse than the current IPv4 >solution, in which a domain may be temporarily unreachable while the routing converges to a new state; in any case, a >solution that would not involve errors, delays and re-trials would be preferable. An obvious improvement here would be to >make sure that the name servers to only list addresses that are reachable, and are quickly updated when a change in the >site connectivity results in a change in the list of available addresses. > Mmm, a third party that does know it better how things are going in the network. To me a bit far fetched. Imagine it being the DNS: depending on the TTL of the relevant information and the place from where the query was launched, I wouldn't count on any relialable info concerning the reachability of a host(let alone a network) , it would always be out of date. At least the transport would know it earlier as its byte/msg stream is interrupted and it has the possibility to changeover to another destination. If the transport layer would ask it to DNS,... well not convinced DNS would do any better, more likely worse. And then I forget that application ask something to DNS before they invoke the transport layer. It would mean that the transport layer would have a direct interface to DNS, not something that I am longing for. I would certainly never count on the DNS for reachability information in any solution(but that is my opinion) Leave it to the transport layer to joggle with the destination addresses for reachability. chapter 3.2 on page 4: Source address selection > >Choosing the source address will affect the reverse path of the connection, as the source address of the message will >become the destination address of the responses. This may be a serious matter in asymmetric applications like web >access, in which the bulk of the data is sent by the server to the client. If the multiple addresses correspond to different >ISPs, ideally the host would pick the source address that will provide the best performance. As for destination address >selection, we may expect that the host will have some knowledge of the effect of choosing one or the other address, for >example by observing that web pages are served faster through one address than through the other. > I agree with first sentence, that the selection of source address in the initiating node will determine the reverse path . The host could try to pick the best address but the only one on the host that has a clear view on this would be the host's transport layer: (it knows the addresses used within a association or all the TCP connections hurded together towards its peer . I am not quite sure that the host network layer would make sense out of it tryng to find the best performance. It could also result in some sort of loadsharing across different paths(a path is meant to be a certain source -destaination address tuple or also know as a transport address) something that hasn't been researched very much. In any case the transports layers presently used such as SCTP have multiple paths but are are not allowed to loadshare across the paths in the association and in case of TCP will have a single path for each of its connections. if loadinfo is contained in a third party(such as DNS) then things look even more bad. Conclusion: leave the DNS out of it, the (fill in your favourite description) is alreay overloaded enough. chapter 3.4 on page 5: Rapid reaction to topology changes > if the destination address selection is done by the transport, then no objection over here. They got the tools to measure the "quality" of the path. If others means are employed then all bets are off. chapter 4.2 on page 7-8: Source address dependent routing > If I understand this correctly, then the exit router (be it a single one or multiple) seems to have different paths to the same prefix avialable at the same time. If that is the case, then that is like a open invitation to use those 2 paths at the same time. There might be a way to use those 2 (or more paths) in the transport layer§be it TCP or SCTP) with some rules in the network for selecting the links, so that the congestion control in the transport (TCP or SCTP) won't go haywire. I am trying to figure this out, there might be a ID out before Salt Lake city meeting on it. (It migth NOT fit all the requirements of this WG but at least it is a worthwhile effort and might fit the bill very nicely for some other folks) There are still some weird things that are not clear to me, such as why is the host routing the msg towards the router with the incorrect source address prefix..... Conclusion: This clearly goes in the right direction, especially if thirdparty stuff is left out of it. Pity that it is only a edge based solution. yours sincerly, Lode Coene Siemens atea ICN D CS D Software development Atealaan 34 B-2200 Herentals Belgium Tel: +32-14-2-52081 Fax: +32-14-2-53212 E-mail: lode.coene@siemens.atea.be From owner-multi6@ops.ietf.org Mon Oct 22 02:09:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04759 for ; Mon, 22 Oct 2001 02:09:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15vYCH-000BsC-00 for multi6-data@psg.com; Sun, 21 Oct 2001 23:04:25 -0700 Received: from evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net ([4.60.69.141] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.33 #1) id 15vYCG-000Brn-00 for multi6@ops.ietf.org; Sun, 21 Oct 2001 23:04:24 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Sun, 21 Oct 2001 23:04:18 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 4BD429DFB60348E28F2AD537BA896FAE for plus 6 more; Sun, 21 Oct 2001 23:04:17 -0700 From: "Tony Hain" To: Cc: , , , , , Subject: Update to Provider Independent addressing format drafts Date: Sun, 21 Oct 2001 23:04:00 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-SLUIDL: EE2F0709-FFDC4238-9E8CAA2A-31D3EF30 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The updates to the provider independent address format & usage drafts are available at: http://www.tndh.net/~tony/ietf/draft-hain-ipv6-pi-addr-fmt-01.txt http://www.tndh.net/~tony/ietf/draft-hain-ipv6-pi-addr-use-01.txt The usage document has been significantly reworked to address both direct comments, as well as distillation of key issues from various mail threads on nanog & multi6 lists. At this point comments should be directed to the multi6 list. Tony From owner-multi6@ops.ietf.org Mon Oct 22 02:18:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05371 for ; Mon, 22 Oct 2001 02:18:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15vYP4-000CH8-00 for multi6-data@psg.com; Sun, 21 Oct 2001 23:17:38 -0700 Received: from coconut.itojun.org ([210.160.95.97]) by psg.com with esmtp (Exim 3.33 #1) id 15vYP2-000CH2-00 for multi6@ops.ietf.org; Sun, 21 Oct 2001 23:17:37 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id A3AF04B22 for ; Mon, 22 Oct 2001 15:17:32 +0900 (JST) To: multi6@ops.ietf.org Subject: RFC3178: IPv6 Multihoming Support at Site Exit Routers X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: itojun@iijlab.net MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <5210.1003731433.0@itojun.org> Date: Mon, 22 Oct 2001 15:17:32 +0900 Message-ID: <5217.1003731452@itojun.org> Sender: owner-multi6@ops.ietf.org Precedence: bulk ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5210.1003731433.1@itojun.org> FYI. itojun ------- =_aaaaaaaaaa0 Content-Type: message/rfc822 Content-ID: <5210.1003731433.2@itojun.org> Content-Description: forwarded message Return-Path: Delivered-To: itojun@itojun.org Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by coconut.itojun.org (Postfix) with ESMTP id D8C5B4B22 for ; Sat, 20 Oct 2001 09:02:05 +0900 (JST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08287; Fri, 19 Oct 2001 18:00:32 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA27759; Fri, 19 Oct 2001 17:00:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JNxxOI001182 for ; Fri, 19 Oct 2001 16:59:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JNxxXw001181 for ipng-dist; Fri, 19 Oct 2001 16:59:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JNxtOI001174 for ; Fri, 19 Oct 2001 16:59:55 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA26762 for ; Fri, 19 Oct 2001 16:59:51 -0700 (PDT) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA04403 for ; Fri, 19 Oct 2001 16:59:57 -0700 (PDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id f9JNxtH26276; Fri, 19 Oct 2001 16:59:55 -0700 (PDT) Message-Id: <200110192359.f9JNxtH26276@gamma.isi.edu> To: IETF-Announce: ; Subject: RFC 3178 on IPv6 Multihoming Support at Site Exit Routers Cc: rfc-ed@ISI.EDU, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 19 Oct 2001 16:59:55 -0700 From: RFC Editor Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk X-Filter: mailagent [version 3.0 PL73] for itojun@itojun.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3178 Title: IPv6 Multihoming Support at Site Exit Routers Author(s): J. Hagino, H. Snyder Status: Informational Date: October 2001 Mailbox: itojun@iijlab.net, hal@vailsys.com Pages: 12 Characters: 24453 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipngwg-ipv6-2260-02.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3178.txt The document describes a mechanism for basic IPv6 multihoming support, and its operational requirements. Unlike currently-practiced IPv4 multihoming, the technique does not impact the worldwide routing table size, nor IGP (Interior Gateway Protocol) routing table size in upstream ISPs. The mechanism can be combined with more sophisticated (or complex) multihoming support mechanisms, and can be used as a foundation for other mechanisms. The document is largely based on RFC 2260 by Tony Bates. This document is a product of the IPNG Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <011019165829.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3178 --OtherAccess Content-Type: Message/External-body; name="rfc3178.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <011019165829.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- ------- =_aaaaaaaaaa0-- From owner-multi6@ops.ietf.org Mon Oct 22 03:26:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08437 for ; Mon, 22 Oct 2001 03:26:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15vZST-000EQM-00 for multi6-data@psg.com; Mon, 22 Oct 2001 00:25:13 -0700 Received: from coconut.itojun.org ([210.160.95.97]) by psg.com with esmtp (Exim 3.33 #1) id 15vZSS-000EQA-00 for multi6@ops.ietf.org; Mon, 22 Oct 2001 00:25:13 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 1FEE44B23; Mon, 22 Oct 2001 16:25:06 +0900 (JST) To: "Tony Hain" Cc: multi6@ops.ietf.org In-reply-to: alh-ietf's message of Sun, 21 Oct 2001 23:04:00 MST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Provider Independent addressing format drafts From: itojun@iijlab.net Date: Mon, 22 Oct 2001 16:25:06 +0900 Message-ID: <5859.1003735506@itojun.org> Sender: owner-multi6@ops.ietf.org Precedence: bulk >The updates to the provider independent address format & usage drafts >are available at: >http://www.tndh.net/~tony/ietf/draft-hain-ipv6-pi-addr-fmt-01.txt >http://www.tndh.net/~tony/ietf/draft-hain-ipv6-pi-addr-use-01.txt I still don't understand how PI address format can be routed in currently-practiced routing infrastructure. PI address, based on physical location can behave very poorly against aggregation. example: I'm using 1fff:ffff:ffff::/48 and connected to ISP A, while my neighbor is using 1fff:ffff:fffe::/48 and connected to ISP B. ISP A and B needs to exchange /48 routes to route between us. I believe we end up having 2^44 routes in the routing system with the PI address allocation. are there any magic I'm missing? examples given in the drafts did not convince me at all. another comment - in the document, it is mentioned that the allocation of a single /48 must be solved by "local jurisdiction". I don't think it workable for highly populated area (think of NY, tokyo, whatever), where skyscrapers make hundreds of companies to share the same geographical location. it may work for less populated area (imagine any farms in middle-of-nowhere). itojun From owner-multi6@ops.ietf.org Mon Oct 22 12:24:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21926 for ; Mon, 22 Oct 2001 12:24:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15vhq8-0003nX-00 for multi6-data@psg.com; Mon, 22 Oct 2001 09:22:12 -0700 Received: from internet-gateway2-x.zurich.ibm.com ([195.212.119.243] helo=internet-gateway2.zurich.ibm.com) by psg.com with esmtp (Exim 3.33 #1) id 15vhq7-0003nP-00 for multi6@ops.ietf.org; Mon, 22 Oct 2001 09:22:11 -0700 Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id SAA11596; Mon, 22 Oct 2001 18:22:08 +0200 Received: from lig32-227-114-97.us.lig-dial.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA77116 from ; Mon, 22 Oct 2001 18:21:58 +0200 Message-Id: <3BD447D5.5EEABCEE@hursley.ibm.com> Date: Mon, 22 Oct 2001 18:22:45 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: itojun@iijlab.net Cc: Tony Hain , multi6@ops.ietf.org Subject: Re: Provider Independent addressing format drafts References: <5859.1003735506@itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I agree. I think this is *very bad* for aggregation, since it won't just be the IBM's of this world who go for it. If every small company goes for a PI /48, the BGP table is a lost cause. I don't believe this is a good idea. I think the correct solution is PA, with PA /35 (or thereabouts) prefixes being used by local neutral exchange points - and policy mechanisms beyond the scope of the IETF to create those exchange points. I don't believe there is anything more we can do in this area by writing standards. Brian itojun@iijlab.net wrote: > > >The updates to the provider independent address format & usage drafts > >are available at: > >http://www.tndh.net/~tony/ietf/draft-hain-ipv6-pi-addr-fmt-01.txt > >http://www.tndh.net/~tony/ietf/draft-hain-ipv6-pi-addr-use-01.txt > > I still don't understand how PI address format can be routed in > currently-practiced routing infrastructure. PI address, based on > physical location can behave very poorly against aggregation. > example: > I'm using 1fff:ffff:ffff::/48 and connected to ISP A, while > my neighbor is using 1fff:ffff:fffe::/48 and connected to ISP B. > ISP A and B needs to exchange /48 routes to route between us. > I believe we end up having 2^44 routes in the routing system with > the PI address allocation. are there any magic I'm missing? > examples given in the drafts did not convince me at all. > > another comment - in the document, it is mentioned that the allocation > of a single /48 must be solved by "local jurisdiction". > I don't think it workable for highly populated area (think of NY, tokyo, > whatever), where skyscrapers make hundreds of companies to share the > same geographical location. it may work for less populated area > (imagine any farms in middle-of-nowhere). > > itojun From owner-multi6@ops.ietf.org Mon Oct 22 14:48:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26920 for ; Mon, 22 Oct 2001 14:48:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15vk6F-0006iF-00 for multi6-data@psg.com; Mon, 22 Oct 2001 11:46:59 -0700 Received: from evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net ([4.60.69.141] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.33 #1) id 15vk6E-0006i9-00 for multi6@ops.ietf.org; Mon, 22 Oct 2001 11:46:58 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Mon, 22 Oct 2001 11:46:52 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id AAE969A1C2FF41F69FFDED9807E41569 for plus 1 more; Mon, 22 Oct 2001 11:46:51 -0700 From: "Tony Hain" To: "Brian E Carpenter" Cc: Subject: RE: Provider Independent addressing format drafts Date: Mon, 22 Oct 2001 11:46:26 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3BD447D5.5EEABCEE@hursley.ibm.com> X-SLUIDL: 9C8EB196-31C0410F-850CA83D-1CF88A3E Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > I agree. I think this is *very bad* for aggregation, since it > won't just > be the IBM's of this world who go for it. If every small company goes > for a PI /48, the BGP table is a lost cause. I don't believe this > is a good idea. Please read the current text. The recommendation specifically addresses the small business / telecommuter case. Tony From owner-multi6@ops.ietf.org Mon Oct 22 14:48:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26931 for ; Mon, 22 Oct 2001 14:48:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15vk6A-0006i5-00 for multi6-data@psg.com; Mon, 22 Oct 2001 11:46:54 -0700 Received: from evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net ([4.60.69.141] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.33 #1) id 15vk69-0006hx-00 for multi6@ops.ietf.org; Mon, 22 Oct 2001 11:46:53 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Mon, 22 Oct 2001 11:46:41 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 822C29B9DBE44488A08222FDC7231CA8 for plus 1 more; Mon, 22 Oct 2001 11:46:38 -0700 From: "Tony Hain" To: Cc: Subject: RE: Provider Independent addressing format drafts Date: Mon, 22 Oct 2001 11:46:17 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <5859.1003735506@itojun.org> X-SLUIDL: B4CA617A-45894A72-A14F00DD-1CD222C7 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit itojun wrote: > I believe we end up having 2^44 routes in the routing > system with > the PI address allocation. are there any magic I'm missing? > examples given in the drafts did not convince me at all. Yes you are missing the point. The magic is that you only have the /48 over a given region, so you are really talking about O 2^20 or so. If that is too big the region needs to be split up with additional exchanges. > I don't think it workable for highly populated area > (think of NY, tokyo, > whatever), where skyscrapers make hundreds of companies > to share the > same geographical location. Please provide a specific example rather than spread FUD. If you read through the doc high rise buildings are specifically addressed in the text. Tony From owner-multi6@ops.ietf.org Mon Oct 22 15:41:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28020 for ; Mon, 22 Oct 2001 15:41:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15vkvY-00082y-00 for multi6-data@psg.com; Mon, 22 Oct 2001 12:40:00 -0700 Received: from internet-gateway2-x.zurich.ibm.com ([195.212.119.243] helo=internet-gateway2.zurich.ibm.com) by psg.com with esmtp (Exim 3.33 #1) id 15vkvW-00082i-00 for multi6@ops.ietf.org; Mon, 22 Oct 2001 12:39:59 -0700 Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id VAA15208; Mon, 22 Oct 2001 21:39:56 +0200 Received: from [9.29.3.171] by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA75506 from ; Mon, 22 Oct 2001 21:39:52 +0200 Message-Id: <3BD4760E.9DFEE2AA@hursley.ibm.com> Date: Mon, 22 Oct 2001 21:39:58 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Tony Hain Cc: multi6@ops.ietf.org Subject: Re: Provider Independent addressing format drafts References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tony Hain wrote: > > Brian E Carpenter wrote: > > I agree. I think this is *very bad* for aggregation, since it > > won't just > > be the IBM's of this world who go for it. If every small company goes > > for a PI /48, the BGP table is a lost cause. I don't believe this > > is a good idea. > > Please read the current text. The recommendation specifically addresses > the small business / telecommuter case. Yes, and I don't believe it will work as you expect. Small companies will use PI /48s and ISPs will announce them in exchange for money. Tragedy of the commons all over again. Brian From owner-multi6@ops.ietf.org Mon Oct 22 15:55:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28398 for ; Mon, 22 Oct 2001 15:55:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15vl9r-0008T5-00 for multi6-data@psg.com; Mon, 22 Oct 2001 12:54:47 -0700 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 15vl9q-0008Sz-00 for multi6@ops.ietf.org; Mon, 22 Oct 2001 12:54:46 -0700 Subject: RE: Provider Independent addressing format drafts Date: Mon, 22 Oct 2001 12:54:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046403AE9E@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Thread-Topic: Provider Independent addressing format drafts Thread-Index: AcFbMrf/5XuZZgn3RJWd3EKzbJgUwwAAAL3Q From: "Michel Py" To: "Brian E Carpenter" Cc: Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA28398 >> Yes, and I don't believe it will work as you expect. Small companies will >> use PI /48s and ISPs will announce them in exchange for money. Tragedy of >> the commons all over again. I have to agree with Brian here. Another possible scenario: bigger companies will try and sometimes succeed in obtaining a TLA for the sole purpose of being able to announce their prefixes. Michel From owner-multi6@ops.ietf.org Mon Oct 22 16:05:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28687 for ; Mon, 22 Oct 2001 16:05:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15vlH8-0008lJ-00 for multi6-data@psg.com; Mon, 22 Oct 2001 13:02:18 -0700 Received: from evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net ([4.60.69.141] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.33 #1) id 15vlH7-0008lC-00 for multi6@ops.ietf.org; Mon, 22 Oct 2001 13:02:17 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Mon, 22 Oct 2001 13:02:12 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 90144A1323ED4C4A9D9DA7C8D3ED0A5E for plus 2 more; Mon, 22 Oct 2001 13:02:11 -0700 From: "Tony Hain" To: "Brian E Carpenter" , "Tony Hain" Cc: Subject: RE: Provider Independent addressing format drafts Date: Mon, 22 Oct 2001 13:01:52 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3BD4760E.9DFEE2AA@hursley.ibm.com> X-SLUIDL: AD656F55-983E43B1-8E5A86C7-D66F8AD2 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > Yes, and I don't believe it will work as you expect. Small > companies will > use PI /48s and ISPs will announce them in exchange for > money. Tragedy of > the commons all over again. Yes the direct connected ISP has to announce the /48 for any redundancy to work, and that will happen no matter what format we choose. What this version of the document is suggesting is that those small business /48's be restricted to a region by virtue of a well defined policy which says only 4 /48's per origin AS. Unless the small business can justify that it has a distinct policy from its providers it will not have an AS, so its /48 will appear with origins from each of the connected providers. Since those AS's will be origin for well over 4, they will be filtered and restricted to a region. Tony From owner-multi6@ops.ietf.org Mon Oct 22 17:23:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00033 for ; Mon, 22 Oct 2001 17:23:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15vmX5-000BCg-00 for multi6-data@psg.com; Mon, 22 Oct 2001 14:22:51 -0700 Received: from internet-gateway2-x.zurich.ibm.com ([195.212.119.243] helo=internet-gateway2.zurich.ibm.com) by psg.com with esmtp (Exim 3.33 #1) id 15vmX4-000BCY-00 for multi6@ops.ietf.org; Mon, 22 Oct 2001 14:22:50 -0700 Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id XAA08648; Mon, 22 Oct 2001 23:22:47 +0200 Received: from [9.29.3.171] by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA41940 from ; Mon, 22 Oct 2001 23:22:42 +0200 Message-Id: <3BD48DF7.550DD307@hursley.ibm.com> Date: Mon, 22 Oct 2001 23:21:59 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Tony Hain Cc: multi6@ops.ietf.org Subject: Re: Provider Independent addressing format drafts References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Yes, Tony, but that is a policy decision - not something the IETF can dictate by a standard, and one that personally I don't think the ISP community would respect. Brian Tony Hain wrote: > > Brian E Carpenter wrote: > > Yes, and I don't believe it will work as you expect. Small > > companies will > > use PI /48s and ISPs will announce them in exchange for > > money. Tragedy of > > the commons all over again. > > Yes the direct connected ISP has to announce the /48 for any redundancy > to work, and that will happen no matter what format we choose. What this > version of the document is suggesting is that those small business /48's > be restricted to a region by virtue of a well defined policy which says > only 4 /48's per origin AS. Unless the small business can justify that > it has a distinct policy from its providers it will not have an AS, so > its /48 will appear with origins from each of the connected providers. > Since those AS's will be origin for well over 4, they will be filtered > and restricted to a region. > > Tony -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland Board Chairman, Internet Society http://www.isoc.org From owner-multi6@ops.ietf.org Mon Oct 22 19:37:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01516 for ; Mon, 22 Oct 2001 19:37:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15voau-000F0s-00 for multi6-data@psg.com; Mon, 22 Oct 2001 16:34:56 -0700 Received: from coconut.itojun.org ([210.160.95.97]) by psg.com with esmtp (Exim 3.33 #1) id 15voat-000F0l-00 for multi6@ops.ietf.org; Mon, 22 Oct 2001 16:34:56 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 3D0AE4B22; Tue, 23 Oct 2001 08:34:45 +0900 (JST) To: "Tony Hain" Cc: multi6@ops.ietf.org In-reply-to: alh-ietf's message of Mon, 22 Oct 2001 11:46:17 MST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Provider Independent addressing format drafts From: itojun@iijlab.net Date: Tue, 23 Oct 2001 08:34:45 +0900 Message-ID: <12228.1003793685@itojun.org> Sender: owner-multi6@ops.ietf.org Precedence: bulk >> I don't think it workable for highly populated area (think of NY, tokyo, >> whatever), where skyscrapers make hundreds of companies to share the >> same geographical location. >Please provide a specific example rather than spread FUD. If you read >through the doc high rise buildings are specifically addressed in the >text. I saw draft-hain-ipv6-PI-addr-use-01.txt, page 8 (extend grid to 150m square). i don't believe it works, as I don't believe local jurisdiction functions. and don't call my comment a FUD. itojun From owner-multi6@ops.ietf.org Mon Oct 22 19:59:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01754 for ; Mon, 22 Oct 2001 19:59:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15voy1-000Fd4-00 for multi6-data@psg.com; Mon, 22 Oct 2001 16:58:49 -0700 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 15voy0-000Fcu-00 for multi6@ops.ietf.org; Mon, 22 Oct 2001 16:58:48 -0700 Subject: RE: (ngtrans) Update to Provider Independent addressing format drafts Date: Mon, 22 Oct 2001 16:58:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046403AEA5@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Thread-Topic: (ngtrans) Update to Provider Independent addressing format drafts Thread-Index: AcFav7w1CLT7OQwIQ+a8fDuSkkKHMgAlQQ1w From: "Michel Py" To: "Tony Hain" Cc: , , , , , Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA01754 Editorial: Interaction with routing.............Error! Bookmark not defined. My $0.02 about it: As an end customer, I don't find it as appealing as an IPv4 PI block. There is something about IPv4 PI blocks that you kind of "own" the address space. Large corporations that have (with or without a valid reason) a tendency to geographically relocate would have to re-number. Michel. -----Original Message----- From: Tony Hain [mailto:alh-ietf@tndh.net] Sent: Sunday, October 21, 2001 11:04 PM To: internet-drafts@ietf.org Cc: multi6@ops.ietf.org; nanog@merit.edu; ipng@sunroof.eng.sun.com; ngtrans@sunroof.eng.sun.com; tech@ipv6forum.com; ipv6-directorate@sunroof.eng.sun.com Subject: (ngtrans) Update to Provider Independent addressing format drafts The updates to the provider independent address format & usage drafts are available at: http://www.tndh.net/~tony/ietf/draft-hain-ipv6-pi-addr-fmt-01.txt http://www.tndh.net/~tony/ietf/draft-hain-ipv6-pi-addr-use-01.txt The usage document has been significantly reworked to address both direct comments, as well as distillation of key issues from various mail threads on nanog & multi6 lists. At this point comments should be directed to the multi6 list. Tony From owner-multi6@ops.ietf.org Tue Oct 23 00:36:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06961 for ; Tue, 23 Oct 2001 00:36:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15vtGY-000LTs-00 for multi6-data@psg.com; Mon, 22 Oct 2001 21:34:14 -0700 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 15vtGX-000LTl-00 for multi6@ops.ietf.org; Mon, 22 Oct 2001 21:34:13 -0700 Subject: RE: (ngtrans) Update to Provider Independent addressing format drafts Date: Mon, 22 Oct 2001 21:34:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <2B81403386729140A3A899A8B39B046403AEA6@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Thread-Topic: (ngtrans) Update to Provider Independent addressing format drafts Thread-Index: AcFbcYTQdXRqNl6rQqyLmNKwU+fCVwABM2pw From: "Michel Py" To: "Keith Moore" Cc: , Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA06961 Keith-- >> if you're doing a massive relocation in physical space, the renumbering >> of your IP network doesn't seem like a huge additional burden. Sometimes, and sometimes not. I have moved entire data rooms over the weekend. It's a matter of logistics and bandwidth to cope with traffic that has not moved yet or that has moved prior to the data room. I have seen server farm moves over two weeks. It's most of the time dirty, but you can indeed bridge a LAN over an OC-48 or bigger using LANE. In short, physical move is only money. If you're a telco or affiliated, it's "monopoly" money. On the other hand, renumbering means headaches and time and downtime, not to mention a few "permit ip any any" to overcome poor planning. IMHO, depending whom you work for and which hat you wear, a physical move can be a lot easier and a lot cheaper than a renumbering. In many situations, it will create un unmanageable monster, other story. Michel From owner-multi6@ops.ietf.org Tue Oct 23 02:28:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20406 for ; Tue, 23 Oct 2001 02:28:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15vv0N-000Mqj-00 for multi6-data@psg.com; Mon, 22 Oct 2001 23:25:39 -0700 Received: from evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net ([4.60.69.141] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.33 #1) id 15vv0M-000Mqd-00 for multi6@ops.ietf.org; Mon, 22 Oct 2001 23:25:38 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Mon, 22 Oct 2001 23:25:27 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 7FC1106C25774905AAF08B349DCE1E45 for plus 1 more; Mon, 22 Oct 2001 23:25:26 -0700 From: "Tony Hain" To: Cc: Subject: RE: Provider Independent addressing format drafts Date: Mon, 22 Oct 2001 23:25:03 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <12228.1003793685@itojun.org> X-SLUIDL: 9B5341D0-F6F94D1A-86B76E3D-0FA17517 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit itojun wrote: > i don't believe it works, as I don't believe local ^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ > jurisdiction functions. and don't call my comment a FUD. > I only called it FUD because you are stating your belief rather than specific detail of an instance where it doesn't work. Lots of people hold the belief it won't work, but how many of those are based on a simple resistance to think differently about the possible solution space? Tony From owner-multi6@ops.ietf.org Tue Oct 23 02:35:11 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20835 for ; Tue, 23 Oct 2001 02:35:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15vv9M-000Mzo-00 for multi6-data@psg.com; Mon, 22 Oct 2001 23:34:56 -0700 Received: from miata.procket.com ([209.140.237.2]) by psg.com with esmtp (Exim 3.33 #1) id 15vv9L-000Mzh-00 for multi6@ops.ietf.org; Mon, 22 Oct 2001 23:34:55 -0700 Received: from alpha-tli.procket.com (IDENT:root@alpha-tli.procket.com [10.2.3.1]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id f9N6YmCD018155; Mon, 22 Oct 2001 23:34:48 -0700 (PDT) Received: (from tli@localhost) by alpha-tli.procket.com (8.12.1/8.12.1) id f9N6Yln7019939; Mon, 22 Oct 2001 23:34:47 -0700 From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15317.3975.754286.758350@alpha-tli.procket.com> Date: Mon, 22 Oct 2001 23:34:47 -0700 To: "Michel Py" Cc: "Keith Moore" , , Subject: RE: (ngtrans) Update to Provider Independent addressing format drafts In-Reply-To: <2B81403386729140A3A899A8B39B046403AEA6@server2000.arneill-py.sacramento.ca.us> References: <2B81403386729140A3A899A8B39B046403AEA6@server2000.arneill-py.sacramento.ca.us> X-Mailer: VM 6.92 under Emacs 20.5.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I have to admit to considerable amusement to see people arguing that renumbering in V6 is too painful. Tony From owner-multi6@ops.ietf.org Tue Oct 23 02:57:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22238 for ; Tue, 23 Oct 2001 02:57:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15vvUR-000NPs-00 for multi6-data@psg.com; Mon, 22 Oct 2001 23:56:43 -0700 Received: from coconut.itojun.org ([210.160.95.97]) by psg.com with esmtp (Exim 3.33 #1) id 15vvUR-000NPm-00 for multi6@ops.ietf.org; Mon, 22 Oct 2001 23:56:43 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 7C2F84B22; Tue, 23 Oct 2001 15:56:36 +0900 (JST) To: "Tony Hain" Cc: multi6@ops.ietf.org In-reply-to: alh-ietf's message of Mon, 22 Oct 2001 23:25:03 MST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Provider Independent addressing format drafts From: itojun@iijlab.net Date: Tue, 23 Oct 2001 15:56:36 +0900 Message-ID: <7146.1003820196@itojun.org> Sender: owner-multi6@ops.ietf.org Precedence: bulk >itojun wrote: >> i don't believe it works, as I don't believe local > ^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ >> jurisdiction functions. and don't call my comment a FUD. >I only called it FUD because you are stating your belief rather than >specific detail of an instance where it doesn't work. Lots of people >hold the belief it won't work, but how many of those are based on a >simple resistance to think differently about the possible solution >space? sorry for poor choice of word. s/believe/think/ itojun From owner-multi6@ops.ietf.org Tue Oct 23 06:09:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24830 for ; Tue, 23 Oct 2001 06:09:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15vyRN-0000uG-00 for multi6-data@psg.com; Tue, 23 Oct 2001 03:05:45 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15vyRM-0000uA-00 for multi6@ops.ietf.org; Tue, 23 Oct 2001 03:05:44 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f9NA77C57719; Tue, 23 Oct 2001 12:07:08 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 23 Oct 2001 12:07:07 +0200 (CEST) From: Iljitsch van Beijnum To: Tony Hain cc: Subject: RE: Provider Independent addressing format drafts In-Reply-To: Message-ID: <20011023114941.C48828-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 22 Oct 2001, Tony Hain wrote: > Lots of people > hold the belief it won't work, but how many of those are based on a > simple resistance to think differently about the possible solution > space? Ok, so it can work. But does it have any real advantages? I don't see them. If we want geo addressing, why not apply some brain power and come up with something that works better. The problem with a direct translation between location and address is that there are locations that need very few addresses and there are locations that need very many. Also, the boundaries will be in impractical places. For instance, half of London is in the western hemisphere, the other half in the eastern hemisphere. So should there be a LINX East and a LINX West then? Doing the translation by hand means you can give areas the number of addresses they need and you can have the boundaries where they should be: where the interconnection is sparse (ie North Sea and not one of the busiest cities of Europe). On the other hand: direct mapping between addresses and locations could be _very_ interesting if we had geo routing. For instance, a satellite or UMTS base station could decide which antenna to use to transmit a packet based on the address. But this doesn't seem to be happening. I still believe is some form of geo addressing, but it has one huge disadvantage: you need to be fully interconnected within the region. With current multihoming, two networks could lose all their interconnects in (for instance) the US and there would still be some level of reachability through interconnects in other parts of the world. With geo addressing, this isn't possible. I'm starting to think we should give large address blocks to commercial organizations who will then negotiate what kind of announcements will be accepted within that block. This way, someone who wants their /24 (v4) or /48 (v6) in the DMZ can do this by paying a large sum of money to one of these address brokers, who will make sure it happens by paying the networks to accept them. Obviously, this will not stop the routing table growth but at least it will introduce the laws of supply and demand so those who supply can buy bigger routers with the money from those who demand. From owner-multi6@ops.ietf.org Tue Oct 23 08:04:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27610 for ; Tue, 23 Oct 2001 08:04:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15w0GC-0003rr-00 for multi6-data@psg.com; Tue, 23 Oct 2001 05:02:20 -0700 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.33 #1) id 15w0GB-0003rl-00 for multi6@ops.ietf.org; Tue, 23 Oct 2001 05:02:20 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA02482; Tue, 23 Oct 2001 06:01:50 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f9NC2Dq27137; Tue, 23 Oct 2001 14:02:13 +0200 (MET DST) Date: Tue, 23 Oct 2001 13:56:39 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: (ngtrans) Update to Provider Independent addressing format drafts To: Keith Moore Cc: Michel Py , Tony Hain , multi6@ops.ietf.org, nanog@merit.edu, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, tech@ipv6forum.com, ipv6-directorate@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200110230320.f9N3K3P00698@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk > > Large corporations that have (with or without a valid > > reason) a tendency to geographically relocate would have to re-number. > > if you're doing a massive relocation in physical space, the renumbering > of your IP network doesn't seem like a huge additional burden. The physical relocation might me relatively minor. For instance, large corporations might choose to define one place (e.g. one building on one of many campuses) as the coordinates as the single place that defines the IP address prefix for the whole company yet that building might house much less than 1% of the company's IP devices and people. This means that giving up the lease on that single building will cause all IP devices to renumber yet the costs due to the physical relocation are small. Erik From owner-multi6@ops.ietf.org Tue Oct 23 17:07:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20249 for ; Tue, 23 Oct 2001 17:07:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15w8gs-000Jr5-00 for multi6-data@psg.com; Tue, 23 Oct 2001 14:02:26 -0700 Received: from evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net ([4.60.69.141] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.33 #1) id 15w8gq-000Jqz-00 for multi6@ops.ietf.org; Tue, 23 Oct 2001 14:02:24 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Tue, 23 Oct 2001 14:02:20 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 6D5DF7DC3EF64A339797477113E7688C for plus 1 more; Tue, 23 Oct 2001 14:02:19 -0700 From: "Tony Hain" To: "Iljitsch van Beijnum" Cc: Subject: RE: Provider Independent addressing format drafts Date: Tue, 23 Oct 2001 14:01:14 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <20011023114941.C48828-100000@sequoia.muada.com> X-SLUIDL: 8B14CD8F-BE3F43FD-8CE9C82B-80A166F9 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > Ok, so it can work. But does it have any real advantages? I don't see > them. If we want geo addressing, why not apply some brain > power and come > up with something that works better. I have no problem with yielding to a better approach, but so far I haven't seen one that addresses anything more than the service provider technical perspective. This is a multi-facetted problem space, and we need a broad perspective approach. > The problem with a > direct translation > between location and address is that there are locations that > need very > few addresses and there are locations that need very many. This is only a problem if one tries to absolutely optimize the allocation to the need. As long as those with a large requirement can get what they need, there is no problem. One of the things that keeps coming up when I talk to site network managers is the fact that a single /48 is functionally equivalent to a /8 in IPv4. There are very few organizations that need more than a single /8 today, so one could extrapolate that very few organizations will need multiple /48's anytime soon. > Also, the > boundaries will be in impractical places. For instance, half > of London is > in the western hemisphere, the other half in the eastern > hemisphere. So > should there be a LINX East and a LINX West then? If one chose to implement it that way, yes that might happen. The point is both prefixes would be exchanged at the current LINX until growth caused that to be inadaquate. There is no reason to make this harder than it needs to be. > On the other hand: direct mapping between addresses and > locations could be > _very_ interesting if we had geo routing. For instance, a satellite or > UMTS base station could decide which antenna to use to > transmit a packet > based on the address. But this doesn't seem to be happening. Is this a chicken and egg problem? We don't currently have a decent mapping that would allow a satellite operator to build a service like this, so is lack of service simply a function of lack of an address model? > I still believe is some form of geo addressing, but it has one huge > disadvantage: you need to be fully interconnected within the > region. Only for those who are not expressing an explicit policy to the DFZ (ie: the ones who really don't need to be known outside the region anyway). The sites that are looking for explicit policy will show up in the DFZ no matter what we do. > With > current multihoming, two networks could lose all their > interconnects in > (for instance) the US and there would still be some level of > reachability > through interconnects in other parts of the world. With geo > addressing, > this isn't possible. Why? You appear to be assuming that there is magic around one of these prefixes which would prevent it from being announced via an alternate path. I would argue that these prefixes would recover automatically where the alternate announcements for PA space would require manual intervention. > I'm starting to think we should give large address blocks to > commercial > organizations who will then negotiate what kind of > announcements will be > accepted within that block. This way, someone who wants their > /24 (v4) or > /48 (v6) in the DMZ can do this by paying a large sum of > money to one of > these address brokers, who will make sure it happens by paying the > networks to accept them. Obviously, this will not stop the > routing table > growth but at least it will introduce the laws of supply and demand so > those who supply can buy bigger routers with the money from those who > demand. To a large degree allocating large blocks is what this proposal is about. The current rules for PA space need to persist intact if there is to be any structure. If we don't hold the line on the current rules, we are simply recreating the IPv4 mess (which people are comfortable with so they seem to like that level of pain). So this means we need an alternate space which is provider independent to work with, and it needs some level of structure to scale globally. One way to implement your suggestion would be to have the registries act as the brokers, and have the explicit value item be the AS number rather than any specific prefix. If any organization wants to have an independent origin AS in the DFZ money would flow. The number of prefixes a single AS could be origin for could be self regulated through financial feedback, or I was suggesting we set a hard limit which would cap table growth at a small multiple of AS growth. I really don't care, and maybe it gets implemented as one price for up to N prefixes, then a significantly higher rate for each one over N. Tony From owner-multi6@ops.ietf.org Wed Oct 24 12:31:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05525 for ; Wed, 24 Oct 2001 12:31:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15wQsp-000DiJ-00 for multi6-data@psg.com; Wed, 24 Oct 2001 09:27:59 -0700 Received: from heffalump.fnal.gov ([131.225.9.20] helo=fnal.gov) by psg.com with esmtp (Exim 3.33 #1) id 15wQso-000DiD-00 for multi6@ops.ietf.org; Wed, 24 Oct 2001 09:27:58 -0700 Received: from gungnir.fnal.gov ([131.225.80.1]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0GLP000H8XQLBL@smtp.fnal.gov> for multi6@ops.ietf.org; Wed, 24 Oct 2001 11:27:57 -0500 (CDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.10.2+Sun/8.10.2) with ESMTP id f9OGRts09954 for ; Wed, 24 Oct 2001 11:27:55 -0500 (CDT) Date: Wed, 24 Oct 2001 11:27:55 -0500 From: Matt Crawford Subject: Re: BOUNCE multi6@ops.ietf.org: Non-member submission from [Matt Crawford ] In-reply-to: "24 Oct 2001 08:19:09 PDT." To: multi6@ops.ietf.org Reply-to: multi6@ops.ietf.org Message-id: <200110241627.f9OGRts09954@gungnir.fnal.gov> MIME-version: 1.0 Content-type: message/rfc822 Sender: owner-multi6@ops.ietf.org Precedence: bulk Return-Path: randy@psg.com Delivery-Date: Wed Oct 24 10:19:10 2001 Delivery-Date: Wed, 24 Oct 2001 10:19:10 -0500 Return-Path: randy@psg.com Received: from heffalump.fnal.gov (heffalump.fnal.gov [131.225.9.20]) by gungnir.fnal.gov (8.10.2+Sun/8.10.2) with ESMTP id f9OFJ9s10805 for ; Wed, 24 Oct 2001 10:19:10 -0500 (CDT) Received: from CONVERSION-DAEMON.smtp.fnal.gov by smtp.fnal.gov (PMDF V6.0-24 #37519) id <0GLP00L01UJY28@smtp.fnal.gov> for crawdad@gungnir.fnal.gov (ORCPT crawdad@fnal.gov); Wed, 24 Oct 2001 10:19:10 -0500 (CDT) Received: from rip.psg.com ([147.28.0.39]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0GLP007NHUJYRZ@smtp.fnal.gov> for crawdad@gungnir.fnal.gov (ORCPT crawdad@fnal.gov); Wed, 24 Oct 2001 10:19:10 -0500 (CDT) Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15wPoD-00045L-00 for crawdad@fnal.gov; Wed, 24 Oct 2001 08:19:09 -0700 Date: Wed, 24 Oct 2001 08:19:09 -0700 From: Randy Bush Subject: BOUNCE multi6@ops.ietf.org: Non-member submission from [Matt Crawford ] To: Matt Crawford Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit you must post from your subscription address randy ------- start of forwarded message ------- From: owner-multi6@ops.ietf.org To: multi6-approval@psg.com Subject: BOUNCE multi6@ops.ietf.org: Non-member submission from [Matt Crawford ] Date: Tue, 23 Oct 2001 07:31:20 -0700 >From crawdad@gungnir.fnal.gov Tue Oct 23 07:31:19 2001 Received: from heffalump.fnal.gov ([131.225.9.20] helo=fnal.gov) by psg.com with esmtp (Exim 3.33 #1) id 15w2aN-0008VW-00 for multi6@ops.ietf.org; Tue, 23 Oct 2001 07:31:19 -0700 Received: from gungnir.fnal.gov ([131.225.80.1]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0GLN0064CXO3LN@smtp.fnal.gov> for multi6@ops.ietf.org; Tue, 23 Oct 2001 09:31:15 -0500 (CDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.10.2+Sun/8.10.2) with ESMTP id f9NEVEs06712; Tue, 23 Oct 2001 09:31:14 -0500 (CDT) Date: Tue, 23 Oct 2001 09:31:13 -0500 From: Matt Crawford Subject: Re: (ngtrans) Update to Provider Independent addressing format drafts In-reply-to: "23 Oct 2001 08:33:03 EDT." <200110231233.f9NCX3P18810@astro.cs.utk.edu> Sender: crawdad@gungnir.fnal.gov To: Keith Moore Cc: multi6@ops.ietf.org, nanog@merit.edu, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, tech@ipv6forum.com, ipv6-directorate@sunroof.eng.sun.com Message-id: <200110231431.f9NEVEs06712@gungnir.fnal.gov> (Do so many lists really need to be cc'd?) > > This means that giving up the lease on that single building will cause all > > IP devices to renumber yet the costs due to the physical relocation are > > small. > > seems like a stretch. as long as the company retained some network presence > in that area it should be able to keep that prefix. It seems to me that a Wall Street prefix would not be announced by (or accepted by peers of) an upstream provider in Chicago, or perhaps even Connecticut. So traffic using the Wall Street PI prefix might actually have to be routed through some location in New York. This might be impractical. ------- end of forwarded message ------- From owner-multi6@ops.ietf.org Thu Oct 25 08:38:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16409 for ; Thu, 25 Oct 2001 08:38:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15wjiJ-000LEA-00 for multi6-data@psg.com; Thu, 25 Oct 2001 05:34:23 -0700 Received: from internet-gateway2-x.zurich.ibm.com ([195.212.119.243] helo=internet-gateway2.zurich.ibm.com) by psg.com with esmtp (Exim 3.33 #1) id 15wjiH-000LE3-00 for multi6@ops.ietf.org; Thu, 25 Oct 2001 05:34:22 -0700 Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id OAA11494; Thu, 25 Oct 2001 14:34:09 +0200 Received: from [9.29.3.174] by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA19556 from ; Thu, 25 Oct 2001 14:34:00 +0200 Message-Id: <3BD806B0.C62643D@hursley.ibm.com> Date: Thu, 25 Oct 2001 14:33:52 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Tony Li Cc: Michel Py , Keith Moore , multi6@ops.ietf.org, ngtrans@sunroof.eng.sun.com Subject: Re: (ngtrans) Update to Provider Independent addressing format drafts References: <2B81403386729140A3A899A8B39B046403AEA6@server2000.arneill-py.sacramento.ca.us> <15317.3975.754286.758350@alpha-tli.procket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tony, for several years now we have talked about making renumbering *significantly easier*, not making it fully automatic. But the proof of the pudding is in the eating, and nobody has tried that yet on any significant scale. Brian Tony Li wrote: > > I have to admit to considerable amusement to see people arguing that > renumbering in V6 is too painful. > > Tony From owner-multi6@ops.ietf.org Thu Oct 25 10:31:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20328 for ; Thu, 25 Oct 2001 10:31:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15wlUZ-000Nqi-00 for multi6-data@psg.com; Thu, 25 Oct 2001 07:28:19 -0700 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 15wlUZ-000Nqc-00 for multi6@ops.ietf.org; Thu, 25 Oct 2001 07:28:19 -0700 content-class: urn:content-classes:message Subject: RE: (ngtrans) Update to Provider Independent addressing format drafts Date: Thu, 25 Oct 2001 07:28:14 -0700 MIME-Version: 1.0 Message-ID: <2B81403386729140A3A899A8B39B046403AEBE@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Thread-Topic: (ngtrans) Update to Provider Independent addressing format drafts Thread-Index: AcFdUZADBjGgE64QRKqkGycTqohyvwADrtEA From: "Michel Py" To: "Brian E Carpenter" , "Tony Li" Cc: , Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA20328 Thank you, Brian. renumbering a two-router, three-host lab setup is one thing. Renumbering a 100-router, 300-server, 24x7 $1M/day revenue generating room is quite another one. Michel. > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Tony, for several years now we have talked about making renumbering > *significantly easier*, not making it fully automatic. > > But the proof of the pudding is in the eating, and nobody has tried > that yet on any significant scale. > > Brian >>> Tony Li wrote: >>> >>> I have to admit to considerable amusement to see people arguing that >>> renumbering in V6 is too painful. >>> >>> Tony From owner-multi6@ops.ietf.org Thu Oct 25 13:34:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24935 for ; Thu, 25 Oct 2001 13:34:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15woNs-0002to-00 for multi6-data@psg.com; Thu, 25 Oct 2001 10:33:36 -0700 Received: from evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net ([4.60.69.141] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.33 #1) id 15woNr-0002ti-00 for multi6@ops.ietf.org; Thu, 25 Oct 2001 10:33:35 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Thu, 25 Oct 2001 10:33:38 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 8839738983134B05BB57BE2209EF9E45 for ; Thu, 25 Oct 2001 10:33:38 -0700 From: "Tony Hain" To: Subject: RE: Update to Provider Independent addressing format drafts Date: Thu, 25 Oct 2001 10:33:32 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-SLUIDL: B879915D-9B7748D0-BAA37987-916D303A Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Matt Crawford wrote: > It seems to me that a Wall Street prefix would not be announced by > (or accepted by peers of) an upstream provider in Chicago, or perhaps > even Connecticut. So traffic using the Wall Street PI prefix might > actually have to be routed through some location in New York. This > might be impractical. If the prefix were to be announced at a Chicago exchange, one would presume there was a circuit from the Wall Street entity's network to that exchange. If their intent was to provide cleaner access to the Chicago area, the providers downstream from the exchange would need to decide to accept it as providing value to thier customers. If the intent was to provide an alternate access point for global use, the providers upstream from the exchange would need to decide if Chicago is where they collectively want to establish the backup for the NY exchange. If they chose DC instead, the Wall Street entity would need to understand that, and realize the Chicago announcement would be for the local region only. Tony From owner-multi6@ops.ietf.org Thu Oct 25 18:52:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01632 for ; Thu, 25 Oct 2001 18:52:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15wtIl-000BXI-00 for multi6-data@psg.com; Thu, 25 Oct 2001 15:48:39 -0700 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.33 #1) id 15wtIk-000BX9-00 for multi6@ops.ietf.org; Thu, 25 Oct 2001 15:48:38 -0700 Received: from hawk.ecs.soton.ac.uk (hawk.ecs.soton.ac.uk [152.78.68.142]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id XAA21686; Thu, 25 Oct 2001 23:49:32 +0100 (BST) Received: from penelope (penelope.ecs.soton.ac.uk [152.78.68.135]) by hawk.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id XAA20059; Thu, 25 Oct 2001 23:48:34 +0100 (BST) Date: Thu, 25 Oct 2001 23:48:35 +0100 (BST) From: Tim Chown To: Keith Moore cc: multi6@ops.ietf.org Subject: Re: (ngtrans) Update to Provider Independent addressing format drafts In-Reply-To: <200110251501.f9PF1AP17437@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 25 Oct 2001, Keith Moore wrote: > > Renumbering a 100-router, 300-server, 24x7 $1M/day revenue generating > > room is quite another one. > > I've been involved with renumbering of ~300 IPv4 machines of widely varying > platforms, in less than an hour, on multiple occasions. It took prior > planning, a bit of coding, and a mechanism for quickly finding the machines > on which the renumbering failed. But it wasn't rocket science. > If we had standard tools to do this it would be even easier. Hi Keith, Is that 300 servers, or mostly clients? If you have a few hundred, or thousands of domains with (virtual or otherwise) mail, web and other (perhaps black box) services hosted then while I agree the renumbering isn't rocket science, it's not much fun logistically. There's domain registrations to update, firewalls to change, a fair few Windows applications which insist on IP numbers being keyed in manually, smooth mail transitions, updates on other people's references to your IPs, and plenty of places where IPs are hard coded on Unix systems. I agree prior planning is key, but to suggest most sites can press a button and have it done in an hour seems optimistic :-) At present operators such as Worldcom have smaller enterprises over a barrel for bandwidth charges. As bandwidth costs fall, and you see rival operators prices looking far more attractive, perhaps up to 50% less, it's not a no brainer to move operator because you have to renumber, and your current operator knows that, and can keep their fees higher for you regardless. If IPv6 were able to offer less painful renumbering (which will need help from the likes of Checkpoint and Microsoft), or we had some non-NAT form of provider-independent addressing, great. But as it is, smaller enterprises who don't have leverage to take address blocks with them suffer when seeking competitive bandwidth rates. With NAT perceived as the "easy" form of provider independent addressing, I'm not convinced we won't see IPv6 NAT. tim From owner-multi6@ops.ietf.org Thu Oct 25 19:39:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02267 for ; Thu, 25 Oct 2001 19:39:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15wu4u-000D2C-00 for multi6-data@psg.com; Thu, 25 Oct 2001 16:38:24 -0700 Received: from miata.procket.com ([209.140.237.2]) by psg.com with esmtp (Exim 3.33 #1) id 15wu4t-000D24-00 for multi6@ops.ietf.org; Thu, 25 Oct 2001 16:38:23 -0700 Received: from alpha-tli.procket.com (IDENT:root@alpha-tli.procket.com [10.2.3.1]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id f9PNcBCD025576; Thu, 25 Oct 2001 16:38:11 -0700 (PDT) Received: (from tli@localhost) by alpha-tli.procket.com (8.12.1/8.12.1) id f9PNc9mk025106; Thu, 25 Oct 2001 16:38:09 -0700 From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15320.41569.475155.36856@alpha-tli.procket.com> Date: Thu, 25 Oct 2001 16:38:09 -0700 To: Brian E Carpenter Cc: Tony Li , Michel Py , Keith Moore , multi6@ops.ietf.org, ngtrans@sunroof.eng.sun.com Subject: Re: (ngtrans) Update to Provider Independent addressing format drafts In-Reply-To: <3BD806B0.C62643D@hursley.ibm.com> References: <2B81403386729140A3A899A8B39B046403AEA6@server2000.arneill-py.sacramento.ca.us> <15317.3975.754286.758350@alpha-tli.procket.com> <3BD806B0.C62643D@hursley.ibm.com> X-Mailer: VM 6.92 under Emacs 20.5.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Sounds like we're not willing to eat what we cooked. Tony Brian E Carpenter writes: | Tony, for several years now we have talked about making renumbering | *significantly easier*, not making it fully automatic. | | But the proof of the pudding is in the eating, and nobody has tried | that yet on any significant scale. | | Brian | | Tony Li wrote: | > | > I have to admit to considerable amusement to see people arguing that | > renumbering in V6 is too painful. | > | > Tony From owner-multi6@ops.ietf.org Thu Oct 25 21:01:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03985 for ; Thu, 25 Oct 2001 21:01:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15wvK7-000FSv-00 for multi6-data@psg.com; Thu, 25 Oct 2001 17:58:11 -0700 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 15wvK6-000FSp-00 for multi6@ops.ietf.org; Thu, 25 Oct 2001 17:58:10 -0700 content-class: urn:content-classes:message Subject: RE: (ngtrans) Update to Provider Independent addressing format drafts Date: Thu, 25 Oct 2001 17:58:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046403AEC3@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Thread-Topic: (ngtrans) Update to Provider Independent addressing format drafts Thread-Index: AcFdquxrz/oZcKjeSMKB0HcngorIxwADEDBA From: "Michel Py" To: "Tim Chown" , "Keith Moore" Cc: Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA03985 I could not agree more with Tim. Add to the picture that Tim painted connections with dozens of customers, providers or partners, all of them having BGP peers, static routes and access-lists on their routers referring to the block to be renumbered, and you make renumbering almost impossible because you have to coordinate it with a score of third party companies that might have other priorities than adapting their own setup because one needs to renumber. Michel. -----Original Message----- From: Tim Chown [mailto:tjc@ecs.soton.ac.uk] Sent: Thursday, October 25, 2001 3:49 PM To: Keith Moore Cc: multi6@ops.ietf.org Subject: Re: (ngtrans) Update to Provider Independent addressing format drafts On Thu, 25 Oct 2001, Keith Moore wrote: > > Renumbering a 100-router, 300-server, 24x7 $1M/day revenue generating > > room is quite another one. > > I've been involved with renumbering of ~300 IPv4 machines of widely varying > platforms, in less than an hour, on multiple occasions. It took prior > planning, a bit of coding, and a mechanism for quickly finding the machines > on which the renumbering failed. But it wasn't rocket science. > If we had standard tools to do this it would be even easier. Hi Keith, Is that 300 servers, or mostly clients? If you have a few hundred, or thousands of domains with (virtual or otherwise) mail, web and other (perhaps black box) services hosted then while I agree the renumbering isn't rocket science, it's not much fun logistically. There's domain registrations to update, firewalls to change, a fair few Windows applications which insist on IP numbers being keyed in manually, smooth mail transitions, updates on other people's references to your IPs, and plenty of places where IPs are hard coded on Unix systems. I agree prior planning is key, but to suggest most sites can press a button and have it done in an hour seems optimistic :-) At present operators such as Worldcom have smaller enterprises over a barrel for bandwidth charges. As bandwidth costs fall, and you see rival operators prices looking far more attractive, perhaps up to 50% less, it's not a no brainer to move operator because you have to renumber, and your current operator knows that, and can keep their fees higher for you regardless. If IPv6 were able to offer less painful renumbering (which will need help from the likes of Checkpoint and Microsoft), or we had some non-NAT form of provider-independent addressing, great. But as it is, smaller enterprises who don't have leverage to take address blocks with them suffer when seeking competitive bandwidth rates. With NAT perceived as the "easy" form of provider independent addressing, I'm not convinced we won't see IPv6 NAT. tim From owner-multi6@ops.ietf.org Fri Oct 26 03:29:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24996 for ; Fri, 26 Oct 2001 03:29:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15x1MX-000Prs-00 for multi6-data@psg.com; Fri, 26 Oct 2001 00:25:05 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15x1MW-000Pri-00 for multi6@ops.ietf.org; Fri, 26 Oct 2001 00:25:04 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f9Q7QHB62895; Fri, 26 Oct 2001 09:26:17 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 26 Oct 2001 09:26:17 +0200 (CEST) From: Iljitsch van Beijnum To: Michel Py cc: Tim Chown , Keith Moore , Subject: RE: (ngtrans) Update to Provider Independent addressing format drafts In-Reply-To: <2B81403386729140A3A899A8B39B046403AEC3@server2000.arneill-py.sacramento.ca.us> Message-ID: <20011026091538.C59709-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 25 Oct 2001, Michel Py wrote: > I could not agree more with Tim. Add to the picture that Tim painted > connections with dozens of customers, providers or partners, all of them > having BGP peers, static routes and access-lists on their routers > referring to the block to be renumbered, and you make renumbering almost > impossible because you have to coordinate it with a score of third party > companies that might have other priorities than adapting their own setup > because one needs to renumber. I disagree. I have personally renumbered two relatively small ISPs (including customers!) a total of three times. That would be 5 - 20 routers and 10 - 40 servers. When compared to a lazy afternoon of doing nothing, renumbering is a lot of work. When compared to the routine maintanance that happens anyway over a period of several months, the added trouble of renumbering is fairly negligible. BTW: changing domains isn't much of a problem: just register a new address for your name server. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Fri Oct 26 08:26:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00160 for ; Fri, 26 Oct 2001 08:26:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15x61L-00054e-00 for multi6-data@psg.com; Fri, 26 Oct 2001 05:23:31 -0700 Received: from internet-gateway2-x.zurich.ibm.com ([195.212.119.243] helo=internet-gateway2.zurich.ibm.com) by psg.com with esmtp (Exim 3.33 #1) id 15x61K-00054X-00 for multi6@ops.ietf.org; Fri, 26 Oct 2001 05:23:31 -0700 Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id OAA12424; Fri, 26 Oct 2001 14:23:25 +0200 Received: from dhcp23-95.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA75044 from ; Fri, 26 Oct 2001 14:23:24 +0200 Message-Id: <3BD95516.8C201A30@hursley.ibm.com> Date: Fri, 26 Oct 2001 14:20:38 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Michel Py Cc: Tim Chown , Keith Moore , multi6@ops.ietf.org Subject: Re: (ngtrans) Update to Provider Independent addressing format drafts References: <2B81403386729140A3A899A8B39B046403AEC3@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Remember that v6 renumbering can include a period of overlap between the old and new prefixes, when both will work and neither of them is deprecated. For a large site with the kind of issues you describe, I would expect this overlap to be quite long - at least a month, why not longer? This will greatly simplify the coordination problem. In fact, a single homed site changing to a new provider would become multihomed during the overlap period; and an n-homed site would become (n+1)-homed during the overlap period. A good multi6 solution *is* a renumbering mechanism. Brian Michel Py wrote: > > I could not agree more with Tim. Add to the picture that Tim painted > connections with dozens of customers, providers or partners, all of them > having BGP peers, static routes and access-lists on their routers > referring to the block to be renumbered, and you make renumbering almost > impossible because you have to coordinate it with a score of third party > companies that might have other priorities than adapting their own setup > because one needs to renumber. > > Michel. > > -----Original Message----- > From: Tim Chown [mailto:tjc@ecs.soton.ac.uk] > Sent: Thursday, October 25, 2001 3:49 PM > To: Keith Moore > Cc: multi6@ops.ietf.org > Subject: Re: (ngtrans) Update to Provider Independent addressing format > drafts > > On Thu, 25 Oct 2001, Keith Moore wrote: > > > > Renumbering a 100-router, 300-server, 24x7 $1M/day revenue > generating > > > room is quite another one. > > > > I've been involved with renumbering of ~300 IPv4 machines of widely > varying > > platforms, in less than an hour, on multiple occasions. It took > prior > > planning, a bit of coding, and a mechanism for quickly finding the > machines > > on which the renumbering failed. But it wasn't rocket science. > > If we had standard tools to do this it would be even easier. > > Hi Keith, > > Is that 300 servers, or mostly clients? If you have a few hundred, or > thousands of domains with (virtual or otherwise) mail, web and other > (perhaps black box) services hosted then while I agree the renumbering > isn't rocket science, it's not much fun logistically. There's domain > registrations to update, firewalls to change, a fair few Windows > applications which insist on IP numbers being keyed in manually, smooth > mail transitions, updates on other people's references to your IPs, > and plenty of places where IPs are hard coded on Unix systems. I agree > prior planning is key, but to suggest most sites can press a button > and have it done in an hour seems optimistic :-) > > At present operators such as Worldcom have smaller enterprises over a > barrel for bandwidth charges. As bandwidth costs fall, and you see > rival > operators prices looking far more attractive, perhaps up to 50% less, > it's not a no brainer to move operator because you have to renumber, > and your current operator knows that, and can keep their fees higher for > you regardless. If IPv6 were able to offer less painful renumbering > (which will need help from the likes of Checkpoint and Microsoft), or > we had some non-NAT form of provider-independent addressing, great. But > as it is, smaller enterprises who don't have leverage to take address > blocks with them suffer when seeking competitive bandwidth rates. With > NAT perceived as the "easy" form of provider independent addressing, I'm > not convinced we won't see IPv6 NAT. > > tim From owner-multi6@ops.ietf.org Fri Oct 26 10:48:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05760 for ; Fri, 26 Oct 2001 10:48:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15x8FV-0008pf-00 for multi6-data@psg.com; Fri, 26 Oct 2001 07:46:17 -0700 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 15x8FV-0008pU-00 for multi6@ops.ietf.org; Fri, 26 Oct 2001 07:46:17 -0700 Subject: (multi6) Ease of re-numbering Date: Fri, 26 Oct 2001 07:46:07 -0700 Message-ID: <2B81403386729140A3A899A8B39B046403AEC5@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: (ngtrans) Update to Provider Independent addressing format drafts Thread-Index: AcFd732vVW0sKg7YS7y8evDFJsb6IwAOz53Q X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message From: "Michel Py" To: "Iljitsch van Beijnum" , "Brian E Carpenter" Cc: "Tim Chown" , "Keith Moore" , Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA05760 Iljitsch and Brian-- You are both right, but the point that Tim and I are trying to make is that the pain of renumbering is not reachability (and to that regard IPv6 will be easier) but all the associated host, server and security configuration. In Iljitsch's example, the small ISP does not provide much services, let's say connectivity, pop/smtp mail and news. These are not a big deal (besides, the size and geographical location would still be manageable). What I have to deal with is dozens of frame-relay and point-to-point circuits to third-party entities including high-inertia ones such as governments, in several time zones. We don't provide connectivity to these guys, we provide services. Like it or not, there are still people that configure batch files based on IP address, static entries in the lmhosts files, that kind of stuff. And all of these guys have access-lists all over the place, and so do we. Even in a dream world where people would actually use DNS and quit configuring static routes, access-lists and firewall holes are still based on IP and renumbering a large setup is NOT an afternoon. Michel. From: Brian E. Carpenter Remember that v6 renumbering can include a period of overlap between the old and new prefixes, when both will work and neither of them is deprecated. For a large site with the kind of issues you describe, I would expect this overlap to be quite long - at least a month, why not longer? This will greatly simplify the coordination problem. In fact, a single homed site changing to a new provider would become multihomed during the overlap period; and an n-homed site would become (n+1)-homed during the overlap period. A good multi6 solution *is* a renumbering mechanism. Brian From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] I disagree. I have personally renumbered two relatively small ISPs (including customers!) a total of three times. That would be 5 - 20 routers and 10 - 40 servers. When compared to a lazy afternoon of doing nothing, renumbering is a lot of work. When compared to the routine maintanance that happens anyway over a period of several months, the added trouble of renumbering is fairly negligible. BTW: changing domains isn't much of a problem: just register a new address for your name server. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Mon Oct 29 02:42:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06836 for ; Mon, 29 Oct 2001 02:42:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15y705-000Kqw-00 for multi6-data@psg.com; Sun, 28 Oct 2001 23:38:25 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.33 #1) id 15y703-000Kqp-00 for multi6@ops.ietf.org; Sun, 28 Oct 2001 23:38:24 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f9T7bo328112; Mon, 29 Oct 2001 09:37:50 +0200 Date: Mon, 29 Oct 2001 09:37:50 +0200 (EET) From: Pekka Savola To: Dancer Vesperman cc: Keith Moore , Michel Py , Brian E Carpenter , Tony Li , , Subject: Re: (ngtrans) Update to Provider Independent addressing format drafts In-Reply-To: <3BDCF306.9030403@zeor.simegen.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 29 Oct 2001, Dancer Vesperman wrote: > Keith Moore wrote: > > >>Renumbering a 100-router, 300-server, 24x7 $1M/day revenue generating > >>room is quite another one. > >> > > > > I've been involved with renumbering of ~300 IPv4 machines of widely varying > > platforms, in less than an hour, on multiple occasions. It took prior > > planning, a bit of coding, and a mechanism for quickly finding the machines > > on which the renumbering failed. But it wasn't rocket science. > > > > If we had standard tools to do this it would be even easier. > > > > Keith > > > > > > Agree. Unless your IT-plan is one of those organic messes, it's no > biggie. A couple of minutes per machine usually suffices, with some > slightly longer times where there are spaghetti systems installed. It > certainly takes less time than the network vendor trying to figure out > why their system isn't working, in my experience. Renumbering is MUCH more than just changing addresses in _your_ systems. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-multi6@ops.ietf.org Mon Oct 29 04:52:17 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08002 for ; Mon, 29 Oct 2001 04:52:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15y93o-000Oa2-00 for multi6-data@psg.com; Mon, 29 Oct 2001 01:50:24 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15y93n-000OZv-00 for multi6@ops.ietf.org; Mon, 29 Oct 2001 01:50:23 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f9T9pWD70448; Mon, 29 Oct 2001 10:51:33 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Mon, 29 Oct 2001 10:51:32 +0100 (CET) From: Iljitsch van Beijnum To: Michel Py cc: Subject: Re: (multi6) Ease of re-numbering In-Reply-To: <2B81403386729140A3A899A8B39B046403AEC5@server2000.arneill-py.sacramento.ca.us> Message-ID: <20011029103122.T59709-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 26 Oct 2001, Michel Py wrote: > You are both right, but the point that Tim and I are trying to make is > that the pain of renumbering is not reachability (and to that regard > IPv6 will be easier) but all the associated host, server and security > configuration. Agree. So the people who make host, server and security products have their work cut out for them. > What I have to deal with is dozens of frame-relay and point-to-point > circuits to third-party entities including high-inertia ones such as > governments, in several time zones. We don't provide connectivity to > these guys, we provide services. Like it or not, there are still people > that configure batch files based on IP address, static entries in the > lmhosts files, that kind of stuff. In my experience, the willingness to renumber has little to do with the amount of work involved. I've seen massive organizations (not of the scale you're talking about, but still very big for a single timezone) with many hard to renumber items renumber without complaints, and fairly small organizations with simple setups refuse to do so and keep their B block even if they didn't even need a full /24. But my real point is that renumbering is not a big deal compared to maintanance work that has to be carried out anyway: > And all of these guys have > access-lists all over the place, and so do we. And every time you get something new, these access lists have to change. I used to work for the largest ISP here in The Netherlands, and we pretty much had to change three access lists on all BGP speaking routers two or three times a week. > Even in a dream world > where people would actually use DNS and quit configuring static routes, > access-lists and firewall holes are still based on IP and renumbering a > large setup is NOT an afternoon. An afternoon is not a useful timeframe for renumbering. Either it has to be done much quicker (30 seconds or so) or you can take much longer, up to at least a month. Is there no way we can come up with a way where hosts can keep their IPv4 address and happily run IPv4, where the other 96 bits are "automagically" added and removed by a border router? That way, I can forever go on using 213.156.3.172, even if I have to renumber daily from 3ffe:1234:x::213.156.3.172 to 3ffe:1234:y::213.156.3.172 and so on. It should be easy enough to do this for the local address, the only problem is where to find the 96 missing bits of the remote address. Iljitsch From owner-multi6@ops.ietf.org Mon Oct 29 15:38:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26225 for ; Mon, 29 Oct 2001 15:38:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15yJ84-000FI4-00 for multi6-data@psg.com; Mon, 29 Oct 2001 12:35:28 -0800 Received: from [216.243.33.138] (helo=roxanne.org) by psg.com with esmtp (Exim 3.33 #1) id 15yJ83-000FHx-00 for multi6@ops.ietf.org; Mon, 29 Oct 2001 12:35:27 -0800 Received: (from eric@localhost) by roxanne.org (8.11.0/8.11.0) id f9TKZHK10748 for multi6@ops.ietf.org; Mon, 29 Oct 2001 15:35:17 -0500 Date: Mon, 29 Oct 2001 15:35:17 -0500 From: Eric Gauthier To: multi6@ops.ietf.org Subject: Re: (multi6) Ease of re-numbering Message-ID: <20011029153517.G10316@roxanne.org> References: <2B81403386729140A3A899A8B39B046403AEC5@server2000.arneill-py.sacramento.ca.us> <20011029103122.T59709-100000@sequoia.muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011029103122.T59709-100000@sequoia.muada.com>; from iljitsch@muada.com on Mon, Oct 29, 2001 at 10:51:32AM +0100 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Is there no way we can come up with a way where hosts can keep their IPv4 > address and happily run IPv4, where the other 96 bits are "automagically" > added and removed by a border router? That way, I can forever go on using > 213.156.3.172, even if I have to renumber daily from > 3ffe:1234:x::213.156.3.172 to 3ffe:1234:y::213.156.3.172 and so on. > > It should be easy enough to do this for the local address, the only > problem is where to find the 96 missing bits of the remote address. My impression was that a system could request whatever it wanted to as the end 64bits of its address and that it 'usually' chose its MAC. If that's the case, your system could chose 32-bits of zeros and then the 32bit combination that corresponds to your IP... Then, the normal renumbering rules would apply? Eric :) From owner-multi6@ops.ietf.org Tue Oct 30 03:35:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22667 for ; Tue, 30 Oct 2001 03:34:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15yUIa-0009Hf-00 for multi6-data@psg.com; Tue, 30 Oct 2001 00:31:04 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15yUIZ-0009HZ-00 for multi6@ops.ietf.org; Tue, 30 Oct 2001 00:31:03 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f9U8TEg72167; Tue, 30 Oct 2001 09:29:19 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Tue, 30 Oct 2001 09:29:14 +0100 (CET) From: Iljitsch van Beijnum To: Eric Gauthier cc: Subject: Re: (multi6) Ease of re-numbering In-Reply-To: <20011029153517.G10316@roxanne.org> Message-ID: <20011030092245.N59709-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 29 Oct 2001, Eric Gauthier wrote: > > Is there no way we can come up with a way where hosts can keep their IPv4 > > address and happily run IPv4, where the other 96 bits are "automagically" > > added and removed by a border router? That way, I can forever go on using > > 213.156.3.172, even if I have to renumber daily from > > 3ffe:1234:x::213.156.3.172 to 3ffe:1234:y::213.156.3.172 and so on. > My impression was that a system could request whatever it wanted to > as the end 64bits of its address and that it 'usually' chose its > MAC. If that's the case, your system could chose 32-bits of zeros > and then the 32bit combination that corresponds to your IP... Then, > the normal renumbering rules would apply? What I want is for the host to use just the 32 bit IPv4 addresses. (The host then wouldn't even have to run IPv6.) So 1.2.3.4 sends a packet to 5.6.7.8 and a border router would turn that into a packet from 3ffe:ab::1.2.3.4 to 3ffe:cd::5.6.7.8. This way, only the border routers need to know the IPv6 prefixes and internal hosts can happily run IPv4 or IPv6 with IPv4 addresses without ever having to renumber. From owner-multi6@ops.ietf.org Tue Oct 30 05:22:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23829 for ; Tue, 30 Oct 2001 05:22:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15yW0D-000ChJ-00 for multi6-data@psg.com; Tue, 30 Oct 2001 02:20:13 -0800 Received: from internet-gateway2-x.zurich.ibm.com ([195.212.119.243] helo=internet-gateway2.zurich.ibm.com) by psg.com with esmtp (Exim 3.33 #1) id 15yW0C-000ChC-00 for multi6@ops.ietf.org; Tue, 30 Oct 2001 02:20:12 -0800 Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id LAA04008; Tue, 30 Oct 2001 11:20:00 +0100 Received: from dhcp23-95.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA52398 from ; Tue, 30 Oct 2001 11:19:54 +0100 Message-Id: <3BDE7DB9.532475EC@hursley.ibm.com> Date: Tue, 30 Oct 2001 11:15:21 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Iljitsch van Beijnum Cc: Eric Gauthier , multi6@ops.ietf.org Subject: Re: (multi6) Ease of re-numbering References: <20011030092245.N59709-100000@sequoia.muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: ... > What I want is for the host to use just the 32 bit IPv4 addresses. (The > host then wouldn't even have to run IPv6.) So 1.2.3.4 sends a packet to > 5.6.7.8 and a border router would turn that into a packet from > 3ffe:ab::1.2.3.4 to 3ffe:cd::5.6.7.8. This way, only the border routers > need to know the IPv6 prefixes and internal hosts can happily run IPv4 or > IPv6 with IPv4 addresses without ever having to renumber. Er, that can only work within a site; since we have run out of IPv4 addresses, it can't cross the Internet in the general case. The general case requires NAT-PT, and anyway you have not given the legacy hosts any benefit from IPv6. Brian