From owner-multi6@ops.ietf.org Thu May 1 00:14:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06367 for ; Thu, 1 May 2003 00:14:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19B50n-000PJF-00 for multi6-data@psg.com; Thu, 01 May 2003 03:45:33 +0000 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 19B50i-000PIr-00 for multi6@ops.ietf.org; Thu, 01 May 2003 03:45:28 +0000 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 9ED50137F04; Wed, 30 Apr 2003 20:45:24 -0700 (PDT) Date: Wed, 30 Apr 2003 20:45:21 -0700 Subject: Re: old GSE idea Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Multi6 Working Group To: Iljitsch van Beijnum From: David Conrad In-Reply-To: Message-Id: <55A8EDEC-7B87-11D7-B0B2-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Going back through some old unanswered (sorry 'bout that) email... On Thursday, April 17, 2003, at 04:59 AM, Iljitsch van Beijnum wrote: >>>> I think the simplest solution is to make the lower 64 bits globally >>>> unique. >>> This breaks autoconfiguration. > MAC address collisions are not uncommon. ... > The problem is that on a LAN, you can do DAD, but doing that world > wide each time you connect to the network is no fun. Understood. Seems to me this is one of the tradeoffs. Globally unique identifiers in the lower 64 bits allows for a very simple mapping mechanism to map that identifier into one or more locators giving you both site and host multi- and re-homing. If you cannot guarantee global uniqueness of those identifiers, then to get the same functionality, you increase the complexity of the mapping mechanism. >> Why put location back into identity? In my view, endpoint >> identifiers are 'names'. They are a flat, undifferentiated (from the >> network perspective, administratively, you may want some hierarchy) >> identifier space. > This is going to be a problem if you want to look these up in a > distributed database. We really need a hierarchy for something like > this. I do not disagree that you want hierarchy. What I am saying is that you do not want is to tie that hierarchy into network topology such that if the object changes its location in the network topology, you must change the identifier. You want an administrative hierarchy disjoint from network topology. >> Assuming you are asking about the multi-homed destination case,the >> naive approach would be to have the source core/edge boundary >> forwarder notice the link is down via 'traditional' methods (BGP >> re-convergence, ICMP network unreachable, whatever) > Obviously this stuff isn't going to be in BGP. :-) Yes it can. A locator, if we want them to scale, is part of an aggregate. If an aggregate is withdrawn, a boundary forwarder listening (but not contributing) to a BGP feed could then choose an alternate locator. > A large percentage of network problems don't generate unreachables. For those problems a router doesn't notice, you pretty much lose, regardless of approach taken, unless you add the complexity of pseudo-connection management or somesuch. For those problems a router does notice, it should back send unreachables. > If an attacker gets to reroute your traffic, then they presumably also > get to route in into oblivion. So IPsec doesn't solve problems in the > routing system. Right. Placing control of a router in the hands of an attacker is generally a bad idea. > This helps but doesn't really solve the problem of dead layer 2 > networks where the IP-speaking boxes at both ends don't see there is > something wrong. There are many Byzantine failure modes that are difficult to create solutions for. I'm of the opinion (actually more than that, I believe we have empirical evidence) that if we try to solve all the problems we'll get nowhere. > What I mean is that you need to implement GSE on both ends before it > will do you any good. Yes. This is, I believe, a fundamental issue that is caused by the layering violations created by letting applications (et al) know address bit structures. As far as I can tell, there are exactly two solutions to this: 1) NAT, which doesn't need to be at both ends 2) map on transmit, remap back to original on receive, which needs to be on both ends. I'd be ecstatic to hear of alternative solutions. > I think hooks forward are possible by not hardcoding the exact 83 bits > we look at into the modified stacks but by making this more generic so > we can support 160 bits or 64 bits out of 128 or whatever at some > later date. Yet more complexity. > I'm not saying we should implement huge steps, but it would be good if > the small steps we implement get us closer to a long term goal. We have been struggling with this issue for about a decade. I think it is past time to start with a simple solution instead of trying to find the generic, infinitely extensible, end-all be-all solution. Rgds, -drc From owner-multi6@ops.ietf.org Thu May 1 00:20:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06407 for ; Thu, 1 May 2003 00:20:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19B5ao-0001Li-00 for multi6-data@psg.com; Thu, 01 May 2003 04:22:46 +0000 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 19B5al-0001LQ-00 for multi6@ops.ietf.org; Thu, 01 May 2003 04:22:43 +0000 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 85E24137F04; Wed, 30 Apr 2003 21:22:27 -0700 (PDT) Date: Wed, 30 Apr 2003 21:22:21 -0700 Subject: Re: old GSE idea Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Iljitsch van Beijnum" , "Multi6 Working Group" To: "Christian Huitema" From: David Conrad In-Reply-To: Message-Id: <80D123A6-7B8C-11D7-B0B2-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mostly just thinking out loud here (if this is still permitted)... On Thursday, April 17, 2003, at 10:58 AM, Christian Huitema wrote: > Even if we solved MAC address collision on a single link, you have to > remember that a host can be multi-homed to several interfaces. Whatever > we do to support the survival of TCP connections should also work when > the traffic moves from interface A to interface B, e.g. from 802.11 to > GPRS. In such cases, the two interfaces are likely to belong to > different sites, and are like to use different interface identifiers > (since they indeed are different interfaces). The solution of "just > using 64 bits" will not work there. > > -- Christian Huitema > If you define the multi-homed 'site' to be the host then I think it will. and On Thursday, April 17, 2003, at 12:35 PM, Christian Huitema wrote: > Sure. Another issue is privacy. I don't necessarily want different ISP > to be able to correlate that two traffic flows do in fact originate > from > the same hosts. In fact, privacy advocates would go ballistic if we > mandated that. No reason (other than efficiency) that a globally unique ID must be permanently assigned to an interface. If you can verify global uniqueness in a reasonably rapid fashion, you just auto-generate a new globally unique ID per 'session'. Rgds, -drc From owner-multi6@ops.ietf.org Thu May 1 01:52:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07939 for ; Thu, 1 May 2003 01:52:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19B711-0008NQ-00 for multi6-data@psg.com; Thu, 01 May 2003 05:53:55 +0000 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 19B70x-0008Mo-00 for multi6@ops.ietf.org; Thu, 01 May 2003 05:53:52 +0000 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 12E38137F04; Wed, 30 Apr 2003 22:53:44 -0700 (PDT) Date: Wed, 30 Apr 2003 22:53:37 -0700 Subject: Re: updating GSE for the new millennium Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Iljitsch van Beijnum , multi6@ops.ietf.org To: Peter Tattam From: David Conrad In-Reply-To: Message-Id: <4060E30C-7B99-11D7-B0B2-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, April 30, 2003, at 07:27 PM, Peter Tattam wrote: >> Depending on your approach, it may not be necessary to rewrite the >> source address. > > I don't think it's necessary. The less changes to the packet, the > better in my > opinion. Just map the N bit label at whatever point a decision has to > be made > to forward the packet outside the site. I think only one relabelling > should be > allowed and the decision to relabel be based on on the pre-labelled > address. Agreed. > I would presume that a MH address be identifiable by just looking at > the address > (i.e. the top M (where M < N) bits represent a particular class of MH > addresses). Why would you not want all addresses to be multi-homable? Why add the complexity of figuring out whether an address is multi-homable or not? > Once the labelling is done, it can be sent all the way to the end > host. If one retains the prelabelled source address, this is an > additional tag > to the end point that the packet can have it's label removed. Right. To put one approach I've been toying with in more concrete terms: Inside the site, call the first 48 bits of the address the 'site identifier'. These are globally unique, permanently assigned identifiers which are used as the prefix for all devices within the site. Outside the site, call the first 48 bits the 'aggregation locator'. These are globally unique, transitory (for the duration of the connectivity contract between the site and the ISP) routing locators assigned by ISPs out of blocks they announce to their peers as aggregates. At the border, the 'site identifier' is used as a key into a table of site identifier/aggregation locator mappings. In the DNS, AAAA rdata is a site identifier and all hosts within a site use the site identifier as the prefix for their source address(es). Packet sent and arrives at a border device. First 48 bits of the destination address are stripped off, used as a key into a table of site identifier/aggregation locator key/value pairs to get back one or more aggregation locators, one of the aggregation locators is chosen and written into the first 48 bits of the destination address. Packeted is forwarded on to the next hop according to the value of the aggregation locator. On reception at the destination site, the first 48 bits of the destination address are stripped off. The aggregation locator value is then looked up in the manually configured set of aggregation locators on the border device that handles the inverse mapping to get the site identifier. The site identifier is then written into the destination addresses and the packet is forwarded onto the destination within the site. Advantages that I can see: - multi-homing is 'easy', simply add new provider's aggregation locator to your site identifier - no need to inform ISPs of each other's existence - no negative impact on global routing tables - re-homing is a special case of multi-homing (only one aggregation locator associated with the site identifier) - renumbering becomes trivial - no modification necessary to existing v6 stacks or applications - no modification necessary to the DNS - all v6 stateless/statefull auto-config stuff continues to work - privacy is no more of a concern than it is in existing v6 addressing arch - mapping of site identifier/aggregation locator is done at the edges where performance is less of a concern - mapping is managed by site administrator so no need for new trust relationships - end-to-end transparent - traceroute still works Disadvantages that I can see: - Assumes the boundary of a site is distinct enough to install a (set of) device(s) at it - Implies a site is internally connected - Needs a globally distributed key/value lookup table - Data integrity of the table must be assurable - Requires mucking about with the packet in flight. Twice. - Needs a border device (or process) at both source and destination - Need at least two globally unique prefixes per site (one site identifier, one or more aggregation locators) - Doesn't provide host multi-homing unless a host is also a site - traceroute still works I'm sure I'm missing some. I'm equally sure people will tell me why this won't work... :-) > The main issues I can see behind restoring the original packet would > be TCP/UDP > checksums and IPSec. Perhaps I misunderstand. If the original values are restored before delivery at the final destination, the TCP/UDP checksums would compute correctly and IPSec would not be affected. > One issue I just thought of is what happens if a physical site > represents > multiple logical MH sites. Not an issue (given oodles of address space) -- use multiple site identifiers and aggregation locators. > When there are several possible MH > site addresses, one would have to match the post labelled transit > addresses to > the MH site prefix that they pertain to. The key would be to maintain a mapping between each and every site identifier and the aggregation locators providing service to that site identifier. Just some thoughts... Rgds, -drc From owner-multi6@ops.ietf.org Thu May 1 02:41:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20406 for ; Thu, 1 May 2003 02:41:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19B7mo-000AYf-00 for multi6-data@psg.com; Thu, 01 May 2003 06:43:18 +0000 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.36 #1) id 19B7mH-000AXR-00 for multi6@ops.ietf.org; Thu, 01 May 2003 06:42:45 +0000 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id QAA06436; Thu, 1 May 2003 16:42:28 +1000 (EST) Date: Thu, 1 May 2003 16:42:28 +1000 (EST) From: Peter Tattam To: David Conrad cc: Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: updating GSE for the new millennium In-Reply-To: <4060E30C-7B99-11D7-B0B2-000393DB42B2@nominum.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 30 Apr 2003, David Conrad wrote: > On Wednesday, April 30, 2003, at 07:27 PM, Peter Tattam wrote: > >> Depending on your approach, it may not be necessary to rewrite the > >> source address. > > > > I don't think it's necessary. The less changes to the packet, the > > better in my > > opinion. Just map the N bit label at whatever point a decision has to > > be made > > to forward the packet outside the site. I think only one relabelling > > should be > > allowed and the decision to relabel be based on on the pre-labelled > > address. > > Agreed. Additionally, I think it is a bad idea to relabel the source as the label supplied is unlikely to be the best path. The other end needs to determine this. > > > I would presume that a MH address be identifiable by just looking at > > the address > > (i.e. the top M (where M < N) bits represent a particular class of MH > > addresses). > > Why would you not want all addresses to be multi-homable? Why add the > complexity of figuring out whether an address is multi-homable or not? it probably doesn't matter - I was suggesting it as a method of determining if the packet was clean or dirty. It would be important if dirty packets end up at the destination host. > > > Once the labelling is done, it can be sent all the way to the end > > host. If one retains the prelabelled source address, this is an > > additional tag > > to the end point that the packet can have it's label removed. > > Right. To put one approach I've been toying with in more concrete > terms: > > Inside the site, call the first 48 bits of the address the 'site > identifier'. These are globally unique, permanently assigned > identifiers which are used as the prefix for all devices within the > site. Outside the site, call the first 48 bits the 'aggregation > locator'. These are globally unique, transitory (for the duration of > the connectivity contract between the site and the ISP) routing > locators assigned by ISPs out of blocks they announce to their peers as > aggregates. At the border, the 'site identifier' is used as a key into > a table of site identifier/aggregation locator mappings. In the DNS, > AAAA rdata is a site identifier and all hosts within a site use the > site identifier as the prefix for their source address(es). > > Packet sent and arrives at a border device. First 48 bits of the > destination address are stripped off, used as a key into a table of > site identifier/aggregation locator key/value pairs to get back one or > more aggregation locators, one of the aggregation locators is chosen > and written into the first 48 bits of the destination address. > Packeted is forwarded on to the next hop according to the value of the > aggregation locator. > > On reception at the destination site, the first 48 bits of the > destination address are stripped off. The aggregation locator value is > then looked up in the manually configured set of aggregation locators > on the border device that handles the inverse mapping to get the site > identifier. The site identifier is then written into the destination > addresses and the packet is forwarded onto the destination within the > site. > > Advantages that I can see: > - multi-homing is 'easy', simply add new provider's aggregation locator > to your site identifier > - no need to inform ISPs of each other's existence > - no negative impact on global routing tables > - re-homing is a special case of multi-homing (only one aggregation > locator associated with the site identifier) > - renumbering becomes trivial > - no modification necessary to existing v6 stacks or applications > - no modification necessary to the DNS > - all v6 stateless/statefull auto-config stuff continues to work > - privacy is no more of a concern than it is in existing v6 addressing > arch > - mapping of site identifier/aggregation locator is done at the edges > where performance is less of a concern > - mapping is managed by site administrator so no need for new trust > relationships > - end-to-end transparent > - traceroute still works > > Disadvantages that I can see: > - Assumes the boundary of a site is distinct enough to install a (set > of) device(s) at it > - Implies a site is internally connected > - Needs a globally distributed key/value lookup table > - Data integrity of the table must be assurable > - Requires mucking about with the packet in flight. Twice. > - Needs a border device (or process) at both source and destination > - Need at least two globally unique prefixes per site (one site > identifier, one or more aggregation locators) > - Doesn't provide host multi-homing unless a host is also a site > - traceroute still works > > I'm sure I'm missing some. I'm equally sure people will tell me why > this won't work... :-) > > > The main issues I can see behind restoring the original packet would > > be TCP/UDP > > checksums and IPSec. > > Perhaps I misunderstand. If the original values are restored before > delivery at the final destination, the TCP/UDP checksums would compute > correctly and IPSec would not be affected. For a TCP connection, the srce/dest part of checksum can be cached. One just has to agree on knowing when to include the srce/dest pair in the checksum. Another reason for determining if the packet is clean or dirty. Minor optimization that's all. Don't forget that in Ipv6 we don't do IP header checksumming any more. We need to search for protocols that depend on the addresses in the header being intact and work out whether the packet needs to be reconstructed or cached values can be used instead. If we are considering very high speeds, this could be important. Messing with the packet in transit could be a performance hit and if we can get away without doing it, all the better. > > > One issue I just thought of is what happens if a physical site > > represents > > multiple logical MH sites. > > Not an issue (given oodles of address space) -- use multiple site > identifiers and aggregation locators. > > > When there are several possible MH > > site addresses, one would have to match the post labelled transit > > addresses to > > the MH site prefix that they pertain to. > > The key would be to maintain a mapping between each and every site > identifier and the aggregation locators providing service to that site > identifier. This is the really tough bit. Maintaining an accurate and secure database of mappings is non-trivial. Each site has their own specific view of the network topology which makes this quite different to the DNS system. The only other issue I wonder about is using single box to do translations at the site boundary. Because such a box is an insertion, it could be a single point of failure, and could well have scalability issues. I would see it as an interim step towards a later solution where end hosts are able to mange the translations themselves. At least it should be a stateless translation which makes it relatively scalable. > > Just some thoughts... Some good ones. Glad to see others recognizing the benefits of the GSE style of doing stuff. > > Rgds, > -drc > > > Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From owner-multi6@ops.ietf.org Thu May 1 03:33:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01131 for ; Thu, 1 May 2003 03:33:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19B8aK-000CnC-00 for multi6-data@psg.com; Thu, 01 May 2003 07:34:28 +0000 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 19B8aH-000Cmv-00 for multi6@ops.ietf.org; Thu, 01 May 2003 07:34:25 +0000 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id A1114137F04; Thu, 1 May 2003 00:34:23 -0700 (PDT) Date: Thu, 1 May 2003 00:34:22 -0700 Subject: Re: updating GSE for the new millennium Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Iljitsch van Beijnum , multi6@ops.ietf.org To: Peter Tattam From: David Conrad In-Reply-To: Message-Id: <537AF503-7BA7-11D7-B0B2-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Peter, On Wednesday, April 30, 2003, at 11:42 PM, Peter Tattam wrote: > Additionally, I think it is a bad idea to relabel the source as the > label > supplied is unlikely to be the best path. The other end needs to > determine > this. Agreed. >> Perhaps I misunderstand. If the original values are restored before >> delivery at the final destination, the TCP/UDP checksums would compute >> correctly and IPSec would not be affected. > > For a TCP connection, the srce/dest part of checksum can be cached. > One just > has to agree on knowing when to include the srce/dest pair in the > checksum. > Another reason for determining if the packet is clean or dirty. Minor > optimization that's all. Don't forget that in Ipv6 we don't do IP > header > checksumming any more. Right. Not convinced this would be necessary, but understand what you're saying. > We need to search for protocols that depend on the addresses in the > header > being intact and work out whether the packet needs to be reconstructed > or > cached values can be used instead. This would be the same set that is sensitive to NAT. > If we are considering very high speeds, > this could be important. Messing with the packet in transit could be a > performance hit and if we can get away without doing it, all the > better. As the rewriting occurs only at the edges, I don't believe extreme performance is that critical (relative to the core). > This is the really tough bit. Maintaining an accurate and secure > database of > mappings is non-trivial. Each site has their own specific view of the > network > topology which makes this quite different to the DNS system. Sorry, don't follow. The mapping table (in my view) is independent of topology -- it is a simple key/value pair where the key is the site identifier and the value is the set of one or more ISP provided aggregation locators from ISPs providing service to that site. The border device at the source fetches the appropriate value based on the first 48 bits of the destination address and rewrites the destination address with (one of) the aggregation locator(s). Where a destination is multi-homed, the policy determining which out of a set of aggregation locators is chosen would be administratively defined by the source site administrator (although I can imagine some sort of preference information being provided by the destination in the mapping table). I gather your view is different? With regards to maintaining the mapping table, I see two generic ways of doing this, either pushing data out like routing protocols or pulling data in on demand like the DNS. Both are (obviously) tractable and both have advantages and disadvantages. For obvious reasons I like the DNS model (not necessarily the DNS itself), but I see this is a side (albeit important) issue to the underlying architecture. > The only other issue I wonder about is using single box to do > translations at > the site boundary. Because such a box is an insertion, it could be a > single > point of failure, and could well have scalability issues. In as much as the existing border router is a single point of failure or potential bottleneck, yes. In my view, the mapping/re-mapping functionality could easily be integrated into the site border router. A separate box would also make sense. Note that if it is a separate box, you can have more than one. Rgds, -drc From owner-multi6@ops.ietf.org Thu May 1 06:36:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04889 for ; Thu, 1 May 2003 06:36:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BBRC-0003Uk-00 for multi6-data@psg.com; Thu, 01 May 2003 10:37:14 +0000 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.36 #1) id 19BBR8-0003UH-00 for multi6@ops.ietf.org; Thu, 01 May 2003 10:37:10 +0000 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id UAA22950; Thu, 1 May 2003 20:36:58 +1000 (EST) Date: Thu, 1 May 2003 20:36:58 +1000 (EST) From: Peter Tattam To: David Conrad cc: Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: updating GSE for the new millennium In-Reply-To: <537AF503-7BA7-11D7-B0B2-000393DB42B2@nominum.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 1 May 2003, David Conrad wrote: > Peter, > > On Wednesday, April 30, 2003, at 11:42 PM, Peter Tattam wrote: > > Additionally, I think it is a bad idea to relabel the source as the > > label > > supplied is unlikely to be the best path. The other end needs to > > determine > > this. > > Agreed. > > >> Perhaps I misunderstand. If the original values are restored before > >> delivery at the final destination, the TCP/UDP checksums would compute > >> correctly and IPSec would not be affected. > > > > For a TCP connection, the srce/dest part of checksum can be cached. > > One just > > has to agree on knowing when to include the srce/dest pair in the > > checksum. > > Another reason for determining if the packet is clean or dirty. Minor > > optimization that's all. Don't forget that in Ipv6 we don't do IP > > header > > checksumming any more. > > Right. Not convinced this would be necessary, but understand what > you're saying. > > > We need to search for protocols that depend on the addresses in the > > header > > being intact and work out whether the packet needs to be reconstructed > > or > > cached values can be used instead. > > This would be the same set that is sensitive to NAT. agreed. > > > If we are considering very high speeds, > > this could be important. Messing with the packet in transit could be a > > performance hit and if we can get away without doing it, all the > > better. > > As the rewriting occurs only at the edges, I don't believe extreme > performance is that critical (relative to the core). not at this stage. It will however introduce some latency even if the boxen can keep up. > > > This is the really tough bit. Maintaining an accurate and secure > > database of > > mappings is non-trivial. Each site has their own specific view of the > > network > > topology which makes this quite different to the DNS system. > > Sorry, don't follow. The mapping table (in my view) is independent of > topology -- it is a simple key/value pair where the key is the site > identifier and the value is the set of one or more ISP provided > aggregation locators from ISPs providing service to that site. The > border device at the source fetches the appropriate value based on the > first 48 bits of the destination address and rewrites the destination > address with (one of) the aggregation locator(s). Where a destination > is multi-homed, the policy determining which out of a set of > aggregation locators is chosen would be administratively defined by the > source site administrator (although I can imagine some sort of > preference information being provided by the destination in the mapping > table). > > I gather your view is different? yes, radically. What you describe is a semi static view of the network. In reality, you have to pick which one of the mappings is suitable to translate. It is not possible for the advertising site to determine this because the best path to reach that site will depend on where you are in the internet. This choice can only be made based on either tracing all possible paths to the site, or relying on information gathered about the network. I think this is a point which is constantly overlooked in the debate over MH solutions which rely on some kind of mapping tables. > > With regards to maintaining the mapping table, I see two generic ways > of doing this, either pushing data out like routing protocols or > pulling data in on demand like the DNS. Both are (obviously) tractable > and both have advantages and disadvantages. For obvious reasons I like > the DNS model (not necessarily the DNS itself), but I see this is a > side (albeit important) issue to the underlying architecture. Try a few examples of a complex MH network with both ends being nulti homed and on opposite sides of the DFZ and you should understand what I am getting at. I have mention the push vs pull approaches to distributing the MH information. I still contend that because of routing topology, a simplistic view like DNS won't fly IMHO. > > > The only other issue I wonder about is using single box to do > > translations at > > the site boundary. Because such a box is an insertion, it could be a > > single > > point of failure, and could well have scalability issues. > > In as much as the existing border router is a single point of failure > or potential bottleneck, yes. In my view, the mapping/re-mapping > functionality could easily be integrated into the site border router. > A separate box would also make sense. Note that if it is a separate > box, you can have more than one. I agree that because it will be stateless so theoretically you could do load balancing with parallel boxes or have a standby box for emergency use. > > Rgds, > -drc > > -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From owner-multi6@ops.ietf.org Thu May 1 07:33:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05473 for ; Thu, 1 May 2003 07:33:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BCKy-0008qO-00 for multi6-data@psg.com; Thu, 01 May 2003 11:34:52 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19BCKv-0008q7-00 for multi6@ops.ietf.org; Thu, 01 May 2003 11:34:49 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h41BXXE99651; Thu, 1 May 2003 13:33:33 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 1 May 2003 10:32:56 +0200 Subject: Re: updating GSE for the new millennium Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: David Conrad From: Iljitsch van Beijnum In-Reply-To: <2BB75AB3-7B6E-11D7-B0B2-000393DB42B2@nominum.com> Message-Id: <8273DC16-7BAF-11D7-BE00-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-28.8 required=5.0 tests=BAYES_01,DATE_IN_PAST_03_06,EMAIL_ATTRIBUTION,IN_REP_TO, QUOTED_EMAIL_TEXT,REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On donderdag, mei 1, 2003, at 02:45 Europe/Amsterdam, David Conrad wrote: >> We've been talking about GSE earlier this month before we got >> side-tracked. I think it's time to see what a descendent of the GSE >> family would look like in the third millennium, so I want to write a >> draft. Hopefully this will give us something useful to talk about in >> Vienna. > Hmm. I am doing the same thing (although I'm not planning on being in > Vienna). Ok. It's going to be interesting to see the differences in two drafts based on the same approach. >> What I'd like to do is take input from everyone and incorporate this >> as much as possible in this draft. That probably means more options >> and more complexity that we'd like to see in an actual protocol, but >> for now that's fine: we can always prune later. > I would suggest starting the other direction -- the IETF already has > way too many drafts that try to be all things to all people. Start > with a simple, easily understood base and see how far that gets you. I hear you, but I'd still like to err on the side of including too much. If nothing else, this makes the discussion easier and we can always remove it later. > Depending on your approach, it may not be necessary to rewrite the > source address. Ok, two problems then: 1. ISPs do ingress filtering towards their customers so those can't spoof their source addresses. This is something we don't want to break if we can avoid it. 2. This makes sending back ICMP errors much more difficult because the routers along the way then need to support this solution. Note that dropping ICMPs is not an option because PMTUd is mandatory for stuff handling packets bigger than 1280 bytes. >> For the source when transmitting or the destination when receiving, >> the rewriter can presumably easily find the additional information >> needed to compelete the mapping in its configuration, but for the >> destination when transmitting or the source when receiving it must >> first discover the mapping. > Yes. I believe it'll turn out that this discovery is where the > complexity (political if not technical) will lie. I do not believe it > to be a difficult technical problem, however I'm sure any solution > proposed will be controversial. Yes, this is the heart of the matter. >> Two additional questions: >> - Is adding options or tunnel headers an option, > I don't think so. Ok, I was thinking along the same lines. However, doing the negotiation/discovery in options in the first few packets of a stream might be a nice way to handle this. I assume this won't be a problem? >> - Can packets only be rewritten once, or can this happen several >> times? > Address rewriting (at least as described above) would appear to me to > be end-to-end transparent. As such, I'd say yes, although I'm not > sure I see the point. A multihomed site may receive transit from a site that is also multihomed. This could happen more often than we expect if single hosts also adopt this mechanism, for instance, a laptop "multihomes" to the company network and a wireless network. From owner-multi6@ops.ietf.org Thu May 1 07:33:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05489 for ; Thu, 1 May 2003 07:33:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BCLC-0008ss-00 for multi6-data@psg.com; Thu, 01 May 2003 11:35:06 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19BCL8-0008rs-00 for multi6@ops.ietf.org; Thu, 01 May 2003 11:35:02 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h41BXiE99659; Thu, 1 May 2003 13:33:44 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 1 May 2003 12:47:26 +0200 Subject: Re: updating GSE for the new millennium Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: David Conrad , multi6@ops.ietf.org To: Peter Tattam From: Iljitsch van Beijnum In-Reply-To: Message-Id: <4C7D85F4-7BC2-11D7-BE00-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On donderdag, mei 1, 2003, at 04:27 Europe/Amsterdam, Peter Tattam wrote: > I think only one relabelling should be allowed Apart from the question if this is what we want, is this something we can enforce? Or should care to enforce? This would give ISPs the option of relabeling just so their customers can't do it themselves. > I would presume that a MH address be identifiable by just looking at > the address (i.e. the top M (where M < N) bits represent a particular > class of MH addresses). Doing this has the advantage we can always easily recognize an unrewritten multihomed address, but is that a big enough advantage to require this? I can imagine a situation where hosts use a regular prefix as long as this prefix works and only rewrite with a secondary prefix when the first one fails. > The main issues I can see behind restoring the original packet would > be TCP/UDP > checksums and IPSec. If the two end points are labelling aware, > measures can > be taken to ignore the label from the checksums or replace it for > IPsec, > otherwise it would be up to labelling boxen (border routers or other) > to do > this on behalf of the hosts which are unaware of the labelling > possibility. Sure, if an end-host implements this itself it can optimize its internal processing to avoid doing unnecessary work. This is going to help even more with reachability detection. > One issue I just thought of is what happens if a physical site > represents > multiple logical MH sites. Then we're right back at the source address selection problem. :-( However, in this case the source multihomed address would presumably always be chosen based on policy/application requirements rather than reachability status, so it shouldn't be as much of a problem. For incoming traffic it's just a matter of keeping the mappings straight. > I wonder if these ideas might receive more support if the terminology > of > labelling were used instead of GSE. We'd be more likely to draw in > some > support from the MPLS mob. It's probably too confusing. MPLS is all about very small labels that are attached and removed without touching the IP packet. What we're doing here involves globally unique values inside IP packets. I used the word "label" to avoid saying "address" or "name". We probably need something better for this. Now using MPLS infrastructure to build a multihoming solution would be an interesting idea in it's own right. From owner-multi6@ops.ietf.org Fri May 2 02:12:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06640 for ; Fri, 2 May 2003 02:12:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BTl0-000PeO-00 for multi6-data@psg.com; Fri, 02 May 2003 06:10:54 +0000 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 19BTkw-000PeC-00 for multi6@ops.ietf.org; Fri, 02 May 2003 06:10:51 +0000 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id F0AC4137F05; Thu, 1 May 2003 23:10:48 -0700 (PDT) Date: Thu, 1 May 2003 23:10:48 -0700 Subject: Re: updating GSE for the new millennium Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Iljitsch van Beijnum , multi6@ops.ietf.org To: Peter Tattam From: David Conrad In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Peter, On Thursday, May 1, 2003, at 03:36 AM, Peter Tattam wrote: >> I gather your view is different? > yes, radically. What you describe is a semi static view of the > network. In > reality, you have to pick which one of the mappings is suitable to > translate. Yes. Even in the semi static view (as you put it), you need to pick one out of set of potential locators provided to you by the destination site. > It is not possible for the advertising site to determine this because > the > best path to reach that site will depend on where you are in the > internet. True. I would think, since the destination site is doing the advertising, it would be useful to include some 'advisory' information, e.g., if all other things are equal, choose locator X instead of Y (or choose X for 60% of flows, Y for the rest, or whatever). Of course, this is just advisory information. It is the source site which is making the decision as to what aggregation locator is chosen and there can be numerous contributing factors to that decision depending on what information is available to the chooser. > This choice can only be made based on either tracing all possible > paths to the > site, or relying on information gathered about the network. Of course, by the time you have traced all possible paths, it is possible new paths have been established, old paths are out of date, etc. Information gathered about the network can be out of date by the time it is collected. Etc. In other words, it is simply impossible to know the full state of the network at any given point in time. The _only_ thing you can know is what a snapshot of the network looked like within some window of time. Pragmatically speaking, at any given instant, I would argue that the vast majority of the end to end connectivity states, that is, whether A can reach B regardless of the path between A and B, do not change. We should optimize for that. A simple, easily implementable solution that optimizes for the normal case but continues to work, albeit potentially sub-optimally, in the exceptional cases is, I believe, what we should be aiming for. > I think this is a > point which is constantly overlooked in the debate over MH solutions > which > rely on some kind of mapping tables. I am not overlooking it. I have made a conscious decision to focus on pragmatism instead of trying to come up with a generic optimal solution as I would contend people have been looking for generic optimal solutions for a decade now and we have gotten nowhere. SIP (not Session Initiation Protocol) could have included a wide variety of bells and whistles to try to address every possible new and sexy idea people had come up with (53 byte packets anyone?). The 'S' in SIP didn't stand for "Steve's", after all... > Try a few examples of a complex MH network with both ends being nulti > homed and > on opposite sides of the DFZ and you should understand what I am > getting at. I have. I'd be very interested in discussing (perhaps offline) the scenarios you believe wouldn't work with this model. As an aside, whether a source is multi-homed is, I would argue, irrelevant. A packet hits the border, a lookup in the mapping table (however it is propagated/fetched) is done to translate the _destination_ site identifier into an aggregation locator. The source address is ignored. > I have mention the push vs pull approaches to distributing the MH > information. I > still contend that because of routing topology, a simplistic view like > DNS > won't fly IMHO. I am not religious. I think simple is good, but if it can be demonstrated it isn't sufficient, then more complex alternatives should be explored. Again, these are just some back-of-envelope type thoughts. I'm sure there are holes here. Pointers to them would be appreciated... Rgds, -drc From owner-multi6@ops.ietf.org Fri May 2 08:46:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12492 for ; Fri, 2 May 2003 08:46:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BZvR-000MWV-00 for multi6-data@psg.com; Fri, 02 May 2003 12:46:05 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19BZuu-000MV4-00 for multi6@ops.ietf.org; Fri, 02 May 2003 12:45:32 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h42CiGE02294; Fri, 2 May 2003 14:44:16 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 2 May 2003 14:44:13 +0200 Subject: Re: IETF multihoming powder: just add IPv6 and stir Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Kurt Erik Lindqvist From: Iljitsch van Beijnum In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-28.3 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On vrijdag, mei 2, 2003, at 09:22 Europe/Amsterdam, Kurt Erik Lindqvist wrote: [...] > I think that this is a very good summary of the situation. And I think > that it is good that we from time to time remind ourself of this..:-) Maybe we should remind the IPng wg as well... >> So we should use Vienna to decide WHAT we want to do, the HOW is then >> only a question of engineering, which we're supposed to know how to >> do here in the IETF. > I would also think that this is the main target of the Vienna meeting. > That said, it doesn't have to be the only thing we do. I think that after the what question has been answered, the how will soon be raised. >> It looks like the type of solution that most people like / the least >> people hate is a GSE++/8+8/6+2+10/16+16 type of solution. Such a >> solution is probably the least ambitious that can still be expected >> to work well in the long term and probably the most ambitious we can >> expect to be deployed before we run out of IPv6^H^H^H^HIPv4 address >> space. If we can't reach rough consensus on this as a general >> approach it is extremely unlikely we can reach it on something else. >> Note that agreeing on this approach doesn't mean all other proposals >> should be off the table immediately: if they provide additional >> benefits (for instance, they can be deployed before the "official" >> solution is ready) they should be viable so individual authors can >> keep working on them as they see fit. > I agree. Question is, with what you note above, how do we move that > forward? Leave that to Vienna to discuss or should me and Sean think > up away and present that? It might be good to get the word out that multi6 wants to recharter and work on the identifier/locator thing aka GSE++ aka 6+10. Then we can see if the pro mob is larger than the anti mob at the meeting. It looks like this approach can't be too controversial (at least on this list) because nobody has taken the trouble of speaking out against it. (Just assuming they would if they were, for no particular reason.) While making some other approaches official multi6 work items may be good for the proponent's egos, I don't think it will help those solutions much as there seems little interest in working on them as a group. Alternatively, you can surprise us. It had better be a pleasant surprise, though. :-) Of course there are the little details of the two documents the wg has to deliver. I'm not going to mention the "R" word, but how about the "how is it done in v4" draft? I seem to remember some text about it, do we need to work on this and get it shipped by Vienna? From owner-multi6@ops.ietf.org Fri May 2 08:46:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12507 for ; Fri, 2 May 2003 08:46:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BZyn-000NAl-00 for multi6-data@psg.com; Fri, 02 May 2003 12:49:33 +0000 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 19BZyk-000NAG-00 for multi6@ops.ietf.org; Fri, 02 May 2003 12:49:30 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h427TwTq003016; Fri, 2 May 2003 09:29:58 +0200 (CEST) Date: Fri, 2 May 2003 09:29:51 +0200 Subject: Re: updating GSE for the new millennium Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-28.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,RCVD_IN_RFCI,REPLY_WITH_QUOTES, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On onsdag, apr 30, 2003, at 16:19 Europe/Stockholm, Iljitsch van Beijnum wrote: > > Two additional questions: > > - Is adding options or tunnel headers an option, or would this make > this scheme too unattractive over IPv4-style multihoming? I would say no. It gives to much complexity on other levels. > > - Can packets only be rewritten once, or can this happen several times? > > > I would say no here was well. Without thinking too much, I would assume that this made to much implications on higher protocols. - kurtis - From owner-multi6@ops.ietf.org Fri May 2 08:47:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12526 for ; Fri, 2 May 2003 08:47:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BZyp-000NAp-00 for multi6-data@psg.com; Fri, 02 May 2003 12:49:35 +0000 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 19BZym-000NAG-00 for multi6@ops.ietf.org; Fri, 02 May 2003 12:49:32 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h426nHTq002903; Fri, 2 May 2003 08:49:18 +0200 (CEST) Date: Fri, 2 May 2003 08:49:11 +0200 Subject: Re: Resolving geo discussions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Tim Chown , multi6@ops.ietf.org To: Erik Nordmark From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <2E72BFB5-7C6A-11D7-92E2-000393520ED8@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-27.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_RFCI,REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ( I am finally back to email with a working computer - long story ) On onsdag, apr 23, 2003, at 01:58 Europe/Stockholm, Erik Nordmark wrote: >> As for what should be included, well we (IMHO) need to change the >> charter, or at least look at doing so and update the milestones. There >> are a number or proposals floating around, of which not all even have >> made it as IDs. Having presentations of all in Vienna, at a depth that >> gives justice to all proposals, might be a bit time consuming, but >> perhaps we need to. > > Instead of reviewing proposals in depth it might make more sense > to task somebody with doing a compare and contrast between the > different > proposals and use such a presentation as the focus for discussion. > > That approach tends to lead to more focus on the problem and the > possible > approaches with less of "my proposal is better than yours" type of > discussion. > I guess that is true. Still I would prefer to have the authors give their own views. I would prefer to discuss the dept of the presentations. - kurtis - From owner-multi6@ops.ietf.org Fri May 2 08:47:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12522 for ; Fri, 2 May 2003 08:47:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BZys-000NB2-00 for multi6-data@psg.com; Fri, 02 May 2003 12:49:38 +0000 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74]) by psg.com with esmtp (Exim 3.36 #1) id 19BZyn-000NAk-00 for multi6@ops.ietf.org; Fri, 02 May 2003 12:49:36 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h426r2Tq002909; Fri, 2 May 2003 08:53:02 +0200 (CEST) Date: Fri, 2 May 2003 08:52:55 +0200 Subject: Re: Resolving geo discussions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Erik Nordmark , Tim Chown , To: Pekka Savola From: Kurt Erik Lindqvist In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-27.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_RFCI,REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On onsdag, apr 23, 2003, at 07:33 Europe/Stockholm, Pekka Savola wrote: >> >> Instead of reviewing proposals in depth it might make more sense >> to task somebody with doing a compare and contrast between the >> different >> proposals and use such a presentation as the focus for discussion. >> >> That approach tends to lead to more focus on the problem and the >> possible >> approaches with less of "my proposal is better than yours" type of >> discussion. > > Totally agree here. > > We shouldn't discuss proposals, but rather talk in some "meta" > multihoming level. > > We need to have better picture what we want and can do before getting > down > to business and digging holes... Maybe (most likely) this will be the outcome of Vienna. Still, I feel that given the time that have passed, and the fact that there are a number proposals out there, they deserve the chance to present them. I think I can already guess the outcome of this, but I think that although we need to agree where to move we also need to listen to peoples ideas on what the steps are. I personally like the idea of a number of design teams as a first step. But this is the discussion we need to have. - kurtis - From owner-multi6@ops.ietf.org Fri May 2 08:47:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12553 for ; Fri, 2 May 2003 08:47:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BZyy-000NBa-00 for multi6-data@psg.com; Fri, 02 May 2003 12:49:44 +0000 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 19BZyl-000NAG-00 for multi6@ops.ietf.org; Fri, 02 May 2003 12:49:31 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h427MATq002998; Fri, 2 May 2003 09:22:10 +0200 (CEST) Date: Fri, 2 May 2003 09:22:03 +0200 Subject: Re: IETF multihoming powder: just add IPv6 and stir Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <8DBCD09F-77E6-11D7-9B9F-00039388672E@muada.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-15.5 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, RCVD_IN_RFCI,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Iljitsch, > It seems to me the problem is that everyone brings different > assumptions and requirements to the table. For instance, the HIP > people are mainly interested in security and mobility, and solving > multihoming is secondary to those goals. Christian Huitema's proposals > are built around the idea that we can only make baby steps and should > work as much as possible with existing mechanisms. Michel Py doesn't > mind much that both ends must be changed in order to support MHAP; in > my geo stuff I don't worry about the fact that this will impose limits > on the network topology; and the GSE++ people aren't all that > concerned with the fact that GSE needs changes to not just one, but > many aspects of IP: routers, hosts, DNS. I think that this is a very good summary of the situation. And I think that it is good that we from time to time remind ourself of this..:-) > So we should use Vienna to decide WHAT we want to do, the HOW is then > only a question of engineering, which we're supposed to know how to do > here in the IETF. I would also think that this is the main target of the Vienna meeting. That said, it doesn't have to be the only thing we do. > > It looks like the type of solution that most people like / the least > people hate is a GSE++/8+8/6+2+10/16+16 type of solution. Such a > solution is probably the least ambitious that can still be expected to > work well in the long term and probably the most ambitious we can > expect to be deployed before we run out of IPv6^H^H^H^HIPv4 address > space. If we can't reach rough consensus on this as a general approach > it is extremely unlikely we can reach it on something else. > > Note that agreeing on this approach doesn't mean all other proposals > should be off the table immediately: if they provide additional > benefits (for instance, they can be deployed before the "official" > solution is ready) they should be viable so individual authors can > keep working on them as they see fit. > I agree. Question is, with what you note above, how do we move that forward? Leave that to Vienna to discuss or should me and Sean think up away and present that? - kurtis - From owner-multi6@ops.ietf.org Fri May 2 08:54:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12645 for ; Fri, 2 May 2003 08:54:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Ba66-000OMM-00 for multi6-data@psg.com; Fri, 02 May 2003 12:57:06 +0000 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 19Ba62-000OJj-00 for multi6@ops.ietf.org; Fri, 02 May 2003 12:57:02 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h42CxMTq003631; Fri, 2 May 2003 14:59:22 +0200 (CEST) Date: Fri, 2 May 2003 14:59:17 +0200 Subject: Re: IETF multihoming powder: just add IPv6 and stir Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-15.5 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, RCVD_IN_RFCI,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > It might be good to get the word out that multi6 wants to recharter > and work on the identifier/locator thing aka GSE++ aka 6+10. Then we > can see if the pro mob is larger than the anti mob at the meeting. It > looks like this approach can't be too controversial (at least on this > list) because nobody has taken the trouble of speaking out against it. > (Just assuming they would if they were, for no particular reason.) I am not sure I want to say that we recharter to the GSE++ model. I think we need to recharter mainly to update the milestones and also to perhaps change the charter somewhat. I am discussing this with Sean. Question is if this is worth doing before meeting in Vienna so that we can discuss this then, or if we should wait until after to reflect what has been discussed. > > While making some other approaches official multi6 work items may be > good for the proponent's egos, I don't think it will help those > solutions much as there seems little interest in working on them as a > group. Well, that is certainly true. But I think that if they want to present and make their case for their solution and against a GSE based approach, they should be allowed to do that in Vienna. > > Alternatively, you can surprise us. It had better be a pleasant > surprise, though. :-) I am not buying the beer..:-) I will discuss with Sean and see what we think is the best way forward. > > Of course there are the little details of the two documents the wg has > to deliver. I'm not going to mention the "R" word, but how about the > "how is it done in v4" draft? I seem to remember some text about it, > do we need to work on this and get it shipped by Vienna? We will last call the "Requirements" doc shortly. As for the "IPv4-HOWTO", does it actually bring us something new that will help us move forward at this point? Or is this a nice to have that gets some issues of the table? - kurtis - From owner-multi6@ops.ietf.org Fri May 2 09:08:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12857 for ; Fri, 2 May 2003 09:08:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BaJ8-0000fO-00 for multi6-data@psg.com; Fri, 02 May 2003 13:10:34 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19BaJ5-0000f5-00 for multi6@ops.ietf.org; Fri, 02 May 2003 13:10:31 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h42D9FE02385; Fri, 2 May 2003 15:09:15 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 2 May 2003 15:09:14 +0200 Subject: Re: IETF multihoming powder: just add IPv6 and stir Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Kurt Erik Lindqvist From: Iljitsch van Beijnum In-Reply-To: Message-Id: <4613E6EE-7C9F-11D7-8648-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On vrijdag, mei 2, 2003, at 14:59 Europe/Amsterdam, Kurt Erik Lindqvist wrote: > I am not sure I want to say that we recharter to the GSE++ model. I > think we need to recharter mainly to update the milestones and also to > perhaps change the charter somewhat. Ok, the charter isn't the most important thing, what we want to accomplish is. >> While making some other approaches official multi6 work items may be >> good for the proponent's egos, I don't think it will help those >> solutions much as there seems little interest in working on them as a >> group. > Well, that is certainly true. But I think that if they want to present > and make their case for their solution and against a GSE based > approach, they should be allowed to do that in Vienna. Ok, you'll probably want to plan this part as the last item on the agenda because I'm pretty sure that after a few rounds of "geo is good" "no it's bad" people aren't in the mood to reach consensus on much of anything. :-) > As for the "IPv4-HOWTO", does it actually bring us something new that > will help us move forward at this point? Or is this a nice to have > that gets some issues of the table? There are quite a few limitations for people that want to multihome in v4. Not everyone may be aware of those and subsequently underestimate the latent need for multihoming. So it might be good to document this after all. From owner-multi6@ops.ietf.org Fri May 2 10:26:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16152 for ; Fri, 2 May 2003 10:26:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BbWS-000DaY-00 for multi6-data@psg.com; Fri, 02 May 2003 14:28:24 +0000 Received: from mail-gw1.hursley.ibm.com ([194.196.110.15]) by psg.com with esmtp (Exim 3.36 #1) id 19BbWP-000DZn-00 for multi6@ops.ietf.org; Fri, 02 May 2003 14:28:21 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19BbWK-0003qi-00; Fri, 02 May 2003 15:28:16 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19BbWK-0003qd-00; Fri, 02 May 2003 15:28:16 +0100 Received: from hursley.ibm.com (dhcp21-82.zurich.ibm.com [9.4.21.82]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA148688; Fri, 2 May 2003 15:28:14 +0100 Message-ID: <3EB280A1.73BF21CD@hursley.ibm.com> Date: Fri, 02 May 2003 16:28:49 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: David Conrad CC: multi6@ops.ietf.org Subject: Re: updating GSE for the new millennium References: <537AF503-7BA7-11D7-B0B2-000393DB42B2@nominum.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit David Conrad wrote: ... > With regards to maintaining the mapping table, I see two generic ways > of doing this, either pushing data out like routing protocols or > pulling data in on demand like the DNS. Both are (obviously) tractable > and both have advantages and disadvantages. For obvious reasons I like > the DNS model (not necessarily the DNS itself), but I see this is a > side (albeit important) issue to the underlying architecture. No, I don't think it's a side issue. DNS brings the risk of a big-time circular dependency. In fact, Jon Postel thought about this one: he contributed the following to RFC 1958: 3.11 Circular dependencies must be avoided. For example, routing must not depend on look-ups in the Domain Name System (DNS), since the updating of DNS servers depends on successful routing. Brian From owner-multi6@ops.ietf.org Fri May 2 12:25:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19632 for ; Fri, 2 May 2003 12:25:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BdND-0008yJ-00 for multi6-data@psg.com; Fri, 02 May 2003 16:26:59 +0000 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 19BdN8-0008xW-00 for multi6@ops.ietf.org; Fri, 02 May 2003 16:26:55 +0000 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 56533137F05; Fri, 2 May 2003 09:26:53 -0700 (PDT) Date: Fri, 2 May 2003 09:26:52 -0700 Subject: Re: updating GSE for the new millennium Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Brian E Carpenter From: David Conrad In-Reply-To: <3EB280A1.73BF21CD@hursley.ibm.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian, There would only be a dependency if the servers providing the mapping lookup table were inside the site being mapped. This is probably something it would be best to avoid (as the doctor says, "don't do that"). Numbering the device that provides the mapping out of aggregation locator space would be a way to avoid this. Other ways exist. Note that I am not against using some other mechanism than something like the DNS that provides the same "data pull" functionality. Nor am I against "data push". As I said, both have advantages and disadvantages. What is more interesting to me is whether or not the idea of implementing identity/locator separation by rewriting at the borders has legs. Rgds, -drc On Friday, May 2, 2003, at 07:28 AM, Brian E Carpenter wrote: > David Conrad wrote: > ... >> With regards to maintaining the mapping table, I see two generic ways >> of doing this, either pushing data out like routing protocols or >> pulling data in on demand like the DNS. Both are (obviously) >> tractable >> and both have advantages and disadvantages. For obvious reasons I >> like >> the DNS model (not necessarily the DNS itself), but I see this is a >> side (albeit important) issue to the underlying architecture. > > No, I don't think it's a side issue. DNS brings the risk of a big-time > circular dependency. In fact, Jon Postel thought about this one: he > contributed the following to RFC 1958: > > 3.11 Circular dependencies must be avoided. > > For example, routing must not depend on look-ups in the Domain > Name System (DNS), since the updating of DNS servers depends on > successful routing. > > > Brian > From owner-multi6@ops.ietf.org Fri May 2 13:32:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22029 for ; Fri, 2 May 2003 13:32:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BeQU-000LgJ-00 for multi6-data@psg.com; Fri, 02 May 2003 17:34:26 +0000 Received: from tomts10.bellnexxia.net ([209.226.175.54] helo=tomts10-srv.bellnexxia.net) by psg.com with esmtp (Exim 3.36 #1) id 19BeQQ-000Lfz-00 for multi6@ops.ietf.org; Fri, 02 May 2003 17:34:22 +0000 Received: from yahoo.com ([65.93.183.71]) by tomts10-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with ESMTP id <20030502173421.RODZ7364.tomts10-srv.bellnexxia.net@yahoo.com>; Fri, 2 May 2003 13:34:21 -0400 Date: Fri, 2 May 2003 13:34:21 -0400 Subject: Re: New draft: Now What? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Pekka Savola From: S Woodside In-Reply-To: Message-Id: <4F7509B0-7CC4-11D7-9FA6-000393414368@yahoo.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-9.0 required=5.0 tests=BAYES_10,FORGED_YAHOO_RCVD,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_FAKE_HELO_DOTCOM,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I have a comment about this draft from the perspective of Community wireless networks. > 3.1.1. Minimal > > Very minimal end-sites, such as typical home networks or very small > enterprises, are quite small and typically do not include mission- > critical activities. Yes, this is true. > Naturally, anyone would be willing to achieve multihoming benefits, > but usually the associated costs, e.g. caused by obtaining physical > connectivity to two ISPs, do not justify it. This is a argument that begs the question "is it expensive". You are assuming that the answer is yes, but it's not with a CWN, one of the main points of a CWN is to share bandwidth from people connected to different ISPs. That's different people, each individually connected to one ISP, but sharing the traffic between them, in a mesh, or a managed network, whatever, they are still sharing it. Simon From owner-multi6@ops.ietf.org Fri May 2 14:13:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23787 for ; Fri, 2 May 2003 14:13:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Bf46-0003fp-00 for multi6-data@psg.com; Fri, 02 May 2003 18:15:22 +0000 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.36 #1) id 19Bf43-0003ev-00 for multi6@ops.ietf.org; Fri, 02 May 2003 18:15:19 +0000 Received: (qmail 9724 invoked by uid 0); 2 May 2003 18:15:18 -0000 Received: from localhost.automagic.org (HELO isc.org) (root@127.0.0.1) by localhost.automagic.org with SMTP; 2 May 2003 18:15:18 -0000 Date: Fri, 2 May 2003 14:15:16 -0400 Subject: Re: IETF multihoming powder: just add IPv6 and stir Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Kurt Erik Lindqvist , multi6@ops.ietf.org To: Iljitsch van Beijnum From: Joe Abley In-Reply-To: <4613E6EE-7C9F-11D7-8648-00039388672E@muada.com> Message-Id: <06A91EE3-7CCA-11D7-AA27-00039312C852@isc.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, May 2, 2003, at 09:09 Canada/Eastern, Iljitsch van Beijnum wrote: > There are quite a few limitations for people that want to multihome in > v4. Not everyone may be aware of those and subsequently underestimate > the latent need for multihoming. So it might be good to document this > after all. I am still very happy to collate ideas and edit that document, if people are happy for me to do so. The main reason it stalled last time was that I wasn't happy being the only one writing down a description of current practices, since many different people are doing many different things for many different reasons, and there weren't many contributors to the doc at the time. It got as far as "rip all the v4 stuff out of the requirements doc into a separate doc", and that was about it. Joe From owner-multi6@ops.ietf.org Fri May 2 14:19:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24026 for ; Fri, 2 May 2003 14:19:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BfAl-0004wO-00 for multi6-data@psg.com; Fri, 02 May 2003 18:22:15 +0000 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.36 #1) id 19BfAi-0004vw-00 for multi6@ops.ietf.org; Fri, 02 May 2003 18:22:12 +0000 Received: (qmail 10183 invoked by uid 0); 2 May 2003 18:22:11 -0000 Received: from localhost.automagic.org (HELO isc.org) (root@127.0.0.1) by localhost.automagic.org with SMTP; 2 May 2003 18:22:11 -0000 Date: Fri, 2 May 2003 14:22:10 -0400 Subject: Re: updating GSE for the new millennium Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: David Conrad , multi6@ops.ietf.org To: Brian E Carpenter From: Joe Abley In-Reply-To: <3EB280A1.73BF21CD@hursley.ibm.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, May 2, 2003, at 10:28 Canada/Eastern, Brian E Carpenter wrote: > David Conrad wrote: > ... >> With regards to maintaining the mapping table, I see two generic ways >> of doing this, either pushing data out like routing protocols or >> pulling data in on demand like the DNS. Both are (obviously) >> tractable >> and both have advantages and disadvantages. For obvious reasons I >> like >> the DNS model (not necessarily the DNS itself), but I see this is a >> side (albeit important) issue to the underlying architecture. > > No, I don't think it's a side issue. DNS brings the risk of a big-time > circular dependency. In fact, Jon Postel thought about this one: he > contributed the following to RFC 1958: > > 3.11 Circular dependencies must be avoided. > > For example, routing must not depend on look-ups in the Domain > Name System (DNS), since the updating of DNS servers depends on > successful routing. Some circular dependencies can be managed, however. The DNS itself contains a circular dependency; a resolver can't find a true current set of authoritative nameservers for the root without asking a question of a root server. In this case we make do with a hints file which doesn't need to contain a true current set of NS records; it just needs a set which is good enough to find at least one root nameserver. So a solution which provided basic connectivity and sub-optimal routing for bootstrap purposes might be ok, if that connectivity and routing could be subsequently refined and optimised by some dependent infrastructure. For example, a site might bootstrap itself as single-homed, ignoring all but one of the diverse paths available to connect itself to the rest of the world, and only become really multi-homed once it had used its single-homed access to look up some supporting data (using the DNS or something). Joe From owner-multi6@ops.ietf.org Fri May 2 16:07:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00375 for ; Fri, 2 May 2003 16:07:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Bgq8-00012i-00 for multi6-data@psg.com; Fri, 02 May 2003 20:09:04 +0000 Received: from mail2.microsoft.com ([131.107.3.124]) by psg.com with esmtp (Exim 3.36 #1) id 19Bgpx-0000uY-00 for multi6@ops.ietf.org; Fri, 02 May 2003 20:08:53 +0000 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Fri, 2 May 2003 13:08:52 -0700 Received: from 157.54.5.25 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 02 May 2003 13:08:51 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 2 May 2003 13:08:49 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 2 May 2003 13:08:48 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Fri, 2 May 2003 13:08:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IETF multihoming powder: just add IPv6 and stir Date: Fri, 2 May 2003 13:08:49 -0700 Message-ID: Thread-Topic: IETF multihoming powder: just add IPv6 and stir Thread-Index: AcMQrLQKthXukw3URcaVjRuOOWJpDwAONqsw From: "Christian Huitema" To: "Iljitsch van Beijnum" , "Kurt Erik Lindqvist" Cc: X-OriginalArrivalTime: 02 May 2003 20:08:49.0362 (UTC) FILETIME=[A5055B20:01C310E6] X-Spam-Status: No, hits=-10.4 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA00375 > > I am not sure I want to say that we recharter to the GSE++ model. I > > think we need to recharter mainly to update the milestones and also to > > perhaps change the charter somewhat. > > Ok, the charter isn't the most important thing, what we want to > accomplish is. Frankly, I don't believe that there is all that much value in the so-called "GSE++" model. I see many shortfalls: 1) Rewriting addresses in the site exit routers deprives smart hosts from the capacity to select their preferred return path; 2) There is a lot of ambiguity as to whether the proposed identifiers relate to an interface, a host or a session, and these choices lead to extremely different trade-offs; 3) We know from previous discussion that 64 bits is too short for a randomly assigned global space; 4) It is kind of too late to rewrite the TCP implementations that are already out there. In fact, if we really want to go towards this independent identifier path, I believe we should make it a session identifier, used by some form of TCP++. Using it for routing does not appear all that practical. -- Christian Huitema From owner-multi6@ops.ietf.org Fri May 2 16:31:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01406 for ; Fri, 2 May 2003 16:31:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BhA5-0005Xb-00 for multi6-data@psg.com; Fri, 02 May 2003 20:29:41 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19BhA2-0005XH-00 for multi6@ops.ietf.org; Fri, 02 May 2003 20:29:38 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h42KStB31702; Fri, 2 May 2003 23:28:55 +0300 Date: Fri, 2 May 2003 23:28:54 +0300 (EEST) From: Pekka Savola To: Kurt Erik Lindqvist cc: Erik Nordmark , Tim Chown , Subject: Re: Resolving geo discussions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 2 May 2003, Kurt Erik Lindqvist wrote: > >> Instead of reviewing proposals in depth it might make more sense > >> to task somebody with doing a compare and contrast between the > >> different > >> proposals and use such a presentation as the focus for discussion. > >> > >> That approach tends to lead to more focus on the problem and the > >> possible > >> approaches with less of "my proposal is better than yours" type of > >> discussion. > > > > Totally agree here. > > > > We shouldn't discuss proposals, but rather talk in some "meta" > > multihoming level. > > > > We need to have better picture what we want and can do before getting > > down > > to business and digging holes... > > Maybe (most likely) this will be the outcome of Vienna. Still, I feel > that given the time that have passed, and the fact that there are a > number proposals out there, they deserve the chance to present them. I > think I can already guess the outcome of this, but I think that > although we need to agree where to move we also need to listen to > peoples ideas on what the steps are. I personally like the idea of a > number of design teams as a first step. But this is the discussion we > need to have. As long as this doesn't significantly reduce the time available for other issues (as it would seem likely), this approach is OK with me. 5-10 mins per method seems useless to me (you can only present the short version of the method -- which mostly everybody should know already, and there would be little time for discussion). Much better have just one person sum all of them up, and if there are significant updates later, get back to them then. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Fri May 2 16:33:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01477 for ; Fri, 2 May 2003 16:33:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BhGG-0006eo-00 for multi6-data@psg.com; Fri, 02 May 2003 20:36:04 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19BhGD-0006eZ-00 for multi6@ops.ietf.org; Fri, 02 May 2003 20:36:01 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h42KZvK31776; Fri, 2 May 2003 23:35:57 +0300 Date: Fri, 2 May 2003 23:35:56 +0300 (EEST) From: Pekka Savola To: S Woodside cc: multi6@ops.ietf.org Subject: Re: New draft: Now What? In-Reply-To: <4F7509B0-7CC4-11D7-9FA6-000393414368@yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 2 May 2003, S Woodside wrote: > Hi, I have a comment about this draft from the perspective of Community > wireless networks. > > > 3.1.1. Minimal > > > > Very minimal end-sites, such as typical home networks or very small > > enterprises, are quite small and typically do not include mission- > > critical activities. > > Yes, this is true. > > > Naturally, anyone would be willing to achieve multihoming benefits, > > but usually the associated costs, e.g. caused by obtaining physical > > connectivity to two ISPs, do not justify it. > > This is a argument that begs the question "is it expensive". You are > assuming that the answer is yes, but it's not with a CWN, one of the > main points of a CWN is to share bandwidth from people connected to > different ISPs. That's different people, each individually connected to > one ISP, but sharing the traffic between them, in a mesh, or a managed > network, whatever, they are still sharing it. Well, actually the "expensive" factor not real for e.g. many SOHO users. Getting two DSL lines from different providers costs you double the 20-40$ (or whatever). Not a big deal. A problem is that they typically go via the same telco phone lines, so it doesn't really add any L1-L2 redundancy. Using Cable+DSL might be more failure-proof though. However, I'd argue such CWN's could classify themselves as "Small" sites. The terminology and drawing the line is a bit shaky, unfortunately. But the point of the draft basically is that anything of the size "small" (or maybe even "large") or smaller, we *have* to go with multiple PA addresses or stick with multi-connecting, IMHO. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Fri May 2 21:10:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08596 for ; Fri, 2 May 2003 21:10:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BlXm-0000iE-00 for multi6-data@psg.com; Sat, 03 May 2003 01:10:26 +0000 Received: from dhcp1.se.kurtis.pp.se ([195.43.225.70]) by psg.com with esmtp (Exim 3.36 #1) id 19BlXi-0000hN-00 for multi6@ops.ietf.org; Sat, 03 May 2003 01:10:23 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h42LuGTq003827; Fri, 2 May 2003 23:56:16 +0200 (CEST) Date: Fri, 2 May 2003 23:56:08 +0200 Subject: Re: IETF multihoming powder: just add IPv6 and stir Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Iljitsch van Beijnum , multi6@ops.ietf.org To: Joe Abley From: Kurt Erik Lindqvist In-Reply-To: <06A91EE3-7CCA-11D7-AA27-00039312C852@isc.org> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On fredag, maj 2, 2003, at 20:15 Europe/Stockholm, Joe Abley wrote: > > On Friday, May 2, 2003, at 09:09 Canada/Eastern, Iljitsch van Beijnum > wrote: > >> There are quite a few limitations for people that want to multihome >> in v4. Not everyone may be aware of those and subsequently >> underestimate the latent need for multihoming. So it might be good to >> document this after all. > > I am still very happy to collate ideas and edit that document, if > people are happy for me to do so. > > The main reason it stalled last time was that I wasn't happy being the > only one writing down a description of current practices, since many > different people are doing many different things for many different > reasons, and there weren't many contributors to the doc at the time. > It got as far as "rip all the v4 stuff out of the requirements doc > into a separate doc", and that was about it. > If we think that this will actually help us move forward - by all means, I think we should do it. If it is as Iljitsch say, that there are valid and tricky cases that should be documented, maybe we should do that. But I think you have a point in that we then need to get more peole providing feedback. - kurtis - From owner-multi6@ops.ietf.org Fri May 2 21:55:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09084 for ; Fri, 2 May 2003 21:55:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BmH6-000AdN-00 for multi6-data@psg.com; Sat, 03 May 2003 01:57:16 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19BmH4-000AdB-00 for multi6@ops.ietf.org; Sat, 03 May 2003 01:57:14 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h431tuE03898; Sat, 3 May 2003 03:55:56 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sat, 3 May 2003 03:55:54 +0200 Subject: Re: IETF multihoming powder: just add IPv6 and stir Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Kurt Erik Lindqvist" , To: "Christian Huitema" From: Iljitsch van Beijnum In-Reply-To: Message-Id: <5FE92875-7D0A-11D7-8432-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On vrijdag, mei 2, 2003, at 22:08 Europe/Amsterdam, Christian Huitema wrote: > Frankly, I don't believe that there is all that much value in the > so-called "GSE++" model. I see many shortfalls: > 1) Rewriting addresses in the site exit routers deprives smart hosts > from the capacity to select their preferred return path; If I get to multihome but I don't get much say in my return path that's a sacrifice I'm willing to make. However, this is a valid concern so we should see if we can do something about this. > 2) There is a lot of ambiguity as to whether the proposed identifiers > relate to an interface, a host or a session, and these choices lead to > extremely different trade-offs; Can you elaborate? I'd prefer the network to be agnostic about the meaning of identifiers, this is something the hosts can work out for themselves. > 3) We know from previous discussion that 64 bits is too short for a > randomly assigned global space; That's why we have the ++ part in GSE++. :-) I want to make this such that the identifier can be a full 128 bit IPv6 address if desired. > 4) It is kind of too late to rewrite the TCP implementations that are > already out there. That's why we want proxy multihoming agents that can handle all the multihoming processing so there is no need to upgrade existing v6 implementations immediately. > In fact, if we really want to go towards this independent identifier > path, I believe we should make it a session identifier, used by some > form of TCP++. Using it for routing does not appear all that practical. If we get the GSE++ right, it should provide much of the groundwork for upgrading TCP. What do you mean by a "session identifier"? From owner-multi6@ops.ietf.org Fri May 2 22:28:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09829 for ; Fri, 2 May 2003 22:28:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BmRM-000Chl-00 for multi6-data@psg.com; Sat, 03 May 2003 02:07:52 +0000 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 19BmRK-000Ch6-00 for multi6@ops.ietf.org; Sat, 03 May 2003 02:07:50 +0000 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id A56A3137F15; Fri, 2 May 2003 16:22:56 -0700 (PDT) Date: Fri, 2 May 2003 16:22:54 -0700 Subject: Re: IETF multihoming powder: just add IPv6 and stir Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Iljitsch van Beijnum" , "Kurt Erik Lindqvist" , To: "Christian Huitema" From: David Conrad In-Reply-To: Message-Id: <001DB068-7CF5-11D7-AF62-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Christian, On Friday, May 2, 2003, at 01:08 PM, Christian Huitema wrote: > Frankly, I don't believe that there is all that much value in the > so-called "GSE++" model. I see many shortfalls: > > 1) Rewriting addresses in the site exit routers deprives smart hosts > from the capacity to select their preferred return path; To be sure I understand, you are saying that my laptop should have the ability to make a decision as to what ISP Microsoft uses to route packets back to me? > 2) There is a lot of ambiguity as to whether the proposed identifiers > relate to an interface, a host or a session, and these choices lead to > extremely different trade-offs; In the model I've tried to describe, everything from bit 48 to 127 is handled identically as it is handled in the existing IPv6 specifications. Are you indicating those specifications have ambiguity and that a specification for multi-homing should remove that ambiguity? > 3) We know from previous discussion that 64 bits is too short for a > randomly assigned global space; Sorry, must have missed this suggestion. Where would a random 64 bits be used? > 4) It is kind of too late to rewrite the TCP implementations that are > already out there. In the model I've tried to describe, existing host IPv6 stacks would require no changes whatsoever. > In fact, if we really want to go towards this independent identifier > path, I believe we should make it a session identifier, used by some > form of TCP++. While I think TCP++ would be a lovely idea, I don't believe it is realistic unless it incorporates backwards compatibility and if it incorporates backwards compatibility, I don't see how you can get multi-homing without either NAT or rewriting. > Using it for routing does not appear all that practical. Eye of the beholder, I guess. Rgds, -drc From owner-multi6@ops.ietf.org Fri May 2 22:31:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09905 for ; Fri, 2 May 2003 22:31:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Bmq6-000IYX-00 for multi6-data@psg.com; Sat, 03 May 2003 02:33:26 +0000 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.36 #1) id 19Bmq1-000IY9-00 for multi6@ops.ietf.org; Sat, 03 May 2003 02:33:21 +0000 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id MAA10567; Sat, 3 May 2003 12:31:51 +1000 (EST) Date: Sat, 3 May 2003 12:31:51 +1000 (EST) From: Peter Tattam To: Christian Huitema cc: Iljitsch van Beijnum , Kurt Erik Lindqvist , multi6@ops.ietf.org Subject: RE: IETF multihoming powder: just add IPv6 and stir In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Hmm. I really don't want to add fuel to the fire on these issues, but I feel that it is important to respond to these criticisms because I don't agree with the analysis. See the end of the messag for some further comments. On Fri, 2 May 2003, Christian Huitema wrote: > > > I am not sure I want to say that we recharter to the GSE++ model. I > > > think we need to recharter mainly to update the milestones and also > to > > > perhaps change the charter somewhat. > > > > Ok, the charter isn't the most important thing, what we want to > > accomplish is. > > Frankly, I don't believe that there is all that much value in the > so-called "GSE++" model. I see many shortfalls: > > 1) Rewriting addresses in the site exit routers deprives smart hosts > from the capacity to select their preferred return path; I proposed that this only need be done for hosts which are not MH aware. > > 2) There is a lot of ambiguity as to whether the proposed identifiers > relate to an interface, a host or a session, and these choices lead to > extremely different trade-offs; I don't know what you mean by this. I thought they referred to whole sites. > > 3) We know from previous discussion that 64 bits is too short for a > randomly assigned global space; I thought we were talking about a M + S + 64 bits address space where the M bits can be guaranteed globally unique and the S bits are managed by the site. For the purposes of global routing, this is unique enough to guarantee no collisions. The uniqueness of the 64 bits within the local segment are managed by existing mechanisms of address autoconfig. > > 4) It is kind of too late to rewrite the TCP implementations that are > already out there. Yes, but such a proposal can work with mixed TCP implementations. The only difference between the two is whether to modify addresses at the edge or in the stack. I'm sure there must be a way to arrange it so that the end hosts can choose to do the translation themselves. > > In fact, if we really want to go towards this independent identifier > path, I believe we should make it a session identifier, used by some > form of TCP++. Using it for routing does not appear all that practical. > > -- Christian Huitema > > > I might add an out of band comment about the political issues surround this whole MH debate. I am agnostic about which proposal(s) make it and at the end of the day will support whatever proposal is chosen. I haven't got the time (I have plenty of other work to do) or money (can't afford to go to IETF meetings) to be an activist for any particular proposal and I don't need the karma points for my career. All I care about is whether in 10 or 20 years time that whatever's in place will work well and history will show that the right decision was made. It's for these very reasons that I haven't invested a great amount of time into a formal proposal that everyone can pull apart. I am happy to throw ideas into the arena and chew them over, but until a firm direction is established and there is overwhelming support for that direction I'm reluctant to spend any more time than is necessary on the debate. Regards Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From owner-multi6@ops.ietf.org Sat May 3 07:43:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28071 for ; Sat, 3 May 2003 07:43:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BvRo-000ObO-00 for multi6-data@psg.com; Sat, 03 May 2003 11:44:56 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19BvRm-000ObB-00 for multi6@ops.ietf.org; Sat, 03 May 2003 11:44:54 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h43BhZE07008; Sat, 3 May 2003 13:43:35 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sat, 3 May 2003 13:43:34 +0200 Subject: IPv4 multihoming limitations Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Kurt Erik Lindqvist , multi6@ops.ietf.org To: Joe Abley From: Iljitsch van Beijnum In-Reply-To: <06A91EE3-7CCA-11D7-AA27-00039312C852@isc.org> Message-Id: <78B7F017-7D5C-11D7-989F-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-28.3 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On vrijdag, mei 2, 2003, at 20:15 Europe/Amsterdam, Joe Abley wrote: >> There are quite a few limitations for people that want to multihome >> in v4. Not everyone may be aware of those and subsequently >> underestimate the latent need for multihoming. So it might be good to >> document this after all. > I am still very happy to collate ideas and edit that document, if > people are happy for me to do so. Ok, here is some text: The preferred way to multihome in IPv4 is to announce an independent block of address space over two or more ISPs using BGP. Until the mid-1990s this was relatively easy to accomplish, as the maximum generally accepted prefix length in the global routing table was a /24, and little justification was needed to receive a /24. However, in 1995 the growth of the global routing table became a problem once again, and as a result Sprint decided to start filtering prefixes it accepted from peers based on prefix length. This broke the expectation that a multihomed network announcing a /24, regardless of where in the IPv4 address space this /24 was taken from, would be globally reachable. Over the course of the next several years, filtering on Regional Internet Registry allocation boundaries became accepted, if not widespread, practice. As of the late 1990s the RIRs allocate address space to those requesting it from them directly (mostly ISPs) in blocks of at least a /20. The address space in 192.0.0.0/8 and part of 193.0.0.0/8 was allocated before CIDR was developed so it still contains a large number of much smaller blocks. This part of the IPv4 address space is often called "the swamp". The networks that filter on prefix length typically accept much larger prefixes from swamp space. In the mean time, RIR address distribution policies became increasingly more restrictive. The result of these two developments is that it is nearly impossible for an non-ISP organization to obtain a large enough block of address space to be sure its BGP announcement isn't filtered. Multihomers are often forced to work around this by taking regular provider aggregatable (PA) rather than the traditional provider-independent (PI) address space from one of their ISPs and announce this prefix to two ISPs. In theory, announcing this prefix to the secondary ISP would be enough as reachability over the primary ISP is assured by the aggregate this ISP announces. However, due to the "longest match first" rule, traffic would exclusively flow over the path with the longer prefix. So in practice the multihomer announces the longer prefix both over the ISP that announces the aggregate and over one or more secondary ISPs. This practice has two advantages and one disadvantage for the multihomed network. The first advantage is that they can obtain a much smaller block of address space from an ISP than from a RIR. (Would-be multihomers still often optimize their networks for qualifying for at least a /24 by adopting accepted but relatively wasteful address deployment strategies.) The second advantage is that even if their announcement is filtered, they are still reachable over the primary ISP by virtue of the aggregate announced by this ISP. Even when the circuit to the primary ISP is down, this often works because the primary ISP will generally accept the announcement over the secondary ISP, so traffic flows from the filtering network to the primary ISP and then to the secondary ISP in order to arrive at the multihomed network. The disadvantage is that the multihomed network must depend on the primary ISP for the aggregate. If the primary ISP goes down, this will impact reachability to networks that filter. And when the multihomed network leaves the primary ISP, they are generally expected to return the address space because otherwise this ISP would have to route traffic for a non-customer. Most ISPs will cooperate with this "shooting holes in an aggregate" solution to multihoming, but some are reluctant. From owner-multi6@ops.ietf.org Sat May 3 08:16:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28387 for ; Sat, 3 May 2003 08:16:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BvyO-0007kt-00 for multi6-data@psg.com; Sat, 03 May 2003 12:18:36 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19BvyJ-0007Ys-00 for multi6@ops.ietf.org; Sat, 03 May 2003 12:18:31 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h43CHCE07053; Sat, 3 May 2003 14:17:13 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sat, 3 May 2003 14:17:11 +0200 Subject: Re: IETF multihoming powder: just add IPv6 and stir Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Christian Huitema" , "Kurt Erik Lindqvist" , To: David Conrad From: Iljitsch van Beijnum In-Reply-To: <001DB068-7CF5-11D7-AF62-000393DB42B2@nominum.com> Message-Id: <2B1035C1-7D61-11D7-989F-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On zaterdag, mei 3, 2003, at 01:22 Europe/Amsterdam, David Conrad wrote: >> 1) Rewriting addresses in the site exit routers deprives smart hosts >> from the capacity to select their preferred return path; > To be sure I understand, you are saying that my laptop should have the > ability to make a decision as to what ISP Microsoft uses to route > packets back to me? Just because that's the way it's done today doesn't mean it has to continue to be done like that in the future. Consider: +-- ISP B --- ISP C --+ DC \ / | | / \ MS +-- ISP A --- ISP D --+ This makes for four possible paths from you to Microsoft: DC -> B -> C -> MS DC -> B -> D -> MS DC -> A -> C -> MS DC -> A -> D -> MS Conversely, there are four paths back. If we get to choose paths on a per-session basis, this makes for no less than sixteen possible permutations. (Of course this assumes transport sessions don't care about the source and/or destination addresses.) This makes for an interesting problem. On the one hand, we want to be able to take advantage of whathever capacity is available. On the other hand, managing n^2*m^2 paths (where n and m are the number of ISPs/addresses on each end) isn't an attractive proposition. >> In fact, if we really want to go towards this independent identifier >> path, I believe we should make it a session identifier, used by some >> form of TCP++. > While I think TCP++ would be a lovely idea, I don't believe it is > realistic unless it incorporates backwards compatibility and if it > incorporates backwards compatibility, I don't see how you can get > multi-homing without either NAT or rewriting. I don't see much of a problem here. In order to be compatible, the first packet must comply with existing TCP semantics but in a way that signals that the session initiator supports the ++ extensions. Then either the receiver answers with a regular SYN/ACK and we do regular TCP, or the receiver answers with a TCP++ session init packet and we don't have to be compatible any more. (Middleboxes won't like this, though.) From owner-multi6@ops.ietf.org Sat May 3 17:37:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09424 for ; Sat, 3 May 2003 17:37:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19C4im-000M19-00 for multi6-data@psg.com; Sat, 03 May 2003 21:39:04 +0000 Received: from [2002:c08b:2e21:3:250:baff:fe2d:b704] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.36 #1) id 19C4ih-000M0w-00 for multi6@ops.ietf.org; Sat, 03 May 2003 21:39:01 +0000 Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h43LXMU00478 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Sat, 3 May 2003 17:33:24 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h43LYKA14188 for ; Sat, 3 May 2003 17:34:21 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h43LXKUA008419 for ; Sat, 3 May 2003 17:33:20 -0400 Message-Id: <200305032133.h43LXKUA008419@sandelman.ottawa.on.ca> To: multi6@ops.ietf.org Subject: Re: updating GSE for the new millennium In-reply-to: Your message of "Fri, 02 May 2003 14:22:10 EDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sat, 03 May 2003 17:33:19 -0400 From: Michael Richardson X-Spam-Status: No, hits=-18.2 required=5.0 tests=BAYES_01,IN_REP_TO,PGP_SIGNATURE,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Joe is absolutely on the right path. > contributed the following to RFC 1958: > > 3.11 Circular dependencies must be avoided. > > For example, routing must not depend on look-ups in the Domain > Name System (DNS), since the updating of DNS servers depends on > successful routing And if you change this to: > For example, core default free routing must not depend on look-ups in > the Domain Name System (DNS), since the updating of DNS servers depends > on successful defaul free routing Long ago there was a discussion about whether or not DNS servers were things that needed to be multihomed - the answer was that they were not. One does far better with multiple DNS servers on unique PA addresses. DNS already deals with failover, etc... ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPrQ1noqHRg3pndX9AQHv3AQAxEjFFT5i5nuNorEJaexeB28KxtUn+XTw Bky8s56cFGl8o6+oigxAQ0Z/EtcnUdJCrJsifxArQtwBzlSmqkR16sQcybdKlEjB +/tNYDQvVO68CW2TNwHI37KzzFp+K+tNNSR6SQ/HMXXiqnix466+U4Ni1kvL99NV w0LOMZx0/xI= =6cUF -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Sat May 3 20:07:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11822 for ; Sat, 3 May 2003 20:07:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19C73t-0007i3-00 for multi6-data@psg.com; Sun, 04 May 2003 00:09:01 +0000 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #1) id 19C73q-0007hn-00 for multi6@ops.ietf.org; Sun, 04 May 2003 00:08:58 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 9868223C3B; Sat, 3 May 2003 16:57:40 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h4408tYB009585; Sat, 3 May 2003 17:08:55 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: updating GSE for the new millennium Date: Sat, 3 May 2003 17:08:55 -0700 Message-ID: Thread-Topic: updating GSE for the new millennium Thread-Index: AcMRvpysH92USwZBRYKW+Xgm6t0ocAAEqpnQ From: "Tony Li" To: "Michael Richardson" , X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA11822 Root name servers are also a service deserving of anycast addresses. Tony | Joe is absolutely on the right path. | | > contributed the following to RFC 1958: | > | > 3.11 Circular dependencies must be avoided. | > | > For example, routing must not depend on look-ups | in the Domain | > Name System (DNS), since the updating of DNS | servers depends on | > successful routing | | And if you change this to: | | > For example, core default free routing must not | depend on look-ups in | > the Domain Name System (DNS), since the updating | of DNS servers depends | > on successful defaul free routing | | Long ago there was a discussion about whether or not DNS | servers were | things that needed to be multihomed - the answer was that | they were not. | | One does far better with multiple DNS servers on unique PA | addresses. | DNS already deals with failover, etc... | | ] ON HUMILITY: to err is human. To moo, bovine. | | firewalls [ | ] Michael Richardson, Sandelman Software Works, Ottawa, | ON |net architect[ | ] mcr@sandelman.ottawa.on.ca | http://www.sandelman.ottawa.on.ca/ |device | driver[ | ] | panic("Just another Debian GNU/Linux using, kernel | hacking, security guy"); [ | | | | | -----BEGIN PGP SIGNATURE----- | Version: GnuPG v1.0.7 (GNU/Linux) | Comment: Finger me for keys | | iQCVAwUBPrQ1noqHRg3pndX9AQHv3AQAxEjFFT5i5nuNorEJaexeB28KxtUn+XTw | Bky8s56cFGl8o6+oigxAQ0Z/EtcnUdJCrJsifxArQtwBzlSmqkR16sQcybdKlEjB | +/tNYDQvVO68CW2TNwHI37KzzFp+K+tNNSR6SQ/HMXXiqnix466+U4Ni1kvL99NV | w0LOMZx0/xI= | =6cUF | -----END PGP SIGNATURE----- | | From owner-multi6@ops.ietf.org Sat May 3 20:11:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11864 for ; Sat, 3 May 2003 20:11:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19C78V-0007uI-00 for multi6-data@psg.com; Sun, 04 May 2003 00:13:47 +0000 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #1) id 19C78U-0007u5-00 for multi6@ops.ietf.org; Sun, 04 May 2003 00:13:46 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 23B2523C3B; Sat, 3 May 2003 17:02:30 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h440DVYB009748; Sat, 3 May 2003 17:13:41 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IETF multihoming powder: just add IPv6 and stir Date: Sat, 3 May 2003 17:13:31 -0700 Message-ID: Thread-Topic: IETF multihoming powder: just add IPv6 and stir Thread-Index: AcMRb0I9yhoq3rGzRQePR82Jq4yVlQAYhy9w From: "Tony Li" To: "Iljitsch van Beijnum" , "David Conrad" Cc: "Christian Huitema" , "Kurt Erik Lindqvist" , X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA11864 | >> 1) Rewriting addresses in the site exit routers | deprives smart hosts | >> from the capacity to select their preferred return path; | | > To be sure I understand, you are saying that my laptop | should have the | > ability to make a decision as to what ISP Microsoft uses | to route | > packets back to me? | | Just because that's the way it's done today doesn't mean it has to | continue to be done like that in the future. If you follow this argument a bit further, the number of possible paths internal to the core explodes. There is no way to completely specify the path of a packet without a connection oriented setup protocol. Further, unless one wants to sever the loose coupling between the routing subsystem and the host, it's not going to be possible to specify even a partial path. Frankly, there's no way to reasonably support a host path selection feature in the Internet architecture. Tony From owner-multi6@ops.ietf.org Sat May 3 21:53:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12717 for ; Sat, 3 May 2003 21:53:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19C8h9-000CmO-00 for multi6-data@psg.com; Sun, 04 May 2003 01:53:39 +0000 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 19C8gy-000Clw-00 for multi6@ops.ietf.org; Sun, 04 May 2003 01:53:28 +0000 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h441rQtU004588; Sat, 3 May 2003 21:53:26 -0400 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id h441rQ27004587; Sat, 3 May 2003 21:53:26 -0400 Date: Sat, 3 May 2003 21:53:26 -0400 From: "J. Noel Chiappa" Message-Id: <200305040153.h441rQ27004587@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: RE: IETF multihoming powder: just add IPv6 and stir Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: "Tony Li" > If you follow this argument a bit further, the number of possible paths > internal to the core explodes. > ... > Frankly, there's no way to reasonably support a host path selection > feature in the Internet architecture. Sorry, but this assertion is not correct. It's true that one cannot support separate state for each individual flow in the core of the network. Hoever, this does not mean that one cannot support host path selection, both setup and non-setup (i.e. completely done by the header of each individual packet). The problems involved in some of the simplistic approaches to doing host path selection were brought to my attention many years ago; the first being the one that you actually (if my memory serves at this great distance) introduced me to, the necessity to scale router state, as explained in this note: http://users.exis.net/~jnc/tech/state_growth.html There's another related problem with flow setup even with aggregated flows, which Vadim Antonov first explained to me, which is more of an O(N) problem at the edges, related to the growth of the overall network. In any event, after much thought, I've come up with a number of mechanisms that allow you to provide host path selection in a feasible manner. One can do a certain amount with address selection - there'a grad student at MIT called Xiaowei Yang who's doing a PhD on that. I don't happen to like that approach, I'm not really sure sure why - probably because it feels like a kludge. However, with a certain amount of cleverness, and also trading off per-packet header overhead to reduce per-flow state in the switches, one can do an amazing amount. I don't want to bore everyone with a long explanation, and sorry, no it's not written down, but very briefly, it all depends on having virtual links in the topology map which correspond to instantiated aggregated flows (and recursively so). You can either do an end-end flow setup which uses those virtual links (and the flow stack in the packet header), or you can play all sorts of interesting tricks with the flow stack to cause packets to take paths composed of those virtual links, or you can do a mixture of the two. I not sure if I have that problem Vadim identified with the full-blown flow-setup case completely licked, but I have some ideas which I think will do it. > There is no way to completely specify the path of a packet without a > connection oriented setup protocol. Source route in the header? Noel From owner-multi6@ops.ietf.org Sat May 3 22:53:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13184 for ; Sat, 3 May 2003 22:53:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19C9er-000Ghe-00 for multi6-data@psg.com; Sun, 04 May 2003 02:55:21 +0000 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #1) id 19C9ep-000GhR-00 for multi6@ops.ietf.org; Sun, 04 May 2003 02:55:19 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 9A70B34443; Sat, 3 May 2003 19:09:29 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h442tIYB013075; Sat, 3 May 2003 19:55:18 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IETF multihoming powder: just add IPv6 and stir Date: Sat, 3 May 2003 19:55:18 -0700 Message-ID: Thread-Topic: IETF multihoming powder: just add IPv6 and stir Thread-Index: AcMR4ve2Q75sT8nPT2Oo6DzRsza+4AABV63A From: "Tony Li" To: "J. Noel Chiappa" , X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA13184 Noel, The architecture that you describe is no longer the Internet architecture. Yes, ok, it's sorta vaguely like it, but it is NOT the architecture that folks have in mind when they say that they want to preserve host path selection. Or have 'smart' hosts. Putting a source route in the header (or deeper) in the packet has been tried and firmly rejected. People want the ability to select paths, but are unwilling to pay for it. Tony | -----Original Message----- | From: J. Noel Chiappa [mailto:jnc@ginger.lcs.mit.edu] | Sent: Saturday, May 03, 2003 6:53 PM | To: multi6@ops.ietf.org | Cc: jnc@ginger.lcs.mit.edu | Subject: RE: IETF multihoming powder: just add IPv6 and stir | | | > From: "Tony Li" | | > If you follow this argument a bit further, the | number of possible paths | > internal to the core explodes. | > ... | > Frankly, there's no way to reasonably support a host | path selection | > feature in the Internet architecture. | | Sorry, but this assertion is not correct. | | It's true that one cannot support separate state for each | individual flow in | the core of the network. Hoever, this does not mean that | one cannot support | host path selection, both setup and non-setup (i.e. | completely done by the | header of each individual packet). | | The problems involved in some of the simplistic approaches | to doing host path | selection were brought to my attention many years ago; the | first being the one | that you actually (if my memory serves at this great | distance) introduced me | to, the necessity to scale router state, as explained in this note: | | http://users.exis.net/~jnc/tech/state_growth.html | | There's another related problem with flow setup even with | aggregated flows, | which Vadim Antonov first explained to me, which is more | of an O(N) problem at | the edges, related to the growth of the overall network. | | | In any event, after much thought, I've come up with a | number of mechanisms | that allow you to provide host path selection in a feasible manner. | | One can do a certain amount with address selection - | there'a grad student at | MIT called Xiaowei Yang who's doing a PhD on that. I don't | happen to like | that approach, I'm not really sure sure why - probably | because it feels like | a kludge. | | However, with a certain amount of cleverness, and also | trading off per-packet | header overhead to reduce per-flow state in the switches, | one can do an | amazing amount. | | I don't want to bore everyone with a long explanation, and | sorry, no it's not | written down, but very briefly, it all depends on having | virtual links in the | topology map which correspond to instantiated aggregated flows (and | recursively so). You can either do an end-end flow setup | which uses those | virtual links (and the flow stack in the packet header), | or you can play all | sorts of interesting tricks with the flow stack to cause | packets to take paths | composed of those virtual links, or you can do a mixture | of the two. | | I not sure if I have that problem Vadim identified with | the full-blown | flow-setup case completely licked, but I have some ideas | which I think will | do it. | | | > There is no way to completely specify the path of a | packet without a | > connection oriented setup protocol. | | Source route in the header? | | Noel | | From owner-multi6@ops.ietf.org Sun May 4 00:19:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14016 for ; Sun, 4 May 2003 00:19:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CAzA-000MMq-00 for multi6-data@psg.com; Sun, 04 May 2003 04:20:24 +0000 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 19CAz4-000MKH-00 for multi6@ops.ietf.org; Sun, 04 May 2003 04:20:21 +0000 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h444KHtU005034; Sun, 4 May 2003 00:20:17 -0400 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id h444KGcA005031; Sun, 4 May 2003 00:20:16 -0400 Date: Sun, 4 May 2003 00:20:16 -0400 From: "J. Noel Chiappa" Message-Id: <200305040420.h444KGcA005031@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: RE: IETF multihoming powder: just add IPv6 and stir Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: "Tony Li" >>> Frankly, there's no way to reasonably support a host path selection >>> feature in the Internet architecture. > The architecture that you describe is no longer the Internet > architecture. Doing much of anything interesting within the current architecture, exactly as it stands, in many cases isn't really possible. (E.g. the many people who'd like to separate location and identity to make multi-homing easier.) Hence I didn't realize that when you said "in the Internet architecture" you really meant "in the Internet architecture as it currently stands", since that latter case is a relatively sterile and pointless one. > People want the ability to select paths, but are unwilling to pay for > it. I have been aware for some decades now that people want filet mignon from the network, and expect to get it for the price they've previously been paying for hamburger. That has been painfully demonstrated in the routing area - which is a good part of why I never bothered to write down how to do all this. They seem to have forgotten the common principle of TANSTAAFL - one which they are only now slowly accepting in the area of multi-homing (and even in that sphere there are still lots of people who don't get it). Noel From owner-multi6@ops.ietf.org Sun May 4 05:27:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27783 for ; Sun, 4 May 2003 05:27:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CFnX-000Nn1-00 for multi6-data@psg.com; Sun, 04 May 2003 09:28:43 +0000 Received: from mail-gw1.hursley.ibm.com ([194.196.110.15]) by psg.com with esmtp (Exim 3.36 #1) id 19CFnU-000Nmb-00 for multi6@ops.ietf.org; Sun, 04 May 2003 09:28:40 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19CFnT-0002Se-00 for multi6@ops.ietf.org; Sun, 04 May 2003 10:28:39 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19CFnT-0002SZ-00 for multi6@ops.ietf.org; Sun, 04 May 2003 10:28:39 +0100 Received: from hursley.ibm.com (gsine08.us.sine.ibm.com [9.14.6.48]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id KAA32994 for ; Sun, 4 May 2003 10:28:37 +0100 Message-ID: <3EB4DD66.F430246@hursley.ibm.com> Date: Sun, 04 May 2003 11:29:10 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: Re: updating GSE for the new millennium References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Indeed. Getting back to GSE, I think the question we have to ask about any solution is: how would we bootstrap the Internet, or a large portion of it, if the power went off everywhere for a while? If the solution isn't robust in that case (e.g. due to circular dependencies) then it doesn't measure up. As Tony said, you can arrange things so that DNS-based GSE doesn't create circularity, but only if you think about it. Brian Tony Li wrote: > > Root name servers are also a service deserving of anycast > addresses. > > Tony > > | Joe is absolutely on the right path. > | > | > contributed the following to RFC 1958: > | > > | > 3.11 Circular dependencies must be avoided. > | > > | > For example, routing must not depend on look-ups > | in the Domain > | > Name System (DNS), since the updating of DNS > | servers depends on > | > successful routing > | > | And if you change this to: > | > | > For example, core default free routing must not > | depend on look-ups in > | > the Domain Name System (DNS), since the updating > | of DNS servers depends > | > on successful defaul free routing > | > | Long ago there was a discussion about whether or not DNS > | servers were > | things that needed to be multihomed - the answer was that > | they were not. > | > | One does far better with multiple DNS servers on unique PA > | addresses. > | DNS already deals with failover, etc... > | > | ] ON HUMILITY: to err is human. To moo, bovine. > | | firewalls [ > | ] Michael Richardson, Sandelman Software Works, Ottawa, > | ON |net architect[ > | ] mcr@sandelman.ottawa.on.ca > | http://www.sandelman.ottawa.on.ca/ |device | driver[ > | ] > | panic("Just another Debian GNU/Linux using, kernel > | hacking, security guy"); [ > | > | From owner-multi6@ops.ietf.org Sun May 4 06:12:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28053 for ; Sun, 4 May 2003 06:12:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CGVY-0002yg-00 for multi6-data@psg.com; Sun, 04 May 2003 10:14:12 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19CGVU-0002y8-00 for multi6@ops.ietf.org; Sun, 04 May 2003 10:14:08 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h44ACoE08787; Sun, 4 May 2003 12:12:50 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sun, 4 May 2003 12:12:48 +0200 Subject: Re: IETF multihoming powder: just add IPv6 and stir Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Tony Li" From: Iljitsch van Beijnum In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-28.3 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On zondag, mei 4, 2003, at 02:13 Europe/Amsterdam, Tony Li wrote: > | > To be sure I understand, you are saying that my laptop > | > should have the ability to make a decision as to what > | > ISP Microsoft uses to route packets back to me? > | Just because that's the way it's done today doesn't mean it has to > | continue to be done like that in the future. > If you follow this argument a bit further, the number of possible > paths internal to the core explodes. There is no way to completely > specify the path of a packet without a connection oriented setup > protocol. It was not my intention to suggest we start building X.25 networks. Even if we define a path as a combination of source ISP and destination ISP, the number of possible paths quickly increases with the number of ISPs used by both ends. I don't think it would be all that useful to differentiate between different paths through the core for a single source/dest combination: traditional mechanisms work well here. > Frankly, there's no way to reasonably support a host path selection > feature in the Internet architecture. Having hosts select paths through the core would be a solution in search of a problem. Having hosts select the optimum combination of source and destination addresses = source and destination ISPs would be a useful feature, if not one that is trivial to implement. Today, we don't have this feature, but we depend on routing to select a single path that is good enough. If it isn't, BGP provides a good number of knobs to manually influence this. As soon as we start giving hosts multiple addresses we open the door to all kinds of suboptimal and even pathalogical behavior. The current rules for source address selection only make this worse because in an attempt to do the right thing, they may succeed in consistently doing the wrong thing, rather than just doing the wrong thing once or twice and then try something else. (Side note: I had to go back to a single IPv6 prefix after experimenting with having two because there was no way I could make my hosts use the right source addresses.) For long-lived sessions, it would be appropriate to go through a somewhat lengthy discovery process where different source/dest combinations are tried and eventually the best combination is adopted. (But this should happen "in the background" while communication is already happening.) For more ephemeral sessions or sessions that can't switch addresses, it is very important to select a good enough path: it doesn't have to be the best, as long as it's not the worst. I'm afraid there is no way to accomplish this without prior knowledge. It might seem like a good idea to import routing information for this purpose but that doesn't help much because this only deals with aggregates. I don't think we can get around this problem without incorporating a discovery phase where a host tries something to see if it works. Fortunately, for the source address, where this problem is most pressing, we should be able to use ICMP messages to quickly determine that something doesn't work. (Use source address in prefix A but router wants to send the packet to ISP B -> ICMP administratively prohibited within a few ms.) For the destination address, it might be workable to used send a connection request to several addresses and complete the session setup with the address that replies quickest. From owner-multi6@ops.ietf.org Sun May 4 07:24:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28576 for ; Sun, 4 May 2003 07:24:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CHd5-000BDB-00 for multi6-data@psg.com; Sun, 04 May 2003 11:26:03 +0000 Received: from dhcp1.se.kurtis.pp.se ([195.43.225.70]) by psg.com with esmtp (Exim 3.36 #1) id 19CHd3-000BCv-00 for multi6@ops.ietf.org; Sun, 04 May 2003 11:26:01 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h44BSKTq004660; Sun, 4 May 2003 13:28:20 +0200 (CEST) Date: Sun, 4 May 2003 13:28:15 +0200 Subject: Re: IETF multihoming powder: just add IPv6 and stir Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Iljitsch van Beijnum" , To: "Christian Huitema" From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <7F6D4AE8-7E23-11D7-92E2-000393520ED8@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-15.3 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> I am not sure I want to say that we recharter to the GSE++ model. I >>> think we need to recharter mainly to update the milestones and also > to >>> perhaps change the charter somewhat. >> >> Ok, the charter isn't the most important thing, what we want to >> accomplish is. > > Frankly, I don't believe that there is all that much value in the > so-called "GSE++" model. I see many shortfalls: There are shortfalls with all the solutions. As Iljitsch noted, this does not have to mean that we depreciate all the others. - kurtis - From owner-multi6@ops.ietf.org Sun May 4 07:41:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28689 for ; Sun, 4 May 2003 07:41:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CHu6-000DIU-00 for multi6-data@psg.com; Sun, 04 May 2003 11:43:38 +0000 Received: from dhcp1.se.kurtis.pp.se ([195.43.225.70]) by psg.com with esmtp (Exim 3.36 #1) id 19CHu2-000DIE-00 for multi6@ops.ietf.org; Sun, 04 May 2003 11:43:35 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h44BjmTq004673; Sun, 4 May 2003 13:45:49 +0200 (CEST) Date: Sun, 4 May 2003 13:45:41 +0200 Subject: Re: IETF multihoming powder: just add IPv6 and stir Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: "J. Noel Chiappa" From: Kurt Erik Lindqvist In-Reply-To: <200305040153.h441rQ27004587@ginger.lcs.mit.edu> Message-Id: X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA28689 On söndag, maj 4, 2003, at 03:53 Europe/Stockholm, J. Noel Chiappa wrote: > > However, with a certain amount of cleverness, and also trading off > per-packet > header overhead to reduce per-flow state in the switches, one can do an > amazing amount. > > I don't want to bore everyone with a long explanation, and sorry, no > it's not > written down, but very briefly, it all depends on having virtual links > in the > topology map which correspond to instantiated aggregated flows (and > recursively so). You can either do an end-end flow setup which uses > those > virtual links (and the flow stack in the packet header), or you can > play all > sorts of interesting tricks with the flow stack to cause packets to > take paths > composed of those virtual links, or you can do a mixture of the two. > > I not sure if I have that problem Vadim identified with the full-blown > flow-setup case completely licked, but I have some ideas which I think > will > do it. > Don't get me wrong here, but on first read-through, isn't what you are describing MPLS? - kurtis - From owner-multi6@ops.ietf.org Sun May 4 11:11:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01663 for ; Sun, 4 May 2003 11:11:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CL9f-000DTW-00 for multi6-data@psg.com; Sun, 04 May 2003 15:11:55 +0000 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 19CL9d-000DTI-00 for multi6@ops.ietf.org; Sun, 04 May 2003 15:11:53 +0000 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h44FBptU007169; Sun, 4 May 2003 11:11:51 -0400 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id h44FBoMU007168; Sun, 4 May 2003 11:11:50 -0400 Date: Sun, 4 May 2003 11:11:50 -0400 From: "J. Noel Chiappa" Message-Id: <200305041511.h44FBoMU007168@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: IETF multihoming powder: just add IPv6 and stir Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_20 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Kurt Erik Lindqvist >> it all depends on having virtual links in the topology map which >> correspond to instantiated aggregated flows (and recursively so). You >> can either do an end-end flow setup which uses those virtual links >> .. or you can play all sorts of interesting tricks with the flow stack >> to cause packets to take paths composed of those virtual links, or you >> can do a mixture of the two. > isn't what you are describing MPLS? Well, they both forward packets based on a flow label, and there's a stack of flow labels, but that's about the only similarity. In other words, it's like saying that because a SPARC and a Pentium are both stored-program machines they are the same thing. MPLS is a lot more than the hardware (which I kind of like); it's also a whole bunch of sofware and protocols (all of which I think is bletcherous junk, and horrible "bag on the side of the architecture"). If you examine just my text above, you will find a number of major differences: e.g. the use of a map-based routing system in which some previously-set-up flows are actually shown (as virtual links); the fact that packets can be created with a whole bunch of labels in the flow stack, and that this feature is available to users, etc, etc. But this is all kind of irrelevant to Multi6; as Tony correctly points out, I'm talking about an alternate reality in which the complete piece of nonfunctional junk masquerading as our routing architecture has been put out of our misery. Noel From owner-multi6@ops.ietf.org Sun May 4 11:29:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01805 for ; Sun, 4 May 2003 11:29:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CLTU-000GAR-00 for multi6-data@psg.com; Sun, 04 May 2003 15:32:24 +0000 Received: from dhcp1.se.kurtis.pp.se ([195.43.225.70]) by psg.com with esmtp (Exim 3.36 #1) id 19CLTR-000G4h-00 for multi6@ops.ietf.org; Sun, 04 May 2003 15:32:22 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h44FYfTq004729; Sun, 4 May 2003 17:34:41 +0200 (CEST) Date: Sun, 4 May 2003 17:34:36 +0200 Subject: Re: IETF multihoming powder: just add IPv6 and stir Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: "J. Noel Chiappa" From: Kurt Erik Lindqvist In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-16.1 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> However, with a certain amount of cleverness, and also trading off >> per-packet >> header overhead to reduce per-flow state in the switches, one can do >> an >> amazing amount. >> >> I don't want to bore everyone with a long explanation, and sorry, no >> it's not >> written down, but very briefly, it all depends on having virtual >> links in the >> topology map which correspond to instantiated aggregated flows (and >> recursively so). You can either do an end-end flow setup which uses >> those >> virtual links (and the flow stack in the packet header), or you can >> play all >> sorts of interesting tricks with the flow stack to cause packets to >> take paths >> composed of those virtual links, or you can do a mixture of the two. >> >> I not sure if I have that problem Vadim identified with the full-blown >> flow-setup case completely licked, but I have some ideas which I >> think will >> do it. >> > > Don't get me wrong here, but on first read-through, isn't what you are > describing MPLS? > Reading it again, I guess this is not completely the case. But at least I would appreciate some more details. - kurtis - From owner-multi6@ops.ietf.org Sun May 4 12:31:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02623 for ; Sun, 4 May 2003 12:31:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CMPB-000OVw-00 for multi6-data@psg.com; Sun, 04 May 2003 16:32:01 +0000 Received: from [2002:c08b:2e21:3:250:baff:fe2d:b704] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.36 #1) id 19CMP9-000OVS-00 for multi6@ops.ietf.org; Sun, 04 May 2003 16:32:00 +0000 Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h44GVpU03109 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Sun, 4 May 2003 12:31:53 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h44GWoR08991; Sun, 4 May 2003 12:32:51 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h44GVm6h001070; Sun, 4 May 2003 12:31:49 -0400 Message-Id: <200305041631.h44GVm6h001070@sandelman.ottawa.on.ca> To: "Tony Li" cc: multi6@ops.ietf.org Subject: Re: updating GSE for the new millennium In-reply-to: Your message of "Sat, 03 May 2003 17:08:55 PDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sun, 04 May 2003 12:31:48 -0400 From: Michael Richardson X-Spam-Status: No, hits=-8.5 required=5.0 tests=BAYES_10,IN_REP_TO,RCVD_IN_OSIRUSOFT_COM autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk >>>>> "Tony" == Tony Li writes: Tony> Root name servers are also a service deserving of anycast Tony> addresses. But, this is multiple systems with the "same" address rather than a single system with multiple addresses. So, I don't see the relevance to multi6 :-) ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ From owner-multi6@ops.ietf.org Sun May 4 16:00:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05823 for ; Sun, 4 May 2003 16:00:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CPf2-0006KO-00 for multi6-data@psg.com; Sun, 04 May 2003 20:00:36 +0000 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 19CPex-0006K0-00 for multi6@ops.ietf.org; Sun, 04 May 2003 20:00:31 +0000 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h44K0TtU008280; Sun, 4 May 2003 16:00:30 -0400 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id h44K0TZH008279; Sun, 4 May 2003 16:00:29 -0400 Date: Sun, 4 May 2003 16:00:29 -0400 From: "J. Noel Chiappa" Message-Id: <200305042000.h44K0TZH008279@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: IETF multihoming powder: just add IPv6 and stir Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_20 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Kurt Erik Lindqvist >> It might be good to get the word out that multi6 wants to recharter >> and work on the identifier/locator thing aka GSE++ aka 6+10. Then we >> can see if the pro mob is larger than the anti mob at the meeting. > I am not sure I want to say that we recharter to the GSE++ model. > ... > they want to present and make their case for their solution and against > a GSE based approach When people start talking loosely about "GSE" I get nervous, because there are a number of (to me) independent architectural and engineering points that are involved in what I think of as "GSE". (Indeed, there might be a danger that "GSE" means different things to different people, but that's a *separate* problem from the one that I'm talking about here.) Anyway, I think we need to: - keep each of these separate things clear in our mind - although of course a particular proposed solution will consist of a (hopefully :-) carefully selected set of detailed answers, one for each point. - because if one proves problematic, that *doesn't* mean the other (independent) ideas are unworkable. As I see them, the points in "GSE" are: 1 - The basic approach to multi-homing being use of more than one locator (I think we are approaching rough consensus on this for any solution, not just GSE, but list it for completeness) 2 - Separation of location and identity, using two separate and distinct labels, one for each function (Again, I think we are approaching rough consensus on this for any solution, but list it for completeness) 3 - Use of IPv6 addresses (or parts of them) as the namespaces for both of those two classes of identifiers 4 - Details of the identifier; two obvious options: A - Use of two complete IPv6 addresses, one for each kind of identifier, sometimes called "16+16" B - One IPv6 address, divided into two fields (the original being "8+8", but I now see mention of "6+10") 5 - Replacement of part or all of the location identifier by entities other than the endpoints of the end-end communication A - replacement involving the destination locator only B - replacement involving the source and destination locators Some combinations have repercussions; e.g. 5 plus 4B means that either you have to modify TCP6 (which I think we decided was unfeasible), or the original contents of the location identifier part of the IPv6 address(es) have to be placed back in the packet before the endpoint processes it. Anyway, I hope this sort of framework for thinking about them is useful. Noel From owner-multi6@ops.ietf.org Sun May 4 17:19:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06812 for ; Sun, 4 May 2003 17:19:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CQuT-000Kvm-00 for multi6-data@psg.com; Sun, 04 May 2003 21:20:37 +0000 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #1) id 19CQuR-000KvR-00 for multi6@ops.ietf.org; Sun, 04 May 2003 21:20:35 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 51BC123C3B; Sun, 4 May 2003 14:09:17 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h44LKTYB005855; Sun, 4 May 2003 14:20:29 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: updating GSE for the new millennium Date: Sun, 4 May 2003 14:20:29 -0700 Message-ID: Thread-Topic: updating GSE for the new millennium Thread-Index: AcMSWrS1nMchDk+EQKGMlR1708vd5gAKBFbQ From: "Tony Li" To: "Michael Richardson" Cc: X-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_20 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA06812 | >>>>> "Tony" == Tony Li writes: | Tony> Root name servers are also a service deserving of anycast | Tony> addresses. | | But, this is multiple systems with the "same" address rather than | a single system with multiple addresses. | So, I don't see the relevance to multi6 :-) If the point is to bootstrap yourself into some way of finding all of the DNS servers that contain useful things like name to locator and name to identifier mappings, then you need to start with a known locator to begin the process. As was pointed out, we today start with a cache of known addresses. We could simplify this through unicast and have a smaller set (one?) of known addresses. Tony From owner-multi6@ops.ietf.org Sun May 4 21:07:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10190 for ; Sun, 4 May 2003 21:06:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CURY-0003QU-00 for multi6-data@psg.com; Mon, 05 May 2003 01:07:00 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19CURU-0003QB-00 for multi6@ops.ietf.org; Mon, 05 May 2003 01:06:56 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.14) id 19CURT-000E0w-Vz for multi6@ops.ietf.org; Sun, 04 May 2003 18:06:56 -0700 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Message-Id: <3C1AB4BA-7CE8-11D7-92E2-000393520ED8@netnod.se> Date: Fri, 2 May 2003 23:51:31 +0200 Subject: WG last-call draft-ietf-multi6-multihoming-requirements-04.txt From: Kurt Erik Lindqvist To: multi6@ops.ietf.org X-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_20 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Unless there are more comments on the above draft by Monday 12.00 CET we will send the above draft to the IESG. Best regards, - kurtis - From owner-multi6@ops.ietf.org Mon May 5 02:29:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25747 for ; Mon, 5 May 2003 02:29:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CZUS-000OrB-00 for multi6-data@psg.com; Mon, 05 May 2003 06:30:20 +0000 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 19CZUN-000Oqr-00 for multi6@ops.ietf.org; Mon, 05 May 2003 06:30:15 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h456WaTq004871 for ; Mon, 5 May 2003 08:32:37 +0200 (CEST) Date: Mon, 5 May 2003 08:32:32 +0200 Subject: Re: WG last-call draft-ietf-multi6-multihoming-requirements-04.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Kurt Erik Lindqvist To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: <3C1AB4BA-7CE8-11D7-92E2-000393520ED8@netnod.se> Message-Id: <59DD86DE-7EC3-11D7-92E2-000393520ED8@kurtis.pp.se> X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-27.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_RFCI,REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ok, I sent this Friday but from the wrong mail-address. I was referring to noon today, but I agree that this is to short notice. My fault. Let's move this up to Wednesday 7th of May 12.00 CET. Apologies again. - kurtis - On fredag, maj 2, 2003, at 23:51 Europe/Stockholm, Kurt Erik Lindqvist wrote: > [ post by non-subscriber. with the massive amount of spam, it is easy > to miss > and therefore delete posts by non-subscribers. if you wish to > regularly > post from an address that is not subscribed to this mailing list, > send a > message to -owner@ops.ietf.org and ask to have the alternate > address added to the list of addresses from which submissions are > automatically accepted. ] > > Unless there are more comments on the above draft by Monday 12.00 CET > we will send the above draft to the IESG. > > > Best regards, > > - kurtis - > > > > From owner-multi6@ops.ietf.org Mon May 5 02:38:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25966 for ; Mon, 5 May 2003 02:38:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CZeg-00004l-00 for multi6-data@psg.com; Mon, 05 May 2003 06:40:54 +0000 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 19CZed-00004W-00 for multi6@ops.ietf.org; Mon, 05 May 2003 06:40:51 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h456h5Tq004875; Mon, 5 May 2003 08:43:06 +0200 (CEST) Date: Mon, 5 May 2003 08:42:59 +0200 Subject: Re: IETF multihoming powder: just add IPv6 and stir Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: "J. Noel Chiappa" From: Kurt Erik Lindqvist In-Reply-To: <200305042000.h44K0TZH008279@ginger.lcs.mit.edu> Message-Id: X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-27.7 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,RCVD_IN_RFCI,REPLY_WITH_QUOTES, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA25966 On söndag, maj 4, 2003, at 22:00 Europe/Stockholm, J. Noel Chiappa wrote: >> From: Kurt Erik Lindqvist > >>> It might be good to get the word out that multi6 wants to recharter >>> and work on the identifier/locator thing aka GSE++ aka 6+10. Then we >>> can see if the pro mob is larger than the anti mob at the meeting. > >> I am not sure I want to say that we recharter to the GSE++ model. >> ... >> they want to present and make their case for their solution and >> against >> a GSE based approach > > When people start talking loosely about "GSE" I get nervous, because > there > are a number of (to me) independent architectural and engineering > points that > are involved in what I think of as "GSE". Actually. I would prefer that we Stop talking about GSE - and start talking about a number of features included in a specific solution. If that is written down in a draft, even better. I think that this will help us avoid the worst confusions and debates on non-issues. > > (Indeed, there might be a danger that "GSE" means different things to > different people, but that's a *separate* problem from the one that I'm > talking about here.) Well, maybe. Unless we solve this we will be running in circles. > > As I see them, the points in "GSE" are: > > > 1 - The basic approach to multi-homing being use of more than one > locator > (I think we are approaching rough consensus on this for any > solution, not just GSE, but list it for completeness) Agreed. > 2 - Separation of location and identity, using two separate and > distinct > labels, one for each function > (Again, I think we are approaching rough consensus on this for > any solution, but list it for completeness) I think that there might be some more work needed here before I would say that we are at consensus. At least that is what I take away from the last days discussions. > 3 - Use of IPv6 addresses (or parts of them) as the namespaces for > both of > those two classes of identifiers > 4 - Details of the identifier; two obvious options: > A - Use of two complete IPv6 addresses, one for each kind of > identifier, sometimes called "16+16" > B - One IPv6 address, divided into two fields (the original being > "8+8", but I now see mention of "6+10") > 5 - Replacement of part or all of the location identifier by entities > other > than the endpoints of the end-end communication > A - replacement involving the destination locator only > B - replacement involving the source and destination locators The above points are definitely not very clear so far, but that is also where we need more work done. Especially if we want to have something to discuss in Vienna. > > Anyway, I hope this sort of framework for thinking about them is > useful. > It is. But it would be even better if we agreed on the characteristics on all solutions (not to mention which solutions have been taken to the IETF)... - kurtis - From owner-multi6@ops.ietf.org Mon May 5 02:46:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26010 for ; Mon, 5 May 2003 02:46:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CZmR-0000vE-00 for multi6-data@psg.com; Mon, 05 May 2003 06:48:55 +0000 Received: from mail-gw1.hursley.ibm.com ([194.196.110.15]) by psg.com with esmtp (Exim 3.36 #1) id 19CZmO-0000uw-00 for multi6@ops.ietf.org; Mon, 05 May 2003 06:48:52 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19CZmL-0001so-00; Mon, 05 May 2003 07:48:49 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19CZmL-0001sZ-00; Mon, 05 May 2003 07:48:49 +0100 Received: from hursley.ibm.com (dhcp21-189.zurich.ibm.com [9.4.21.189]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id HAA187924; Mon, 5 May 2003 07:48:46 +0100 Message-ID: <3EB60971.453985B0@hursley.ibm.com> Date: Mon, 05 May 2003 08:49:21 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Kurt Erik Lindqvist CC: multi6@ops.ietf.org Subject: Re: WG last-call draft-ietf-multi6-multihoming-requirements-04.txt References: <3C1AB4BA-7CE8-11D7-92E2-000393520ED8@netnod.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-28.5 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hold it!!! I sent several editorial comments on April 16, that Joe stated he would include, and there was one substantive comment on the security considerations, where I think there was an agreed change. So at the minimum there has to be an -05 version. Also, a last call that arrived 03:00 Monday and expires 12:00 Monday seems a little short ;-) Brian Kurt Erik Lindqvist wrote: > > [ post by non-subscriber. with the massive amount of spam, it is easy to miss > and therefore delete posts by non-subscribers. if you wish to regularly > post from an address that is not subscribed to this mailing list, send a > message to -owner@ops.ietf.org and ask to have the alternate > address added to the list of addresses from which submissions are > automatically accepted. ] > > Unless there are more comments on the above draft by Monday 12.00 CET > we will send the above draft to the IESG. > > Best regards, > > - kurtis - From owner-multi6@ops.ietf.org Mon May 5 02:50:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26044 for ; Mon, 5 May 2003 02:50:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CZqz-0001YD-00 for multi6-data@psg.com; Mon, 05 May 2003 06:53:37 +0000 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 19CZqx-0001Xs-00 for multi6@ops.ietf.org; Mon, 05 May 2003 06:53:35 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h456ttTq004878; Mon, 5 May 2003 08:55:56 +0200 (CEST) Date: Mon, 5 May 2003 08:55:47 +0200 Subject: Re: WG last-call draft-ietf-multi6-multihoming-requirements-04.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Brian E Carpenter From: Kurt Erik Lindqvist In-Reply-To: <3EB60971.453985B0@hursley.ibm.com> Message-Id: <996B60EC-7EC6-11D7-92E2-000393520ED8@kurtis.pp.se> X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-28.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,RCVD_IN_RFCI,REPLY_WITH_QUOTES, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA26044 On måndag, maj 5, 2003, at 08:49 Europe/Stockholm, Brian E Carpenter wrote: > Hold it!!! > > I sent several editorial comments on April 16, that Joe stated he would > include, and there was one substantive comment on the security > considerations, > where I think there was an agreed change. Hmm. Joe? > > So at the minimum there has to be an -05 version. > > Also, a last call that arrived 03:00 Monday and expires 12:00 Monday > seems a little short ;-) See other mail. - kurtis - > > Brian > > Kurt Erik Lindqvist wrote: >> >> [ post by non-subscriber. with the massive amount of spam, it is >> easy to miss >> and therefore delete posts by non-subscribers. if you wish to >> regularly >> post from an address that is not subscribed to this mailing list, >> send a >> message to -owner@ops.ietf.org and ask to have the >> alternate >> address added to the list of addresses from which submissions are >> automatically accepted. ] >> >> Unless there are more comments on the above draft by Monday 12.00 CET >> we will send the above draft to the IESG. >> >> Best regards, >> >> - kurtis - From owner-multi6@ops.ietf.org Mon May 5 03:03:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26161 for ; Mon, 5 May 2003 03:03:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Ca2X-0002px-00 for multi6-data@psg.com; Mon, 05 May 2003 07:05:33 +0000 Received: from mail-gw1.hursley.ibm.com ([194.196.110.15]) by psg.com with esmtp (Exim 3.36 #1) id 19Ca2T-0002pT-00 for multi6@ops.ietf.org; Mon, 05 May 2003 07:05:30 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19Ca2S-0002Tg-00; Mon, 05 May 2003 08:05:28 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19Ca2S-0002Ta-00; Mon, 05 May 2003 08:05:28 +0100 Received: from hursley.ibm.com (dhcp21-189.zurich.ibm.com [9.4.21.189]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id IAA161682; Mon, 5 May 2003 08:05:24 +0100 Message-ID: <3EB60D55.E692719D@hursley.ibm.com> Date: Mon, 05 May 2003 09:05:57 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Peter Tattam CC: multi6@ops.ietf.org Subject: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-12.8 required=5.0 tests=BAYES_20,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Peter Tattam wrote: ... > > > > 3) We know from previous discussion that 64 bits is too short for a > > randomly assigned global space; > > I thought we were talking about a M + S + 64 bits address space where the M > bits can be guaranteed globally unique and the S bits are managed by the site. > For the purposes of global routing, this is unique enough to guarantee no > collisions. The uniqueness of the 64 bits within the local segment are managed > by existing mechanisms of address autoconfig. That isn't the only requirement. If the M is mutable and the S has no particular reason to be unique, then if you have a set of peers intercommunicating, you've only got the 64 bit IDs available to act as unique IDs for transport end-point and security end-point identification. So there is a strong requirement that the 64 bit IDs be unique within any set of intercommunicating peers. (In the case of TCP, the set has two members; in the case of FTP it's any number, by use of the PORT command.) Brian From owner-multi6@ops.ietf.org Mon May 5 03:20:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26280 for ; Mon, 5 May 2003 03:20:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CaJB-0004uM-00 for multi6-data@psg.com; Mon, 05 May 2003 07:22:45 +0000 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #1) id 19CaJ9-0004u7-00 for multi6@ops.ietf.org; Mon, 05 May 2003 07:22:43 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id ADFB523C3C; Mon, 5 May 2003 00:11:24 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h457MgYB026012; Mon, 5 May 2003 00:22:43 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Date: Mon, 5 May 2003 00:22:42 -0700 Message-ID: Thread-Topic: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Thread-Index: AcMS1g+ZC0/QwR1wShKKzCx+8UVHTgAAOkDA From: "Tony Li" To: "Brian E Carpenter" , "Peter Tattam" Cc: X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA26280 We also run into the issue of doing an identifier to locator mapping. If the identifier is a random value, then this would be 'challenging'. However, if this is a 64 bit administratively assigned number, then we have both global uniqueness and hierarchical search capability. Tony | -----Original Message----- | From: Brian E Carpenter [mailto:brian@hursley.ibm.com] | Sent: Monday, May 05, 2003 12:06 AM | To: Peter Tattam | Cc: multi6@ops.ietf.org | Subject: GSE IDs [Re: IETF multihoming powder: just add | IPv6 and stir] | | | Peter Tattam wrote: | ... | > > | > > 3) We know from previous discussion that 64 bits is | too short for a | > > randomly assigned global space; | > | > I thought we were talking about a M + S + 64 bits | address space where the M | > bits can be guaranteed globally unique and the S bits | are managed by the site. | > For the purposes of global routing, this is unique | enough to guarantee no | > collisions. The uniqueness of the 64 bits within the | local segment are managed | > by existing mechanisms of address autoconfig. | | That isn't the only requirement. If the M is mutable and | the S has no | particular reason to be unique, then if you have a set of peers | intercommunicating, you've only got the 64 bit IDs | available to act as | unique IDs for transport end-point and security end-point | identification. | | So there is a strong requirement that the 64 bit IDs be | unique within | any set of intercommunicating peers. (In the case of TCP, | the set has | two members; in the case of FTP it's any number, by use of the PORT | command.) | | Brian | | From owner-multi6@ops.ietf.org Mon May 5 08:10:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29869 for ; Mon, 5 May 2003 08:10:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Ceot-000FJY-00 for multi6-data@psg.com; Mon, 05 May 2003 12:11:47 +0000 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.36 #1) id 19Ceoq-000FJK-00 for multi6@ops.ietf.org; Mon, 05 May 2003 12:11:44 +0000 Received: (qmail 71383 invoked by uid 0); 5 May 2003 12:11:43 -0000 Received: from localhost.automagic.org (HELO isc.org) (root@127.0.0.1) by localhost.automagic.org with SMTP; 5 May 2003 12:11:43 -0000 Date: Mon, 5 May 2003 08:11:49 -0400 Subject: Re: WG last-call draft-ietf-multi6-multihoming-requirements-04.txt Content-Type: text/plain; delsp=yes; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Brian E Carpenter , multi6@ops.ietf.org To: Kurt Erik Lindqvist From: Joe Abley In-Reply-To: <996B60EC-7EC6-11D7-92E2-000393520ED8@kurtis.pp.se> Message-Id: X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA29869 On Monday, May 5, 2003, at 02:55 Canada/Eastern, Kurt Erik Lindqvist wrote: > On måndag, maj 5, 2003, at 08:49 Europe/Stockholm, Brian E Carpenter > wrote: > >> Hold it!!! >> >> I sent several editorial comments on April 16, that Joe stated he >> would >> include, and there was one substantive comment on the security >> considerations, >> where I think there was an agreed change. > > Hmm. Joe? Those changes were applied, as far as I know. At least, I sent diffs to the list at the time and received no feedback. >> So at the minimum there has to be an -05 version. >> >> Also, a last call that arrived 03:00 Monday and expires 12:00 Monday >> seems a little short ;-) > > See other mail. -05 is the current draft. http://www.ietf.org/internet-drafts/draft-ietf-multi6-multihoming- requirements-05.txt Joe From owner-multi6@ops.ietf.org Mon May 5 09:50:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01876 for ; Mon, 5 May 2003 09:50:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CgNN-0004Ec-00 for multi6-data@psg.com; Mon, 05 May 2003 13:51:29 +0000 Received: from mail-gw1.hursley.ibm.com ([194.196.110.15]) by psg.com with esmtp (Exim 3.36 #1) id 19CgNL-0004EI-00 for multi6@ops.ietf.org; Mon, 05 May 2003 13:51:27 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19CgNK-0006kP-00; Mon, 05 May 2003 14:51:26 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19CgNJ-0006kK-00; Mon, 05 May 2003 14:51:25 +0100 Received: from hursley.ibm.com (dhcp21-189.zurich.ibm.com [9.4.21.189]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA168510; Mon, 5 May 2003 14:51:23 +0100 Message-ID: <3EB66C7E.F5BF2545@hursley.ibm.com> Date: Mon, 05 May 2003 15:51:58 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Joe Abley CC: Kurt Erik Lindqvist , multi6@ops.ietf.org Subject: Re: WG last-call draft-ietf-multi6-multihoming-requirements-04.txt References: Content-Type: text/plain; charset=iso-8859-1 X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA01876 Quite right. Kurt last-called the obsolete draft. Could we restart the last call, on the basis of the -05 draft? My answer on that is: ship it! Brian Joe Abley wrote: > > On Monday, May 5, 2003, at 02:55 Canada/Eastern, Kurt Erik Lindqvist > wrote: > > > On måndag, maj 5, 2003, at 08:49 Europe/Stockholm, Brian E Carpenter > > wrote: > > > >> Hold it!!! > >> > >> I sent several editorial comments on April 16, that Joe stated he > >> would > >> include, and there was one substantive comment on the security > >> considerations, > >> where I think there was an agreed change. > > > > Hmm. Joe? > > Those changes were applied, as far as I know. At least, I sent diffs to > the list at the time and received no feedback. > > >> So at the minimum there has to be an -05 version. > >> > >> Also, a last call that arrived 03:00 Monday and expires 12:00 Monday > >> seems a little short ;-) > > > > See other mail. > > -05 is the current draft. > > http://www.ietf.org/internet-drafts/draft-ietf-multi6-multihoming- > requirements-05.txt > > Joe From owner-multi6@ops.ietf.org Mon May 5 10:57:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04813 for ; Mon, 5 May 2003 10:57:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19ChQd-000FLr-00 for multi6-data@psg.com; Mon, 05 May 2003 14:58:55 +0000 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 19ChQZ-000FLb-00 for multi6@ops.ietf.org; Mon, 05 May 2003 14:58:52 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h45F17Tq005061; Mon, 5 May 2003 17:01:08 +0200 (CEST) Date: Mon, 5 May 2003 17:01:01 +0200 Subject: Re: WG last-call draft-ietf-multi6-multihoming-requirements-04.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Joe Abley , multi6@ops.ietf.org To: Brian E Carpenter From: Kurt Erik Lindqvist In-Reply-To: <3EB66C7E.F5BF2545@hursley.ibm.com> Message-Id: <62F11E83-7F0A-11D7-92E2-000393520ED8@kurtis.pp.se> X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-28.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,RCVD_IN_RFCI,REPLY_WITH_QUOTES, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA04813 On måndag, maj 5, 2003, at 15:51 Europe/Stockholm, Brian E Carpenter wrote: > Quite right. Kurt last-called the obsolete draft. Grr. For some reason me posting to this mailinglist is under some form of spell...:-) > > Could we restart the last call, on the basis of the -05 draft? > My answer on that is: ship it! Me and Sean have discussed around this last-call in private and we are both really in favor of getting this shipped ASAP. Unless anyone have come up with a really compelling reason not to ship it by Wen 12.00 CET we will ship it. The -05 draft that is. - kurtis - PS From my understanding there is actually nothing that require a WG last-call procedure-wise, and not all WGs use it either. Randy correct me if I am wrong. > > Brian > > Joe Abley wrote: >> >> On Monday, May 5, 2003, at 02:55 Canada/Eastern, Kurt Erik Lindqvist >> wrote: >> >>> On måndag, maj 5, 2003, at 08:49 Europe/Stockholm, Brian E Carpenter >>> wrote: >>> >>>> Hold it!!! >>>> >>>> I sent several editorial comments on April 16, that Joe stated he >>>> would >>>> include, and there was one substantive comment on the security >>>> considerations, >>>> where I think there was an agreed change. >>> >>> Hmm. Joe? >> >> Those changes were applied, as far as I know. At least, I sent diffs >> to >> the list at the time and received no feedback. >> >>>> So at the minimum there has to be an -05 version. >>>> >>>> Also, a last call that arrived 03:00 Monday and expires 12:00 Monday >>>> seems a little short ;-) >>> >>> See other mail. >> >> -05 is the current draft. >> >> http://www.ietf.org/internet-drafts/draft-ietf-multi6-multihoming- >> requirements-05.txt >> >> Joe From owner-multi6@ops.ietf.org Mon May 5 14:44:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10961 for ; Mon, 5 May 2003 14:44:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Ckyh-0005HW-00 for multi6-data@psg.com; Mon, 05 May 2003 18:46:19 +0000 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 19CkyZ-0005GP-00 for multi6@ops.ietf.org; Mon, 05 May 2003 18:46:11 +0000 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id C65AB137F25; Mon, 5 May 2003 11:22:20 -0700 (PDT) Date: Mon, 5 May 2003 11:22:19 -0700 Subject: Re: WG last-call draft-ietf-multi6-multihoming-requirements-05.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Joe Abley , Kurt Erik Lindqvist , multi6@ops.ietf.org To: Brian E Carpenter From: David Conrad In-Reply-To: <3EB66C7E.F5BF2545@hursley.ibm.com> Message-Id: <81A45C94-7F26-11D7-9DAB-000393DB42B2@nominum.com> X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA10961 Just to be explicit: Christian raised an issue regarding the ability for 'smart hosts' to be able to pick the return path. Should this be added to the list of goals? Rgds, -drc On Monday, May 5, 2003, at 06:51 AM, Brian E Carpenter wrote: > Quite right. Kurt last-called the obsolete draft. > > Could we restart the last call, on the basis of the -05 draft? > My answer on that is: ship it! > > Brian > > Joe Abley wrote: >> >> On Monday, May 5, 2003, at 02:55 Canada/Eastern, Kurt Erik Lindqvist >> wrote: >> >>> On måndag, maj 5, 2003, at 08:49 Europe/Stockholm, Brian E Carpenter >>> wrote: >>> >>>> Hold it!!! >>>> >>>> I sent several editorial comments on April 16, that Joe stated he >>>> would >>>> include, and there was one substantive comment on the security >>>> considerations, >>>> where I think there was an agreed change. >>> >>> Hmm. Joe? >> >> Those changes were applied, as far as I know. At least, I sent diffs >> to >> the list at the time and received no feedback. >> >>>> So at the minimum there has to be an -05 version. >>>> >>>> Also, a last call that arrived 03:00 Monday and expires 12:00 Monday >>>> seems a little short ;-) >>> >>> See other mail. >> >> -05 is the current draft. >> >> http://www.ietf.org/internet-drafts/draft-ietf-multi6-multihoming- >> requirements-05.txt >> >> Joe > From owner-multi6@ops.ietf.org Mon May 5 15:53:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13985 for ; Mon, 5 May 2003 15:53:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Cm3p-000JIl-00 for multi6-data@psg.com; Mon, 05 May 2003 19:55:41 +0000 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 19Cm3m-000JIX-00 for multi6@ops.ietf.org; Mon, 05 May 2003 19:55:38 +0000 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 0B6C3137F0D; Mon, 5 May 2003 12:55:37 -0700 (PDT) Date: Mon, 5 May 2003 12:55:33 -0700 Subject: Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Peter Tattam , multi6@ops.ietf.org To: Brian E Carpenter From: David Conrad In-Reply-To: <3EB60D55.E692719D@hursley.ibm.com> Message-Id: <87F3B032-7F33-11D7-9DAB-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian, On Monday, May 5, 2003, at 12:05 AM, Brian E Carpenter wrote: >> I thought we were talking about a M + S + 64 bits address space where >> the M >> bits can be guaranteed globally unique and the S bits are managed by >> the site. Or, more specifically, S+64. >> For the purposes of global routing, this is unique enough to >> guarantee no >> collisions. The uniqueness of the 64 bits within the local segment >> are managed >> by existing mechanisms of address autoconfig. Right. > That isn't the only requirement. If the M is mutable and the S has no > particular reason to be unique, then if you have a set of peers > intercommunicating, you've only got the 64 bit IDs available to act as > unique IDs for transport end-point and security end-point > identification. Not unless M is globally unique. > So there is a strong requirement that the 64 bit IDs be unique within > any set of intercommunicating peers. (In the case of TCP, the set has > two members; in the case of FTP it's any number, by use of the PORT > command.) No. All the GSE-like solutions discussed to date that I am aware of have assumed the first 48 bits (the locator) are globally unique. This is sort of fundamental. If the first 48 bits are unique, then the last 80 bits may or may not be unique depending on what you want to do. Rgds, -drc From owner-multi6@ops.ietf.org Mon May 5 16:46:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15659 for ; Mon, 5 May 2003 16:46:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CmsV-0004Fy-00 for multi6-data@psg.com; Mon, 05 May 2003 20:48:03 +0000 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 19CmsO-0004Ff-00 for multi6@ops.ietf.org; Mon, 05 May 2003 20:47:56 +0000 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h45KlstU013673; Mon, 5 May 2003 16:47:54 -0400 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id h45KlrKe013672; Mon, 5 May 2003 16:47:53 -0400 Date: Mon, 5 May 2003 16:47:53 -0400 From: "J. Noel Chiappa" Message-Id: <200305052047.h45KlrKe013672@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_20 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: David Conrad > All the GSE-like solutions discussed to date that I am aware of have > assumed the first 48 bits (the locator) are globally unique. ... the > last 80 bits may or may not be unique depending on what you want to do. There's not much point to separating location and identity if the portion of the name which is the identity is not globally unique *by itself*. Noel From owner-multi6@ops.ietf.org Mon May 5 17:19:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16658 for ; Mon, 5 May 2003 17:19:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CnNi-000B6y-00 for multi6-data@psg.com; Mon, 05 May 2003 21:20:18 +0000 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 19CnNf-000B6j-00 for multi6@ops.ietf.org; Mon, 05 May 2003 21:20:15 +0000 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 20197137F0D; Mon, 5 May 2003 14:20:15 -0700 (PDT) Date: Mon, 5 May 2003 14:20:12 -0700 Subject: Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: "J. Noel Chiappa" From: David Conrad In-Reply-To: <200305052047.h45KlrKe013672@ginger.lcs.mit.edu> Message-Id: <5B2DA490-7F3F-11D7-9DAB-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Noel, I agree. However, I have been told that ensuring the global uniqueness of the last 80 bits is non-trivial because people like the stateless auto-configuration stuff that has been defined for v6. One way of addressing this particular concern is to say the top 48 bits are mutable from one globally unique value (a "site identifier") to another globally unique value (an "aggregation locator") via some mapping function at both exit from the source site as well as entry at the destination site. In this case, the identity portion of the name (the first 48 bits within a site) is globally unique by itself. Rgds, -drc On Monday, May 5, 2003, at 01:47 PM, J. Noel Chiappa wrote: >> From: David Conrad > >> All the GSE-like solutions discussed to date that I am aware of have >> assumed the first 48 bits (the locator) are globally unique. ... the >> last 80 bits may or may not be unique depending on what you want to >> do. > > There's not much point to separating location and identity if the > portion of > the name which is the identity is not globally unique *by itself*. > > Noel > From owner-multi6@ops.ietf.org Mon May 5 18:09:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18182 for ; Mon, 5 May 2003 18:09:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CoBT-000LUQ-00 for multi6-data@psg.com; Mon, 05 May 2003 22:11:43 +0000 Received: from mail2.microsoft.com ([131.107.3.124]) by psg.com with esmtp (Exim 3.36 #1) id 19CoBB-000LQs-00 for multi6@ops.ietf.org; Mon, 05 May 2003 22:11:25 +0000 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Mon, 5 May 2003 15:11:25 -0700 Received: from 157.54.8.109 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 05 May 2003 15:11:25 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 5 May 2003 15:11:25 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 5 May 2003 15:11:24 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Mon, 5 May 2003 15:11:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Date: Mon, 5 May 2003 15:11:22 -0700 Message-ID: Thread-Topic: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] thread-index: AcMTTbNKmV9EoicuSladuML2sa6p/QABGbjg From: "Christian Huitema" To: "David Conrad" , "J. Noel Chiappa" Cc: X-OriginalArrivalTime: 05 May 2003 22:11:23.0949 (UTC) FILETIME=[43EF85D0:01C31353] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA18182 > One way of addressing this particular concern is to say the top 48 bits > are mutable from one globally unique value (a "site identifier") to > another globally unique value (an "aggregation locator") via some > mapping function at both exit from the source site as well as entry at > the destination site. The focus on the site misses an important point. Computers are often multi-homed to several sites, e.g. WiFi and GPRS. If you do something as radical as changing the behavior of TCP, then you want a solution that handles host multi-homing as well as site multi-homing. But then you cannot expect that all the "locators" that carry packets to a single TCP++ solution belong to the same aggregate. In the site multi-homing case, you must also be concerned with privacy issues. You should not force multi-homed computers to attach the same "global identifier" tag in all of their IP addresses, and you may expect privacy advocates to forcefully remind you if you ignore that point. Having a 16+16 solution a la Mobile IPv6 may be fine, provided that the privacy-conscious can encrypt the correlation identifier (the second 16) in an encrypted exchange. And it would also be nice if the second 16 did not have to be present in every packet. -- Christian Huitema From owner-multi6@ops.ietf.org Mon May 5 18:44:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20407 for ; Mon, 5 May 2003 18:44:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Cojg-0003Cu-00 for multi6-data@psg.com; Mon, 05 May 2003 22:47:04 +0000 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #1) id 19Cojc-0003Cf-00 for multi6@ops.ietf.org; Mon, 05 May 2003 22:47:00 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 5A18423C45; Mon, 5 May 2003 15:35:40 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h45MkxYB026667; Mon, 5 May 2003 15:46:59 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Date: Mon, 5 May 2003 15:46:59 -0700 Message-ID: Thread-Topic: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Thread-Index: AcMTTbNKmV9EoicuSladuML2sa6p/QABGbjgAAF2aaA= From: "Tony Li" To: "Christian Huitema" , "David Conrad" , "J. Noel Chiappa" Cc: X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA20407 | The focus on the site misses an important point. Computers | are often | multi-homed to several sites, e.g. WiFi and GPRS. If you | do something as | radical as changing the behavior of TCP, then you want a | solution that | handles host multi-homing as well as site multi-homing. | But then you | cannot expect that all the "locators" that carry packets | to a single | TCP++ solution belong to the same aggregate. | | In the site multi-homing case, you must also be concerned | with privacy | issues. You should not force multi-homed computers to | attach the same | "global identifier" tag in all of their IP addresses, and | you may expect | privacy advocates to forcefully remind you if you ignore | that point. I don't believe that that's a serious issue, but if those same folks want the full advantages of being a multi-homed host, then something has to give. The correspondent host can only work with information that is disclosed. Without that, the host would appear to be multiple independent hosts. Tony From owner-multi6@ops.ietf.org Mon May 5 18:49:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20564 for ; Mon, 5 May 2003 18:49:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Coo0-0004RS-00 for multi6-data@psg.com; Mon, 05 May 2003 22:51:32 +0000 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 19Conv-0004RE-00 for multi6@ops.ietf.org; Mon, 05 May 2003 22:51:27 +0000 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id C71B3137F0D; Mon, 5 May 2003 15:51:26 -0700 (PDT) Date: Mon, 5 May 2003 15:51:24 -0700 Subject: Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "J. Noel Chiappa" , To: "Christian Huitema" From: David Conrad In-Reply-To: Message-Id: <194AF2A9-7F4C-11D7-9DAB-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-28.3 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Christian, > The focus on the site misses an important point. I thought this working group was working on site multi-homing. On Monday, May 5, 2003, at 03:11 PM, Christian Huitema wrote: > Computers are often > multi-homed to several sites, e.g. WiFi and GPRS. Terminology issue. According to the working group draft: A "site" is an entity autonomously operating a network using IP and, in particular, determining the addressing plan and routing policy for that network. This definition is intended to be equivalent to "enterprise" as defined in [RFC 1918]. WiFi and GPRS are access methods. A network provider could offer connectivity to a "site" via WiFi or GPRS. However, with that said, presumably the device you are thinking of is a dual-mode cell phone/PDA or equivalent. As I have said before, a "site" in such a case could be defined to be the PAN (of perhaps no devices) connected to the Internet via the cell phone/PDA or equivalent, connected via WiFi and/or GPRS. > If you do something as > radical as changing the behavior of TCP, then you want a solution that > handles host multi-homing as well as site multi-homing. If you are doing something as radical as changing the behavior of TCP, then there are a lot of things that could be fixed, e.g., the layering violations of having the network address be aware to the transport and application layers, creation of a real session layer, etc. etc. However, I don't think this would be the right working group (or even the right area) to try to come up with (Transport Layer Protocol)++. > You should not force multi-homed computers to attach the same > "global identifier" tag in all of their IP addresses, and you may > expect > privacy advocates to forcefully remind you if you ignore that point. I think this is a bit overblown. Privacy advocates went non-linear on the idea that _individuals_ could be identified by the traffic they originate or receive due to IPv6's stateless auto-configuration using the EUI-64 associated with hardware interfaces on the user's computer. I do not believe they were concerned that _sites_ could be identified. If they were, I would imagine they'd be pretty unhappy with IPv4. Rgds, -drc From owner-multi6@ops.ietf.org Mon May 5 20:51:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22981 for ; Mon, 5 May 2003 20:51:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CqhU-000Me5-00 for multi6-data@psg.com; Tue, 06 May 2003 00:52:56 +0000 Received: from mail4.microsoft.com ([131.107.3.122]) by psg.com with esmtp (Exim 3.36 #1) id 19CqhQ-000Mdp-00 for multi6@ops.ietf.org; Tue, 06 May 2003 00:52:52 +0000 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Mon, 5 May 2003 17:52:52 -0700 Received: from 157.54.5.25 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 05 May 2003 17:52:51 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 5 May 2003 17:52:51 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 5 May 2003 17:52:50 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Mon, 5 May 2003 17:52:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Date: Mon, 5 May 2003 17:52:49 -0700 Message-ID: Thread-Topic: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Thread-Index: AcMTTbNKmV9EoicuSladuML2sa6p/QABGbjgAAF2aaAABGeNcA== From: "Christian Huitema" To: "Tony Li" , "David Conrad" , "J. Noel Chiappa" Cc: X-OriginalArrivalTime: 06 May 2003 00:52:50.0726 (UTC) FILETIME=[D1B46460:01C31369] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA22981 > | In the site multi-homing case, you must also be concerned > | with privacy > | issues. You should not force multi-homed computers to > | attach the same > | "global identifier" tag in all of their IP addresses, and > | you may expect > | privacy advocates to forcefully remind you if you ignore > | that point. > > > I don't believe that that's a serious issue, but if those same > folks want the full advantages of being a multi-homed host, then > something has to give. The correspondent host can only work with > information that is disclosed. Without that, the host would > appear to be multiple independent hosts. Notifying the correspondent host is fine, provided there is a way to control it. Notifying the network is not. -- Christian Huitema From owner-multi6@ops.ietf.org Tue May 6 02:05:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02983 for ; Tue, 6 May 2003 02:05:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CvX8-000JJ8-00 for multi6-data@psg.com; Tue, 06 May 2003 06:02:34 +0000 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 3.36 #1) id 19CvX4-000JIm-00 for multi6@ops.ietf.org; Tue, 06 May 2003 06:02:31 +0000 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id ED9B31C; Tue, 6 May 2003 09:12:27 +0300 (EEST) Message-ID: <3EB7501C.9060706@nomadiclab.com> Date: Tue, 06 May 2003 09:03:08 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Huitema Cc: multi6@ops.ietf.org Subject: Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Christian Huitema wrote: > Having a 16+16 solution a la Mobile IPv6 may be fine, provided that the > privacy-conscious can encrypt the correlation identifier (the second 16) > in an encrypted exchange. And it would also be nice if the second 16 did > not have to be present in every packet. With the danger of repeating myself (which I apparently do), I just want to remind that the above is more or less what HIP does. In HIP the second 16 is carried only during the initial host-to-host state setup; after that both the second 16s are "compressed" into ESP SPI. There is one problem with encrypting the second 16, which is making stateful middleboxes harder to implement. Thus, there is a tradeoff between privacy and dealing with middle boxes such as firewalls. In the case of HIP, this is (partly) taken care of by allowing the hosts to use several "second 16"s, different ones for different purposes (or locations). There might be other alternatives, like partial encryption that allows authorized middle boxes to learn, through some computation, the real second 16s while making such a computation far too expensive for third parties. Secondly, in whichever solution is selected, we must remember that the mapping from the identifiers to the locators (or from DNS names to identifier/locator pairs) must be made secure enough in a scalable manner. Secure DNS has been shown not to be scalable in practise. --Pekka Nikander From owner-multi6@ops.ietf.org Tue May 6 03:51:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11070 for ; Tue, 6 May 2003 03:51:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CxE6-0002zX-00 for multi6-data@psg.com; Tue, 06 May 2003 07:51:02 +0000 Received: from mail-gw1.hursley.ibm.com ([194.196.110.15]) by psg.com with esmtp (Exim 3.36 #1) id 19CxE3-0002zJ-00 for multi6@ops.ietf.org; Tue, 06 May 2003 07:50:59 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19CxE2-0004ka-00 for multi6@ops.ietf.org; Tue, 06 May 2003 08:50:58 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19CxE2-0004kV-00 for multi6@ops.ietf.org; Tue, 06 May 2003 08:50:58 +0100 Received: from hursley.ibm.com (dhcp21-189.zurich.ibm.com [9.4.21.189]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id IAA44762 for ; Tue, 6 May 2003 08:50:55 +0100 Message-ID: <3EB76980.CD3B80D4@hursley.ibm.com> Date: Tue, 06 May 2003 09:51:28 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] References: <5B2DA490-7F3F-11D7-9DAB-000393DB42B2@nominum.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit If the prefix is mutable en route, it doesn't matter that it's globally unique: the end points can't use it as part of any checksum, so either you have to add HIP, or the 64 bit suffix has to be unique enough for checksum purposes. (You might be prepared to accept an RFC 3041 suffix as unique enough, if you think that network level privacy is more important than the chance of a checksum coincidence.) Brian David Conrad wrote: > > Noel, > > I agree. > > However, I have been told that ensuring the global uniqueness of the > last 80 bits is non-trivial because people like the stateless > auto-configuration stuff that has been defined for v6. > > One way of addressing this particular concern is to say the top 48 bits > are mutable from one globally unique value (a "site identifier") to > another globally unique value (an "aggregation locator") via some > mapping function at both exit from the source site as well as entry at > the destination site. > > In this case, the identity portion of the name (the first 48 bits > within a site) is globally unique by itself. > > Rgds, > -drc > > On Monday, May 5, 2003, at 01:47 PM, J. Noel Chiappa wrote: > > >> From: David Conrad > > > >> All the GSE-like solutions discussed to date that I am aware of have > >> assumed the first 48 bits (the locator) are globally unique. ... the > >> last 80 bits may or may not be unique depending on what you want to > >> do. > > > > There's not much point to separating location and identity if the > > portion of > > the name which is the identity is not globally unique *by itself*. > > > > Noel > > From owner-multi6@ops.ietf.org Tue May 6 04:02:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11227 for ; Tue, 6 May 2003 04:02:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CxPw-000456-00 for multi6-data@psg.com; Tue, 06 May 2003 08:03:16 +0000 Received: from mail-gw1.hursley.ibm.com ([194.196.110.15]) by psg.com with esmtp (Exim 3.36 #1) id 19CxPt-00044e-00 for multi6@ops.ietf.org; Tue, 06 May 2003 08:03:13 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19CxPs-0005po-00; Tue, 06 May 2003 09:03:12 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19CxPr-0005pO-00; Tue, 06 May 2003 09:03:11 +0100 Received: from hursley.ibm.com (dhcp21-189.zurich.ibm.com [9.4.21.189]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id JAA180376; Tue, 6 May 2003 09:03:09 +0100 Message-ID: <3EB76C60.7632A3F4@hursley.ibm.com> Date: Tue, 06 May 2003 10:03:44 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: multi6@ops.ietf.org CC: Joe Abley Subject: Re: WG last-call draft-ietf-multi6-multihoming-requirements-05.txt References: <81A45C94-7F26-11D7-9DAB-000393DB42B2@nominum.com> Content-Type: text/plain; charset=iso-8859-1 X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA11227 It sounds more like a "nice to have" than a major goal. I suspect it's the sort of thing that might come in a Stage 2 solution, with topology information being distributed to hosts - not something I expect to see very soon. Stage 1 seems to be hard enough. Brian David Conrad wrote: > > Just to be explicit: > > Christian raised an issue regarding the ability for 'smart hosts' to be > able to pick the return path. > > Should this be added to the list of goals? > > Rgds, > -drc > > On Monday, May 5, 2003, at 06:51 AM, Brian E Carpenter wrote: > > > Quite right. Kurt last-called the obsolete draft. > > > > Could we restart the last call, on the basis of the -05 draft? > > My answer on that is: ship it! > > > > Brian > > > > Joe Abley wrote: > >> > >> On Monday, May 5, 2003, at 02:55 Canada/Eastern, Kurt Erik Lindqvist > >> wrote: > >> > >>> On måndag, maj 5, 2003, at 08:49 Europe/Stockholm, Brian E Carpenter > >>> wrote: > >>> > >>>> Hold it!!! > >>>> > >>>> I sent several editorial comments on April 16, that Joe stated he > >>>> would > >>>> include, and there was one substantive comment on the security > >>>> considerations, > >>>> where I think there was an agreed change. > >>> > >>> Hmm. Joe? > >> > >> Those changes were applied, as far as I know. At least, I sent diffs > >> to > >> the list at the time and received no feedback. > >> > >>>> So at the minimum there has to be an -05 version. > >>>> > >>>> Also, a last call that arrived 03:00 Monday and expires 12:00 Monday > >>>> seems a little short ;-) > >>> > >>> See other mail. > >> > >> -05 is the current draft. > >> > >> http://www.ietf.org/internet-drafts/draft-ietf-multi6-multihoming- > >> requirements-05.txt > >> > >> Joe From owner-multi6@ops.ietf.org Tue May 6 04:13:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11418 for ; Tue, 6 May 2003 04:13:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Cxa5-0005ER-00 for multi6-data@psg.com; Tue, 06 May 2003 08:13:45 +0000 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 19Cxa2-0005E9-00 for multi6@ops.ietf.org; Tue, 06 May 2003 08:13:42 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h468FpTq005247; Tue, 6 May 2003 10:15:52 +0200 (CEST) Date: Tue, 6 May 2003 10:14:11 +0200 Subject: Re: WG last-call draft-ietf-multi6-multihoming-requirements-05.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Brian E Carpenter , Joe Abley , multi6@ops.ietf.org To: David Conrad From: Kurt Erik Lindqvist In-Reply-To: <81A45C94-7F26-11D7-9DAB-000393DB42B2@nominum.com> Message-Id: X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-27.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_RFCI,REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA11418 I would say no for this version. We might want to publish a new version later on when we have a more clear picture. - kurtis - On måndag, maj 5, 2003, at 20:22 Europe/Stockholm, David Conrad wrote: > Just to be explicit: > > Christian raised an issue regarding the ability for 'smart hosts' to > be able to pick the return path. > > Should this be added to the list of goals? > > Rgds, > -drc > > On Monday, May 5, 2003, at 06:51 AM, Brian E Carpenter wrote: > >> Quite right. Kurt last-called the obsolete draft. >> >> Could we restart the last call, on the basis of the -05 draft? >> My answer on that is: ship it! >> >> Brian >> >> Joe Abley wrote: >>> >>> On Monday, May 5, 2003, at 02:55 Canada/Eastern, Kurt Erik Lindqvist >>> wrote: >>> >>>> On måndag, maj 5, 2003, at 08:49 Europe/Stockholm, Brian E Carpenter >>>> wrote: >>>> >>>>> Hold it!!! >>>>> >>>>> I sent several editorial comments on April 16, that Joe stated he >>>>> would >>>>> include, and there was one substantive comment on the security >>>>> considerations, >>>>> where I think there was an agreed change. >>>> >>>> Hmm. Joe? >>> >>> Those changes were applied, as far as I know. At least, I sent diffs >>> to >>> the list at the time and received no feedback. >>> >>>>> So at the minimum there has to be an -05 version. >>>>> >>>>> Also, a last call that arrived 03:00 Monday and expires 12:00 >>>>> Monday >>>>> seems a little short ;-) >>>> >>>> See other mail. >>> >>> -05 is the current draft. >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-multi6-multihoming- >>> requirements-05.txt >>> >>> Joe >> > From owner-multi6@ops.ietf.org Tue May 6 09:13:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20016 for ; Tue, 6 May 2003 09:13:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19D2Hy-000Dcp-00 for multi6-data@psg.com; Tue, 06 May 2003 13:15:22 +0000 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.36 #1) id 19D2Hv-000DbO-00 for multi6@ops.ietf.org; Tue, 06 May 2003 13:15:19 +0000 Received: (qmail 72976 invoked by uid 0); 6 May 2003 13:15:17 -0000 Received: from localhost.automagic.org (HELO isc.org) (root@127.0.0.1) by localhost.automagic.org with SMTP; 6 May 2003 13:15:17 -0000 Date: Tue, 6 May 2003 09:15:16 -0400 Subject: Re: WG last-call draft-ietf-multi6-multihoming-requirements-05.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: David Conrad , Brian E Carpenter , multi6@ops.ietf.org To: Kurt Erik Lindqvist From: Joe Abley In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday, May 6, 2003, at 04:14 Canada/Eastern, Kurt Erik Lindqvist wrote: > I would say no for this version. We might want to publish a new > version later on when we have a more clear picture. Sections 3.1.4 and 3.2.4 kind of hint at this capability already. It's not very explicit, but since all the MUSTs and MUST NOTs have been stripped from the document, I don't think this should keep anybody awake at night. So I also say "no for this version". Joe From owner-multi6@ops.ietf.org Tue May 6 17:10:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09267 for ; Tue, 6 May 2003 17:10:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19D9ij-0009Cj-00 for multi6-data@psg.com; Tue, 06 May 2003 21:11:29 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19D9ic-0009AX-00 for multi6@ops.ietf.org; Tue, 06 May 2003 21:11:22 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h46LB6q08545; Wed, 7 May 2003 00:11:06 +0300 Date: Wed, 7 May 2003 00:11:05 +0300 (EEST) From: Pekka Savola To: Kurt Erik Lindqvist cc: Joe Abley , Subject: comments on requirements-05 In-Reply-To: <62F11E83-7F0A-11D7-92E2-000393520ED8@kurtis.pp.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 5 May 2003, Kurt Erik Lindqvist wrote: > > Could we restart the last call, on the basis of the -05 draft? > > My answer on that is: ship it! > > Me and Sean have discussed around this last-call in private and we are > both really in favor of getting this shipped ASAP. Unless anyone have > come up with a really compelling reason not to ship it by Wen 12.00 CET > we will ship it. The -05 draft that is. I've done a quick review on the document. There are lots of things that should be clarified, but all should be rather easily editable. The document name should also be changed (s/requirements/goals/) if that's possible. substantial ----------- 1) the terminology should be improved to be more precise. A "transit provider" operates a site which directly provides connectivity to the Internet to one or more external sites. The connectivity provided extends beyond the transit provider's own site. A transit provider's site is directly connected to the sites for which it provides transit. ==> should be reworded to remove references to "transit provider is a site" -concept, which is irrelevant and confusing in this context. A "multihomed" site is one with more than one transit provider. "Site-multihoming" is the practice of arranging a site to be multihomed. ==> this also needs rewording. In general, the term "transit provider" is applied to network service providers which are in the middle of the packet forwarding chain. I do not call first-hop upstream providers transit providers. The term "transit" here is also misleading because it IMO points to the difference between "transit" and "peering", which do not apply to end-sites. ==> therefore, I think the last three terms could be reworded a bit. (I might be able to try to help with some text if needed and folks agree.) ==> similar consideration wrt. "transit" applies to the rest of the document. 2) simplicity for the internet and/or the site should be made explicit. 3.1.5 Simplicity As any proposed multihoming solution must be deployed in real networks with real customers, simplicity is paramount. The current multihoming solution is quite straightforward to deploy and maintain. A new IPv6 multihoming proposal should not be substantially more complex to deploy and operate than current IPv4 multihoming practices. ==> there are two aspects to the simplicity, with two different axes: - simplicity to those who deploy it, and to those that don't - simplicity to the Big Internet as a whole and the end-site itself Solutions will probably not be simple for all of these; stating these explicitly will make the solution designers aware of different aspects of simplicity which should be considered. 3) there are a few especially worrisome goals. 3.1.2 Load Sharing By multihoming, a site should be able to distribute both inbound and outbound traffic between multiple transit providers. 3.1.3 Performance [...] A multihomed site should be able to distribute inbound traffic from particular multiple transit providers according to the particular address range within their site which is sourcing or sinking the traffic. ==> typically "inbound traffic balancing", especially as made a very specific and detailed goal by "performance", go a long way in the "very potentially unscalable" territory. Therefore, I'd like to add some disclaimers or a few additional words to these goals -- but I don't know how and what in particular. Anyone else worried? 4) document assumes the Internet transit/ISP architecture is a single administrative entity 3.1.8 Packet Filtering Multihoming solutions should not preclude filtering packets with forged or otherwise inappropriate source IP addresses at the administrative boundary of the multihomed site. ==> replace from the end (remove the period): , or administrative boundaries between any transit providers in the Internet. (this is done to facilitate for the fact that the Internet is *not* just a homogenous single routing blob -- "once you're in, you're in for good"). 5) co-operation (non)goals are not explicit about third party ISP's and non-direct transit ISP's 3.2.6 Cooperation between Transit Providers A multihoming strategy may require cooperation between a site and its transit providers, but should not require cooperation (relating specifically to the multihomed site) directly between the transit providers. ==> particularly if the "transit provider" terminology is not redefined, this needs to be very much clarified. I believe the above text is used to refer to the direct first-hop upstream providers of the site only. It should also say that co-operation with any of the site's transit providers and any of their peers or transits should not be required ("no requirement for third parties", here transit of the transit being a 2 1/2 party) semi-editorial/substantial -------------------------- For purposes of redundancy and load-sharing, the multihomed address blocks, which are almost always a longer prefix than the provider aggregate, are announced along with the larger, covering aggregate originated by the provider. ==> s/redundancy/redundancy, independence/ This contributes to the rapidly-increasing size of the global routing table. ==> s/size/size and dynamicity/ (better word than dynamicity?!?!) By multihoming, a site should be able to distribute both inbound and outbound traffic between multiple transit providers. This requirement is for concurrent use of the multiple transit providers, not just the ==> s/requirement/goal/ 3.2.2 Impact on Routers The solution may require changes to IPv6 router implementations, but ==> s/solution/solutions/ -- many more under section 3.2.x. The text seems to indicate that a single solution would fit the bill. Normative References ==> references section should be numbered. [4] Hinden, R., O'Dell, M. and S. Deering, "An IPv6 Aggregatable Global Unicast Address Format", RFC 2374, July 1998. ==> this ref is no longer used in the body, and good riddance. Remove. [7] Huston, G., "Analyzing the Internet's BGP Routing Table", January 2001. ==> especially for a *normative reference*, the reference should IMO be much more explicit (e.g. refer to a publication and give a URL or the like). editorial --------- site-multihoming ==>s/site-multihoming/site multihoming/ (everywhere) ? This seems a more common practice..? providers may share a single conduit from the street into a building; in this case backhoe-fade of both circuits may be experienced due to ==> "backhoe-fade" ? No idea what that means, and couldn't find it in a dictionary either. demonstrate that the modified name resolution system required to support them are readily deployable. ==> s/are/is/ The multihoming solution may allow host or application changes if that would enhance session survivability. ==> s/session/transport-layer/ (to make a more explicit reference to the goal presented earlier) It should be posssible for staff responsible for the operation of a ==> s/posssible/possible/ -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Tue May 6 17:10:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09290 for ; Tue, 6 May 2003 17:10:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19D9kf-0009XH-00 for multi6-data@psg.com; Tue, 06 May 2003 21:13:29 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19D9kc-0009SQ-00 for multi6@ops.ietf.org; Tue, 06 May 2003 21:13:26 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h46LDEg08565; Wed, 7 May 2003 00:13:14 +0300 Date: Wed, 7 May 2003 00:13:12 +0300 (EEST) From: Pekka Savola To: Joe Abley cc: Iljitsch van Beijnum , Kurt Erik Lindqvist , Subject: v4 multihoming doc [Re: IETF multihoming powder: just add IPv6 and stir] In-Reply-To: <06A91EE3-7CCA-11D7-AA27-00039312C852@isc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 2 May 2003, Joe Abley wrote: > On Friday, May 2, 2003, at 09:09 Canada/Eastern, Iljitsch van Beijnum > wrote: > > > There are quite a few limitations for people that want to multihome in > > v4. Not everyone may be aware of those and subsequently underestimate > > the latent need for multihoming. So it might be good to document this > > after all. > > I am still very happy to collate ideas and edit that document, if > people are happy for me to do so. > > The main reason it stalled last time was that I wasn't happy being the > only one writing down a description of current practices, since many > different people are doing many different things for many different > reasons, and there weren't many contributors to the doc at the time. It > got as far as "rip all the v4 stuff out of the requirements doc into a > separate doc", and that was about it. As stated previously, I think the v4 document would be worthwhile. I'm willing to work on it, and I think I've some stuff in my thesis for extracting that would fit the bill quite nicely. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Tue May 6 17:23:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09651 for ; Tue, 6 May 2003 17:23:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19D9wS-000CNO-00 for multi6-data@psg.com; Tue, 06 May 2003 21:25:40 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19D9wO-000CMr-00 for multi6@ops.ietf.org; Tue, 06 May 2003 21:25:36 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h46LPYv08641 for ; Wed, 7 May 2003 00:25:34 +0300 Date: Wed, 7 May 2003 00:25:33 +0300 (EEST) From: Pekka Savola To: multi6@ops.ietf.org Subject: Re: New draft: Now What? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi, Anyone (else S Woodside :-) had time to read my "roadmap" document yet? http://www.ietf.org/internet-drafts/draft-savola-multi6-nowwhat-00.txt I'd be very interesteded in receiving feedback on it. In particular, the document classifies the sites in 4 different categories, and makes a hypothesis on their multihoming requirements, like: .--------------.------------.--------------. | Independence | Redundancy | Load sharing | .--------------+--------------+------------+--------------+ |Minimal | no | no | no | |Small | maybe | maybe | no | |Large | maybe/yes | yes | maybe | |International | yes | yes | yes | '--------------'--------------'------------'--------------' * Do the classifications seem close to reality? * Does the hypothesis on their typical requirements seem to be close to the mark? As one another point that was raised was a way forward; basically, a short term goal being on multi-connecting, host-centric multihoming, multihoming at site exit routers and a PI-based addressing for the "International" and possibly even some "Large" site classifications. An alternative to PI-based addressing might be a different concept of breaking such big "sites" into smaller pieces. * Do these immediate/short term goals seem reasonable? * Are there some short-term goals which I've missed? * Do folks think that we need a PI-based (de facto) addressing/multihoming solutions for a class of sites (think "Cisco", "Nokia", "IBM", etc.)? * Do folks think that actually defining a border between those which could use PI-based addressing and those who couldn't would be possible? * Do folks agree that we should continue the work with host-centric multihoming/multihoming at site-exit routers -type solutions? There missing pieces there (ingress filtering, tunneling overhead with RFC3178, etc.) Some food for thought... On Fri, 25 Apr 2003, Pekka Savola wrote: > As promised, here's a new draft which has been partially extracted from my > MSc (also plugged in here earlier): > > http://www.netcore.fi/pekkas/ietf/draft-savola-multi6-nowwhat-00.txt > > (It has also been submitted to the I-D repository, and will probably > appear next week -- but I know you guys like spending time reading drafts > during the weekend, so here we go.. :-) > > In particular the goal is to make us able to focus our thoughts a bit and > try to break the site multihoming into a bit smaller pieces. > > It's 15 pages; the abstract is below. Have fun. > > Abstract > > ROUTING ARCHITECT'S WARNING: flagrant IPv4 site multihoming practices > cause a significant increase the routing table size, change rates and > instability, the tragedy of the commons by encouraging selfish > routing practices, the exhaustion of the 16-bit AS number space, and > may collapse the Internet interdomain routing architecture. > > As there has been a desire to avoid similar problems as seen with > IPv4, the use of similar techniques to achieve site multihoming has > been prevented operationally in IPv6. However, the long effort to > proceed with other IPv6 multihoming mechanisms has produced lots of > heat but little light. This memo tries to list available techniques, > split the organizations to different types to separately examine > their multihoming needs, to look at the immediate and short-term > solutions for these organization types, and to list a few immediate > action items on how to proceed with IPv6 site multihoming. > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Tue May 6 19:34:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14168 for ; Tue, 6 May 2003 19:34:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DBzF-000G7S-00 for multi6-data@psg.com; Tue, 06 May 2003 23:36:41 +0000 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.36 #1) id 19DBzA-000G5j-00 for multi6@ops.ietf.org; Tue, 06 May 2003 23:36:36 +0000 Received: (qmail 15455 invoked by uid 0); 6 May 2003 23:36:35 -0000 Received: from localhost.automagic.org (HELO isc.org) (root@127.0.0.1) by localhost.automagic.org with SMTP; 6 May 2003 23:36:35 -0000 Date: Tue, 6 May 2003 19:36:34 -0400 Subject: Re: comments on requirements-05 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Kurt Erik Lindqvist , To: Pekka Savola From: Joe Abley In-Reply-To: Message-Id: <92AA0B9C-801B-11D7-AA27-00039312C852@isc.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, On Tuesday, May 6, 2003, at 17:11 Canada/Eastern, Pekka Savola wrote: > On Mon, 5 May 2003, Kurt Erik Lindqvist wrote: >>> Could we restart the last call, on the basis of the -05 draft? >>> My answer on that is: ship it! >> >> Me and Sean have discussed around this last-call in private and we are >> both really in favor of getting this shipped ASAP. Unless anyone have >> come up with a really compelling reason not to ship it by Wen 12.00 >> CET >> we will ship it. The -05 draft that is. > > I've done a quick review on the document. > > There are lots of things that should be clarified, but all should be > rather easily editable. The document name should also be changed > (s/requirements/goals/) if that's possible. I don't think it's worth changing the name; if we do that we lose the version control of the document since we have to start again as -00. The name of the draft will become largely irrelevant if it is published as an RFC. > substantial > ----------- > 1) the terminology should be improved to be more precise. > > A "transit provider" operates a site which directly provides > connectivity to the Internet to one or more external sites. The > connectivity provided extends beyond the transit provider's own > site. > A transit provider's site is directly connected to the sites for > which it provides transit. > > ==> should be reworded to remove references to "transit provider is a > site" -concept, which is irrelevant and confusing in this context. Please explain. > A "multihomed" site is one with more than one transit provider. > "Site-multihoming" is the practice of arranging a site to be > multihomed. > > ==> this also needs rewording. In general, the term "transit provider" > is applied to network service providers which are in the middle of the > packet forwarding chain. I do not call first-hop upstream providers > transit providers. The term "transit" here is also misleading because > it IMO points to the difference between "transit" and "peering", > which do not apply to end-sites. When I originally put forward these definitions, it was because lots of different people had widely differing opinions about what exactly the terms "transit", "site", "network", etc meant. It was not possible to produce definitions that suited the meanings entrenched in everybody's heads, so I settled on a set that seemed to work for the majority of people. [The reason these definitions are there at all is to disambiguate the document, given the differing opinions of those terms]. I would prefer to leave those definitions alone, unless there are concepts which need to be understood in the text of the draft which are not accommodated by the definitions that are there. > 2) simplicity for the internet and/or the site should be made explicit. > > 3.1.5 Simplicity > > As any proposed multihoming solution must be deployed in real > networks with real customers, simplicity is paramount. The current > multihoming solution is quite straightforward to deploy and > maintain. > A new IPv6 multihoming proposal should not be substantially more > complex to deploy and operate than current IPv4 multihoming > practices. > > ==> there are two aspects to the simplicity, with two different axes: > - simplicity to those who deploy it, and to those that don't > - simplicity to the Big Internet as a whole and the end-site itself I don't see those as orthogonal; your second line looks to me like a rewording of the first line (taking the Big Internet to be a collection of people who do and don't deploy multihoming). Perhaps you could explain that further. > 3) there are a few especially worrisome goals. > > 3.1.2 Load Sharing > > By multihoming, a site should be able to distribute both inbound and > outbound traffic between multiple transit providers. > > 3.1.3 Performance > > [...] > > A multihomed site should be able to distribute inbound traffic from > particular multiple transit providers according to the particular > address range within their site which is sourcing or sinking the > traffic. > > ==> typically "inbound traffic balancing", especially as made a very > specific and detailed goal by "performance", go a long way in the "very > potentially unscalable" territory. > > Therefore, I'd like to add some disclaimers or a few additional words > to > these goals -- but I don't know how and what in particular. > > Anyone else worried? These two particular requirements (when they were being called requirements) were discussed at some length on this list. The reason they were in the document was that they are capabilities which are widely used by sites which multi-home today, and any replacement multihoming strategy probably needs to support them if it is going to be adopted by people in the real world. The concern people had about whether any single solution would meet all of these requirements was what led us to replace the "requirements" word with "goals". > 4) document assumes the Internet transit/ISP architecture is a single > administrative entity > > 3.1.8 Packet Filtering > > Multihoming solutions should not preclude filtering packets with > forged or otherwise inappropriate source IP addresses at the > administrative boundary of the multihomed site. > > ==> replace from the end (remove the period): > > , or administrative > boundaries between any transit providers in the Internet. > > (this is done to facilitate for the fact that the Internet is *not* > just > a homogenous single routing blob -- "once you're in, you're in for > good"). I'm not sure that additional sentiment is required, but I wouldn't object to it going in. > 5) co-operation (non)goals are not explicit about third party ISP's and > non-direct transit ISP's > > 3.2.6 Cooperation between Transit Providers > > A multihoming strategy may require cooperation between a site and > its > transit providers, but should not require cooperation (relating > specifically to the multihomed site) directly between the transit > providers. > > ==> particularly if the "transit provider" terminology is not > redefined, > this needs to be very much clarified. I believe the above text is > used to > refer to the direct first-hop upstream providers of the site only. Your interpretation is correct. I think this is implicit in the way that "transit provider" is currently defined (it says "A transit provider's site is directly connected to the sites for which it provides transit."). > It > should also say that co-operation with any of the site's transit > providers > and any of their peers or transits should not be required ("no > requirement > for third parties", here transit of the transit being a 2 1/2 party) I'm not sure what you're intending to say here; co-operation between whom and any of the site's transit providers? Who is "their" in "their peers or transits"? > semi-editorial/substantial > -------------------------- > For purposes of > redundancy and load-sharing, the multihomed address blocks, which > are > almost always a longer prefix than the provider aggregate, are > announced along with the larger, covering aggregate originated by > the > provider. > > ==> s/redundancy/redundancy, independence/ No, I don't think there's any "independence" rationale there; these are covered prefixes describing PA assignments, not announcements of PI space. > This contributes to the rapidly-increasing size of the > global routing table. > > ==> s/size/size and dynamicity/ (better word than dynamicity?!?!) complexity? > By multihoming, a site should be able to distribute both inbound and > outbound traffic between multiple transit providers. This > requirement > is for concurrent use of the multiple transit providers, not just > the > > ==> s/requirement/goal/ Good catch. > 3.2.2 Impact on Routers > > The solution may require changes to IPv6 router implementations, but > > ==> s/solution/solutions/ -- many more under section 3.2.x. The text > seems to indicate that a single solution would fit the bill. Fair enough. > Normative References > > ==> references section should be numbered. It will do what xml2rfc decides is right. Unless there is tremendous breakage in xml2rfc's output (in which case let's tell Dr Rose) I'm inclined to leave these bits as they are. > [4] Hinden, R., O'Dell, M. and S. Deering, "An IPv6 Aggregatable > Global Unicast Address Format", RFC 2374, July 1998. > > ==> this ref is no longer used in the body, and good riddance. Remove. Good catch. > > [7] Huston, G., "Analyzing the Internet's BGP Routing Table", > January 2001. > > ==> especially for a *normative reference*, the reference should IMO be > much > more explicit (e.g. refer to a publication and give a URL or the like). I will find an URL. > editorial > --------- > site-multihoming > > ==>s/site-multihoming/site multihoming/ (everywhere) ? This seems a > more > common practice..? I have no opinion on this. > providers may share a single conduit from the street into a > building; > in this case backhoe-fade of both circuits may be experienced due to > > ==> "backhoe-fade" ? No idea what that means, and couldn't find it > in a dictionary either. http://www.net.oregonstate.edu/netvideo/dugout.html > demonstrate that the modified name resolution system required to > support them are readily deployable. > > ==> s/are/is/ Good catch, > The multihoming solution may allow host or application changes if > that would enhance session survivability. > > ==> s/session/transport-layer/ (to make a more explicit reference to > the goal presented earlier) Good catch, and... > > It should be posssible for staff responsible for the operation of a > > ==> s/posssible/possible/ Good catch. Thanks :) Joe From owner-multi6@ops.ietf.org Tue May 6 22:57:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18429 for ; Tue, 6 May 2003 22:57:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DF84-0006c9-00 for multi6-data@psg.com; Wed, 07 May 2003 02:58:00 +0000 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 19DF7Y-0006Z8-00 for multi6@ops.ietf.org; Wed, 07 May 2003 02:57:28 +0000 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 80EC8137F15; Tue, 6 May 2003 19:57:27 -0700 (PDT) Date: Tue, 6 May 2003 19:57:25 -0700 Subject: Re: WG last-call draft-ietf-multi6-multihoming-requirements-05.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Kurt Erik Lindqvist , Brian E Carpenter , multi6@ops.ietf.org To: Joe Abley From: David Conrad In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In reviewing the draft, I see that it is more generic than simply site multihoming. Specifically, the last paragraph of 3.1.3 and section 3.1.4 imply an ability to multihome down to a specific host (address range of 1) and applications (e.g., nntp servers) respectively. I am not sure if or how this should be clarified -- perhaps it was just me jumping to the wrong conclusion. Rgds, -drc On Tuesday, May 6, 2003, at 06:15 AM, Joe Abley wrote: > > On Tuesday, May 6, 2003, at 04:14 Canada/Eastern, Kurt Erik Lindqvist > wrote: > >> I would say no for this version. We might want to publish a new >> version later on when we have a more clear picture. > > Sections 3.1.4 and 3.2.4 kind of hint at this capability already. It's > not very explicit, but since all the MUSTs and MUST NOTs have been > stripped from the document, I don't think this should keep anybody > awake at night. > > So I also say "no for this version". > > > Joe > > From owner-multi6@ops.ietf.org Tue May 6 23:02:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18560 for ; Tue, 6 May 2003 23:02:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DFFF-00077w-00 for multi6-data@psg.com; Wed, 07 May 2003 03:05:25 +0000 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 19DFET-000741-00 for multi6@ops.ietf.org; Wed, 07 May 2003 03:04:37 +0000 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 86EF7137F15; Tue, 6 May 2003 20:04:36 -0700 (PDT) Date: Tue, 6 May 2003 20:04:35 -0700 Subject: Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Brian E Carpenter From: David Conrad In-Reply-To: <3EB76980.CD3B80D4@hursley.ibm.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-15.9 required=5.0 tests=BAYES_00,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > If the prefix is mutable en route, it doesn't matter that it's > globally unique: the end points can't use it as part of any checksum, > so either you have to add HIP, or the 64 bit suffix has to be > unique enough for checksum purposes. Or you simply rewrite the first 48 bits when the packet traverses the border into the destination site with the same value the packet had prior to traversing the border of the source site. Rgds, -drc From owner-multi6@ops.ietf.org Tue May 6 23:06:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18655 for ; Tue, 6 May 2003 23:06:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DFIb-0007OG-00 for multi6-data@psg.com; Wed, 07 May 2003 03:08:53 +0000 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 19DFI5-0007Kk-00 for multi6@ops.ietf.org; Wed, 07 May 2003 03:08:21 +0000 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 59D2F137F15; Tue, 6 May 2003 20:08:20 -0700 (PDT) Date: Tue, 6 May 2003 20:08:19 -0700 Subject: Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Christian Huitema , multi6@ops.ietf.org To: Pekka Nikander From: David Conrad In-Reply-To: <3EB7501C.9060706@nomadiclab.com> Message-Id: <27AA2950-8039-11D7-961B-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-19.4 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday, May 5, 2003, at 11:03 PM, Pekka Nikander wrote: > Secure DNS has been shown not to be scalable in practise. Oh? References? Rgds, -drc From owner-multi6@ops.ietf.org Wed May 7 02:31:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17964 for ; Wed, 7 May 2003 02:31:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DITI-000Ntl-00 for multi6-data@psg.com; Wed, 07 May 2003 06:32:08 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19DITF-000NtY-00 for multi6@ops.ietf.org; Wed, 07 May 2003 06:32:06 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h476Uln15146; Wed, 7 May 2003 08:30:47 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 7 May 2003 08:30:47 +0200 Subject: Re: comments on requirements-05 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: Joe Abley From: Iljitsch van Beijnum In-Reply-To: <92AA0B9C-801B-11D7-AA27-00039312C852@isc.org> Message-Id: <70670C16-8055-11D7-820B-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-28.3 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On woensdag, mei 7, 2003, at 01:36 Europe/Amsterdam, Joe Abley wrote: >> [7] Huston, G., "Analyzing the Internet's BGP Routing Table", >> January 2001. >> ==> especially for a *normative reference*, the reference should IMO >> be much >> more explicit (e.g. refer to a publication and give a URL or the >> like). > I will find an URL. Seems all of this is suffering from "broken-URL-itis". You can probably find something resembling the original in Cisco's Internet Protocol Journal, but it has since become an RFC unless I'm very much mistaken: http://www.ietf.org/rfc/rfc3221.txt Also note that things have changed since then (only 8% growth), Geoff presented a different story at Apricot 2002: http://www.apricot2002.net/download/Conference/22/01.pdf "An Examination of the Internet's BGP Table Behaviour in 2001" but again the URL is broken. (There should be a law against that.) Also, he unfairly blames multihomers, while not aggregating is the number one, two and three reason for the growth in the global routing table. >> ==> "backhoe-fade" ? No idea what that means, and couldn't find it >> in a dictionary either. > http://www.net.oregonstate.edu/netvideo/dugout.html So are you going to include the URL in the text or what??? Remember that RFCs are published by an international standards organization. As such, the text should be clear also for people who have English as their second or third language and are unfamiliar with American colloquialisms. Iljitsch From owner-multi6@ops.ietf.org Wed May 7 04:11:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20183 for ; Wed, 7 May 2003 04:11:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DK32-0008U9-00 for multi6-data@psg.com; Wed, 07 May 2003 08:13:08 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19DK2t-0008TT-00 for multi6@ops.ietf.org; Wed, 07 May 2003 08:13:00 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h478Cqv12763; Wed, 7 May 2003 11:12:52 +0300 Date: Wed, 7 May 2003 11:12:52 +0300 (EEST) From: Pekka Savola To: Joe Abley cc: Kurt Erik Lindqvist , Subject: Re: comments on requirements-05 In-Reply-To: <92AA0B9C-801B-11D7-AA27-00039312C852@isc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 6 May 2003, Joe Abley wrote: > On Tuesday, May 6, 2003, at 17:11 Canada/Eastern, Pekka Savola wrote: > > On Mon, 5 May 2003, Kurt Erik Lindqvist wrote: > >>> Could we restart the last call, on the basis of the -05 draft? > >>> My answer on that is: ship it! > >> > >> Me and Sean have discussed around this last-call in private and we are > >> both really in favor of getting this shipped ASAP. Unless anyone have > >> come up with a really compelling reason not to ship it by Wen 12.00 > >> CET > >> we will ship it. The -05 draft that is. > > > > I've done a quick review on the document. > > > > There are lots of things that should be clarified, but all should be > > rather easily editable. The document name should also be changed > > (s/requirements/goals/) if that's possible. > > I don't think it's worth changing the name; if we do that we lose the > version control of the document since we have to start again as -00. > The name of the draft will become largely irrelevant if it is published > as an RFC. Indeed. However, the misleading names have often caused confusion at IETF LC and IESG review time, from those who haven't read it properly. However, IETF LC is not necessary for this document, and it states rather clearly in the abstract that these are goals, not requirements -- so this seems ~OK. > > substantial > > ----------- > > 1) the terminology should be improved to be more precise. > > > > A "transit provider" operates a site which directly provides > > connectivity to the Internet to one or more external sites. The > > connectivity provided extends beyond the transit provider's own > > site. > > A transit provider's site is directly connected to the sites for > > which it provides transit. > > > > ==> should be reworded to remove references to "transit provider is a > > site" -concept, which is irrelevant and confusing in this context. > > Please explain. Typically "site" is considered to be an "end-site", in the transit provider's case, the NOC of the transit provider. The backbone of the transit provider, possibly spanning contininents, seems to stretch the definition and the mental picture of a "site" pretty far. > > A "multihomed" site is one with more than one transit provider. > > "Site-multihoming" is the practice of arranging a site to be > > multihomed. > > > > ==> this also needs rewording. In general, the term "transit provider" > > is applied to network service providers which are in the middle of the > > packet forwarding chain. I do not call first-hop upstream providers > > transit providers. The term "transit" here is also misleading because > > it IMO points to the difference between "transit" and "peering", > > which do not apply to end-sites. > > When I originally put forward these definitions, it was because lots of > different people had widely differing opinions about what exactly the > terms "transit", "site", "network", etc meant. It was not possible to > produce definitions that suited the meanings entrenched in everybody's > heads, so I settled on a set that seemed to work for the majority of > people. > > [The reason these definitions are there at all is to disambiguate the > document, given the differing opinions of those terms]. > > I would prefer to leave those definitions alone, unless there are > concepts which need to be understood in the text of the draft which are > not accommodated by the definitions that are there. I'm not sure if these are OK. In some cases in the document, at least, it is important to refer to the upstreams of the first-hop ISP's. With the current terminology, that's difficult. Also, the text may be rather ambiguous as it doesn't seem to match the common understanding of what "transit provider" typically is. XXXX > > 2) simplicity for the internet and/or the site should be made explicit. > > > > 3.1.5 Simplicity > > > > As any proposed multihoming solution must be deployed in real > > networks with real customers, simplicity is paramount. The current > > multihoming solution is quite straightforward to deploy and > > maintain. > > A new IPv6 multihoming proposal should not be substantially more > > complex to deploy and operate than current IPv4 multihoming > > practices. > > > > ==> there are two aspects to the simplicity, with two different axes: > > - simplicity to those who deploy it, and to those that don't > > - simplicity to the Big Internet as a whole and the end-site itself > > I don't see those as orthogonal; your second line looks to me like a > rewording of the first line (taking the Big Internet to be a collection > of people who do and don't deploy multihoming). Perhaps you could > explain that further. There is a slight difference there, in my eyes. The first item separates "multihomed site and its ISP(s) and possibly their transits" and "everyone else". The second item separates "multihoming end-site" and "everyone else (including their ISPs)". I was not sure how to reword that better, but I do believe there are differences here. > > 3) there are a few especially worrisome goals. > > > > 3.1.2 Load Sharing > > > > By multihoming, a site should be able to distribute both inbound and > > outbound traffic between multiple transit providers. > > > > 3.1.3 Performance > > > > [...] > > > > A multihomed site should be able to distribute inbound traffic from > > particular multiple transit providers according to the particular > > address range within their site which is sourcing or sinking the > > traffic. > > > > ==> typically "inbound traffic balancing", especially as made a very > > specific and detailed goal by "performance", go a long way in the "very > > potentially unscalable" territory. > > > > Therefore, I'd like to add some disclaimers or a few additional words > > to > > these goals -- but I don't know how and what in particular. > > > > Anyone else worried? > > These two particular requirements (when they were being called > requirements) were discussed at some length on this list. The reason > they were in the document was that they are capabilities which are > widely used by sites which multi-home today, and any replacement > multihoming strategy probably needs to support them if it is going to > be adopted by people in the real world. Real world is not set in stone, the procedures can change. I fear we'll fail if they don't, and we have an attitude "something is done like this, so we must always be able to do the same thing, unchanged". But.. > The concern people had about whether any single solution would meet all > of these requirements was what led us to replace the "requirements" > word with "goals". .. yes. > > 4) document assumes the Internet transit/ISP architecture is a single > > administrative entity > > > > 3.1.8 Packet Filtering > > > > Multihoming solutions should not preclude filtering packets with > > forged or otherwise inappropriate source IP addresses at the > > administrative boundary of the multihomed site. > > > > ==> replace from the end (remove the period): > > > > , or administrative > > boundaries between any transit providers in the Internet. > > > > (this is done to facilitate for the fact that the Internet is *not* > > just > > a homogenous single routing blob -- "once you're in, you're in for > > good"). > > I'm not sure that additional sentiment is required, but I wouldn't > object to it going in. I feel it's important, but I'm willing to hear what others think. > > 5) co-operation (non)goals are not explicit about third party ISP's and > > non-direct transit ISP's > > > > 3.2.6 Cooperation between Transit Providers > > > > A multihoming strategy may require cooperation between a site and > > its > > transit providers, but should not require cooperation (relating > > specifically to the multihomed site) directly between the transit > > providers. > > > > ==> particularly if the "transit provider" terminology is not > > redefined, > > this needs to be very much clarified. I believe the above text is > > used to > > refer to the direct first-hop upstream providers of the site only. > > Your interpretation is correct. I think this is implicit in the way > that "transit provider" is currently defined (it says "A transit > provider's site is directly connected to the sites for which it > provides transit."). > > > It should also say that co-operation with any of the site's transit > > providers and any of their peers or transits should not be required > > ("no requirement for third parties", here transit of the transit being > > a 2 1/2 party) > > I'm not sure what you're intending to say here; co-operation between > whom and any of the site's transit providers? Who is "their" in "their > peers or transits"? Let's try to illustrate: Site S / \ ISP A -- ISP B | | Transit1 - Transit2 -- [ Internet ] | \ [Internet] [Internet] Co-operation is currently a goal with Site S <-> ISP A and Site S <-> ISP B. It is not with ISP A <-> ISP B. This doesn't take a stance on even more non-goal co-operation, with e.g. - Site S <-> Transit1 - ISP A <-> Transit1 - ISP A <-> Transit2 - Site S <-> [Internet] - ISP A <-> [Internet] - Transit1 <-> [Internet] > > semi-editorial/substantial > > -------------------------- > > For purposes of > > redundancy and load-sharing, the multihomed address blocks, which > > are > > almost always a longer prefix than the provider aggregate, are > > announced along with the larger, covering aggregate originated by > > the > > provider. > > > > ==> s/redundancy/redundancy, independence/ > > No, I don't think there's any "independence" rationale there; these are > covered prefixes describing PA assignments, not announcements of PI > space. There certainly is, if you can, and in practice do, take the portion of the PA with you, to another provider. The text in the introduction does not require the site to advertise the more specific from the behind the direct ISP: as long as a covering aggregate (from somewhere else) exists, you're fine. But why do you then say: the multihomed address blocks, which are almost always a longer prefix than the provider aggregate, ==> there is no "coverage" if it is not a longer prefix. In any case, the introduction is incomplete. Multihoming is also done with PI addresses, without covering aggregates. The introduction should be either modified to be a bit more descriptive (or generic), or make a reference to the v4 multihoming draft (which would require us to start working on it again) -- which should be there anyway, at least as an informational ref. > > This contributes to the rapidly-increasing size of the > > global routing table. > > > > ==> s/size/size and dynamicity/ (better word than dynamicity?!?!) > > complexity? Complexity is too generic a term unfortunately, it doesn't imply anything about the advertise/withdraw cycles caused by site multihoming. > > Normative References > > > > ==> references section should be numbered. > > It will do what xml2rfc decides is right. Unless there is tremendous > breakage in xml2rfc's output (in which case let's tell Dr Rose) I'm > inclined to leave these bits as they are. Nothing major but: http://www.rfc-editor.org/policy.html states "s. Normative References" and "s+1. Informative References". > > providers may share a single conduit from the street into a > > building; > > in this case backhoe-fade of both circuits may be experienced due to > > > > ==> "backhoe-fade" ? No idea what that means, and couldn't find it > > in a dictionary either. > > http://www.net.oregonstate.edu/netvideo/dugout.html A bit too technical term, when a simpler, generally understandable way to say something to the same effect might be possible. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Wed May 7 04:28:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20774 for ; Wed, 7 May 2003 04:28:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DKKr-000Aiq-00 for multi6-data@psg.com; Wed, 07 May 2003 08:31:33 +0000 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 3.36 #1) id 19DKKo-000AiJ-00 for multi6@ops.ietf.org; Wed, 07 May 2003 08:31:31 +0000 Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 18CEB1C; Wed, 7 May 2003 11:41:27 +0300 (EEST) Message-ID: <3EB8C48B.6070409@nomadiclab.com> Date: Wed, 07 May 2003 11:32:11 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Conrad Cc: multi6@ops.ietf.org Subject: Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] References: <27AA2950-8039-11D7-961B-000393DB42B2@nominum.com> In-Reply-To: <27AA2950-8039-11D7-961B-000393DB42B2@nominum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-35.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit David Conrad wrote: > On Monday, May 5, 2003, at 11:03 PM, Pekka Nikander wrote: > >> Secure DNS has been shown not to be scalable in practise. > > Oh? References? Well, apparently I should have been more careful with my wording. No, it has not been scientifically (by analysis) shown not to be scalable. I was merely referring to the current state of deployment and to my admittedly very limited practical experience, mostly within the scope of Mobile IPv6 security design team. Maybe I am wrong, and in any case my statement above was far too strong. Sorry about that. Now, what I was referring to was merely our strawman analysis of what happens if you use secure reverse DNS to verify if someone is authorized to use a particular address. I didn't find the text any more (maybe it is available in the DT archives, but I don't know where they are). Anyway, the result was that you typially end up doing maybe 7-8 DNS queries and verifying 10-12 public key certificates, or something like that. Not really scalable if you would need to do that for each address that you get. Thinking about the issue a little bit more, it is not at all clear whether we need secure reverse DNS in this case at all. If we want to securely resolve host identifiers (second 16s or whatever) into locators, maybe we need. In that case the analysis applies, and should probably be made again, perphaps with more rigor this time. --Pekka Nikander From owner-multi6@ops.ietf.org Wed May 7 05:05:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21535 for ; Wed, 7 May 2003 05:05:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DKu3-000FX6-00 for multi6-data@psg.com; Wed, 07 May 2003 09:07:55 +0000 Received: from mail-gw1.hursley.ibm.com ([194.196.110.15]) by psg.com with esmtp (Exim 3.36 #1) id 19DKtz-000FWi-00 for multi6@ops.ietf.org; Wed, 07 May 2003 09:07:51 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19DKty-00017j-00; Wed, 07 May 2003 10:07:50 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19DKty-00017e-00; Wed, 07 May 2003 10:07:50 +0100 Received: from hursley.ibm.com (dhcp21-189.zurich.ibm.com [9.4.21.189]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id KAA161616; Wed, 7 May 2003 10:07:48 +0100 Message-ID: <3EB8CD07.BCD04EFD@hursley.ibm.com> Date: Wed, 07 May 2003 11:08:23 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: David Conrad CC: multi6@ops.ietf.org Subject: Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit David Conrad wrote: > > > If the prefix is mutable en route, it doesn't matter that it's > > globally unique: the end points can't use it as part of any checksum, > > so either you have to add HIP, or the 64 bit suffix has to be > > unique enough for checksum purposes. > > Or you simply rewrite the first 48 bits when the packet traverses the > border into the destination site with the same value the packet had > prior to traversing the border of the source site. This was not part of any GSE proposal I ever saw, and it involves stateful distribution of mapping information. A very different beast from GSE, and it sets off my stateful=bad alarm. Brian From owner-multi6@ops.ietf.org Wed May 7 07:40:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25042 for ; Wed, 7 May 2003 07:40:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DNJY-000CdO-00 for multi6-data@psg.com; Wed, 07 May 2003 11:42:24 +0000 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 3.36 #1) id 19DNJW-000Cd7-00 for multi6@ops.ietf.org; Wed, 07 May 2003 11:42:22 +0000 Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id EE8911C for ; Wed, 7 May 2003 14:52:19 +0300 (EEST) Message-ID: <3EB8F148.6030409@nomadiclab.com> Date: Wed, 07 May 2003 14:43:04 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: New version of the HIP architecture draft Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-12.9 required=5.0 tests=BAYES_01,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I just submitted a new version of the HIP architecture draft, draft-moskowitz-hip-arch-03.txt, to the repositories. In the meanwhile, the draft is available at http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-03.txt http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-03.html http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-03.xml This is a high level description of our current HIP thinking. It doesn't discuss multihoming much, but that is mentioned. We are planning to prepare the next version towards the end of May. Please read and comment before that. --Pekka Nikander From owner-multi6@ops.ietf.org Wed May 7 09:05:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28993 for ; Wed, 7 May 2003 09:05:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DOdz-0001lO-00 for multi6-data@psg.com; Wed, 07 May 2003 13:07:35 +0000 Received: from maunaloa.aafes.com ([199.67.7.206]) by psg.com with esmtp (Exim 3.36 #1) id 19DOdt-0001k7-00 for multi6@ops.ietf.org; Wed, 07 May 2003 13:07:29 +0000 Received: (from daemon@localhost) by maunaloa.aafes.com (8.12.9/8.12.9) id h47D7Dih052304; Wed, 7 May 2003 08:07:13 -0500 (CDT) Received: from hqexch01.aafes.com(192.168.32.32) via SMTP by maunaloa.aafes.com, id smtpd7Br9UU; Wed May 7 08:07:05 2003 Received: by hqexch01.aafes.com with Internet Mail Service (5.5.2655.55) id ; Wed, 7 May 2003 08:07:05 -0500 Message-ID: From: "Grovesteen, Harold" To: "'Pekka Savola'" , Kurt Erik Lindqvist Cc: Joe Abley , multi6@ops.ietf.org Subject: RE: comments on requirements-05 Date: Wed, 7 May 2003 08:07:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-22.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,ORIGINAL_MESSAGE, QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Requirements/goals which are subjective and arbitrary should be avoided. "Simplicity" is subjective. How is something determined to be simple or not? Simplicity is in the eye of the beholder. Some things are simple by nature others are not. Whatever architecture is developed here may or may not be simple and that depends upon who looks at it. The entire set of goals about traffic engineering are arbitrary. Organizations engineer traffic for totally non-technical reasons which can be neither anticipated nor guaranteed architecturally because they tend to be capabilities offered by specific implementations. We can not seem to agree on basic functionality or requirements that truly are such. Subjective and arbitrary goals simply muddy the waters. Of course, since everything is "should" or "should not," I am not sure that any content has real value. It can always be argued that although something only should or should not be there no requirement actually exists. I am hoping Vienna will sort some of these issues out and provide a clear direction which may make the "requirement" document somewhat moot. Harold Grovesteen -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: Tuesday, May 06, 2003 4:11 PM To: Kurt Erik Lindqvist Cc: Joe Abley; multi6@ops.ietf.org Subject: comments on requirements-05 On Mon, 5 May 2003, Kurt Erik Lindqvist wrote: > > Could we restart the last call, on the basis of the -05 draft? > > My answer on that is: ship it! > > Me and Sean have discussed around this last-call in private and we are > both really in favor of getting this shipped ASAP. Unless anyone have > come up with a really compelling reason not to ship it by Wen 12.00 CET > we will ship it. The -05 draft that is. I've done a quick review on the document. There are lots of things that should be clarified, but all should be rather easily editable. The document name should also be changed (s/requirements/goals/) if that's possible. substantial ----------- 1) the terminology should be improved to be more precise. A "transit provider" operates a site which directly provides connectivity to the Internet to one or more external sites. The connectivity provided extends beyond the transit provider's own site. A transit provider's site is directly connected to the sites for which it provides transit. ==> should be reworded to remove references to "transit provider is a site" -concept, which is irrelevant and confusing in this context. A "multihomed" site is one with more than one transit provider. "Site-multihoming" is the practice of arranging a site to be multihomed. ==> this also needs rewording. In general, the term "transit provider" is applied to network service providers which are in the middle of the packet forwarding chain. I do not call first-hop upstream providers transit providers. The term "transit" here is also misleading because it IMO points to the difference between "transit" and "peering", which do not apply to end-sites. ==> therefore, I think the last three terms could be reworded a bit. (I might be able to try to help with some text if needed and folks agree.) ==> similar consideration wrt. "transit" applies to the rest of the document. 2) simplicity for the internet and/or the site should be made explicit. 3.1.5 Simplicity As any proposed multihoming solution must be deployed in real networks with real customers, simplicity is paramount. The current multihoming solution is quite straightforward to deploy and maintain. A new IPv6 multihoming proposal should not be substantially more complex to deploy and operate than current IPv4 multihoming practices. ==> there are two aspects to the simplicity, with two different axes: - simplicity to those who deploy it, and to those that don't - simplicity to the Big Internet as a whole and the end-site itself Solutions will probably not be simple for all of these; stating these explicitly will make the solution designers aware of different aspects of simplicity which should be considered. 3) there are a few especially worrisome goals. 3.1.2 Load Sharing By multihoming, a site should be able to distribute both inbound and outbound traffic between multiple transit providers. 3.1.3 Performance [...] A multihomed site should be able to distribute inbound traffic from particular multiple transit providers according to the particular address range within their site which is sourcing or sinking the traffic. ==> typically "inbound traffic balancing", especially as made a very specific and detailed goal by "performance", go a long way in the "very potentially unscalable" territory. Therefore, I'd like to add some disclaimers or a few additional words to these goals -- but I don't know how and what in particular. Anyone else worried? 4) document assumes the Internet transit/ISP architecture is a single administrative entity 3.1.8 Packet Filtering Multihoming solutions should not preclude filtering packets with forged or otherwise inappropriate source IP addresses at the administrative boundary of the multihomed site. ==> replace from the end (remove the period): , or administrative boundaries between any transit providers in the Internet. (this is done to facilitate for the fact that the Internet is *not* just a homogenous single routing blob -- "once you're in, you're in for good"). 5) co-operation (non)goals are not explicit about third party ISP's and non-direct transit ISP's 3.2.6 Cooperation between Transit Providers A multihoming strategy may require cooperation between a site and its transit providers, but should not require cooperation (relating specifically to the multihomed site) directly between the transit providers. ==> particularly if the "transit provider" terminology is not redefined, this needs to be very much clarified. I believe the above text is used to refer to the direct first-hop upstream providers of the site only. It should also say that co-operation with any of the site's transit providers and any of their peers or transits should not be required ("no requirement for third parties", here transit of the transit being a 2 1/2 party) semi-editorial/substantial -------------------------- For purposes of redundancy and load-sharing, the multihomed address blocks, which are almost always a longer prefix than the provider aggregate, are announced along with the larger, covering aggregate originated by the provider. ==> s/redundancy/redundancy, independence/ This contributes to the rapidly-increasing size of the global routing table. ==> s/size/size and dynamicity/ (better word than dynamicity?!?!) By multihoming, a site should be able to distribute both inbound and outbound traffic between multiple transit providers. This requirement is for concurrent use of the multiple transit providers, not just the ==> s/requirement/goal/ 3.2.2 Impact on Routers The solution may require changes to IPv6 router implementations, but ==> s/solution/solutions/ -- many more under section 3.2.x. The text seems to indicate that a single solution would fit the bill. Normative References ==> references section should be numbered. [4] Hinden, R., O'Dell, M. and S. Deering, "An IPv6 Aggregatable Global Unicast Address Format", RFC 2374, July 1998. ==> this ref is no longer used in the body, and good riddance. Remove. [7] Huston, G., "Analyzing the Internet's BGP Routing Table", January 2001. ==> especially for a *normative reference*, the reference should IMO be much more explicit (e.g. refer to a publication and give a URL or the like). editorial --------- site-multihoming ==>s/site-multihoming/site multihoming/ (everywhere) ? This seems a more common practice..? providers may share a single conduit from the street into a building; in this case backhoe-fade of both circuits may be experienced due to ==> "backhoe-fade" ? No idea what that means, and couldn't find it in a dictionary either. demonstrate that the modified name resolution system required to support them are readily deployable. ==> s/are/is/ The multihoming solution may allow host or application changes if that would enhance session survivability. ==> s/session/transport-layer/ (to make a more explicit reference to the goal presented earlier) It should be posssible for staff responsible for the operation of a ==> s/posssible/possible/ -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Wed May 7 10:20:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02746 for ; Wed, 7 May 2003 10:20:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DPoC-000GEx-00 for multi6-data@psg.com; Wed, 07 May 2003 14:22:12 +0000 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.36 #1) id 19DPng-000G68-00 for multi6@ops.ietf.org; Wed, 07 May 2003 14:21:40 +0000 Received: (qmail 74567 invoked by uid 0); 7 May 2003 14:21:39 -0000 Received: from localhost.automagic.org (HELO isc.org) (root@127.0.0.1) by localhost.automagic.org with SMTP; 7 May 2003 14:21:39 -0000 Date: Wed, 7 May 2003 10:21:42 -0400 Subject: Re: comments on requirements-05 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: Iljitsch van Beijnum From: Joe Abley In-Reply-To: <70670C16-8055-11D7-820B-00039388672E@muada.com> Message-Id: <3993C36C-8097-11D7-BEC9-00039312C852@isc.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, May 7, 2003, at 02:30 Canada/Eastern, Iljitsch van Beijnum wrote: > On woensdag, mei 7, 2003, at 01:36 Europe/Amsterdam, Joe Abley wrote: > >>> [7] Huston, G., "Analyzing the Internet's BGP Routing Table", >>> January 2001. > >>> ==> especially for a *normative reference*, the reference should IMO >>> be much >>> more explicit (e.g. refer to a publication and give a URL or the >>> like). > >> I will find an URL. > > Seems all of this is suffering from "broken-URL-itis". You can > probably find something resembling the original in Cisco's Internet > Protocol Journal, but it has since become an RFC unless I'm very much > mistaken: http://www.ietf.org/rfc/rfc3221.txt Thanks. >>> ==> "backhoe-fade" ? No idea what that means, and couldn't find it >>> in a dictionary either. > >> http://www.net.oregonstate.edu/netvideo/dugout.html > > So are you going to include the URL in the text or what??? > > Remember that RFCs are published by an international standards > organization. As such, the text should be clear also for people who > have English as their second or third language and are unfamiliar with > American colloquialisms. Yep, good point. I think I am blaming Vijay or Ben for that phrase anyway :-) I will find something more straightforward. Joe From owner-multi6@ops.ietf.org Wed May 7 10:47:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04587 for ; Wed, 7 May 2003 10:47:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DQEF-000Lir-00 for multi6-data@psg.com; Wed, 07 May 2003 14:49:07 +0000 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.36 #1) id 19DQEA-000LiZ-00 for multi6@ops.ietf.org; Wed, 07 May 2003 14:49:02 +0000 Received: (qmail 76430 invoked by uid 0); 7 May 2003 14:49:01 -0000 Received: from localhost.automagic.org (HELO isc.org) (root@127.0.0.1) by localhost.automagic.org with SMTP; 7 May 2003 14:49:01 -0000 Date: Wed, 7 May 2003 10:49:03 -0400 Subject: Re: comments on requirements-05 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Kurt Erik Lindqvist , To: Pekka Savola From: Joe Abley In-Reply-To: Message-Id: <0B98096B-809B-11D7-BEC9-00039312C852@isc.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, May 7, 2003, at 04:12 Canada/Eastern, Pekka Savola wrote: > On Tue, 6 May 2003, Joe Abley wrote: > >>> ==> should be reworded to remove references to "transit provider is a >>> site" -concept, which is irrelevant and confusing in this context. >> >> Please explain. > > Typically "site" is considered to be an "end-site", in the transit > provider's case, the NOC of the transit provider. The backbone of the > transit provider, possibly spanning contininents, seems to stretch the > definition and the mental picture of a "site" pretty far. I think in practice "typically" is in the eye of the beholder, which is why I was careful to define what I meant by site. > Also, the text may be rather ambiguous as it doesn't seem to match the > common understanding of what "transit provider" typically is. Again, this came up when the draft was originally published with definitions. There is no common understanding of what "transit provider" is; different people add different nuances to their understanding of the phrase, which is why the definitions are there. I think the current set of definitions are sufficient to cover the concepts used in the draft, and I think they're about as commonly accepted amongst operators as we're likely to find. >>> 2) simplicity for the internet and/or the site should be made >>> explicit. >>> >>> 3.1.5 Simplicity >>> >>> As any proposed multihoming solution must be deployed in real >>> networks with real customers, simplicity is paramount. The current >>> multihoming solution is quite straightforward to deploy and >>> maintain. >>> A new IPv6 multihoming proposal should not be substantially more >>> complex to deploy and operate than current IPv4 multihoming >>> practices. >>> >>> ==> there are two aspects to the simplicity, with two different axes: >>> - simplicity to those who deploy it, and to those that don't >>> - simplicity to the Big Internet as a whole and the end-site itself >> >> I don't see those as orthogonal; your second line looks to me like a >> rewording of the first line (taking the Big Internet to be a >> collection >> of people who do and don't deploy multihoming). Perhaps you could >> explain that further. > > There is a slight difference there, in my eyes. > > The first item separates "multihomed site and its ISP(s) and possibly > their transits" and "everyone else". > > The second item separates "multihoming end-site" and "everyone else > (including their ISPs)". All of "its ISPs" and "their transits" and a good chunk of "everybody else" are potentially multi-homed sites; multi-homing doesn't only happen at "end-sites" (assuming I'm understanding your terminology correctly). The topology is a richly connected graph. Your use of "site" and "transit" seem to imply a more rigid hiererarchy which is not the case, in general. >>> 3.1.8 Packet Filtering >>> >>> Multihoming solutions should not preclude filtering packets with >>> forged or otherwise inappropriate source IP addresses at the >>> administrative boundary of the multihomed site. >>> >>> ==> replace from the end (remove the period): >>> >>> , or administrative >>> boundaries between any transit providers in the Internet. >>> >>> (this is done to facilitate for the fact that the Internet is >>> *not* >>> just >>> a homogenous single routing blob -- "once you're in, you're in >>> for >>> good"). >> >> I'm not sure that additional sentiment is required, but I wouldn't >> object to it going in. > > I feel it's important, but I'm willing to hear what others think. > >>> 3.2.6 Cooperation between Transit Providers >>> >>> A multihoming strategy may require cooperation between a site and >>> its >>> transit providers, but should not require cooperation (relating >>> specifically to the multihomed site) directly between the transit >>> providers. [...] > Let's try to illustrate: > > Site S > / \ > ISP A -- ISP B > | | > Transit1 - Transit2 -- [ Internet ] > | \ > [Internet] [Internet] > > Co-operation is currently a goal with Site S <-> ISP A and Site S <-> > ISP > B. It is not with ISP A <-> ISP B. > > This doesn't take a stance on even more non-goal co-operation, with > e.g. > - Site S <-> Transit1 > - ISP A <-> Transit1 Ah, ok, I see what you mean. I'm not sure it's reasonable to take a stance on that. If site S wants to come to an arrangement with Transit1 to handle its traffic or routing in a certain way, why shouldn't it? With v4 CIDR abuse, for example, why shouldn't I be able to call up Sprint and say "hey, let me pay you money to relax your assignment-boundary filters in my particular case, so you'll accept my long-prefix route"? This in general does not sound like a recipe for simple, pervasive multi-homing but I'm not sure why the goals document should state it as a non-goal. >>> semi-editorial/substantial >>> -------------------------- >>> For purposes of >>> redundancy and load-sharing, the multihomed address blocks, which >>> are >>> almost always a longer prefix than the provider aggregate, are >>> announced along with the larger, covering aggregate originated by >>> the >>> provider. >>> >>> ==> s/redundancy/redundancy, independence/ >> >> No, I don't think there's any "independence" rationale there; these >> are >> covered prefixes describing PA assignments, not announcements of PI >> space. > > There certainly is, if you can, and in practice do, take the portion of > the PA with you, to another provider. The text in the introduction > does > not require the site to advertise the more specific from the behind the > direct ISP: as long as a covering aggregate (from somewhere else) > exists, > you're fine. I mean, there's no independence in the sense that you are still dependent on the provider who allocated you the numbers. You can't stop paying that guy and continue to announce your long-prefix route to other transit providers. "Independence", when mentioned in the context of v4 multihoming, is invariably to do with PI addressing I have noticed. Hence I think introducing that word here would add confusion rather than clarity. > But why do you then say: > > the multihomed address blocks, which are > almost always a longer prefix than the provider aggregate, > > ==> there is no "coverage" if it is not a longer prefix. ok, how about "which are almost always covered by a provider aggregate,". > In any case, the introduction is incomplete. Multihoming is also done > with PI addresses, without covering aggregates. OK. That's a fair point. > The introduction should be either modified to be a bit more descriptive > (or generic), or make a reference to the v4 multihoming draft (which > would > require us to start working on it again) -- which should be there > anyway, > at least as an informational ref. > >>> This contributes to the rapidly-increasing size of the >>> global routing table. >>> >>> ==> s/size/size and dynamicity/ (better word than dynamicity?!?!) >> >> complexity? > > Complexity is too generic a term unfortunately, it doesn't imply > anything > about the advertise/withdraw cycles caused by site multihoming. turbulence? >>> ==> "backhoe-fade" ? No idea what that means, and couldn't find it >>> in a dictionary either. >> >> http://www.net.oregonstate.edu/netvideo/dugout.html > > A bit too technical term, when a simpler, generally understandable way > to > say something to the same effect might be possible. Yep, fair enough. Joe From owner-multi6@ops.ietf.org Wed May 7 11:18:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05455 for ; Wed, 7 May 2003 11:18:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DQhc-0001sj-00 for multi6-data@psg.com; Wed, 07 May 2003 15:19:28 +0000 Received: from mail-gw1.hursley.ibm.com ([194.196.110.15]) by psg.com with esmtp (Exim 3.36 #1) id 19DQh5-0001rl-00 for multi6@ops.ietf.org; Wed, 07 May 2003 15:18:55 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19DQh4-0003nU-00 for multi6@ops.ietf.org; Wed, 07 May 2003 16:18:54 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19DQh4-0003nP-00 for multi6@ops.ietf.org; Wed, 07 May 2003 16:18:54 +0100 Received: from hursley.ibm.com (dhcp21-189.zurich.ibm.com [9.4.21.189]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA44178 for ; Wed, 7 May 2003 16:18:52 +0100 Message-ID: <3EB923FF.37EE449@hursley.ibm.com> Date: Wed, 07 May 2003 17:19:27 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: Re: comments on requirements-05 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_00,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Harold, this sort of issue is exactly why we agreed to convert it from a requirements document into a simple list of goals. Personally, I'd like to see it out as an RFC as soon as Joe has tweaked it for the latest round of comments, so that we can all use it as a thinking aid when analysing specific proposals. There is nothing to be gained by trying to make a list of goals perfect or watertight, and I see no harm in some of the goals being manifestly subjective. It's time to move on from this document. Brian "Grovesteen, Harold" wrote: > > Requirements/goals which are subjective and arbitrary should be avoided. > "Simplicity" is subjective. How is something determined to be simple or > not? Simplicity is in the eye of the beholder. Some things are simple by > nature others are not. Whatever architecture is developed here may or may > not be simple and that depends upon who looks at it. > > The entire set of goals about traffic engineering are arbitrary. > Organizations engineer traffic for totally non-technical reasons which can > be neither anticipated nor guaranteed architecturally because they tend to > be capabilities offered by specific implementations. > > We can not seem to agree on basic functionality or requirements that truly > are such. Subjective and arbitrary goals simply muddy the waters. > > Of course, since everything is "should" or "should not," I am not sure that > any content has real value. It can always be argued that although something > only should or should not be there no requirement actually exists. I am > hoping Vienna will sort some of these issues out and provide a clear > direction which may make the "requirement" document somewhat moot. > > Harold Grovesteen > > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Tuesday, May 06, 2003 4:11 PM > To: Kurt Erik Lindqvist > Cc: Joe Abley; multi6@ops.ietf.org > Subject: comments on requirements-05 > > On Mon, 5 May 2003, Kurt Erik Lindqvist wrote: > > > Could we restart the last call, on the basis of the -05 draft? > > > My answer on that is: ship it! > > > > Me and Sean have discussed around this last-call in private and we are > > both really in favor of getting this shipped ASAP. Unless anyone have > > come up with a really compelling reason not to ship it by Wen 12.00 CET > > we will ship it. The -05 draft that is. > > I've done a quick review on the document. > > There are lots of things that should be clarified, but all should be > rather easily editable. The document name should also be changed > (s/requirements/goals/) if that's possible. > > substantial > ----------- > 1) the terminology should be improved to be more precise. > > A "transit provider" operates a site which directly provides > connectivity to the Internet to one or more external sites. The > connectivity provided extends beyond the transit provider's own site. > A transit provider's site is directly connected to the sites for > which it provides transit. > > ==> should be reworded to remove references to "transit provider is a > site" -concept, which is irrelevant and confusing in this context. > > A "multihomed" site is one with more than one transit provider. > "Site-multihoming" is the practice of arranging a site to be > multihomed. > > ==> this also needs rewording. In general, the term "transit provider" > is applied to network service providers which are in the middle of the > packet forwarding chain. I do not call first-hop upstream providers > transit providers. The term "transit" here is also misleading because > it IMO points to the difference between "transit" and "peering", > which do not apply to end-sites. > > ==> therefore, I think the last three terms could be reworded a bit. > (I might be able to try to help with some text if needed and folks agree.) > > ==> similar consideration wrt. "transit" applies to the rest of the > document. > > 2) simplicity for the internet and/or the site should be made explicit. > > 3.1.5 Simplicity > > As any proposed multihoming solution must be deployed in real > networks with real customers, simplicity is paramount. The current > multihoming solution is quite straightforward to deploy and maintain. > A new IPv6 multihoming proposal should not be substantially more > complex to deploy and operate than current IPv4 multihoming > practices. > > ==> there are two aspects to the simplicity, with two different axes: > - simplicity to those who deploy it, and to those that don't > - simplicity to the Big Internet as a whole and the end-site itself > > Solutions will probably not be simple for all of these; stating these > explicitly will make the solution designers aware of different aspects of > simplicity which should be considered. > > 3) there are a few especially worrisome goals. > > 3.1.2 Load Sharing > > By multihoming, a site should be able to distribute both inbound and > outbound traffic between multiple transit providers. > > 3.1.3 Performance > > [...] > > A multihomed site should be able to distribute inbound traffic from > particular multiple transit providers according to the particular > address range within their site which is sourcing or sinking the > traffic. > > ==> typically "inbound traffic balancing", especially as made a very > specific and detailed goal by "performance", go a long way in the "very > potentially unscalable" territory. > > Therefore, I'd like to add some disclaimers or a few additional words to > these goals -- but I don't know how and what in particular. > > Anyone else worried? > > 4) document assumes the Internet transit/ISP architecture is a single > administrative entity > > 3.1.8 Packet Filtering > > Multihoming solutions should not preclude filtering packets with > forged or otherwise inappropriate source IP addresses at the > administrative boundary of the multihomed site. > > ==> replace from the end (remove the period): > > , or administrative > boundaries between any transit providers in the Internet. > > (this is done to facilitate for the fact that the Internet is *not* just > a homogenous single routing blob -- "once you're in, you're in for > good"). > > 5) co-operation (non)goals are not explicit about third party ISP's and > non-direct transit ISP's > > 3.2.6 Cooperation between Transit Providers > > A multihoming strategy may require cooperation between a site and its > transit providers, but should not require cooperation (relating > specifically to the multihomed site) directly between the transit > providers. > > ==> particularly if the "transit provider" terminology is not redefined, > this needs to be very much clarified. I believe the above text is used to > refer to the direct first-hop upstream providers of the site only. It > should also say that co-operation with any of the site's transit providers > and any of their peers or transits should not be required ("no requirement > for third parties", here transit of the transit being a 2 1/2 party) > > semi-editorial/substantial > -------------------------- > For purposes of > redundancy and load-sharing, the multihomed address blocks, which are > almost always a longer prefix than the provider aggregate, are > announced along with the larger, covering aggregate originated by the > provider. > > ==> s/redundancy/redundancy, independence/ > > This contributes to the rapidly-increasing size of the > global routing table. > > ==> s/size/size and dynamicity/ (better word than dynamicity?!?!) > > By multihoming, a site should be able to distribute both inbound and > outbound traffic between multiple transit providers. This requirement > is for concurrent use of the multiple transit providers, not just the > > ==> s/requirement/goal/ > > 3.2.2 Impact on Routers > > The solution may require changes to IPv6 router implementations, but > > ==> s/solution/solutions/ -- many more under section 3.2.x. The text > seems to indicate that a single solution would fit the bill. > > Normative References > > ==> references section should be numbered. > > [4] Hinden, R., O'Dell, M. and S. Deering, "An IPv6 Aggregatable > Global Unicast Address Format", RFC 2374, July 1998. > > ==> this ref is no longer used in the body, and good riddance. Remove. > > [7] Huston, G., "Analyzing the Internet's BGP Routing Table", > January 2001. > > ==> especially for a *normative reference*, the reference should IMO be > much > more explicit (e.g. refer to a publication and give a URL or the like). > > editorial > --------- > site-multihoming > > ==>s/site-multihoming/site multihoming/ (everywhere) ? This seems a more > common practice..? > > providers may share a single conduit from the street into a building; > in this case backhoe-fade of both circuits may be experienced due to > > ==> "backhoe-fade" ? No idea what that means, and couldn't find it > in a dictionary either. > > demonstrate that the modified name resolution system required to > support them are readily deployable. > > ==> s/are/is/ > > The multihoming solution may allow host or application changes if > that would enhance session survivability. > > ==> s/session/transport-layer/ (to make a more explicit reference to > the goal presented earlier) > > It should be posssible for staff responsible for the operation of a > > ==> s/posssible/possible/ > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Wed May 7 14:57:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12500 for ; Wed, 7 May 2003 14:57:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DU7h-000PG4-00 for multi6-data@psg.com; Wed, 07 May 2003 18:58:37 +0000 Received: from tomts6.bellnexxia.net ([209.226.175.26] helo=tomts6-srv.bellnexxia.net) by psg.com with esmtp (Exim 3.36 #1) id 19DU7d-000PEQ-00 for multi6@ops.ietf.org; Wed, 07 May 2003 18:58:33 +0000 Received: from yahoo.com ([65.93.188.175]) by tomts6-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with ESMTP id <20030507185831.DDWM5330.tomts6-srv.bellnexxia.net@yahoo.com>; Wed, 7 May 2003 14:58:31 -0400 Date: Wed, 7 May 2003 14:58:31 -0400 Subject: Re: New draft: Now What? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Pekka Savola From: S Woodside In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-19.3 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,FORGED_YAHOO_RCVD,IN_REP_TO, QUOTED_EMAIL_TEXT,RCVD_FAKE_HELO_DOTCOM,REPLY_WITH_QUOTES, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I'm confused though. This is the site multihoming WG, so does a single host, or let's say, a single home qualify as a site? I'll continue to harp on the CWN angle since I think I've found the right IETF area ;-) Load sharing is a requirement for multihoming CWN nodes. It would be good to get that into the internet architecture instead of having to create something special to CWNs to handle it. Also IIRC another person mentioned the PAN, where you might have WiFi and GPRS connections, where does that fall into your taxonomy? simon On Tuesday, May 6, 2003, at 05:25 PM, Pekka Savola wrote: > .--------------.------------.--------------. > | Independence | Redundancy | Load sharing | > .--------------+--------------+------------+--------------+ > |Minimal | no | no | no | > |Small | maybe | maybe | no | > |Large | maybe/yes | yes | maybe | > |International | yes | yes | yes | > '--------------'--------------'------------'--------------' > -- www.simonwoodside.com -- 99% Devil, 1% Angel From owner-multi6@ops.ietf.org Wed May 7 16:50:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16928 for ; Wed, 7 May 2003 16:50:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DVsu-00004v-00 for multi6-data@psg.com; Wed, 07 May 2003 20:51:28 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19DVss-000Q0Z-00 for multi6@ops.ietf.org; Wed, 07 May 2003 20:51:26 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h47Knqn16375; Wed, 7 May 2003 22:49:54 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 7 May 2003 22:49:52 +0200 Subject: Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: David Conrad , multi6@ops.ietf.org To: Brian E Carpenter From: Iljitsch van Beijnum In-Reply-To: <3EB8CD07.BCD04EFD@hursley.ibm.com> Message-Id: <73ACFDB9-80CD-11D7-A6F7-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On woensdag, mei 7, 2003, at 11:08 Europe/Amsterdam, Brian E Carpenter wrote: >> Or you simply rewrite the first 48 bits when the packet traverses the >> border into the destination site with the same value the packet had >> prior to traversing the border of the source site. > This was not part of any GSE proposal I ever saw, True enough, but I think there was reasonable consensus that GSE as-is wouldn't be very useful as it requires changes to too many things and doesn't implement important multihoming functionality such as failover. We need to come up with some new names though, to avoid confusion. > and it involves stateful distribution of mapping information. A very > different beast from GSE, and it sets off my stateful=bad alarm. Actually this wouldn't be a problem at all since we have to keep this exact same state anyway in order to map the other way around for sending packets back. From owner-multi6@ops.ietf.org Wed May 7 18:57:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21739 for ; Wed, 7 May 2003 18:57:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DXru-0008kN-00 for multi6-data@psg.com; Wed, 07 May 2003 22:58:34 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19DXrq-0008k8-00 for multi6@ops.ietf.org; Wed, 07 May 2003 22:58:30 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h47MvCn16519 for ; Thu, 8 May 2003 00:57:12 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 8 May 2003 00:57:13 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: rewriting draft, next round From: Iljitsch van Beijnum To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: <3E08D450-80DF-11D7-A6F7-00039388672E@muada.com> X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-8.9 required=5.0 tests=BAYES_10,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ok, I've written some text for the draft based on GSE/8+8 I was talking about. For anyone interested in following my progress: http://www.muada.com/drafts/draft-van-beijnum-multi-rewrite-00.txt (Please no spelling or style comments just yet, this is work in progress.) I've done away with the 64 bits + 64 bits thing on the grounds that it is insecure and breaks transport protocols and autoconfiguation. Instead, there is a mapping between the identifier address and the locator addresses and back, so the locators essentially retain the identifying function. Next order of business: the mapping function. I'm thinking: - use a simple packet format with information that announces capabilities and preferences (not specifying the format, though: too much detail at this stage) - both hosts should then be able to determine from their own information and that of the correspondent how they're going to communicate without the need for additional round trips (similar to TCP options in the SYN packets) - getting this mapping mechanism exactly right the first time is going to be close to impossible and take a lot of time, so why even try, but rather: do something simple now but provide hooks for upgrading later - so each host must support: 1. doing this inband in an IP option in the first packet for a session 2. find this information in the DNS 3. request the information from some central host that presumably implements a smarter mapping discovery/negotiation mechanism I'm also considering a "delayed negotation" mechanism where hosts only use an IP or TCP option to deliver a cookie that makes it possible to negotiate multihoming later when it turns out that the session is long-lived. (We do NOT want to go through all of this for each individual TCP session towards a webserver.) Comments welcome. Iljitsch From owner-multi6@ops.ietf.org Thu May 8 02:13:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13091 for ; Thu, 8 May 2003 02:13:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Defm-0003V5-00 for multi6-data@psg.com; Thu, 08 May 2003 06:14:30 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19Defj-0003Ut-00 for multi6@ops.ietf.org; Thu, 08 May 2003 06:14:27 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h486ENX22174; Thu, 8 May 2003 09:14:23 +0300 Date: Thu, 8 May 2003 09:14:23 +0300 (EEST) From: Pekka Savola To: S Woodside cc: multi6@ops.ietf.org Subject: Re: New draft: Now What? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 7 May 2003, S Woodside wrote: > I'm confused though. This is the site multihoming WG, so does a single > host, or let's say, a single home qualify as a site? A degenerate case of site is a single host. In particular, "home networks" are considered sites. All of these fall within my "Minimal" category. > I'll continue to harp on the CWN angle since I think I've found the > right IETF area ;-) Load sharing is a requirement for multihoming CWN > nodes. It would be good to get that into the internet architecture > instead of having to create something special to CWNs to handle it. Could you elaborate on the specific load sharing needs, how it's done now, etc. because this seems very surprising to me. > Also IIRC another person mentioned the PAN, where you might have WiFi > and GPRS connections, where does that fall into your taxonomy? I'm not sure what you refer to. > On Tuesday, May 6, 2003, at 05:25 PM, Pekka Savola wrote: > > > .--------------.------------.--------------. > > | Independence | Redundancy | Load sharing | > > .--------------+--------------+------------+--------------+ > > |Minimal | no | no | no | > > |Small | maybe | maybe | no | > > |Large | maybe/yes | yes | maybe | > > |International | yes | yes | yes | > > '--------------'--------------'------------'--------------' > > > > -- > www.simonwoodside.com -- 99% Devil, 1% Angel > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Thu May 8 05:49:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18255 for ; Thu, 8 May 2003 05:49:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Di20-0002Wv-00 for multi6-data@psg.com; Thu, 08 May 2003 09:49:40 +0000 Received: from mail-gw1.hursley.ibm.com ([194.196.110.15]) by psg.com with esmtp (Exim 3.36 #1) id 19Di1y-0002Wf-00 for multi6@ops.ietf.org; Thu, 08 May 2003 09:49:38 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19Di1v-0001iT-00; Thu, 08 May 2003 10:49:35 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19Di1v-0001iO-00; Thu, 08 May 2003 10:49:35 +0100 Received: from hursley.ibm.com (dhcp21-189.zurich.ibm.com [9.4.21.189]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id KAA174192; Thu, 8 May 2003 10:49:31 +0100 Message-ID: <3EBA284C.61E0BE3A@hursley.ibm.com> Date: Thu, 08 May 2003 11:50:04 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Iljitsch van Beijnum CC: multi6@ops.ietf.org Subject: Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] References: <73ACFDB9-80CD-11D7-A6F7-00039388672E@muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > > On woensdag, mei 7, 2003, at 11:08 Europe/Amsterdam, Brian E Carpenter > wrote: > > >> Or you simply rewrite the first 48 bits when the packet traverses the > >> border into the destination site with the same value the packet had > >> prior to traversing the border of the source site. > > > This was not part of any GSE proposal I ever saw, > > True enough, but I think there was reasonable consensus that GSE as-is > wouldn't be very useful as it requires changes to too many things and > doesn't implement important multihoming functionality such as failover. > We need to come up with some new names though, to avoid confusion. > > > and it involves stateful distribution of mapping information. A very > > different beast from GSE, and it sets off my stateful=bad alarm. > > Actually this wouldn't be a problem at all since we have to keep this > exact same state anyway in order to map the other way around for > sending packets back. Again, not in GSE as I understand it. In MHAP or map-and-encap, yes. Brian From owner-multi6@ops.ietf.org Thu May 8 06:32:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19120 for ; Thu, 8 May 2003 06:32:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DijK-0008dH-00 for multi6-data@psg.com; Thu, 08 May 2003 10:34:26 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19DijI-0008d2-00 for multi6@ops.ietf.org; Thu, 08 May 2003 10:34:24 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h48AX5n17606; Thu, 8 May 2003 12:33:05 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 8 May 2003 12:33:09 +0200 Subject: Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Brian E Carpenter From: Iljitsch van Beijnum In-Reply-To: <3EBA284C.61E0BE3A@hursley.ibm.com> Message-Id: <764588BD-8140-11D7-8261-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On donderdag, mei 8, 2003, at 11:50 Europe/Amsterdam, Brian E Carpenter wrote: >>> and it involves stateful distribution of mapping information. A very >>> different beast from GSE, and it sets off my stateful=bad alarm. >> Actually this wouldn't be a problem at all since we have to keep this >> exact same state anyway in order to map the other way around for >> sending packets back. > Again, not in GSE as I understand it. I don't think it's a coincidence that there hasn't been any progress with GSE for five years or so. In theory, GSE can work without a mapping mechanism, but this opens the door to security problems. So in practice we need to keep state to know whether there is a valid locator <-> identifier mapping to avoid trivial identity theft. And if we accept that, we may as well remove the whole globally unique lower 64 bit thing as it just breaks too much stuff without any real benefits at this point. Aside from that, not having a mapping mechanism makes failover very difficult: the only way that still works is if the border router at the source sees the problem. This works for last mile problems, but not for routing problems further upstream. I know others have different experiences, but for me routing problems are the number one cause of outages. Is there anyone who wants to stick with GSE without a mapping mechanism? From owner-multi6@ops.ietf.org Thu May 8 07:10:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19703 for ; Thu, 8 May 2003 07:10:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DjJv-000E2w-00 for multi6-data@psg.com; Thu, 08 May 2003 11:12:15 +0000 Received: from smtp03.uc3m.es ([163.117.136.123] helo=smtp.uc3m.es) by psg.com with esmtp (Exim 3.36 #1) id 19DjJr-000E2g-00 for multi6@ops.ietf.org; Thu, 08 May 2003 11:12:12 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 973EA4333C; Thu, 8 May 2003 13:12:10 +0200 (CEST) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp03.uc3m.es (Postfix) with ESMTP id 4BB2A2B663; Thu, 8 May 2003 13:12:10 +0200 (CEST) Subject: Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] From: marcelo bagnulo To: Iljitsch van Beijnum Cc: Brian E Carpenter , multi6@ops.ietf.org In-Reply-To: <764588BD-8140-11D7-8261-00039388672E@muada.com> References: <764588BD-8140-11D7-8261-00039388672E@muada.com> Content-Type: text/plain Organization: uc3m Message-Id: <1052392244.1110.12.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 May 2003 13:10:45 +0200 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I guess that what Brian means is that this (what you are describing) is not GSE anymore, since it is not stateless (which is a fundamental feature of GSE, as i see it) It is just a matter of name. what you are describing sounds more like MHAP... So as someone suggested earlier, i think i would be better to find a new name (or just avoid mentioning GSE) in order to avoid misunderstandings. Regards, marcelo n Thu, 2003-05-08 at 12:33, Iljitsch van Beijnum wrote: > On donderdag, mei 8, 2003, at 11:50 Europe/Amsterdam, Brian E Carpenter > wrote: > > >>> and it involves stateful distribution of mapping information. A very > >>> different beast from GSE, and it sets off my stateful=bad alarm. > > >> Actually this wouldn't be a problem at all since we have to keep this > >> exact same state anyway in order to map the other way around for > >> sending packets back. > > > Again, not in GSE as I understand it. > > I don't think it's a coincidence that there hasn't been any progress > with GSE for five years or so. In theory, GSE can work without a > mapping mechanism, but this opens the door to security problems. So in > practice we need to keep state to know whether there is a valid locator > <-> identifier mapping to avoid trivial identity theft. And if we > accept that, we may as well remove the whole globally unique lower 64 > bit thing as it just breaks too much stuff without any real benefits at > this point. > > Aside from that, not having a mapping mechanism makes failover very > difficult: the only way that still works is if the border router at the > source sees the problem. This works for last mile problems, but not for > routing problems further upstream. I know others have different > experiences, but for me routing problems are the number one cause of > outages. > > Is there anyone who wants to stick with GSE without a mapping mechanism? -- marcelo bagnulo uc3m From owner-multi6@ops.ietf.org Thu May 8 07:29:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19958 for ; Thu, 8 May 2003 07:29:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DjdD-000GqX-00 for multi6-data@psg.com; Thu, 08 May 2003 11:32:11 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19DjdB-000GqH-00 for multi6@ops.ietf.org; Thu, 08 May 2003 11:32:09 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h48BUpn17700; Thu, 8 May 2003 13:30:51 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 8 May 2003 13:30:55 +0200 Subject: Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: marcelo bagnulo From: Iljitsch van Beijnum In-Reply-To: <1052392244.1110.12.camel@presto.it.uc3m.es> Message-Id: <880CA468-8148-11D7-8261-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On donderdag, mei 8, 2003, at 13:10 Europe/Amsterdam, marcelo bagnulo wrote: > I guess that what Brian means is that this (what you are describing) is > not GSE anymore, since it is not stateless (which is a fundamental > feature of GSE, as i see it) No disagreement there. > what you are describing sounds more like MHAP... Originally, I wanted to write something that encompasses both MHAP and GSE. But: "The original GSE and 8+8 drafts split the IPv6 address in two 64-bit parts. The lower part is used within the site or subnet. Routers add the higher 64 bits as packets leave the site. Since hosts don't know the higher 64 bits their correspondent will see, they must disregard these bits, which has the relatively minor consequence that the TCP and UDP pseudo header used in checksum calculations must be changed. A more severe consequence is that the lower 64 bits must now be globally unique. This in turn makes it very easy to perform spoofing attacks, as an attacker can simply present arbitrary lower bits, thereby assuming any desired identity, while setting the higher bits such that the packets are routed back to the attacker and not to the host identified by the lower 64 bits. This vulnerability, breaking autoconfiguration and, to a lesser degree, the transport layer checksums, make adopting GSE or 8+8 unfeasible and undesirable." Is there anyone who disagrees and feels stateless GSE is still viable? The letter combination "GSE" will not appear in the title. The preliminary title is "Multihoming in IPv6 by Rewriting Addresses". From owner-multi6@ops.ietf.org Thu May 8 08:11:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20591 for ; Thu, 8 May 2003 08:11:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DkGj-000Mki-00 for multi6-data@psg.com; Thu, 08 May 2003 12:13:01 +0000 Received: from mail-gw1.hursley.ibm.com ([194.196.110.15]) by psg.com with esmtp (Exim 3.36 #1) id 19DkGg-000MkT-00 for multi6@ops.ietf.org; Thu, 08 May 2003 12:12:58 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19DkGd-0001Wa-00; Thu, 08 May 2003 13:12:55 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19DkGc-0001WV-00; Thu, 08 May 2003 13:12:54 +0100 Received: from hursley.ibm.com (dhcp21-189.zurich.ibm.com [9.4.21.189]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id NAA120892; Thu, 8 May 2003 13:12:52 +0100 Message-ID: <3EBA49E3.73947101@hursley.ibm.com> Date: Thu, 08 May 2003 14:13:23 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Iljitsch van Beijnum CC: multi6@ops.ietf.org Subject: Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] References: <880CA468-8148-11D7-8261-00039388672E@muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch, As I've said before, the actual requirement is that the lower 64 bits be mutually unique among the set of correspondents (two for normal cases, N for p2p cases). But indeed it is a general point that non-topological fields are more readily spoofed than topological fields, since ingress filtering and RPF checks don't apply. The consequence is not automatically that they can't be used, but that if they are used, an additional layer (such as HIP) is needed. I think that is what you should say. Brian Iljitsch van Beijnum wrote: > > On donderdag, mei 8, 2003, at 13:10 Europe/Amsterdam, marcelo bagnulo > wrote: > > > I guess that what Brian means is that this (what you are describing) is > > not GSE anymore, since it is not stateless (which is a fundamental > > feature of GSE, as i see it) > > No disagreement there. > > > what you are describing sounds more like MHAP... > > Originally, I wanted to write something that encompasses both MHAP and > GSE. But: > > "The original GSE and 8+8 drafts split the IPv6 address in two 64-bit > parts. The lower part is used within the site or subnet. Routers add > the higher 64 bits as packets leave the site. Since hosts don't know > the higher 64 bits their correspondent will see, they must disregard > these bits, which has the relatively minor consequence that the TCP > and UDP pseudo header used in checksum calculations must be changed. > A more severe consequence is that the lower 64 bits must now be > globally unique. This in turn makes it very easy to perform spoofing > attacks, as an attacker can simply present arbitrary lower bits, > thereby assuming any desired identity, while setting the higher bits > such that the packets are routed back to the attacker and not to the > host identified by the lower 64 bits. This vulnerability, breaking > autoconfiguration and, to a lesser degree, the transport layer > checksums, make adopting GSE or 8+8 unfeasible and undesirable." > > Is there anyone who disagrees and feels stateless GSE is still viable? > > The letter combination "GSE" will not appear in the title. The > preliminary title is "Multihoming in IPv6 by Rewriting Addresses". From owner-multi6@ops.ietf.org Thu May 8 08:28:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20879 for ; Thu, 8 May 2003 08:28:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DkYC-000Pf0-00 for multi6-data@psg.com; Thu, 08 May 2003 12:31:04 +0000 Received: from smtp02.uc3m.es ([163.117.136.122] helo=smtp.uc3m.es) by psg.com with esmtp (Exim 3.36 #1) id 19DkY7-000Pen-00 for multi6@ops.ietf.org; Thu, 08 May 2003 12:30:59 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id C65D743183; Thu, 8 May 2003 14:30:58 +0200 (CEST) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp02.uc3m.es (Postfix) with ESMTP id B4F4999F8F; Thu, 8 May 2003 14:30:58 +0200 (CEST) Subject: Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] From: marcelo bagnulo To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org In-Reply-To: <880CA468-8148-11D7-8261-00039388672E@muada.com> References: <880CA468-8148-11D7-8261-00039388672E@muada.com> Content-Type: text/plain Organization: uc3m Message-Id: <1052396976.1110.23.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 May 2003 14:29:36 +0200 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 2003-05-08 at 13:30, Iljitsch van Beijnum wrote: > On donderdag, mei 8, 2003, at 13:10 Europe/Amsterdam, marcelo bagnulo > wrote: > > > I guess that what Brian means is that this (what you are describing) is > > not GSE anymore, since it is not stateless (which is a fundamental > > feature of GSE, as i see it) > > No disagreement there. > > > what you are describing sounds more like MHAP... > > Originally, I wanted to write something that encompasses both MHAP and > GSE. But: > > "The original GSE and 8+8 drafts split the IPv6 address in two 64-bit > parts. The lower part is used within the site or subnet. Routers add > the higher 64 bits as packets leave the site. Since hosts don't know > the higher 64 bits their correspondent will see, they must disregard > these bits, which has the relatively minor consequence that the TCP > and UDP pseudo header used in checksum calculations must be changed. > A more severe consequence is that the lower 64 bits must now be > globally unique. This in turn makes it very easy to perform spoofing > attacks, as an attacker can simply present arbitrary lower bits, > thereby assuming any desired identity, while setting the higher bits > such that the packets are routed back to the attacker and not to the > host identified by the lower 64 bits. This vulnerability, breaking > autoconfiguration and, to a lesser degree, the transport layer > checksums, make adopting GSE or 8+8 unfeasible and undesirable." > > Is there anyone who disagrees and feels stateless GSE is still viable? > I think that the statless condition of GSE is really valuable and perhaps we can come up with a solution that can preserve it. As you mention, security issues need to be solved somehow in order to enable this solution. A possibility would be to use crypto identifiers such as in HIP but included in the 64 lower bits of the address (CGAs) I guess that this could provide the security needed and it would also preserve middle boxes stateless as in GSE. Regards, marcelo > The letter combination "GSE" will not appear in the title. The > preliminary title is "Multihoming in IPv6 by Rewriting Addresses". -- marcelo bagnulo uc3m From owner-multi6@ops.ietf.org Thu May 8 08:58:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21498 for ; Thu, 8 May 2003 08:58:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Dkzy-0003KE-00 for multi6-data@psg.com; Thu, 08 May 2003 12:59:46 +0000 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by psg.com with esmtp (Exim 3.36 #1) id 19Dkzv-0003Jy-00 for multi6@ops.ietf.org; Thu, 08 May 2003 12:59:43 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id B885E7F86; Thu, 8 May 2003 08:59:42 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Thu, 8 May 2003 08:59:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Date: Thu, 8 May 2003 08:59:40 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD761@tayexc13.americas.cpqcorp.net> Thread-Topic: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Thread-Index: AcMVXrUfe3llM8suSmivdT41M8PhogAAu86A From: "Bound, Jim" To: "marcelo bagnulo" , "Iljitsch van Beijnum" Cc: X-OriginalArrivalTime: 08 May 2003 12:59:42.0528 (UTC) FILETIME=[B130C400:01C31561] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA21498 CGA's have to many IPR issues lets not go there here for this work please. /jim > -----Original Message----- > From: marcelo bagnulo [mailto:marcelo@it.uc3m.es] > Sent: Thursday, May 08, 2003 8:30 AM > To: Iljitsch van Beijnum > Cc: multi6@ops.ietf.org > Subject: Re: GSE IDs [Re: IETF multihoming powder: just add > IPv6 and stir] > > > On Thu, 2003-05-08 at 13:30, Iljitsch van Beijnum wrote: > > On donderdag, mei 8, 2003, at 13:10 Europe/Amsterdam, > marcelo bagnulo > > wrote: > > > > > I guess that what Brian means is that this (what you are > describing) > > > is not GSE anymore, since it is not stateless (which is a > > > fundamental feature of GSE, as i see it) > > > > No disagreement there. > > > > > what you are describing sounds more like MHAP... > > > > Originally, I wanted to write something that encompasses > both MHAP and > > GSE. But: > > > > "The original GSE and 8+8 drafts split the IPv6 address > in two 64-bit > > parts. The lower part is used within the site or > subnet. Routers add > > the higher 64 bits as packets leave the site. Since > hosts don't know > > the higher 64 bits their correspondent will see, they > must disregard > > these bits, which has the relatively minor consequence > that the TCP > > and UDP pseudo header used in checksum calculations > must be changed. > > A more severe consequence is that the lower 64 bits must now be > > globally unique. This in turn makes it very easy to > perform spoofing > > attacks, as an attacker can simply present arbitrary lower bits, > > thereby assuming any desired identity, while setting > the higher bits > > such that the packets are routed back to the attacker > and not to the > > host identified by the lower 64 bits. This > vulnerability, breaking > > autoconfiguration and, to a lesser degree, the transport layer > > checksums, make adopting GSE or 8+8 unfeasible and undesirable." > > > > Is there anyone who disagrees and feels stateless GSE is > still viable? > > > > I think that the statless condition of GSE is really valuable > and perhaps we can come up with a solution that can preserve it. > > As you mention, security issues need to be solved somehow in > order to enable this solution. > > A possibility would be to use crypto identifiers such as in > HIP but included in the 64 lower bits of the address (CGAs) > > I guess that this could provide the security needed and it > would also preserve middle boxes stateless as in GSE. > > > Regards, marcelo > > > > The letter combination "GSE" will not appear in the title. The > > preliminary title is "Multihoming in IPv6 by Rewriting Addresses". > -- > marcelo bagnulo > uc3m > > > From owner-multi6@ops.ietf.org Thu May 8 09:09:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21693 for ; Thu, 8 May 2003 09:09:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DlBb-0004wp-00 for multi6-data@psg.com; Thu, 08 May 2003 13:11:47 +0000 Received: from smtp03.uc3m.es ([163.117.136.123] helo=smtp.uc3m.es) by psg.com with esmtp (Exim 3.36 #1) id 19DlBY-0004wb-00 for multi6@ops.ietf.org; Thu, 08 May 2003 13:11:44 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 9706D432EA; Thu, 8 May 2003 15:11:43 +0200 (CEST) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp03.uc3m.es (Postfix) with ESMTP id 887F92B670; Thu, 8 May 2003 15:11:43 +0200 (CEST) Subject: RE: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] From: marcelo bagnulo To: "Bound, Jim" Cc: Iljitsch van Beijnum , multi6@ops.ietf.org In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD761@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD761@tayexc13.americas.cpqcorp.net> Content-Type: text/plain Organization: uc3m Message-Id: <1052399420.1093.38.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 May 2003 15:10:21 +0200 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Jim, I was not aware of this, thanks for pointing it out. Perhaps if i rephrase it in the following way it would be acceptable? Instead of including the HIP's HIT in the SPI, we could include it in the lower 64 bits of the IP addresses. This would imply that the 64 lower bits could be used as identifiers and the 64 higher bits can be changed for routing purposes. Perhaps this would provide the security features needed for GSE to work in a stateless fashion. Regards, marcelo On Thu, 2003-05-08 at 14:59, Bound, Jim wrote: > CGA's have to many IPR issues lets not go there here for this work > please. > /jim > > > -----Original Message----- > > From: marcelo bagnulo [mailto:marcelo@it.uc3m.es] > > Sent: Thursday, May 08, 2003 8:30 AM > > To: Iljitsch van Beijnum > > Cc: multi6@ops.ietf.org > > Subject: Re: GSE IDs [Re: IETF multihoming powder: just add > > IPv6 and stir] > > > > > > On Thu, 2003-05-08 at 13:30, Iljitsch van Beijnum wrote: > > > On donderdag, mei 8, 2003, at 13:10 Europe/Amsterdam, > > marcelo bagnulo > > > wrote: > > > > > > > I guess that what Brian means is that this (what you are > > describing) > > > > is not GSE anymore, since it is not stateless (which is a > > > > fundamental feature of GSE, as i see it) > > > > > > No disagreement there. > > > > > > > what you are describing sounds more like MHAP... > > > > > > Originally, I wanted to write something that encompasses > > both MHAP and > > > GSE. But: > > > > > > "The original GSE and 8+8 drafts split the IPv6 address > > in two 64-bit > > > parts. The lower part is used within the site or > > subnet. Routers add > > > the higher 64 bits as packets leave the site. Since > > hosts don't know > > > the higher 64 bits their correspondent will see, they > > must disregard > > > these bits, which has the relatively minor consequence > > that the TCP > > > and UDP pseudo header used in checksum calculations > > must be changed. > > > A more severe consequence is that the lower 64 bits must now be > > > globally unique. This in turn makes it very easy to > > perform spoofing > > > attacks, as an attacker can simply present arbitrary lower bits, > > > thereby assuming any desired identity, while setting > > the higher bits > > > such that the packets are routed back to the attacker > > and not to the > > > host identified by the lower 64 bits. This > > vulnerability, breaking > > > autoconfiguration and, to a lesser degree, the transport layer > > > checksums, make adopting GSE or 8+8 unfeasible and undesirable." > > > > > > Is there anyone who disagrees and feels stateless GSE is > > still viable? > > > > > > > I think that the statless condition of GSE is really valuable > > and perhaps we can come up with a solution that can preserve it. > > > > As you mention, security issues need to be solved somehow in > > order to enable this solution. > > > > A possibility would be to use crypto identifiers such as in > > HIP but included in the 64 lower bits of the address (CGAs) > > > > I guess that this could provide the security needed and it > > would also preserve middle boxes stateless as in GSE. > > > > > > Regards, marcelo > > > > > > > The letter combination "GSE" will not appear in the title. The > > > preliminary title is "Multihoming in IPv6 by Rewriting Addresses". > > -- > > marcelo bagnulo > > uc3m > > > > > > -- marcelo bagnulo uc3m From owner-multi6@ops.ietf.org Thu May 8 09:45:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22447 for ; Thu, 8 May 2003 09:45:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Dlk0-0009JR-00 for multi6-data@psg.com; Thu, 08 May 2003 13:47:20 +0000 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 19Dlju-0009Iv-00 for multi6@ops.ietf.org; Thu, 08 May 2003 13:47:14 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id B1E04BF08; Thu, 8 May 2003 09:47:13 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Thu, 8 May 2003 09:47:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Date: Thu, 8 May 2003 09:47:12 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241213@tayexc13.americas.cpqcorp.net> Thread-Topic: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Thread-Index: AcMVZCnIW7wRBUCGSFmEpMiMvZ7fOQAAlmAw From: "Bound, Jim" To: "marcelo bagnulo" Cc: "Iljitsch van Beijnum" , X-OriginalArrivalTime: 08 May 2003 13:47:13.0439 (UTC) FILETIME=[547742F0:01C31568] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA22447 Hi Marcelo, Yes the HIP SPI could use the low order 64 bits but I want to read updates from Pekka N. just sent out for arch-03. I am also unclear the HIP code changes to our transport layers or at the IP layers will be done by what time frame. As far as GSE I am very behind in mail and have to read a few things and being quite now. But if we can change the high end 64 bits then I am naievly unclear why MHAP architecture is not valid for solution instead of hardline differentiation for 8+8 (my preferred term for GSE). I am also not clear on rewrite of headers in transit is going to fly in some cases I can think of as use case and one example is the military tactical operations case, which for me is one area I work on and care about as one of my roles working with users. But, in many cases they are their own Internet and can do things that cannot be done on the public Internet as easily simply from total network operations control. I believe if we rewrite headers we need to swap them into new routing header type for IPv6 too, which will remove going to the DNS, LDAP, or MPLS database to get back to the end node. I view this feature as keeping a history of location that is important. Off the top of my I would think we have to assume location will not change for 300 milliseconds (use this as that is what is needed for RTT for VoIP to be successful), but we probably need to define some time_t variables for the solution as best guess or derived time_t for when location can change. Probably also need to think about identity changing from say system crash, neighbor discovery DAD collision (after the fact of solicited node multicast which I have seen in the real world). I know I am going far to down in details sorry :--) /jim > -----Original Message----- > From: marcelo bagnulo [mailto:marcelo@it.uc3m.es] > Sent: Thursday, May 08, 2003 9:10 AM > To: Bound, Jim > Cc: Iljitsch van Beijnum; multi6@ops.ietf.org > Subject: RE: GSE IDs [Re: IETF multihoming powder: just add > IPv6 and stir] > > > Hi Jim, > > I was not aware of this, thanks for pointing it out. > > Perhaps if i rephrase it in the following way it would be acceptable? > > Instead of including the HIP's HIT in the SPI, we could > include it in the lower 64 bits of the IP addresses. This > would imply that the 64 lower bits could be used as > identifiers and the 64 higher bits can be changed for routing > purposes. Perhaps this would provide the security features > needed for GSE to work in a stateless fashion. > > Regards, marcelo > > On Thu, 2003-05-08 at 14:59, Bound, Jim wrote: > > CGA's have to many IPR issues lets not go there here for this work > > please. /jim > > > > > -----Original Message----- > > > From: marcelo bagnulo [mailto:marcelo@it.uc3m.es] > > > Sent: Thursday, May 08, 2003 8:30 AM > > > To: Iljitsch van Beijnum > > > Cc: multi6@ops.ietf.org > > > Subject: Re: GSE IDs [Re: IETF multihoming powder: just add > > > IPv6 and stir] > > > > > > > > > On Thu, 2003-05-08 at 13:30, Iljitsch van Beijnum wrote: > > > > On donderdag, mei 8, 2003, at 13:10 Europe/Amsterdam, > > > marcelo bagnulo > > > > wrote: > > > > > > > > > I guess that what Brian means is that this (what you are > > > describing) > > > > > is not GSE anymore, since it is not stateless (which is a > > > > > fundamental feature of GSE, as i see it) > > > > > > > > No disagreement there. > > > > > > > > > what you are describing sounds more like MHAP... > > > > > > > > Originally, I wanted to write something that encompasses > > > both MHAP and > > > > GSE. But: > > > > > > > > "The original GSE and 8+8 drafts split the IPv6 address > > > in two 64-bit > > > > parts. The lower part is used within the site or > > > subnet. Routers add > > > > the higher 64 bits as packets leave the site. Since > > > hosts don't know > > > > the higher 64 bits their correspondent will see, they > > > must disregard > > > > these bits, which has the relatively minor consequence > > > that the TCP > > > > and UDP pseudo header used in checksum calculations > > > must be changed. > > > > A more severe consequence is that the lower 64 bits > must now be > > > > globally unique. This in turn makes it very easy to > > > perform spoofing > > > > attacks, as an attacker can simply present > arbitrary lower bits, > > > > thereby assuming any desired identity, while setting > > > the higher bits > > > > such that the packets are routed back to the attacker > > > and not to the > > > > host identified by the lower 64 bits. This > > > vulnerability, breaking > > > > autoconfiguration and, to a lesser degree, the > transport layer > > > > checksums, make adopting GSE or 8+8 unfeasible and > > > > undesirable." > > > > > > > > Is there anyone who disagrees and feels stateless GSE is > > > still viable? > > > > > > > > > > I think that the statless condition of GSE is really valuable > > > and perhaps we can come up with a solution that can preserve it. > > > > > > As you mention, security issues need to be solved somehow in > > > order to enable this solution. > > > > > > A possibility would be to use crypto identifiers such as in > > > HIP but included in the 64 lower bits of the address (CGAs) > > > > > > I guess that this could provide the security needed and it > > > would also preserve middle boxes stateless as in GSE. > > > > > > > > > Regards, marcelo > > > > > > > > > > The letter combination "GSE" will not appear in the title. The > > > > preliminary title is "Multihoming in IPv6 by Rewriting > Addresses". > > > -- > > > marcelo bagnulo > > > uc3m > > > > > > > > > > -- > marcelo bagnulo > uc3m > > From owner-multi6@ops.ietf.org Thu May 8 09:48:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22479 for ; Thu, 8 May 2003 09:48:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Dlnl-0009pH-00 for multi6-data@psg.com; Thu, 08 May 2003 13:51:13 +0000 Received: from mailout.zma.compaq.com ([161.114.64.104] helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 19Dlnj-0009p4-00 for multi6@ops.ietf.org; Thu, 08 May 2003 13:51:11 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id BD4C582C0 for ; Thu, 8 May 2003 09:51:10 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Thu, 8 May 2003 09:51:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Mutli6 meeting in Vienna Date: Thu, 8 May 2003 09:51:10 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241214@tayexc13.americas.cpqcorp.net> Thread-Topic: Mutli6 meeting in Vienna Thread-Index: AcMVZCnIW7wRBUCGSFmEpMiMvZ7fOQABC1CA From: "Bound, Jim" To: X-OriginalArrivalTime: 08 May 2003 13:51:10.0648 (UTC) FILETIME=[E1DA7B80:01C31568] X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA22479 Chairs, I am rethinking my R&R time off in July and might change my mind and come to Vienna. Part of my decision is are we going to meet officially as Multi6 and if we do can we schedule one 2 hour offsite but not on Sunday as coming from U.S. I don't want to get there on Saturday (well I can't). Us meeting would input to my decision and two other areas of the IETF I am not comfortable not being at for some issues that require important face-to-face discussion. Any idea yet? Thanks /jim From owner-multi6@ops.ietf.org Thu May 8 10:36:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25155 for ; Thu, 8 May 2003 10:36:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DmXG-000G4X-00 for multi6-data@psg.com; Thu, 08 May 2003 14:38:14 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19DmXC-000G4L-00 for multi6@ops.ietf.org; Thu, 08 May 2003 14:38:10 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h48Eaon17990; Thu, 8 May 2003 16:36:51 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 8 May 2003 16:36:50 +0200 Subject: Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Brian E Carpenter From: Iljitsch van Beijnum In-Reply-To: <3EBA49E3.73947101@hursley.ibm.com> Message-Id: <812C7D77-8162-11D7-8399-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On donderdag, mei 8, 2003, at 14:13 Europe/Amsterdam, Brian E Carpenter wrote: > As I've said before, the actual requirement is that the lower 64 bits > be mutually unique among the set of correspondents (two for normal > cases, > N for p2p cases). Is it useful to define the requirement this narrow? For a server, I would think it's hard to work with non-globally unique correspondents as potentially every host connected to the network can open a session at any time, creating a collision where there wasn't one previously. > But indeed it is a general point that non-topological > fields are more readily spoofed than topological fields, since > ingress filtering and RPF checks don't apply. Don't forget return routability. Ingress filtering and RPF checks aren't done everywhere, but return routability protection is relatively good except when the attacker shares a subnet. > The consequence is not automatically that they can't be used, but that > if they are used, an additional layer (such as HIP) is needed. So we agree that breaking return routability and not repairing the resulting gap with something else isn't an option? Wouldn't such an additional layer always carry even more state with it? The only advantage is that this kind of state is kept in the endpoints. However, then we end up with the requirement that endpoints must implement the solution, which leads to deployment problems and management difficulties in some networks. This leaves us with: 1. do it with unmodified hosts in a proxy multihoming agent and eat the state 2. do it in modified hosts and don't involve the routers 3. 1. on on end an 2. on the other I don't feel the GSE way of doing it in modified hosts and then expect routers to do some additional work provides benefits over one of the above options. > I think that is what you should say. I'm getting there... It's still more than a month before the draft cutoff for Vienna. :-) Iljitsch From owner-multi6@ops.ietf.org Thu May 8 11:42:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27133 for ; Thu, 8 May 2003 11:42:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DnZ3-000PYm-00 for multi6-data@psg.com; Thu, 08 May 2003 15:44:09 +0000 Received: from mail-gw1.hursley.ibm.com ([194.196.110.15]) by psg.com with esmtp (Exim 3.36 #1) id 19DnYt-000PYM-00 for multi6@ops.ietf.org; Thu, 08 May 2003 15:43:59 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19DnYr-0007tN-00; Thu, 08 May 2003 16:43:57 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19DnYr-0007tI-00; Thu, 08 May 2003 16:43:57 +0100 Received: from hursley.ibm.com (dhcp21-189.zurich.ibm.com [9.4.21.189]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA82156; Thu, 8 May 2003 16:43:54 +0100 Message-ID: <3EBA7B5B.A3FD41AC@hursley.ibm.com> Date: Thu, 08 May 2003 17:44:27 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Iljitsch van Beijnum CC: multi6@ops.ietf.org Subject: Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] References: <812C7D77-8162-11D7-8399-00039388672E@muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-29.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > > On donderdag, mei 8, 2003, at 14:13 Europe/Amsterdam, Brian E Carpenter > wrote: > > > As I've said before, the actual requirement is that the lower 64 bits > > be mutually unique among the set of correspondents (two for normal > > cases, > > N for p2p cases). > > Is it useful to define the requirement this narrow? For a server, I > would think it's hard to work with non-globally unique correspondents > as potentially every host connected to the network can open a session > at any time, creating a collision where there wasn't one previously. I think it's a footnote on the word "global". You can say global, but add a note that mathematically that is not a necessary condition, although it may be the most practical solution. > > > But indeed it is a general point that non-topological > > fields are more readily spoofed than topological fields, since > > ingress filtering and RPF checks don't apply. > > Don't forget return routability. Ingress filtering and RPF checks > aren't done everywhere, but return routability protection is relatively > good except when the attacker shares a subnet. Sure > > > The consequence is not automatically that they can't be used, but that > > if they are used, an additional layer (such as HIP) is needed. > > So we agree that breaking return routability and not repairing the > resulting gap with something else isn't an option? I think so. > > Wouldn't such an additional layer always carry even more state with it? > The only advantage is that this kind of state is kept in the endpoints. > However, then we end up with the requirement that endpoints must > implement the solution, which leads to deployment problems and > management difficulties in some networks. Right, except that we have to solve key management anyway, to make any kind of security scale. Which as we know is hardly trivial. > > This leaves us with: > > 1. do it with unmodified hosts in a proxy multihoming agent and eat the > state > 2. do it in modified hosts and don't involve the routers > 3. 1. on on end an 2. on the other > > I don't feel the GSE way of doing it in modified hosts and then expect > routers to do some additional work provides benefits over one of the > above options. > > > I think that is what you should say. > > I'm getting there... It's still more than a month before the draft > cutoff for Vienna. :-) Lots of time to solve a problem that was discovered around 1992 :-) Brian From owner-multi6@ops.ietf.org Thu May 8 13:00:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00123 for ; Thu, 8 May 2003 13:00:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Dold-000BTr-00 for multi6-data@psg.com; Thu, 08 May 2003 17:01:13 +0000 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 19DolT-000BTO-00 for multi6@ops.ietf.org; Thu, 08 May 2003 17:01:03 +0000 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h48H11tU000107; Thu, 8 May 2003 13:01:01 -0400 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id h48H10X3000105; Thu, 8 May 2003 13:01:00 -0400 Date: Thu, 8 May 2003 13:01:00 -0400 From: "J. Noel Chiappa" Message-Id: <200305081701.h48H10X3000105@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: RE: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: "Bound, Jim" > 8+8 (my preferred term for GSE) The two are fairly different, actually. 8+8 was originally proposed by Dave Clark, and it was splitting the IPv6 address into two fields, a 64-bit globally unique identifier in the low part, and a locator in the high part. GSE was an enhancement to that done by Mike O'Dell in which the high order parts (of both source and destination) were massaged by border routers to achieve various things. It brings a number of additional capabilities, but at the cost of making the location<->identity binding even harder to secure. (Unless you just throw your hands in the air and use authentication on all packets, at which point the address becomes irrelevant.) Noel From owner-multi6@ops.ietf.org Thu May 8 13:14:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00515 for ; Thu, 8 May 2003 13:14:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Dp0G-000E49-00 for multi6-data@psg.com; Thu, 08 May 2003 17:16:20 +0000 Received: from smtp02.uc3m.es ([163.117.136.122] helo=smtp.uc3m.es) by psg.com with esmtp (Exim 3.36 #1) id 19Dp0C-000E3l-00 for multi6@ops.ietf.org; Thu, 08 May 2003 17:16:16 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 8788A4323A; Thu, 8 May 2003 19:16:15 +0200 (CEST) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp02.uc3m.es (Postfix) with ESMTP id 59A6999F9D; Thu, 8 May 2003 19:16:15 +0200 (CEST) Subject: RE: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] From: marcelo bagnulo To: "Bound, Jim" Cc: Iljitsch van Beijnum , multi6@ops.ietf.org In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03241213@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B03241213@tayexc13.americas.cpqcorp.net> Content-Type: text/plain Organization: uc3m Message-Id: <1052414088.1093.51.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 May 2003 19:14:49 +0200 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jim, i share all your doubts. However, i think that the 64 lower bits of IPv6 addresses are currently reserved for an identifier, and they are already carried in all packets so why not just use it? (just as GSE) I guess you can carry the identifier somewhere else, but i would say that if we can save some bits it would be interesting One of the problems is security, which (with my little knowledge about the subject) can be solved usdign HIP like techniques, so just include the HIT as the 64 lower bits of the IPv6 address This could preserve the nice feature of GSE that the state is only maintained in the end hosts and routers could make a stateless translation. But probably there are thousands things that i am missing here... Regards, marcelo On Thu, 2003-05-08 at 15:47, Bound, Jim wrote: > Hi Marcelo, > > Yes the HIP SPI could use the low order 64 bits but I want to read > updates from Pekka N. just sent out for arch-03. I am also unclear the > HIP code changes to our transport layers or at the IP layers will be > done by what time frame. > > As far as GSE I am very behind in mail and have to read a few things and > being quite now. But if we can change the high end 64 bits then I am > naievly unclear why MHAP architecture is not valid for solution instead > of hardline differentiation for 8+8 (my preferred term for GSE). > > I am also not clear on rewrite of headers in transit is going to fly in > some cases I can think of as use case and one example is the military > tactical operations case, which for me is one area I work on and care > about as one of my roles working with users. But, in many cases they are > their own Internet and can do things that cannot be done on the public > Internet as easily simply from total network operations control. I > believe if we rewrite headers we need to swap them into new routing > header type for IPv6 too, which will remove going to the DNS, LDAP, or > MPLS database to get back to the end node. I view this feature as > keeping a history of location that is important. Off the top of my I > would think we have to assume location will not change for 300 > milliseconds (use this as that is what is needed for RTT for VoIP to be > successful), but we probably need to define some time_t variables for > the solution as best guess or derived time_t for when location can > change. > Probably also need to think about identity changing from say system > crash, neighbor discovery DAD collision (after the fact of solicited > node multicast which I have seen in the real world). > > I know I am going far to down in details sorry :--) > > /jim > > > -----Original Message----- > > From: marcelo bagnulo [mailto:marcelo@it.uc3m.es] > > Sent: Thursday, May 08, 2003 9:10 AM > > To: Bound, Jim > > Cc: Iljitsch van Beijnum; multi6@ops.ietf.org > > Subject: RE: GSE IDs [Re: IETF multihoming powder: just add > > IPv6 and stir] > > > > > > Hi Jim, > > > > I was not aware of this, thanks for pointing it out. > > > > Perhaps if i rephrase it in the following way it would be acceptable? > > > > Instead of including the HIP's HIT in the SPI, we could > > include it in the lower 64 bits of the IP addresses. This > > would imply that the 64 lower bits could be used as > > identifiers and the 64 higher bits can be changed for routing > > purposes. Perhaps this would provide the security features > > needed for GSE to work in a stateless fashion. > > > > Regards, marcelo > > > > On Thu, 2003-05-08 at 14:59, Bound, Jim wrote: > > > CGA's have to many IPR issues lets not go there here for this work > > > please. /jim > > > > > > > -----Original Message----- > > > > From: marcelo bagnulo [mailto:marcelo@it.uc3m.es] > > > > Sent: Thursday, May 08, 2003 8:30 AM > > > > To: Iljitsch van Beijnum > > > > Cc: multi6@ops.ietf.org > > > > Subject: Re: GSE IDs [Re: IETF multihoming powder: just add > > > > IPv6 and stir] > > > > > > > > > > > > On Thu, 2003-05-08 at 13:30, Iljitsch van Beijnum wrote: > > > > > On donderdag, mei 8, 2003, at 13:10 Europe/Amsterdam, > > > > marcelo bagnulo > > > > > wrote: > > > > > > > > > > > I guess that what Brian means is that this (what you are > > > > describing) > > > > > > is not GSE anymore, since it is not stateless (which is a > > > > > > fundamental feature of GSE, as i see it) > > > > > > > > > > No disagreement there. > > > > > > > > > > > what you are describing sounds more like MHAP... > > > > > > > > > > Originally, I wanted to write something that encompasses > > > > both MHAP and > > > > > GSE. But: > > > > > > > > > > "The original GSE and 8+8 drafts split the IPv6 address > > > > in two 64-bit > > > > > parts. The lower part is used within the site or > > > > subnet. Routers add > > > > > the higher 64 bits as packets leave the site. Since > > > > hosts don't know > > > > > the higher 64 bits their correspondent will see, they > > > > must disregard > > > > > these bits, which has the relatively minor consequence > > > > that the TCP > > > > > and UDP pseudo header used in checksum calculations > > > > must be changed. > > > > > A more severe consequence is that the lower 64 bits > > must now be > > > > > globally unique. This in turn makes it very easy to > > > > perform spoofing > > > > > attacks, as an attacker can simply present > > arbitrary lower bits, > > > > > thereby assuming any desired identity, while setting > > > > the higher bits > > > > > such that the packets are routed back to the attacker > > > > and not to the > > > > > host identified by the lower 64 bits. This > > > > vulnerability, breaking > > > > > autoconfiguration and, to a lesser degree, the > > transport layer > > > > > checksums, make adopting GSE or 8+8 unfeasible and > > > > > undesirable." > > > > > > > > > > Is there anyone who disagrees and feels stateless GSE is > > > > still viable? > > > > > > > > > > > > > I think that the statless condition of GSE is really valuable > > > > and perhaps we can come up with a solution that can preserve it. > > > > > > > > As you mention, security issues need to be solved somehow in > > > > order to enable this solution. > > > > > > > > A possibility would be to use crypto identifiers such as in > > > > HIP but included in the 64 lower bits of the address (CGAs) > > > > > > > > I guess that this could provide the security needed and it > > > > would also preserve middle boxes stateless as in GSE. > > > > > > > > > > > > Regards, marcelo > > > > > > > > > > > > > The letter combination "GSE" will not appear in the title. The > > > > > preliminary title is "Multihoming in IPv6 by Rewriting > > Addresses". > > > > -- > > > > marcelo bagnulo > > > > uc3m > > > > > > > > > > > > > > -- > > marcelo bagnulo > > uc3m > > > > -- marcelo bagnulo uc3m From owner-multi6@ops.ietf.org Thu May 8 13:17:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00583 for ; Thu, 8 May 2003 13:17:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Dp3J-000EKi-00 for multi6-data@psg.com; Thu, 08 May 2003 17:19:29 +0000 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 19Dp3F-000EK7-00 for multi6@ops.ietf.org; Thu, 08 May 2003 17:19:25 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 3E8EFBB1C; Thu, 8 May 2003 13:19:20 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Thu, 8 May 2003 13:19:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Date: Thu, 8 May 2003 13:19:19 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD778@tayexc13.americas.cpqcorp.net> Thread-Topic: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Thread-Index: AcMVhRNJR8xY+zAzTiSP0G7cLYnyJwAAL2pg From: "Bound, Jim" To: "J. Noel Chiappa" , X-OriginalArrivalTime: 08 May 2003 17:19:19.0999 (UTC) FILETIME=[F61634F0:01C31585] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA00583 Agreed. In the meeting I was in Mike called it 8+8 to but your note is accurate. Thanks /jim > -----Original Message----- > From: J. Noel Chiappa [mailto:jnc@ginger.lcs.mit.edu] > Sent: Thursday, May 08, 2003 1:01 PM > To: multi6@ops.ietf.org > Cc: jnc@ginger.lcs.mit.edu > Subject: RE: GSE IDs [Re: IETF multihoming powder: just add > IPv6 and stir] > > > > From: "Bound, Jim" > > > 8+8 (my preferred term for GSE) > > The two are fairly different, actually. > > 8+8 was originally proposed by Dave Clark, and it was > splitting the IPv6 > address into two fields, a 64-bit globally unique identifier > in the low part, and a locator in the high part. > > GSE was an enhancement to that done by Mike O'Dell in which > the high order parts (of both source and destination) were > massaged by border routers to achieve various things. It > brings a number of additional capabilities, but at the cost > of making the location<->identity binding even harder to > secure. (Unless you just throw your hands in the air and use > authentication on all packets, at which point the address > becomes irrelevant.) > > Noel > > From owner-multi6@ops.ietf.org Thu May 8 14:26:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02594 for ; Thu, 8 May 2003 14:26:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Dq8G-0000tD-00 for multi6-data@psg.com; Thu, 08 May 2003 18:28:40 +0000 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 19Dq8D-0000sn-00 for multi6@ops.ietf.org; Thu, 08 May 2003 18:28:37 +0000 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 1B3FB137F02; Thu, 8 May 2003 11:28:36 -0700 (PDT) Date: Thu, 8 May 2003 11:28:31 -0700 Subject: Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Brian E Carpenter From: David Conrad In-Reply-To: <3EB8CD07.BCD04EFD@hursley.ibm.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian, On Wednesday, May 7, 2003, at 02:08 AM, Brian E Carpenter wrote: >> Or you simply rewrite the first 48 bits when the packet traverses the >> border into the destination site with the same value the packet had >> prior to traversing the border of the source site. > This was not part of any GSE proposal I ever saw, Different terminology would be helpful. Of course, this implies my messages on this topic have been whistling past people for the last two months. > and it involves stateful > distribution of mapping information. Yes. In one approach, a mapping of a globally unique 48 bit value to a set of other globally unique 48 bit values where that distributed lookup of that mapping occurs at the source border only. > A very different beast from GSE, > and it sets off my stateful=bad alarm. Your alarm must go off continually today, as the mapping is more or less equivalent to either the DNS or routing tables, depending on your point of view. Rgds, -drc From owner-multi6@ops.ietf.org Thu May 8 14:34:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02841 for ; Thu, 8 May 2003 14:34:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DqGk-0002Ub-00 for multi6-data@psg.com; Thu, 08 May 2003 18:37:26 +0000 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 19DqGg-0002UJ-00 for multi6@ops.ietf.org; Thu, 08 May 2003 18:37:22 +0000 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id D0C66137F02; Thu, 8 May 2003 11:37:21 -0700 (PDT) Date: Thu, 8 May 2003 11:37:20 -0700 Subject: Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "marcelo bagnulo" , "Iljitsch van Beijnum" , To: "Bound, Jim" From: David Conrad In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03241213@tayexc13.americas.cpqcorp.net> Message-Id: <1A4597E0-8184-11D7-9BA8-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jim, On Thursday, May 8, 2003, at 06:47 AM, Bound, Jim wrote: > I am also not clear on rewrite of headers in transit is going to fly in > some cases I can think of as use case and one example is the military > tactical operations case, which for me is one area I work on and care > about as one of my roles working with users. I'd be interested in understanding these cases better. From my perspective, what happens to my packet headers after they leave my machine is completely irrelevant as long as they get put back together into something that will pass the checksum on the destination host. > I believe if we rewrite headers we need to swap them into new routing > header type for IPv6 too, which will remove going to the DNS, LDAP, or > MPLS database to get back to the end node. I view this feature as > keeping a history of location that is important. Why? > Probably also need to think about identity changing from say system > crash, neighbor discovery DAD collision (after the fact of solicited > node multicast which I have seen in the real world). The appoach I've been thinking about does not touch the identity of the end system as determined via DAD or any other mechanism -- a packet has a site identity value in the top 48 bits of the destination address that maps into an aggregatable locator when the packet leaves the source site and gets remapped from the locator back into the site identity when it arrives at the destination site. > I know I am going far to down in details sorry :--) I like details when trying to figure out if a particular (arguably radical) approach will fly. Rgds, -drc From owner-multi6@ops.ietf.org Thu May 8 15:14:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05064 for ; Thu, 8 May 2003 15:14:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Dqs2-0009t9-00 for multi6-data@psg.com; Thu, 08 May 2003 19:15:58 +0000 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 19Dqrz-0009sx-00 for multi6@ops.ietf.org; Thu, 08 May 2003 19:15:55 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id C5A1E418D; Thu, 8 May 2003 15:15:53 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Thu, 8 May 2003 15:15:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Date: Thu, 8 May 2003 15:15:50 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0324121B@tayexc13.americas.cpqcorp.net> Thread-Topic: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Thread-Index: AcMVkOIfPpVlEd0tR4KdaTEvXc+HdQABIJcg From: "Bound, Jim" To: "David Conrad" Cc: "marcelo bagnulo" , "Iljitsch van Beijnum" , X-OriginalArrivalTime: 08 May 2003 19:15:50.0501 (UTC) FILETIME=[3CC02950:01C31596] X-Spam-Status: No, hits=-10.4 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA05064 Dave, > On Thursday, May 8, 2003, at 06:47 AM, Bound, Jim wrote: > > I am also not clear on rewrite of headers in transit is > going to fly > > in some cases I can think of as use case and one example is the > > military tactical operations case, which for me is one area > I work on > > and care about as one of my roles working with users. > > I'd be interested in understanding these cases better. From my > perspective, what happens to my packet headers after they leave my > machine is completely irrelevant as long as they get put back > together > into something that will pass the checksum on the destination host. If I am communicating with two command centers for mission critical operation I want a knob that says I trust NO ONE and NO ONE is to rewrite my headers but only forward operations. Having a routing header type would at least track that operation within the context of the datagram. Also cases where the entire IP datagram is compressed. Cases where all below the Header and DST/HOP-BY-HOP operations is ecrypted and I do not want to trust any path to rewrite incorrectly where the end result of that error are dead people. > > I believe if we rewrite headers we need to swap them into > new routing > > header type for IPv6 too, which will remove going to the > DNS, LDAP, or > > MPLS database to get back to the end node. I view this feature as > > keeping a history of location that is important. > If I save the orgininal loc+id in route header I can pass it along and likewise use it to pass it back. MHAP could use this feature too. /jim > > > Probably also need to think about identity changing from say system > > crash, neighbor discovery DAD collision (after the fact of > solicited > > node multicast which I have seen in the real world). > > The appoach I've been thinking about does not touch the > identity of the > end system as determined via DAD or any other mechanism -- a > packet has > a site identity value in the top 48 bits of the destination address > that maps into an aggregatable locator when the packet leaves the > source site and gets remapped from the locator back into the site > identity when it arrives at the destination site. > > > I know I am going far to down in details sorry :--) > > I like details when trying to figure out if a particular (arguably > radical) approach will fly. > > Rgds, > -drc > > From owner-multi6@ops.ietf.org Thu May 8 15:39:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06353 for ; Thu, 8 May 2003 15:39:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DrGs-000EmX-00 for multi6-data@psg.com; Thu, 08 May 2003 19:41:38 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19DrGp-000EmK-00 for multi6@ops.ietf.org; Thu, 08 May 2003 19:41:36 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h48JeGn18481; Thu, 8 May 2003 21:40:17 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 8 May 2003 21:40:18 +0200 Subject: Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Brian E Carpenter From: Iljitsch van Beijnum In-Reply-To: <3EBA7B5B.A3FD41AC@hursley.ibm.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On donderdag, mei 8, 2003, at 17:44 Europe/Amsterdam, Brian E Carpenter wrote: >> Wouldn't such an additional layer always carry even more state with >> it? >> The only advantage is that this kind of state is kept in the >> endpoints. >> However, then we end up with the requirement that endpoints must >> implement the solution, which leads to deployment problems and >> management difficulties in some networks. > Right, except that we have to solve key management anyway, to make any > kind of security scale. Which as we know is hardly trivial. What I was talking about wasn't key management, but the problem that if each individual host makes its own decisions it's hard to implement traffic engineering and other policies. Rewriting the source address helps some here as this makes return traffic take a certain path, but the problem remains for destination address selection. Deployment is problematic because GSE hosts will have to communicate with non-GSE hosts, in which case the border routers must leave the source address alone. Source rewriting is really only an optimization: with some extra effort, the source host can find out which source address it should use. It's starting to look like this optimization is more expensive than simply doing it the hard way and let the host figure out the source address it has to use by trial and error (for "GSE"-enabled sessions), possibly aided by ICMP messages. >>> I think that is what you should say. >> I'm getting there... It's still more than a month before the draft >> cutoff for Vienna. :-) > Lots of time to solve a problem that was discovered around 1992 :-) I'm flattered that you assume my draft will be the one to solve this problem. (-: Iljitsch From owner-multi6@ops.ietf.org Thu May 8 19:06:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16097 for ; Thu, 8 May 2003 19:06:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DuUo-0006Lc-00 for multi6-data@psg.com; Thu, 08 May 2003 23:08:14 +0000 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #1) id 19DuUl-0006LM-00 for multi6@ops.ietf.org; Thu, 08 May 2003 23:08:11 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 7250F3443B; Thu, 8 May 2003 15:22:29 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h48N81YB003286; Thu, 8 May 2003 16:08:05 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Date: Thu, 8 May 2003 16:08:01 -0700 Message-ID: Thread-Topic: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Thread-Index: AcMVT1b8jAkLIWmPQRmstnm4E1FKwwAZwjew From: "Tony Li" To: "Iljitsch van Beijnum" , "Brian E Carpenter" Cc: X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA16097 I would prefer that we avoided having a stateful mapping mechanism. It's unnecessary and certainly more complication than we need. I would also prefer that we not proclaim something to be GSE that isn't, regardless of congruence or continuation of ideas. GSE is a specific idea and while it can certainly evolve, I think it's a disservice to mo to re-use his name for something else without his permission. Tony | -----Original Message----- | From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] | Sent: Thursday, May 08, 2003 3:33 AM | To: Brian E Carpenter | Cc: multi6@ops.ietf.org | Subject: Re: GSE IDs [Re: IETF multihoming powder: just | add IPv6 and stir] | | | On donderdag, mei 8, 2003, at 11:50 Europe/Amsterdam, | Brian E Carpenter | wrote: | | >>> and it involves stateful distribution of mapping | information. A very | >>> different beast from GSE, and it sets off my | stateful=bad alarm. | | >> Actually this wouldn't be a problem at all since we | have to keep this | >> exact same state anyway in order to map the other way around for | >> sending packets back. | | > Again, not in GSE as I understand it. | | I don't think it's a coincidence that there hasn't been | any progress | with GSE for five years or so. In theory, GSE can work without a | mapping mechanism, but this opens the door to security | problems. So in | practice we need to keep state to know whether there is a | valid locator | <-> identifier mapping to avoid trivial identity theft. And if we | accept that, we may as well remove the whole globally | unique lower 64 | bit thing as it just breaks too much stuff without any | real benefits at | this point. | | Aside from that, not having a mapping mechanism makes | failover very | difficult: the only way that still works is if the border | router at the | source sees the problem. This works for last mile | problems, but not for | routing problems further upstream. I know others have different | experiences, but for me routing problems are the number | one cause of | outages. | | Is there anyone who wants to stick with GSE without a | mapping mechanism? | | | From owner-multi6@ops.ietf.org Fri May 9 01:01:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23222 for ; Fri, 9 May 2003 01:01:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19E00t-000BkN-00 for multi6-data@psg.com; Fri, 09 May 2003 05:01:43 +0000 Received: from dhcp1.se.kurtis.pp.se ([195.43.225.70]) by psg.com with esmtp (Exim 3.36 #1) id 19E00n-000BkA-00 for multi6@ops.ietf.org; Fri, 09 May 2003 05:01:37 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h4953nTq006243; Fri, 9 May 2003 07:03:49 +0200 (CEST) Date: Fri, 9 May 2003 07:03:44 +0200 Subject: Re: Mutli6 meeting in Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Bound, Jim" From: Kurt Erik Lindqvist In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03241214@tayexc13.americas.cpqcorp.net> Message-Id: <9BE8BA1A-81DB-11D7-B6FB-000393520ED8@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-16.1 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I am rethinking my R&R time off in July and might change my mind and > come to Vienna. > Part of my decision is are we going to meet officially as Multi6 and if > we do can we schedule one 2 hour offsite but not on Sunday as coming > from U.S. I don't want to get there on Saturday (well I can't). Us > meeting would input to my decision and two other areas of the IETF I am > not comfortable not being at for some issues that require important > face-to-face discussion. > We are in the clear that we should meet. What we need to work on is the agenda. Me and Sean have been sending some sporadic emails between eachother on this, but I guess we need to more a bit more here. As to an off-site face-to-face meeting, I would say that this is partly up to what the agenda would include. I am still also open to input on the agenda and the structure of the meeting. From the past weeks discussions here I would assume that "GSE" will be a large topic, but we would need something to discuss around. We also have Pekkas draft and we have the option to have someone go through the options brought to the IETF so far (I was going through the ID archives but I could't find much more than my drafts, Iljitsch, Tonys and Michels expired drafts. Then we also have HIP. Have I missed something?). Opinions? I guess that if we want to have a private session, that would be on the topic of identifier/locator separation ? - kurtis - From owner-multi6@ops.ietf.org Fri May 9 02:08:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03429 for ; Fri, 9 May 2003 02:08:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19E14v-000Hd8-00 for multi6-data@psg.com; Fri, 09 May 2003 06:09:57 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19E14s-000Hcv-00 for multi6@ops.ietf.org; Fri, 09 May 2003 06:09:55 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4966jL01005; Fri, 9 May 2003 09:06:45 +0300 Date: Fri, 9 May 2003 09:06:45 +0300 (EEST) From: Pekka Savola To: Kurt Erik Lindqvist cc: "Bound, Jim" , Subject: Re: Mutli6 meeting in Vienna In-Reply-To: <9BE8BA1A-81DB-11D7-B6FB-000393520ED8@kurtis.pp.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 9 May 2003, Kurt Erik Lindqvist wrote: > We also have Pekkas draft and we have the option to have someone go > through the options brought to the IETF so far (I was going through the > ID archives but I could't find much more than my drafts, Iljitsch, > Tonys and Michels expired drafts. I could also do the summary if necessary, as I've already made one myself, but that could be a bit biased.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Fri May 9 02:54:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07008 for ; Fri, 9 May 2003 02:54:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19E1nt-000M0B-00 for multi6-data@psg.com; Fri, 09 May 2003 06:56:25 +0000 Received: from astrolabe.info.ucl.ac.be ([130.104.229.109] helo=info.ucl.ac.be) by psg.com with esmtp (Exim 3.36 #1) id 19E1nq-000Lzy-00 for multi6@ops.ietf.org; Fri, 09 May 2003 06:56:22 +0000 Received: from descartes.info.ucl.ac.be (descartes [130.104.229.82]) by info.ucl.ac.be (8.12.9/8.12.8) with ESMTP id h496tCRK029641 for ; Fri, 9 May 2003 08:55:12 +0200 (MET DST) Subject: Re: Mutli6 meeting in Vienna From: Cedric de Launois To: multi6@ops.ietf.org In-Reply-To: <9BE8BA1A-81DB-11D7-B6FB-000393520ED8@kurtis.pp.se> References: <9BE8BA1A-81DB-11D7-B6FB-000393520ED8@kurtis.pp.se> Content-Type: text/plain; charset=ISO-8859-1 Organization: Universite Catholique de Louvain Message-Id: <1052463399.749.24.camel@descartes.info.ucl.ac.be> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 09 May 2003 08:56:39 +0200 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_XIMIAN autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Le ven 09/05/2003 à 07:03, Kurt Erik Lindqvist a écrit : > ... (I was going through the > ID archives but I could't find much more than my drafts, Iljitsch, > Tonys and Michels expired drafts. Then we also have HIP. Have I missed > something?). Opinions? I am currently working on a new draft, "Host-Centric IPv6 Multihoming with Traffic Engineering". It will be soon ready. It is quite far from what is discussed here at the moment but I think we should not forget host-centric solutions and traffic engineering needs. Cedric From owner-multi6@ops.ietf.org Fri May 9 04:09:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08656 for ; Fri, 9 May 2003 04:09:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19E2xd-0003Wh-00 for multi6-data@psg.com; Fri, 09 May 2003 08:10:33 +0000 Received: from mail-gw1.hursley.ibm.com ([194.196.110.15]) by psg.com with esmtp (Exim 3.36 #1) id 19E2xZ-0003WV-00 for multi6@ops.ietf.org; Fri, 09 May 2003 08:10:29 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19E2xX-0000Ty-00; Fri, 09 May 2003 09:10:27 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19E2xX-0000Tt-00; Fri, 09 May 2003 09:10:27 +0100 Received: from hursley.ibm.com (dhcp21-189.zurich.ibm.com [9.4.21.189]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id JAA115318; Fri, 9 May 2003 09:10:20 +0100 Message-ID: <3EBB628D.D4CDFFA9@hursley.ibm.com> Date: Fri, 09 May 2003 10:10:53 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: David Conrad CC: multi6@ops.ietf.org Subject: Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit David Conrad wrote: > > Brian, > > On Wednesday, May 7, 2003, at 02:08 AM, Brian E Carpenter wrote: > >> Or you simply rewrite the first 48 bits when the packet traverses the > >> border into the destination site with the same value the packet had > >> prior to traversing the border of the source site. > > This was not part of any GSE proposal I ever saw, > > Different terminology would be helpful. Of course, this implies my > messages on this topic have been whistling past people for the last two > months. > > > and it involves stateful > > distribution of mapping information. > > Yes. In one approach, a mapping of a globally unique 48 bit value to a > set of other globally unique 48 bit values where that distributed > lookup of that mapping occurs at the source border only. > > > A very different beast from GSE, > > and it sets off my stateful=bad alarm. > > Your alarm must go off continually today, as the mapping is more or > less equivalent to either the DNS or routing tables, depending on your > point of view. Right, and we know that faulty DNS setups cause connectivity glitches on a daily basis - because DNS state is created and managed by every site worthy of the name, and mistakes are inevitable. We also had years of connectivity glitches caused by BGP4 configuration errors - most operators seem to have that figured out now, but it was bad for a while. Introducing a third distributed state mechanism that will be critical for connectivity is indeed a big step. Brian From owner-multi6@ops.ietf.org Fri May 9 04:26:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09155 for ; Fri, 9 May 2003 04:26:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19E3F4-0005XX-00 for multi6-data@psg.com; Fri, 09 May 2003 08:28:34 +0000 Received: from [3ffe:501:100c:d120::53] (helo=shonan.sfc.wide.ad.jp) by psg.com with esmtp (Exim 3.36 #1) id 19E3Eu-0005NS-00 for multi6@ops.ietf.org; Fri, 09 May 2003 08:28:24 +0000 Received: from localhost.sfc.wide.ad.jp (unknown [203.178.138.14]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id AE1035D019 for ; Fri, 9 May 2003 17:27:53 +0900 (JST) Date: Fri, 9 May 2003 17:22:23 +0900 From: Thierry Ernst To: multi6@ops.ietf.org Subject: What is a site ? Message-Id: <20030509172223.02fa4153.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear all, I'm trying to understand the concept of site, and I'm stuck. I think the definitions below are not consitent (same or different ISPs) ? From the Multi6 charter: ~~~~~~~~~~~~~~~~~~~~~~~~ Description of Working Group: A multihomed site is a site that has more than one connection to the public internet with those connections through either the same or different ISPs From http://www.ietf.org/internet-drafts/draft-ietf-multi6-multihoming-requirements-05.txt ~~~~ Abstract Site-multihoming, i.e. connecting to more than one IP service provider, is an essential component of service for many sites which are part of the Internet. Terminology A "multihomed" site is one with more than one transit provider. "Site-multihoming" is the practice of arranging a site to be multihomed. Thierry Ernst, WIDE. From owner-multi6@ops.ietf.org Fri May 9 04:42:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09493 for ; Fri, 9 May 2003 04:42:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19E3V1-0007SV-00 for multi6-data@psg.com; Fri, 09 May 2003 08:45:03 +0000 Received: from mail-gw1.hursley.ibm.com ([194.196.110.15]) by psg.com with esmtp (Exim 3.36 #1) id 19E3Ux-0007Qw-00 for multi6@ops.ietf.org; Fri, 09 May 2003 08:44:59 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19E3Ux-0002Op-00; Fri, 09 May 2003 09:44:59 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19E3Uw-0002Of-00; Fri, 09 May 2003 09:44:58 +0100 Received: from hursley.ibm.com (dhcp222-27.zurich.ibm.com [9.4.222.27]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id JAA185150; Fri, 9 May 2003 09:44:57 +0100 Message-ID: <3EBB6AA9.5524DAA6@hursley.ibm.com> Date: Fri, 09 May 2003 10:45:29 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Kurt Erik Lindqvist CC: multi6@ops.ietf.org Subject: Re: Mutli6 meeting in Vienna References: <9BE8BA1A-81DB-11D7-B6FB-000393520ED8@kurtis.pp.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think what would be excellent would be for someone to open the meeting with an overview of the classes of solutions. We may need to launch parallel efforts, so agreeing which classes of solution we want to develop is an important first step. Brian Kurt Erik Lindqvist wrote: > > > I am rethinking my R&R time off in July and might change my mind and > > come to Vienna. > > Part of my decision is are we going to meet officially as Multi6 and if > > we do can we schedule one 2 hour offsite but not on Sunday as coming > > from U.S. I don't want to get there on Saturday (well I can't). Us > > meeting would input to my decision and two other areas of the IETF I am > > not comfortable not being at for some issues that require important > > face-to-face discussion. > > > > We are in the clear that we should meet. What we need to work on is the > agenda. Me and Sean have been sending some sporadic emails between > eachother on this, but I guess we need to more a bit more here. As to > an off-site face-to-face meeting, I would say that this is partly up to > what the agenda would include. > > I am still also open to input on the agenda and the structure of the > meeting. From the past weeks discussions here I would assume that "GSE" > will be a large topic, but we would need something to discuss around. > We also have Pekkas draft and we have the option to have someone go > through the options brought to the IETF so far (I was going through the > ID archives but I could't find much more than my drafts, Iljitsch, > Tonys and Michels expired drafts. Then we also have HIP. Have I missed > something?). Opinions? > > I guess that if we want to have a private session, that would be on the > topic of identifier/locator separation ? > > - kurtis - From owner-multi6@ops.ietf.org Fri May 9 04:47:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09567 for ; Fri, 9 May 2003 04:47:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19E3aG-00089B-00 for multi6-data@psg.com; Fri, 09 May 2003 08:50:28 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19E3aC-00088v-00 for multi6@ops.ietf.org; Fri, 09 May 2003 08:50:24 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h498n4n19747; Fri, 9 May 2003 10:49:04 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 9 May 2003 10:49:05 +0200 Subject: Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: "Tony Li" From: Iljitsch van Beijnum In-Reply-To: Message-Id: <1745C9F6-81FB-11D7-AF00-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On vrijdag, mei 9, 2003, at 01:08 Europe/Amsterdam, Tony Li wrote: > I would prefer that we avoided having a stateful mapping mechanism. It all flows from having more than one address with different reachability properties. At some point, someone has to decide which address to use for a particular purpose, and it had better be the "right" address most of the time or we're worse off than being single-homed. > It's unnecessary and certainly more complication than we need. It doesn't have to be complicated: something as simple as publishing all the addresses in the DNS and/or in an option in the first packet along with a simple algorithm that figures out which address seems to be working best is all we need. (But it may not be all we want.) What kind of stateless mechanism do you have in mind? Obviously a stateless solution would be preferable over a stateful one. > I would also prefer that we not proclaim something to be GSE that > isn't, regardless of congruence or continuation of ideas. I did use the term "GSE" a bit loosely a week or so ago but rest assured that this won't happen in the final version of the draft. From owner-multi6@ops.ietf.org Fri May 9 07:08:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12531 for ; Fri, 9 May 2003 07:08:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19E5lG-0001Mp-00 for multi6-data@psg.com; Fri, 09 May 2003 11:09:58 +0000 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 3.36 #1) id 19E5lD-0001MS-00 for multi6@ops.ietf.org; Fri, 09 May 2003 11:09:55 +0000 Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 0D3B61C; Fri, 9 May 2003 14:19:52 +0300 (EEST) Message-ID: <3EBB8CAC.9040908@nomadiclab.com> Date: Fri, 09 May 2003 14:10:36 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Bound, Jim" Cc: multi6@ops.ietf.org Subject: Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] References: <9C422444DE99BC46B3AD3C6EAFC9711B03241213@tayexc13.americas.cpqcorp.net> In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03241213@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jim, Bound, Jim wrote: > Yes the HIP SPI could use the low order 64 bits but I want to read > updates from Pekka N. just sent out for arch-03. I am also unclear the > HIP code changes to our transport layers or at the IP layers will be > done by what time frame. HIP, in the way we implement it today, does not require any changes to the transport layers at all, or to the IP layer in anywhere else but at the end-hosts. That is, of course, not the only way to implement HIP, and it is probably also possible to "distribute" HIP between an end-host and a middle box, resulting in something that resembles MHAP. In our current implementation, the only changes in the kernel are in IPsec ESP code. All the rest is in user level, and the user level deamon dynamically modifies the IPsec SPD and SA entries to implement mobility. Implementing multi-homing will require more extensive changes to IPsec or elsewhere in the kernel. We are still thinking on how to do that. Basically, we need to implement destination address selection somewhere in the kernel. (At this stage we will be ignoring the actual selection algorithm, and concentrate on the architecture: Where to "rewrite" the HIT into an IP address, and how to select the right destination (and source) address(es).) --Pekka Nikander From owner-multi6@ops.ietf.org Fri May 9 07:18:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12634 for ; Fri, 9 May 2003 07:18:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19E5vf-00032j-00 for multi6-data@psg.com; Fri, 09 May 2003 11:20:43 +0000 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 3.36 #1) id 19E5vc-00032X-00 for multi6@ops.ietf.org; Fri, 09 May 2003 11:20:41 +0000 Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 2242A1C; Fri, 9 May 2003 14:30:37 +0300 (EEST) Message-ID: <3EBB8F32.9040106@nomadiclab.com> Date: Fri, 09 May 2003 14:21:22 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: marcelo bagnulo Cc: multi6@ops.ietf.org Subject: Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] References: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD761@tayexc13.americas.cpqcorp.net> <1052399420.1093.38.camel@presto.it.uc3m.es> In-Reply-To: <1052399420.1093.38.camel@presto.it.uc3m.es> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Marcelo, marcelo bagnulo wrote: > Instead of including the HIP's HIT in the SPI, we could include it in > the lower 64 bits of the IP addresses. This would imply that the 64 > lower bits could be used as identifiers and the 64 higher bits can be > changed for routing purposes. Perhaps this would provide the security > features needed for GSE to work in a stateless fashion. I am afraid such a practice would fall within the claims of the patent I know about. Basically, the widest claim cover anything that effectively does interface id = hash(public key | anything) where | is concatenation (in any order). Thus, to circumvent that you both have to split the IPv6 address into something else but 64+64, and call the right hand (identifier) part something else but interface id. And even then I am not sure if you would be done. But IANAL, so go and check the patent. It can be found in the British patent database fairly easily. Then there is another problem. 64 bits is not quite enough to be secure in the future. See draft-aura-cga-00.txt for the detailed analysis and a suggestion on how to work around that limitation. --Pekka Nikander From owner-multi6@ops.ietf.org Fri May 9 07:58:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13196 for ; Fri, 9 May 2003 07:58:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19E6Y7-0009Wl-00 for multi6-data@psg.com; Fri, 09 May 2003 12:00:27 +0000 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 19E6Xq-0009WH-00 for multi6@ops.ietf.org; Fri, 09 May 2003 12:00:10 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id DC340AB69; Fri, 9 May 2003 08:00:05 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Fri, 9 May 2003 08:00:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Date: Fri, 9 May 2003 08:00:05 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD7AD@tayexc13.americas.cpqcorp.net> Thread-Topic: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Thread-Index: AcMWA/ScRzLgO60GRhyL29jGrAdFLwAHobqg From: "Bound, Jim" To: "Brian E Carpenter" , "David Conrad" Cc: X-OriginalArrivalTime: 09 May 2003 12:00:05.0710 (UTC) FILETIME=[87A766E0:01C31622] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA13196 There is no reason to do this based on my previous mail. /jim > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Friday, May 09, 2003 4:11 AM > To: David Conrad > Cc: multi6@ops.ietf.org > Subject: Re: GSE IDs [Re: IETF multihoming powder: just add > IPv6 and stir] > > > David Conrad wrote: > > > > Brian, > > > > On Wednesday, May 7, 2003, at 02:08 AM, Brian E Carpenter wrote: > > >> Or you simply rewrite the first 48 bits when the packet > traverses > > >> the border into the destination site with the same value > the packet > > >> had prior to traversing the border of the source site. > > > This was not part of any GSE proposal I ever saw, > > > > Different terminology would be helpful. Of course, this implies my > > messages on this topic have been whistling past people for the last > > two months. > > > > > and it involves stateful > > > distribution of mapping information. > > > > Yes. In one approach, a mapping of a globally unique 48 > bit value to > > a set of other globally unique 48 bit values where that distributed > > lookup of that mapping occurs at the source border only. > > > > > A very different beast from GSE, > > > and it sets off my stateful=bad alarm. > > > > Your alarm must go off continually today, as the mapping > is more or > > less equivalent to either the DNS or routing tables, > depending on your > > point of view. > > Right, and we know that faulty DNS setups cause connectivity > glitches on a daily basis - because DNS state is created and > managed by every site worthy of the name, and mistakes are > inevitable. We also had years of > connectivity glitches caused by BGP4 configuration errors - > most operators > seem to have that figured out now, but it was bad for a > while. Introducing > a third distributed state mechanism that will be critical for > connectivity > is indeed a big step. > > Brian > > From owner-multi6@ops.ietf.org Fri May 9 08:02:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13290 for ; Fri, 9 May 2003 08:02:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19E6cm-000AMv-00 for multi6-data@psg.com; Fri, 09 May 2003 12:05:16 +0000 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 19E6ch-000AMY-00 for multi6@ops.ietf.org; Fri, 09 May 2003 12:05:11 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 6A827B666; Fri, 9 May 2003 08:05:10 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Fri, 9 May 2003 08:05:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Date: Fri, 9 May 2003 08:05:09 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD7AF@tayexc13.americas.cpqcorp.net> Thread-Topic: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Thread-Index: AcMWCwWH6b9ZZDWYTD2I9HnfU4UcNwAGB5MA From: "Bound, Jim" To: "Iljitsch van Beijnum" , "Tony Li" Cc: X-OriginalArrivalTime: 09 May 2003 12:05:10.0215 (UTC) FILETIME=[3D272D70:01C31623] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA13290 By storing the end nodes in a routing header all other location can change enroute. This is completely stateless. /jim > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Friday, May 09, 2003 4:49 AM > To: Tony Li > Cc: multi6@ops.ietf.org > Subject: Re: GSE IDs [Re: IETF multihoming powder: just add > IPv6 and stir] > > > On vrijdag, mei 9, 2003, at 01:08 Europe/Amsterdam, Tony Li wrote: > > > I would prefer that we avoided having a stateful mapping mechanism. > > It all flows from having more than one address with different > reachability properties. At some point, someone has to decide which > address to use for a particular purpose, and it had better be the > "right" address most of the time or we're worse off than being > single-homed. > > > It's unnecessary and certainly more complication than we need. > > It doesn't have to be complicated: something as simple as publishing > all the addresses in the DNS and/or in an option in the first packet > along with a simple algorithm that figures out which address seems to > be working best is all we need. (But it may not be all we want.) > > What kind of stateless mechanism do you have in mind? Obviously a > stateless solution would be preferable over a stateful one. > > > I would also prefer that we not proclaim something to be GSE that > > isn't, regardless of congruence or continuation of ideas. > > I did use the term "GSE" a bit loosely a week or so ago but rest > assured that this won't happen in the final version of the draft. > > > From owner-multi6@ops.ietf.org Fri May 9 08:40:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14145 for ; Fri, 9 May 2003 08:40:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19E7C5-000GZv-00 for multi6-data@psg.com; Fri, 09 May 2003 12:41:45 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19E7C2-000GZj-00 for multi6@ops.ietf.org; Fri, 09 May 2003 12:41:42 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h49CeNn20061; Fri, 9 May 2003 14:40:24 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 9 May 2003 14:40:24 +0200 Subject: Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: "Bound, Jim" From: Iljitsch van Beijnum In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD7AF@tayexc13.americas.cpqcorp.net> Message-Id: <675A48BD-821B-11D7-AF00-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On vrijdag, mei 9, 2003, at 14:05 Europe/Amsterdam, Bound, Jim wrote: > By storing the end nodes in a routing header all other location can > change enroute. > This is completely stateless. Not really. Someone must know to put in the routing header at some point. And this doesn't provide the functionality we need. Assume ISP A can reach destination X but ISP B can't. In this case, the source must transmit the packet over A. Transmitting it over B isn't going to yield useful results, regardless of the presence of routing headers. Also, we can't assume that users will universally prefer a stateless solution with per-packet overhead over a stateful one that doesn't have extra overhead. I think state in the endpoints is perfectly acceptable. If people want central control over their multihoming and/or they want to multihome-enable unmodified hosts by implementing the multihoming functionality in a middlebox, having state in this middlebox would also be acceptable, especially if it's "soft state" that can be recreated without breaking sessions if the middlebox fails. NAT shows that it is possible to build middleboxes that keep lots of state. From owner-multi6@ops.ietf.org Fri May 9 09:06:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14569 for ; Fri, 9 May 2003 09:06:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19E7by-000L5q-00 for multi6-data@psg.com; Fri, 09 May 2003 13:08:30 +0000 Received: from mail-gw1.hursley.ibm.com ([194.196.110.15]) by psg.com with esmtp (Exim 3.36 #1) id 19E7bw-000L5e-00 for multi6@ops.ietf.org; Fri, 09 May 2003 13:08:28 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19E7bv-0005nd-00; Fri, 09 May 2003 14:08:27 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19E7bu-0005nW-00; Fri, 09 May 2003 14:08:26 +0100 Received: from hursley.ibm.com (dhcp21-189.zurich.ibm.com [9.4.21.189]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA161742; Fri, 9 May 2003 14:08:24 +0100 Message-ID: <3EBBA867.6FBB3AFC@hursley.ibm.com> Date: Fri, 09 May 2003 15:08:55 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Iljitsch van Beijnum CC: "Bound, Jim" , multi6@ops.ietf.org Subject: Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] References: <675A48BD-821B-11D7-AF00-00039388672E@muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-19.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > ... NAT shows that it is > possible to build middleboxes that keep lots of state. and the failure modes associated with NATs show why this is a really bad idea. But even NATs keep that state reasonably local; it doesn't have to be known by magic to an anti-NAT at the other end. Iljitsch, the big hole in your -00 draft is that is doesn't at all discuss the magic needed to distribute mapping state and keep it fresh. As I think I already said, this is why we never pursued the map-and-encap proposal some years ago- it's not a side issue, it's *the* issue in this class of solutions, and it is the fundamental difference from 8+8/GSE. I believe MHAP does discuss this question. And as Jim said, there are stateless solutions, but that means adding bits to the packet. Brian From owner-multi6@ops.ietf.org Fri May 9 09:33:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15335 for ; Fri, 9 May 2003 09:33:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19E82Z-000Pdz-00 for multi6-data@psg.com; Fri, 09 May 2003 13:35:59 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19E82X-000Pdl-00 for multi6@ops.ietf.org; Fri, 09 May 2003 13:35:57 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h49DYOn20143; Fri, 9 May 2003 15:34:25 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 9 May 2003 15:34:24 +0200 Subject: Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Bound, Jim" , multi6@ops.ietf.org To: Brian E Carpenter From: Iljitsch van Beijnum In-Reply-To: <3EBBA867.6FBB3AFC@hursley.ibm.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On vrijdag, mei 9, 2003, at 15:08 Europe/Amsterdam, Brian E Carpenter wrote: > Iljitsch, the big hole in your -00 draft is that is doesn't > at all discuss the magic needed to distribute mapping state > and keep it fresh. Ok, we'll revisit this as soon as I have this part in the draft or when it's finished. In the mean time... > And as Jim said, there are stateless solutions, but that means adding > bits to the packet. And as I replied to Jim, I don't feel what he mentioned is truly stateless. Sure, it avoids state in the core of the network and at the receiver. Nobody was suggesting we should have state in the core, so the problem must be with mapping back at the receiving end. I don't see how this can be considered problematic as doing this for the destination address is entirely trivial (just replace PA prefix A or B with PI prefix X) and for the source address it may either be unnecessary if we transmit the source address unmodified or the state necessary for this must be present in order to be able to send packets back anyway. Similar state must be present in order to add the routing header that Jim mentioned. From owner-multi6@ops.ietf.org Fri May 9 09:33:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15364 for ; Fri, 9 May 2003 09:33:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19E82R-000Pdg-00 for multi6-data@psg.com; Fri, 09 May 2003 13:35:51 +0000 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by psg.com with esmtp (Exim 3.36 #1) id 19E82O-000PdT-00 for multi6@ops.ietf.org; Fri, 09 May 2003 13:35:48 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 5575FA811; Fri, 9 May 2003 09:35:47 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Fri, 9 May 2003 09:35:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Date: Fri, 9 May 2003 09:35:46 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241225@tayexc13.americas.cpqcorp.net> Thread-Topic: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Thread-Index: AcMWKF2k4KaAPV9bQl+7fOzpdPNrJAABUwVQ From: "Bound, Jim" To: "Iljitsch van Beijnum" Cc: X-OriginalArrivalTime: 09 May 2003 13:35:47.0132 (UTC) FILETIME=[E5CEDFC0:01C3162F] X-Spam-Status: No, hits=-10.4 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA15364 > On vrijdag, mei 9, 2003, at 14:05 Europe/Amsterdam, Bound, Jim wrote: > > > By storing the end nodes in a routing header all other location can > > change enroute. This is completely stateless. > > Not really. Someone must know to put in the routing header at some > point. We build a dst option that informs the router the host did this so the routers don't have to mess with it. Or just but it in as dst option. Or as new ext header. I don't care how. > > And this doesn't provide the functionality we need. Assume ISP A can > reach destination X but ISP B can't. In this case, the source must > transmit the packet over A. Transmitting it over B isn't > going to yield > useful results, regardless of the presence of routing headers. This is not what I am addressing and orthogonal However we get the packet to the dst whether thru A or B the return address of the node is required. I want to avoid stateful looks in the path back to the orginal, by last hop router to the dst, or by the receiving node as one option for multi6. Or it can be kept in FINAL DST option within IPv6 too. That way only the receiving end node would ever see it and routers would not care. > > Also, we can't assume that users will universally prefer a stateless > solution with per-packet overhead over a stateful one that > doesn't have > extra overhead. I can as one solution and that is my proposal for a stateless solution as enhancement and use of the extensibility of IPv6. > > I think state in the endpoints is perfectly acceptable. If > people want > central control over their multihoming and/or they want to > multihome-enable unmodified hosts by implementing the multihoming > functionality in a middlebox, having state in this middlebox > would also > be acceptable, especially if it's "soft state" that can be recreated > without breaking sessions if the middlebox fails. NAT shows > that it is > possible to build middleboxes that keep lots of state. NAT is an abortion to networking that is not worthy of any response from me it is almost as bad as the invention of bridges. But if folks want state in the middleboxes that is fine I am proposing another fix using the network computer science use of overloading, extensibility of the datum being carried, and principles of cohesion (close proximity) for indirection back to the end node. It also causes no processing by ASICs in routers or processing. It is used by the receiving end node to respond to the destination. It is similar in property and architecture as the Home Address Option in Mobile IPv6, but not exactly. I believe it has less overhead too. This way we can define the semantics of the 128bits architecturally to support loc+ID and how to route packets across a inter-network of topology and not have to worry about what the loc+id was for the original node it becomes a non-issue. Security for this is now well understood to apply what is required here from MIPv6, HIP, AAA, and DNSSEC principles in those cases. But has to be clearly worked out. If you don't like it that is fine but I would like to hear from others on this list and the WG if that is ok with you? I assume the answer is yes or you and I can go offline and discuss IETF process? /jim > > From owner-multi6@ops.ietf.org Fri May 9 09:34:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15394 for ; Fri, 9 May 2003 09:34:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19E83U-000Pol-00 for multi6-data@psg.com; Fri, 09 May 2003 13:36:56 +0000 Received: from pa-monroeville1d-140.pit.adelphia.net ([24.50.190.140] helo=localhost) by psg.com with esmtp (Exim 3.36 #1) id 19E83S-000PoY-00 for multi6@ops.ietf.org; Fri, 09 May 2003 13:36:54 +0000 Received: from [192.168.1.100] (localhost [127.0.0.1]) by localhost (8.12.9/8.12.2) with ESMTP id h49Das9L000702 for ; Fri, 9 May 2003 09:36:55 -0400 (EDT) Date: Fri, 09 May 2003 09:36:53 -0400 From: "Michael H. Lambert" To: multi6@ops.ietf.org Subject: Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Message-ID: <674339.1052473013@[192.168.1.100]> In-Reply-To: <3EBBA867.6FBB3AFC@hursley.ibm.com> References: <675A48BD-821B-11D7-AF00-00039388672E@muada.com> <3EBBA867.6FBB3AFC@hursley.ibm.com> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-24.8 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >--On Friday, 9 May 2003 15:08 +0200 Brian E Carpenter brian@hursley.ibm.com> wrote: > I believe MHAP does discuss this question. And as Jim said, there > are stateless solutions, but that means adding bits to the packet. And which is better (is some meaningful sense)? We don't know. And without implementations and operational experience, we aren't going to know. The crux of the issue is that sites are reluctant to adopt IPv6 because the "multihoming problem" has not been solved, but we can't solve the problem without that operational experience. Michael From owner-multi6@ops.ietf.org Fri May 9 09:41:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15596 for ; Fri, 9 May 2003 09:41:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19E8AB-00017X-00 for multi6-data@psg.com; Fri, 09 May 2003 13:43:51 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19E8A9-00017I-00 for multi6@ops.ietf.org; Fri, 09 May 2003 13:43:49 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h49DgTn20190; Fri, 9 May 2003 15:42:29 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 9 May 2003 15:42:29 +0200 Subject: Re: Mutli6 meeting in Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Kurt Erik Lindqvist , multi6@ops.ietf.org To: Brian E Carpenter From: Iljitsch van Beijnum In-Reply-To: <3EBB6AA9.5524DAA6@hursley.ibm.com> Message-Id: <139EA57F-8224-11D7-AF00-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On vrijdag, mei 9, 2003, at 10:45 Europe/Amsterdam, Brian E Carpenter wrote: > I think what would be excellent would be for someone to open the > meeting > with an overview of the classes of solutions. We may need to launch > parallel > efforts, so agreeing which classes of solution we want to develop is > an important first step. It seems we're still not at the stage where there is agreement on whether any given type of solution is viable or not. Waiting for Vienna and then discuss all the details in a meeting is not the most efficient use of time. I suggest that everyone submits solution classes to be presented and we then identify the central issue with that class beforehand so we don't have to be sidetracked by either minor details or fairly obvious fatal flaws in the meeting. This should allows us to focus on what's important. Iljitsch From owner-multi6@ops.ietf.org Fri May 9 09:44:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15686 for ; Fri, 9 May 2003 09:44:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19E8Dq-0001xa-00 for multi6-data@psg.com; Fri, 09 May 2003 13:47:38 +0000 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by psg.com with esmtp (Exim 3.36 #1) id 19E8DO-0001s1-00 for multi6@ops.ietf.org; Fri, 09 May 2003 13:47:10 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 7C71E736E; Fri, 9 May 2003 09:47:09 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Fri, 9 May 2003 09:47:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Date: Fri, 9 May 2003 09:47:08 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241226@tayexc13.americas.cpqcorp.net> Thread-Topic: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Thread-Index: AcMWLBpnD0a/4jbUT4GcycITi7oqCgABMt5g From: "Bound, Jim" To: "Brian E Carpenter" , "Iljitsch van Beijnum" Cc: X-OriginalArrivalTime: 09 May 2003 13:47:09.0340 (UTC) FILETIME=[7C6F8DC0:01C31631] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA15686 I went to an industry session yesterday in New England that discussed blades, switches, 10gbE and beyond. The IPv6 PMTU is large and capable. I believe adding 128bits at original node idea to a DST, EXT option will not kill the Internet or fast path for any ASICs I am looking at now (not for routing but host IP / IPsec offload engines for prototype and research on day job). Just as note. Also routing header is not a good idea that was just off the top of the head. EXT or DST option would the way to go and be transparent to routers which is one of my goals. /jim > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Friday, May 09, 2003 9:09 AM > To: Iljitsch van Beijnum > Cc: Bound, Jim; multi6@ops.ietf.org > Subject: Re: GSE IDs [Re: IETF multihoming powder: just add > IPv6 and stir] > > > Iljitsch van Beijnum wrote: > > ... NAT shows that it is > > possible to build middleboxes that keep lots of state. > > and the failure modes associated with NATs show why > this is a really bad idea. But even NATs keep that state > reasonably local; it doesn't have to be known by magic to an > anti-NAT at the other end. > > Iljitsch, the big hole in your -00 draft is that is doesn't > at all discuss the magic needed to distribute mapping state > and keep it fresh. As I think I already said, this is why we > never pursued the map-and-encap proposal some years ago- it's > not a side issue, it's *the* issue in this class of > solutions, and it is the fundamental difference from 8+8/GSE. > > I believe MHAP does discuss this question. And as Jim said, > there are stateless solutions, but that means adding bits to > the packet. > > Brian > From owner-multi6@ops.ietf.org Fri May 9 10:07:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16673 for ; Fri, 9 May 2003 10:07:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19E8Z6-0006A9-00 for multi6-data@psg.com; Fri, 09 May 2003 14:09:36 +0000 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 19E8Z3-00069w-00 for multi6@ops.ietf.org; Fri, 09 May 2003 14:09:33 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 13E39A9FB; Fri, 9 May 2003 10:09:31 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Fri, 9 May 2003 10:09:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Date: Fri, 9 May 2003 10:09:30 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD7C4@tayexc13.americas.cpqcorp.net> Thread-Topic: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Thread-Index: AcMWLBpnD0a/4jbUT4GcycITi7oqCgABMt5gAADJ3dA= From: "Bound, Jim" To: "Brian E Carpenter" , "Iljitsch van Beijnum" Cc: X-OriginalArrivalTime: 09 May 2003 14:09:30.0940 (UTC) FILETIME=[9C1777C0:01C31634] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA16673 ALso this is just one infitesimal piece to multi6 to solve "keeping the orginal node IP delivery address on the LAN" (using old standard terms on purpose). Possibly what we have to do for multi6 is break the problem area into multiple pieces that need resolution instead of trying to solve it as huge glob all at once and part of what has been holding us up. For example why not agree on what loc is equivalent to and how many bits and ID for semantics? Then go to next step. If it breaks we reevaluate. That way bright people here can be working on specific tasks. In fact different bright people can go off and work on different aspects. Then each with solution can look at those parts for their favorite solution HIP, MHAP, MIPv6-LIKE. /jim > -----Original Message----- > From: Bound, Jim > Sent: Friday, May 09, 2003 9:47 AM > To: Brian E Carpenter; Iljitsch van Beijnum > Cc: multi6@ops.ietf.org > Subject: RE: GSE IDs [Re: IETF multihoming powder: just add > IPv6 and stir] > > > I went to an industry session yesterday in New England that > discussed blades, switches, 10gbE and beyond. The IPv6 PMTU > is large and capable. I believe adding 128bits at original > node idea to a DST, EXT option will not kill the Internet or > fast path for any ASICs I am looking at now (not for routing > but host IP / IPsec offload engines for prototype and > research on day job). Just as note. Also routing header is > not a good idea that was just off the top of the head. EXT > or DST option would the way to go and be transparent to > routers which is one of my goals. > > /jim > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: Friday, May 09, 2003 9:09 AM > > To: Iljitsch van Beijnum > > Cc: Bound, Jim; multi6@ops.ietf.org > > Subject: Re: GSE IDs [Re: IETF multihoming powder: just add > > IPv6 and stir] > > > > > > Iljitsch van Beijnum wrote: > > > ... NAT shows that it is > > > possible to build middleboxes that keep lots of state. > > > > and the failure modes associated with NATs show why > > this is a really bad idea. But even NATs keep that state > > reasonably local; it doesn't have to be known by magic to an > > anti-NAT at the other end. > > > > Iljitsch, the big hole in your -00 draft is that is doesn't at all > > discuss the magic needed to distribute mapping state and keep it > > fresh. As I think I already said, this is why we never pursued the > > map-and-encap proposal some years ago- it's not a side issue, it's > > *the* issue in this class of solutions, and it is the fundamental > > difference from 8+8/GSE. > > > > I believe MHAP does discuss this question. And as Jim said, > > there are stateless solutions, but that means adding bits to > > the packet. > > > > Brian > > > > From owner-multi6@ops.ietf.org Fri May 9 10:24:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17795 for ; Fri, 9 May 2003 10:24:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19E8pV-0009Dh-00 for multi6-data@psg.com; Fri, 09 May 2003 14:26:33 +0000 Received: from mailout.zma.compaq.com ([161.114.64.104] helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 19E8pR-0009DU-00 for multi6@ops.ietf.org; Fri, 09 May 2003 14:26:30 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 58DECA105; Fri, 9 May 2003 10:26:29 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Fri, 9 May 2003 10:26:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Date: Fri, 9 May 2003 10:26:28 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD7C7@tayexc13.americas.cpqcorp.net> Thread-Topic: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Thread-Index: AcMWLBpnD0a/4jbUT4GcycITi7oqCgABMt5gAADJ3dAAALTGoA== From: "Bound, Jim" To: "Brian E Carpenter" , "Iljitsch van Beijnum" Cc: X-OriginalArrivalTime: 09 May 2003 14:26:29.0148 (UTC) FILETIME=[FAFDADC0:01C31636] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA17795 I think this is formally called a spriral engineering process using the E letter in IETF :-) /jim > -----Original Message----- > From: Bound, Jim > Sent: Friday, May 09, 2003 10:10 AM > To: Brian E Carpenter; Iljitsch van Beijnum > Cc: multi6@ops.ietf.org > Subject: RE: GSE IDs [Re: IETF multihoming powder: just add > IPv6 and stir] > > > ALso this is just one infitesimal piece to multi6 to solve > "keeping the orginal node IP delivery address on the LAN" > (using old standard terms on purpose). Possibly what we have > to do for multi6 is break the problem area into multiple > pieces that need resolution instead of trying to solve it as > huge glob all at once and part of what has been holding us up. > > For example why not agree on what loc is equivalent to and > how many bits and ID for semantics? Then go to next step. > If it breaks we reevaluate. > > That way bright people here can be working on specific tasks. > In fact different bright people can go off and work on > different aspects. > > Then each with solution can look at those parts for their > favorite solution HIP, MHAP, MIPv6-LIKE. > > /jim > > > -----Original Message----- > > From: Bound, Jim > > Sent: Friday, May 09, 2003 9:47 AM > > To: Brian E Carpenter; Iljitsch van Beijnum > > Cc: multi6@ops.ietf.org > > Subject: RE: GSE IDs [Re: IETF multihoming powder: just add > > IPv6 and stir] > > > > > > I went to an industry session yesterday in New England that > > discussed blades, switches, 10gbE and beyond. The IPv6 PMTU > > is large and capable. I believe adding 128bits at original > > node idea to a DST, EXT option will not kill the Internet or > > fast path for any ASICs I am looking at now (not for routing > > but host IP / IPsec offload engines for prototype and > > research on day job). Just as note. Also routing header is > > not a good idea that was just off the top of the head. EXT > > or DST option would the way to go and be transparent to > > routers which is one of my goals. > > > > /jim > > > > > -----Original Message----- > > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > > Sent: Friday, May 09, 2003 9:09 AM > > > To: Iljitsch van Beijnum > > > Cc: Bound, Jim; multi6@ops.ietf.org > > > Subject: Re: GSE IDs [Re: IETF multihoming powder: just add > > > IPv6 and stir] > > > > > > > > > Iljitsch van Beijnum wrote: > > > > ... NAT shows that it is > > > > possible to build middleboxes that keep lots of state. > > > > > > and the failure modes associated with NATs show why > > > this is a really bad idea. But even NATs keep that state > reasonably > > > local; it doesn't have to be known by magic to an anti-NAT at the > > > other end. > > > > > > Iljitsch, the big hole in your -00 draft is that is doesn't at all > > > discuss the magic needed to distribute mapping state and keep it > > > fresh. As I think I already said, this is why we never > pursued the > > > map-and-encap proposal some years ago- it's not a side > issue, it's > > > *the* issue in this class of solutions, and it is the fundamental > > > difference from 8+8/GSE. > > > > > > I believe MHAP does discuss this question. And as Jim said, there > > > are stateless solutions, but that means adding bits to the packet. > > > > > > Brian > > > > > > > > > From owner-multi6@ops.ietf.org Fri May 9 12:15:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21682 for ; Fri, 9 May 2003 12:15:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19EAYb-00041T-00 for multi6-data@psg.com; Fri, 09 May 2003 16:17:13 +0000 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 19EAYZ-00041G-00 for multi6@ops.ietf.org; Fri, 09 May 2003 16:17:11 +0000 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h49GH9tU005834; Fri, 9 May 2003 12:17:09 -0400 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id h49GH9Mm005833; Fri, 9 May 2003 12:17:09 -0400 Date: Fri, 9 May 2003 12:17:09 -0400 From: "J. Noel Chiappa" Message-Id: <200305091617.h49GH9Mm005833@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: RE: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_20 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: "Bound, Jim" > NAT is an abortion to networking that is not worthy of any response > from me it is almost as bad as the invention of bridges. Funny you should put it that way - I've always thought that my inability to see how useful bridges would be (within a certain limied context), and my opposition to doing one, was the single biggest technical mistake I made during my association with Proteon, and one of the biggest causes of their loss to Cisco. But this is all irrelevant to Multi6, so I'll stop there, and instead comment on something relevant (next message). Noel From owner-multi6@ops.ietf.org Fri May 9 12:38:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22372 for ; Fri, 9 May 2003 12:38:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19EAve-0008hw-00 for multi6-data@psg.com; Fri, 09 May 2003 16:41:02 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19EAva-0008he-00 for multi6@ops.ietf.org; Fri, 09 May 2003 16:40:58 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h49Gek606250; Fri, 9 May 2003 19:40:46 +0300 Date: Fri, 9 May 2003 19:40:46 +0300 (EEST) From: Pekka Savola To: Joe Abley cc: Kurt Erik Lindqvist , Subject: Re: comments on requirements-05 In-Reply-To: <0B98096B-809B-11D7-BEC9-00039312C852@isc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-32.1 required=5.0 tests=BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Sorry for a slight delay in answering. On Wed, 7 May 2003, Joe Abley wrote: > On Wednesday, May 7, 2003, at 04:12 Canada/Eastern, Pekka Savola wrote: > > > On Tue, 6 May 2003, Joe Abley wrote: > > > >>> ==> should be reworded to remove references to "transit provider is a > >>> site" -concept, which is irrelevant and confusing in this context. > >> > >> Please explain. > > > > Typically "site" is considered to be an "end-site", in the transit > > provider's case, the NOC of the transit provider. The backbone of the > > transit provider, possibly spanning contininents, seems to stretch the > > definition and the mental picture of a "site" pretty far. > > I think in practice "typically" is in the eye of the beholder, which is > why I was careful to define what I meant by site. > > > Also, the text may be rather ambiguous as it doesn't seem to match the > > common understanding of what "transit provider" typically is. > > Again, this came up when the draft was originally published with > definitions. There is no common understanding of what "transit > provider" is; different people add different nuances to their > understanding of the phrase, which is why the definitions are there. > > I think the current set of definitions are sufficient to cover the > concepts used in the draft, and I think they're about as commonly > accepted amongst operators as we're likely to find. I suggest replacing the definitions: A "transit provider" operates a site which directly provides connectivity to the Internet to one or more external sites. The connectivity provided extends beyond the transit provider's own site. A transit provider's site is directly connected to the sites for which it provides transit. A "multihomed" site is one with more than one transit provider. "Site-multihoming" is the practice of arranging a site to be multihomed. The term "re-homing" denotes a transition of a site between two states of connectedness, due to a change in the connectivity between the site and its transit providers' sites. with: A "direct Internet services provider" (ISP) provides a physical connection and Internet connectivity to the site. The connectivity extends beyond the ISP's own network. A "multihomed" site is one with more than one ISP. "Site-multihoming" is the practice of arranging a site to be multihomed. The term "re-homing" denotes a transition of a site between two states of connectedness, due to a change in the connectivity between the site and its ISPs. (of course, this would require changes where the terms are being used.) note: I believe the term "physical connection" is generic enough to include a wireless connection, but I'm not a native speaker, so.. note 2: one could also use NSP, not ISP. An alternative would be to define a "direct transit provider" and use that instead of "transit provider", but I'm not sure whether that's any better. > >>> 2) simplicity for the internet and/or the site should be made > >>> explicit. > >>> > >>> 3.1.5 Simplicity > >>> > >>> As any proposed multihoming solution must be deployed in real > >>> networks with real customers, simplicity is paramount. The current > >>> multihoming solution is quite straightforward to deploy and > >>> maintain. > >>> A new IPv6 multihoming proposal should not be substantially more > >>> complex to deploy and operate than current IPv4 multihoming > >>> practices. > >>> > >>> ==> there are two aspects to the simplicity, with two different axes: > >>> - simplicity to those who deploy it, and to those that don't > >>> - simplicity to the Big Internet as a whole and the end-site itself > >> > >> I don't see those as orthogonal; your second line looks to me like a > >> rewording of the first line (taking the Big Internet to be a > >> collection > >> of people who do and don't deploy multihoming). Perhaps you could > >> explain that further. > > > > There is a slight difference there, in my eyes. > > > > The first item separates "multihomed site and its ISP(s) and possibly > > their transits" and "everyone else". > > > > The second item separates "multihoming end-site" and "everyone else > > (including their ISPs)". > > All of "its ISPs" and "their transits" and a good chunk of "everybody > else" are potentially multi-homed sites; multi-homing doesn't only > happen at "end-sites" (assuming I'm understanding your terminology > correctly). But note that these do not necessarily use the same set of solutions. Some might choose a simpler mechanism for the network, while others want simplicity for the end-site. Those transits or folks in the Internet which value the simplicity for the network (and are willing to "pay" for it by requiring different solutions for their customers) should be considered. On the other hand, for business reasons, a direct upstream may be practically forced to accept bad practices. Therefore, interest in the overall health is more important. > >>> 3.2.6 Cooperation between Transit Providers > >>> > >>> A multihoming strategy may require cooperation between a site and > >>> its > >>> transit providers, but should not require cooperation (relating > >>> specifically to the multihomed site) directly between the transit > >>> providers. > > [...] > > > Let's try to illustrate: > > > > Site S > > / \ > > ISP A -- ISP B > > | | > > Transit1 - Transit2 -- [ Internet ] > > | \ > > [Internet] [Internet] > > > > Co-operation is currently a goal with Site S <-> ISP A and Site S <-> > > ISP > > B. It is not with ISP A <-> ISP B. > > > > This doesn't take a stance on even more non-goal co-operation, with > > e.g. > > - Site S <-> Transit1 > > - ISP A <-> Transit1 > > Ah, ok, I see what you mean. > > I'm not sure it's reasonable to take a stance on that. If site S wants > to come to an arrangement with Transit1 to handle its traffic or > routing in a certain way, why shouldn't it? With v4 CIDR abuse, for > example, why shouldn't I be able to call up Sprint and say "hey, let me > pay you money to relax your assignment-boundary filters in my > particular case, so you'll accept my long-prefix route"? > > This in general does not sound like a recipe for simple, pervasive > multi-homing but I'm not sure why the goals document should state it as > a non-goal. There is nothing to prevent that, if the solution supports it, but IMO it's better if the solution does not require co-operation with further upstream transit providers. Also note that there was another case: Site S interacting with the Internet (ie. with folks it is not directly or indirectly paying money to). Co-operation must not be required there, I think. > >>> semi-editorial/substantial > >>> -------------------------- > >>> For purposes of > >>> redundancy and load-sharing, the multihomed address blocks, which > >>> are > >>> almost always a longer prefix than the provider aggregate, are > >>> announced along with the larger, covering aggregate originated by > >>> the > >>> provider. > >>> > >>> ==> s/redundancy/redundancy, independence/ > >> > >> No, I don't think there's any "independence" rationale there; these > >> are > >> covered prefixes describing PA assignments, not announcements of PI > >> space. > > > > There certainly is, if you can, and in practice do, take the portion of > > the PA with you, to another provider. The text in the introduction > > does > > not require the site to advertise the more specific from the behind the > > direct ISP: as long as a covering aggregate (from somewhere else) > > exists, > > you're fine. > > I mean, there's no independence in the sense that you are still > dependent on the provider who allocated you the numbers. You can't stop > paying that guy and continue to announce your long-prefix route to > other transit providers. Can't stop paying? Why can't? You just keep advertising the route, more specifics if you need to, and there's no one stopping you. Of course, I guess there is typically some smallish, nominal fee for not allocating the address space again to some poor sucker. > "Independence", when mentioned in the context of v4 multihoming, is > invariably to do with PI addressing I have noticed. Hence I think > introducing that word here would add confusion rather than clarity. Yes, I agree independence is typically a factor in PI-based BGP use, but that is also used for site multihoming -- which should be in scope too. With the current state of *being typically able* to punch a hole in the aggregate and steal the address space (perhaps by paying some small sum to the original party), you end up with rather a close approximation of independence ("PA address becomes de-facto PI"). > > But why do you then say: > > > > the multihomed address blocks, which are > > almost always a longer prefix than the provider aggregate, > > > > ==> there is no "coverage" if it is not a longer prefix. > > ok, how about "which are almost always covered by a provider > aggregate,". That covers it, but I'm confused why you like to fade away the PI-address case -- which seems rather typical for biggest sites, at least. > > In any case, the introduction is incomplete. Multihoming is also done > > with PI addresses, without covering aggregates. > > OK. That's a fair point. > > > The introduction should be either modified to be a bit more descriptive > > (or generic), or make a reference to the v4 multihoming draft (which > > would > > require us to start working on it again) -- which should be there > > anyway, > > at least as an informational ref. > > > >>> This contributes to the rapidly-increasing size of the > >>> global routing table. > >>> > >>> ==> s/size/size and dynamicity/ (better word than dynamicity?!?!) > >> > >> complexity? > > > > Complexity is too generic a term unfortunately, it doesn't imply > > anything > > about the advertise/withdraw cycles caused by site multihoming. > > turbulence? Sounds rather good, gives the right impression. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Fri May 9 13:04:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23341 for ; Fri, 9 May 2003 13:04:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19EBKn-000Dqq-00 for multi6-data@psg.com; Fri, 09 May 2003 17:07:01 +0000 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.36 #1) id 19EBKj-000Dqa-00 for multi6@ops.ietf.org; Fri, 09 May 2003 17:06:57 +0000 Received: (qmail 84220 invoked by uid 0); 9 May 2003 17:06:56 -0000 Received: from localhost.automagic.org (HELO isc.org) (root@127.0.0.1) by localhost.automagic.org with SMTP; 9 May 2003 17:06:56 -0000 Date: Fri, 9 May 2003 13:06:59 -0400 Subject: Re: comments on requirements-05 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Kurt Erik Lindqvist , To: Pekka Savola From: Joe Abley In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, May 9, 2003, at 12:40 Canada/Eastern, Pekka Savola wrote: > I suggest replacing the definitions: > > A "transit provider" operates a site which directly provides > connectivity to the Internet to one or more external sites. The > connectivity provided extends beyond the transit provider's own > site. > A transit provider's site is directly connected to the sites for > which it provides transit. [...] > with: > > A "direct Internet services provider" (ISP) provides a physical > connection > and Internet connectivity to the site. The connectivity extends > beyond > the ISP's own network. I don't see the reason for introducing a new term ("direct Internet services provider") which I have never heard used before in preference to one which I hear commonly used, in the exact sense in which it is defined in -05. Does anybody else have an opinion about this? >>>>> 2) simplicity for the internet and/or the site should be made >>>>> explicit. >>>>> >>>>> 3.1.5 Simplicity I'm going to think some more about your comments here, and see if I can distill something pithy to cover it. >>>>> 3.2.6 Cooperation between Transit Providers >>>>> >>>>> A multihoming strategy may require cooperation between a site >>>>> and >>>>> its >>>>> transit providers, but should not require cooperation (relating >>>>> specifically to the multihomed site) directly between the >>>>> transit >>>>> providers. >> >> [...] >> >>> Let's try to illustrate: >>> >>> Site S >>> / \ >>> ISP A -- ISP B >>> | | >>> Transit1 - Transit2 -- [ Internet ] >>> | \ >>> [Internet] [Internet] >>> >>> Co-operation is currently a goal with Site S <-> ISP A and Site S <-> >>> ISP >>> B. It is not with ISP A <-> ISP B. >>> >>> This doesn't take a stance on even more non-goal co-operation, with >>> e.g. >>> - Site S <-> Transit1 >>> - ISP A <-> Transit1 [...] > There is nothing to prevent that, if the solution supports it, but IMO > it's better if the solution does not require co-operation with further > upstream transit providers. > > Also note that there was another case: Site S interacting with the > Internet (ie. with folks it is not directly or indirectly paying money > to). Co-operation must not be required there, I think. Since these are goals, and not requirements, I'm not sure it's necessary or desirable (from the point of view of getting a message across) to enumerate every single possible case and permit, require or prohibit each in turn. Maybe we could insert a comment like "The impact of any inter-provider cooperation that might be required to facilitate the multi-homing strategy should be examined and assessed from the point of view of operational practicality." >> I mean, there's no independence in the sense that you are still >> dependent on the provider who allocated you the numbers. You can't >> stop >> paying that guy and continue to announce your long-prefix route to >> other transit providers. > > Can't stop paying? Why can't? You just keep advertising the route, > more > specifics if you need to, and there's no one stopping you. Similarly, there's nothing to stop you choosing any unadvertised space and using it as your own, but it does tend to make people upset and it's not something I would base a business on. I will make some provisional edits to -05 and float them on the list today. Joe From owner-multi6@ops.ietf.org Fri May 9 13:11:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23575 for ; Fri, 9 May 2003 13:11:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19EBRH-000FTc-00 for multi6-data@psg.com; Fri, 09 May 2003 17:13:43 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19EBRE-000FTM-00 for multi6@ops.ietf.org; Fri, 09 May 2003 17:13:40 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h49HB1n20612; Fri, 9 May 2003 19:11:01 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 9 May 2003 19:11:02 +0200 Subject: Re: comments on requirements-05 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Joe Abley , Kurt Erik Lindqvist , To: Pekka Savola From: Iljitsch van Beijnum In-Reply-To: Message-Id: <35EFBBBC-8241-11D7-AF00-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On vrijdag, mei 9, 2003, at 18:40 Europe/Amsterdam, Pekka Savola wrote: >>> Also, the text may be rather ambiguous as it doesn't seem to match >>> the >>> common understanding of what "transit provider" typically is. >> Again, this came up when the draft was originally published with >> definitions. There is no common understanding of what "transit >> provider" is; different people add different nuances to their >> understanding of the phrase, which is why the definitions are there. Really? Can you list some examples of conflicting use of the term "transit"? It seems like a reasonably well-defined word to me. > I suggest replacing the definitions: > A "transit provider" operates a site This is completely confusing. It seems we lack a definition for "site", and as a non-native speaker I might be missing something, but the word "site" makes me think along the lines of a building site: a single location. Transit providers tend to operate networks that span more than a single location. If we're going to change wording, let's do away with "site" and replace it with "AS". This one is well-defined and used extensively in discussions about interdomain routing. > which directly provides > connectivity to the Internet to one or more external sites. Or "the rest of the world" for short. I don't think we should consider the plight of those selling or buying partial transit as it leads to endless problems with multi-address solutions. And it doesn't have to be directly. > A transit provider's site is directly connected to the sites for > which it provides transit. Nonsense. > A "direct Internet services provider" (ISP) provides a physical > connection > and Internet connectivity to the site. The connectivity extends > beyond > the ISP's own network. Ok, now define the internet... Logical connections work too. > note: I believe the term "physical connection" is generic enough to > include a wireless connection, but I'm not a native speaker, so.. "connection" is even more generic. > An alternative would be to define a "direct transit provider" and use > that > instead of "transit provider", but I'm not sure whether that's any > better. What's the thing with directness??? >> I mean, there's no independence in the sense that you are still >> dependent on the provider who allocated you the numbers. You can't >> stop >> paying that guy and continue to announce your long-prefix route to >> other transit providers. > Can't stop paying? Why can't? You just keep advertising the route, > more > specifics if you need to, and there's no one stopping you. A quick message to the NOC of the remaining ISPs can do wonders in this regard. Many ISPs only accept more specifics out of other ISP's prefixes if that ISP is ok with it. Some don't accept them at all. From owner-multi6@ops.ietf.org Fri May 9 13:21:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23785 for ; Fri, 9 May 2003 13:21:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19EBaf-000H9o-00 for multi6-data@psg.com; Fri, 09 May 2003 17:23:25 +0000 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.36 #1) id 19EBac-000H6M-00 for multi6@ops.ietf.org; Fri, 09 May 2003 17:23:22 +0000 Received: (qmail 85523 invoked by uid 0); 9 May 2003 17:23:21 -0000 Received: from localhost.automagic.org (HELO isc.org) (root@127.0.0.1) by localhost.automagic.org with SMTP; 9 May 2003 17:23:21 -0000 Date: Fri, 9 May 2003 13:23:25 -0400 Subject: Re: comments on requirements-05 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Pekka Savola , Kurt Erik Lindqvist , To: Iljitsch van Beijnum From: Joe Abley In-Reply-To: <35EFBBBC-8241-11D7-AF00-00039388672E@muada.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, May 9, 2003, at 13:11 Canada/Eastern, Iljitsch van Beijnum wrote: > This is completely confusing. It seems we lack a definition for > "site", and as a non-native speaker I might be missing something, but > the word "site" makes me think along the lines of a building site: a > single location. Transit providers tend to operate networks that span > more than a single location. The document includes a definition for "site": A "site" is an entity autonomously operating a network using IP and, in particular, determining the addressing plan and routing policy for that network. This definition is intended to be equivalent to "enterprise" as defined in [2]. > If we're going to change wording, let's do away with "site" and > replace it with "AS". This one is well-defined and used extensively in > discussions about interdomain routing. The original reason for not using "AS" was that we did not want to presuppose a routing solution to the problem (e.g. to the exclusion of solutions which involve address overloading on the edge). >> which directly provides >> connectivity to the Internet to one or more external sites. > > Or "the rest of the world" for short. I don't think we should consider > the plight of those selling or buying partial transit as it leads to > endless > problems with multi-address solutions. > > And it doesn't have to be directly. > >> A transit provider's site is directly connected to the sites for >> which it provides transit. > > Nonsense. As I seem to be mentioning in every single message on this subject, the reason for the definitions being there at all is that different people have different ideas about what "transit provider" means. At home, I buy transit from an ISP in Ontario called Sentex. They buy transit from Telus. According to some understandings of "transit provider", Sentex is a transit provider of Joe Abley, but Telus is not, since Telus have no direct provider relationship with Joe Abley. According to other definitions, Telus and Sentex are both transit providers of Joe Abley. To clear up this ambiguity, the document was modified to include definitions. To be clear, the purpose of the document is not to define the term "transit provider": the purpose is to describe a set of criteria which might be viewed as useful capabilities for a multihoming strategy. If the set of definitions in the document are (a) not completely off the wall and (b) cover the terms used in the document, then we are finished talking about definitions. >> A "direct Internet services provider" (ISP) provides a physical >> connection >> and Internet connectivity to the site. The connectivity extends >> beyond >> the ISP's own network. > > Ok, now define the internet... It's the "largest equivalence class in the reflexive transitive symmetric closure of the relationship "can be reached by an IP packet from" [Seth Breidbart] > Logical connections work too. Let's not introduce new exciting vague terminology for the sake of it. Joe From owner-multi6@ops.ietf.org Fri May 9 13:46:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24542 for ; Fri, 9 May 2003 13:46:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19EBzP-000MRT-00 for multi6-data@psg.com; Fri, 09 May 2003 17:48:59 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19EBzL-000MRD-00 for multi6@ops.ietf.org; Fri, 09 May 2003 17:48:56 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h49HmmI06871; Fri, 9 May 2003 20:48:49 +0300 Date: Fri, 9 May 2003 20:48:48 +0300 (EEST) From: Pekka Savola To: Joe Abley cc: Kurt Erik Lindqvist , Subject: Re: comments on requirements-05 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 9 May 2003, Joe Abley wrote: > On Friday, May 9, 2003, at 12:40 Canada/Eastern, Pekka Savola wrote: > > I suggest replacing the definitions: > > > > A "transit provider" operates a site which directly provides > > connectivity to the Internet to one or more external sites. The > > connectivity provided extends beyond the transit provider's own > > site. > > A transit provider's site is directly connected to the sites for > > which it provides transit. > > [...] > > > with: > > > > A "direct Internet services provider" (ISP) provides a physical > > connection > > and Internet connectivity to the site. The connectivity extends > > beyond > > the ISP's own network. > > I don't see the reason for introducing a new term ("direct Internet > services provider") which I have never heard used before in preference > to one which I hear commonly used, in the exact sense in which it is > defined in -05. Well, "first-hop provider" or "first-hop ISP" could be others. But still, I think it's *better* to define a new term than redefine a commonly used one. That way people do not have prior expectations on what the term refers to, and even though they would not read the terminology with great care, it would still point to the right direction. Even if you my proposition for a new definition is ignored, I think the "transit provider" term should be edited to remove stuff about its site. I think it would be possible to do so, in a similar fashion as with my terms. > > There is nothing to prevent that, if the solution supports it, but IMO > > it's better if the solution does not require co-operation with further > > upstream transit providers. > > > > Also note that there was another case: Site S interacting with the > > Internet (ie. with folks it is not directly or indirectly paying money > > to). Co-operation must not be required there, I think. > > Since these are goals, and not requirements, I'm not sure it's > necessary or desirable (from the point of view of getting a message > across) to enumerate every single possible case and permit, require or > prohibit each in turn. > > Maybe we could insert a comment like "The impact of any inter-provider > cooperation that might be required to facilitate the multi-homing > strategy should be examined and assessed from the point of view of > operational practicality." Looks fine (in addition to other clarification on this subject, wrt. "transit provider"). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Fri May 9 13:52:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24655 for ; Fri, 9 May 2003 13:52:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19EC53-000NV9-00 for multi6-data@psg.com; Fri, 09 May 2003 17:54:49 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19EC50-000NUw-00 for multi6@ops.ietf.org; Fri, 09 May 2003 17:54:46 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h49HrRn20686; Fri, 9 May 2003 19:53:27 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 9 May 2003 19:53:28 +0200 Subject: Re: comments on requirements-05 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: Joe Abley From: Iljitsch van Beijnum In-Reply-To: Message-Id: <23C4B1D1-8247-11D7-AF00-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On vrijdag, mei 9, 2003, at 19:23 Europe/Amsterdam, Joe Abley wrote: >> This is completely confusing. It seems we lack a definition for >> "site", and as a non-native speaker I might be missing something, but >> the word "site" makes me think along the lines of a building site: a >> single location. Transit providers tend to operate networks that span >> more than a single location. > The document includes a definition for "site": Ok, I took Thierry Ernst's message as an indication there was no definition; my apologies. > A "site" is an entity autonomously operating a network using IP and, > in particular, determining the addressing plan and routing policy > for > that network. This definition is intended to be equivalent to > "enterprise" as defined in [2]. >> If we're going to change wording, let's do away with "site" and >> replace it with "AS". This one is well-defined and used extensively >> in discussions about interdomain routing. > The original reason for not using "AS" was that we did not want to > presuppose a routing solution to the problem (e.g. to the exclusion of > solutions which involve address overloading on the edge). Ok, we keep "site" then even though the definition seems identical to AS, but I do maintain that "transit site" is confusing and shouldn't be used. >>> A transit provider's site is directly connected to the sites for >>> which it provides transit. >> Nonsense. > As I seem to be mentioning in every single message on this subject, > the reason for the definitions being there at all is that different > people have different ideas about what "transit provider" means. When I was responding everything was pretty much out of context. I took "sites for which it provides transit" to mean "destinations reachable through the transit service" which would indeed be nonsense, but the context makes clear (or at least: clearer) that this means "sites that are customers of the transit provider". Maybe it's a good idea to spell this out in the definition. > At home, I buy transit from an ISP in Ontario called Sentex. They buy > transit from Telus. According to some understandings of "transit > provider", Sentex is a transit provider of Joe Abley, but Telus is > not, since Telus have no direct provider relationship with Joe Abley. > According to other definitions, Telus and Sentex are both transit > providers of Joe Abley. Regardless of your personal circumstances, they are always "a transit provider", which is the term being defined. Things would be different if you were defining "a site's transit provider". > To clear up this ambiguity, the document was modified to include > definitions. To be clear, the purpose of the document is not to define > the term "transit provider": the purpose is to describe a set of > criteria which might be viewed as useful capabilities for a > multihoming strategy. If the set of definitions in the document are > (a) not completely off the wall and (b) cover the terms used in the > document, then we are finished talking about definitions. Nobody is ever finished talking about definitions. :-) >> Ok, now define the internet... > It's the "largest equivalence class in the reflexive transitive > symmetric closure of the relationship "can be reached by an IP packet > from" [Seth Breidbart] That's a good one. >> Logical connections work too. > Let's not introduce new exciting vague terminology for the sake of it. If I am connected to my ISP over ADSL, how is that a "physical" connection with the ADSL whole sale company's ATM network in the middle? If the connection isn't always physical, the word physical shouldn't be used. Iljitsch PS. I really do appreciate you doing a difficult job here. From owner-multi6@ops.ietf.org Fri May 9 14:10:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25401 for ; Fri, 9 May 2003 14:10:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19ECMn-0001Sh-00 for multi6-data@psg.com; Fri, 09 May 2003 18:13:09 +0000 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #1) id 19ECMl-0001RG-00 for multi6@ops.ietf.org; Fri, 09 May 2003 18:13:07 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id A731834468; Fri, 9 May 2003 10:27:26 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h49ID3YB012960; Fri, 9 May 2003 11:13:03 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Date: Fri, 9 May 2003 11:13:03 -0700 Message-ID: Thread-Topic: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Thread-Index: AcMWSE98+2f4geZ8Tvq5sXpnxCnQYwADjdKg From: "Tony Li" To: "J. Noel Chiappa" , X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA25401 In the words of Kirk Lougheed: don't fall in love with your technology. Tony | -----Original Message----- | From: J. Noel Chiappa [mailto:jnc@ginger.lcs.mit.edu] | Sent: Friday, May 09, 2003 9:17 AM | To: multi6@ops.ietf.org | Cc: jnc@ginger.lcs.mit.edu | Subject: RE: GSE IDs [Re: IETF multihoming powder: just | add IPv6 and stir] | | | > From: "Bound, Jim" | | > NAT is an abortion to networking that is not worthy | of any response | > from me it is almost as bad as the invention of bridges. | | Funny you should put it that way - I've always thought | that my inability to | see how useful bridges would be (within a certain limied | context), and my | opposition to doing one, was the single biggest technical | mistake I made | during my association with Proteon, and one of the biggest | causes of their | loss to Cisco. | | But this is all irrelevant to Multi6, so I'll stop there, | and instead comment | on something relevant (next message). | | Noel | | From owner-multi6@ops.ietf.org Sun May 11 04:39:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00145 for ; Sun, 11 May 2003 04:39:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19EmLY-000P2z-00 for multi6-data@psg.com; Sun, 11 May 2003 08:38:16 +0000 Received: from mail-gw1.hursley.ibm.com ([194.196.110.15]) by psg.com with esmtp (Exim 3.36 #1) id 19EmLW-000P2k-00 for multi6@ops.ietf.org; Sun, 11 May 2003 08:38:14 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19EmLS-00044p-00; Sun, 11 May 2003 09:38:10 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19EmLS-00044k-00; Sun, 11 May 2003 09:38:10 +0100 Received: from hursley.ibm.com (gsine06.us.sine.ibm.com [9.14.6.46]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id JAA185228; Sun, 11 May 2003 09:38:05 +0100 Message-ID: <3EBE0B23.4C4FE08F@hursley.ibm.com> Date: Sun, 11 May 2003 10:34:43 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Kurt Erik Lindqvist , multi6@ops.ietf.org Subject: Re: Mutli6 meeting in Vienna References: <139EA57F-8224-11D7-AF00-00039388672E@muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Well, I need to see a single taxonomy, not a bunch of independently drafted half proposals. But I agree that we need to focus on fatal flaws and major advantages, not on details. Brian Iljitsch van Beijnum wrote: > > On vrijdag, mei 9, 2003, at 10:45 Europe/Amsterdam, Brian E Carpenter > wrote: > > > I think what would be excellent would be for someone to open the > > meeting > > with an overview of the classes of solutions. We may need to launch > > parallel > > efforts, so agreeing which classes of solution we want to develop is > > an important first step. > > It seems we're still not at the stage where there is agreement on > whether any given type of solution is viable or not. Waiting for Vienna > and then discuss all the details in a meeting is not the most efficient > use of time. I suggest that everyone submits solution classes to be > presented and we then identify the central issue with that class > beforehand so we don't have to be sidetracked by either minor details > or fairly obvious fatal flaws in the meeting. This should allows us to > focus on what's important. > > Iljitsch From owner-multi6@ops.ietf.org Sun May 11 04:59:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00532 for ; Sun, 11 May 2003 04:59:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Emj3-0001jD-00 for multi6-data@psg.com; Sun, 11 May 2003 09:02:33 +0000 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 19Emik-0001iJ-00 for multi6@ops.ietf.org; Sun, 11 May 2003 09:02:14 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 4559BAE06; Sun, 11 May 2003 05:02:10 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sun, 11 May 2003 05:02:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IETF multihoming powder: just add IPv6 and stir Date: Sun, 11 May 2003 05:02:09 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0341193A@tayexc13.americas.cpqcorp.net> Thread-Topic: IETF multihoming powder: just add IPv6 and stir Thread-Index: AcMSenIBFWAsjF1XRjijHwG+/JoPFgE42oKQ From: "Bound, Jim" To: "J. Noel Chiappa" , X-OriginalArrivalTime: 11 May 2003 09:02:10.0038 (UTC) FILETIME=[0148A160:01C3179C] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA00532 we need to capture what Noel listed here for sure. /jim > -----Original Message----- > From: J. Noel Chiappa [mailto:jnc@ginger.lcs.mit.edu] > Sent: Sunday, May 04, 2003 4:00 PM > To: multi6@ops.ietf.org > Cc: jnc@ginger.lcs.mit.edu > Subject: Re: IETF multihoming powder: just add IPv6 and stir > > > > From: Kurt Erik Lindqvist > > >> It might be good to get the word out that multi6 wants > to recharter > >> and work on the identifier/locator thing aka GSE++ aka > 6+10. Then we > >> can see if the pro mob is larger than the anti mob at > the meeting. > > > I am not sure I want to say that we recharter to the > GSE++ model. > > ... > > they want to present and make their case for their > solution and against > > a GSE based approach > > When people start talking loosely about "GSE" I get nervous, > because there are a number of (to me) independent > architectural and engineering points that are involved in > what I think of as "GSE". > > (Indeed, there might be a danger that "GSE" means different > things to different people, but that's a *separate* problem > from the one that I'm talking about here.) > > Anyway, I think we need to: > > - keep each of these separate things clear in our mind - > although of course a > particular proposed solution will consist of a (hopefully :-) > carefully selected set of detailed answers, one for each point. > - because if one proves problematic, that *doesn't* mean the other > (independent) ideas are unworkable. > > As I see them, the points in "GSE" are: > > > 1 - The basic approach to multi-homing being use of more than > one locator > (I think we are approaching rough consensus on this for any > solution, not just GSE, but list it for completeness) > 2 - Separation of location and identity, using two separate > and distinct > labels, one for each function > (Again, I think we are approaching rough consensus on this for > any solution, but list it for completeness) > 3 - Use of IPv6 addresses (or parts of them) as the > namespaces for both of > those two classes of identifiers > 4 - Details of the identifier; two obvious options: > A - Use of two complete IPv6 addresses, one for each kind of > identifier, sometimes called "16+16" > B - One IPv6 address, divided into two fields (the > original being > "8+8", but I now see mention of "6+10") > 5 - Replacement of part or all of the location identifier by > entities other > than the endpoints of the end-end communication > A - replacement involving the destination locator only > B - replacement involving the source and destination locators > > Some combinations have repercussions; e.g. 5 plus 4B means > that either you have to modify TCP6 (which I think we decided > was unfeasible), or the original contents of the location > identifier part of the IPv6 address(es) have to be placed > back in the packet before the endpoint processes it. > > Anyway, I hope this sort of framework for thinking about them > is useful. > > Noel > > From owner-multi6@ops.ietf.org Sun May 11 05:00:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00564 for ; Sun, 11 May 2003 05:00:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Emiv-0001j3-00 for multi6-data@psg.com; Sun, 11 May 2003 09:02:25 +0000 Received: from mailout.zma.compaq.com ([161.114.64.104] helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 19Emik-0001iK-00 for multi6@ops.ietf.org; Sun, 11 May 2003 09:02:14 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id AC80EAB41; Sun, 11 May 2003 05:02:10 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sun, 11 May 2003 05:02:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Date: Sun, 11 May 2003 05:02:10 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0341193C@tayexc13.americas.cpqcorp.net> Thread-Topic: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Thread-Index: AcMWG42uzv9qWLhrSB22o3QJHJsxvQBQ6KyA From: "Bound, Jim" To: "Pekka Nikander" Cc: X-OriginalArrivalTime: 11 May 2003 09:02:10.0585 (UTC) FILETIME=[019C1890:01C3179C] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA00564 Pekka, Didn't you have to keep as HIT cache on the end host? Also I have read the updated drafts and now I will say after much thought I am not clear the pain for HIP is worth it and it will take a long time to sort this out as IP stack developer. THere will be much needed change on end host and in the core of layer and I am not clear it is a big win. And I like the idea of IP adddreses used for IPsec identifiers totally. It keeps us all honest about e2e in relation to the IP header. I view HIP like my work on the offload of IP stackes to NICs. It will take much thought. But I think it is heing oversold completely. For IPsec can we go offline we must make this an extension not a change or it will not fly for a long time for implementation? thanks /jim > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] > Sent: Friday, May 09, 2003 7:11 AM > To: Bound, Jim > Cc: multi6@ops.ietf.org > Subject: Re: GSE IDs [Re: IETF multihoming powder: just add > IPv6 and stir] > > > Jim, > > Bound, Jim wrote: > > Yes the HIP SPI could use the low order 64 bits but I want to read > > updates from Pekka N. just sent out for arch-03. I am also unclear > > the HIP code changes to our transport layers or at the IP > layers will > > be done by what time frame. > > HIP, in the way we implement it today, does not require any > changes to the transport layers at all, or to the IP layer in > anywhere else but at the end-hosts. That is, of course, not > the only way to implement HIP, and it is probably also > possible to "distribute" HIP between an end-host and a middle > box, resulting in something that resembles MHAP. > > In our current implementation, the only changes in the > kernel are in IPsec ESP code. All the rest is in user > level, and the user level deamon dynamically modifies the > IPsec SPD and SA entries to implement mobility. > > Implementing multi-homing will require more extensive changes > to IPsec or elsewhere in the kernel. We are still thinking > on how to do that. Basically, we need to implement > destination address selection somewhere in the kernel. (At > this stage we will be ignoring the actual selection > algorithm, and concentrate on the architecture: Where to > "rewrite" the HIT into an IP address, and how to select the > right destination (and source) > address(es).) > > --Pekka Nikander > > From owner-multi6@ops.ietf.org Sun May 11 05:00:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00580 for ; Sun, 11 May 2003 05:00:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Emim-0001ie-00 for multi6-data@psg.com; Sun, 11 May 2003 09:02:16 +0000 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 19Emik-0001iI-00 for multi6@ops.ietf.org; Sun, 11 May 2003 09:02:14 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 80CD5BD3C; Sun, 11 May 2003 05:02:10 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sun, 11 May 2003 05:02:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: comments on requirements-05 Date: Sun, 11 May 2003 05:02:09 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0341193B@tayexc13.americas.cpqcorp.net> Thread-Topic: comments on requirements-05 Thread-Index: AcMUFpmjyM6ODoNVRHW/dLOlOJSG6QDR82HA From: "Bound, Jim" To: "Kurt Erik Lindqvist" Cc: X-OriginalArrivalTime: 11 May 2003 09:02:10.0413 (UTC) FILETIME=[0181D9D0:01C3179C] X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA00580 I see nothing worth complaining about I think this req doc is in far better shape than before. Two notes: 1. Add Noel's list for clarity to the reqs. 2. Change RFC 2553 to RFC 3493 Thanks /jim From owner-multi6@ops.ietf.org Sun May 11 05:19:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00848 for ; Sun, 11 May 2003 05:19:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19En2G-0004DB-00 for multi6-data@psg.com; Sun, 11 May 2003 09:22:24 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19En2E-0004Cz-00 for multi6@ops.ietf.org; Sun, 11 May 2003 09:22:22 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h4B9Kxn26025; Sun, 11 May 2003 11:20:59 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sun, 11 May 2003 11:21:01 +0200 Subject: Re: IETF multihoming powder: just add IPv6 and stir Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "J. Noel Chiappa" , To: "Bound, Jim" From: Iljitsch van Beijnum In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B0341193A@tayexc13.americas.cpqcorp.net> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-19.4 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On zondag, mei 11, 2003, at 11:02 Europe/Amsterdam, Bound, Jim wrote: > we need to capture what Noel listed here for sure. At the same time we have to be careful that we don't go through this list and pick the option we like best for each item. It's pretty clear that any solution will include some parts that aren't great. The only way to judge the "not great" part is by evaluating the solution as a whole and compare it to other fleshed out solutions. From owner-multi6@ops.ietf.org Sun May 11 05:22:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00889 for ; Sun, 11 May 2003 05:22:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19En4p-0004Yt-00 for multi6-data@psg.com; Sun, 11 May 2003 09:25:03 +0000 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 19En4l-0004Xz-00 for multi6@ops.ietf.org; Sun, 11 May 2003 09:24:59 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 9E9FB1F2F; Sun, 11 May 2003 05:24:58 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sun, 11 May 2003 05:24:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IETF multihoming powder: just add IPv6 and stir Date: Sun, 11 May 2003 05:24:58 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD803@tayexc13.americas.cpqcorp.net> Thread-Topic: IETF multihoming powder: just add IPv6 and stir Thread-Index: AcMXntdok/PK+rNTRWibwngn+mC/RgAACQUA From: "Bound, Jim" To: "Iljitsch van Beijnum" Cc: "J. Noel Chiappa" , X-OriginalArrivalTime: 11 May 2003 09:24:58.0531 (UTC) FILETIME=[30F81730:01C3179F] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA00889 I agree but Noel's list is a good list for the community to see. We cannot not put good stuff out because people will do bad things with it and also that is far to political of a viewpoint to ever achieve progress for our efforts here. /jim > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Sunday, May 11, 2003 5:21 AM > To: Bound, Jim > Cc: J. Noel Chiappa; multi6@ops.ietf.org > Subject: Re: IETF multihoming powder: just add IPv6 and stir > > > On zondag, mei 11, 2003, at 11:02 Europe/Amsterdam, Bound, Jim wrote: > > > we need to capture what Noel listed here for sure. > > At the same time we have to be careful that we don't go through this > list and pick the option we like best for each item. It's > pretty clear > that any solution will include some parts that aren't great. The only > way to judge the "not great" part is by evaluating the solution as a > whole and compare it to other fleshed out solutions. > > From owner-multi6@ops.ietf.org Sun May 11 07:26:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02238 for ; Sun, 11 May 2003 07:26:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Ep04-000JWl-00 for multi6-data@psg.com; Sun, 11 May 2003 11:28:16 +0000 Received: from mail-gw1.hursley.ibm.com ([194.196.110.15]) by psg.com with esmtp (Exim 3.36 #1) id 19Ep02-000JWZ-00 for multi6@ops.ietf.org; Sun, 11 May 2003 11:28:14 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19Ep01-00041n-00 for multi6@ops.ietf.org; Sun, 11 May 2003 12:28:13 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19Ep01-00041i-00 for multi6@ops.ietf.org; Sun, 11 May 2003 12:28:13 +0100 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id MAA154952 for ; Sun, 11 May 2003 12:28:08 +0100 Message-ID: <3EBE2CE4.A33ABE9B@hursley.ibm.com> Date: Sun, 11 May 2003 12:58:44 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: Re: comments on requirements-05 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-13.1 required=5.0 tests=BAYES_01,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Does anybody else have an opinion about this? My opinion is that we have spent *far* too long wordsmithing this document, have as a result downgraded it from "requirements" to "goals," and that we should now just publish it and move on. The current text is good enough. Brian From owner-multi6@ops.ietf.org Sun May 11 09:31:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03618 for ; Sun, 11 May 2003 09:31:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Eqvq-000EoZ-00 for multi6-data@psg.com; Sun, 11 May 2003 13:32:02 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19Eqvo-000EoN-00 for multi6@ops.ietf.org; Sun, 11 May 2003 13:32:00 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h4BDUen26263 for ; Sun, 11 May 2003 15:30:41 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sun, 11 May 2003 15:30:42 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: new draft From: Iljitsch van Beijnum To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-9.7 required=5.0 tests=BAYES_01,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit After friday's discussion I wanted to see what could be accomplished without any kind of negotiation. What I came up with: http://www.muada.com/drafts/draft-van-beijnum-multi6-2pi1a.txt - no middleboxes - no state in routers - bare-bones multihoming for servers is possible without any state in the server (the client must keep state though) - we have to break autoconfiguration - we need the DNS, no multihoming for severs with just IP addresses - optional source address rewriting Note that this is a finished draft and it's not related to the other one I've been working on. Adding some negotiation to the client part should make this much more reasonable but the server part seems reasonably solid. Iljitsch From owner-multi6@ops.ietf.org Sun May 11 12:29:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07611 for ; Sun, 11 May 2003 12:29:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19EtiJ-0000lk-00 for multi6-data@psg.com; Sun, 11 May 2003 16:30:15 +0000 Received: from pa-monroeville1d-140.pit.adelphia.net ([24.50.190.140] helo=localhost) by psg.com with esmtp (Exim 3.36 #1) id 19EtiH-0000lY-00 for multi6@ops.ietf.org; Sun, 11 May 2003 16:30:13 +0000 Received: from [192.168.1.100] (localhost [127.0.0.1]) by localhost (8.12.9/8.12.2) with ESMTP id h4BGU59L001464; Sun, 11 May 2003 12:30:06 -0400 (EDT) Date: Sun, 11 May 2003 12:30:05 -0400 From: "Michael H. Lambert" To: Iljitsch van Beijnum cc: multi6@ops.ietf.org Subject: Re: new draft Message-ID: <5781313.1052656205@[192.168.1.100]> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-15.1 required=5.0 tests=BAYES_01,IN_REP_TO,RCVD_IN_RFCI,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch, A couple of comments on your draft: 1) If I'm drawing the correct inference, it would appear that the number of locator addresses used by a client goes as n!, where n is the number of ISP prefixes. I can easily see sites with n=5. 2) In the case of a host with multiple interfaces, is each interface treated separately (both in the DNS and wrt locator addresses)? Michael From owner-multi6@ops.ietf.org Sun May 11 12:35:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07796 for ; Sun, 11 May 2003 12:35:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Etpq-0002OF-00 for multi6-data@psg.com; Sun, 11 May 2003 16:38:02 +0000 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 19Etpo-0002No-00 for multi6@ops.ietf.org; Sun, 11 May 2003 16:38:00 +0000 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h4BGbwtU019492; Sun, 11 May 2003 12:37:58 -0400 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id h4BGbwJm019489; Sun, 11 May 2003 12:37:58 -0400 Date: Sun, 11 May 2003 12:37:58 -0400 From: "J. Noel Chiappa" Message-Id: <200305111637.h4BGbwJm019489@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: IETF multihoming powder: just add IPv6 and stir Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Iljitsch van Beijnum > At the same time we have to be careful that we don't go through this > list and pick the option we like best for each item. Do note that my list is not a complete list of all possible design questions; it's simply the list that I thought of (in increasing order of specificity) on the way to the solution called "GSE". It would be interesting to try the same exercise on some others sketch designs and see if there are some other ones that aren't in that list. Noel From owner-multi6@ops.ietf.org Sun May 11 12:59:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08306 for ; Sun, 11 May 2003 12:59:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19EuDE-0008UM-00 for multi6-data@psg.com; Sun, 11 May 2003 17:02:12 +0000 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 19EuDB-0008UA-00 for multi6@ops.ietf.org; Sun, 11 May 2003 17:02:10 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 28DAB6AC; Sun, 11 May 2003 13:02:09 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sun, 11 May 2003 13:02:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: new draft Date: Sun, 11 May 2003 13:02:08 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241242@tayexc13.americas.cpqcorp.net> Thread-Topic: new draft Thread-Index: AcMXxNei9qCLC6G2QYew/ihitc6n/wAGP/+A From: "Bound, Jim" To: "Iljitsch van Beijnum" , X-OriginalArrivalTime: 11 May 2003 17:02:09.0057 (UTC) FILETIME=[0ED63110:01C317DF] X-Spam-Status: No, hits=-7.0 required=5.0 tests=BAYES_10,NEW_DOMAIN_EXTENSIONS,QUOTED_EMAIL_TEXT version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA08306 Iljitsch, On first read architecturally I believe where you going will work. Note A6 records are dead and deprecated in IETF and the BIND DNS code base will get rid of them in the near future and remove them from exisitence. Very painful to us who use BIND regarding the cost fyi. So that means lets be very very careful with adding new DNS A* records here folks the BIND community will be very gun-shy of putting new record types in for IPv6 records regarding implementation. I will do deep dive technical review what it means to the server and client code base but I would like to hear a few folks here agree with me the idea is sound and folks will support the architectural principles ??????????????????? I will view it from my day jobs various stacks, BSD, and Linux as a note. It is critical the identification of a mobile client is very very fast serves can take millions of hits in just one hour at the high end it needs to be quick. This architecturally does not break IPv6. We will need to define a new address type for IPv6 and I think you avoid much of the formality of that approach with your method. You also traded off complexity in the host instead of using some IPv6 extensions to assist with the effort architecturally. I am still not convinced that trade off is completely necessary and some of this can be reduced with DST Options and a New Extension Header to support identification and processing for mutli6. But that is an engineering discussion if we believe this architecture is worth discussion. I believe it is. Nice job, /jim > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Sunday, May 11, 2003 9:31 AM > To: multi6@ops.ietf.org > Subject: new draft > > > After friday's discussion I wanted to see what could be accomplished > without any kind of negotiation. What I came up with: > http://www.muada.com/drafts/draft-van-beijnum-multi6-2pi1a.txt - no middleboxes - no state in routers - bare-bones multihoming for servers is possible without any state in the server (the client must keep state though) - we have to break autoconfiguration - we need the DNS, no multihoming for severs with just IP addresses - optional source address rewriting Note that this is a finished draft and it's not related to the other one I've been working on. Adding some negotiation to the client part should make this much more reasonable but the server part seems reasonably solid. Iljitsch From owner-multi6@ops.ietf.org Sun May 11 16:00:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11780 for ; Sun, 11 May 2003 16:00:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Ewzz-000320-00 for multi6-data@psg.com; Sun, 11 May 2003 20:00:43 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19Ewzx-00031f-00 for multi6@ops.ietf.org; Sun, 11 May 2003 20:00:41 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h4BJxLn26703; Sun, 11 May 2003 21:59:21 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sun, 11 May 2003 21:59:23 +0200 Subject: Re: new draft Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: "Michael H. Lambert" From: Iljitsch van Beijnum In-Reply-To: <5781313.1052656205@[192.168.1.100]> Message-Id: <0FCB2C4E-83EB-11D7-96F1-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On zondag, mei 11, 2003, at 18:30 Europe/Amsterdam, Michael H. Lambert wrote: > A couple of comments on your draft: > 1) If I'm drawing the correct inference, it would appear that the > number of locator addresses used by a client goes as n!, where n is > the number of ISP prefixes. I can easily see sites with n=5. A multihomed server would use n locator addresses for a single identifier. A multihomed client could decide to create double prefix addresses for each combination of prefixes, which would make for n(n-1) addresses, or even double this by also creating two versions of each combination, with different prefixes being the identifier for each of those two versions. I'm not sure if I'd recommend this, though... > 2) In the case of a host with multiple interfaces, is each interface > treated separately (both in the DNS and wrt locator addresses)? I don't think it matters whether n addresses are from n interfaces with one address each or 1 interface with n addresses. So it seems this solves host multihoming as well. Iljitsch From owner-multi6@ops.ietf.org Sun May 11 16:17:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12199 for ; Sun, 11 May 2003 16:17:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19ExIo-0008AC-00 for multi6-data@psg.com; Sun, 11 May 2003 20:20:10 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19ExIm-00089x-00 for multi6@ops.ietf.org; Sun, 11 May 2003 20:20:08 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h4BKImn26735; Sun, 11 May 2003 22:18:48 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sun, 11 May 2003 22:18:51 +0200 Subject: Re: new draft Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Bound, Jim" From: Iljitsch van Beijnum In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03241242@tayexc13.americas.cpqcorp.net> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-27.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,NEW_DOMAIN_EXTENSIONS, QUOTED_EMAIL_TEXT,REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On zondag, mei 11, 2003, at 19:02 Europe/Amsterdam, Bound, Jim wrote: > On first read architecturally I believe where you going will work. > Note > A6 records are dead and deprecated in IETF and the BIND DNS code base > will get rid of them in the near future and remove them from > exisitence. > Very painful to us who use BIND regarding the cost fyi. So that means > lets be very very careful with adding new DNS A* records here folks the > BIND community will be very gun-shy of putting new record types in for > IPv6 records regarding implementation. I understand. But I see no reasonable alternative. Creating something that does exactly this job but isn't DNS would be inefficient, to say the least. If there is another way to infer the locators from an identifier that doesn't involve a huge distributed database, I'd like to hear about it as it would solve some additional stuff. > You also traded off complexity in the host instead of using some IPv6 > extensions to assist with the effort architecturally. I am still not > convinced that trade off is completely necessary and some of this can > be > reduced with DST Options and a New Extension Header to support > identification and processing for mutli6. But that is an engineering > discussion if we believe this architecture is worth discussion. I > believe it is. If we go down the option path we quickly end up in mobility teritory. This may or may not be a bad thing. Since options are easily forged, they must be protected cryptographically. Maybe we should see if there is any synergy to be found by combining all of this with IPsec. > Nice job, Thanks. Iljitsch From owner-multi6@ops.ietf.org Sun May 11 17:09:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12809 for ; Sun, 11 May 2003 17:09:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Ey6d-000N34-00 for multi6-data@psg.com; Sun, 11 May 2003 21:11:39 +0000 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 19Ey6a-000N1F-00 for multi6@ops.ietf.org; Sun, 11 May 2003 21:11:36 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 3C077CE0E; Sun, 11 May 2003 17:11:31 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sun, 11 May 2003 17:11:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: new draft Date: Sun, 11 May 2003 17:11:30 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD818@tayexc13.americas.cpqcorp.net> Thread-Topic: new draft Thread-Index: AcMX+rsdiI1Ud6UETFSXwclDKwEwCgABwAiw From: "Bound, Jim" To: "Iljitsch van Beijnum" Cc: X-OriginalArrivalTime: 11 May 2003 21:11:31.0140 (UTC) FILETIME=[E4EEE040:01C31801] X-Spam-Status: No, hits=-7.8 required=5.0 tests=BAYES_01,NEW_DOMAIN_EXTENSIONS,QUOTED_EMAIL_TEXT version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA12809 On the DNS. I support doing this with DNS. I just want to be sure that the DNS community has no pain with it. I don't think they will as it is just another record type which is far less than A6 was. /jim > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Sunday, May 11, 2003 4:19 PM > To: Bound, Jim > Cc: multi6@ops.ietf.org > Subject: Re: new draft > > > On zondag, mei 11, 2003, at 19:02 Europe/Amsterdam, Bound, Jim wrote: > > > On first read architecturally I believe where you going will work. > > Note > > A6 records are dead and deprecated in IETF and the BIND DNS > code base > > will get rid of them in the near future and remove them from > > exisitence. > > Very painful to us who use BIND regarding the cost fyi. So > that means > > lets be very very careful with adding new DNS A* records > here folks the > > BIND community will be very gun-shy of putting new record > types in for > > IPv6 records regarding implementation. > > I understand. But I see no reasonable alternative. Creating something > that does exactly this job but isn't DNS would be inefficient, to say > the least. If there is another way to infer the locators from an > identifier that doesn't involve a huge distributed database, I'd like > to hear about it as it would solve some additional stuff. > > > You also traded off complexity in the host instead of using > some IPv6 > > extensions to assist with the effort architecturally. I am > still not > > convinced that trade off is completely necessary and some > of this can > > be reduced with DST Options and a New Extension Header to support > > identification and processing for mutli6. But that is an > engineering > > discussion if we believe this architecture is worth discussion. I > > believe it is. > > If we go down the option path we quickly end up in mobility teritory. > This may or may not be a bad thing. > > Since options are easily forged, they must be protected > cryptographically. Maybe we should see if there is any synergy to be > found by combining all of this with IPsec. > > > Nice job, > > Thanks. > > Iljitsch > > From owner-multi6@ops.ietf.org Mon May 12 16:14:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02248 for ; Mon, 12 May 2003 16:14:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FJhY-000EMx-00 for multi6-data@psg.com; Mon, 12 May 2003 20:15:12 +0000 Received: from cordelia.lcs.mit.edu ([18.26.0.55]) by psg.com with esmtp (Exim 3.36 #1) id 19FJhU-000EMh-00 for multi6@ops.ietf.org; Mon, 12 May 2003 20:15:08 +0000 Received: from cordelia.lcs.mit.edu (localhost [127.0.0.1]) by cordelia.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h4CKF703061477 for ; Mon, 12 May 2003 16:15:07 -0400 (EDT) (envelope-from yxw@cordelia.lcs.mit.edu) Date: Mon, 12 May 2003 16:15:06 -0400 Message-ID: From: Xiaowei Yang To: multi6@ops.ietf.org Subject: my work on a new Internet routing architecture In-Reply-To: References: <200305042000.h44K0TZH008279@ginger.lcs.mit.edu> User-Agent: Wanderlust/2.8.1 (Something) Emacs/21.2 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, hits=-15.5 required=5.0 tests=BAYES_10,IN_REP_TO,REFERENCES,USER_AGENT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi, I am a graduate student working on the design of a new Internet Routing architecture. I've sketched out the design in a short paper. One reader pointed out that I might get some operational side comments from this list. If you are interested, you can find the paper at: http://www.isi.edu/newarch/DOCUMENTS/anon2.routing.pdf I'd appreciate your comments very much! If this posting is against the policy of the list, I apology and promise will not do it again. Xiaowei From owner-multi6@ops.ietf.org Mon May 12 20:00:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09178 for ; Mon, 12 May 2003 20:00:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FNEx-000HVI-00 for multi6-data@psg.com; Tue, 13 May 2003 00:01:55 +0000 Received: from tomts19.bellnexxia.net ([209.226.175.73] helo=tomts19-srv.bellnexxia.net) by psg.com with esmtp (Exim 3.36 #1) id 19FNEu-000HUx-00 for multi6@ops.ietf.org; Tue, 13 May 2003 00:01:52 +0000 Received: from yahoo.com ([65.93.188.118]) by tomts19-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with ESMTP id <20030513000151.BDHK21297.tomts19-srv.bellnexxia.net@yahoo.com>; Mon, 12 May 2003 20:01:51 -0400 Date: Mon, 12 May 2003 20:01:49 -0400 Subject: Re: New draft: Now What? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Pekka Savola From: S Woodside In-Reply-To: Message-Id: <1870D5AD-84D6-11D7-9CED-000393414368@yahoo.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-22.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,FORGED_YAHOO_RCVD,IN_REP_TO, QUOTED_EMAIL_TEXT,RCVD_FAKE_HELO_DOTCOM,REPLY_WITH_QUOTES, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday, May 8, 2003, at 02:14 AM, Pekka Savola wrote: >> I'll continue to harp on the CWN angle since I think I've found the >> right IETF area ;-) Load sharing is a requirement for multihoming CWN >> nodes. It would be good to get that into the internet architecture >> instead of having to create something special to CWNs to handle it. > > Could you elaborate on the specific load sharing needs, how it's done > now, > etc. because this seems very surprising to me. Load sharing: people want to join the CWN to use the aggregate upstream bandwidth of the CWN nodes. Even if it's just me and my neighbour, the ability for me to use the bandwidth from my DSL and his cable at the same time is desired. (Yes ... I know I can't bond the links ...) CWN Multihoming, currently it's not done. - The MeshAP in Knightsbridge and generally systems based on the locustworld system select the closest internet gateway in the mesh and use that one. Routing inside the mesh is with AODV. It's probably the most advanced CWN today. - SeattleWireless uses squid to proxy network connections for gateway owners who want to share their bandwidth. They know they want it. They just don't know how to do it. >> Also IIRC another person mentioned the PAN, where you might have WiFi >> and GPRS connections, where does that fall into your taxonomy? > > I'm not sure what you refer to. Let me outline a hypothetical situation. I have a PB titanium, it's a new one, with bluetooth, and WiFi, and I have a bluetooth phone with a GPRS connection. I'm at the office so my pb can connect either with Wifi to the corporate network to the intranet only, or with GPRS to the public internet. Is that challenging enough? ;-) simon >> On Tuesday, May 6, 2003, at 05:25 PM, Pekka Savola wrote: >> >>> .--------------.------------.--------------. >>> | Independence | Redundancy | Load sharing | >>> .--------------+--------------+------------+--------------+ >>> |Minimal | no | no | no | >>> |Small | maybe | maybe | no | >>> |Large | maybe/yes | yes | maybe | >>> |International | yes | yes | yes | >>> '--------------'--------------'------------'--------------' >>> -- www.simonwoodside.com -- 99% Devil, 1% Angel From owner-multi6@ops.ietf.org Mon May 12 20:11:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09565 for ; Mon, 12 May 2003 20:11:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FNQc-000IKE-00 for multi6-data@psg.com; Tue, 13 May 2003 00:13:58 +0000 Received: from tomts19.bellnexxia.net ([209.226.175.73] helo=tomts19-srv.bellnexxia.net) by psg.com with esmtp (Exim 3.36 #1) id 19FNQZ-000IJn-00 for multi6@ops.ietf.org; Tue, 13 May 2003 00:13:55 +0000 Received: from yahoo.com ([65.93.188.118]) by tomts19-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with ESMTP id <20030513001354.BPBQ21297.tomts19-srv.bellnexxia.net@yahoo.com>; Mon, 12 May 2003 20:13:54 -0400 Date: Mon, 12 May 2003 20:13:53 -0400 Subject: Re: comments on requirements-05 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Pekka Savola From: S Woodside In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-22.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,FORGED_YAHOO_RCVD,IN_REP_TO, QUOTED_EMAIL_TEXT,RCVD_FAKE_HELO_DOTCOM,REPLY_WITH_QUOTES, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, May 9, 2003, at 12:40 PM, Pekka Savola wrote: > With the current state of *being typically able* to punch a hole in the > aggregate and steal the address space (perhaps by paying some small > sum to > the original party), you end up with rather a close approximation of > independence ("PA address becomes de-facto PI"). Typically for large sites only though right? simon From owner-multi6@ops.ietf.org Mon May 12 21:02:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10480 for ; Mon, 12 May 2003 21:02:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FOCa-000L9L-00 for multi6-data@psg.com; Tue, 13 May 2003 01:03:32 +0000 Received: from tomts25-srv.bellnexxia.net ([209.226.175.188]) by psg.com with esmtp (Exim 3.36 #1) id 19FOCW-000L98-00 for multi6@ops.ietf.org; Tue, 13 May 2003 01:03:28 +0000 Received: from yahoo.com ([65.93.188.118]) by tomts25-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with ESMTP id <20030513010326.WETH24880.tomts25-srv.bellnexxia.net@yahoo.com> for ; Mon, 12 May 2003 21:03:26 -0400 Date: Mon, 12 May 2003 21:03:26 -0400 Subject: Re: comments on requirements-05 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: S Woodside To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-22.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,FORGED_YAHOO_RCVD,IN_REP_TO, QUOTED_EMAIL_TEXT,RCVD_FAKE_HELO_DOTCOM,REPLY_WITH_QUOTES, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, May 9, 2003, at 12:40 PM, Pekka Savola wrote: >>>>> This contributes to the rapidly-increasing size of the >>>>> global routing table. >>>>> ==> s/size/size and dynamicity/ (better word than dynamicity?!?!) >>>> complexity? >>> Complexity is too generic a term unfortunately, it doesn't imply >>> anything about the advertise/withdraw cycles caused by site >>> multihoming. >> turbulence? > Sounds rather good, gives the right impression. turnover is used when there's a lot of change in the staff at a company. Or how about turmoil ? cycling could work too since it's cycles. turbulence makes me think of airplanes ;-) yes, I love playing with words ;-) simon From owner-multi6@ops.ietf.org Tue May 13 01:46:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16056 for ; Tue, 13 May 2003 01:46:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FSdN-000Guo-00 for multi6-data@psg.com; Tue, 13 May 2003 05:47:29 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19FSdL-000GuX-00 for multi6@ops.ietf.org; Tue, 13 May 2003 05:47:27 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4D5lKE16280; Tue, 13 May 2003 08:47:20 +0300 Date: Tue, 13 May 2003 08:47:19 +0300 (EEST) From: Pekka Savola To: S Woodside cc: multi6@ops.ietf.org Subject: Re: comments on requirements-05 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 12 May 2003, S Woodside wrote: > On Friday, May 9, 2003, at 12:40 PM, Pekka Savola wrote: > > With the current state of *being typically able* to punch a hole in the > > aggregate and steal the address space (perhaps by paying some small > > sum to > > the original party), you end up with rather a close approximation of > > independence ("PA address becomes de-facto PI"). > > Typically for large sites only though right? Yes, but rather small ones have also paid for that. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Tue May 13 01:53:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16163 for ; Tue, 13 May 2003 01:53:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FSl0-000Hom-00 for multi6-data@psg.com; Tue, 13 May 2003 05:55:22 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19FSkp-000Hnv-00 for multi6@ops.ietf.org; Tue, 13 May 2003 05:55:11 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4D5t6516353; Tue, 13 May 2003 08:55:06 +0300 Date: Tue, 13 May 2003 08:55:05 +0300 (EEST) From: Pekka Savola To: S Woodside cc: multi6@ops.ietf.org Subject: Re: New draft: Now What? In-Reply-To: <1870D5AD-84D6-11D7-9CED-000393414368@yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 12 May 2003, S Woodside wrote: > On Thursday, May 8, 2003, at 02:14 AM, Pekka Savola wrote: > >> I'll continue to harp on the CWN angle since I think I've found the > >> right IETF area ;-) Load sharing is a requirement for multihoming CWN > >> nodes. It would be good to get that into the internet architecture > >> instead of having to create something special to CWNs to handle it. > > > > Could you elaborate on the specific load sharing needs, how it's done > > now, > > etc. because this seems very surprising to me. > > Load sharing: people want to join the CWN to use the aggregate upstream > bandwidth of the CWN nodes. Even if it's just me and my neighbour, the > ability for me to use the bandwidth from my DSL and his cable at the > same time is desired. (Yes ... I know I can't bond the links ...) Which addresses do the CWN nodes configure in the DNS? E.g. if I have a BSD box sitting there as my personal home router, and it has DNS records, which of them are used for that? I would imagine it's today done with NAT, if it's possible.. Or is the direction of the load-sharing strictly out-bound? (which is less of a problem.) > > CWN Multihoming, currently it's not done. - The MeshAP in Knightsbridge > and generally systems based on the locustworld system select the > closest internet gateway in the mesh and use that one. Routing inside > the mesh is with AODV. It's probably the most advanced CWN today. - > SeattleWireless uses squid to proxy network connections for gateway > owners who want to share their bandwidth. They know they want it. They > just don't know how to do it. > Interesting -- even though a bit more research-oriented than "mainstream" multihoming. > >> Also IIRC another person mentioned the PAN, where you might have WiFi > >> and GPRS connections, where does that fall into your taxonomy? > > > > I'm not sure what you refer to. > > Let me outline a hypothetical situation. I have a PB titanium, it's a > new one, with bluetooth, and WiFi, and I have a bluetooth phone with a > GPRS connection. I'm at the office so my pb can connect either with > Wifi to the corporate network to the intranet only, or with GPRS to the > public internet. Is that challenging enough? ;-) Well, PB+phone could be considered as a small site of its own, but for most intents and purposes, it seems to act similarly as a single node. This issue seems similar in some ways to the case where a company (a site) provides ADSL access to its employees' homes. Are those homes (where there might be more than one node, even more than one subnet) sites too? What if the home also has a "regular" Internet access? These are tough questions, and I don't have the answers, unfortunately. :-) Multihoming with multiple connections and multiple addresses should work, though. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Tue May 13 03:54:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00016 for ; Tue, 13 May 2003 03:54:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FUdV-00043l-00 for multi6-data@psg.com; Tue, 13 May 2003 07:55:45 +0000 Received: from dhcp-9-211.ripemtg.ripe.net ([193.0.9.211] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 19FUdR-00043D-00 for multi6@ops.ietf.org; Tue, 13 May 2003 07:55:41 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h4D7w8Tq009222; Tue, 13 May 2003 09:58:09 +0200 (CEST) Date: Tue, 13 May 2003 09:58:05 +0200 Subject: Re: Mutli6 meeting in Vienna Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Cedric de Launois From: Kurt Erik Lindqvist In-Reply-To: <1052463399.749.24.camel@descartes.info.ucl.ac.be> Message-Id: X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA00016 On fredag, maj 9, 2003, at 08:56 Europe/Stockholm, Cedric de Launois wrote: > Le ven 09/05/2003 à 07:03, Kurt Erik Lindqvist a écrit : >> ... (I was going through the >> ID archives but I could't find much more than my drafts, Iljitsch, >> Tonys and Michels expired drafts. Then we also have HIP. Have I missed >> something?). Opinions? > > I am currently working on a new draft, "Host-Centric IPv6 Multihoming > with Traffic Engineering". It will be soon ready. It is quite far from > what is discussed here at the moment but I think we should not forget > host-centric solutions and traffic engineering needs. > The problem is that I am not sure we will have the time to let everyone present their solutions. This is to some extend a "catch-up" meeting and we might have more detailed presentations in the future. But let's see what we get on the agenda. - kurtis - From owner-multi6@ops.ietf.org Tue May 13 03:55:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00040 for ; Tue, 13 May 2003 03:55:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FUgB-0004Gd-00 for multi6-data@psg.com; Tue, 13 May 2003 07:58:31 +0000 Received: from dhcp-9-211.ripemtg.ripe.net ([193.0.9.211] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 19FUg8-0004GR-00 for multi6@ops.ietf.org; Tue, 13 May 2003 07:58:28 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h4D80vTq009228; Tue, 13 May 2003 10:00:57 +0200 (CEST) Date: Tue, 13 May 2003 10:00:55 +0200 Subject: Re: Mutli6 meeting in Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Brian E Carpenter From: Kurt Erik Lindqvist In-Reply-To: <3EBB6AA9.5524DAA6@hursley.ibm.com> Message-Id: <060AC75F-8519-11D7-BDC5-000393520ED8@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Agreed. We will try and arrange an overview presentation. - kurtis - On fredag, maj 9, 2003, at 10:45 Europe/Stockholm, Brian E Carpenter wrote: > I think what would be excellent would be for someone to open the > meeting > with an overview of the classes of solutions. We may need to launch > parallel > efforts, so agreeing which classes of solution we want to develop is > an important first step. > > Brian > > Kurt Erik Lindqvist wrote: >> >>> I am rethinking my R&R time off in July and might change my mind and >>> come to Vienna. >>> Part of my decision is are we going to meet officially as Multi6 and >>> if >>> we do can we schedule one 2 hour offsite but not on Sunday as coming >>> from U.S. I don't want to get there on Saturday (well I can't). Us >>> meeting would input to my decision and two other areas of the IETF I >>> am >>> not comfortable not being at for some issues that require important >>> face-to-face discussion. >>> >> >> We are in the clear that we should meet. What we need to work on is >> the >> agenda. Me and Sean have been sending some sporadic emails between >> eachother on this, but I guess we need to more a bit more here. As to >> an off-site face-to-face meeting, I would say that this is partly up >> to >> what the agenda would include. >> >> I am still also open to input on the agenda and the structure of the >> meeting. From the past weeks discussions here I would assume that >> "GSE" >> will be a large topic, but we would need something to discuss around. >> We also have Pekkas draft and we have the option to have someone go >> through the options brought to the IETF so far (I was going through >> the >> ID archives but I could't find much more than my drafts, Iljitsch, >> Tonys and Michels expired drafts. Then we also have HIP. Have I missed >> something?). Opinions? >> >> I guess that if we want to have a private session, that would be on >> the >> topic of identifier/locator separation ? >> >> - kurtis - From owner-multi6@ops.ietf.org Tue May 13 03:59:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00224 for ; Tue, 13 May 2003 03:59:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FUjt-0004Op-00 for multi6-data@psg.com; Tue, 13 May 2003 08:02:21 +0000 Received: from dhcp-9-211.ripemtg.ripe.net ([193.0.9.211] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 19FUjq-0004Od-00 for multi6@ops.ietf.org; Tue, 13 May 2003 08:02:19 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h4D84XTq009231; Tue, 13 May 2003 10:04:34 +0200 (CEST) Date: Tue, 13 May 2003 10:04:31 +0200 Subject: Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Tony Li" , multi6@ops.ietf.org To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <1745C9F6-81FB-11D7-AF00-00039388672E@muada.com> Message-Id: <87337375-8519-11D7-BDC5-000393520ED8@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On fredag, maj 9, 2003, at 10:49 Europe/Stockholm, Iljitsch van Beijnum wrote: > On vrijdag, mei 9, 2003, at 01:08 Europe/Amsterdam, Tony Li wrote: > >> I would prefer that we avoided having a stateful mapping mechanism. > > It all flows from having more than one address with different > reachability properties. At some point, someone has to decide which > address to use for a particular purpose, and it had better be the > "right" address most of the time or we're worse off than being > single-homed. > >> It's unnecessary and certainly more complication than we need. > > It doesn't have to be complicated: something as simple as publishing > all the addresses in the DNS and/or in an option in the first packet > along with a simple algorithm that figures out which address seems to > be working best is all we need. (But it may not be all we want.) > > What kind of stateless mechanism do you have in mind? Obviously a > stateless solution would be preferable over a stateful one. What worries me as ex-operator is that state in a network comes at a cost. Normally state is actually among the most costly components of network design. So, I agree that I would like to avoid any stateful mapping. Now, that said I agree that a stateless mechanism is going to harder to design and implement. > >> I would also prefer that we not proclaim something to be GSE that >> isn't, regardless of congruence or continuation of ideas. > > I did use the term "GSE" a bit loosely a week or so ago but rest > assured that this won't happen in the final version of the draft. I think we need to define a new term to denote a id/loc separation solution. - kurtis - From owner-multi6@ops.ietf.org Tue May 13 04:01:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00294 for ; Tue, 13 May 2003 04:01:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FUlT-0004UX-00 for multi6-data@psg.com; Tue, 13 May 2003 08:03:59 +0000 Received: from dhcp-9-211.ripemtg.ripe.net ([193.0.9.211] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 19FUlR-0004UF-00 for multi6@ops.ietf.org; Tue, 13 May 2003 08:03:57 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h4D864Tq009234; Tue, 13 May 2003 10:06:05 +0200 (CEST) Date: Tue, 13 May 2003 10:06:02 +0200 Subject: Re: Mutli6 meeting in Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Bound, Jim" , multi6@ops.ietf.org To: Coene Lode From: Kurt Erik Lindqvist In-Reply-To: <57FD2C3A246F76438CA6FDAD8FE9F195A7F3E4@hrtades7.atea.be> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On fredag, maj 9, 2003, at 12:48 Europe/Stockholm, Coene Lode wrote: >> >> I am still also open to input on the agenda and the structure of the >> meeting. From the past weeks discussions here I would assume >> that "GSE" >> will be a large topic, but we would need something to discuss around. >> We also have Pekkas draft and we have the option to have someone go >> through the options brought to the IETF so far (I was going >> through the >> ID archives but I could't find much more than my drafts, Iljitsch, >> Tonys and Michels expired drafts. Then we also have HIP. Have >> I missed >> something?). Opinions? > > There are folks out that can do multihoming already(via SCTP using > multiple > addresses) > I can present something on that(if you don't mind). Again, there are a number of proposals and I am sure that everyone would like to present, but I don't think we can fit them all in. My reason for asking was to make sure that we have an overview solution that covers them all. - kurtis - From owner-multi6@ops.ietf.org Tue May 13 04:06:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00387 for ; Tue, 13 May 2003 04:06:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FUqK-0004or-00 for multi6-data@psg.com; Tue, 13 May 2003 08:09:00 +0000 Received: from dhcp-9-211.ripemtg.ripe.net ([193.0.9.211] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 19FUqI-0004oW-00 for multi6@ops.ietf.org; Tue, 13 May 2003 08:08:58 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h4D8BATq009241; Tue, 13 May 2003 10:11:12 +0200 (CEST) Date: Tue, 13 May 2003 10:11:09 +0200 Subject: Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Bound, Jim" , multi6@ops.ietf.org To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <675A48BD-821B-11D7-AF00-00039388672E@muada.com> Message-Id: <740D93C4-851A-11D7-BDC5-000393520ED8@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On fredag, maj 9, 2003, at 14:40 Europe/Stockholm, Iljitsch van Beijnum wrote: > > Also, we can't assume that users will universally prefer a stateless > solution with per-packet overhead over a stateful one that doesn't > have extra overhead. I would like to argue that per-packet overhead is cheaper than stateful mappning. - kurtis - From owner-multi6@ops.ietf.org Tue May 13 04:10:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00507 for ; Tue, 13 May 2003 04:10:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FUuv-000554-00 for multi6-data@psg.com; Tue, 13 May 2003 08:13:45 +0000 Received: from dhcp-9-211.ripemtg.ripe.net ([193.0.9.211] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 19FUut-00054n-00 for multi6@ops.ietf.org; Tue, 13 May 2003 08:13:43 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h4D8G3Tq009244; Tue, 13 May 2003 10:16:04 +0200 (CEST) Date: Tue, 13 May 2003 10:16:00 +0200 Subject: Re: Mutli6 meeting in Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Brian E Carpenter , multi6@ops.ietf.org To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <139EA57F-8224-11D7-AF00-00039388672E@muada.com> Message-Id: <21D930E9-851B-11D7-BDC5-000393520ED8@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On fredag, maj 9, 2003, at 15:42 Europe/Stockholm, Iljitsch van Beijnum wrote: > On vrijdag, mei 9, 2003, at 10:45 Europe/Amsterdam, Brian E Carpenter > wrote: > >> I think what would be excellent would be for someone to open the >> meeting >> with an overview of the classes of solutions. We may need to launch >> parallel >> efforts, so agreeing which classes of solution we want to develop is >> an important first step. > > It seems we're still not at the stage where there is agreement on > whether any given type of solution is viable or not. Waiting for > Vienna and then discuss all the details in a meeting is not the most > efficient use of time. My goal was not that we would have a "vote" on the solutions. It was merely to give an overview of what proposals have been made and where we are. > I suggest that everyone submits solution classes to be presented and > we then identify the central issue with that class beforehand so we > don't have to be sidetracked by either minor details or fairly obvious > fatal flaws in the meeting. This should allows us to focus on what's > important. > From what I can tell, there are two main-line solution classes that have some wider support. A loc/id separated solution, which seems to have the widest support and what most of the discussions seems to circling around. The second solution class seems to be a "host based" solution. In addition there is HIP, which seems to pop up as an example in both of these solution classes. Am I correct in my assumptions above? - kurtis - From owner-multi6@ops.ietf.org Tue May 13 04:22:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00653 for ; Tue, 13 May 2003 04:22:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FV5n-0005mn-00 for multi6-data@psg.com; Tue, 13 May 2003 08:24:59 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19FV5k-0005mb-00 for multi6@ops.ietf.org; Tue, 13 May 2003 08:24:57 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4D8Om817509; Tue, 13 May 2003 11:24:49 +0300 Date: Tue, 13 May 2003 11:24:48 +0300 (EEST) From: Pekka Savola To: Kurt Erik Lindqvist cc: Iljitsch van Beijnum , Brian E Carpenter , Subject: Re: Mutli6 meeting in Vienna In-Reply-To: <21D930E9-851B-11D7-BDC5-000393520ED8@kurtis.pp.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 13 May 2003, Kurt Erik Lindqvist wrote: > > I suggest that everyone submits solution classes to be presented and > > we then identify the central issue with that class beforehand so we > > don't have to be sidetracked by either minor details or fairly obvious > > fatal flaws in the meeting. This should allows us to focus on what's > > important. > > > > From what I can tell, there are two main-line solution classes that > have some wider support. A loc/id separated solution, which seems to > have the widest support and what most of the discussions seems to > circling around. The second solution class seems to be a "host based" > solution. > In addition there is HIP, which seems to pop up as an example in both > of these solution classes. > > Am I correct in my assumptions above? I think HIP is a loc/id separation solution. But perhaps you meant something like "loc/id separation in the network solution" by your terminology? In my book, HIP is just a way to do certain things in a host-based solution, e.g. fix connection survivability, possibly make the ingress filtering easier/eliminate it etc. HIP is also fit for some other solution spaces for e.g. connection survivability, but it won't be able to solve the whole multihoming problem for certain classes of networks, especially those who require load sharing. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Tue May 13 04:30:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00769 for ; Tue, 13 May 2003 04:30:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FVDz-0006Jx-00 for multi6-data@psg.com; Tue, 13 May 2003 08:33:27 +0000 Received: from dhcp-9-211.ripemtg.ripe.net ([193.0.9.211] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 19FVDw-0006Jj-00 for multi6@ops.ietf.org; Tue, 13 May 2003 08:33:25 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h4D8ZZTq009252; Tue, 13 May 2003 10:35:35 +0200 (CEST) Date: Tue, 13 May 2003 10:35:33 +0200 Subject: Re: comments on requirements-05 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Bound, Jim" From: Kurt Erik Lindqvist In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B0341193B@tayexc13.americas.cpqcorp.net> Message-Id: X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA00769 Ok, I am waiting for Joe to post the -06 version and then I think we will have a short "last-call" and then ship it - kurtis - PS By short I do not mean the 5 hours of last time...:-) On söndag, maj 11, 2003, at 11:02 Europe/Stockholm, Bound, Jim wrote: > I see nothing worth complaining about I think this req doc is in far > better shape than before. > > Two notes: > > 1. Add Noel's list for clarity to the reqs. > > 2. Change RFC 2553 to RFC 3493 > > Thanks > /jim From owner-multi6@ops.ietf.org Tue May 13 04:33:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00817 for ; Tue, 13 May 2003 04:33:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FVGD-0006Ta-00 for multi6-data@psg.com; Tue, 13 May 2003 08:35:45 +0000 Received: from dhcp-9-211.ripemtg.ripe.net ([193.0.9.211] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 19FVGA-0006TO-00 for multi6@ops.ietf.org; Tue, 13 May 2003 08:35:43 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h4D8bmTq009255; Tue, 13 May 2003 10:37:48 +0200 (CEST) Date: Tue, 13 May 2003 10:37:46 +0200 Subject: Re: IETF multihoming powder: just add IPv6 and stir Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Iljitsch van Beijnum" , "J. Noel Chiappa" , To: "Bound, Jim" From: Kurt Erik Lindqvist In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD803@tayexc13.americas.cpqcorp.net> Message-Id: <2C479B28-851E-11D7-BDC5-000393520ED8@kurtis.pp.se> X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA00817 But Noels list for me is more criteria for a specific solution (loc/id separation) rather than a general list? - kurtis - On söndag, maj 11, 2003, at 11:24 Europe/Stockholm, Bound, Jim wrote: > I agree but Noel's list is a good list for the community to see. We > cannot not put good stuff out because people will do bad things with it > and also that is far to political of a viewpoint to ever achieve > progress for our efforts here. > > /jim > > > >> -----Original Message----- >> From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] >> Sent: Sunday, May 11, 2003 5:21 AM >> To: Bound, Jim >> Cc: J. Noel Chiappa; multi6@ops.ietf.org >> Subject: Re: IETF multihoming powder: just add IPv6 and stir >> >> >> On zondag, mei 11, 2003, at 11:02 Europe/Amsterdam, Bound, Jim wrote: >> >>> we need to capture what Noel listed here for sure. >> >> At the same time we have to be careful that we don't go through this >> list and pick the option we like best for each item. It's >> pretty clear >> that any solution will include some parts that aren't great. The only >> way to judge the "not great" part is by evaluating the solution as a >> whole and compare it to other fleshed out solutions. >> >> > From owner-multi6@ops.ietf.org Tue May 13 04:52:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01058 for ; Tue, 13 May 2003 04:52:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FVYn-0007jR-00 for multi6-data@psg.com; Tue, 13 May 2003 08:54:57 +0000 Received: from dhcp-9-211.ripemtg.ripe.net ([193.0.9.211] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 19FVYk-0007jF-00 for multi6@ops.ietf.org; Tue, 13 May 2003 08:54:55 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h4D8v7Tq009273; Tue, 13 May 2003 10:57:08 +0200 (CEST) Date: Tue, 13 May 2003 10:57:05 +0200 Subject: Re: Mutli6 meeting in Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Iljitsch van Beijnum , Brian E Carpenter , To: Pekka Savola From: Kurt Erik Lindqvist In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-16.1 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> I suggest that everyone submits solution classes to be presented and >>> we then identify the central issue with that class beforehand so we >>> don't have to be sidetracked by either minor details or fairly >>> obvious >>> fatal flaws in the meeting. This should allows us to focus on what's >>> important. >>> >> >> From what I can tell, there are two main-line solution classes that >> have some wider support. A loc/id separated solution, which seems to >> have the widest support and what most of the discussions seems to >> circling around. The second solution class seems to be a "host based" >> solution. >> In addition there is HIP, which seems to pop up as an example in both >> of these solution classes. >> >> Am I correct in my assumptions above? > > I think HIP is a loc/id separation solution. But perhaps you meant > something like "loc/id separation in the network solution" by your > terminology? Well, I actually meant that parts of the HIP solution was being discussed as possible pieces for both hosts based and loc/id based solutions. - kurtis - From owner-multi6@ops.ietf.org Tue May 13 05:09:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01458 for ; Tue, 13 May 2003 05:09:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FVoq-0008hj-00 for multi6-data@psg.com; Tue, 13 May 2003 09:11:32 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19FVol-0008hX-00 for multi6@ops.ietf.org; Tue, 13 May 2003 09:11:27 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h4D99tn30304; Tue, 13 May 2003 11:09:55 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 13 May 2003 11:10:01 +0200 Subject: Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Bound, Jim" , multi6@ops.ietf.org To: Kurt Erik Lindqvist From: Iljitsch van Beijnum In-Reply-To: <740D93C4-851A-11D7-BDC5-000393520ED8@kurtis.pp.se> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On dinsdag, mei 13, 2003, at 10:11 Europe/Amsterdam, Kurt Erik Lindqvist wrote: > What worries me as ex-operator is that state in a network comes at a > cost. Normally state is actually among the most costly components of > network design. So, I agree that I would like to avoid any stateful > mapping. Now, that said I agree that a stateless mechanism is going to > harder to design and implement. I think we should more carefully define the word "state". A BGP routing table is state. An IPsec security association is state. An ARP table entry is state. A TCP control block is state. A socket bound to a UDP port is state. We use all of this (maybe with the exception of IPsec) every day, so apparently keeping all this state is worth it. Assume we have A and B that want to communicate, and they have C and D sitting between them passing along the packets. There are also E - Z who are connected to A, B, C and D but they aren't involved in this particular communication. My position is: State in A and B: perfectly acceptable. Applications and transport layer protocols keep state anyway. State in C and D: not good, but not entirely inconceivable. State in E - Z: unacceptable. Which part were you talking about? And in another message you said: >> Also, we can't assume that users will universally prefer a stateless >> solution with per-packet overhead over a stateful one that doesn't >> have extra overhead. > I would like to argue that per-packet overhead is cheaper than > stateful mappning. I'm sure this is true for you. However, I regularly connect to the net with my laptop over GSM at 960 bytes per second costing me 11 cents per minute, and when I do that every byte counts. If you're sitting behind gigabit ethernet where you can do 100000 packets per second regardless of how big they are, you'd rather throw away 10% of the usable data in each packet than add extra processing that halves the number of packets per second you can do. What I'm saying is that it is impossible to determine that globally, EVERYONE will always prefer either state or overhead. Another important point is that the additional information can't be trusted so it must be authenticated. This means crypto, which is harder to do fast than state. Obviously some people will implement very fast crypto but for others even a moderate amount of crypto is extremely undesireable because either they simply don't have the CPU power or they don't want to use it (CPU costs energy, not nice when running on the battery). But I think we should revisit this when there is an actual proposal that adds extra headers to packets because only then we'll be able to see how this helps us and how it hurts us. Finally, I want to warn everyone that there is a very dangerous "who cares about the overhead" attitude in some circles. (Not just IETF, but also IEEE and others.) I did some calculations on VoIP over IPsec and it turns out that even with a factor 4 compression of the data, the total number of bits used by this is larger than regular TDM for voice. Don't forget we have more than 5 layers, if every one of those adds 3% overhead, that's 16% total. If they all do 5% it's 28% and if they all do 10% it's no less than 61%. It adds up very quickly. A good example of what can happen hee is 802.11g that has a 54 Mbps bitrate but delivers little more than 20 Mbps. (But that's partially because of some radio stuff obviously.) From owner-multi6@ops.ietf.org Tue May 13 06:19:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02697 for ; Tue, 13 May 2003 06:19:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FWtc-000DTu-00 for multi6-data@psg.com; Tue, 13 May 2003 10:20:32 +0000 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 19FWtS-000DTc-00 for multi6@ops.ietf.org; Tue, 13 May 2003 10:20:22 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id D15D34322; Tue, 13 May 2003 06:20:20 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Tue, 13 May 2003 06:20:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IETF multihoming powder: just add IPv6 and stir Date: Tue, 13 May 2003 06:20:20 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD84D@tayexc13.americas.cpqcorp.net> Thread-Topic: IETF multihoming powder: just add IPv6 and stir Thread-Index: AcMZKqBaGUN5In3qSkmWKc+lBKNhJQADpwLw From: "Bound, Jim" To: "Kurt Erik Lindqvist" Cc: "Iljitsch van Beijnum" , "J. Noel Chiappa" , X-OriginalArrivalTime: 13 May 2003 10:20:20.0773 (UTC) FILETIME=[42017D50:01C31939] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA02697 I don't agree. But do what you want. /jim > -----Original Message----- > From: Kurt Erik Lindqvist [mailto:kurtis@kurtis.pp.se] > Sent: Tuesday, May 13, 2003 4:38 AM > To: Bound, Jim > Cc: Iljitsch van Beijnum; J. Noel Chiappa; multi6@ops.ietf.org > Subject: Re: IETF multihoming powder: just add IPv6 and stir > > > > > But Noels list for me is more criteria for a specific > solution (loc/id > separation) rather than a general list? > > - kurtis - > > On söndag, maj 11, 2003, at 11:24 Europe/Stockholm, Bound, Jim wrote: > > > I agree but Noel's list is a good list for the community to > see. We > > cannot not put good stuff out because people will do bad > things with > > it and also that is far to political of a viewpoint to ever achieve > > progress for our efforts here. > > > > /jim > > > > > > > >> -----Original Message----- > >> From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > >> Sent: Sunday, May 11, 2003 5:21 AM > >> To: Bound, Jim > >> Cc: J. Noel Chiappa; multi6@ops.ietf.org > >> Subject: Re: IETF multihoming powder: just add IPv6 and stir > >> > >> > >> On zondag, mei 11, 2003, at 11:02 Europe/Amsterdam, Bound, > Jim wrote: > >> > >>> we need to capture what Noel listed here for sure. > >> > >> At the same time we have to be careful that we don't go > through this > >> list and pick the option we like best for each item. It's pretty > >> clear that any solution will include some parts that aren't great. > >> The only way to judge the "not great" part is by evaluating the > >> solution as a whole and compare it to other fleshed out solutions. > >> > >> > > > > From owner-multi6@ops.ietf.org Tue May 13 07:40:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04500 for ; Tue, 13 May 2003 07:40:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FYAW-000JxJ-00 for multi6-data@psg.com; Tue, 13 May 2003 11:42:04 +0000 Received: from server.ripemtg.ripe.net ([193.0.8.2]) by psg.com with esmtp (Exim 3.36 #1) id 19FYAT-000Jwn-00 for multi6@ops.ietf.org; Tue, 13 May 2003 11:42:01 +0000 Received: from dhcp-9-94.ripemtg.ripe.net (marcelo@dhcp-9-94.ripemtg.ripe.net [193.0.9.94]) by server.ripemtg.ripe.net (8.12.9/8.12.6) with ESMTP id h4DBfYwV013773; Tue, 13 May 2003 13:41:36 +0200 Subject: Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] From: marcelo bagnulo To: Iljitsch van Beijnum Cc: Kurt Erik Lindqvist , "Bound, Jim" , multi6@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Organization: uc3m Message-Id: <1052825910.795.10.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 13 May 2003 13:40:08 +0200 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_XIMIAN autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, > But I think we should revisit this when there is an actual proposal > that adds extra headers to packets because only then we'll be able to > see how this helps us and how it hurts us. Well, using MIPv6 could be one of such proposals (there are some issues to solve) but still can be useful to quantify the amount of overhead involved. Regards, marcelo > Finally, I want to warn everyone that there is a very dangerous "who > cares about the overhead" attitude in some circles. (Not just IETF, but > also IEEE and others.) I did some calculations on VoIP over IPsec and > it turns out that even with a factor 4 compression of the data, the > total number of bits used by this is larger than regular TDM for voice. > Don't forget we have more than 5 layers, if every one of those adds 3% > overhead, that's 16% total. If they all do 5% it's 28% and if they all > do 10% it's no less than 61%. It adds up very quickly. A good example > of what can happen hee is 802.11g that has a 54 Mbps bitrate but > delivers little more than 20 Mbps. (But that's partially because of > some radio stuff obviously.) -- marcelo bagnulo uc3m From owner-multi6@ops.ietf.org Tue May 13 08:54:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08850 for ; Tue, 13 May 2003 08:54:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FZJI-000Nsv-00 for multi6-data@psg.com; Tue, 13 May 2003 12:55:12 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19FZJE-000Nsj-00 for multi6@ops.ietf.org; Tue, 13 May 2003 12:55:09 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h4DCrln30668; Tue, 13 May 2003 14:53:47 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 13 May 2003 14:53:53 +0200 Subject: Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: marcelo bagnulo From: Iljitsch van Beijnum In-Reply-To: <1052825910.795.10.camel@presto.it.uc3m.es> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On dinsdag, mei 13, 2003, at 13:40 Europe/Amsterdam, marcelo bagnulo wrote: >> But I think we should revisit this when there is an actual proposal >> that adds extra headers to packets because only then we'll be able to >> see how this helps us and how it hurts us. > Well, using MIPv6 could be one of such proposals (there are some issues > to solve) but still can be useful to quantify the amount of overhead > involved. Mobile IP in IPv6 uses a 24 byte header to carry the original source address, right? If we assume ethernet with a 1500 byte MTU and include the ethernet encapsulation (MAC addresses, ethertype and frame check sequence) but not the lower layer stuff (this is a good compromise between looking only at IP, which is slightly worse or also including the extra framing bits/gap, which is another 20 bytes per packet) and assume full sized packets we arrive at: IPv4 IPv6 MIPv6 Data 1460 1440 1416 Overhead 58 78 112 Efficiency1 96.2% 94.9% 93.3% Efficiency2 94.4% 92.5% 90.3% In the efficiency1 figure we drop 2.9% when moving from IPv4 to MIPv6 but this figure doesn't include the TCP ACKs that nearly double in size. For a full duplex link this adds up to another 3% in overhead while this is only 1.8% for IPv4 so the overall drop in efficiency is 4.1%. Now if you're going to do high speed data transfers you'll obviously want to enable the RFC 1323 high performance extensions which means another 12 bytes per packet are used for timestamp landing you at 89.1% efficiency (93.2% in IPv4). And then there is IPsec... In the real world all of this is a lot worse because the average packet size is significantly smaller than the maximum possible packet size. Now all of this may not seem like a huge deal but what if the bank decides they want to take 4% of the money in your account, or look at the trouble people go through to lose 4% of their weight. For some people this may be a reason to stick with IPv4. On the other hand, if we can keep it at 4% it might be ok. But if the application protocols (which usually have HUGE overhead) and all the lower layers add 4% too then it's no fun anymore. From owner-multi6@ops.ietf.org Tue May 13 10:25:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14454 for ; Tue, 13 May 2003 10:25:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FakT-0007Hu-00 for multi6-data@psg.com; Tue, 13 May 2003 14:27:21 +0000 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.36 #1) id 19FakR-0007Hc-00 for multi6@ops.ietf.org; Tue, 13 May 2003 14:27:19 +0000 Received: (qmail 55628 invoked by uid 0); 13 May 2003 14:27:17 -0000 Received: from localhost.automagic.org (HELO isc.org) (root@127.0.0.1) by localhost.automagic.org with SMTP; 13 May 2003 14:27:17 -0000 Date: Tue, 13 May 2003 10:27:28 -0400 Subject: Re: comments on requirements-05 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Pekka Savola , Kurt Erik Lindqvist , To: Joe Abley From: Joe Abley In-Reply-To: Message-Id: <065B02C0-854F-11D7-92E4-00039312C852@isc.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, May 9, 2003, at 13:06 Canada/Eastern, Joe Abley wrote: > I will make some provisional edits to -05 and float them on the list > today. Sorry about the delay; various other things came up and conspired to keep me busy over the weekend and yesterday. I haven't forgotten about these. Joe From owner-multi6@ops.ietf.org Tue May 13 10:55:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15395 for ; Tue, 13 May 2003 10:55:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FbDu-000AIO-00 for multi6-data@psg.com; Tue, 13 May 2003 14:57:46 +0000 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 19FbDp-000AFC-00 for multi6@ops.ietf.org; Tue, 13 May 2003 14:57:42 +0000 From: Masataka Ohta Message-Id: <200305131450.XAA09092@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id XAA09092; Tue, 13 May 2003 23:50:34 +0900 Subject: Re: Mutli6 meeting in Vienna In-Reply-To: from Kurt Erik Lindqvist at "May 13, 2003 10:06:02 am" To: Kurt Erik Lindqvist Date: Tue, 13 May 2003 23:50:33 +0859 () CC: Coene Lode , "Bound, Jim" , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurt; > >> I am still also open to input on the agenda and the structure of the > >> meeting. From the past weeks discussions here I would assume > >> that "GSE" > >> will be a large topic, GSE is not a proper name of any topic. > >> but we would need something to discuss around. > >> We also have Pekkas draft and we have the option to have someone go > >> through the options brought to the IETF so far (I was going > >> through the > >> ID archives but I could't find much more than my drafts, Iljitsch, > >> Tonys and Michels expired drafts. Then we also have HIP. Have > >> I missed > >> something?). Opinions? You miss LIN6. > > There are folks out that can do multihoming already(via SCTP using > > multiple > > addresses) > > I can present something on that(if you don't mind). > > Again, there are a number of proposals and I am sure that everyone > would like to present, but I don't think we can fit them all in. My > reason for asking was to make sure that we have an overview solution > that covers them all. "The Architecture of End to End Multihoming" has been giving an overview on so-called host based solutions in a way not specific to LIN6 before the WG was created. Thus, I'd like to have a chance of presentation. Masataka Ohta From owner-multi6@ops.ietf.org Tue May 13 11:24:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16542 for ; Tue, 13 May 2003 11:24:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FbgQ-000E1B-00 for multi6-data@psg.com; Tue, 13 May 2003 15:27:14 +0000 Received: from mail2.microsoft.com ([131.107.3.124]) by psg.com with esmtp (Exim 3.36 #1) id 19FbgO-000E0s-00 for multi6@ops.ietf.org; Tue, 13 May 2003 15:27:12 +0000 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Tue, 13 May 2003 08:27:11 -0700 Received: from 157.54.8.23 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 13 May 2003 08:27:11 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 13 May 2003 08:27:11 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 13 May 2003 08:27:10 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Tue, 13 May 2003 08:26:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Date: Tue, 13 May 2003 08:26:55 -0700 Message-ID: Thread-Topic: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] thread-index: AcMZT//q2Al44P7WRQ+LGsI0pi1VkAAE72pA From: "Christian Huitema" To: "Iljitsch van Beijnum" , "marcelo bagnulo" Cc: X-OriginalArrivalTime: 13 May 2003 15:26:55.0490 (UTC) FILETIME=[161C8E20:01C31964] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA16542 > >> But I think we should revisit this when there is an actual proposal > >> that adds extra headers to packets because only then we'll be able to > >> see how this helps us and how it hurts us. > > > Well, using MIPv6 could be one of such proposals (there are some issues > > to solve) but still can be useful to quantify the amount of overhead > > involved. > > Mobile IP in IPv6 uses a 24 byte header to carry the original source > address, right? It does, but it only needs to do so when negotiating a binding update. The trick is to design a usage model of MIPv6 in which binding updates are used to redirect a TCP connection (or a UDP flow) to a new address. -- Christian Huitema From owner-multi6@ops.ietf.org Tue May 13 17:45:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00075 for ; Tue, 13 May 2003 17:45:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FhaT-000O8E-00 for multi6-data@psg.com; Tue, 13 May 2003 21:45:29 +0000 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 19FhaQ-000O3J-00 for multi6@ops.ietf.org; Tue, 13 May 2003 21:45:26 +0000 From: Masataka Ohta Message-Id: <200305132136.GAA10051@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id GAA10051; Wed, 14 May 2003 06:36:37 +0900 Subject: Re: IETF multihoming powder: just add IPv6 and stir In-Reply-To: <200305042000.h44K0TZH008279@ginger.lcs.mit.edu> from "J. Noel Chiappa" at "May 4, 2003 04:00:29 pm" To: "J. Noel Chiappa" Date: Wed, 14 May 2003 06:36:36 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Noel; > 5 - Replacement of part or all of the location identifier by entities other > than the endpoints of the end-end communication > A - replacement involving the destination locator only > B - replacement involving the source and destination locators The question, then, is that what are the endpoints. IMHO, mobile (home) agents and PIM RPs are the end points, just as DNS servers and mail relays are the end points. And the rewriting of destination locators on mobile agents and PIM RPs is useful to eliminate tunneling, OTOH, rewriting of source locator is not so useful, though I have no reason to forbid it. > Some combinations have repercussions; e.g. 5 plus 4B means that either you > have to modify TCP6 (which I think we decided was unfeasible), I showed it feasible. It is working and interoperating with leagacy hosts without extra overhead of negotiation. Masataka Ohta From owner-multi6@ops.ietf.org Tue May 13 18:34:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02572 for ; Tue, 13 May 2003 18:34:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FiNp-00091W-00 for multi6-data@psg.com; Tue, 13 May 2003 22:36:29 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19FiNm-00090e-00 for multi6@ops.ietf.org; Tue, 13 May 2003 22:36:26 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h4DMZ0n31380; Wed, 14 May 2003 00:35:00 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 14 May 2003 00:35:02 +0200 Subject: Re: IETF multihoming powder: just add IPv6 and stir Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "J. Noel Chiappa" , multi6@ops.ietf.org To: Masataka Ohta From: Iljitsch van Beijnum In-Reply-To: <200305132136.GAA10051@necom830.hpcl.titech.ac.jp> Message-Id: <230584F8-8593-11D7-9519-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On dinsdag, mei 13, 2003, at 23:37 Europe/Amsterdam, Masataka Ohta wrote: > OTOH, rewriting of source locator is not so useful, though I have > no reason to forbid it. Unless the source address is already a valid address assigned by the ISP you're forwarding the packet to (which can't by definition always be the case in a locator/identifier scheme), you need to rewrite it in order to get through ingress filtering and to be able to receive ICMP messages. Remember that path MTU discovery is pretty much mandatory in IPv6 so you need those ICMPs. Ingress filtering is important to keep denial of service attacks in check to at least some degree. From owner-multi6@ops.ietf.org Tue May 13 19:34:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03996 for ; Tue, 13 May 2003 19:34:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FjJP-000Kic-00 for multi6-data@psg.com; Tue, 13 May 2003 23:35:59 +0000 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #1) id 19FjJN-000KiG-00 for multi6@ops.ietf.org; Tue, 13 May 2003 23:35:57 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 1A6C934437; Tue, 13 May 2003 15:50:21 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h4DNZnYB029627; Tue, 13 May 2003 16:35:50 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IETF multihoming powder: just add IPv6 and stir Date: Tue, 13 May 2003 16:35:49 -0700 Message-ID: Thread-Topic: IETF multihoming powder: just add IPv6 and stir Thread-Index: AcMZolLuhqIZ3f2ZRge4XMQYPdYiDwABfs8Q From: "Tony Li" To: "Iljitsch van Beijnum" , "Masataka Ohta" Cc: "J. Noel Chiappa" , X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA03996 A filter that is looking at a locator is probably a bug. Tony | On dinsdag, mei 13, 2003, at 23:37 Europe/Amsterdam, Masataka Ohta | wrote: | | > OTOH, rewriting of source locator is not so useful, though I have | > no reason to forbid it. | | Unless the source address is already a valid address | assigned by the | ISP you're forwarding the packet to (which can't by | definition always | be the case in a locator/identifier scheme), you need to | rewrite it in | order to get through ingress filtering and to be able to | receive ICMP | messages. Remember that path MTU discovery is pretty much | mandatory in | IPv6 so you need those ICMPs. Ingress filtering is | important to keep | denial of service attacks in check to at least some degree. | | | From owner-multi6@ops.ietf.org Tue May 13 20:23:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04917 for ; Tue, 13 May 2003 20:23:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Fk5v-0002ly-00 for multi6-data@psg.com; Wed, 14 May 2003 00:26:07 +0000 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.36 #1) id 19Fk5r-0002lW-00 for multi6@ops.ietf.org; Wed, 14 May 2003 00:26:03 +0000 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id KAA27029 for ; Wed, 14 May 2003 10:26:01 +1000 (EST) Date: Wed, 14 May 2003 10:26:01 +1000 (EST) From: Peter Tattam To: Multi6 Working Group Subject: taking a break Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-11.5 required=5.0 tests=BAYES_10,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk I'll be taking a rest from the MH debate for a while. I was hoping to make it to Vienna but I am embroiled in some difficult personal problems that will tie me up for at least the next year (divorce proceeedings). But before I leave the list in a day or so, I have one last thought. Is it possible to fix BGP in such a way that the burden of the DFZ is removed from the core. Aggregation meets this goal but perhaps there are other ways. Even the search for a solution may lead to the conclusion that a stateful table is mandatory for multihoming to work whatever form it takes. Regards Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From owner-multi6@ops.ietf.org Wed May 14 02:36:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07029 for ; Wed, 14 May 2003 02:36:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FptN-0008wv-00 for multi6-data@psg.com; Wed, 14 May 2003 06:37:33 +0000 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 19FptK-0008wi-00 for multi6@ops.ietf.org; Wed, 14 May 2003 06:37:30 +0000 From: Masataka Ohta Message-Id: <200305140629.PAA11598@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id PAA11598; Wed, 14 May 2003 15:29:23 +0900 Subject: Re: IETF multihoming powder: just add IPv6 and stir In-Reply-To: <230584F8-8593-11D7-9519-00039388672E@muada.com> from Iljitsch van Beijnum at "May 14, 2003 00:35:02 am" To: Iljitsch van Beijnum Date: Wed, 14 May 2003 15:29:20 +0859 () CC: "J. Noel Chiappa" , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Iljitsch; > > OTOH, rewriting of source locator is not so useful, though I have > > no reason to forbid it. > > Unless the source address is already a valid address assigned by the > ISP you're forwarding the packet to (which can't by definition always > be the case in a locator/identifier scheme), That's why I overviewed in draft-ohta-e2e-multihoming-03.txt: However, to enable source address filtering to discard packets with source addresses not belonging to an ISP, it is useful to enable a host, not some intelligent intermediate router, select a source address compatible with an outgoing ISP. For that purpose, intra domain routing protocols should maintain routing table entries with not only preference values of an external routes, but also proper prefixes to be selected for source addresses, if the entries are chosen by a host. The solutions should be end to end that complex functionality must be performed only on hosts. Hosts needs help from routing protocols. Traditionally, when only a single address was usually assigned to each interface and when hosts with multiple interfaces are routers, address of outgoing interface was the source address. However, with multiple addresses to an interface, selection of source address/locator can be performed properly only with the help from routing protocol, which is a reason why IPv6 is broken in source address selection. > you need to rewrite it in > order to get through ingress filtering and to be able to receive ICMP > messages. No. See above. > Remember that path MTU discovery is pretty much mandatory in > IPv6 so you need those ICMPs. No. PMTUD is one, among many, of a useless feature of IPv6. Worse, implementations are wrong to do it at IP layer, where there can be no proper value of timeout. Just send packets not loger than 1280B. > Ingress filtering is important to keep > denial of service attacks in check to at least some degree. Ingress? Do you mean egress? You can't filter an ICMP packet generated for a packet with forged source address, because the ICMP packet has valid source and destination addresses. Tony> A filter that is looking at a locator is probably a bug. Maybe or may not be. But, my point is that it is harmless. Or, do you, may be as a router designer, mind if some intermediate routers are required to perform egress filtering on source locators? Note that an alternative proposal is to let routers have complex packet tracing functionality. Masataka Ohta From owner-multi6@ops.ietf.org Wed May 14 03:19:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07805 for ; Wed, 14 May 2003 03:19:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FqZr-000E7I-00 for multi6-data@psg.com; Wed, 14 May 2003 07:21:27 +0000 Received: from dhcp-9-211.ripemtg.ripe.net ([193.0.9.211] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 19FqZn-000E6S-00 for multi6@ops.ietf.org; Wed, 14 May 2003 07:21:24 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h4E7NfTq014007; Wed, 14 May 2003 09:23:42 +0200 (CEST) Date: Wed, 14 May 2003 09:23:39 +0200 Subject: Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Bound, Jim" , multi6@ops.ietf.org To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On tisdag, maj 13, 2003, at 11:10 Europe/Stockholm, Iljitsch van Beijnum wrote: > On dinsdag, mei 13, 2003, at 10:11 Europe/Amsterdam, Kurt Erik > Lindqvist wrote: > >> What worries me as ex-operator is that state in a network comes at a >> cost. Normally state is actually among the most costly components of >> network design. So, I agree that I would like to avoid any stateful >> mapping. Now, that said I agree that a stateless mechanism is going >> to harder to design and implement. > > I think we should more carefully define the word "state". A BGP > routing table is state. An IPsec security association is state. An ARP > table entry is state. A TCP control block is state. A socket bound to > a UDP port is state. We use all of this (maybe with the exception of > IPsec) every day, so apparently keeping all this state is worth it. Absolutely, we do! But some of those examples cost more than others. And the total costs quite a lot. No need to add to this. > > Assume we have A and B that want to communicate, and they have C and D > sitting between them passing along the packets. There are also E - Z > who are connected to A, B, C and D but they aren't involved in this > particular communication. My position is: > > State in A and B: perfectly acceptable. Applications and transport > layer protocols keep state anyway. > > State in C and D: not good, but not entirely inconceivable. > > State in E - Z: unacceptable. > > Which part were you talking about? Just to be clear in the example above, is A, B, C, D, E-Z sites, or nodes? " My answer would say that it depends. As (I think it was) Brian pointed out, you have a problem to "distribute the state" as well. And if that state should sit in in the sending/receiving nodes or the edge nodes, or in all of the nodes of the sending/receiving sites - is a good question. And one of the questions we need to solve. My point was merely that I want to minimize state at all. We most likely will have to allow some state, but the cost of that state will depend on the protocol (type of state) and where that state is. > > And in another message you said: > >>> Also, we can't assume that users will universally prefer a stateless >>> solution with per-packet overhead over a stateful one that doesn't >>> have extra overhead. > >> I would like to argue that per-packet overhead is cheaper than >> stateful mappning. > > I'm sure this is true for you. However, I regularly connect to the net > with my laptop over GSM at 960 bytes per second costing me 11 cents > per minute, and when I do that every byte counts. If you're sitting > behind gigabit ethernet where you can do 100000 packets per second > regardless of how big they are, you'd rather throw away 10% of the > usable data in each packet than add extra processing that halves the > number of packets per second you can do. What I'm saying is that it is > impossible to determine that globally, EVERYONE will always prefer > either state or overhead. True. I made a very general comment. And it is true that there are cases where conservation of bit's would be preferred, I my self use GPRS quite a lot and then I would also like to have the cheapest option. However, this actually comes down to another issue. This is seen from the POV of the user. From the POV of the network operator, the cost of state will be higher. That cost will be taken out of the users, but it will not be as visible to the users as more bits would. > Finally, I want to warn everyone that there is a very dangerous "who > cares about the overhead" attitude in some circles. Agreed. But it's a trade-off. - kurtis - From owner-multi6@ops.ietf.org Wed May 14 03:24:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07877 for ; Wed, 14 May 2003 03:24:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FqfQ-000Em5-00 for multi6-data@psg.com; Wed, 14 May 2003 07:27:12 +0000 Received: from e6.ny.us.ibm.com ([32.97.182.106]) by psg.com with esmtp (Exim 3.36 #1) id 19FqfO-000Elr-00 for multi6@ops.ietf.org; Wed, 14 May 2003 07:27:10 +0000 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by e6.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4E7R7xr186642 for ; Wed, 14 May 2003 03:27:08 -0400 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h4E7Qxps290978 for ; Wed, 14 May 2003 09:27:06 +0200 Received: from gsine05.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA21686 from ; Wed, 14 May 2003 09:26:56 +0200 Message-Id: <3EC1EFD0.39CD4D84@hursley.ibm.com> Date: Wed, 14 May 2003 09:27:12 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: multi6@ops.ietf.org Subject: Re: IETF multihoming powder: just add IPv6 and stir References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-29.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tony Li wrote: > > A filter that is looking at a locator is probably a bug. In that case there will be many bugs. Similar issues arise for QOS classifiers (unless we get the flow label into general use). Brian > > Tony > > | On dinsdag, mei 13, 2003, at 23:37 Europe/Amsterdam, Masataka Ohta > | wrote: > | > | > OTOH, rewriting of source locator is not so useful, though I have > | > no reason to forbid it. > | > | Unless the source address is already a valid address > | assigned by the > | ISP you're forwarding the packet to (which can't by > | definition always > | be the case in a locator/identifier scheme), you need to > | rewrite it in > | order to get through ingress filtering and to be able to > | receive ICMP > | messages. Remember that path MTU discovery is pretty much > | mandatory in > | IPv6 so you need those ICMPs. Ingress filtering is > | important to keep > | denial of service attacks in check to at least some degree. From owner-multi6@ops.ietf.org Wed May 14 03:29:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08136 for ; Wed, 14 May 2003 03:29:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FqkM-000FRM-00 for multi6-data@psg.com; Wed, 14 May 2003 07:32:18 +0000 Received: from dhcp-9-211.ripemtg.ripe.net ([193.0.9.211] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 19FqkI-000FPX-00 for multi6@ops.ietf.org; Wed, 14 May 2003 07:32:15 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h4E7YaTq014014; Wed, 14 May 2003 09:34:37 +0200 (CEST) Date: Wed, 14 May 2003 09:34:33 +0200 Subject: Re: Mutli6 meeting in Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Coene Lode , "Bound, Jim" , multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200305131450.XAA09092@necom830.hpcl.titech.ac.jp> Message-Id: <81C74524-85DE-11D7-BDC5-000393520ED8@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-16.1 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>>> >>>> I am still also open to input on the agenda and the structure of the >>>> meeting. From the past weeks discussions here I would assume >>>> that "GSE" >>>> will be a large topic, > > GSE is not a proper name of any topic. ...which is why I put it in quotes. >>>> but we would need something to discuss around. >>>> We also have Pekkas draft and we have the option to have someone go >>>> through the options brought to the IETF so far (I was going >>>> through the >>>> ID archives but I could't find much more than my drafts, Iljitsch, >>>> Tonys and Michels expired drafts. Then we also have HIP. Have >>>> I missed >>>> something?). Opinions? > > You miss LIN6. What is the draft name? I can't seem to find this. > >>> There are folks out that can do multihoming already(via SCTP using >>> multiple >>> addresses) >>> I can present something on that(if you don't mind). >> >> Again, there are a number of proposals and I am sure that everyone >> would like to present, but I don't think we can fit them all in. My >> reason for asking was to make sure that we have an overview solution >> that covers them all. > > "The Architecture of End to End Multihoming" > has been giving an overview > on so-called host based solutions in a way not specific to LIN6 > before the WG was created. > > Thus, I'd like to have a chance of presentation. > As I said yesterday, we will not have time at this meeting for all the proposals to present. Instead we will try and have an overview of solution classes. Most work seems to be done with loc/id separation and Christians host-based solutions. For the time being this is where I think we should spend time at the meeting. We might want to spend more time on other solutions at the next meeting. Unfortunately we have some catching up to do and having all proposals presented would take up very much time, without us moving on. Even then what to do in order to forward would not be clear. Therefor discussing the solution classes seems as a good compromise to me. Then looking at the (from my POV) two mostly supported proposals and try to iron them out a bit seems feasible. Me and Sean are discussing exactly how to do this. - kurtis - From owner-multi6@ops.ietf.org Wed May 14 04:05:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08942 for ; Wed, 14 May 2003 04:05:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FrIH-000JfH-00 for multi6-data@psg.com; Wed, 14 May 2003 08:07:21 +0000 Received: from [3ffe:501:100c:d120::53] (helo=shonan.sfc.wide.ad.jp) by psg.com with esmtp (Exim 3.36 #1) id 19FrIF-000Je4-00 for multi6@ops.ietf.org; Wed, 14 May 2003 08:07:19 +0000 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 0B9B55D0A1; Wed, 14 May 2003 17:06:48 +0900 (JST) Date: Wed, 14 May 2003 17:04:33 +0900 From: Thierry Ernst To: multi6@ops.ietf.org Cc: Kurt Erik Lindqvist Subject: Re: Mutli6 meeting in Vienna Message-Id: <20030514170433.31b7287c.ernst@sfc.wide.ad.jp> In-Reply-To: <81C74524-85DE-11D7-BDC5-000393520ED8@kurtis.pp.se> References: <200305131450.XAA09092@necom830.hpcl.titech.ac.jp> <81C74524-85DE-11D7-BDC5-000393520ED8@kurtis.pp.se> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-16.9 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTE_TWICE_1,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, > > You miss LIN6. > > What is the draft name? I can't seem to find this. On LIN6 documentation, including the draft available on http://www.lin6.net/index.html The LIN6 draft was presented in 2001 in Mobile IP WG and IPv6 WG, but probably too late at the end of the meeting to receive the interest it deserves. There are many people still working on it, having actual implementations, etc. By the way, some NEMO folks are working on a multihoming taxonomy draft that you would find interest in, since site-multihoming is one feature that would be particularly useful for NEMO. Actually, this is the reason why Friday I posted an email to this list, enquiring about your current definition of site-multihoming, but no reply. The answer to the question is not clear while reading the charter AND the draft: it's not consitent. I need this question because I would like to know if, say, a mobile network deployed in a vehicle can be considered a "site". Thierry From owner-multi6@ops.ietf.org Wed May 14 04:05:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08957 for ; Wed, 14 May 2003 04:05:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FrIf-000Jfp-00 for multi6-data@psg.com; Wed, 14 May 2003 08:07:45 +0000 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 19FrId-000Jfd-00 for multi6@ops.ietf.org; Wed, 14 May 2003 08:07:43 +0000 From: Masataka Ohta Message-Id: <200305140753.QAA11898@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id QAA11898; Wed, 14 May 2003 16:53:07 +0900 Subject: Re: Mutli6 meeting in Vienna In-Reply-To: <81C74524-85DE-11D7-BDC5-000393520ED8@kurtis.pp.se> from Kurt Erik Lindqvist at "May 14, 2003 09:34:33 am" To: Kurt Erik Lindqvist Date: Wed, 14 May 2003 16:53:07 +0859 () CC: Coene Lode , "Bound, Jim" , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurt; > >>>> but we would need something to discuss around. > >>>> We also have Pekkas draft and we have the option to have someone go > >>>> through the options brought to the IETF so far (I was going > >>>> through the > >>>> ID archives but I could't find much more than my drafts, Iljitsch, > >>>> Tonys and Michels expired drafts. Then we also have HIP. Have > >>>> I missed > >>>> something?). Opinions? > > > > You miss LIN6. > > What is the draft name? I can't seem to find this. I will prepare it, if there is a chance for presentation. > > "The Architecture of End to End Multihoming" > > has been giving an overview > > on so-called host based solutions in a way not specific to LIN6 > > before the WG was created. > > > > Thus, I'd like to have a chance of presentation. > > > > As I said yesterday, we will not have time at this meeting for all the > proposals to present. Are you saying that you have tried to request 3 slots and denied by IESG? Or, are you just saying you are not so sure? > Instead we will try and have an overview of > solution classes. That's why I'm asking for presentation of the overview on end to end multihoming. > Most work seems to be done with loc/id separation and > Christians host-based solutions. For the time being this is where I > think we should spend time at the meeting. We might want to spend more > time on other solutions at the next meeting. > > Unfortunately we have some catching up to do and having all proposals > presented would take up very much time, without us moving on. Even then > what to do in order to forward would not be clear. Therefor discussing > the solution classes seems as a good compromise to me. Then looking at > the (from my POV) two mostly supported proposals and try to iron them > out a bit seems feasible. Me and Sean are discussing exactly how to do > this. What do you want to discuss on solution classes? Isn't it already obvious that the only solution class is host-based one with loc/id separation? Masataka Ohta From owner-multi6@ops.ietf.org Wed May 14 04:11:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09081 for ; Wed, 14 May 2003 04:11:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FrOx-000KML-00 for multi6-data@psg.com; Wed, 14 May 2003 08:14:15 +0000 Received: from dhcp-9-211.ripemtg.ripe.net ([193.0.9.211] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 19FrOt-000KM1-00 for multi6@ops.ietf.org; Wed, 14 May 2003 08:14:11 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h4E8GZTq014035; Wed, 14 May 2003 10:16:36 +0200 (CEST) Date: Wed, 14 May 2003 10:16:33 +0200 Subject: Re: Mutli6 meeting in Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Coene Lode , "Bound, Jim" , multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200305140753.QAA11898@necom830.hpcl.titech.ac.jp> Message-Id: <5FE3B449-85E4-11D7-BDC5-000393520ED8@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-16.1 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>>>>> but we would need something to discuss around. >>>>>> We also have Pekkas draft and we have the option to have someone >>>>>> go >>>>>> through the options brought to the IETF so far (I was going >>>>>> through the >>>>>> ID archives but I could't find much more than my drafts, Iljitsch, >>>>>> Tonys and Michels expired drafts. Then we also have HIP. Have >>>>>> I missed >>>>>> something?). Opinions? >>> >>> You miss LIN6. >> >> What is the draft name? I can't seem to find this. > > I will prepare it, if there is a chance for presentation. I got the draft mail to me in private. Reading to it quickly I noticed that parts of this solution is actually pending patent? > >>> "The Architecture of End to End Multihoming" >>> has been giving an overview >>> on so-called host based solutions in a way not specific to LIN6 >>> before the WG was created. >>> >>> Thus, I'd like to have a chance of presentation. >>> >> >> As I said yesterday, we will not have time at this meeting for all the >> proposals to present. > > Are you saying that you have tried to request 3 slots and denied by > IESG? > > Or, are you just saying you are not so sure? I am saying that I do not think it would be useful for us to request three slots. I don't think that will move us forward. >> Instead we will try and have an overview of >> solution classes. > > That's why I'm asking for presentation of the overview on end to > end multihoming. I think we are looking at one single presentation listing the solution classes. Pekka have volunteered to make such a presentation and we will most likely take him up on this offer. >> Most work seems to be done with loc/id separation and >> Christians host-based solutions. For the time being this is where I >> think we should spend time at the meeting. We might want to spend more >> time on other solutions at the next meeting. >> >> Unfortunately we have some catching up to do and having all proposals >> presented would take up very much time, without us moving on. Even >> then >> what to do in order to forward would not be clear. Therefor discussing >> the solution classes seems as a good compromise to me. Then looking at >> the (from my POV) two mostly supported proposals and try to iron them >> out a bit seems feasible. Me and Sean are discussing exactly how to do >> this. > > What do you want to discuss on solution classes? Isn't it already > obvious that the only solution class is host-based one with loc/id > separation? > I said I wanted an overview. If that means discussion or not remains to be seen. I would personally be happier if not. I don't think that there is a clear view on host based solutions vs loc/id and I am definitely not sure that host-based with loc/id is obvious. But that is why we are having this discussion. - kurtis - From owner-multi6@ops.ietf.org Wed May 14 04:16:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09147 for ; Wed, 14 May 2003 04:16:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FrTT-000L1G-00 for multi6-data@psg.com; Wed, 14 May 2003 08:18:55 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19FrTR-000L0x-00 for multi6@ops.ietf.org; Wed, 14 May 2003 08:18:53 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h4E8HVn32503; Wed, 14 May 2003 10:17:31 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 14 May 2003 10:17:35 +0200 Subject: Re: IETF multihoming powder: just add IPv6 and stir Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: "Tony Li" From: Iljitsch van Beijnum In-Reply-To: Message-Id: <84A4E25A-85E4-11D7-9519-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-19.4 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On woensdag, mei 14, 2003, at 01:35 Europe/Amsterdam, Tony Li wrote: > A filter that is looking at a locator is probably a bug. The need to filter is an operational reality. So how do we filter on an identifier? Put them into the routing tables and then uRPF? And if the identifiers are in the routing tables, who needs a locator? To me, identifiers belong at layer 4 and up. Locators belong at layer 3. So any filtering on layer 3 must be on locators. From owner-multi6@ops.ietf.org Wed May 14 04:17:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09178 for ; Wed, 14 May 2003 04:17:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FrV0-000LCE-00 for multi6-data@psg.com; Wed, 14 May 2003 08:20:30 +0000 Received: from dhcp-9-211.ripemtg.ripe.net ([193.0.9.211] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 19FrUx-000LBz-00 for multi6@ops.ietf.org; Wed, 14 May 2003 08:20:28 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h4E8MvTq014042; Wed, 14 May 2003 10:22:58 +0200 (CEST) Date: Wed, 14 May 2003 10:22:55 +0200 Subject: Re: Mutli6 meeting in Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Thierry Ernst From: Kurt Erik Lindqvist In-Reply-To: <20030514170433.31b7287c.ernst@sfc.wide.ad.jp> Message-Id: <433CF35E-85E5-11D7-BDC5-000393520ED8@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-16.7 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > By the way, some NEMO folks are working on a multihoming taxonomy draft > that you would find interest in, since site-multihoming is one feature > that would be particularly useful for NEMO. > > Actually, this is the reason why Friday I posted an email to this list, > enquiring about your current definition of site-multihoming, but no > reply. The answer to the question is not clear while reading the > charter > AND the draft: it's not consitent. > > I need this question because I would like to know if, say, a mobile > network deployed in a vehicle can be considered a "site". > I think the charter is pretty clear "A multihomed site is a site that has more than one connection to the public internet with those connections through either the same or different ISPs." The draft says "A "multihomed" site is one with more than one transit provider. "Site-multihoming" is the practice of arranging a site to be multihomed.". I don't see a conflict between these two and I would say that the answer to your question is yes? - kurtis - From owner-multi6@ops.ietf.org Wed May 14 04:35:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09419 for ; Wed, 14 May 2003 04:35:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FrlZ-000NGy-00 for multi6-data@psg.com; Wed, 14 May 2003 08:37:37 +0000 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 19FrlX-000NER-00 for multi6@ops.ietf.org; Wed, 14 May 2003 08:37:35 +0000 From: Masataka Ohta Message-Id: <200305140824.RAA12115@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id RAA12115; Wed, 14 May 2003 17:24:23 +0900 Subject: Re: Mutli6 meeting in Vienna In-Reply-To: <5FE3B449-85E4-11D7-BDC5-000393520ED8@kurtis.pp.se> from Kurt Erik Lindqvist at "May 14, 2003 10:16:33 am" To: Kurt Erik Lindqvist Date: Wed, 14 May 2003 17:24:23 +0859 () CC: Coene Lode , "Bound, Jim" , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurt; > >> As I said yesterday, we will not have time at this meeting for all the > >> proposals to present. > > > > Are you saying that you have tried to request 3 slots and denied by > > IESG? > > > > Or, are you just saying you are not so sure? > > I am saying that I do not think it would be useful for us to request > three slots. I don't think that will move us forward. You mean you shall not have time. I don't think it a good management of WG. > > That's why I'm asking for presentation of the overview on end to > > end multihoming. > > I think we are looking at one single presentation listing the solution > classes. Pekka have volunteered to make such a presentation and we will > most likely take him up on this offer. Having presentation by Pekka, you will get view of Pekka, but nothing more than that, which is not so productive. > > What do you want to discuss on solution classes? Isn't it already > > obvious that the only solution class is host-based one with loc/id > > separation? > > I said I wanted an overview. If that means discussion or not remains to > be seen. I would personally be happier if not. > > I don't think that there is a clear view on host based solutions vs > loc/id and I am definitely not sure that host-based with loc/id is > obvious. But that is why we are having this discussion. That is not a productive way of discussion. Discussion on solution classes, if any, should be more abstact and should not be based on specific proposals. Overview on specific proposals is a different topic. Masataka Ohta From owner-multi6@ops.ietf.org Wed May 14 04:41:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09508 for ; Wed, 14 May 2003 04:41:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Frs5-000NlD-00 for multi6-data@psg.com; Wed, 14 May 2003 08:44:21 +0000 Received: from [3ffe:501:100c:d120::53] (helo=shonan.sfc.wide.ad.jp) by psg.com with esmtp (Exim 3.36 #1) id 19Frs1-000Nga-00 for multi6@ops.ietf.org; Wed, 14 May 2003 08:44:17 +0000 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 88DC25D114; Wed, 14 May 2003 17:43:46 +0900 (JST) Date: Wed, 14 May 2003 17:41:31 +0900 From: Thierry Ernst To: Kurt Erik Lindqvist Cc: multi6@ops.ietf.org Subject: Re: Mutli6 meeting in Vienna Message-Id: <20030514174131.393f6a6b.ernst@sfc.wide.ad.jp> In-Reply-To: <433CF35E-85E5-11D7-BDC5-000393520ED8@kurtis.pp.se> References: <20030514170433.31b7287c.ernst@sfc.wide.ad.jp> <433CF35E-85E5-11D7-BDC5-000393520ED8@kurtis.pp.se> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-26.6 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Kurt, Thanks for the answer. More below. > I think the charter is pretty clear "A multihomed site is a site that > has more than one connection to the > public internet with those connections through either the same or > different ISPs." > > The draft says "A "multihomed" site is one with more than one transit > provider. "Site-multihoming" is the practice of arranging a site to be > multihomed.". > > I don't see a conflict between these two OK, my concern was about the Charter saying "either the same or different ISPs" while the draft says "more than one ISP". This sounds conflicting to me and I don't know how many prefixes my site-multihomed network is supposed to have. > > I need this question because I would like to know if, say, a mobile > > network deployed in a vehicle can be considered a "site". > > > and I would say that the answer to your question is yes? Well, that first depends on the first question (same ISPs or not) and then I would like to know where my prefix(es) come from. Is there any restriction on the length of the prefix for a network to be considered site-multihomed ? Thanks, Thierry From owner-multi6@ops.ietf.org Wed May 14 05:00:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09883 for ; Wed, 14 May 2003 05:00:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FsAL-000PLv-00 for multi6-data@psg.com; Wed, 14 May 2003 09:03:13 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19FsAI-000PLh-00 for multi6@ops.ietf.org; Wed, 14 May 2003 09:03:10 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h4E91nn32589; Wed, 14 May 2003 11:01:49 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 14 May 2003 11:01:53 +0200 Subject: Re: IETF multihoming powder: just add IPv6 and stir Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Masataka Ohta From: Iljitsch van Beijnum In-Reply-To: <200305140629.PAA11598@necom830.hpcl.titech.ac.jp> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On woensdag, mei 14, 2003, at 08:30 Europe/Amsterdam, Masataka Ohta wrote: >> Unless the source address is already a valid address assigned by the >> ISP you're forwarding the packet to (which can't by definition always >> be the case in a locator/identifier scheme), > That's why I overviewed in draft-ohta-e2e-multihoming-03.txt: > However, to enable source address filtering to discard packets with > source addresses not belonging to an ISP, it is useful to enable a > host, not some intelligent intermediate router, select a source > address compatible with an outgoing ISP. Does it really matter who does it? This should be something we leave up to the implementers, if at all possible. However, if you want to get this deployed while the century is still young you'll have to make the hosts do it if the routers can't. > For that purpose, intra > domain routing protocols should maintain routing table entries with > not only preference values of an external routes, but also proper > prefixes to be selected for source addresses, if the entries are > chosen by a host. No way. First of all having a routing table in each host is a huge waste of resources. Second, why use fifth hand information if a host can simply send some packets and see if they make it through? That's much more effective and light-weight at the expense of some only a few otherwise unnecessary end-to-end packets. Routing protocols seldom know which paths are good. They barely know how to avoid the very bad and non-functioning ones. > The solutions should be end to end that complex functionality must > be performed only on hosts. I agree in principle. However, if we can give people the option to offload this to a middlebox if they so desire, that's a plus. (Which is a very different thing from requiring middleboxes or requiring routers or other non-middlebox boxes in the middle to do it.) > Hosts needs help from routing protocols. That's the same logic as suing a lawyer. At the surface it seems to make sense but you really don't want to do it if you can avoid it. > However, with multiple addresses to an interface, selection of source > address/locator can be performed properly only with the help from > routing protocol, which is a reason why IPv6 is broken in > source address selection. The trouble with current transport protocols is that once you've selected your source address you can't change it. So we change it and then listen for ICMP messages to see when we have the wrong source address. Or you can turn the whole thing around and decide if the host is going to use a source address that belongs to ISP A, well, then we have to send this packet out over ISP A. That way we don't even need routing tables in routers. :-) >> you need to rewrite it in >> order to get through ingress filtering and to be able to receive ICMP >> messages. > No. See above. Note that I was taking no position about where the rewriting happens: this may very well be done inside the source host. >> Remember that path MTU discovery is pretty much mandatory in >> IPv6 so you need those ICMPs. > No. PMTUD is one, among many, of a useless feature of IPv6. Why is it useless? > Just send packets not loger than 1280B. That's unacceptable. In fact, we need to go even further and implement functionality in neighbor discovery to enable the use of jumboframes between two hosts that support them even though other hosts on the same subnet may not. >> Ingress filtering is important to keep >> denial of service attacks in check to at least some degree. > Ingress? Do you mean egress? No. I can't trust my neighbors to send me only good packets, so I have to make sure this is the case myself. > You can't filter an ICMP packet generated for a packet with forged > source address, because the ICMP packet has valid source and > destination addresses. That's why we must filter the original packet with the forged source address. Then there is no trouble with ICMP messages generated for it. > Note that an alternative proposal is to let routers have complex > packet tracing functionality. I assume you mean tracing forged sources? This done for only very few packets so it doesn't get in the way of regular operation. From owner-multi6@ops.ietf.org Wed May 14 05:02:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09944 for ; Wed, 14 May 2003 05:02:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FsCr-000Ph5-00 for multi6-data@psg.com; Wed, 14 May 2003 09:05:49 +0000 Received: from dhcp-9-211.ripemtg.ripe.net ([193.0.9.211] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 19FsCo-000Pgq-00 for multi6@ops.ietf.org; Wed, 14 May 2003 09:05:47 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h4E98ATq014058; Wed, 14 May 2003 11:08:11 +0200 (CEST) Date: Wed, 14 May 2003 11:08:09 +0200 Subject: Re: Mutli6 meeting in Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Coene Lode , "Bound, Jim" , multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200305140824.RAA12115@necom830.hpcl.titech.ac.jp> Message-Id: <94DC0456-85EB-11D7-BDC5-000393520ED8@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-16.1 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> Are you saying that you have tried to request 3 slots and denied by >>> IESG? >>> >>> Or, are you just saying you are not so sure? >> >> I am saying that I do not think it would be useful for us to request >> three slots. I don't think that will move us forward. > > You mean you shall not have time. > > I don't think it a good management of WG. I am worried that we would spend large amount of time in our first meeting for a long time going through proposals, without a clear picture of where this would lead us. From what I can see there are very few proposals that have any broader support. HOWEVER, Randy and Sean have an idea of a different way we can do the meeting and perhaps achieve what you want as well as try and get something useful out of it. I will try and write this up during the day. > >>> That's why I'm asking for presentation of the overview on end to >>> end multihoming. >> >> I think we are looking at one single presentation listing the solution >> classes. Pekka have volunteered to make such a presentation and we >> will >> most likely take him up on this offer. > > Having presentation by Pekka, you will get view of Pekka, but nothing > more than that, which is not so productive. Well, I was not going to ask him to present his views of the proposals. Rather a summary of the classes of solutions we see. Without any comments on the solutions as such. That is also what I understood that he was willing to do. >>> What do you want to discuss on solution classes? Isn't it already >>> obvious that the only solution class is host-based one with loc/id >>> separation? >> >> I said I wanted an overview. If that means discussion or not remains >> to >> be seen. I would personally be happier if not. >> >> I don't think that there is a clear view on host based solutions vs >> loc/id and I am definitely not sure that host-based with loc/id is >> obvious. But that is why we are having this discussion. > > That is not a productive way of discussion. > > Discussion on solution classes, if any, should be more abstact > and should not be based on specific proposals. > > Overview on specific proposals is a different topic. > That is why I wanted this split in to parts. One to give the overview (abstracts if you want) of the classes of solutions, one part on the proposals that appears to have the widest support. But I will try and write up the alternative idea during the day. - kurtis - From owner-multi6@ops.ietf.org Wed May 14 05:06:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09990 for ; Wed, 14 May 2003 05:06:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FsFO-000PpI-00 for multi6-data@psg.com; Wed, 14 May 2003 09:08:26 +0000 Received: from dhcp-9-211.ripemtg.ripe.net ([193.0.9.211] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 19FsFL-000Poq-00 for multi6@ops.ietf.org; Wed, 14 May 2003 09:08:23 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h4E9AiTq014061; Wed, 14 May 2003 11:10:54 +0200 (CEST) Date: Wed, 14 May 2003 11:10:42 +0200 Subject: Re: Mutli6 meeting in Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Thierry Ernst From: Kurt Erik Lindqvist In-Reply-To: <20030514174131.393f6a6b.ernst@sfc.wide.ad.jp> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On onsdag, maj 14, 2003, at 10:41 Europe/Stockholm, Thierry Ernst wrote: > Hi Kurt, > > Thanks for the answer. More below. > >> I think the charter is pretty clear "A multihomed site is a site that >> has more than one connection to the >> public internet with those connections through either the same or >> different ISPs." >> >> The draft says "A "multihomed" site is one with more than one transit >> provider. "Site-multihoming" is the practice of arranging a site to be >> multihomed.". >> >> I don't see a conflict between these two > > OK, my concern was about the Charter saying "either the same or > different ISPs" while the draft says "more than one ISP". > > This sounds conflicting to me and I don't know how many prefixes my > site-multihomed network is supposed to have. Ok, I see your point. Personally I would think the charter is more correct for the normal use of the term "multihoming" but for the problem we are looking at, I would say that the draft is more accurate. >>> I need this question because I would like to know if, say, a mobile >>> network deployed in a vehicle can be considered a "site". >>> >> and I would say that the answer to your question is yes? > > Well, that first depends on the first question (same ISPs or not) and > then I would like to know where my prefix(es) come from. > > Is there any restriction on the length of the prefix for a network to > be > considered site-multihomed ? The answer to both of your questions depend on what suggested solution your are looking at. - kurtis - From owner-multi6@ops.ietf.org Wed May 14 05:21:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10151 for ; Wed, 14 May 2003 05:21:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FsUX-000145-00 for multi6-data@psg.com; Wed, 14 May 2003 09:24:05 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19FsUV-00013s-00 for multi6@ops.ietf.org; Wed, 14 May 2003 09:24:03 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h4E9Mgn32631; Wed, 14 May 2003 11:22:42 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 14 May 2003 11:22:44 +0200 Subject: Re: Mutli6 meeting in Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Kurt Erik Lindqvist From: Iljitsch van Beijnum In-Reply-To: <81C74524-85DE-11D7-BDC5-000393520ED8@kurtis.pp.se> Message-Id: <9ED0F50A-85ED-11D7-9519-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On woensdag, mei 14, 2003, at 09:34 Europe/Amsterdam, Kurt Erik Lindqvist wrote: >> "The Architecture of End to End Multihoming" >> has been giving an overview >> on so-called host based solutions in a way not specific to LIN6 >> before the WG was created. >> Thus, I'd like to have a chance of presentation. > As I said yesterday, we will not have time at this meeting for all the > proposals to present. Note that the above isn't so much a proposal as discussion with some conclusions about what a solution should look like. > Instead we will try and have an overview of solution classes. Most > work seems to be done with loc/id separation and Christians host-based > solutions. For the time being this is where I think we should spend > time at the meeting. I've been trying to come up with a useful approach for this for a while. We really have to get this right because if this turns out to be a huge shouting match or nap time, it's the end of multi6. How about this: if everyone says what proposals they feel are worth working on. Then we can discuss those proposals. It seems likely the proposals that many people want to work on have some promise. I think this is a good way to get around "this proposal sucks" "no it's great" type of discussions. The other advantage is that it limits the number of "active" proposals significantly. For instance, my geo stuff doesn't require work but simply adoption :-) so there is no need to go over it. Mobility and HIP have their home elsewhere, so those don't have to be discussed either, apart from maybe send an annotated copy of the requirements to those groups to make this stuff work well with multihoming. So that leaves the whole locator/identifier thing. A few questions about that: - on what layer do we want to do this? - can we break applications? - can we break transport protocols? - can we break autoconfiguration? - can we break IP? - can we break IPsec? - if we can't break something, what are the alternatives? - where can we add state? - can it be done without state? - do we need a discovery protocol? - do we need a negotiation protocol? > Unfortunately we have some catching up to do and having all proposals > presented would take up very much time, without us moving on. Everyone should read the drafts. From owner-multi6@ops.ietf.org Wed May 14 06:04:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10915 for ; Wed, 14 May 2003 06:04:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Ft9r-0004Ry-00 for multi6-data@psg.com; Wed, 14 May 2003 10:06:47 +0000 Received: from dhcp-9-211.ripemtg.ripe.net ([193.0.9.211] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 19Ft9e-0004MJ-00 for multi6@ops.ietf.org; Wed, 14 May 2003 10:06:34 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h4EA8wTq014084; Wed, 14 May 2003 12:08:59 +0200 (CEST) Date: Wed, 14 May 2003 12:08:54 +0200 Subject: Re: Mutli6 meeting in Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <9ED0F50A-85ED-11D7-9519-00039388672E@muada.com> Message-Id: <11EA153F-85F4-11D7-BDC5-000393520ED8@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-16.7 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> Instead we will try and have an overview of solution classes. Most >> work seems to be done with loc/id separation and Christians >> host-based solutions. For the time being this is where I think we >> should spend time at the meeting. > > I've been trying to come up with a useful approach for this for a > while. We really have to get this right because if this turns out to > be a huge shouting match or nap time, it's the end of multi6. I think that we will need some discussions (I don't like shouting). I to some extent think that is unavoidable with the number of proposals out there. However, after the discussions we also need to decide on the way forward. > How about this: if everyone says what proposals they feel are worth > working on. Then we can discuss those proposals. It seems likely the > proposals that many people want to work on have some promise. I think > this is a good way to get around "this proposal sucks" "no it's great" > type of discussions. The other advantage is that it limits the number > of "active" proposals significantly. For instance, my geo stuff > doesn't require work but simply adoption :-) so there is no need to > go over it. Ok, stay tuned for suggested agenda to come. > Mobility and HIP have their home elsewhere, so those don't have to be > discussed either, apart from maybe send an annotated copy of the > requirements to those groups to make this stuff work well with > multihoming. Agreed. > So that leaves the whole locator/identifier thing. A few questions > about that: My views > > - on what layer do we want to do this? IP > - can we break applications? if break=modify, we might be forced to. > - can we break transport protocols? see previous. > - can we break autoconfiguration? yes. > - can we break IP? yes > - can we break IPsec? isn't that transport? > - where can we add state? As little as possible. > - can it be done without state? Remains to be seen. > - do we need a discovery protocol? Discovery of? > - do we need a negotiation protocol? Negotiation of what? > >> Unfortunately we have some catching up to do and having all proposals >> presented would take up very much time, without us moving on. > > Everyone should read the drafts. First they need to be submitted..:-) - kurtis - From owner-multi6@ops.ietf.org Wed May 14 06:52:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12057 for ; Wed, 14 May 2003 06:52:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Fttt-000BMB-00 for multi6-data@psg.com; Wed, 14 May 2003 10:54:21 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19Fttr-000BLt-00 for multi6@ops.ietf.org; Wed, 14 May 2003 10:54:19 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4EAsAQ29472; Wed, 14 May 2003 13:54:11 +0300 Date: Wed, 14 May 2003 13:54:10 +0300 (EEST) From: Pekka Savola To: Thierry Ernst cc: Kurt Erik Lindqvist , Subject: Re: Mutli6 meeting in Vienna In-Reply-To: <20030514174131.393f6a6b.ernst@sfc.wide.ad.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 14 May 2003, Thierry Ernst wrote: > Thanks for the answer. More below. > > I think the charter is pretty clear "A multihomed site is a site that > > has more than one connection to the > > public internet with those connections through either the same or > > different ISPs." > > > > The draft says "A "multihomed" site is one with more than one transit > > provider. "Site-multihoming" is the practice of arranging a site to be > > multihomed.". > > > > I don't see a conflict between these two > > OK, my concern was about the Charter saying "either the same or > different ISPs" while the draft says "more than one ISP". > > This sounds conflicting to me and I don't know how many prefixes my > site-multihomed network is supposed to have. > > > > I need this question because I would like to know if, say, a mobile > > > network deployed in a vehicle can be considered a "site". > > > > > and I would say that the answer to your question is yes? > > Well, that first depends on the first question (same ISPs or not) and > then I would like to know where my prefix(es) come from. > > Is there any restriction on the length of the prefix for a network to be > considered site-multihomed ? "Site multihoming" to one provider (called site multiconnecting in the v4 draft) is basically a no-brainer, AFAIK. Is there something here which leads you to believe we need to work on this? We could push multi-connecting as a solution/workaround for some use cases though. IMO, that makes perfect sense to me, but at the same time, it cannot meet *all* the sites' needs, so we need something else too. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Wed May 14 06:56:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12155 for ; Wed, 14 May 2003 06:56:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Ftyr-000CAt-00 for multi6-data@psg.com; Wed, 14 May 2003 10:59:29 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19Ftyp-000CAe-00 for multi6@ops.ietf.org; Wed, 14 May 2003 10:59:27 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4EAvsD29490; Wed, 14 May 2003 13:57:54 +0300 Date: Wed, 14 May 2003 13:57:54 +0300 (EEST) From: Pekka Savola To: Kurt Erik Lindqvist cc: Masataka Ohta , Coene Lode , "Bound, Jim" , Subject: Re: Mutli6 meeting in Vienna In-Reply-To: <94DC0456-85EB-11D7-BDC5-000393520ED8@kurtis.pp.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 14 May 2003, Kurt Erik Lindqvist wrote: > >>> Are you saying that you have tried to request 3 slots and denied by > >>> IESG? > >>> > >>> Or, are you just saying you are not so sure? > >> > >> I am saying that I do not think it would be useful for us to request > >> three slots. I don't think that will move us forward. > > > > You mean you shall not have time. > > > > I don't think it a good management of WG. > > I am worried that we would spend large amount of time in our first > meeting for a long time going through proposals, without a clear > picture of where this would lead us. From what I can see there are very > few proposals that have any broader support. I totally support this approach -- everyone presenting their own proposals (mine included :-) -- does NOT seem like the good management at this time, regardless of the time it would or would not take. > > Having presentation by Pekka, you will get view of Pekka, but nothing > > more than that, which is not so productive. > > Well, I was not going to ask him to present his views of the proposals. > Rather a summary of the classes of solutions we see. Without any > comments on the solutions as such. That is also what I understood that > he was willing to do. Agree. Even though I have my own preferences to the proposals, I don't think this would be the right place to push them. (And if there is something, I'd circulate it among the folks whose proposals are affected to be able to comment if they feel something is being misrepresented.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Wed May 14 07:03:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12277 for ; Wed, 14 May 2003 07:03:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Fu4u-000DDB-00 for multi6-data@psg.com; Wed, 14 May 2003 11:05:44 +0000 Received: from server.ripemtg.ripe.net ([193.0.8.2]) by psg.com with esmtp (Exim 3.36 #1) id 19Fu4r-000DCy-00 for multi6@ops.ietf.org; Wed, 14 May 2003 11:05:41 +0000 Received: from [193.0.8.247] (marcelo@[193.0.8.247]) by server.ripemtg.ripe.net (8.12.9/8.12.6) with ESMTP id h4EB5bwV025328; Wed, 14 May 2003 13:05:37 +0200 Subject: RE: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] From: marcelo bagnulo To: Christian Huitema Cc: Iljitsch van Beijnum , multi6@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Organization: uc3m Message-Id: <1052910249.785.9.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 14 May 2003 13:04:09 +0200 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Christian, On Tue, 2003-05-13 at 17:26, Christian Huitema wrote: > > >> But I think we should revisit this when there is an actual proposal > > >> that adds extra headers to packets because only then we'll be able > to > > >> see how this helps us and how it hurts us. > > > > > Well, using MIPv6 could be one of such proposals (there are some > issues > > > to solve) but still can be useful to quantify the amount of overhead > > > involved. > > > > Mobile IP in IPv6 uses a 24 byte header to carry the original source > > address, right? > > It does, but it only needs to do so when negotiating a binding update. > The trick is to design a usage model of MIPv6 in which binding updates > are used to redirect a TCP connection (or a UDP flow) to a new address. > IMHO, it would be interesting to use the MIPv6 protocol in such a way that changes are imposed to the CNs are as few as possible (Changing Mobile Nodes behaviour, assuming that this role will be assumed by hosts within the multi-homed site is acceptable). So considering that MIPv6 already provides connection survivability throughout network access point changes, it is would be interesting to evaluate if it can be adapted to support multi-homing. So, i would say that a MIPv6 based solution for multi-homing can be evaluated considering the changes it imposes to CN. However, from your comments above, i would say that you are considering more substantial changes in the CN behaviour, perhaps you could expand on this? Thanks, marcelo > -- Christian Huitema -- marcelo bagnulo uc3m From owner-multi6@ops.ietf.org Wed May 14 07:35:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13157 for ; Wed, 14 May 2003 07:35:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FuZv-000I4B-00 for multi6-data@psg.com; Wed, 14 May 2003 11:37:47 +0000 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 19FuZs-000I3e-00 for multi6@ops.ietf.org; Wed, 14 May 2003 11:37:45 +0000 From: Masataka Ohta Message-Id: <200305141128.UAA13332@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id UAA13332; Wed, 14 May 2003 20:28:27 +0900 Subject: Re: Mutli6 meeting in Vienna In-Reply-To: <94DC0456-85EB-11D7-BDC5-000393520ED8@kurtis.pp.se> from Kurt Erik Lindqvist at "May 14, 2003 11:08:09 am" To: Kurt Erik Lindqvist Date: Wed, 14 May 2003 20:28:27 +0859 () CC: Coene Lode , "Bound, Jim" , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurt; > >>> Are you saying that you have tried to request 3 slots and denied by > >>> IESG? > >>> > >>> Or, are you just saying you are not so sure? > >> > >> I am saying that I do not think it would be useful for us to request > >> three slots. I don't think that will move us forward. > > > > You mean you shall not have time. > > > > I don't think it a good management of WG. > I am worried that we would spend large amount of time in our first > meeting for a long time going through proposals, without a clear > picture of where this would lead us. It is a job of chairs to assign appropriate amount of time for each presentation. It is a job of chairs to reserve appropriate amount of time for the wrap up discussion. > From what I can see there are very > few proposals that have any broader support. That's why we need presentations and discussions. We shouldn't expect Pekka can draw a clear picture to lead us. > > Having presentation by Pekka, you will get view of Pekka, but nothing > > more than that, which is not so productive. > > Well, I was not going to ask him to present his views of the proposals. > Rather a summary of the classes of solutions we see. Without any > comments on the solutions as such. That is also what I understood that > he was willing to do. It's Pekka's view of classification. > > Discussion on solution classes, if any, should be more abstact > > and should not be based on specific proposals. > > > > Overview on specific proposals is a different topic. > > > > That is why I wanted this split in to parts. One to give the overview > (abstracts if you want) of the classes of solutions, one part on the > proposals that appears to have the widest support. You are saying to select proposals that appears to have the widest support based on the Pekka's view of classification. That's not fair. Worse, a good class can contain poor solutions that classes and solutions are rather orthogonal. Masataka Ohta From owner-multi6@ops.ietf.org Wed May 14 08:50:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16030 for ; Wed, 14 May 2003 08:50:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Fvk0-0003el-00 for multi6-data@psg.com; Wed, 14 May 2003 12:52:16 +0000 Received: from pa-monroeville1d-140.pit.adelphia.net ([24.50.190.140] helo=localhost) by psg.com with esmtp (Exim 3.36 #1) id 19Fvjy-0003eY-00 for multi6@ops.ietf.org; Wed, 14 May 2003 12:52:14 +0000 Received: from [192.168.1.100] (localhost [127.0.0.1]) by localhost (8.12.9/8.12.2) with ESMTP id h4ECqC9L002550 for ; Wed, 14 May 2003 08:52:12 -0400 (EDT) Date: Wed, 14 May 2003 08:52:11 -0400 From: "Michael H. Lambert" To: multi6@ops.ietf.org Subject: Re: IETF multihoming powder: just add IPv6 and stir Message-ID: <12630661.1052902075@[192.168.1.100]> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-25.4 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, RCVD_IN_RFCI,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Wednesday, 14 May 2003 11:01 +0200 Iljitsch van Beijnum wrote: > On woensdag, mei 14, 2003, at 08:30 Europe/Amsterdam, Masataka Ohta wrote: [...] > > No way. First of all having a routing table in each host is a huge waste > of resources. Second, why use fifth hand information if a host can simply > send some packets and see if they make it through? That's much more > effective and light-weight at the expense of some only a few otherwise > unnecessary end-to-end packets. Routing protocols seldom know which paths > are good. They barely know how to avoid the very bad and non-functioning > ones. Just because the path is valid (and perhaps "good" by a reasonable set of metrics) does not mean that it is even near-optimal. A host sending a few packets to check a path will have no idea of the bandwidth along the path, for example. >> The solutions should be end to end that complex functionality must >> be performed only on hosts. > > I agree in principle. However, if we can give people the option to > offload this to a middlebox if they so desire, that's a plus. (Which is a > very different thing from requiring middleboxes or requiring routers or > other non-middlebox boxes in the middle to do it.) I think the right approach is to allow the functionality to be implemented hierarchically. >> Hosts needs help from routing protocols. > > That's the same logic as suing a lawyer. At the surface it seems to make > sense but you really don't want to do it if you can avoid it. > >> However, with multiple addresses to an interface, selection of source >> address/locator can be performed properly only with the help from >> routing protocol, which is a reason why IPv6 is broken in >> source address selection. > > The trouble with current transport protocols is that once you've selected > your source address you can't change it. So we change it and then listen > for ICMP messages to see when we have the wrong source address. I think the right way to think about this is that whatever device is responsible for making decisions about dynamic source address selection can usually benefit from hints from the routing protocols. [...] >>> Remember that path MTU discovery is pretty much mandatory in >>> IPv6 so you need those ICMPs. > >> No. PMTUD is one, among many, of a useless feature of IPv6. > > Why is it useless? > >> Just send packets not loger than 1280B. > > That's unacceptable. > > In fact, we need to go even further and implement functionality in > neighbor discovery to enable the use of jumboframes between two hosts > that support them even though other hosts on the same subnet may not. Exactly, although probably not important for small flows (< 100 Mb/s). Ohta-san: Please consider the loss requirements for a trans-Pacific 10 Gb/s flow using the default Ethernet MTU. Michael From owner-multi6@ops.ietf.org Wed May 14 10:59:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20663 for ; Wed, 14 May 2003 10:59:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Fxl5-000Nes-00 for multi6-data@psg.com; Wed, 14 May 2003 15:01:31 +0000 Received: from dhcp-9-211.ripemtg.ripe.net ([193.0.9.211] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 19Fxky-000Nbf-00 for multi6@ops.ietf.org; Wed, 14 May 2003 15:01:24 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h4EF3sTq014240 for ; Wed, 14 May 2003 17:03:55 +0200 (CEST) Date: Wed, 14 May 2003 17:03:52 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Agenda for Vienna From: Kurt Erik Lindqvist To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: <465D5422-861D-11D7-BDC5-000393520ED8@kurtis.pp.se> X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-9.7 required=5.0 tests=BAYES_01,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ok, so me, Sean and Randy have been discussing a possible agenda for Vienna. We tried to incorporate as much of the views as possible. Our suggestion is as follows : 1. We schedule two sessions. 2. The first session is early in the week, and have one topic. The proposals that have then been made formally to the IETF will each get around five minutes. Each presenter will be a member of a "panel". The working-group and the other presenters are allowed to ask questions on the proposals and try and better understand the proposals. 3. The second session will be scheduled later in the week. This will concentrate on the two main proposals that are currently being worked on. Those being loc/id which seems to be the main one, and host based solutions. This session would be started off with an overview of the status on this, and perhaps a summary of the earlier session. So to elaborate a bit. The first session is not meant to be a "survivor wins" session; and that will put some work on the chairs. It's intention is to give a clearer picture of the proposals. The main reason for the first session would be to allow discussions around the proposals in the hallways, leading up to the next session (so we will try and have a few days in between). The first session is also not mean to be q "qualifying" session for the second one. To me (and from what I read on the list - most others) it is very clear that there is only two real solutions being worked on at the moment. I also want to point out that the WG sessions are not there for a full presentation of the proposals - You are supposed to read the drafts :-) ; which means that you need to submit the drafts. As for members of the panel, I would personally not want to see several similar proposals being presented, but there aren't that many out there anyway so this should not be an issue. The second session is meant to be an opportunity to dig more into what we think are required of each of the solutions; what the issues are; ways forward. As has been said a number of times on this list by Vienna we need to have a lot of basic issues sorted out by Vienna. As I see it at the moment I would schedule 1h for the first session and 2h for the second one. Last, I guess one of the questions will be "why the first session?". The intent is only that a better understanding of other proposals will help us with more ideas. I don't see the main track changing unless all of a sudden a large part of the working group change their minds. I will leave this a few days for comments and then go ahead and make the request to the secretariat. We would like to do this as quick as possible though. And I hope that there isn't to many issues with this proposal. Best regards, - kurtis - From owner-multi6@ops.ietf.org Wed May 14 11:15:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21230 for ; Wed, 14 May 2003 11:15:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Fy14-000PEa-00 for multi6-data@psg.com; Wed, 14 May 2003 15:18:02 +0000 Received: from dhcp-9-211.ripemtg.ripe.net ([193.0.9.211] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 19Fy12-000PEL-00 for multi6@ops.ietf.org; Wed, 14 May 2003 15:18:00 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h4EFIXTq014250; Wed, 14 May 2003 17:18:33 +0200 (CEST) Date: Wed, 14 May 2003 17:18:31 +0200 Subject: Re: Mutli6 meeting in Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Coene Lode , "Bound, Jim" , multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200305141128.UAA13332@necom830.hpcl.titech.ac.jp> Message-Id: <524D27D3-861F-11D7-BDC5-000393520ED8@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-16.7 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> I am worried that we would spend large amount of time in our first >> meeting for a long time going through proposals, without a clear >> picture of where this would lead us. > > It is a job of chairs to assign appropriate amount of time for > each presentation. > > It is a job of chairs to reserve appropriate amount of time for > the wrap up discussion. There is also the job of the chairs to sense which proposals have backing and which do not. That is currently pretty clear to me. Also note that the sessions (at least to me) are not meant for presentations of the proposals, they are meant as possibility for clarification or discussions of a certain solutions viability. But see my mail on proposal for the agenda. > >> From what I can see there are very >> few proposals that have any broader support. > > That's why we need presentations and discussions. Why? If there are few proposals with wide support, that to me is an achievement over many proposals with little support. We are trying to move towards a very distant consensus here. > We shouldn't expect Pekka can draw a clear picture to lead us. Well, at some point someone will have to. Be it me and Sean, the IESG or Pekka as presenting an overview. > >>> Having presentation by Pekka, you will get view of Pekka, but nothing >>> more than that, which is not so productive. >> >> Well, I was not going to ask him to present his views of the >> proposals. >> Rather a summary of the classes of solutions we see. Without any >> comments on the solutions as such. That is also what I understood that >> he was willing to do. > > It's Pekka's view of classification. > I haven't seen much disagreement on that here though. >>> Discussion on solution classes, if any, should be more abstact >>> and should not be based on specific proposals. >>> >>> Overview on specific proposals is a different topic. >>> >> >> That is why I wanted this split in to parts. One to give the overview >> (abstracts if you want) of the classes of solutions, one part on the >> proposals that appears to have the widest support. > > You are saying to select proposals that appears to have the widest > support based on the Pekka's view of classification. No. I am saying that there are few proposals here that are a) Being discussed b) Seems to have any support that is wider than the author. Some of the proposals would not even have the support of their authors if we where moving forward on a longer term solution (like mine and Iljitsch I guess). > > That's not fair. > > Worse, a good class can contain poor solutions that classes > and solutions are rather orthogonal. > Again, I only see work being done on loc/id and some on host based solutions. There are good and bad suggestions and characteristics in both of those discussions. That are why we are having them. But see suggestion for agenda. - kurtis - From owner-multi6@ops.ietf.org Wed May 14 17:00:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05431 for ; Wed, 14 May 2003 17:00:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19G3Np-0004mt-00 for multi6-data@psg.com; Wed, 14 May 2003 21:01:53 +0000 Received: from [2002:c08b:2e21:3:250:baff:fe2d:b704] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.36 #1) id 19G3Nm-0004mU-00 for multi6@ops.ietf.org; Wed, 14 May 2003 21:01:50 +0000 Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4EL1g913877 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 14 May 2003 17:01:44 -0400 (EDT) Received: from sandelman.ottawa.on.ca (res158.cooperix.net [192.139.46.158]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4EL2lh09979; Wed, 14 May 2003 17:02:48 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h4EL1WbU002885; Wed, 14 May 2003 17:01:32 -0400 Message-Id: <200305142101.h4EL1WbU002885@sandelman.ottawa.on.ca> To: Kurt Erik Lindqvist cc: multi6@ops.ietf.org Subject: Re: Agenda for Vienna In-reply-to: Your message of "Wed, 14 May 2003 17:03:52 +0200." <465D5422-861D-11D7-BDC5-000393520ED8@kurtis.pp.se> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 14 May 2003 17:01:31 -0400 From: Michael Richardson X-Spam-Status: No, hits=-9.3 required=5.0 tests=BAYES_01,IN_REP_TO,RCVD_IN_OSIRUSOFT_COM autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurtis, I think that this is an excellent way to go. Thank you kindly for the cat herding. From owner-multi6@ops.ietf.org Wed May 14 17:40:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07023 for ; Wed, 14 May 2003 17:40:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19G41v-000DJn-00 for multi6-data@psg.com; Wed, 14 May 2003 21:43:19 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19G41s-000DJb-00 for multi6@ops.ietf.org; Wed, 14 May 2003 21:43:17 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h4ELftn33668; Wed, 14 May 2003 23:41:55 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 14 May 2003 23:41:56 +0200 Subject: Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: "Christian Huitema" From: Iljitsch van Beijnum In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On dinsdag, mei 13, 2003, at 17:26 Europe/Amsterdam, Christian Huitema wrote: >> Mobile IP in IPv6 uses a 24 byte header to carry the original source >> address, right? > It does, but it only needs to do so when negotiating a binding update. > The trick is to design a usage model of MIPv6 in which binding updates > are used to redirect a TCP connection (or a UDP flow) to a new address. Christian, why did you have to do this??? All this time I managed to avoid reading the MIPv6 draft (no RFC yet...) but now I had to in order to be able to disagree with you. On page 78 it says that there must be state in the binding cache AND the correspondent has to use a routing header. So there's something to hate there for everyone. (I know I was talking about the source and not the dest address but that one is significantly more convoluted in the spec. Looks like the same thing applies, though.) Unfortunately it isn't entirely trivial to remove the routing header and have the identifier^H^H^H^H^Hhome address be implied as this requires a mechanism to detect whether something is directed at the home address or the care-of address, which we need to know to do the checksums. Who's bright idea was it to include the addresses in the transport checksums anyway??? From owner-multi6@ops.ietf.org Wed May 14 17:54:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07193 for ; Wed, 14 May 2003 17:54:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19G4Fe-000G8c-00 for multi6-data@psg.com; Wed, 14 May 2003 21:57:30 +0000 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 19G4Fa-000G6B-00 for multi6@ops.ietf.org; Wed, 14 May 2003 21:57:26 +0000 From: Masataka Ohta Message-Id: <200305142149.GAA15023@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id GAA15023; Thu, 15 May 2003 06:49:08 +0900 Subject: Re: Agenda for Vienna In-Reply-To: <465D5422-861D-11D7-BDC5-000393520ED8@kurtis.pp.se> from Kurt Erik Lindqvist at "May 14, 2003 05:03:52 pm" To: Kurt Erik Lindqvist Date: Thu, 15 May 2003 06:49:07 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurt; > 1. We schedule two sessions. Why its not three 2H sessions? Have you tried? > 2. The first session is early in the week, and have one topic. The > proposals that have then been made formally to the IETF will each get > around five minutes. Each presenter will be a member of a "panel". Formally? OK. When can I see formal call for proposals? Note that people, including chairs, insisting on a requirement draft have been deprecating to discuss specific proposals. > 3. The second session will be scheduled later in the week. This will > concentrate on the two main proposals that are currently being worked > on. Hugh? Two? > Those being loc/id which seems to be the main one, and host based > solutions. Host based loc/id is a single class of many solutions including LIN6. > it is very clear that there is only two > real solutions being worked on at the moment. Note that something being worked on is not better than something completed. Note also that repeating the same discussion against geo and GSE again and again does not mean "work on". Masataka Ohta PS It's good that no time is wasted on a requirement draft. From owner-multi6@ops.ietf.org Wed May 14 17:55:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07208 for ; Wed, 14 May 2003 17:55:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19G4F1-000G4u-00 for multi6-data@psg.com; Wed, 14 May 2003 21:56:51 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19G4Ey-000G0V-00 for multi6@ops.ietf.org; Wed, 14 May 2003 21:56:48 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h4ELtNn33687; Wed, 14 May 2003 23:55:23 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 14 May 2003 23:55:26 +0200 Subject: Re: Agenda for Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Kurt Erik Lindqvist From: Iljitsch van Beijnum In-Reply-To: <465D5422-861D-11D7-BDC5-000393520ED8@kurtis.pp.se> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On woensdag, mei 14, 2003, at 17:03 Europe/Amsterdam, Kurt Erik Lindqvist wrote: > 2. The first session is early in the week, and have one topic. The > proposals that have then been made formally to the IETF will each get > around five minutes. Each presenter will be a member of a "panel". The > working-group and the other presenters are allowed to ask questions on > the proposals and try and better understand the proposals. Who are the presenters? The authors? > I also want to point out that the WG sessions are not there for a full > presentation of the proposals - You are supposed to read the drafts > :-) I fully agree, however: it is likely that there will be a significant number of "new" people there to see what's shaking in multi6. It might be good to introduce every proposal so the entire audience at least knows the general gest of all proposals. Then they can read the draft before the second meeting if they're interested. I think we need more than five minutes per proposal. Would ten be doable? Remember that not everyone is as brief as we were at the RIPE meeting in Amsterdam. :-) > I would personally not want to see several similar proposals being > presented, The different takes on the whole locator/identifier thing are different enough to warrant talking about all that are fleshed out enough, I think. Finally an organizational remark: if we allow everyone to have their own slides we lose half the allocated time with hooking up laptops. I suggest that everyone who presents submits some slides and someone makes sure all of them are projected around the right time. If Steve Kent can do it over the phone this should be easy... From owner-multi6@ops.ietf.org Wed May 14 18:05:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07740 for ; Wed, 14 May 2003 18:05:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19G4PS-000IbO-00 for multi6-data@psg.com; Wed, 14 May 2003 22:07:38 +0000 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 19G4PQ-000IZ3-00 for multi6@ops.ietf.org; Wed, 14 May 2003 22:07:36 +0000 From: Masataka Ohta Message-Id: <200305142158.GAA15087@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id GAA15087; Thu, 15 May 2003 06:58:35 +0900 Subject: Re: Mutli6 meeting in Vienna In-Reply-To: <524D27D3-861F-11D7-BDC5-000393520ED8@kurtis.pp.se> from Kurt Erik Lindqvist at "May 14, 2003 05:18:31 pm" To: Kurt Erik Lindqvist Date: Thu, 15 May 2003 06:58:35 +0859 () CC: Coene Lode , "Bound, Jim" , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurt; > Again, I only see work being done on loc/id and some on host based > solutions. There are good and bad suggestions and characteristics in > both of those discussions. That are why we are having them. Personally for me, that's fine. I'm tired of repeated discussion against geo and GSE. But there are many loc/id proposals to be compared that your statement: > Again, I only see work being done on loc/id and some on host based > solutions. does not help the situation. Masataka Ohta From owner-multi6@ops.ietf.org Wed May 14 18:53:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09373 for ; Wed, 14 May 2003 18:53:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19G5AV-0001p8-00 for multi6-data@psg.com; Wed, 14 May 2003 22:56:15 +0000 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #1) id 19G5AT-0001ow-00 for multi6@ops.ietf.org; Wed, 14 May 2003 22:56:13 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 28C473446D; Wed, 14 May 2003 15:10:40 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h4EMuCYB022066; Wed, 14 May 2003 15:56:12 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Agenda for Vienna Date: Wed, 14 May 2003 15:56:12 -0700 Message-ID: Thread-Topic: Agenda for Vienna Thread-Index: AcMaLbBQwb3RCOGGQSGsW/GE2VNM3gAPVyWQ From: "Tony Li" To: "Kurt Erik Lindqvist" , X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA09373 I'd like to take this opportunity to again ask that we put aside our petty and trivial differences, the implementation foibles and our particular pet proposals (mine included). Instead we should take this time to sit down and have a collaborative architectural discussion. It is the perogative and responsibility of the chairs to ensure that we make forward progress and I call on them to step up, lead the discussion, and ensure that we stay at a civilized and architectural level. Once we have an architecture for a solution, THEN we can start worrying about the bits. This implies that we should not be looking at particular proposals. We should not even be looking at 'categories' of proposals. Instead, we should be talking about possible architectures. That's one layer farther up. Regards, Tony | -----Original Message----- | From: Kurt Erik Lindqvist [mailto:kurtis@kurtis.pp.se] | Sent: Wednesday, May 14, 2003 8:04 AM | To: multi6@ops.ietf.org | Subject: Agenda for Vienna | | | | Ok, so me, Sean and Randy have been discussing a possible | agenda for | Vienna. We tried to incorporate as much of the views as | possible. Our | suggestion is as follows : | | | 1. We schedule two sessions. | | 2. The first session is early in the week, and have one topic. The | proposals that have then been made formally to the IETF | will each get | around five minutes. Each presenter will be a member of a | "panel". The | working-group and the other presenters are allowed to ask | questions on | the proposals and try and better understand the proposals. | | 3. The second session will be scheduled later in the week. | This will | concentrate on the two main proposals that are currently | being worked | on. Those being loc/id which seems to be the main one, and | host based | solutions. This session would be started off with an | overview of the | status on this, and perhaps a summary of the earlier session. | | So to elaborate a bit. The first session is not meant to | be a "survivor | wins" session; and that will put some work on the chairs. It's | intention is to give a clearer picture of the proposals. The main | reason for the first session would be to allow discussions | around the | proposals in the hallways, leading up to the next session | (so we will | try and have a few days in between). The first session is | also not mean | to be q "qualifying" session for the second one. To me | (and from what I | read on the list - most others) it is very clear that | there is only two | real solutions being worked on at the moment. I also want | to point out | that the WG sessions are not there for a full presentation of the | proposals - You are supposed to read the drafts :-) ; | which means that | you need to submit the drafts. As for members of the | panel, I would | personally not want to see several similar proposals being | presented, | but there aren't that many out there anyway so this should | not be an | issue. | | The second session is meant to be an opportunity to dig | more into what | we think are required of each of the solutions; what the | issues are; | ways forward. As has been said a number of times on this | list by Vienna | we need to have a lot of basic issues sorted out by Vienna. | | As I see it at the moment I would schedule 1h for the | first session and | 2h for the second one. | | Last, I guess one of the questions will be "why the first | session?". | The intent is only that a better understanding of other | proposals will | help us with more ideas. I don't see the main track | changing unless all | of a sudden a large part of the working group change their minds. | | I will leave this a few days for comments and then go | ahead and make | the request to the secretariat. We would like to do this | as quick as | possible though. And I hope that there isn't to many | issues with this | proposal. | | Best regards, | | - kurtis - | | | From owner-multi6@ops.ietf.org Wed May 14 18:55:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09422 for ; Wed, 14 May 2003 18:55:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19G5Cu-0002Zr-00 for multi6-data@psg.com; Wed, 14 May 2003 22:58:44 +0000 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #1) id 19G5Ct-0002Yk-00 for multi6@ops.ietf.org; Wed, 14 May 2003 22:58:43 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 2F08E3446E; Wed, 14 May 2003 15:13:10 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h4EMwgYB022135; Wed, 14 May 2003 15:58:42 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IETF multihoming powder: just add IPv6 and stir Date: Wed, 14 May 2003 15:58:42 -0700 Message-ID: Thread-Topic: IETF multihoming powder: just add IPv6 and stir Thread-Index: AcMZ8Xv1Q3br1WJCSGuXeQzt3v9JJQAeouew From: "Tony Li" To: "Iljitsch van Beijnum" Cc: X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA09422 IMHO, firewall type filtering should be on "who" you are, not on "where" you are. The only filtering on location that makes sense to me is to simply ensure that the source locator is not spoofed. Tony | > A filter that is looking at a locator is probably a bug. | | The need to filter is an operational reality. | | So how do we filter on an identifier? Put them into the | routing tables | and then uRPF? And if the identifiers are in the routing | tables, who | needs a locator? | | To me, identifiers belong at layer 4 and up. Locators | belong at layer | 3. So any filtering on layer 3 must be on locators. | | From owner-multi6@ops.ietf.org Wed May 14 22:48:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13413 for ; Wed, 14 May 2003 22:48:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19G8p0-000Pfj-00 for multi6-data@psg.com; Thu, 15 May 2003 02:50:18 +0000 Received: from [3ffe:501:100c:d120::53] (helo=shonan.sfc.wide.ad.jp) by psg.com with esmtp (Exim 3.36 #1) id 19G8ow-000PdU-00 for multi6@ops.ietf.org; Thu, 15 May 2003 02:50:16 +0000 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 845E35D013; Thu, 15 May 2003 11:49:41 +0900 (JST) Date: Thu, 15 May 2003 11:47:25 +0900 From: Thierry Ernst To: Pekka Savola Cc: kurtis@kurtis.pp.se, multi6@ops.ietf.org Subject: Re: Mutli6 meeting in Vienna Message-Id: <20030515114725.512d26cf.ernst@sfc.wide.ad.jp> In-Reply-To: References: <20030514174131.393f6a6b.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-26.6 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, > > Is there any restriction on the length of the prefix for a network to be > > considered site-multihomed ? > > "Site multihoming" to one provider (called site multiconnecting in the v4 > draft) is basically a no-brainer, AFAIK. I'm happy to learn it's a no-brainer, that was not my perception, but I need a little more thoughts on this. Is there any recommended document we should read to understand the problem space (besides the multi6 i-d) ? > Is there something here which leads you to believe we need to work on this? No, I'm just trying to understand the problem space in the case I connect an in-vehicle network to different ISPs, where the prefix should come from, its length, etc, and also scalability concerns (there are 700 Millions vehicles in the world). So, I have a strong interest in the word conducted in Multi6. We have to make sure your forthcoming solutions will work for NEMO. > We could push multi-connecting as a solution/workaround for some use cases > though. IMO, that makes perfect sense to me, but at the same time, it > cannot meet *all* the sites' needs, so we need something else too. Thanks, Thierry From owner-multi6@ops.ietf.org Thu May 15 02:01:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17913 for ; Thu, 15 May 2003 02:01:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GBpw-000G1V-00 for multi6-data@psg.com; Thu, 15 May 2003 06:03:28 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19GBpt-000G1E-00 for multi6@ops.ietf.org; Thu, 15 May 2003 06:03:26 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4F63IY05215; Thu, 15 May 2003 09:03:19 +0300 Date: Thu, 15 May 2003 09:03:17 +0300 (EEST) From: Pekka Savola To: Thierry Ernst cc: kurtis@kurtis.pp.se, Subject: Re: Mutli6 meeting in Vienna In-Reply-To: <20030515114725.512d26cf.ernst@sfc.wide.ad.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 15 May 2003, Thierry Ernst wrote: > > > Is there any restriction on the length of the prefix for a network to be > > > considered site-multihomed ? > > > > "Site multihoming" to one provider (called site multiconnecting in the v4 > > draft) is basically a no-brainer, AFAIK. > > I'm happy to learn it's a no-brainer, that was not my perception, but I > need a little more thoughts on this. Is there any recommended document > we should read to understand the problem space (besides the multi6 i-d) > ? No. Well, I've covered it very briefly in my thesis, available at: http://staff.csc.fi/psavola/di.ps The main thing is that if you're multiconnecting inside the ISP, you don't need more than one set of addresses, at least in the typical case. In that case, the ISP can route them appropriately to you any way you agree about it. But if you consider this from the "small customer" perspective, e.g. a laptop with both GPRS and WLAN interfaces *to the same ISP*, the problem space is probably not that much different from the two ISP case. > > Is there something here which leads you to believe we need to work on this? > > No, I'm just trying to understand the problem space in the case I > connect an in-vehicle network to different ISPs, where the prefix should > come from, its length, etc, and also scalability concerns (there are 700 > Millions vehicles in the world). So, I have a strong interest in the > word conducted in Multi6. We have to make sure your forthcoming > solutions will work for NEMO. Ok, thanks for info. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Thu May 15 03:11:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29199 for ; Thu, 15 May 2003 03:11:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GCvL-000NH2-00 for multi6-data@psg.com; Thu, 15 May 2003 07:13:07 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19GCvJ-000NGm-00 for multi6@ops.ietf.org; Thu, 15 May 2003 07:13:05 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h4F7Bhn34850; Thu, 15 May 2003 09:11:43 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 15 May 2003 09:11:46 +0200 Subject: Re: IETF multihoming powder: just add IPv6 and stir Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: "Michael H. Lambert" From: Iljitsch van Beijnum In-Reply-To: <12630661.1052902075@[192.168.1.100]> Message-Id: <7D50032D-86A4-11D7-A2C3-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On woensdag, mei 14, 2003, at 14:52 Europe/Amsterdam, Michael H. Lambert wrote: >> Second, why use fifth hand information if a host can simply >> send some packets and see if they make it through? That's much more >> effective and light-weight at the expense of some only a few otherwise >> unnecessary end-to-end packets. Routing protocols seldom know which >> paths >> are good. They barely know how to avoid the very bad and >> non-functioning >> ones. > Just because the path is valid (and perhaps "good" by a reasonable set > of metrics) does not mean that it is even near-optimal. A host > sending a few packets to check a path will have no idea of the > bandwidth along the path, for example. Note that in the commodity internet the bandwidth of a path is a non-issue: ISP connections are almost always of a much higher bandwidth than the part between the ISP edge and the end-host. I agree that a few packets isn't enough to determine the bandwidth of a path but with a higher number of packets this shouldn't be much of a problem. But in these cases a partial routing table in the host would be ok, I guess. Another approach is to use diffserv to signal packets should take the high-bandwidth path. >>> The solutions should be end to end that complex functionality must >>> be performed only on hosts. >> I agree in principle. However, if we can give people the option to >> offload this to a middlebox if they so desire, that's a plus. > I think the right approach is to allow the functionality to be > implemented hierarchically. What does that mean? > I think the right way to think about this is that whatever device is > responsible for making decisions about dynamic source address > selection can usually benefit from hints from the routing protocols. I'm not saying there are no benefits, just that the downsides are much bigger and that it would be unacceptable to mandate having a routing table in each host. >> In fact, we need to go even further and implement functionality in >> neighbor discovery to enable the use of jumboframes between two hosts >> that support them even though other hosts on the same subnet may not. > Exactly, although probably not important for small flows (< 100 Mb/s). I don't think setting the MTU based on the flow speed is useful: either you can do it so you do it or you can't so you don't. But I agree there isn't much point in having jumboframes in 10 or 100 Mbps equipment and it seems vendors feel the same way because I have yet to encounter a < 1000 Mbps ethernet NIC that supports them. From owner-multi6@ops.ietf.org Thu May 15 03:53:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00148 for ; Thu, 15 May 2003 03:53:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GDb5-0002Pi-00 for multi6-data@psg.com; Thu, 15 May 2003 07:56:15 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19GDb3-0002PU-00 for multi6@ops.ietf.org; Thu, 15 May 2003 07:56:13 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h4F7smn35105; Thu, 15 May 2003 09:54:51 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 15 May 2003 09:54:49 +0200 Subject: Re: Agenda for Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: "Tony Li" From: Iljitsch van Beijnum In-Reply-To: Message-Id: <80CE291C-86AA-11D7-A2C3-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On donderdag, mei 15, 2003, at 00:56 Europe/Amsterdam, Tony Li wrote: > I'd like to take this opportunity to again ask that we put aside > our petty and trivial differences, the implementation foibles > and our particular pet proposals (mine included). Instead > we should take this time to sit down and have a collaborative > architectural discussion. It's not always easy to see where architecture ends and interior decorating begins. Some notions that seem relatively undisputed: - we separate the identifier and locator functions so we can have multiple locators and still have a single identifier - IP in transit works with locators, everything above the IP layer with the identifier This leads to the following questions: - what should identifiers look like? - assuming applications use identifiers, how do we know which locators go with a certain identifier? - when receiving packets, how do we know (= better than take her word for it) the correspondent's identifier? Then there is the address selection problem. We know that the current "pick one and die if it doesn't work" approach is no good so we have to come up with something better. The draft I wrote on sunday uses a minimalist approach to answer all these questions (well except the source address selection thing). It would be good to have one or more different sets of answers written up in enough detail to be able to determine which approach is preferable. Waiting for Vienna and trying to do it there in two hours isn't going to work well IMO. From owner-multi6@ops.ietf.org Thu May 15 04:00:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00270 for ; Thu, 15 May 2003 04:00:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GDi2-0003Fy-00 for multi6-data@psg.com; Thu, 15 May 2003 08:03:26 +0000 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #1) id 19GDi0-0003Fm-00 for multi6@ops.ietf.org; Thu, 15 May 2003 08:03:24 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 2361A34464; Thu, 15 May 2003 00:17:52 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h4F83NYB012988; Thu, 15 May 2003 01:03:24 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Agenda for Vienna Date: Thu, 15 May 2003 01:02:39 -0700 Message-ID: Thread-Topic: Agenda for Vienna Thread-Index: AcMat3p+YWqRSln/R4KsMpi2hGBEcgAAMnxw From: "Tony Li" To: "Iljitsch van Beijnum" Cc: X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA00270 | Some notions that seem relatively undisputed: | | - we separate the identifier and locator functions so we can have | multiple locators and still have a single identifier | - IP in transit works with locators, everything above the | IP layer with | the identifier | Do we really have consensus on these points? Does this imply that tunneling is no longer a consideration? Tony From owner-multi6@ops.ietf.org Thu May 15 04:13:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00602 for ; Thu, 15 May 2003 04:13:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GDtI-0004qj-00 for multi6-data@psg.com; Thu, 15 May 2003 08:15:04 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19GDtE-0004pk-00 for multi6@ops.ietf.org; Thu, 15 May 2003 08:15:00 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4F8EpU06047; Thu, 15 May 2003 11:14:51 +0300 Date: Thu, 15 May 2003 11:14:51 +0300 (EEST) From: Pekka Savola To: Tony Li cc: Iljitsch van Beijnum , Subject: RE: Agenda for Vienna In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 15 May 2003, Tony Li wrote: > | Some notions that seem relatively undisputed: > | > | - we separate the identifier and locator functions so we can have > | multiple locators and still have a single identifier > | - IP in transit works with locators, everything above the > | IP layer with > | the identifier > | > > Do we really have consensus on these points? Does this imply that > tunneling is no longer a consideration? For some scenarios, and maybe in the long term, I think the separation is probably necessary. But that doesn't mean it solves all the problems, or fits all the scenarios. On the contrary. Connection survivability? Sure. Load sharing? Nope. Provider indendence? Maybe not, difficult to say. Etc. Personally, I see a ID/LOC separation as a long term issue, and more of a distraction at the moment. It will not be able to give us all, so too much attention to it could be dangerous. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Thu May 15 05:09:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01520 for ; Thu, 15 May 2003 05:09:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GElS-000C63-00 for multi6-data@psg.com; Thu, 15 May 2003 09:11:02 +0000 Received: from dhcp-9-211.ripemtg.ripe.net ([193.0.9.211] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 19GElQ-000C5r-00 for multi6@ops.ietf.org; Thu, 15 May 2003 09:11:00 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h4F9DPTq014381; Thu, 15 May 2003 11:13:26 +0200 (CEST) Date: Thu, 15 May 2003 11:13:23 +0200 Subject: Re: Agenda for Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <7AC2E576-86B5-11D7-BDC5-000393520ED8@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On onsdag, maj 14, 2003, at 23:55 Europe/Stockholm, Iljitsch van Beijnum wrote: > On woensdag, mei 14, 2003, at 17:03 Europe/Amsterdam, Kurt Erik > Lindqvist wrote: > >> 2. The first session is early in the week, and have one topic. The >> proposals that have then been made formally to the IETF will each get >> around five minutes. Each presenter will be a member of a "panel". >> The working-group and the other presenters are allowed to ask >> questions on the proposals and try and better understand the >> proposals. > > Who are the presenters? The authors? That was the thinking yes. > >> I also want to point out that the WG sessions are not there for a >> full presentation of the proposals - You are supposed to read the >> drafts > :-) > > I fully agree, however: it is likely that there will be a significant > number of "new" people there to see what's shaking in multi6. It might > be good to introduce every proposal so the entire audience at least > knows the general gest of all proposals. Then they can read the draft > before the second meeting if they're interested. The idea was that that was the 5 min introduction. > > I think we need more than five minutes per proposal. Would ten be > doable? Remember that not everyone is as brief as we were at the RIPE > meeting in Amsterdam. :-) How much time we have will depend on the amount of proposals. What worries me is that this means I most likely will have to keep the agenda floating until the draft cut-off date :-) >> I would personally not want to see several similar proposals being >> presented, > > The different takes on the whole locator/identifier thing are > different enough to warrant talking about all that are fleshed out > enough, I think. Again, this is more a time constraint than anything else and would depend on the amount of presentations. > Finally an organizational remark: if we allow everyone to have their > own slides we lose half the allocated time with hooking up laptops. I > suggest that everyone who presents submits some slides and someone > makes sure all of them are projected around the right time. If Steve > Kent can do it over the phone this should be easy... Agreed. I will try and have all presentations on one laptop. - kurtis - From owner-multi6@ops.ietf.org Thu May 15 05:46:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01929 for ; Thu, 15 May 2003 05:46:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GFM9-000EX8-00 for multi6-data@psg.com; Thu, 15 May 2003 09:48:57 +0000 Received: from dhcp-9-211.ripemtg.ripe.net ([193.0.9.211] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 19GFLy-000EWb-00 for multi6@ops.ietf.org; Thu, 15 May 2003 09:48:47 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h4F9p7Tq014393; Thu, 15 May 2003 11:51:08 +0200 (CEST) Date: Thu, 15 May 2003 11:51:05 +0200 Subject: Re: Agenda for Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200305142149.GAA15023@necom830.hpcl.titech.ac.jp> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-16.1 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> 1. We schedule two sessions. > > Why its not three 2H sessions? Have you tried? No. I don't see the need for it, and I don't think it would be useful. If others disagree they are free to step forward. > >> 2. The first session is early in the week, and have one topic. The >> proposals that have then been made formally to the IETF will each get >> around five minutes. Each presenter will be a member of a "panel". > > Formally? OK. When can I see formal call for proposals? Eh, from what I know of the IETF, send text. If you send in a draft and ask the secretariat to CC the multi6 list we will pick it up and ask you to present. > Note that people, including chairs, insisting on a requirement draft > have been deprecating to discuss specific proposals. I don't think we are at the stage of formal proposals yet. I think we need to learn to walk before we start thinking of doing base-jumping. > >> 3. The second session will be scheduled later in the week. This will >> concentrate on the two main proposals that are currently being worked >> on. > > Hugh? > > Two? I only see two major solution "classes" that have any wider support right now. >> it is very clear that there is only two >> real solutions being worked on at the moment. > > Note that something being worked on is not better than something > completed. Something with wide support is better than something completed. It's not "first with code" it's "running code AND consensus". - kurtis - From owner-multi6@ops.ietf.org Thu May 15 05:48:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01958 for ; Thu, 15 May 2003 05:48:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GFOb-000EeD-00 for multi6-data@psg.com; Thu, 15 May 2003 09:51:29 +0000 Received: from dhcp-9-211.ripemtg.ripe.net ([193.0.9.211] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 19GFOZ-000Edw-00 for multi6@ops.ietf.org; Thu, 15 May 2003 09:51:27 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h4F9rkTq014396; Thu, 15 May 2003 11:53:46 +0200 (CEST) Date: Thu, 15 May 2003 11:53:43 +0200 Subject: Re: Mutli6 meeting in Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Coene Lode , "Bound, Jim" , multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200305142158.GAA15087@necom830.hpcl.titech.ac.jp> Message-Id: <1CCAD444-86BB-11D7-BDC5-000393520ED8@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-16.1 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> Again, I only see work being done on loc/id and some on host based >> solutions. There are good and bad suggestions and characteristics in >> both of those discussions. That are why we are having them. > > Personally for me, that's fine. > > I'm tired of repeated discussion against geo and GSE. To be honest, I don't see you make any comments on either of these. I see you make comments that they won't work and that you have a solution ready that we should all adopt and be done with. Personally I would be interested in seeing you write up a technical basis for your reasons against these and then we could move from there. - kurtis - From owner-multi6@ops.ietf.org Thu May 15 05:53:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02054 for ; Thu, 15 May 2003 05:53:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GFTJ-000Eot-00 for multi6-data@psg.com; Thu, 15 May 2003 09:56:21 +0000 Received: from dhcp-9-211.ripemtg.ripe.net ([193.0.9.211] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 19GFTG-000EoW-00 for multi6@ops.ietf.org; Thu, 15 May 2003 09:56:18 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h4F9woTq014400; Thu, 15 May 2003 11:58:51 +0200 (CEST) Date: Thu, 15 May 2003 11:58:48 +0200 Subject: Re: Agenda for Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Tony Li" From: Kurt Erik Lindqvist In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-15.9 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Tony, > I'd like to take this opportunity to again ask that we put aside > our petty and trivial differences, the implementation foibles > and our particular pet proposals (mine included). Instead > we should take this time to sit down and have a collaborative > architectural discussion. Agreed. > > It is the perogative and responsibility of the chairs to > ensure that we make forward progress and I call on them to > step up, lead the discussion, and ensure that we stay at > a civilized and architectural level. > > Once we have an architecture for a solution, THEN we can > start worrying about the bits. > > This implies that we should not be looking at particular > proposals. We should not even be looking at 'categories' > of proposals. Instead, we should be talking about possible > architectures. That's one layer farther up. > The idea with doing the agenda the way we have proposed is to try and have the best of both worlds. The idea is that the second session is just this. Sit down and try and work out the architectural principles. The first session is not necessarily intended to influence this discussion (again, the first session is not the qualifying session for the second). See the first session as a "marketing" (for the lack of better word) event for multi6. It's not ideal, but we are trying to a) Give people the opportunity to express their thoughts on the architecture (although with detailed examples) and b) Have a discussion on the future architecture. Best regards, - kurtis - From owner-multi6@ops.ietf.org Thu May 15 06:01:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02224 for ; Thu, 15 May 2003 06:01:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GFaf-000FBN-00 for multi6-data@psg.com; Thu, 15 May 2003 10:03:57 +0000 Received: from d12lmsgate.de.ibm.com ([194.196.100.234]) by psg.com with esmtp (Exim 3.36 #1) id 19GFad-000FBB-00 for multi6@ops.ietf.org; Thu, 15 May 2003 10:03:55 +0000 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h4FA3ju9082132; Thu, 15 May 2003 12:03:46 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h4FA3bDk045678; Thu, 15 May 2003 12:03:39 +0200 Received: from dhcp22-123.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA35506 from ; Thu, 15 May 2003 12:03:35 +0200 Message-Id: <3EC36615.60E1A77A@hursley.ibm.com> Date: Thu, 15 May 2003 12:04:05 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Kurt Erik Lindqvist Cc: multi6@ops.ietf.org Subject: Architecture [Re: Agenda for Vienna] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tony Li wrote: ... > This implies that we should not be looking at particular > proposals. We should not even be looking at 'categories' > of proposals. Instead, we should be talking about possible > architectures. That's one layer farther up. This is *very* important. In the proposed second session, please let us concentrate on the architectural model of each of the two solution classes you want to explore. For example, whether we achieve identifier/locator separation by encapsulation, rewriting, 2-addresses-in-1-header, or 2-halves-in-1-address should be an implementation detail in the first level of discussion. Tony Li also wrote: > | Some notions that seem relatively undisputed: > | > | - we separate the identifier and locator functions so we can have > | multiple locators and still have a single identifier > | - IP in transit works with locators, everything above the > | IP layer with > | the identifier > | > > Do we really have consensus on these points? Does this imply that > tunneling is no longer a consideration? As I just said, I don't think that follows. Map-and-encap is just an implementation of id/loc separation, viewed from high enough. Brian From owner-multi6@ops.ietf.org Thu May 15 06:09:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02434 for ; Thu, 15 May 2003 06:09:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GFj8-000FZH-00 for multi6-data@psg.com; Thu, 15 May 2003 10:12:42 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19GFj6-000FZ1-00 for multi6@ops.ietf.org; Thu, 15 May 2003 10:12:40 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h4FABIn35460; Thu, 15 May 2003 12:11:18 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 15 May 2003 12:11:22 +0200 Subject: Re: Agenda for Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: "Tony Li" From: Iljitsch van Beijnum In-Reply-To: Message-Id: <941B8152-86BD-11D7-A2C3-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On donderdag, mei 15, 2003, at 10:02 Europe/Amsterdam, Tony Li wrote: > | Some notions that seem relatively undisputed: > | - we separate the identifier and locator functions so we can have > | multiple locators and still have a single identifier > | - IP in transit works with locators, everything above the > | IP layer with the identifier > Do we really have consensus on these points? Consensus is probably too big a word. "Relatively undisputed" is as far as I am prepared to go at this point... But do you see workable alternatives inside the loc/id realm? > Does this imply that tunneling is no longer a consideration? Tunneling is one way to implement a locator/identifier separation solution. Or are you referring to some other tunneling mechanism? From owner-multi6@ops.ietf.org Thu May 15 06:15:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02525 for ; Thu, 15 May 2003 06:15:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GFnq-000FlY-00 for multi6-data@psg.com; Thu, 15 May 2003 10:17:34 +0000 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 19GFnn-000FlK-00 for multi6@ops.ietf.org; Thu, 15 May 2003 10:17:32 +0000 From: Masataka Ohta Message-Id: <200305151004.TAA17461@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id TAA17461; Thu, 15 May 2003 19:04:11 +0900 Subject: Re: Mutli6 meeting in Vienna In-Reply-To: <1CCAD444-86BB-11D7-BDC5-000393520ED8@kurtis.pp.se> from Kurt Erik Lindqvist at "May 15, 2003 11:53:43 am" To: Kurt Erik Lindqvist Date: Thu, 15 May 2003 19:04:11 +0859 () CC: Coene Lode , "Bound, Jim" , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurt; > >> Again, I only see work being done on loc/id and some on host based > >> solutions. There are good and bad suggestions and characteristics in > >> both of those discussions. That are why we are having them. > > > > Personally for me, that's fine. > > > > I'm tired of repeated discussion against geo and GSE. > > To be honest, I don't see you make any comments on either of these. For GSE, read the draft. > Personally I would be > interested in seeing you write up a technical basis for your reasons > against these and then we could move from there. It has been there before the WG existed. I see no point repeating it here for you. Read the draft. For geo, I saw several good reasoning against it by someone else at the first several rounds that I see no point repeating it by myself. Masataka Ohta From owner-multi6@ops.ietf.org Thu May 15 06:23:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02594 for ; Thu, 15 May 2003 06:23:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GFvT-000G8R-00 for multi6-data@psg.com; Thu, 15 May 2003 10:25:27 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19GFvR-000G8C-00 for multi6@ops.ietf.org; Thu, 15 May 2003 10:25:25 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4FANs406995; Thu, 15 May 2003 13:23:54 +0300 Date: Thu, 15 May 2003 13:23:54 +0300 (EEST) From: Pekka Savola To: Masataka Ohta cc: Kurt Erik Lindqvist , Coene Lode , "Bound, Jim" , Subject: Re: Mutli6 meeting in Vienna In-Reply-To: <200305151004.TAA17461@necom830.hpcl.titech.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-21.2 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 15 May 2003, Masataka Ohta wrote: > Read the draft. Write the details. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Thu May 15 06:24:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02623 for ; Thu, 15 May 2003 06:24:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GFxR-000GBQ-00 for multi6-data@psg.com; Thu, 15 May 2003 10:27:29 +0000 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 19GFxO-000GBC-00 for multi6@ops.ietf.org; Thu, 15 May 2003 10:27:27 +0000 From: Masataka Ohta Message-Id: <200305151014.TAA17526@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id TAA17526; Thu, 15 May 2003 19:14:28 +0900 Subject: Re: Architecture [Re: Agenda for Vienna] In-Reply-To: <3EC36615.60E1A77A@hursley.ibm.com> from Brian E Carpenter at "May 15, 2003 12:04:05 pm" To: Brian E Carpenter Date: Thu, 15 May 2003 19:14:27 +0859 () CC: Kurt Erik Lindqvist , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Brian; > Tony Li wrote: > ... > > This implies that we should not be looking at particular > > proposals. We should not even be looking at 'categories' > > of proposals. Instead, we should be talking about possible > > architectures. That's one layer farther up. > > This is *very* important. In the proposed second session, please > let us concentrate on the architectural model of each of the > two solution classes you want to explore. My draft draft-ohta-e2e-multihoming-03.txt: The Architecture of End to End Multihoming discusses, as is obvious from its title, architectural issue on host based approach. It, of course, mention loc/id separation. > For example, whether we achieve identifier/locator separation > by encapsulation, rewriting, 2-addresses-in-1-header, or > 2-halves-in-1-address should be an implementation detail in > the first level of discussion. That's rather an implementation detail than an architecural issue. The more important architecural issue is which part of the Internet protocol suits must/should/may be affected. In my draft, I, so far, have identified, IP, TCP, non-TCP applications, DNS and IGP. Masataka Ohta From owner-multi6@ops.ietf.org Thu May 15 06:34:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02771 for ; Thu, 15 May 2003 06:34:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GG76-000GeB-00 for multi6-data@psg.com; Thu, 15 May 2003 10:37:28 +0000 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 19GG74-000Gdh-00 for multi6@ops.ietf.org; Thu, 15 May 2003 10:37:26 +0000 From: Masataka Ohta Message-Id: <200305151029.TAA17600@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id TAA17600; Thu, 15 May 2003 19:28:51 +0859 Subject: Re: Agenda for Vienna In-Reply-To: from Kurt Erik Lindqvist at "May 15, 2003 11:51:05 am" To: Kurt Erik Lindqvist Date: Thu, 15 May 2003 19:28:50 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurt; You are totally confused. > > Note that people, including chairs, insisting on a requirement draft > > have been deprecating to discuss specific proposals. > > I don't think we are at the stage of formal proposals yet. I think we > need to learn to walk before we start thinking of doing base-jumping. I never said "formal proposals". However, you said "proposals that have then been made formally to the IETF", which means "formal proposals". Do you need formal proposals or not? >> 3. The second session will be scheduled later in the week. This will > >> concentrate on the two main proposals that are currently being worked > >> on. > >> concentrate on the two main proposals that are currently being worked > >> on. > I only see two major solution "classes" that have any wider support > right now. Assuming you are requesting formal proposals, do you need formal proposals of classes? Or, do you need formal proposals of solutions? > >> it is very clear that there is only two > >> real solutions being worked on at the moment. > > > > Note that something being worked on is not better than something > > completed. > > Something with wide support is better than something completed. It's > not "first with code" it's "running code AND consensus". A class can not have code, a solution of a class can. Masataka Ohta From owner-multi6@ops.ietf.org Thu May 15 06:34:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02787 for ; Thu, 15 May 2003 06:34:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GG7T-000GgE-00 for multi6-data@psg.com; Thu, 15 May 2003 10:37:51 +0000 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 19GG7J-000Gf7-00 for multi6@ops.ietf.org; Thu, 15 May 2003 10:37:41 +0000 From: Masataka Ohta Message-Id: <200305151030.TAA17616@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id TAA17616; Thu, 15 May 2003 19:30:26 +0900 Subject: Re: Mutli6 meeting in Vienna In-Reply-To: from Pekka Savola at "May 15, 2003 01:23:54 pm" To: Pekka Savola Date: Thu, 15 May 2003 19:30:25 +0859 () CC: Kurt Erik Lindqvist , Coene Lode , "Bound, Jim" , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-9.5 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Pekka; > > Read the draft. > > Write the details. On which part of the draft? Read the draft and, if you want details, ask the questions. Masataka Ohta From owner-multi6@ops.ietf.org Thu May 15 06:39:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02841 for ; Thu, 15 May 2003 06:39:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GGBi-000GvJ-00 for multi6-data@psg.com; Thu, 15 May 2003 10:42:14 +0000 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 19GGBg-000Gv6-00 for multi6@ops.ietf.org; Thu, 15 May 2003 10:42:12 +0000 From: Masataka Ohta Message-Id: <200305151036.TAA17734@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id TAA17734; Thu, 15 May 2003 19:36:34 +0900 Subject: Re: Agenda for Vienna In-Reply-To: <7AC2E576-86B5-11D7-BDC5-000393520ED8@kurtis.pp.se> from Kurt Erik Lindqvist at "May 15, 2003 11:13:23 am" To: Kurt Erik Lindqvist Date: Thu, 15 May 2003 19:36:31 +0859 () CC: Iljitsch van Beijnum , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurt; You wrote me: > >> 1. We schedule two sessions. > > > > Why its not three 2H sessions? Have you tried? > > No. I don't see the need for it, and I don't think it would be useful. > If others disagree they are free to step forward. that the time constraint is artificially put by no one else but you. Then, you wrote Iljitsch that > Again, this is more a time constraint than anything else and would > depend on the amount of presentations. So, why not have three 2H sessions and stop saying "time constraint"? Masataka Ohta From owner-multi6@ops.ietf.org Thu May 15 06:58:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03050 for ; Thu, 15 May 2003 06:58:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GGTv-000HsQ-00 for multi6-data@psg.com; Thu, 15 May 2003 11:01:03 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19GGTg-000HrH-00 for multi6@ops.ietf.org; Thu, 15 May 2003 11:00:49 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h4FAxRn35641; Thu, 15 May 2003 12:59:27 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 15 May 2003 12:59:31 +0200 Subject: Re: Architecture [Re: Agenda for Vienna] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Masataka Ohta From: Iljitsch van Beijnum In-Reply-To: <200305151014.TAA17526@necom830.hpcl.titech.ac.jp> Message-Id: <4E1F074F-86C4-11D7-A2C3-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-28.3 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On donderdag, mei 15, 2003, at 12:15 Europe/Amsterdam, Masataka Ohta wrote: > My draft draft-ohta-e2e-multihoming-03.txt: > The Architecture of End to End Multihoming > discusses, as is obvious from its title, architectural issue on > host based approach. It, of course, mention loc/id separation. In this draft you say TCP (and other protocols, leaving those alone for a moment) should get multiple addresses from the application. This is what SCTP already does. I don't see how this is separating the locator and identifier functions, it's just more instances of the combined locator/identifier we're used to. I feel this approach isn't a good one both for architectural reasons and for deployment reasons (this simply needs too many changes to too many things). The current architecture doesn't differentiate between identifiers and locators so it imposes limits on one because of the requirements for the other. This is messy. Having more of those combined locator/identifier addresses just increases the mess linearly. On the other hand, separating the identifier and locator functions makes it possible to have both the advantages of a stable identifier and the advantages of flexible locators. However, I do agree that TCP knows much more about reachability than IP so in practice we'll want to take advantage of that. But there are other ways to skin this particular cat than selecting layer 4 as the place to solve the multihoming problem. From owner-multi6@ops.ietf.org Thu May 15 07:52:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04953 for ; Thu, 15 May 2003 07:52:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GHJW-000Kl1-00 for multi6-data@psg.com; Thu, 15 May 2003 11:54:22 +0000 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238]) by psg.com with esmtp (Exim 3.36 #1) id 19GHJU-000Kkp-00 for multi6@ops.ietf.org; Thu, 15 May 2003 11:54:20 +0000 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-5.de.ibm.com (8.12.9/8.12.8) with ESMTP id h4FBsGlr060648; Thu, 15 May 2003 13:54:16 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h4FBsGDk055386; Thu, 15 May 2003 13:54:16 +0200 Received: from dhcp22-123.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA25460 from ; Thu, 15 May 2003 13:54:14 +0200 Message-Id: <3EC38005.913A905A@hursley.ibm.com> Date: Thu, 15 May 2003 13:54:45 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Kurt Erik Lindqvist Cc: multi6@ops.ietf.org Subject: Re: Mutli6 meeting in Vienna References: <11EA153F-85F4-11D7-BDC5-000393520ED8@kurtis.pp.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-13.1 required=5.0 tests=BAYES_01,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kurt Erik Lindqvist wrote: ... > > > - can we break applications? > > if break=modify, we might be forced to. > > > - can we break transport protocols? > > see previous. > > > - can we break autoconfiguration? > > yes. > > > - can we break IP? > > yes > > > - can we break IPsec? > > isn't that transport? > On all these, please see goals 3.2.2 and 3.2.3 of the goals (ex-requirements) draft. If we don't meet those goals (carefully defined backwards compatibility with existing, shipped router and host code) the solution will be a non-starter. So certain things can be "broken" but only subject to real-world compatibility constraints with shipping code. Brian From owner-multi6@ops.ietf.org Thu May 15 08:05:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05519 for ; Thu, 15 May 2003 08:05:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GHW5-000LZL-00 for multi6-data@psg.com; Thu, 15 May 2003 12:07:21 +0000 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 19GHW2-000LYv-00 for multi6@ops.ietf.org; Thu, 15 May 2003 12:07:18 +0000 From: Masataka Ohta Message-Id: <200305151201.VAA18404@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id VAA18404; Thu, 15 May 2003 21:01:33 +0900 Subject: Re: Architecture [Re: Agenda for Vienna] In-Reply-To: <4E1F074F-86C4-11D7-A2C3-00039388672E@muada.com> from Iljitsch van Beijnum at "May 15, 2003 12:59:31 pm" To: Iljitsch van Beijnum Date: Thu, 15 May 2003 21:01:32 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Iljitsch; > > My draft draft-ohta-e2e-multihoming-03.txt: > > > The Architecture of End to End Multihoming > > > discusses, as is obvious from its title, architectural issue on > > host based approach. It, of course, mention loc/id separation. > > In this draft you say TCP (and other protocols, leaving those alone for > a moment) should get multiple addresses from the application. Well, basically, I say hosts should have multiple addresses. It is, of course, at IP layer. Protocols above IP are, expected to exploit the benefit of the feature. > This is > what SCTP already does. That's fine. > I don't see how this is separating the locator > and identifier functions, it's just more instances of the combined > locator/identifier we're used to. Reasoning in the draft is related to reverse look up with local addresses. The more strong reason is that implementation becomes a lot easier but is not an architectural point > I feel this approach isn't a good one both for architectural reasons > and for deployment reasons (this simply needs too many changes to too > many things). It is architecuturally of course that a change at the IP layer affects many things. As for deployment, change is optionaly. As I wrote several times already in this ML, our code is running interoperating with leagacy hosts. > The current architecture doesn't differentiate between > identifiers and locators so it imposes limits on one because of the > requirements for the other. This is messy. Having more of those > combined locator/identifier addresses just increases the mess linearly. That is an abstract nonsense against the running code. > On the other hand, separating the identifier and locator functions > makes it possible to have both the advantages of a stable identifier > and the advantages of flexible locators. > > However, I do agree that TCP knows much more about reachability than IP > so in practice we'll want to take advantage of that. But there are > other ways to skin this particular cat than selecting layer 4 as the > place to solve the multihoming problem. IP layer, (layer 3), of course, is the place to solve the problem of IP addresses. Layers above, including but not limited to 4, are, of course, affected. NAT is a example (hopefully to a reverse direction) of how a simple change at IP layer has tremendous effects on layers above. A good news with out code is that upper layers are not affected if a host or its peer chooses to stay to be as reliable as a singly homed host. Masataka Ohta From owner-multi6@ops.ietf.org Thu May 15 08:48:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07371 for ; Thu, 15 May 2003 08:48:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GIBW-000ONg-00 for multi6-data@psg.com; Thu, 15 May 2003 12:50:10 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19GIBI-000OLr-00 for multi6@ops.ietf.org; Thu, 15 May 2003 12:49:56 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h4FCmZn35869; Thu, 15 May 2003 14:48:35 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 15 May 2003 14:48:38 +0200 Subject: Re: Architecture [Re: Agenda for Vienna] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Masataka Ohta From: Iljitsch van Beijnum In-Reply-To: <200305151201.VAA18404@necom830.hpcl.titech.ac.jp> Message-Id: <8CA93838-86D3-11D7-A2C3-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On donderdag, mei 15, 2003, at 14:02 Europe/Amsterdam, Masataka Ohta wrote: >> In this draft you say TCP (and other protocols, leaving those alone >> for >> a moment) should get multiple addresses from the application. > Well, basically, I say hosts should have multiple addresses. It is, > of course, at IP layer. What I mean is that when an applications wants to connect to an application on another host, the first application has to find all the addresses for the correspondent host and give them to TCP so that TCP can start a session. I don't think this is the right approach. Applications should only work with one thing that identifiers the other end and not worry what happens on the network. (BTW, how does the second host learn the alternative addresses for the first host?) >> I feel this approach isn't a good one both for architectural reasons >> and for deployment reasons (this simply needs too many changes to too >> many things). > It is architecuturally of course that a change at the IP layer > affects many things. It shouldn't. > As for deployment, change is optionaly. All of the stuff we're discussing right now needs support from both ends in order for multihoming on one end to work. This means change is NOT optional, we need to get at least 95% of the internet to adopt this or we have failed. From owner-multi6@ops.ietf.org Thu May 15 09:18:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08175 for ; Thu, 15 May 2003 09:18:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GIef-0000Xs-00 for multi6-data@psg.com; Thu, 15 May 2003 13:20:17 +0000 Received: from pa-monroeville1d-140.pit.adelphia.net ([24.50.190.140] helo=localhost) by psg.com with esmtp (Exim 3.36 #1) id 19GIec-0000Xc-00 for multi6@ops.ietf.org; Thu, 15 May 2003 13:20:15 +0000 Received: from [192.168.1.100] (localhost [127.0.0.1]) by localhost (8.12.9/8.12.2) with ESMTP id h4FDKF9L002970 for ; Thu, 15 May 2003 09:20:16 -0400 (EDT) Date: Thu, 15 May 2003 09:20:14 -0400 From: "Michael H. Lambert" To: multi6@ops.ietf.org Subject: Re: IETF multihoming powder: just add IPv6 and stir Message-ID: <14693061.1052990414@[192.168.1.100]> In-Reply-To: <7D50032D-86A4-11D7-A2C3-00039388672E@muada.com> References: <7D50032D-86A4-11D7-A2C3-00039388672E@muada.com> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-24.8 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I agree that a few packets isn't enough to determine the bandwidth of a > path but with a higher number of packets this shouldn't be much of a > problem. But in these cases a partial routing table in the host would be > ok, I guess. > > Another approach is to use diffserv to signal packets should take the > high-bandwidth path. This doesn't scale well, but now I'm not sure how important that is. As long as a "good" path can be determined with no manual host configuration, then we're probably okay requiring more work for an optimal path. >> I think the right approach is to allow the functionality to be >> implemented hierarchically. > > What does that mean? All I mean is that if we have an architecture which allows the use of middle boxes, then a site (perhaps defined broadly enough to include a local/metropolitan/regional aggregation point) could have a set of such middle boxes. Those closer to the end host could ask those closer to the CE for path selection help. > I'm not saying there are no benefits, just that the downsides are much > bigger and that it would be unacceptable to mandate having a routing > table in each host. I agree, but it's equally unacceptable to prohibit it. The cases where it matters are few, but generally important to funding agencies. > I don't think setting the MTU based on the flow speed is useful: either > you can do it so you do it or you can't so you don't. But I agree there > isn't much point in having jumboframes in 10 or 100 Mbps equipment and it > seems vendors feel the same way because I have yet to encounter a < 1000 > Mbps ethernet NIC that supports them. The upshot is that discussion of MTU is off-topic for this WG, except as a metric for path selection. Michael From owner-multi6@ops.ietf.org Thu May 15 09:19:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08218 for ; Thu, 15 May 2003 09:19:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GIgr-0000gq-00 for multi6-data@psg.com; Thu, 15 May 2003 13:22:33 +0000 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 19GIgm-0000gZ-00 for multi6@ops.ietf.org; Thu, 15 May 2003 13:22:29 +0000 From: Masataka Ohta Message-Id: <200305151313.WAA18752@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id WAA18752; Thu, 15 May 2003 22:13:29 +0900 Subject: Re: Architecture [Re: Agenda for Vienna] In-Reply-To: <8CA93838-86D3-11D7-A2C3-00039388672E@muada.com> from Iljitsch van Beijnum at "May 15, 2003 02:48:38 pm" To: Iljitsch van Beijnum Date: Thu, 15 May 2003 22:13:28 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-11.9 required=5.0 tests=BAYES_10,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Iljitsch; > >> In this draft you say TCP (and other protocols, leaving those alone > >> for > >> a moment) should get multiple addresses from the application. > > > Well, basically, I say hosts should have multiple addresses. It is, > > of course, at IP layer. > > What I mean is that when an applications wants to connect to an > application on another host, the first application has to find all the > addresses for the correspondent host and give them to TCP so that TCP > can start a session. > > I don't think this is the right approach. Applications should only work > with one thing that identifiers the other end and not worry what > happens on the network. That's merely a terminology concern. Our TCP has an API accepting multiple addresses. We also support API over TCP accepting a DNS name of a peer and nothing more than that, which may be located at transport or application layer. An interesting property of the API is universal that it transparently works with IPv4, leagacy IPv6 and multihomed IPv6 peers. Or, there can be an API accepting ID of a peer, though it is not universal. Note that, architecturally, there is no real difference between transport and application layers on the best effort Internet, though, traditionally, something implemented in BSD kernel has been called transport. So, you can call all the APIs above TCP, if you so want. > (BTW, how does the second host learn the alternative addresses for the > first host?) Through DNS reverse and forward lookup, TCP option or some transport/application specific way. > > It is architecuturally of course that a change at the IP layer > > affects many things. > > It shouldn't. Remember that promoters of NAT was saying so. NAT was advertised to be a small harmless change. > > As for deployment, change is optionaly. > > All of the stuff we're discussing right now needs support from both > ends in order for multihoming on one end to work. This means change is > NOT optional, we need to get at least 95% of the internet to adopt this > or we have failed. Interesting. According to your logic, IPv6 have failed as IPv6 needs support from both ends in order for IPv6 on one end to work. As you know, far less than 95% of the Internet speak IPv6. So, don't bother to discuss IPv6 multihoming. On the other hand, the stuff we have finished is interoperating with 100% of the leagacy IPv6 hosts. Masataka Ohta From owner-multi6@ops.ietf.org Thu May 15 10:09:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09737 for ; Thu, 15 May 2003 10:09:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GJRz-0004aC-00 for multi6-data@psg.com; Thu, 15 May 2003 14:11:15 +0000 Received: from dhcp-9-211.ripemtg.ripe.net ([193.0.9.211] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 19GJRT-0004Z5-00 for multi6@ops.ietf.org; Thu, 15 May 2003 14:10:43 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h4FED5Tq014492; Thu, 15 May 2003 16:13:06 +0200 (CEST) Date: Thu, 15 May 2003 16:13:03 +0200 Subject: Re: Mutli6 meeting in Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Coene Lode , "Bound, Jim" , multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200305151004.TAA17461@necom830.hpcl.titech.ac.jp> Message-Id: <57AB9EE8-86DF-11D7-BDC5-000393520ED8@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-16.1 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>>> Again, I only see work being done on loc/id and some on host based >>>> solutions. There are good and bad suggestions and characteristics in >>>> both of those discussions. That are why we are having them. >>> >>> Personally for me, that's fine. >>> >>> I'm tired of repeated discussion against geo and GSE. >> >> To be honest, I don't see you make any comments on either of these. > > For GSE, read the draft. Are your comments in the draft? I have read the draft of the proposal. > >> Personally I would be >> interested in seeing you write up a technical basis for your reasons >> against these and then we could move from there. > > It has been there before the WG existed. > > I see no point repeating it here for you. > > Read the draft. This is the LIN6 draft? If so I will as soon as I am back from RIPE. > For geo, I saw several good reasoning against it by someone else > at the first several rounds that I see no point repeating it > by myself. > Good. Then that is clear. The problem (and this goes for the entire working group though - perhaps even for many other WGs) is that if people just agree and don't post, it's very hard to follow where people think we should go. I talk to a number of people and I have started getting a large number of private emails, and therefor think I have a pretty good feeling of what people seems to think. But that is not really an issue here for this discussion. - kurtis - From owner-multi6@ops.ietf.org Thu May 15 10:14:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10173 for ; Thu, 15 May 2003 10:14:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GJWx-00052l-00 for multi6-data@psg.com; Thu, 15 May 2003 14:16:23 +0000 Received: from dhcp-9-211.ripemtg.ripe.net ([193.0.9.211] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 19GJVv-0004x9-00 for multi6@ops.ietf.org; Thu, 15 May 2003 14:15:19 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h4FEHlTq014495; Thu, 15 May 2003 16:17:47 +0200 (CEST) Date: Thu, 15 May 2003 16:17:45 +0200 Subject: Re: Agenda for Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200305151029.TAA17600@necom830.hpcl.titech.ac.jp> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On torsdag, maj 15, 2003, at 12:29 Europe/Stockholm, Masataka Ohta wrote: > Kurt; > > You are totally confused. Thank you. > >>> Note that people, including chairs, insisting on a requirement draft >>> have been deprecating to discuss specific proposals. >> >> I don't think we are at the stage of formal proposals yet. I think we >> need to learn to walk before we start thinking of doing base-jumping. > > I never said "formal proposals". > > However, you said "proposals that have then been made formally > to the IETF", which means "formal proposals". > > Do you need formal proposals or not? With proposals that have been made formally I meant submitted to the IETF. That is enough. I will try and go out and ask the authors of what I can find that is in the current drafts directory to find presenters for the first session. If I miss someone, I am sure the WG will point that out to me. >>> 3. The second session will be scheduled later in the week. This will >>>> concentrate on the two main proposals that are currently being >>>> worked >>>> on. >>>> concentrate on the two main proposals that are currently being >>>> worked >>>> on. > >> I only see two major solution "classes" that have any wider support >> right now. > > Assuming you are requesting formal proposals, do you need formal > proposals of classes? > > Or, do you need formal proposals of solutions? For the first session I am looking at the drafts submitted. >>>> it is very clear that there is only two >>>> real solutions being worked on at the moment. >>> >>> Note that something being worked on is not better than something >>> completed. >> >> Something with wide support is better than something completed. It's >> not "first with code" it's "running code AND consensus". > > A class can not have code, a solution of a class can. > And both can have support or not have to support. - kurtis - From owner-multi6@ops.ietf.org Thu May 15 10:14:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10247 for ; Thu, 15 May 2003 10:14:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GJXU-00057N-00 for multi6-data@psg.com; Thu, 15 May 2003 14:16:56 +0000 Received: from dhcp-9-211.ripemtg.ripe.net ([193.0.9.211] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 19GJWq-00052R-00 for multi6@ops.ietf.org; Thu, 15 May 2003 14:16:16 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h4FEIbTq014498; Thu, 15 May 2003 16:18:37 +0200 (CEST) Date: Thu, 15 May 2003 16:18:34 +0200 Subject: Re: Agenda for Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Iljitsch van Beijnum , multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200305151036.TAA17734@necom830.hpcl.titech.ac.jp> Message-Id: <1CD326FC-86E0-11D7-BDC5-000393520ED8@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On torsdag, maj 15, 2003, at 12:37 Europe/Stockholm, Masataka Ohta wrote: > Kurt; > > You wrote me: > >>>> 1. We schedule two sessions. >>> >>> Why its not three 2H sessions? Have you tried? >> >> No. I don't see the need for it, and I don't think it would be useful. >> If others disagree they are free to step forward. > > that the time constraint is artificially put by no one else but you. Correct. For the reason stated above. - kurtis - From owner-multi6@ops.ietf.org Thu May 15 10:20:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10556 for ; Thu, 15 May 2003 10:20:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GJbt-0005Uc-00 for multi6-data@psg.com; Thu, 15 May 2003 14:21:29 +0000 Received: from dhcp-9-211.ripemtg.ripe.net ([193.0.9.211] helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 19GJbN-0005Tr-00 for multi6@ops.ietf.org; Thu, 15 May 2003 14:20:57 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h4FENRTq014501; Thu, 15 May 2003 16:23:27 +0200 (CEST) Date: Thu, 15 May 2003 16:23:25 +0200 Subject: Re: Mutli6 meeting in Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Brian E Carpenter From: Kurt Erik Lindqvist In-Reply-To: <3EC38005.913A905A@hursley.ibm.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On torsdag, maj 15, 2003, at 13:54 Europe/Stockholm, Brian E Carpenter wrote: > Kurt Erik Lindqvist wrote: > ... >> >>> - can we break applications? >> >> if break=modify, we might be forced to. >> >>> - can we break transport protocols? >> >> see previous. >> >>> - can we break autoconfiguration? >> >> yes. >> >>> - can we break IP? >> >> yes >> >>> - can we break IPsec? >> >> isn't that transport? >> > > On all these, please see goals 3.2.2 and 3.2.3 of the goals > (ex-requirements) > draft. If we don't meet those goals (carefully defined backwards > compatibility with existing, shipped router and host code) the solution > will be a non-starter. So certain things can be "broken" but only > subject > to real-world compatibility constraints with shipping code. > Agreed. - kurtis - From owner-multi6@ops.ietf.org Thu May 15 11:04:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11708 for ; Thu, 15 May 2003 11:04:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GKJQ-0009ZO-00 for multi6-data@psg.com; Thu, 15 May 2003 15:06:28 +0000 Received: from mail4.microsoft.com ([131.107.3.122]) by psg.com with esmtp (Exim 3.36 #1) id 19GKIv-0009Yg-00 for multi6@ops.ietf.org; Thu, 15 May 2003 15:05:57 +0000 Received: from mail6.microsoft.com ([157.54.6.196]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 15 May 2003 08:05:56 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 15 May 2003 08:05:55 -0700 Received: from 157.54.8.109 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 15 May 2003 08:05:55 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 15 May 2003 08:05:55 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 15 May 2003 08:05:54 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Thu, 15 May 2003 08:05:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Mutli6 meeting in Vienna Date: Thu, 15 May 2003 08:05:51 -0700 Message-ID: Thread-Topic: Mutli6 meeting in Vienna thread-index: AcMa7zRQufAbzMC4SbGVrrToPItqUgAAwz7g From: "Christian Huitema" To: "Kurt Erik Lindqvist" , "Brian E Carpenter" Cc: X-OriginalArrivalTime: 15 May 2003 15:05:54.0189 (UTC) FILETIME=[7B24CBD0:01C31AF3] X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA11708 > >>> - can we break applications? > >> > >> if break=modify, we might be forced to. > >> > >>> - can we break transport protocols? > >> > >> see previous. > >> > >>> - can we break autoconfiguration? > >> > >> yes. > >> > >>> - can we break IP? > >> > >> yes > >> > >>> - can we break IPsec? > >> > >> isn't that transport? I think we have to qualify "break". I would personally say "augment" rather than "break". The basic idea should be: 1) An unmodified implementation continues working, and receives at least the same quality of service as if the local site was not multi-homed, or the correspondent node was not multi-homed. 2) An augmented implementation gains benefits such as survival of sessions, or migration of associations from a low quality path to a higher quality path. In practice, that means that we cannot "break" transports, IP or IPSEC. However, we should be able to augment each of them. For example, if a transport or IPSEC gain some notion of IP-address-independent session, then it should be possible to use several "locator pairs" between two entities. If two hosts have been augmented to support multi-homing adaptations, then they should be able to cooperate. If auto-configuration is augmented to provide support for multi-homing, then augmented implementations should take advantage of it. -- Christian Huitema From owner-multi6@ops.ietf.org Thu May 15 12:33:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14467 for ; Thu, 15 May 2003 12:33:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GLhE-000IUA-00 for multi6-data@psg.com; Thu, 15 May 2003 16:35:08 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19GLhC-000ITo-00; Thu, 15 May 2003 16:35:06 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.14) id 19GLh9-0001CK-Sa; Thu, 15 May 2003 18:35:03 +0200 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 15 May 2003 18:35:03 +0200 To: Masataka Ohta Cc: multi6@ops.ietf.org Subject: Re: Mutli6 meeting in Vienna References: <200305151030.TAA17616@necom830.hpcl.titech.ac.jp> Message-Id: X-Spam-Status: No, hits=-12.3 required=5.0 tests=BAYES_10,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Read the draft and, if you want details, ask the questions. drafts are supposed to be pretty complete. if you want to be taken seriously, get serious. randy From owner-multi6@ops.ietf.org Thu May 15 12:33:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14490 for ; Thu, 15 May 2003 12:33:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GLil-000IXf-00 for multi6-data@psg.com; Thu, 15 May 2003 16:36:43 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19GLij-000IWy-00; Thu, 15 May 2003 16:36:41 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.14) id 19GLig-0001CP-Lj; Thu, 15 May 2003 18:36:38 +0200 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 15 May 2003 18:36:38 +0200 To: Masataka Ohta Cc: multi6@ops.ietf.org Subject: Re: Agenda for Vienna References: <7AC2E576-86B5-11D7-BDC5-000393520ED8@kurtis.pp.se> <200305151036.TAA17734@necom830.hpcl.titech.ac.jp> Message-Id: X-Spam-Status: No, hits=-15.5 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > So, why not have three 2H sessions and stop saying "time constraint"? because you will need a different AD to approve it. this wg has yet to show good use of one session. you don't get any pudding unless you eat your meat. randy From owner-multi6@ops.ietf.org Thu May 15 17:05:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23067 for ; Thu, 15 May 2003 17:05:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GPvH-0003hX-00 for multi6-data@psg.com; Thu, 15 May 2003 21:05:55 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19GPuk-0003Vn-00 for multi6@ops.ietf.org; Thu, 15 May 2003 21:05:23 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h4FL40n36475; Thu, 15 May 2003 23:04:01 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 15 May 2003 23:04:03 +0200 Subject: Re: Mutli6 meeting in Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: "Christian Huitema" From: Iljitsch van Beijnum In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-28.3 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On donderdag, mei 15, 2003, at 17:05 Europe/Amsterdam, Christian Huitema wrote: > I think we have to qualify "break". I would personally say "augment" > rather than "break". Yes, I was very imprecise here. There are several things that can happen, including the requirement to change something. I think it would be a mistake to require both hosts and routers to change, as it pretty much doubles the required deployment efforts needed to get this off the ground. Requiring applications to change is absolutely a nonstarter as we'll have single homed applications for decades that way. > The basic idea should be: > 1) An unmodified implementation continues working, and receives at > least > the same quality of service as if the local site was not multi-homed, > or > the correspondent node was not multi-homed. Supporting single homed correspondents is essential but I don't care much for single homed hosts in a multihomed site. Upgrade already. It's not like there is a huge installed base of stuff that isn't supported any more in IPv6. > In practice, that means that we cannot "break" transports, IP or IPSEC. > However, we should be able to augment each of them. It would be better if we didn't have to... > If auto-configuration is augmented to provide support for multi-homing, > then augmented implementations should take advantage of it. It might be challenging to change autoconfiguration so it can assign an identifier as well as a number of locators. From owner-multi6@ops.ietf.org Thu May 15 17:45:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24228 for ; Thu, 15 May 2003 17:45:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GQZs-000AW5-00 for multi6-data@psg.com; Thu, 15 May 2003 21:47:52 +0000 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 19GQZM-000ARz-00; Thu, 15 May 2003 21:47:20 +0000 From: Masataka Ohta Message-Id: <200305152139.GAA20195@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id GAA20195; Fri, 16 May 2003 06:38:57 +0859 Subject: Re: Mutli6 meeting in Vienna In-Reply-To: from Randy Bush at "May 15, 2003 06:35:03 pm" To: Randy Bush Date: Fri, 16 May 2003 06:38:55 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Randy; > > Read the draft and, if you want details, ask the questions. > > drafts are supposed to be pretty complete. if you want to be taken > seriously, get serious. My draft is complete, as an architectural one. Remember that the first version was taken seriously by you and Harald. Masataka Ohta From owner-multi6@ops.ietf.org Thu May 15 17:46:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24247 for ; Thu, 15 May 2003 17:46:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GQaR-000AXM-00 for multi6-data@psg.com; Thu, 15 May 2003 21:48:27 +0000 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 19GQZP-000ARz-00; Thu, 15 May 2003 21:47:23 +0000 From: Masataka Ohta Message-Id: <200305152137.GAA20188@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id GAA20188; Fri, 16 May 2003 06:37:18 +0900 Subject: Re: Agenda for Vienna In-Reply-To: from Randy Bush at "May 15, 2003 06:36:38 pm" To: Randy Bush Date: Fri, 16 May 2003 06:37:17 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Randy; > > So, why not have three 2H sessions and stop saying "time constraint"? > > because you will need a different AD to approve it. According to Kurt, no. >>> Are you saying that you have tried to request 3 slots and denied by >>> IESG? >>> >>> Or, are you just saying you are not so sure? >> >> I am saying that I do not think it would be useful for us to request >> three slots. I don't think that will move us forward. the problem was and still is "I (Kurt) do not think it would be useful" that it is at the chair(s), not at IESG (yet). > this wg has yet > to show good use of one session. you don't get any pudding unless > you eat your meat. We are not yet at the table to eat the meat. We are hungry that I'm saying to sit and check menu. Masataka Ohta From owner-multi6@ops.ietf.org Thu May 15 17:56:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24447 for ; Thu, 15 May 2003 17:56:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GQjs-000C85-00 for multi6-data@psg.com; Thu, 15 May 2003 21:58:12 +0000 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 19GQjN-000C13-00 for multi6@ops.ietf.org; Thu, 15 May 2003 21:57:41 +0000 From: Masataka Ohta Message-Id: <200305152147.GAA20255@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id GAA20255; Fri, 16 May 2003 06:47:17 +0900 Subject: Re: Agenda for Vienna In-Reply-To: <1CD326FC-86E0-11D7-BDC5-000393520ED8@kurtis.pp.se> from Kurt Erik Lindqvist at "May 15, 2003 04:18:34 pm" To: Kurt Erik Lindqvist Date: Fri, 16 May 2003 06:47:16 +0859 () CC: Iljitsch van Beijnum , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.5 required=5.0 tests=BAYES_00,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurt; > > that the time constraint is artificially put by no one else but you. > > Correct. For the reason stated above. Then, how can you say Iljitsch that > Again, this is more a time constraint than anything else and would > depend on the amount of presentations. Randy, this is not a problem of AD. Masataka Ohta From owner-multi6@ops.ietf.org Thu May 15 17:57:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24484 for ; Thu, 15 May 2003 17:57:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GQl0-000CJr-00 for multi6-data@psg.com; Thu, 15 May 2003 21:59:22 +0000 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 19GQjZ-000C7b-00 for multi6@ops.ietf.org; Thu, 15 May 2003 21:57:53 +0000 From: Masataka Ohta Message-Id: <200305152145.GAA20248@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id GAA20248; Fri, 16 May 2003 06:45:15 +0900 Subject: Re: Mutli6 meeting in Vienna In-Reply-To: <5FE3B449-85E4-11D7-BDC5-000393520ED8@kurtis.pp.se> from Kurt Erik Lindqvist at "May 14, 2003 10:16:33 am" To: Kurt Erik Lindqvist Date: Fri, 16 May 2003 06:45:14 +0859 () CC: Coene Lode , "Bound, Jim" , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurt; > >>> You miss LIN6. > >> > >> What is the draft name? I can't seem to find this. > > > > I will prepare it, if there is a chance for presentation. > > I got the draft mail to me in private. Reading to it quickly I noticed > that parts of this solution is actually pending patent? As I say "I will prepare it", that is not my draft. LIN6 was originally proposed by Prof. Teraoka and he seems to have tried to get patent on something. After that, I use some quite generic componet of LIN6 to make it a solution for multihoming. I don't know whether the pending patent is useless or strong enough to cover all the multihoming solutions. Ask Prof. Teraoka. Masataka Ohta From owner-multi6@ops.ietf.org Thu May 15 18:06:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24757 for ; Thu, 15 May 2003 18:06:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GQtp-000E1H-00 for multi6-data@psg.com; Thu, 15 May 2003 22:08:29 +0000 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 19GQsn-000DmS-00 for multi6@ops.ietf.org; Thu, 15 May 2003 22:07:25 +0000 From: Masataka Ohta Message-Id: <200305152154.GAA20327@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id GAA20327; Fri, 16 May 2003 06:54:02 +0900 Subject: Re: Mutli6 meeting in Vienna In-Reply-To: <57AB9EE8-86DF-11D7-BDC5-000393520ED8@kurtis.pp.se> from Kurt Erik Lindqvist at "May 15, 2003 04:13:03 pm" To: Kurt Erik Lindqvist Date: Fri, 16 May 2003 06:54:02 +0859 () CC: Coene Lode , "Bound, Jim" , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurt; > >>> I'm tired of repeated discussion against geo and GSE. > >> > >> To be honest, I don't see you make any comments on either of these. > > > > For GSE, read the draft. > > > Are your comments in the draft? Yes. "The Architecture of End to End Multihoming" has been there with several revisions each posted to the ML. You can dig it, or I can mail you privately. > I have read the draft of the proposal. It is not a draft of a proposal. > > For geo, I saw several good reasoning against it by someone else > > at the first several rounds that I see no point repeating it > > by myself. > > > > Good. Then that is clear. The problem (and this goes for the entire > working group though - perhaps even for many other WGs) is that if > people just agree and don't post, it's very hard to follow where people > think we should go. That could be a valid argument for the first and, maybe, second round with little posting. However, at all the round, many people just disagreed and posted that it is not even so. Anyway, at the third round and thereafter, it is a poor management to allow same topic repeated again and again. Masataka Ohta From owner-multi6@ops.ietf.org Thu May 15 18:12:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25404 for ; Thu, 15 May 2003 18:12:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GQzc-000Eu1-00 for multi6-data@psg.com; Thu, 15 May 2003 22:14:28 +0000 Received: from host217-37-202-105.in-addr.btopenworld.com ([217.37.202.105] helo=ab.use.net) by psg.com with esmtp (Exim 3.36 #1) id 19GQyy-000EmK-00 for multi6@ops.ietf.org; Thu, 15 May 2003 22:13:48 +0000 Received: from ab.use.net (conf.use.net [217.37.202.109]) by ab.use.net (Postfix) with ESMTP id EC3E639683; Thu, 15 May 2003 22:13:46 +0000 (GMT) Date: Thu, 15 May 2003 23:13:46 +0100 Subject: Re: Mutli6 meeting in Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Sean Doran , Randy Bush , multi6@ops.ietf.org To: Masataka Ohta From: Sean Doran In-Reply-To: <200305152139.GAA20195@necom830.hpcl.titech.ac.jp> Message-Id: <7F507F1E-8722-11D7-9EEC-0003938E4DE4@ab.use.net> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday, May 15, 2003, at 22:39 Europe/London, Masataka Ohta wrote: > Remember that the first version was taken seriously by you and > Harald. And me. However, two things stand out: (i) I made a number of comments and asked some questions on the list after having read through your draft; and (ii) The draft is old and needs a refresh. I wonder if you could be persuaded to submit a new revision in light of these two points? Sean. From owner-multi6@ops.ietf.org Thu May 15 18:16:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25841 for ; Thu, 15 May 2003 18:16:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GR3T-000FRG-00 for multi6-data@psg.com; Thu, 15 May 2003 22:18:27 +0000 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 19GR2S-000FBk-00 for multi6@ops.ietf.org; Thu, 15 May 2003 22:17:24 +0000 From: Masataka Ohta Message-Id: <200305152208.HAA20401@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id HAA20401; Fri, 16 May 2003 07:08:00 +0900 Subject: Re: Agenda for Vienna In-Reply-To: from Kurt Erik Lindqvist at "May 15, 2003 04:17:45 pm" To: Kurt Erik Lindqvist Date: Fri, 16 May 2003 07:08:00 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurt; > > You are totally confused. > > Thank you. You are welcome. > With proposals that have been made formally I meant submitted to the > IETF. That is enough. I will try and go out and ask the authors of what > I can find that is in the current drafts directory to find presenters > for the first session. If I miss someone, I am sure the WG will point > that out to me. Please first ask all the people to be the authors by call for drafts. > >>> Note that people, including chairs, insisting on a requirement draft > >>> have been deprecating to discuss specific proposals. > > Or, do you need formal proposals of solutions? > > For the first session I am looking at the drafts submitted. Which drafts? On classes or on solutions? Please call for them clarifying it. > >>>> it is very clear that there is only two > >>>> real solutions being worked on at the moment. > >> Something with wide support is better than something completed. It's > >> not "first with code" it's "running code AND consensus". > > > > A class can not have code, a solution of a class can. > And both can have support or not have to support. But, solutions can be evaluated only after classes are chosen. It is fine for you to say: it is very clear that there is only two real classes being worked on at the moment. but, you said: it is very clear that there is only two real solutions being worked on at the moment. That is, you are totally confused. Masataka Ohta From owner-multi6@ops.ietf.org Thu May 15 22:03:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29492 for ; Thu, 15 May 2003 22:03:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GUZd-000BKA-00 for multi6-data@psg.com; Fri, 16 May 2003 02:03:53 +0000 Received: from [3ffe:501:100c:d120::53] (helo=shonan.sfc.wide.ad.jp) by psg.com with esmtp (Exim 3.36 #1) id 19GUZ7-000BIf-00 for multi6@ops.ietf.org; Fri, 16 May 2003 02:03:22 +0000 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id B72215D0CC for ; Fri, 16 May 2003 11:02:50 +0900 (JST) Date: Fri, 16 May 2003 11:00:31 +0900 From: Thierry Ernst To: multi6@ops.ietf.org Subject: Re: Architecture [Re: Agenda for Vienna] Message-Id: <20030516110031.4425d7b2.ernst@sfc.wide.ad.jp> In-Reply-To: <200305151313.WAA18752@necom830.hpcl.titech.ac.jp> References: <8CA93838-86D3-11D7-A2C3-00039388672E@muada.com> <200305151313.WAA18752@necom830.hpcl.titech.ac.jp> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-25.8 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > All of the stuff we're discussing right now needs support from both > > ends in order for multihoming on one end to work. This means change is > > NOT optional, we need to get at least 95% of the internet to adopt this > > or we have failed. Definitely, if a solution does not require changes at the end nodes, this solution should be favored. New protocols shouldn't require change at all implementations to work. This is a bit too late. If we need to update exisiting implementations everytime there is a new feature on the table, IPv6 cannot be deployed. My point is that modifications at the other end should be done ONLY as an OPTION to make a feature work BETTER. Same as MIPv6: if you don't implement the CN operation at the other end node's side, it still works, but not efficiently. My 2 euro cents. Thierry. From owner-multi6@ops.ietf.org Fri May 16 07:10:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19043 for ; Fri, 16 May 2003 07:10:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Gd6i-000AIW-00 for multi6-data@psg.com; Fri, 16 May 2003 11:10:36 +0000 Received: from d12lmsgate-4.de.ibm.com ([194.196.100.237]) by psg.com with esmtp (Exim 3.36 #1) id 19Gd5p-000A8m-00 for multi6@ops.ietf.org; Fri, 16 May 2003 11:09:41 +0000 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-4.de.ibm.com (8.12.9/8.12.8) with ESMTP id h4GB9bDI028986 for ; Fri, 16 May 2003 13:09:38 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h4GB9aEw080224 for ; Fri, 16 May 2003 13:09:37 +0200 Received: from dhcp22-123.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA33908 from ; Fri, 16 May 2003 13:09:34 +0200 Message-Id: <3EC4C70C.69CB0560@hursley.ibm.com> Date: Fri, 16 May 2003 13:10:04 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: multi6@ops.ietf.org Subject: Re: Mutli6 meeting in Vienna References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: ... > > 1) An unmodified implementation continues working, and receives at > > least > > the same quality of service as if the local site was not multi-homed, > > or > > the correspondent node was not multi-homed. > > Supporting single homed correspondents is essential but I don't care > much for single homed hosts in a multihomed site. Upgrade already. It's > not like there is a huge installed base of stuff that isn't supported > any more in IPv6. Well, pretty much every operating system image shipped today includes RFC 2460 support. So I suspect the installed (but not enabled) base is in fact huge. At least in a large corporate network, routers and hosts are *not* upgraded in a coordinated way. So 'upgrade already' won't fly. We need incremental deployment; that has always been the guiding principle for IPv6 coexistence. Brian From owner-multi6@ops.ietf.org Fri May 16 07:23:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19627 for ; Fri, 16 May 2003 07:23:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GdLE-000C7w-00 for multi6-data@psg.com; Fri, 16 May 2003 11:25:36 +0000 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 19GdKK-000C5B-00 for multi6@ops.ietf.org; Fri, 16 May 2003 11:24:40 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19279; Fri, 16 May 2003 07:21:33 -0400 (EDT) Message-Id: <200305161121.HAA19279@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-de-launois-multi6-naros-00.txt Date: Fri, 16 May 2003 07:21:33 -0400 X-Spam-Status: No, hits=0.0 required=5.0 tests=BAYES_20,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NAROS : Host-Centric IPv6 Multihoming with Traffic Engineering Author(s) : C. de Launois, O. Bonaventure Filename : draft-de-launois-multi6-naros-00.txt Pages : 19 Date : 2003-5-15 More and more ISPs are multihomed and need to engineer their interdomain traffic. Unfortunately, both multihoming and traffic engineering contribute to the growth of the BGP routing tables. For IPv6, a better solution for multihoming and traffic engineering is required. This document proposes a host-centric IPv6 multihoming solution that relies on the utilization of a 'Name, Address and ROute System' (NAROS) server. A key advantage of using this server is that it allows a multihomed site to engineer its interdomain traffic without transmitting any BGP message. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-de-launois-multi6-naros-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-de-launois-multi6-naros-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-de-launois-multi6-naros-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: <2003-5-15145555.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-de-launois-multi6-naros-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-de-launois-multi6-naros-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-15145555.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-multi6@ops.ietf.org Fri May 16 11:22:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28943 for ; Fri, 16 May 2003 11:22:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Gh48-000NZ0-00 for multi6-data@psg.com; Fri, 16 May 2003 15:24:12 +0000 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #1) id 19Gh44-000NYS-00 for multi6@ops.ietf.org; Fri, 16 May 2003 15:24:08 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA18101 for ; Fri, 16 May 2003 16:24:06 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id QAA28588 for ; Fri, 16 May 2003 16:24:06 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h4GFO6N04476 for multi6@ops.ietf.org; Fri, 16 May 2003 16:24:06 +0100 Date: Fri, 16 May 2003 16:24:06 +0100 From: Tim Chown To: multi6@ops.ietf.org Subject: Re: Mutli6 meeting in Vienna Message-ID: <20030516152406.GS851@login.ecs.soton.ac.uk> Mail-Followup-To: multi6@ops.ietf.org References: <3EC4C70C.69CB0560@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EC4C70C.69CB0560@hursley.ibm.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-38.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, May 16, 2003 at 01:10:04PM +0200, Brian E Carpenter wrote: > > Well, pretty much every operating system image shipped today includes > RFC 2460 support. So I suspect the installed (but not enabled) base > is in fact huge. At least in a large corporate network, routers and > hosts are *not* upgraded in a coordinated way. So 'upgrade already' > won't fly. We need incremental deployment; that has always been the > guiding principle for IPv6 coexistence. Agreed. My view is that there should be three thrusts to multi6 at present, which may be a bit more contentious. 1. We pursue Christian's suggestion for bite by bite implementation of multi-addressing in SOHO-class and small networks with one or two routers connecting to two ISPs. That means ingress filtering avoidance, etc, adding new tricks where needed (e.g. new ICMP message) and resuing existing tools from our toolbox where possible. These may become usable within 1-2 years. 2. We allocate suitably large enterprises /32 prefixes (as per Craig's suggestion), for some definition of "suitably large", out of some new /16 prefix. There would only be a few thousand of these for the next 2-3 years, most likely. 3. We pursue the longer-term goal of identifier-locator separation for multihoming (and other benefits). This probably wouldn't lead to deployment for at least 2-3 years, maybe more. With #1 we can multihome for the majority of multihomers - the home networks, SME's and networks where multi-address methods can work and do not (usually) need policy management (of the type Craig mentions). With #2 we create a small swamp, but one we can fence off. It helps remove the perceived barrier for deployment in large enterprises or corporations. With #3 we plan for the future, with incremental deployment of two-space solutions being the goal. It might include HIP as a motivator, or maybe something like Iljitsch's recent proposal. I suspect #1 and #3 would not be too contentous, #2 might be :) I'd like to see some discussion of #1 and #3 in Vienna, where probably #1 is more "piecemeal" and #3 more "architectural". Tim From owner-multi6@ops.ietf.org Fri May 16 12:27:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01688 for ; Fri, 16 May 2003 12:27:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Gi55-0008XY-00 for multi6-data@psg.com; Fri, 16 May 2003 16:29:15 +0000 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.36 #1) id 19Gi53-0008XL-00 for multi6@ops.ietf.org; Fri, 16 May 2003 16:29:13 +0000 Received: (qmail 57728 invoked by uid 0); 16 May 2003 16:29:12 -0000 Received: from localhost.automagic.org (HELO isc.org) (root@127.0.0.1) by localhost.automagic.org with SMTP; 16 May 2003 16:29:12 -0000 Date: Fri, 16 May 2003 12:29:34 -0400 Subject: Re: comments on requirements-05 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Kurt Erik Lindqvist" , To: "Bound, Jim" From: Joe Abley In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B0341193B@tayexc13.americas.cpqcorp.net> Message-Id: <941278B4-87BB-11D7-92E4-00039312C852@isc.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sunday, May 11, 2003, at 05:02 Canada/Eastern, Bound, Jim wrote: > I see nothing worth complaining about I think this req doc is in far > better shape than before. > > Two notes: > > 1. Add Noel's list for clarity to the reqs. I'm almost finished with edits to -05, but I can't find Noel's list in my multi6 folder. Could someone point me in the right direction? From owner-multi6@ops.ietf.org Fri May 16 12:47:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02452 for ; Fri, 16 May 2003 12:47:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GiPQ-000Cru-00 for multi6-data@psg.com; Fri, 16 May 2003 16:50:16 +0000 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 19GiPM-000Cqw-00 for multi6@ops.ietf.org; Fri, 16 May 2003 16:50:12 +0000 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h4GGoAtU020596; Fri, 16 May 2003 12:50:10 -0400 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id h4GGo9xt020595; Fri, 16 May 2003 12:50:09 -0400 Date: Fri, 16 May 2003 12:50:09 -0400 From: "J. Noel Chiappa" Message-Id: <200305161650.h4GGo9xt020595@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: comments on requirements-05 Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Joe Abley > I'm almost finished with edits to -05, but I can't find Noel's list in > my multi6 folder. Could someone point me in the right direction? Done. Noel From owner-multi6@ops.ietf.org Fri May 16 13:25:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04197 for ; Fri, 16 May 2003 13:25:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Gizv-000KTd-00 for multi6-data@psg.com; Fri, 16 May 2003 17:27:59 +0000 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.36 #1) id 19Gizo-000KSO-00 for multi6@ops.ietf.org; Fri, 16 May 2003 17:27:52 +0000 Received: (qmail 61638 invoked by uid 0); 16 May 2003 17:27:50 -0000 Received: from localhost.automagic.org (HELO isc.org) (root@127.0.0.1) by localhost.automagic.org with SMTP; 16 May 2003 17:27:50 -0000 Date: Fri, 16 May 2003 13:28:13 -0400 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: multipart/mixed; boundary=Apple-Mail-12--363034386 Subject: requirements-06 From: Joe Abley To: multi6@ops.ietf.org Message-Id: X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-11.5 required=5.0 tests=BAYES_20,HTML_10_20,PATCH_UNIFIED_DIFF,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk --Apple-Mail-12--363034386 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Revised draft, attached below, has been sent in and should appear in the usual places in due course. Apologies for the delay in making these changes. RFC 2629 source diff follows. [jabley@snowfall]% cvs diff -u -r 1.5 -r 1.6 draft-ietf-multi6-multihoming-requirements.xml Index: draft-ietf-multi6-multihoming-requirements.xml =================================================================== RCS file: /home/cvs/doc/ietf/draft-ietf-multi6-multihoming-requirements.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- draft-ietf-multi6-multihoming-requirements.xml 16 Apr 2003 13:40:47 -0000 1.5 +++ draft-ietf-multi6-multihoming-requirements.xml 16 May 2003 17:19:43 -0000 1.6 @@ -5,7 +5,7 @@ - + Goals for IPv6 Site-Multihoming Architectures @@ -15,13 +15,13 @@ <organization abbrev="ISC">Internet Software Consortium</organization> <address> <postal> - <street>10805 Old River Road</street> - <country>Canada</country> - <code>N0L 1R0</code> - <region>ON</region> - <city>Komoka</city> + <street>950 Charter Street</street> + <country>USA</country> + <code>94063</code> + <region>CA</region> + <city>Redwood City</city> </postal> - <phone>+1 519 641 4368</phone> + <phone>+1 650 423 1317</phone> <email>jabley@isc.org</email> </address> </author> @@ -43,7 +43,7 @@ <date month="April" year="2003" /> <area>Operations and Management</area> - <workgroup>multi6</workgroup> + <workgroup>Network Working Group</workgroup> <abstract> <t>Site-multihoming, i.e. connecting to more than one IP service @@ -65,16 +65,15 @@ <t>However, it appears that this hierarchy is being supplanted by a dense mesh - of interconnections <xref target="refs.Huston" />. Additionally, + of interconnections <xref target="refs.RFC3221" />. Additionally, there has been an enormous growth in the number of multihomed sites. For purposes of redundancy and load-sharing, the - multihomed address blocks, which are almost always a longer prefix - than the provider aggregate, are announced along with the larger, - covering - aggregate originated by the provider. This contributes to the - rapidly-increasing size - of the global routing table. This explosion places significant - stress on the inter-provider routing system.</t> + multihomed address blocks are introduced into the global table + even if they are covered by a provider aggregate. + This contributes to the + rapidly-increasing size of both + the global routing table and the turbulence exhibited within + it, and places stress on the inter-provider routing system.</t> <t>Continued growth of both the Internet and the practice of site-multihoming will seriously exacerbate this stress. The @@ -123,7 +122,8 @@ circuits ordered from different suppliers and connecting a site to independent transit providers may share a single conduit from the street into a building; in this case - backhoe-fade of both circuits may be experienced due to a + physical disruption (sometimes referred to as + "backhoe-fade") of both circuits may be experienced due to a single incident in the street. The two circuits are said to "share fate".</t> @@ -146,7 +146,7 @@ <section anchor="loadshare" title="Load Sharing"> <t>By multihoming, a site should be able to distribute both inbound and outbound traffic between multiple - transit providers. This requirement is for concurrent + transit providers. This goal is for concurrent use of the multiple transit providers, not just the usage of one provider over one interval of time and another provider over a different interval.</t> @@ -184,9 +184,12 @@ <t>As any proposed multihoming solution must be deployed in real networks with real customers, simplicity is paramount. The current multihoming solution is quite - straightforward to deploy and maintain. A new IPv6 multihoming - proposal should not be substantially more complex to deploy and - operate than current IPv4 multihoming practices.</t> + straightforward to deploy and maintain.</t> + + <t>A new IPv6 multihoming + solution should not be substantially more complex to deploy and + operate (for multihomed sites or for the rest of the Internet) + than current IPv4 multihoming practices.</t> </section> <section anchor="transportSurvivability" title="Transport-Layer @@ -213,13 +216,14 @@ <t>Multi-homing solutions either should be compatible with the observed dynamics of the current DNS system, or the solutions should demonstrate that the modified name resolution - system required to support them are readily deployable.</t> + system required to support them is readily deployable.</t> </section> <section anchor="antiSpoofing" title="Packet Filtering"> <t>Multihoming solutions should not preclude filtering packets with forged or otherwise inappropriate source IP addresses - at the administrative boundary of the multihomed site.</t> + at the administrative boundary of the multihomed site, or + at the administrative boundaries of any site in the Internet.</t> </section> </section> @@ -231,7 +235,7 @@ is a concern both because of the hardware requirements it imposes and also because of the impact on the stability of the routing system. This issue is discussed in great - detail in <xref target="refs.Huston" />.</t> + detail in <xref target="refs.RFC3221" />.</t> <t>A new IPv6 multihoming architecture should scale to accommodate orders of magnitude more multihomed sites @@ -240,7 +244,7 @@ </section> <section anchor="routerImpact" title="Impact on Routers"> - <t>The solution may require changes to IPv6 router implementations, + <t>The solutions may require changes to IPv6 router implementations, but these changes should be either minor, or in the form of logically separate functions added to existing functions.</t> @@ -253,7 +257,7 @@ <t>The solution should not destroy IPv6 connectivity for a legacy host implementing RFC 3513 <xref target="refs.RFC3513" />, RFC 2460 <xref target="refs.RFC2460" />, - RFC 2553 <xref target="refs.RFC2553" /> and other basic IPv6 + RFC 3493 <xref target="refs.RFC3493" /> and other basic IPv6 specifications current in April 2003. That is to say, if a host can work in a single-homed site, it should still be able to work in a @@ -274,7 +278,7 @@ cannot benefit from multihoming.</t> <t>The multihoming solution may allow host or application - changes if that would enhance session survivability.</t> + changes if that would enhance transport-layer survivability.</t> </section> <section anchor="hostrouter" title="Interaction between Hosts and @@ -285,7 +289,7 @@ </section> <section anchor="operations" title="Operations and Management"> - <t>It should be posssible for staff responsible for the operation + <t>It should be possible for staff responsible for the operation of a site to monitor and configure the site's multihoming system.</t> </section> @@ -296,6 +300,11 @@ and its transit providers, but should not require cooperation (relating specifically to the multihomed site) directly between the transit providers.</t> + + <t>The impact of any inter-site cooperation that might be + required to facilitate the multihoming solution should be + examined and assessed from the point of view of operational + practicality.</t> </section> <section anchor="multipleSolutions" title="Multiple Solutions"> @@ -381,23 +390,6 @@ <seriesInfo name="RFC" value="3513" /> </reference> - <reference anchor="refs.RFC2374"> - <front> - <title>An IPv6 Aggregatable Global Unicast Address Format - - Nokia - - - UUNET - - - Cisco - - - - - - Internet Protocol, Version 6 (IPv6) Specification @@ -412,34 +404,35 @@ - + Basic Socket Interface Extensions for IPv6 - FreeGate + Intransa, Inc. - Bellcore + Cisco Systems - Compaq + Hewlett-Packard Company - - Consultant + + Hewlett-Packard Company - + - + - + - Analyzing the Internet's BGP Routing Table + Commentary on Inter-Domain Routing in the Internet Telstra - + + --Apple-Mail-12--363034386 Content-Disposition: attachment; filename=draft-ietf-multi6-multihoming-requirements-06.txt Content-Type: text/plain; x-unix-mode=0640; name="draft-ietf-multi6-multihoming-requirements-06.txt" Content-Transfer-Encoding: quoted-printable Network Working Group J. Abley Internet-Draft ISC Expires: September 30, 2003 B. Black Layer8 Networks V. Gill AOL Time Warner April 2003 Goals for IPv6 Site-Multihoming Architectures draft-ietf-multi6-multihoming-requirements-06 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 30, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract Site-multihoming, i.e. connecting to more than one IP service provider, is an essential component of service for many sites which are part of the Internet. This document outlines a set of goals for proposed new IPv6 site-multihoming architectures. 1. Introduction Abley, et al. Expires September 30, 2003 [Page 1] =0C Internet-Draft IPv6 Site-Multihoming Goals April 2003 Current IPv4 site-multihoming practices have been added on to the CIDR architecture [1], which assumes that routing table entries can be aggregated based upon a hierarchy of customers and service providers. However, it appears that this hierarchy is being supplanted by a dense mesh of interconnections [6]. Additionally, there has been an enormous growth in the number of multihomed sites. For purposes of redundancy and load-sharing, the multihomed address blocks are introduced into the global table even if they are covered by a provider aggregate. This contributes to the rapidly-increasing size of both the global routing table and the turbulence exhibited within it, and places stress on the inter-provider routing system. Continued growth of both the Internet and the practice of site-multihoming will seriously exacerbate this stress. The site-multihoming architecture for IPv6 should allow the routing system to scale more pleasantly. 2. Terminology A "site" is an entity autonomously operating a network using IP and, in particular, determining the addressing plan and routing policy for that network. This definition is intended to be equivalent to "enterprise" as defined in [2]. A "transit provider" operates a site which directly provides connectivity to the Internet to one or more external sites. The connectivity provided extends beyond the transit provider's own site. A transit provider's site is directly connected to the sites for which it provides transit. A "multihomed" site is one with more than one transit provider. "Site-multihoming" is the practice of arranging a site to be multihomed. The term "re-homing" denotes a transition of a site between two states of connectedness, due to a change in the connectivity between the site and its transit providers' sites. 3. Multihoming Goals 3.1 Capabilities of IPv4 Multihoming The following capabilities of current IPv4 multihoming practices should be supported by an IPv6 multihoming architecture. Abley, et al. Expires September 30, 2003 [Page 2] =0C Internet-Draft IPv6 Site-Multihoming Goals April 2003 3.1.1 Redundancy By multihoming, a site should be able to insulate itself from certain failure modes within one or more transit providers, as well as failures in the network providing interconnection among one or more transit providers. Infrastructural commonalities below the IP layer may result in connectivity which is apparently diverse sharing single points of failure. For example, two separate DS3 circuits ordered from different suppliers and connecting a site to independent transit providers may share a single conduit from the street into a building; in this case physical disruption (sometimes referred to as "backhoe-fade") of both circuits may be experienced due to a single incident in the street. The two circuits are said to "share fate". The multihoming architecture should accommodate (in the general case, issues of shared fate notwithstanding) continuity of connectivity during the following failures: o Physical failure, such as a fiber cut, or router failure, o Logical link failure, such as a misbehaving router interface, o Routing protocol failure, such as a BGP peer reset, o Transit provider failure, such as a backbone-wide IGP failure, and o Exchange failure, such as a BGP reset on an inter-provider peering. 3.1.2 Load Sharing By multihoming, a site should be able to distribute both inbound and outbound traffic between multiple transit providers. This goal is for concurrent use of the multiple transit providers, not just the usage of one provider over one interval of time and another provider over a different interval. 3.1.3 Performance By multihoming, a site should be able to protect itself from performance difficulties directly between the site's transit providers. For example, suppose site E obtains transit from transit providers T1 and T2, and there is long-term congestion between T1 and T2. The Abley, et al. Expires September 30, 2003 [Page 3] =0C Internet-Draft IPv6 Site-Multihoming Goals April 2003 multihoming architecture should allow E to ensure that in normal operation none of its traffic is carried over the congested interconnection T1-T2. The process by which this is achieved should be a manual one. A multihomed site should be able to distribute inbound traffic from particular multiple transit providers according to the particular address range within their site which is sourcing or sinking the traffic. 3.1.4 Policy A customer may choose to multihome for a variety of policy reasons beyond technical scope (e.g. cost, acceptable use conditions, etc.) For example, customer C homed to ISP A may wish to shift traffic of a certain class or application, NNTP, for example, to ISP B as matter of policy. A new IPv6 multihoming proposal should provide support for site-multihoming for external policy reasons. 3.1.5 Simplicity As any proposed multihoming solution must be deployed in real networks with real customers, simplicity is paramount. The current multihoming solution is quite straightforward to deploy and maintain. A new IPv6 multihoming solution should not be substantially more complex to deploy and operate (for multihomed sites or for the rest of the Internet) than current IPv4 multihoming practices. 3.1.6 Transport-Layer Survivability Multihoming solutions should provide re-homing transparency for transport-layer sessions; i.e. exchange of data between devices on the multihomed site and devices elsewhere on the Internet may proceed with no greater interruption than that associated with the transient packet loss during the re-homing event. New transport-layer sessions should be able to be created following a re-homing event. Transport-layer sessions include those involving transport-layer protocols such as TCP, UDP and SCTP over IP. Applications which communicate over raw IP and other network-layer protocols may also enjoy re-homing transparency. 3.1.7 Impact on DNS Multi-homing solutions either should be compatible with the observed Abley, et al. Expires September 30, 2003 [Page 4] =0C Internet-Draft IPv6 Site-Multihoming Goals April 2003 dynamics of the current DNS system, or the solutions should demonstrate that the modified name resolution system required to support them is readily deployable. 3.1.8 Packet Filtering Multihoming solutions should not preclude filtering packets with forged or otherwise inappropriate source IP addresses at the administrative boundary of the multihomed site, or at the administrative boundaries of any site in the Internet. 3.2 Additional Requirements 3.2.1 Scalability Current IPV4 multihoming practices contribute to the significant growth currently observed in the state held in the global inter-provider routing system; this is a concern both because of the hardware requirements it imposes and also because of the impact on the stability of the routing system. This issue is discussed in great detail in [6]. A new IPv6 multihoming architecture should scale to accommodate orders of magnitude more multihomed sites without imposing unreasonable requirements on the routing system. 3.2.2 Impact on Routers The solutions may require changes to IPv6 router implementations, but these changes should be either minor, or in the form of logically separate functions added to existing functions. Such changes should not prevent normal single-homed operation, and routers implementing these changes should be able to interoperate fully with hosts and routers not implementing them. 3.2.3 Impact on Hosts The solution should not destroy IPv6 connectivity for a legacy host implementing RFC 3513 [3], RFC 2460 [4], RFC 3493 [5] and other basic IPv6 specifications current in April 2003. That is to say, if a host can work in a single-homed site, it should still be able to work in a multihomed site, even if it cannot benefit from site-multihoming. It would be compatible with this goal for such a host to lose connectivity if a site lost connectivity to one transit provider, despite the fact that other transit provider connections were still operational. Abley, et al. Expires September 30, 2003 [Page 5] =0C Internet-Draft IPv6 Site-Multihoming Goals April 2003 If the solution requires changes to the host stack, these changes should be either minor, or in the form of logically separate functions added to existing functions. If the solution requires changes to the socket API and/or the transport layer, it should be possible to retain the original socket API and transport protocols in parallel, even if they cannot benefit from multihoming. The multihoming solution may allow host or application changes if that would enhance transport-layer survivability. 3.2.4 Interaction between Hosts and the Routing System The solution may involve interaction between a site's hosts and its routing system; such an interaction should be simple, scaleable and securable. 3.2.5 Operations and Management It should be possible for staff responsible for the operation of a site to monitor and configure the site's multihoming system. 3.2.6 Cooperation between Transit Providers A multihoming strategy may require cooperation between a site and its transit providers, but should not require cooperation (relating specifically to the multihomed site) directly between the transit providers. The impact of any inter-site cooperation that might be required to facilitate the multihoming solution should be examined and assessed from the point of view of operational practicality. 3.2.7 Multiple Solutions There may be more than one approach to multihoming, provided all approaches are orthogonal (i.e. each approach addresses a distinct segment or category within the site multihoming problem). Multiple solutions will incur a greater management overhead, however, and the adopted solutions should attempt to cover as many multihoming scenarios and goals as possible. 4. Security Considerations A multihomed site should not be more vulnerable to security breaches than a traditionally IPv4-multihomed site. Abley, et al. Expires September 30, 2003 [Page 6] =0C Internet-Draft IPv6 Site-Multihoming Goals April 2003 Any changes to routing practices made to accommodate multihomed sites should not cause non-multihomed sites to become more vulnerable to security breaches. Normative References [1] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993. [2] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", RFC 1918, February 1996. [3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [5] Gilligan, R., Thomson, S., Bound, J. and J. McCann, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003. [6] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221, December 2001. Authors' Addresses Joe Abley Internet Software Consortium 950 Charter Street Redwood City, CA 94063 USA Phone: +1 650 423 1317 EMail: jabley@isc.org Benjamin Black Layer8 Networks EMail: ben@layer8.net Abley, et al. Expires September 30, 2003 [Page 7] =0C Internet-Draft IPv6 Site-Multihoming Goals April 2003 Vijay Gill AOL Time Warner EMail: vijaygill9@aol.com Abley, et al. Expires September 30, 2003 [Page 8] =0C Internet-Draft IPv6 Site-Multihoming Goals April 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Abley, et al. Expires September 30, 2003 [Page 9] =0C Internet-Draft IPv6 Site-Multihoming Goals April 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Abley, et al. Expires September 30, 2003 [Page 10] =0C --Apple-Mail-12--363034386-- From owner-multi6@ops.ietf.org Fri May 16 21:07:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15942 for ; Fri, 16 May 2003 21:07:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GqB2-000FZf-00 for multi6-data@psg.com; Sat, 17 May 2003 01:07:56 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19GqAx-000FZH-00 for multi6@ops.ietf.org; Sat, 17 May 2003 01:07:52 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h4H16Pn39272; Sat, 17 May 2003 03:06:27 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sat, 17 May 2003 03:06:27 +0200 Subject: Re: Mutli6 meeting in Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Brian E Carpenter From: Iljitsch van Beijnum In-Reply-To: <3EC4C70C.69CB0560@hursley.ibm.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On vrijdag, mei 16, 2003, at 13:10 Europe/Amsterdam, Brian E Carpenter wrote: >> Supporting single homed correspondents is essential but I don't care >> much for single homed hosts in a multihomed site. Upgrade already. >> It's >> not like there is a huge installed base of stuff that isn't supported >> any more in IPv6. > Well, pretty much every operating system image shipped today includes > RFC 2460 support. So I suspect the installed (but not enabled) base > is in fact huge. I agree, the operating systems are in good shape. Applications and service providers are much more problematic, not to mention the DNS. > At least in a large corporate network, routers and > hosts are *not* upgraded in a coordinated way. So 'upgrade already' > won't fly. We need incremental deployment; that has always been the > guiding principle for IPv6 coexistence. Well I'm not a huge fan of what has been happening with IPv6 so far. Why is it that the IETF can standardize something like A6 DNS records that turns out undeployable (big surprise) but at the same time over the past 10 years fail to come up with a way for IPv6 hosts to get at a DNS server (note: preferably not "discover") without using stateful mechanisms? But then if an IPv6 host could query an IPv6 nameserver that IPv6 nameserver wouldn't be able to reply without going back to IPv4 because the root and TLD infrastructure is oblivious to v6. And why exactly? For a large part because we don't want to break hosts that can't handle packets that are bigger than half a kilobyte. That's right, the amount of data an average computer these days can transmit in 50 microseconds. And why choose either the IPX approach where the MAC address is part of the address (simple) or the Appletalk approach where hosts automatically find a free address (keep addresses short) when you can do both at the same time, adding complexity to large addresses, so nobody gets to be happy? People who like to be conservative when building networks don't get what they want from the IETF because there are too many standards and *way* too many drafts (and those are often implemented so they can't be ignored), but at the same time people who like to be at the leading edge don't get what they want either because it takes forever to get anything done and everything has to be baby steps. I'm sure I had a point I wanted to make but it's late so it'll have to wait. Iljitsch From owner-multi6@ops.ietf.org Sat May 17 02:55:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02205 for ; Sat, 17 May 2003 02:55:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GvdQ-000IHf-00 for multi6-data@psg.com; Sat, 17 May 2003 06:57:36 +0000 Received: from tomts14.bellnexxia.net ([209.226.175.35] helo=tomts14-srv.bellnexxia.net) by psg.com with esmtp (Exim 3.36 #1) id 19GvdN-000IHS-00 for multi6@ops.ietf.org; Sat, 17 May 2003 06:57:33 +0000 Received: from yahoo.com ([65.93.187.122]) by tomts14-srv.bellnexxia.net (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20030517065732.KNWX14433.tomts14-srv.bellnexxia.net@yahoo.com>; Sat, 17 May 2003 02:57:32 -0400 Date: Sat, 17 May 2003 02:57:31 -0400 Subject: Re: Agenda for Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Masataka Ohta From: S Woodside In-Reply-To: <200305151036.TAA17734@necom830.hpcl.titech.ac.jp> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-22.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,FORGED_YAHOO_RCVD,IN_REP_TO, QUOTED_EMAIL_TEXT,RCVD_FAKE_HELO_DOTCOM,REPLY_WITH_QUOTES, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday, May 15, 2003, at 06:37 AM, Masataka Ohta wrote: > Kurt; > > You wrote me: > >>>> 1. We schedule two sessions. >>> >>> Why its not three 2H sessions? Have you tried? >> >> No. I don't see the need for it, and I don't think it would be useful. >> If others disagree they are free to step forward. > > that the time constraint is artificially put by no one else but you. Are you disagreeing? In absence of disagreement then presumably it's a reasonable way to set up the time management. > Then, you wrote Iljitsch that > >> Again, this is more a time constraint than anything else and would >> depend on the amount of presentations. > > So, why not have three 2H sessions and stop saying "time constraint"? > Because the time constraint is intentional. It's not a time constraint imposed by above, but rather self-imposed to improve the effectiveness of the meeting. More time does not always equal better. simon From owner-multi6@ops.ietf.org Sat May 17 04:40:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03168 for ; Sat, 17 May 2003 04:40:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GxHX-0003pK-00 for multi6-data@psg.com; Sat, 17 May 2003 08:43:07 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19GxHT-0003mL-00 for multi6@ops.ietf.org; Sat, 17 May 2003 08:43:03 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h4H8fen42065; Sat, 17 May 2003 10:41:40 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sat, 17 May 2003 03:06:27 +0200 Subject: Re: Mutli6 meeting in Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Brian E Carpenter From: Iljitsch van Beijnum In-Reply-To: <3EC4C70C.69CB0560@hursley.ibm.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.0 required=5.0 tests=BAYES_01,DATE_IN_PAST_06_12,EMAIL_ATTRIBUTION,IN_REP_TO, QUOTED_EMAIL_TEXT,REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On vrijdag, mei 16, 2003, at 13:10 Europe/Amsterdam, Brian E Carpenter wrote: >> Supporting single homed correspondents is essential but I don't care >> much for single homed hosts in a multihomed site. Upgrade already. >> It's >> not like there is a huge installed base of stuff that isn't supported >> any more in IPv6. > Well, pretty much every operating system image shipped today includes > RFC 2460 support. So I suspect the installed (but not enabled) base > is in fact huge. I agree, the operating systems are in good shape. Applications and service providers are much more problematic, not to mention the DNS. > At least in a large corporate network, routers and > hosts are *not* upgraded in a coordinated way. So 'upgrade already' > won't fly. We need incremental deployment; that has always been the > guiding principle for IPv6 coexistence. Well I'm not a huge fan of what has been happening with IPv6 so far. Why is it that the IETF can standardize something like A6 DNS records that turns out undeployable (big surprise) but at the same time over the past 10 years fail to come up with a way for IPv6 hosts to get at a DNS server (note: preferably not "discover") without using stateful mechanisms? But then if an IPv6 host could query an IPv6 nameserver that IPv6 nameserver wouldn't be able to reply without going back to IPv4 because the root and TLD infrastructure is oblivious to v6. And why exactly? For a large part because we don't want to break hosts that can't handle packets that are bigger than half a kilobyte. That's right, the amount of data an average computer these days can transmit in 50 microseconds. And why choose either the IPX approach where the MAC address is part of the address (simple) or the Appletalk approach where hosts automatically find a free address (keep addresses short) when you can do both at the same time, adding complexity to large addresses, so nobody gets to be happy? People who like to be conservative when building networks don't get what they want from the IETF because there are too many standards and *way* too many drafts (and those are often implemented so they can't be ignored), but at the same time people who like to be at the leading edge don't get what they want either because it takes forever to get anything done and everything has to be baby steps. I'm sure I had a point I wanted to make but it's late so it'll have to wait. Iljitsch From owner-multi6@ops.ietf.org Sat May 17 05:38:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04142 for ; Sat, 17 May 2003 05:38:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GyAl-000AWZ-00 for multi6-data@psg.com; Sat, 17 May 2003 09:40:11 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19GyAj-000AW9-00; Sat, 17 May 2003 09:40:09 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h4H9ckn42122; Sat, 17 May 2003 11:38:46 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sat, 17 May 2003 11:38:52 +0200 Subject: Re: Agenda for Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Randy Bush From: Iljitsch van Beijnum In-Reply-To: Message-Id: <5EE3E008-884B-11D7-8597-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-19.4 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On donderdag, mei 15, 2003, at 18:36 Europe/Amsterdam, Randy Bush wrote: > this wg has yet to show good use of one session. Randy, are you seriously suggesting that the chairs will be denied even a signle session in Vienna? Obviously this wg isn't the best example of the IETF's prowess but we have been making progress towards useful work and consensus the past months, and I think it's important to capitalize on that face to face and create some momentum for further progress. Email and face to face interaction are simply not interchangable. So what is it going to be: do you want to be part of the problem, or part of the solution? Now if you have concrete suggestions for progress, by all means, let us know. (And yes, we know we have to send code.) From owner-multi6@ops.ietf.org Sun May 18 10:57:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11130 for ; Sun, 18 May 2003 10:57:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19HPcA-0005sv-00 for multi6-data@psg.com; Sun, 18 May 2003 14:58:18 +0000 Received: from d12lmsgate.de.ibm.com ([194.196.100.234]) by psg.com with esmtp (Exim 3.36 #1) id 19HPc8-0005sX-00; Sun, 18 May 2003 14:58:16 +0000 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h4IEvvu9053342; Sun, 18 May 2003 16:57:58 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h4IEvoLe098582; Sun, 18 May 2003 16:57:54 +0200 Received: from gsine01.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA49094 from ; Sun, 18 May 2003 16:57:43 +0200 Message-Id: <3EC76F23.F9DA37E5@hursley.ibm.com> Date: Sun, 18 May 2003 13:31:47 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Iljitsch van Beijnum Cc: Randy Bush , multi6@ops.ietf.org Subject: Re: Agenda for Vienna References: <5EE3E008-884B-11D7-8597-00039388672E@muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-29.0 required=5.0 tests=BAYES_01,DATE_IN_PAST_03_06,EMAIL_ATTRIBUTION, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I believe we have a reasonable agenda proposal already from Kurt, and that we need to meet. Certainly, whether to keep the WG alive and if so how its charter needs to be updated should be a topic for the end of the second session. Brian Iljitsch van Beijnum wrote: > > On donderdag, mei 15, 2003, at 18:36 Europe/Amsterdam, Randy Bush wrote: > > > this wg has yet to show good use of one session. > > Randy, are you seriously suggesting that the chairs will be denied even > a signle session in Vienna? > > Obviously this wg isn't the best example of the IETF's prowess but we > have been making progress towards useful work and consensus the past > months, and I think it's important to capitalize on that face to face > and create some momentum for further progress. Email and face to face > interaction are simply not interchangable. > > So what is it going to be: do you want to be part of the problem, or > part of the solution? > > Now if you have concrete suggestions for progress, by all means, let us > know. (And yes, we know we have to send code.) From owner-multi6@ops.ietf.org Sun May 18 10:57:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11145 for ; Sun, 18 May 2003 10:57:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19HPbx-0005sK-00 for multi6-data@psg.com; Sun, 18 May 2003 14:58:05 +0000 Received: from d12lmsgate-4.de.ibm.com ([194.196.100.237]) by psg.com with esmtp (Exim 3.36 #1) id 19HPbv-0005rx-00 for multi6@ops.ietf.org; Sun, 18 May 2003 14:58:03 +0000 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-4.de.ibm.com (8.12.9/8.12.8) with ESMTP id h4IEvwDI033580; Sun, 18 May 2003 16:57:58 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h4IEvw5e253718; Sun, 18 May 2003 16:57:59 +0200 Received: from gsine01.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA59556 from ; Sun, 18 May 2003 16:57:55 +0200 Message-Id: <3EC76FFB.55773EE8@hursley.ibm.com> Date: Sun, 18 May 2003 13:35:23 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Joe Abley Cc: multi6@ops.ietf.org Subject: Re: requirements-06 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-29.0 required=5.0 tests=BAYES_01,DATE_IN_PAST_03_06,EMAIL_ATTRIBUTION, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Great. Let's ship it and move on. Brian Joe Abley wrote: > > Revised draft, attached below, has been sent in and should appear in > the usual places in due course. From owner-multi6@ops.ietf.org Sun May 18 13:37:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13256 for ; Sun, 18 May 2003 13:37:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19HS7w-000P25-00 for multi6-data@psg.com; Sun, 18 May 2003 17:39:16 +0000 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #1) id 19HS7l-000P1L-00 for multi6@ops.ietf.org; Sun, 18 May 2003 17:39:06 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id SAA23955 for ; Sun, 18 May 2003 18:39:04 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id SAA27215 for ; Sun, 18 May 2003 18:39:04 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h4IHd3C02839 for multi6@ops.ietf.org; Sun, 18 May 2003 18:39:03 +0100 Date: Sun, 18 May 2003 18:39:03 +0100 From: Tim Chown To: multi6@ops.ietf.org Subject: Re: Agenda for Vienna Message-ID: <20030518173903.GB2743@login.ecs.soton.ac.uk> Mail-Followup-To: multi6@ops.ietf.org References: <5EE3E008-884B-11D7-8597-00039388672E@muada.com> <3EC76F23.F9DA37E5@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EC76F23.F9DA37E5@hursley.ibm.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk I thought two multi6 sessions had been agreed some time ago for Vienna? Is this no longer the case? If so, why? Tim On Sun, May 18, 2003 at 01:31:47PM +0200, Brian E Carpenter wrote: > I believe we have a reasonable agenda proposal already from Kurt, > and that we need to meet. Certainly, whether to keep the WG alive > and if so how its charter needs to be updated should be a topic for > the end of the second session. > > Brian > > Iljitsch van Beijnum wrote: > > > > On donderdag, mei 15, 2003, at 18:36 Europe/Amsterdam, Randy Bush wrote: > > > > > this wg has yet to show good use of one session. > > > > Randy, are you seriously suggesting that the chairs will be denied even > > a signle session in Vienna? > > > > Obviously this wg isn't the best example of the IETF's prowess but we > > have been making progress towards useful work and consensus the past > > months, and I think it's important to capitalize on that face to face > > and create some momentum for further progress. Email and face to face > > interaction are simply not interchangable. > > > > So what is it going to be: do you want to be part of the problem, or > > part of the solution? > > > > Now if you have concrete suggestions for progress, by all means, let us > > know. (And yes, we know we have to send code.) > > From owner-multi6@ops.ietf.org Mon May 19 00:38:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25176 for ; Mon, 19 May 2003 00:38:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19HcQX-000NNw-00 for multi6-data@psg.com; Mon, 19 May 2003 04:39:09 +0000 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 19HcQS-000NNP-00 for multi6@ops.ietf.org; Mon, 19 May 2003 04:39:05 +0000 From: Masataka Ohta Message-Id: <200305190426.NAA13955@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id NAA13955; Mon, 19 May 2003 13:26:42 +0900 Subject: Re: Agenda for Vienna In-Reply-To: from S Woodside at "May 17, 2003 02:57:31 am" To: S Woodside Date: Mon, 19 May 2003 13:26:41 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Simon; > > that the time constraint is artificially put by no one else but you. > > Are you disagreeing? Yes. > In absence of disagreement then presumably it's a > reasonable way to set up the time management. > > Then, you wrote Iljitsch that > > > >> Again, this is more a time constraint than anything else and would > >> depend on the amount of presentations. > > > > So, why not have three 2H sessions and stop saying "time constraint"? > Because the time constraint is intentional. It's not a time constraint > imposed by above, but rather self-imposed to improve the effectiveness > of the meeting. Then, the reasoning against Iljitsch must not be a constraint on time but a poorness of content. In my case, note that, as Kurt said, he never seen my draft that he can't say anything about the effectiveness of the meeting with regard to my draft. So, it is an intentional, but purposeless time constraint. > More time does not always equal better. Remember that we must spent a week at Vienna, anyway. Our concern is effectiveness of the week. The effectiveness of the WG meeting becomes our concern only with externally imposed time constraint. Masataka Ohta From owner-multi6@ops.ietf.org Mon May 19 01:36:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26103 for ; Mon, 19 May 2003 01:36:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19HdMb-0000YJ-00 for multi6-data@psg.com; Mon, 19 May 2003 05:39:09 +0000 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 19HdMX-0000Y0-00; Mon, 19 May 2003 05:39:06 +0000 From: Masataka Ohta Message-Id: <200305190531.OAA16036@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id OAA16036; Mon, 19 May 2003 14:31:08 +0900 Subject: Re: Mutli6 meeting in Vienna In-Reply-To: <7F507F1E-8722-11D7-9EEC-0003938E4DE4@ab.use.net> from Sean Doran at "May 15, 2003 11:13:46 pm" To: Sean Doran Date: Mon, 19 May 2003 14:31:07 +0859 () CC: Randy Bush , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Sean; > > Remember that the first version was taken seriously by you and > > Harald. > > And me. Oh, yes. Thank you and several others. > However, two things stand out: > > (i) I made a number of comments and asked some questions > on the list after having read through your draft; and > > (ii) The draft is old and needs a refresh. > > I wonder if you could be persuaded to submit a new revision > in light of these two points? Yes, of course. In addition, I answer your questions in this mail (as, in your mail, they are located after an lengthy discussion and summary of my draft, I have overlooked to answer them) in this mail. > How does a host know its address? > > That is, how does a host learn what set of path-indicators > _can_ (not should, can) be advertised during the initial > handshaking of a new TCP connection (or thereafter)? Your question should be about a set of addresses of its own, not peer's. Then, my assumption is, they is preconfigured, just as addresses of hosts today, by hand or through DHCP. You can also say RA, though I think it sucks. A more smart solution is to let IGPs carry them. After the initial hand shaking, mobility may modify the set. > How many path-indicators should MultihomedSender > announce to the Receiver? Two? More than two? > How many path-indicators will Receiver announce > back in reply to the Sender's SYN (which uses a > path-indicator from the DNS)? There should be reasonable maximum. Currently, we set it 8. Please don't assume that we can't modify TCP, or its maximum option length. > Next: change. What happens on the host if > MultihomedSite multihomes to another network? > What happens if some time (days?) subsequently > MultihomedSite permanently disconnects from > LocalISPNumberOne? If the answer is: the host > acquires via some protocol (or manual > configuration) a new path-indicator, who assigned > the path-indicator in the first place? Upper level ISPs assign the path-indicator, which will be hand configured to hosts, DHCP servers and, most importantly, DNS servers. Please don't say "automatic renumbering", which is known to be impossible w.r.t. DNS entries. > Incidentally, any solution to this which does not > require changes to the current routing system is > also a general solution to site renumbering, which > is much-missed feature in IPv4 and IPv6, and > likely would be worthy of an RFC of its own. As I wrote: However, to enable source address filtering to discard packets with source addresses not belonging to an ISP, it is useful to enable a host, not some intelligent intermediate router, select a source address compatible with an outgoing ISP. For that purpose, intra domain routing protocols should maintain routing table entries with not only preference values of an external routes, but also proper prefixes to be selected for source addresses, if the entries are chosen by a host. I don't preclude the possibility to change the current routing system, though, in this case, it is entirely optional and you can do it by hand. But, remember that the impossible part of automatic renumering is in DNS. Masataka Ohta From owner-multi6@ops.ietf.org Mon May 19 06:14:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13987 for ; Mon, 19 May 2003 06:14:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Hhg4-000LRj-00 for multi6-data@psg.com; Mon, 19 May 2003 10:15:32 +0000 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 19Hhg1-000LRX-00 for multi6@ops.ietf.org; Mon, 19 May 2003 10:15:29 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13913; Mon, 19 May 2003 06:12:22 -0400 (EDT) Message-Id: <200305191012.GAA13913@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-ietf-multi6-multihoming-requirements-06.txt Date: Mon, 19 May 2003 06:12:21 -0400 X-Spam-Status: No, hits=-3.5 required=5.0 tests=BAYES_01,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Site Multihoming in IPv6 Working Group of the IETF. Title : Goals for IPv6 Site-Multihoming Architectures Author(s) : J. Abley, B. Black, V. Gill Filename : draft-ietf-multi6-multihoming-requirements-06.txt Pages : 10 Date : 2003-5-16 Site-multihoming, i.e. connecting to more than one IP service provider, is an essential component of service for many sites which are part of the Internet. This document outlines a set of goals for proposed new IPv6 site-multihoming architectures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-multi6-multihoming-requirements-06.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-ietf-multi6-multihoming-requirements-06.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-ietf-multi6-multihoming-requirements-06.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: <2003-5-16151715.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-multi6-multihoming-requirements-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-multi6-multihoming-requirements-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-16151715.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-multi6@ops.ietf.org Mon May 19 08:23:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18755 for ; Mon, 19 May 2003 08:23:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Hjg5-0009u7-00 for multi6-data@psg.com; Mon, 19 May 2003 12:23:41 +0000 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by psg.com with esmtp (Exim 3.36 #1) id 19Hjg3-0009tt-00 for multi6@ops.ietf.org; Mon, 19 May 2003 12:23:39 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4JCNXx9011269; Mon, 19 May 2003 05:23:34 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h4JCNXL19612; Mon, 19 May 2003 14:23:33 +0200 (MEST) Date: Mon, 19 May 2003 14:22:50 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Agenda for Vienna To: Kurt Erik Lindqvist Cc: multi6@ops.ietf.org In-Reply-To: "Your message with ID" <465D5422-861D-11D7-BDC5-000393520ED8@kurtis.pp.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-13.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk The agenda proposal makes sense to me. One question though: > 3. The second session will be scheduled later in the week. This will > concentrate on the two main proposals that are currently being worked > on. Those being loc/id which seems to be the main one, and host based > solutions. This session would be started off with an overview of the > status on this, and perhaps a summary of the earlier session. I don't understand the split across "two main proposals". loc/id separation can be done either a the hosts, in some (border) router, or in a combination of them (e.g. for transition reasons doing it in the border router first with the intent to moving it to the host). I would understand the split between longer term solutions based on loc/id separation, and shorter term ones based on multi-addressing (e.g. Christian's proposal). Mobile IP-based solutions might fall somewhere in between the two since there isn't a strict split between loc and id; everything is an IP address with some being more stable than others and a binding protocol. Can you unconfuse me? Erik From owner-multi6@ops.ietf.org Mon May 19 08:30:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18992 for ; Mon, 19 May 2003 08:30:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Hjp8-000BDr-00 for multi6-data@psg.com; Mon, 19 May 2003 12:33:02 +0000 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 19Hjp6-000BDf-00 for multi6@ops.ietf.org; Mon, 19 May 2003 12:33:00 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4JCWtY9011533; Mon, 19 May 2003 06:32:55 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h4JCWsL20119; Mon, 19 May 2003 14:32:54 +0200 (MEST) Date: Mon, 19 May 2003 14:32:12 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Agenda for Vienna To: Iljitsch van Beijnum Cc: Tony Li , multi6@ops.ietf.org In-Reply-To: "Your message with ID" <80CE291C-86AA-11D7-A2C3-00039388672E@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-13.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > Some notions that seem relatively undisputed: > > - we separate the identifier and locator functions so we can have > multiple locators and still have a single identifier > - IP in transit works with locators, everything above the IP layer with > the identifier Yep. And I think tunneling is one approach to implement this. There might be an attribute of transparency that can be derived from the above (not that I know we'd agree on it): Assume that layer X in the stack is operating on locators (where there might be arguments for X=transport and X=application, but that is separate discussion) then X will send a packet with some source locator and some destination locator. The transpareency attribute would be that the X layer on the receiver receive the same packet (apart from TTL) as the sender sent. > This leads to the following questions: > > - what should identifiers look like? More detailed questions in this area are: - are identifiers flat or do they have internal structure? - are (the fields of) the identifiers managed for uniqueness and other purposes or are they more or less random? (If there is internal structure potentially different fields can be different in this respect.) > - assuming applications use identifiers, how do we know which locators > go with a certain identifier? And potentially at different time scales: - find a set of potential locators from an identifiers (whether or not they are currently usable) - find a set of usable locators for an identifier (taking into account failures that affect one locator but not others) And potentially at different granularity: - site mapping (from site part of identifier to site part of locator) - host mapping (allowing host multihoming and host IP mobility) > - when receiving packets, how do we know (= better than take her word > for it) the correspondent's identifier? Agreed. If there is a system that maps to identifiers to locators there is also the issue of authenticating and authorizing entries (new and updates) to that system. > Then there is the address selection problem. We know that the current > "pick one and die if it doesn't work" approach is no good so we have to > come up with something better. I assume you meant "locator selection" and not "address selection". :-) Erik From owner-multi6@ops.ietf.org Mon May 19 09:58:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21017 for ; Mon, 19 May 2003 09:58:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19HlBN-000MP0-00 for multi6-data@psg.com; Mon, 19 May 2003 14:00:05 +0000 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238]) by psg.com with esmtp (Exim 3.36 #1) id 19HlB5-000MNK-00 for multi6@ops.ietf.org; Mon, 19 May 2003 13:59:48 +0000 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-5.de.ibm.com (8.12.9/8.12.8) with ESMTP id h4JDxVlr067878; Mon, 19 May 2003 15:59:37 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h4JDvGut243052; Mon, 19 May 2003 15:57:20 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA23228 from ; Mon, 19 May 2003 15:57:14 +0200 Message-Id: <3EC8E2D7.DDB2AAD7@hursley.ibm.com> Date: Mon, 19 May 2003 15:57:43 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org Subject: Re: new draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Reading this draft and draft-de-launois-multi6-naros-00.txt together, I feel that they have a lot in common - except that NAROS uses an ad hoc protocol instead of DNS, and is explicitly linked to TE. But they both seem to me to be the nucleus of a depolyable solution that doesn't break much at all. Can we ignore for a moment the DNS-vs-ad hoc question and look at the pros and cons of this family of solutions? Brian Iljitsch van Beijnum wrote: > > After friday's discussion I wanted to see what could be accomplished > without any kind of negotiation. What I came up with: > > http://www.muada.com/drafts/draft-van-beijnum-multi6-2pi1a.txt > > - no middleboxes > - no state in routers > - bare-bones multihoming for servers is possible without any state > in the server (the client must keep state though) > - we have to break autoconfiguration > - we need the DNS, no multihoming for severs with just IP addresses > - optional source address rewriting > > Note that this is a finished draft and it's not related to the other > one I've been working on. > > Adding some negotiation to the client part should make this much more > reasonable but the server part seems reasonably solid. > > Iljitsch From owner-multi6@ops.ietf.org Mon May 19 17:40:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06818 for ; Mon, 19 May 2003 17:40:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19HsOL-0009I5-00 for multi6-data@psg.com; Mon, 19 May 2003 21:41:57 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19HsO2-0009G7-00 for multi6@ops.ietf.org; Mon, 19 May 2003 21:41:39 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h4JLeEn51756; Mon, 19 May 2003 23:40:14 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Mon, 19 May 2003 23:40:19 +0200 Subject: Re: Agenda for Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Erik Nordmark From: Iljitsch van Beijnum In-Reply-To: Message-Id: <7CCAFF29-8A42-11D7-A50F-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On maandag, mei 19, 2003, at 14:32 Europe/Amsterdam, Erik Nordmark wrote: >> Some notions that seem relatively undisputed: >> - we separate the identifier and locator functions so we can have >> multiple locators and still have a single identifier >> - IP in transit works with locators, everything above the IP layer >> with >> the identifier > Yep. And I think tunneling is one approach to implement this. :-) I don't care much for tunnels. Now if they would really solve anything I guess I could live with another wasted 40 bytes per packet but I don't think they do as you can't trust any information in the inner header. So either you need crypto or you check the inner header against know information. But if you knew in the first place, why add the header...? > There might be an attribute of transparency that can be derived from > the above > (not that I know we'd agree on it): > Assume that layer X in the stack is operating on locators (where there > might > be arguments for X=transport and X=application, but that is separate > discussion) then X will send a packet with some source locator and some > destination locator. > The transpareency attribute would be that the X layer on the receiver > receive the same packet (apart from TTL) as the sender sent. I think this is what happens, and I sure think this should be what happens. >> This leads to the following questions: >> - what should identifiers look like? > More detailed questions in this area are: > - are identifiers flat or do they have internal structure? We know that looking up stuff in a flat namespace isn't pretty. If we truly want the identifier to be the identifier, then we need to be able to look up stuff such as locators based on the identifier. We can also have something at an even higher level that is used as the "real" identifier, I think this is what the HIP people do by mapping from the FQDN to the crypto ID and the locators but not from the crypto ID directly to the locators. > - are (the fields of) the identifiers managed for uniqueness and other > purposes or are they more or less random? (If there is internal > structure > potentially different fields can be different in this respect.) I would like to make as few assumptions about the identifiers as possible, so we can use different kinds of identifiers and not just IPv6 addresses. FQDNs would make good identifiers. Cryptographic hashes are also useful identifiers for some purposes. But that means we have to design for the lowest common denominator = no real structure = hard to look up. >> - when receiving packets, how do we know (= better than take her word >> for it) the correspondent's identifier? > Agreed. > If there is a system that maps to identifiers to locators there is > also the issue of authenticating and authorizing entries (new and > updates) > to that system. And yet it has to be simple enough that people who don't know an X.509 certificate from a piece of toilet paper can deploy it. >> Then there is the address selection problem. We know that the current >> "pick one and die if it doesn't work" approach is no good so we have >> to >> come up with something better. > I assume you meant "locator selection" and not "address selection". :-) Aarghh, yes... Iljitsch From owner-multi6@ops.ietf.org Tue May 20 02:19:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00550 for ; Tue, 20 May 2003 02:19:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19I0UM-000DJq-00 for multi6-data@psg.com; Tue, 20 May 2003 06:20:42 +0000 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74]) by psg.com with esmtp (Exim 3.36 #1) id 19I0UA-000DDi-00 for multi6@ops.ietf.org; Tue, 20 May 2003 06:20:30 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.9/8.10.2) with ESMTP id h4K6Ofur000789; Tue, 20 May 2003 08:24:44 +0200 (CEST) Date: Tue, 20 May 2003 08:24:40 +0200 Subject: Re: Agenda for Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Iljitsch van Beijnum , multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200305152147.GAA20255@necom830.hpcl.titech.ac.jp> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-14.9 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> that the time constraint is artificially put by no one else but you. >> >> Correct. For the reason stated above. > > Then, how can you say Iljitsch that > >> Again, this is more a time constraint than anything else and would >> depend on the amount of presentations. > > Randy, this is not a problem of AD. > I simply think that we will not move more forward just because we add 2h. If there is something that is that important, I think we better take it to the mailinglist and discuss it here first. - kurtis - From owner-multi6@ops.ietf.org Tue May 20 02:19:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00602 for ; Tue, 20 May 2003 02:19:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19I0W3-000DoQ-00 for multi6-data@psg.com; Tue, 20 May 2003 06:22:27 +0000 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74]) by psg.com with esmtp (Exim 3.36 #1) id 19I0W1-000Dmq-00; Tue, 20 May 2003 06:22:25 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.9/8.10.2) with ESMTP id h4K6Qiur000813; Tue, 20 May 2003 08:26:44 +0200 (CEST) Date: Tue, 20 May 2003 08:26:43 +0200 Subject: Re: Agenda for Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Randy Bush , multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200305152137.GAA20188@necom830.hpcl.titech.ac.jp> Message-Id: <06363214-8A8C-11D7-BA5E-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-14.9 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> So, why not have three 2H sessions and stop saying "time constraint"? >> >> because you will need a different AD to approve it. > > According to Kurt, no. Say again? I think I have made it pretty clear that we will not apply for three 2h sessions. > >>>> Are you saying that you have tried to request 3 slots and denied by >>>> IESG? >>>> >>>> Or, are you just saying you are not so sure? >>> >>> I am saying that I do not think it would be useful for us to request >>> three slots. I don't think that will move us forward. > > the problem was and still is "I (Kurt) do not think it would be useful" > that it is at the chair(s), not at IESG (yet). > ...I still don't think that thee 2h sessions will be useful. Sorry. You have yet to convince me. - kurtis - From owner-multi6@ops.ietf.org Tue May 20 02:23:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00706 for ; Tue, 20 May 2003 02:23:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19I0Zb-000EaZ-00 for multi6-data@psg.com; Tue, 20 May 2003 06:26:07 +0000 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74]) by psg.com with esmtp (Exim 3.36 #1) id 19I0ZY-000EaL-00 for multi6@ops.ietf.org; Tue, 20 May 2003 06:26:04 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.9/8.10.2) with ESMTP id h4K6UOur000816; Tue, 20 May 2003 08:30:24 +0200 (CEST) Date: Tue, 20 May 2003 08:30:23 +0200 Subject: Re: Agenda for Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200305152208.HAA20401@necom830.hpcl.titech.ac.jp> Message-Id: <8953E43E-8A8C-11D7-BA5E-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-15.5 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, RCVD_IN_RFCI,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> th proposals that have been made formally I meant submitted to the >> IETF. That is enough. I will try and go out and ask the authors of >> what >> I can find that is in the current drafts directory to find presenters >> for the first session. If I miss someone, I am sure the WG will point >> that out to me. > > Please first ask all the people to be the authors by call for drafts. There is a draft cut-off date posted by the IETF secretariat. If you submit a draft and ask that it should be CC:ed to a certain WG it will (see recent discussion on the ietf mailinglist). Once that is done, I will also try and make a list and post it here. If someone feel that I have forgotten about them I am sure I will be told..:) >>>>>> it is very clear that there is only two >>>>>> real solutions being worked on at the moment. > >>>> Something with wide support is better than something completed. It's >>>> not "first with code" it's "running code AND consensus". >>> >>> A class can not have code, a solution of a class can. > >> And both can have support or not have to support. > > But, solutions can be evaluated only after classes are chosen. As Tony Li pointed out, we should start with an architecture. That is where we should spend time in the second session, to try and find points where we can find agreement and build from there. > > It is fine for you to say: > > it is very clear that there is only two > real classes being worked on at the moment. > > but, you said: > > it is very clear that there is only two > real solutions being worked on at the moment. > > That is, you are totally confused. > I will leave that to others to judge. - kurtis - From owner-multi6@ops.ietf.org Tue May 20 02:37:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01146 for ; Tue, 20 May 2003 02:37:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19I0nG-000Htu-00 for multi6-data@psg.com; Tue, 20 May 2003 06:40:14 +0000 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74]) by psg.com with esmtp (Exim 3.36 #1) id 19I0nD-000Htg-00; Tue, 20 May 2003 06:40:11 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.9/8.10.2) with ESMTP id h4K6iXur000822; Tue, 20 May 2003 08:44:33 +0200 (CEST) Date: Tue, 20 May 2003 08:44:31 +0200 Subject: Re: Agenda for Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Randy Bush , multi6@ops.ietf.org To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <5EE3E008-884B-11D7-8597-00039388672E@muada.com> Message-Id: <82FBDF14-8A8E-11D7-BA5E-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-14.9 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> this wg has yet to show good use of one session. > > Randy, are you seriously suggesting that the chairs will be denied > even a signle session in Vienna? > I noticed that Randy have not answered, but I also know that Randy most likely have been traveling back from Barcelona and his vacation/RIPE meeting. When in Barcelona, Randy told me he would approve the two session approach. I think that Randys point above is that we now need to prove that we can use those two sessions for something useful and actually produce something. - kurtis - From owner-multi6@ops.ietf.org Tue May 20 02:43:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01279 for ; Tue, 20 May 2003 02:43:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19I0so-000JAU-00 for multi6-data@psg.com; Tue, 20 May 2003 06:45:58 +0000 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74]) by psg.com with esmtp (Exim 3.36 #1) id 19I0sm-000JAH-00 for multi6@ops.ietf.org; Tue, 20 May 2003 06:45:56 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.9/8.10.2) with ESMTP id h4K6oDur000835; Tue, 20 May 2003 08:50:13 +0200 (CEST) Date: Tue, 20 May 2003 08:50:12 +0200 Subject: Re: Agenda for Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: S Woodside , multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200305190426.NAA13955@necom830.hpcl.titech.ac.jp> Message-Id: <4DC615E7-8A8F-11D7-BA5E-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-14.7 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, RCVD_IN_RFCI,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> Because the time constraint is intentional. It's not a time constraint >> imposed by above, but rather self-imposed to improve the effectiveness >> of the meeting. > > Then, the reasoning against Iljitsch must not be a constraint on time > but a poorness of content. I was not arguing against Iljitsch. I said that the time allocated to each proposal will depend on the number of items to be discussed. This will apply now matter how much total time we have. From what I can tell, no one else than you seem to think that we need more time than the two sessions we are going to ask for. Therefor I will today go ahead with the proposed agenda and send it to the IETF secretariat. > > In my case, note that, as Kurt said, he never seen my draft that > he can't say anything about the effectiveness of the meeting with > regard to my draft. It's true that I haven't read it. But I have never see any draft that have improved from having it discussed at length at a IETF WG meeting. what I HAVE seen is discussions being short, and to the point if people have actually read the draft. Perhaps I should publish a reading list before the meeting, hoping it would improve the discussions.... Note that there is a reason that many WG chairs ask how many in the audience have actually read the drafts being discussed. >> More time does not always equal better. > > Remember that we must spent a week at Vienna, anyway. Yes, but it's not only multi6 that is meeting during this week. > > Our concern is effectiveness of the week. Mine too. - kurtis - From owner-multi6@ops.ietf.org Tue May 20 02:53:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01472 for ; Tue, 20 May 2003 02:53:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19I12f-000LKC-00 for multi6-data@psg.com; Tue, 20 May 2003 06:56:09 +0000 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74]) by psg.com with esmtp (Exim 3.36 #1) id 19I12b-000LGt-00 for multi6@ops.ietf.org; Tue, 20 May 2003 06:56:05 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.9/8.10.2) with ESMTP id h4K70Sur000838; Tue, 20 May 2003 09:00:28 +0200 (CEST) Date: Tue, 20 May 2003 09:00:27 +0200 Subject: Re: Agenda for Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Erik Nordmark From: Kurt Erik Lindqvist In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-15.5 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, RCVD_IN_RFCI,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The agenda proposal makes sense to me. > One question though: > >> 3. The second session will be scheduled later in the week. This will >> concentrate on the two main proposals that are currently being worked >> on. Those being loc/id which seems to be the main one, and host based >> solutions. This session would be started off with an overview of the >> status on this, and perhaps a summary of the earlier session. > > I don't understand the split across "two main proposals". > > loc/id separation can be done either a the hosts, in some (border) > router, > or in a combination of them (e.g. for transition reasons doing it > in the border router first with the intent to moving it to the host). > > I would understand the split between longer term solutions based on > loc/id separation, and shorter term ones based on multi-addressing > (e.g. Christian's proposal). In my original mail, with host based what I meant was multiaddressing and I think I finally understand in what way I managed to confuse Ohta-san. > > Can you unconfuse me? I hope I did. - kurtis - From owner-multi6@ops.ietf.org Tue May 20 03:15:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01838 for ; Tue, 20 May 2003 03:15:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19I1Na-0000zb-00 for multi6-data@psg.com; Tue, 20 May 2003 07:17:46 +0000 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74]) by psg.com with esmtp (Exim 3.36 #1) id 19I1NY-0000zO-00 for multi6@ops.ietf.org; Tue, 20 May 2003 07:17:44 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.9/8.10.2) with ESMTP id h4K7M7ur000846 for ; Tue, 20 May 2003 09:22:07 +0200 (CEST) Date: Tue, 20 May 2003 09:22:06 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: WG Last-call for draft-ietf-multi6-multihoming-requirements-06.txt From: Kurt Erik Lindqvist To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-8.5 required=5.0 tests=BAYES_01,RCVD_IN_RFCI,USER_AGENT_APPLEMAIL version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit (I hope this goes a lot better than last time) So this mail announces the last chance to comment on the above draft. If nothing particular have been commented before 17.00 CET Wed 21 May 2003 I will ship this to the IESG. (Yes this is a short period). - kurtis - From owner-multi6@ops.ietf.org Tue May 20 03:27:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01931 for ; Tue, 20 May 2003 03:27:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19I1ZB-0004CW-00 for multi6-data@psg.com; Tue, 20 May 2003 07:29:45 +0000 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74]) by psg.com with esmtp (Exim 3.36 #1) id 19I1Z9-0004CJ-00 for multi6@ops.ietf.org; Tue, 20 May 2003 07:29:43 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.9/8.10.2) with ESMTP id h4K7Y6ur000853 for ; Tue, 20 May 2003 09:34:06 +0200 (CEST) Date: Tue, 20 May 2003 09:34:05 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Thoughts for the second session in Vienna From: Kurt Erik Lindqvist To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: <6F46CE76-8A95-11D7-BA5E-000393A638B2@kurtis.pp.se> X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-8.5 required=5.0 tests=BAYES_01,RCVD_IN_RFCI,USER_AGENT_APPLEMAIL version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I would like to see what we do on the mailinglist for the architecture before Vienna. I think that before the second session, it would be good to try and list a) What we agree on in terms of architecture (I can go and dig through the archives and try and make a list) b) Items of architecture that we think we need to discuss further (Eriks and Iljitsch list might be a good start) If we manage to get some form of consensus on the above, we need to decide on what do use it for, but I think that is best to spare some 15 minutes at the end of the second session to discuss. With the above also comes the obvious question of what I mean as "terms of architecture". I think the detail level here will vary, but I think we need to continue on Iljitsch/Tonys/Eriks comments on how various pieces will interact and come together; what we can/can't change; How will packets transit from one point to another; What impact will what hops have the packets; etc. - kurtis - From owner-multi6@ops.ietf.org Tue May 20 04:16:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02728 for ; Tue, 20 May 2003 04:16:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19I2L6-000EMO-00 for multi6-data@psg.com; Tue, 20 May 2003 08:19:16 +0000 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #1) id 19I2L4-000EMC-00 for multi6@ops.ietf.org; Tue, 20 May 2003 08:19:14 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 7DF6934463; Tue, 20 May 2003 00:33:50 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h4K8JDYB006870; Tue, 20 May 2003 01:19:13 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Thoughts for the second session in Vienna Date: Tue, 20 May 2003 01:19:13 -0700 Message-ID: Thread-Topic: Thoughts for the second session in Vienna Thread-Index: AcMeo7q6YEBXy+kjTrGPpV1eL8MaPwABFIVA From: "Tony Li" To: "Kurt Erik Lindqvist" , X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA02728 | With the above also comes the obvious question of what I | mean as "terms | of architecture". I think the detail level here will vary, | but I think | we need to continue on Iljitsch/Tonys/Eriks comments on | how various | pieces will interact and come together; what we can/can't | change; How | will packets transit from one point to another; What | impact will what | hops have the packets; etc. To amplify a bit: Architecture is - How does it work? - What are the top level abstract pieces? - What are the (max nine) top level subsystems? - How do they interact? What function do they serve? - What can we throw away? Architecture is NOT - The bits should be aligned this way - This protocol is better than that - Implementation specifics - What can we add? - That should be a requirement ... Tony From owner-multi6@ops.ietf.org Tue May 20 07:52:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07096 for ; Tue, 20 May 2003 07:52:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19I5gS-00086r-00 for multi6-data@psg.com; Tue, 20 May 2003 11:53:32 +0000 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #1) id 19I5gN-00082I-00 for multi6@ops.ietf.org; Tue, 20 May 2003 11:53:27 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4KBrMHN003498; Tue, 20 May 2003 04:53:23 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h4KBrLL24620; Tue, 20 May 2003 13:53:21 +0200 (MEST) Date: Tue, 20 May 2003 13:52:38 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Agenda for Vienna To: Kurt Erik Lindqvist Cc: Erik Nordmark , multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-13.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > In my original mail, with host based what I meant was multiaddressing > and I think I finally understand in what way I managed to confuse > Ohta-san. > > > > > Can you unconfuse me? > > I hope I did. Yes. Thanks. Erik From owner-multi6@ops.ietf.org Tue May 20 08:40:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10255 for ; Tue, 20 May 2003 08:40:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19I6SB-0000dM-00 for multi6-data@psg.com; Tue, 20 May 2003 12:42:51 +0000 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by psg.com with esmtp (Exim 3.36 #1) id 19I6S8-0000d8-00 for multi6@ops.ietf.org; Tue, 20 May 2003 12:42:49 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 08B58961E; Tue, 20 May 2003 08:42:48 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Tue, 20 May 2003 08:42:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Agenda for Vienna Date: Tue, 20 May 2003 08:42:47 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD951@tayexc13.americas.cpqcorp.net> Thread-Topic: Agenda for Vienna Thread-Index: AcMenlFvgVn4KCvUQY2psz0HIOeZVAALvSaA From: "Bound, Jim" To: "Kurt Erik Lindqvist" , "Iljitsch van Beijnum" Cc: "Randy Bush" , X-OriginalArrivalTime: 20 May 2003 12:42:47.0867 (UTC) FILETIME=[515CC8B0:01C31ECD] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA10255 Having more than one is a stretch unless it is ok to do some thinking type work? /jim > -----Original Message----- > From: Kurt Erik Lindqvist [mailto:kurtis@kurtis.pp.se] > Sent: Tuesday, May 20, 2003 2:45 AM > To: Iljitsch van Beijnum > Cc: Randy Bush; multi6@ops.ietf.org > Subject: Re: Agenda for Vienna > > > >> this wg has yet to show good use of one session. > > > > Randy, are you seriously suggesting that the chairs will be denied > > even a signle session in Vienna? > > > > I noticed that Randy have not answered, but I also know that > Randy most > likely have been traveling back from Barcelona and his vacation/RIPE > meeting. > > When in Barcelona, Randy told me he would approve the two session > approach. I think that Randys point above is that we now need > to prove > that we can use those two sessions for something useful and actually > produce something. > > - kurtis - > > > From owner-multi6@ops.ietf.org Tue May 20 10:14:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14781 for ; Tue, 20 May 2003 10:14:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19I7tY-0007OZ-00 for multi6-data@psg.com; Tue, 20 May 2003 14:15:12 +0000 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74]) by psg.com with esmtp (Exim 3.36 #1) id 19I7tV-0007Lw-00 for multi6@ops.ietf.org; Tue, 20 May 2003 14:15:09 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.9/8.10.2) with ESMTP id h4KEF5Rp000468 for ; Tue, 20 May 2003 16:15:05 +0200 (CEST) Date: Tue, 20 May 2003 16:15:04 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Fwd: Internet-Draft Cutoff Dates for Vienna, Austria (July 16-21, 2003) From: Kurt Erik Lindqvist To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: <7386A255-8ACD-11D7-B63E-000393A638B2@kurtis.pp.se> X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-11.7 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit If you have not seen this. - kurtis - Begin forwarded message: > From: Internet-Drafts Administrator > Date: tis maj 20, 2003 13:36:48 Europe/Stockholm > To: IETF-Announce: ; > Subject: Internet-Draft Cutoff Dates for Vienna, Austria (July 16-21, > 2003) > > > NOTE: There are two (2) Internet-Draft Cutoff dates > > June 23rd: Cutoff for Initial Submissions (new documents) > > All initial submissions(-00) must be submitted by Monday, June 23rd, > at 09:00 ET. Initial submissions received after this time will NOT be > made available in the Internet-Drafts directory, and will have to be > resubmitted. > > > As before, all initial submissions (-00.txt) with a filename beginning > with a draft-ietf MUST be approved by the appropriate WG Chair prior to > processing and announcing. WG Chair approval must be received by > Monday, June 16th. > > Please do NOT wait until the last minute to submit. > > Be advised: NO placeholders. Updates to initial submissions received > the week of June 23rd will NOT be accepted. > > June 30st: FINAL Internet-Draft Cutoff > > All revised Internet-Draft submissions must be submitted by Monday, > June 30st, 2003 at 09:00 ET. Internet-Drafts received after this > time will NOT be announced NOR made available in the Internet-Drafts > Directories. > > We will begin accepting Internet-Draft submissions the week of the > meeting, though announcements will NOT be sent until the IETF meeting > is over. > > Thank you for your understanding and cooperation. Please do not > hesitate > to contact us if you have any questions or concenrs. > > FYI: These and other significant dates can be found at > http://www.ietf.org/meetings/cutoff_dates_57.html > > From owner-multi6@ops.ietf.org Tue May 20 10:55:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16523 for ; Tue, 20 May 2003 10:55:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19I8YZ-0001iK-00 for multi6-data@psg.com; Tue, 20 May 2003 14:57:35 +0000 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #1) id 19I8YG-0001cC-00 for multi6@ops.ietf.org; Tue, 20 May 2003 14:57:16 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4KEv6HN008332; Tue, 20 May 2003 07:57:07 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h4KEv5L07054; Tue, 20 May 2003 16:57:05 +0200 (MEST) Date: Tue, 20 May 2003 16:56:23 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: tunneling [Was: Agenda for Vienna] To: Iljitsch van Beijnum Cc: Erik Nordmark , multi6@ops.ietf.org In-Reply-To: "Your message with ID" <7CCAFF29-8A42-11D7-A50F-00039388672E@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-13.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > I don't care much for tunnels. Now if they would really solve anything > I guess I could live with another wasted 40 bytes per packet but I > don't think they do as you can't trust any information in the inner > header. So either you need crypto or you check the inner header against > know information. But if you knew in the first place, why add the > header...? I'm thinking more at a conceptual level where tunneling implies that a packet logically injected by the "identifier layer" on one node with source and destination being identifiers and being tunneled (by putting it in an IP packet with source and destination being locators) to the "identifier layer" unmodified. Thus conceptually it is wrapped in an IP packet and then unwrapped. This doesn't prevent optimizations like avoiding an extra IP header when it is known that the receiver can map from the pair of locators in the packet to the pair of identifiers. To do this compression would require some packet exchange to establish the state thus for delay reasons it might in some cases make sense to be able to start sending "uncompressed" packets in parallel with such state being established. And perhaps such state should be optional. It isn't likely to be harmful when the tunnel endpoint is the host, but there might potentially be scaling issues when the tunnel endpoint is some form of per-site proxy. So I don't mind avoiding 40 useless bytes either. Erik From owner-multi6@ops.ietf.org Tue May 20 10:56:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16579 for ; Tue, 20 May 2003 10:56:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19I8aD-0002Of-00 for multi6-data@psg.com; Tue, 20 May 2003 14:59:17 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19I8Zw-0002KO-00 for multi6@ops.ietf.org; Tue, 20 May 2003 14:59:00 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h4KEvan53636; Tue, 20 May 2003 16:57:36 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 20 May 2003 16:57:42 +0200 Subject: Re: Thoughts for the second session in Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Kurt Erik Lindqvist From: Iljitsch van Beijnum In-Reply-To: <6F46CE76-8A95-11D7-BA5E-000393A638B2@kurtis.pp.se> Message-Id: <68698DF3-8AD3-11D7-8982-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On dinsdag, mei 20, 2003, at 09:34 Europe/Amsterdam, Kurt Erik Lindqvist wrote: > I would like to see what we do on the mailinglist for the architecture > before Vienna. I think that before the second session, it would be > good to try and list > a) What we agree on in terms of architecture (I can go and dig through > the archives and try and make a list) > b) Items of architecture that we think we need to discuss further > (Eriks and Iljitsch list might be a good start) I would be especially interested in a good "pro" argument about tunnel headers. As I've said before, I don't think they're useful, but many people keep mentioning them. It would be good if we can reach a conclusion here. Also, I suspect the mapping discovery/negotiation and the actual failover will be the hard parts in practice. The identifier<->locator stuff itself isn't that complicated once we agree on the best way to do this. > If we manage to get some form of consensus on the above, we need to > decide on what do use it for, but I think that is best to spare some > 15 minutes at the end of the second session to discuss. Maybe it would be a good idea to get together in a smaller group and see if we can hammer out something workable. A little whiteboard can go a long way. We could do this between the first and second session and then see if there is consensus on the result in the second session. From owner-multi6@ops.ietf.org Tue May 20 11:04:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16920 for ; Tue, 20 May 2003 11:04:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19I8hV-0004W3-00 for multi6-data@psg.com; Tue, 20 May 2003 15:06:49 +0000 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #1) id 19I8hL-0004VC-00 for multi6@ops.ietf.org; Tue, 20 May 2003 15:06:39 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4KF6VHN014115; Tue, 20 May 2003 08:06:32 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h4KF6UL07849; Tue, 20 May 2003 17:06:30 +0200 (MEST) Date: Tue, 20 May 2003 17:05:48 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Identifier (structure) [Was: Agenda for Vienna] To: Iljitsch van Beijnum Cc: Erik Nordmark , multi6@ops.ietf.org In-Reply-To: "Your message with ID" <7CCAFF29-8A42-11D7-A50F-00039388672E@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-13.6 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > > More detailed questions in this area are: > > - are identifiers flat or do they have internal structure? > > We know that looking up stuff in a flat namespace isn't pretty. If we > truly want the identifier to be the identifier, then we need to be able > to look up stuff such as locators based on the identifier. Yep. It would be interesting to look at distributed hash tables for this, even if it is probably unrealistic to do lookups on flat host identifiers. > We can also > have something at an even higher level that is used as the "real" > identifier, I think this is what the HIP people do by mapping from the > FQDN to the crypto ID and the locators but not from the crypto ID > directly to the locators. Yes, that is one approach. It might make it more difficult for transition schemes where an unmodified IPv6 host plus some "proxy" e.g. at the site border together implement things. In such a case I think the IPv6 host (for transition purposes) would send packets where IP source and destination are identifiers thus the "proxy" would not see such higher level "real" identifiers. Another issue to consider in this space is the goal to allow applications already ported to IPv6 to continue to work when the application uses getaddrinfo() followed by connect()/sendto(). This is at least easier to accomplish if the identifier fits in 128 bits. So these are all important tradeoffs to try to understand better. > > - are (the fields of) the identifiers managed for uniqueness and other > > purposes or are they more or less random? (If there is internal > > structure > > potentially different fields can be different in this respect.) > > I would like to make as few assumptions about the identifiers as > possible, so we can use different kinds of identifiers and not just > IPv6 addresses. FQDNs would make good identifiers. Cryptographic hashes > are also useful identifiers for some purposes. But that means we have > to design for the lowest common denominator = no real structure = hard > to look up. Makes sense. If the identifier is split into "site identifier" plus "node within site ID" then it might be feasable to build a distributed hash table for the site identifier part. Some hard issues there is how to secure the DHT (the updates and the information retrieved from it) - but that might not be that much different than securing the source identifier received in a packet; solve one and the other might fall out. Erik From owner-multi6@ops.ietf.org Tue May 20 11:14:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17245 for ; Tue, 20 May 2003 11:14:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19I8qh-0005ca-00 for multi6-data@psg.com; Tue, 20 May 2003 15:16:19 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19I8qd-0005bX-00 for multi6@ops.ietf.org; Tue, 20 May 2003 15:16:15 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h4KFEpn53684; Tue, 20 May 2003 17:14:51 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 20 May 2003 17:14:57 +0200 Subject: Re: tunneling [Was: Agenda for Vienna] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Erik Nordmark From: Iljitsch van Beijnum In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On dinsdag, mei 20, 2003, at 16:56 Europe/Amsterdam, Erik Nordmark wrote: >> I don't care much for tunnels. Now if they would really solve anything >> I guess I could live with another wasted 40 bytes per packet but I >> don't think they do as you can't trust any information in the inner >> header. So either you need crypto or you check the inner header >> against >> know information. But if you knew in the first place, why add the >> header...? > I'm thinking more at a conceptual level where tunneling implies > that a packet logically injected by the "identifier layer" > on one node with source and destination being identifiers > and being tunneled (by putting it in an IP packet with > source and destination being locators) to the "identifier layer" > unmodified. > Thus conceptually it is wrapped in an IP packet and then unwrapped. Yes, this is a good way of looking at it. > This doesn't prevent optimizations like avoiding an extra IP header > when it is known that the receiver can map from the pair of > locators in the packet to the pair of identifiers. > To do this compression would require some packet exchange to establish > the > state thus for delay reasons it might in some cases make sense to be > able > to start sending "uncompressed" packets in parallel with such state > being > established. I see three ways to do this. See the link to a draft I posted on this list last week (http://www.muada.com/drafts/draft-van-beijnum-multi6-2pi1a.txt) where I tried to make this work with as little state as possible. The destination identifier in packets to the server is implied, as the server can map the locator address used to the identifier without maintaining any per-session state. For the client address we can't do this so I decided to encode the alternative prefix into the address in addition to the regular prefix. > > And perhaps such state should be optional. It isn't likely to be > harmful > when the tunnel endpoint is the host, but there might potentially be > scaling issues when the tunnel endpoint is some form of per-site proxy. > > So I don't mind avoiding 40 useless bytes either. > > Erik From owner-multi6@ops.ietf.org Tue May 20 11:30:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17726 for ; Tue, 20 May 2003 11:30:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19I96Y-0007Q5-00 for multi6-data@psg.com; Tue, 20 May 2003 15:32:42 +0000 Received: from ran.psg.com ([209.20.253.166]) by psg.com with esmtp (Exim 3.36 #1) id 19I96V-0007OD-00 for multi6@ops.ietf.org; Tue, 20 May 2003 15:32:40 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.14) id 19I96S-0006Su-Dt; Tue, 20 May 2003 08:32:36 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 20 May 2003 08:32:35 -0700 To: Kurt Erik Lindqvist Cc: Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: Agenda for Vienna References: <5EE3E008-884B-11D7-8597-00039388672E@muada.com> <82FBDF14-8A8E-11D7-BA5E-000393A638B2@kurtis.pp.se> Message-Id: X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ( i was on holiday, and then a mail system here broke. sorry for the latter. eat your hearts out re the former :-) >> Randy, are you seriously suggesting that the chairs will be denied >> even a signle session in Vienna? i said "no agenda, no meeting." that is normal ietf practice. life is simple until you get above layer eight. ymmv. > When in Barcelona, Randy told me he would approve the two session > approach. I think that Randys point above is that we now need to prove > that we can use those two sessions for something useful and actually > produce something. yup. randy From owner-multi6@ops.ietf.org Tue May 20 12:43:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20826 for ; Tue, 20 May 2003 12:43:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IACj-000L8F-00 for multi6-data@psg.com; Tue, 20 May 2003 16:43:09 +0000 Received: from smtp01.uc3m.es ([163.117.136.121] helo=smtp.uc3m.es) by psg.com with esmtp (Exim 3.36 #1) id 19IACf-000L7z-00 for multi6@ops.ietf.org; Tue, 20 May 2003 16:43:05 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 4587C43143; Tue, 20 May 2003 18:43:04 +0200 (CEST) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp01.uc3m.es (Postfix) with ESMTP id C11B299E7B; Tue, 20 May 2003 18:43:01 +0200 (CEST) Subject: Re: Identifier (structure) [Was: Agenda for Vienna] From: marcelo bagnulo To: Erik Nordmark Cc: Iljitsch van Beijnum , multi6@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Organization: uc3m Message-Id: <1053448888.752.42.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 20 May 2003 18:41:29 +0200 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-32.9 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Erik, > Yes, that is one approach. > It might make it more difficult for transition schemes where an unmodified > IPv6 host plus some "proxy" e.g. at the site border together implement things. > In such a case I think the IPv6 host (for transition purposes) would > send packets where IP source and destination are identifiers > thus the "proxy" would not see such higher level "real" identifiers. > > Another issue to consider in this space is the goal to allow > applications already ported to IPv6 to continue to work when > the application uses getaddrinfo() followed by connect()/sendto(). > This is at least easier to accomplish if the identifier fits in 128 bits. > Do you think that the identifier name space should be the same that the locator address space or should be a separate one? I mean, we could use the IPv6 address space to contain both locators and identifiers and that any address could be used both as an identifier or as locator. The other option is to split the IPv6 address space and reserve a part of it to identifiers Finally, we could use a completely separate 128 bit address space I guess that there are some clear benefits in all the cases, for instance: if we create a completely new address space, we can use it fits better to our needs. The first option can provide us with good backward compatibility, since old hosts can just use the address bothas identifier and locator and no mapping (i.e. additional security) is needed. But i am sure that there is much more here for me to understand... > So these are all important tradeoffs to try to understand better. > Fully agree, A really good approach to this issue is JNC's Endpoint and endpoint names (can be found http://users.exis.net/~jnc/tech/endpoints.txt) for those few of you who has not read it yet :-) I would even say that this should become a wg document regards, marcelo > > > - are (the fields of) the identifiers managed for uniqueness and other > > > purposes or are they more or less random? (If there is internal > > > structure > > > potentially different fields can be different in this respect.) > > > > I would like to make as few assumptions about the identifiers as > > possible, so we can use different kinds of identifiers and not just > > IPv6 addresses. FQDNs would make good identifiers. Cryptographic hashes > > are also useful identifiers for some purposes. But that means we have > > to design for the lowest common denominator = no real structure = hard > > to look up. > > Makes sense. > > If the identifier is split into "site identifier" plus "node within site ID" > then it might be feasable to build a distributed hash table for > the site identifier part. > Some hard issues there is how to secure the DHT (the updates and the > information retrieved from it) - but that might not be that much different > than securing the source identifier received in a packet; solve one and the > other might fall out. > > Erik > -- marcelo bagnulo uc3m From owner-multi6@ops.ietf.org Tue May 20 13:49:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22846 for ; Tue, 20 May 2003 13:49:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IBDv-0008xR-00 for multi6-data@psg.com; Tue, 20 May 2003 17:48:27 +0000 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 19IBDs-0008u9-00 for multi6@ops.ietf.org; Tue, 20 May 2003 17:48:24 +0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA29605; Tue, 20 May 2003 10:48:18 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h4KHmHq03670; Tue, 20 May 2003 10:48:17 -0700 X-mProtect: <200305201748> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.79, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdRYUORN; Tue, 20 May 2003 10:48:15 PDT Received: (from david@localhost) by iprg.nokia.com (8.11.2/8.11.2) id h4KHqSj29874; Tue, 20 May 2003 10:52:28 -0700 Date: Tue, 20 May 2003 10:52:28 -0700 From: David Kessens To: Kurt Erik Lindqvist Cc: multi6@ops.ietf.org Subject: Re: WG Last-call for draft-ietf-multi6-multihoming-requirements-06.txt Message-ID: <20030520105228.A29847@iprg.nokia.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from kurtis@kurtis.pp.se on Tue, May 20, 2003 at 09:22:06AM +0200 X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurtis, On Tue, May 20, 2003 at 09:22:06AM +0200, Kurt Erik Lindqvist wrote: > > (I hope this goes a lot better than last time) > > So this mail announces the last chance to comment on the above draft. > If nothing particular have been commented before 17.00 CET Wed 21 May > 2003 I will ship this to the IESG. (Yes this is a short period). I would like to voice my support for shipping this draft. David K. --- From owner-multi6@ops.ietf.org Tue May 20 15:02:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25254 for ; Tue, 20 May 2003 15:02:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19ICMV-0000mU-00 for multi6-data@psg.com; Tue, 20 May 2003 19:01:23 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19ICMT-0000mD-00 for multi6@ops.ietf.org; Tue, 20 May 2003 19:01:21 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h4KIxrn53982; Tue, 20 May 2003 20:59:53 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 20 May 2003 21:00:00 +0200 Subject: Re: tunneling [Was: Agenda for Vienna] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Erik Nordmark , multi6@ops.ietf.org To: Iljitsch van Beijnum From: Iljitsch van Beijnum In-Reply-To: Message-Id: <4176E9E6-8AF5-11D7-B7A7-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This message was supposed to go to my drafts folder but I must have hit send... On dinsdag, mei 20, 2003, at 17:14 Europe/Amsterdam, Iljitsch van Beijnum wrote: >> To do this compression would require some packet exchange to >> establish the >> state thus for delay reasons it might in some cases make sense to be >> able >> to start sending "uncompressed" packets in parallel with such state >> being >> established. > I see three ways to do this. See the link to a draft I posted on this > list last week > (http://www.muada.com/drafts/draft-van-beijnum-multi6-2pi1a.txt) where > I tried to make this work with as little state as possible. The > destination identifier in packets to the server is implied, as the > server can map the locator address used to the identifier without > maintaining any per-session state. For the client address we can't do > this so I decided to encode the alternative prefix into the address in > addition to the regular prefix. Five ways. The above uses two different ones for servers and clients: 1. Encoding the locators in the identifier 2. Looking up the mapping from the identifier to locators somewhere 3. Negotiate the mapping before communication happens (like the ISAKMP protocol does) but this requires some bootstrapping mechanism 4. Negotiate the mapping during session start 5. Send the packet and receive the mapping state if there is any I think the simple DNS approach is a good choice to start with unless depending on the DNS isn't acceptable. Option 5 could be a reasonable alternative if we decide we have to go with crypto (which I personally don't care for). But it's hard to know at this stage what the best approach is, and there probably isn't a single best approach. So what I'd like to see happen is that we select the simplest option as a default mechanism that everyone must implement, but keep the option open for the user to override this default behavior in a way that doesn't make the implementation too complex. This could solve the policy problem in enterprises. People running enterprise networks have told us they absolutely positively need mechanisms to implement traffic engineering and other policies and not depend on what any particular host decides is the best way to route a packet. With this hook in place hosts could run a daemon that asks some central servers about the mapping state and source/dest locator preference whenever a session is initiated to a destination for which there is no mapping state yet. (A stateless way to see if a destination is multihomed or legacy v4 would be good here.) This has the additional benefit that the dependence on the DNS isn't so bad anymore. Mapping information for known correspondents can be cached on local storage and periodically updated rather than resolved whenever the information is needed. >> And perhaps such state should be optional. It isn't likely to be >> harmful >> when the tunnel endpoint is the host, but there might potentially be >> scaling issues when the tunnel endpoint is some form of per-site >> proxy. We can make receiving stateless if we create our own mapping for sending and depend on return routability. This wouldn't lead to worse security problems than regular IP. So if we can make mapping from the identifier to the locator for sending stateless we're in stateless business. From owner-multi6@ops.ietf.org Tue May 20 16:30:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29067 for ; Tue, 20 May 2003 16:30:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IDjF-0005ok-00 for multi6-data@psg.com; Tue, 20 May 2003 20:28:57 +0000 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #1) id 19IDjC-0005oU-00 for multi6@ops.ietf.org; Tue, 20 May 2003 20:28:54 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 7E0B934466; Tue, 20 May 2003 12:43:31 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h4KKSoYB029985; Tue, 20 May 2003 13:28:54 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: tunneling [Was: Agenda for Vienna] Date: Tue, 20 May 2003 13:28:50 -0700 Message-ID: Thread-Topic: tunneling [Was: Agenda for Vienna] Thread-Index: AcMfBMgpHd9RAb6fTQGwCISUaeePFgACQW9Q From: "Tony Li" To: "Iljitsch van Beijnum" Cc: "Erik Nordmark" , X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA29067 Meta note: if we're trying to talk architecture, I'd say that dealing with the identifier/locator relationship is secondary. Our primary discussion should be about alternatives to "identifier/locator split" solutions. That's clearly one architecture, what are others that folks find credible? Tunneling has certainly been mentioned. I've always considered this simply a mechanism for virtualizing the topology. There's effectively still a single address per host, so there's nothing new in addressing. Other directions? Tony | -----Original Message----- | From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] | Sent: Tuesday, May 20, 2003 12:00 PM | To: Iljitsch van Beijnum | Cc: Erik Nordmark; multi6@ops.ietf.org | Subject: Re: tunneling [Was: Agenda for Vienna] | | | This message was supposed to go to my drafts folder but I | must have hit | send... | | On dinsdag, mei 20, 2003, at 17:14 Europe/Amsterdam, Iljitsch van | Beijnum wrote: | | >> To do this compression would require some packet exchange to | >> establish the | >> state thus for delay reasons it might in some cases | make sense to be | >> able | >> to start sending "uncompressed" packets in parallel | with such state | >> being | >> established. | | > I see three ways to do this. See the link to a draft I | posted on this | > list last week | > | (http://www.muada.com/drafts/draft-van-beijnum-multi6-2pi1a | .txt) where | > I tried to make this work with as little state as possible. The | > destination identifier in packets to the server is | implied, as the | > server can map the locator address used to the | identifier without | > maintaining any per-session state. For the client | address we can't do | > this so I decided to encode the alternative prefix into | the address in | > addition to the regular prefix. | | Five ways. The above uses two different ones for servers | and clients: | | 1. Encoding the locators in the identifier | 2. Looking up the mapping from the identifier to locators somewhere | 3. Negotiate the mapping before communication happens | (like the ISAKMP | protocol does) but this requires some bootstrapping mechanism | 4. Negotiate the mapping during session start | 5. Send the packet and receive the mapping state if there is any | | I think the simple DNS approach is a good choice to start | with unless | depending on the DNS isn't acceptable. Option 5 could be a | reasonable | alternative if we decide we have to go with crypto (which | I personally | don't care for). | | But it's hard to know at this stage what the best approach is, and | there probably isn't a single best approach. So what I'd | like to see | happen is that we select the simplest option as a default | mechanism | that everyone must implement, but keep the option open for | the user to | override this default behavior in a way that doesn't make the | implementation too complex. | | This could solve the policy problem in enterprises. People running | enterprise networks have told us they absolutely positively need | mechanisms to implement traffic engineering and other | policies and not | depend on what any particular host decides is the best way | to route a | packet. With this hook in place hosts could run a daemon | that asks some | central servers about the mapping state and source/dest locator | preference whenever a session is initiated to a | destination for which | there is no mapping state yet. (A stateless way to see if | a destination | is multihomed or legacy v4 would be good here.) | | This has the additional benefit that the dependence on the | DNS isn't so | bad anymore. Mapping information for known correspondents | can be cached | on local storage and periodically updated rather than | resolved whenever | the information is needed. | | >> And perhaps such state should be optional. It isn't | likely to be | >> harmful | >> when the tunnel endpoint is the host, but there might | potentially be | >> scaling issues when the tunnel endpoint is some form of | per-site | >> proxy. | | We can make receiving stateless if we create our own mapping for | sending and depend on return routability. This wouldn't | lead to worse | security problems than regular IP. So if we can make | mapping from the | identifier to the locator for sending stateless we're in stateless | business. | | | From owner-multi6@ops.ietf.org Tue May 20 18:00:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01932 for ; Tue, 20 May 2003 18:00:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IF8G-000BJx-00 for multi6-data@psg.com; Tue, 20 May 2003 21:58:52 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19IF8E-000BJl-00 for multi6@ops.ietf.org; Tue, 20 May 2003 21:58:50 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h4KLvPn54275; Tue, 20 May 2003 23:57:25 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 20 May 2003 23:57:32 +0200 Subject: Re: tunneling [Was: Agenda for Vienna] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: "Tony Li" From: Iljitsch van Beijnum In-Reply-To: Message-Id: <0EA27AB2-8B0E-11D7-B7A7-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On dinsdag, mei 20, 2003, at 22:28 Europe/Amsterdam, Tony Li wrote: > Meta note: if we're trying to talk architecture, I'd say that > dealing with the identifier/locator relationship is secondary. I don't think we can make informed decisions about the architectural approach unless we know how well each approach is going to work out. That's why I keep going into detail. > Our primary discussion should be about alternatives to > "identifier/locator split" solutions. That's clearly one > architecture, what are others that folks find credible? Ok, let me list some solutions that have come up: - mobility - HIP - source routing / conditional source routing - controlled deaggregation - backup path over second ISP using routing or tunnels - address agile transports - loc/id - geo aggregation I think the limitations of each have been discussed in the past. Some kind of more formal recap would probably be useful at this point. Kurt, is that what you want in your first proposed Vienna meeting or do you only want "active" solutions discussed there? > Tunneling has certainly been mentioned. I've always considered > this simply a mechanism for virtualizing the topology. There's > effectively still a single address per host, so there's nothing > new in addressing. After some discussions on the ipv6mh mailinglist we reached the conclusion that rewriting the original source and destination addresses with something else at the source and then replacing the original addresses before the packet is processed at the destination is simply tunneling optimized for header size at the cost of some state. So I guess that makes the loc/id thing a dynamic version of tunneling... From owner-multi6@ops.ietf.org Tue May 20 22:11:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08559 for ; Tue, 20 May 2003 22:11:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IJ27-0005gv-00 for multi6-data@psg.com; Wed, 21 May 2003 02:08:47 +0000 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #1) id 19IJ1b-0005cR-00 for multi6@ops.ietf.org; Wed, 21 May 2003 02:08:15 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 50B6F23C2F; Tue, 20 May 2003 18:56:26 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h4L289YB016164; Tue, 20 May 2003 19:08:14 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: tunneling [Was: Agenda for Vienna] Date: Tue, 20 May 2003 19:08:09 -0700 Message-ID: Thread-Topic: tunneling [Was: Agenda for Vienna] Thread-Index: AcMfGwSwbB2Rj3YaS7Smle8O6JwpcwAIhDfQ From: "Tony Li" To: "Iljitsch van Beijnum" Cc: X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA08559 | > Meta note: if we're trying to talk architecture, I'd say that | > dealing with the identifier/locator relationship is secondary. | | I don't think we can make informed decisions about the | architectural | approach unless we know how well each approach is going to | work out. | That's why I keep going into detail. This is a common trap. Some detail causes someone else to go into further detail and then we end up arguing about the details. Bzzt. We need to understand at the very top level how things are going to work. Then we flesh out details. If things aren't going to work at the top level, then the details are a waste of time. Tony From owner-multi6@ops.ietf.org Wed May 21 01:16:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12465 for ; Wed, 21 May 2003 01:16:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19ILwH-000PmO-00 for multi6-data@psg.com; Wed, 21 May 2003 05:14:57 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19ILwF-000Pjp-00 for multi6@ops.ietf.org; Wed, 21 May 2003 05:14:55 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4L5Eif07260; Wed, 21 May 2003 08:14:44 +0300 Date: Wed, 21 May 2003 08:14:44 +0300 (EEST) From: Pekka Savola To: Iljitsch van Beijnum cc: Tony Li , Subject: Re: tunneling [Was: Agenda for Vienna] In-Reply-To: <0EA27AB2-8B0E-11D7-B7A7-00039388672E@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 20 May 2003, Iljitsch van Beijnum wrote: > Ok, let me list some solutions that have come up: > > - mobility > - HIP > - source routing / conditional source routing > - controlled deaggregation - controlled assignment of address space to a class of sites > - backup path over second ISP using routing or tunnels > - address agile transports > - loc/id > - geo aggregation HIP is a subset of loc/id, or maybe you mean a different kind of loc-id. If you're using loc/id to refer to loc/id separation in the network, stop abusing the term to apply for that only. > > Tunneling has certainly been mentioned. I've always considered > > this simply a mechanism for virtualizing the topology. There's > > effectively still a single address per host, so there's nothing > > new in addressing. > > After some discussions on the ipv6mh mailinglist we reached the > conclusion that rewriting the original source and destination addresses > with something else at the source and then replacing the original > addresses before the packet is processed at the destination is simply > tunneling optimized for header size at the cost of some state. So I > guess that makes the loc/id thing a dynamic version of tunneling... The failure modes are entirely different with rewriting and tunneling. Consider the case where the state is not fully shared with those who might would need it, and the requirements for the devices which must have the state. Tunneling is a very simple thing for intermediaries, and a bit more for the end-points (a bit less than rewriting though). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Wed May 21 01:27:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12675 for ; Wed, 21 May 2003 01:27:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IM8A-0001SN-00 for multi6-data@psg.com; Wed, 21 May 2003 05:27:14 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19IM88-0001SA-00 for multi6@ops.ietf.org; Wed, 21 May 2003 05:27:12 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4L5Qxn07347; Wed, 21 May 2003 08:26:59 +0300 Date: Wed, 21 May 2003 08:26:59 +0300 (EEST) From: Pekka Savola To: Tony Li cc: Iljitsch van Beijnum , Erik Nordmark , Subject: RE: tunneling [Was: Agenda for Vienna] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 20 May 2003, Tony Li wrote: > Meta note: if we're trying to talk architecture, I'd say that > dealing with the identifier/locator relationship is secondary. > > Our primary discussion should be about alternatives to > "identifier/locator split" solutions. That's clearly one > architecture, what are others that folks find credible? > > Tunneling has certainly been mentioned. I've always considered > this simply a mechanism for virtualizing the topology. There's > effectively still a single address per host, so there's nothing > new in addressing. "Tunneling" is too generic a term here, and I don't know how you mean it. I think you refer to some host-to-host end2end automatic tunneling mechanisms.. > Other directions? (I'm wondering how to say this without going too far into solutions, perhaps trying to abstract Iljitsch' list might be useful.) 1) caring for the small organizations - use of multiple addresses, connection survivability optional - multi-connecting 2) caring for the very large/international organizations - having very large end-sites have their own address blocks - requiring international endsites to get addresses for each region from a regional ISP (satisfies the traffic engineering requirements) IMO, the biggest question seems to be whether we want to find a "magic" solution for large/larger end-sites. Smaller ones are probably easier to cure rather easily. It may also be prudent to consider which properties of multihoming are required for each scenario: - being able to switch ISP's without renumbering - redundancy due to link failures etc. - connection survivability (internal connections, external connections) - more fine-grained (ie. not 50/50) inbound traffic engineering - the maximum frequency of ISP (=prefix) changes - ... but perhaps this is a bit too detailed yet. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Wed May 21 02:19:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28316 for ; Wed, 21 May 2003 02:19:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IMuf-0005HT-00 for multi6-data@psg.com; Wed, 21 May 2003 06:17:21 +0000 Received: from astrolabe.info.ucl.ac.be ([130.104.229.109] helo=info.ucl.ac.be) by psg.com with esmtp (Exim 3.36 #1) id 19IMu8-0005Gk-00 for multi6@ops.ietf.org; Wed, 21 May 2003 06:16:49 +0000 Received: from descartes.info.ucl.ac.be (descartes [130.104.229.82]) by info.ucl.ac.be (8.12.9/8.12.8) with ESMTP id h4L6FNgV012789; Wed, 21 May 2003 08:15:23 +0200 (MET DST) Subject: Re: tunneling [Was: Agenda for Vienna] From: Cedric de Launois To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org In-Reply-To: <4176E9E6-8AF5-11D7-B7A7-00039388672E@muada.com> References: <4176E9E6-8AF5-11D7-B7A7-00039388672E@muada.com> Content-Type: text/plain; charset=ISO-8859-1 Organization: Universite Catholique de Louvain Message-Id: <1053497844.892.107.camel@descartes.info.ucl.ac.be> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 21 May 2003 08:17:24 +0200 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-31.5 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_XIMIAN autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Le mar 20/05/2003 à 21:00, Iljitsch van Beijnum a écrit : > This could solve the policy problem in enterprises. People running > enterprise networks have told us they absolutely positively need > mechanisms to implement traffic engineering and other policies and not > depend on what any particular host decides is the best way to route a > packet. With this hook in place hosts could run a daemon that asks some > central servers about the mapping state and source/dest locator > preference whenever a session is initiated to a destination for which > there is no mapping state yet. (A stateless way to see if a destination > is multihomed or legacy v4 would be good here.) This is exactly what is done in the new draft http://www.ietf.org/internet-drafts/draft-de-launois-multi6-naros-00.txt Maybe you should take a look at it. We would appreciate your comments ! Cédric de Launois From owner-multi6@ops.ietf.org Wed May 21 03:26:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10890 for ; Wed, 21 May 2003 03:26:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19INy4-0009m8-00 for multi6-data@psg.com; Wed, 21 May 2003 07:24:56 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19INxm-0009ih-00 for multi6@ops.ietf.org; Wed, 21 May 2003 07:24:38 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h4L7NEn55309; Wed, 21 May 2003 09:23:14 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 21 May 2003 09:23:21 +0200 Subject: Re: tunneling [Was: Agenda for Vienna] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Tony Li" From: Iljitsch van Beijnum In-Reply-To: Message-Id: <19FEC52D-8B5D-11D7-B7A7-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On woensdag, mei 21, 2003, at 04:08 Europe/Amsterdam, Tony Li wrote: > | I don't think we can make informed decisions about the > | architectural > | approach unless we know how well each approach is going to > | work out. That's why I keep going into detail. > This is a common trap. So then there must be a reason why it's hard to avoid it. :-) > Some detail causes someone else to go into > further detail and then we end up arguing about the details. Bzzt. > We need to understand at the very top level how things are going > to work. Then we flesh out details. If things aren't going to > work at the top level, then the details are a waste of time. Didn't we kinda sorta agree that loc/id is our collective favorite architecture and that the rest is either flawed, should be worked on elsewhere or no interest in working on it as a group? Even though we get a bit sidetracked from time to time, I think we're having a very useful discussion on the identifier semantics and mapping mechanisms right now. From owner-multi6@ops.ietf.org Wed May 21 03:28:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10921 for ; Wed, 21 May 2003 03:28:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IO1B-000A3d-00 for multi6-data@psg.com; Wed, 21 May 2003 07:28:09 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19IO11-000A2d-00 for multi6@ops.ietf.org; Wed, 21 May 2003 07:27:59 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h4L7QZn55316; Wed, 21 May 2003 09:26:35 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 21 May 2003 09:26:43 +0200 Subject: Re: tunneling [Was: Agenda for Vienna] Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Cedric de Launois From: Iljitsch van Beijnum In-Reply-To: <1053497844.892.107.camel@descartes.info.ucl.ac.be> Message-Id: <9234DABA-8B5D-11D7-B7A7-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On woensdag, mei 21, 2003, at 08:17 Europe/Amsterdam, Cedric de Launois wrote: >> packet. With this hook in place hosts could run a daemon that asks >> some >> central servers about the mapping state and source/dest locator >> preference whenever a session is initiated to a destination for which >> there is no mapping state yet. (A stateless way to see if a >> destination >> is multihomed or legacy v4 would be good here.) > This is exactly what is done in the new draft > http://www.ietf.org/internet-drafts/draft-de-launois-multi6-naros- > 00.txt > Maybe you should take a look at it. We would appreciate your comments ! Yes I read it after Brian mentioned it. My main comment is that it only addresses the source address if I read it correctly. Why not ask the system for the best destination/source combination? And maybe report back if something doesn't work so the next host gets better information? From owner-multi6@ops.ietf.org Wed May 21 04:18:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11852 for ; Wed, 21 May 2003 04:18:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IOn3-000EGl-00 for multi6-data@psg.com; Wed, 21 May 2003 08:17:37 +0000 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #1) id 19IOmt-000EFM-00 for multi6@ops.ietf.org; Wed, 21 May 2003 08:17:27 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id D074B3442A; Wed, 21 May 2003 00:32:04 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h4L8HQYB000230; Wed, 21 May 2003 01:17:26 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: tunneling [Was: Agenda for Vienna] Date: Wed, 21 May 2003 01:02:27 -0700 Message-ID: Thread-Topic: tunneling [Was: Agenda for Vienna] Thread-Index: AcMfag4G/t5Z+xsfQaOba4u0mDyDDwABLGzw From: "Tony Li" To: "Iljitsch van Beijnum" Cc: X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA11852 | > | I don't think we can make informed decisions about the | > | architectural | > | approach unless we know how well each approach is going to | > | work out. That's why I keep going into detail. | | > This is a common trap. | | So then there must be a reason why it's hard to avoid it. :-) Good engineers are detail oriented. Even when they shouldn't be. | Didn't we kinda sorta agree that loc/id is our collective favorite | architecture and that the rest is either flawed, should be | worked on | elsewhere or no interest in working on it as a group? I think that you and I agreed that. However, if we are to truly build WG consensus on this issue, it's only fair that we allow supporters of alternatives to speak their piece. I'm hoping that if there are any such folks, they will speak up, so that we are not accused later of shouting them down. | Even though we get a bit sidetracked from time to time, I | think we're | having a very useful discussion on the identifier | semantics and mapping | mechanisms right now. I think that the cart belongs behind the horse. Until we get rough consensus on the architecture and make a decision, all other energies are a distraction from that milestone. Tony From owner-multi6@ops.ietf.org Wed May 21 04:23:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11891 for ; Wed, 21 May 2003 04:23:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IOsT-000Etb-00 for multi6-data@psg.com; Wed, 21 May 2003 08:23:13 +0000 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #1) id 19IOsL-000Et4-00 for multi6@ops.ietf.org; Wed, 21 May 2003 08:23:05 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA23517 for ; Wed, 21 May 2003 09:23:03 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id JAA23311 for ; Wed, 21 May 2003 09:23:03 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h4L8N3V04325 for multi6@ops.ietf.org; Wed, 21 May 2003 09:23:03 +0100 Date: Wed, 21 May 2003 09:23:03 +0100 From: Tim Chown To: multi6@ops.ietf.org Subject: Re: tunneling [Was: Agenda for Vienna] Message-ID: <20030521082303.GF3653@login.ecs.soton.ac.uk> Mail-Followup-To: multi6@ops.ietf.org References: <19FEC52D-8B5D-11D7-B7A7-00039388672E@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19FEC52D-8B5D-11D7-B7A7-00039388672E@muada.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, May 21, 2003 at 09:23:21AM +0200, Iljitsch van Beijnum wrote: > > Didn't we kinda sorta agree that loc/id is our collective favorite > architecture and that the rest is either flawed, should be worked on > elsewhere or no interest in working on it as a group? So if you were drawing out a multihoming roadmap, where would loc/id be on that roadmap? I ask because we should consider what we can do short-term and long-term. Is the loc/id approach long-term? Christian's multi-address "challenge" is much more short-term, and I think is something we should push forward on now. The question then is whether we need to create any swamp in the interim for large enterprises for which Christian's approach is out of scope and where loc/id (in the host or at the edge) is too far off. Might we for example agree what the multi6 group can do now to assist multihoming for new IPv6 deployments, and then "split off" long term approaches (either within the group or out to IRTF if long-term really is just that)? Should multi6 focus on what can be done now, or what can be done in 3+ years? > Even though we get a bit sidetracked from time to time, I think we're > having a very useful discussion on the identifier semantics and mapping > mechanisms right now. This is the sort of thing that should be on the Vienna agenda. Tim From owner-multi6@ops.ietf.org Wed May 21 05:25:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12798 for ; Wed, 21 May 2003 05:25:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IPq4-000LHw-00 for multi6-data@psg.com; Wed, 21 May 2003 09:24:48 +0000 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238]) by psg.com with esmtp (Exim 3.36 #1) id 19IPpv-000LDp-00 for multi6@ops.ietf.org; Wed, 21 May 2003 09:24:39 +0000 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-5.de.ibm.com (8.12.9/8.12.8) with ESMTP id h4L9OGlr088572; Wed, 21 May 2003 11:24:18 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h4L9NkJ4178168; Wed, 21 May 2003 11:23:47 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA16750 from ; Wed, 21 May 2003 11:23:44 +0200 Message-Id: <3ECB45BC.C66F56BD@hursley.ibm.com> Date: Wed, 21 May 2003 11:24:12 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Iljitsch van Beijnum Cc: Cedric de Launois , multi6@ops.ietf.org Subject: Re: tunneling [Was: Agenda for Vienna] References: <9234DABA-8B5D-11D7-B7A7-00039388672E@muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > > On woensdag, mei 21, 2003, at 08:17 Europe/Amsterdam, Cedric de Launois > wrote: > > >> packet. With this hook in place hosts could run a daemon that asks > >> some > >> central servers about the mapping state and source/dest locator > >> preference whenever a session is initiated to a destination for which > >> there is no mapping state yet. (A stateless way to see if a > >> destination > >> is multihomed or legacy v4 would be good here.) > > > This is exactly what is done in the new draft > > http://www.ietf.org/internet-drafts/draft-de-launois-multi6-naros- > > 00.txt > > > Maybe you should take a look at it. We would appreciate your comments ! > > Yes I read it after Brian mentioned it. My main comment is that it only > addresses the source address if I read it correctly. Why not ask the > system for the best destination/source combination? And maybe report > back if something doesn't work so the next host gets better information? If we want to develop a multi-address based solution, these questions would need to be answered. Plus why not do the same thing using DNS. Plus security, since as proposed it is wide open to attack. But first, let's decide if we want a multi-address solution. Brian From owner-multi6@ops.ietf.org Wed May 21 06:04:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13631 for ; Wed, 21 May 2003 06:04:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IQRw-000Puq-00 for multi6-data@psg.com; Wed, 21 May 2003 10:03:56 +0000 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238]) by psg.com with esmtp (Exim 3.36 #1) id 19IQRk-000Pnz-00 for multi6@ops.ietf.org; Wed, 21 May 2003 10:03:44 +0000 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-5.de.ibm.com (8.12.9/8.12.8) with ESMTP id h4LA3alr089706 for ; Wed, 21 May 2003 12:03:40 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h4LA1xJ4254118 for ; Wed, 21 May 2003 12:02:04 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA42376 from ; Wed, 21 May 2003 12:01:58 +0200 Message-Id: <3ECB4EB2.9141D299@hursley.ibm.com> Date: Wed, 21 May 2003 12:02:26 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: multi6@ops.ietf.org Subject: Options to consider [Re: tunneling [Was: Agenda for Vienna]] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tony is correct, we need to take the big decisions first. So, I think we have these options to consider: 1. For really big enterprises, leave the RIRs to set a policy that allows such enterprises to get a /32 and negotiate appropriately with ISPs. No work for the IETF. 2. Design a multi-address based solution, where an enterprise would have multiple PA prefixes and some technology would be added to support address selection. draft-de-launois-multi6-naros-00.txt might be the starting point. --> this is a conservative approach. It doesn't change anything in the addressing or routing architecture. We could write a WG charter for this quite easily. 3. Design a two-level solution, in which a locator is used for routing and an identifier is used end2end (and possibly for local routing). There are several sub-options: 3.1 Map-and-encapsulate, i.e. tunnels driven by a distributed mapping. In this case, both the locator and the identifier can be standard addresses, the identifier perhaps being something like draft-hinden-ipv6-global-local-addr-00.txt. 3.2 Splitting the address into two fields, and swapping routing prefixes en route (a.k.a. GSE) 3.3 Swapping & restoring addresses en route. Again, both the identifier and locator can be standard addresses. 3.4 Carrying the identifier, whatever it is, in an extension header. All of these carry the need for locator mapping. Actually, the multi-address method also needs equivalent mapping information, it's just a bit hidden. So that seems to be our fundamental piece of magic. 800 numbers, anybody? It seems to me we can plausibly pursue all three of the above approaches, with 1) being immediate, 2) being medium term and any of 3) being long term. 4. Transport layer solution. My belief is that TCP is too entrenched for this to be a reasonable approach. Brian Tony Li wrote: > > | > | I don't think we can make informed decisions about the > | > | architectural > | > | approach unless we know how well each approach is going to > | > | work out. That's why I keep going into detail. > | > | > This is a common trap. > | > | So then there must be a reason why it's hard to avoid it. :-) > > Good engineers are detail oriented. Even when they shouldn't be. > > | Didn't we kinda sorta agree that loc/id is our collective favorite > | architecture and that the rest is either flawed, should be > | worked on > | elsewhere or no interest in working on it as a group? > > I think that you and I agreed that. However, if we are to truly build > WG consensus on this issue, it's only fair that we allow supporters > of alternatives to speak their piece. I'm hoping that if there are > any such folks, they will speak up, so that we are not accused later > of shouting them down. > > > | Even though we get a bit sidetracked from time to time, I > | think we're > | having a very useful discussion on the identifier > | semantics and mapping > | mechanisms right now. > > I think that the cart belongs behind the horse. Until we get rough > consensus on the architecture and make a decision, all other energies > are a distraction from that milestone. > > Tony -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland From owner-multi6@ops.ietf.org Wed May 21 06:17:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13819 for ; Wed, 21 May 2003 06:17:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IQee-000146-00 for multi6-data@psg.com; Wed, 21 May 2003 10:17:04 +0000 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #1) id 19IQea-00013K-00 for multi6@ops.ietf.org; Wed, 21 May 2003 10:17:00 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA27389 for ; Wed, 21 May 2003 11:16:59 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id LAA29334 for ; Wed, 21 May 2003 11:16:59 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h4LAGwS06978 for multi6@ops.ietf.org; Wed, 21 May 2003 11:16:58 +0100 Date: Wed, 21 May 2003 11:16:58 +0100 From: Tim Chown To: multi6@ops.ietf.org Subject: Re: Options to consider [Re: tunneling [Was: Agenda for Vienna]] Message-ID: <20030521101658.GQ3653@login.ecs.soton.ac.uk> Mail-Followup-To: multi6@ops.ietf.org References: <3ECB4EB2.9141D299@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3ECB4EB2.9141D299@hursley.ibm.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk This looks good. For #2, Christian also presented a 4-6 stage plan that would enable such a solution. I haven't read launois-multi6-naros-00 yet, maybe it is similar to Christian's proposal. If we have concensus on this, we could build and agenda around it. But I am very aware there are other proposals, which should be allowed a fair shout (or which may go their own commercial way anyway ;) Tim On Wed, May 21, 2003 at 12:02:26PM +0200, Brian E Carpenter wrote: > Tony is correct, we need to take the big decisions first. So, I think we > have these options to consider: > > 1. For really big enterprises, leave the RIRs to set a policy that > allows such enterprises to get a /32 and negotiate appropriately > with ISPs. No work for the IETF. > > 2. Design a multi-address based solution, where an enterprise would > have multiple PA prefixes and some technology would be added to support > address selection. draft-de-launois-multi6-naros-00.txt > might be the starting point. > > --> this is a conservative approach. It doesn't change anything in > the addressing or routing architecture. We could write a WG > charter for this quite easily. > > 3. Design a two-level solution, in which a locator is used > for routing and an identifier is used end2end (and possibly > for local routing). There are several sub-options: > > 3.1 Map-and-encapsulate, i.e. tunnels driven by a distributed mapping. > In this case, both the locator and the identifier can be standard > addresses, the identifier perhaps being something like > draft-hinden-ipv6-global-local-addr-00.txt. > > 3.2 Splitting the address into two fields, and swapping routing prefixes > en route (a.k.a. GSE) > > 3.3 Swapping & restoring addresses en route. Again, both the identifier > and locator can be standard addresses. > > 3.4 Carrying the identifier, whatever it is, in an extension header. > > All of these carry the need for locator mapping. Actually, the multi-address > method also needs equivalent mapping information, it's just a bit hidden. > So that seems to be our fundamental piece of magic. 800 numbers, anybody? > > It seems to me we can plausibly pursue all three of the above approaches, > with 1) being immediate, 2) being medium term and any of 3) being long term. > > 4. Transport layer solution. My belief is that TCP is too entrenched for > this to be a reasonable approach. > > Brian > > Tony Li wrote: > > > > | > | I don't think we can make informed decisions about the > > | > | architectural > > | > | approach unless we know how well each approach is going to > > | > | work out. That's why I keep going into detail. > > | > > | > This is a common trap. > > | > > | So then there must be a reason why it's hard to avoid it. :-) > > > > Good engineers are detail oriented. Even when they shouldn't be. > > > > | Didn't we kinda sorta agree that loc/id is our collective favorite > > | architecture and that the rest is either flawed, should be > > | worked on > > | elsewhere or no interest in working on it as a group? > > > > I think that you and I agreed that. However, if we are to truly build > > WG consensus on this issue, it's only fair that we allow supporters > > of alternatives to speak their piece. I'm hoping that if there are > > any such folks, they will speak up, so that we are not accused later > > of shouting them down. > > > > > > | Even though we get a bit sidetracked from time to time, I > > | think we're > > | having a very useful discussion on the identifier > > | semantics and mapping > > | mechanisms right now. > > > > I think that the cart belongs behind the horse. Until we get rough > > consensus on the architecture and make a decision, all other energies > > are a distraction from that milestone. > > > > Tony > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM > On assignment at the IBM Zurich Laboratory, Switzerland From owner-multi6@ops.ietf.org Wed May 21 06:20:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13864 for ; Wed, 21 May 2003 06:20:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IQhr-0001BA-00 for multi6-data@psg.com; Wed, 21 May 2003 10:20:23 +0000 Received: from smtp03.uc3m.es ([163.117.136.123] helo=smtp.uc3m.es) by psg.com with esmtp (Exim 3.36 #1) id 19IQhn-0001Ar-00 for multi6@ops.ietf.org; Wed, 21 May 2003 10:20:19 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 4126E432A4; Wed, 21 May 2003 12:20:18 +0200 (CEST) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp03.uc3m.es (Postfix) with ESMTP id D67172B674; Wed, 21 May 2003 12:20:17 +0200 (CEST) Subject: Re: tunneling [Was: Agenda for Vienna] From: marcelo bagnulo To: Iljitsch van Beijnum Cc: Tony Li , multi6@ops.ietf.org In-Reply-To: <0EA27AB2-8B0E-11D7-B7A7-00039388672E@muada.com> References: <0EA27AB2-8B0E-11D7-B7A7-00039388672E@muada.com> Content-Type: text/plain Organization: uc3m Message-Id: <1053512321.766.20.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 May 2003 12:18:41 +0200 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, On Tue, 2003-05-20 at 23:57, Iljitsch van Beijnum wrote: > On dinsdag, mei 20, 2003, at 22:28 Europe/Amsterdam, Tony Li wrote: > > > Meta note: if we're trying to talk architecture, I'd say that > > dealing with the identifier/locator relationship is secondary. > > I don't think we can make informed decisions about the architectural > approach unless we know how well each approach is going to work out. > That's why I keep going into detail. > > > Our primary discussion should be about alternatives to > > "identifier/locator split" solutions. That's clearly one > > architecture, what are others that folks find credible? > > Ok, let me list some solutions that have come up: > > - mobility > - HIP > - source routing / conditional source routing > - controlled deaggregation > - backup path over second ISP using routing or tunnels > - address agile transports > - loc/id > - geo aggregation > to my understanding multiple of the above solutions are based on the loc/id separation That is: - mobility - HIP - address agile transports - loc/id Are solutions based on the separation of loc/id roles. I mean all of them use a fixed identifier for application layer and multiple locators for routing (in this case in the end -hosts) Moreover, i would say that all (host) multi-address solutions are based on loc/id split concept when they attempt to preserve established connections - backup path over second ISP using routing or tunnels This may also be considered a loc/id separation, sine an alternative locator is used to reach a final destination (so the original dest address plays the role of a locator) However, i think that there is some fuzziness in this, so perhaps it would be interesting to have a more precise definition about what we are talking about when we use the loc/id split expression I've tried but couldn't find any short definition that i liked... Perhaps after we have a more precise definition we could ask for opinions and reach consensus more easily. So solutions not based on loc/id separation remaining are: - controlled deaggregation - geo aggregation FWIW, i prefer the loc/id split approach (if this means what i think it does) Regards, marcelo > I think the limitations of each have been discussed in the past. Some > kind of more formal recap would probably be useful at this point. Kurt, > is that what you want in your first proposed Vienna meeting or do you > only want "active" solutions discussed there? > > > Tunneling has certainly been mentioned. I've always considered > > this simply a mechanism for virtualizing the topology. There's > > effectively still a single address per host, so there's nothing > > new in addressing. > > After some discussions on the ipv6mh mailinglist we reached the > conclusion that rewriting the original source and destination addresses > with something else at the source and then replacing the original > addresses before the packet is processed at the destination is simply > tunneling optimized for header size at the cost of some state. So I > guess that makes the loc/id thing a dynamic version of tunneling... -- marcelo bagnulo uc3m From owner-multi6@ops.ietf.org Wed May 21 06:26:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13954 for ; Wed, 21 May 2003 06:26:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IQn4-0001PA-00 for multi6-data@psg.com; Wed, 21 May 2003 10:25:46 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19IQn0-0001Ox-00 for multi6@ops.ietf.org; Wed, 21 May 2003 10:25:43 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4LAPdr09838; Wed, 21 May 2003 13:25:39 +0300 Date: Wed, 21 May 2003 13:25:39 +0300 (EEST) From: Pekka Savola To: Brian E Carpenter cc: multi6@ops.ietf.org Subject: Re: Options to consider [Re: tunneling [Was: Agenda for Vienna]] In-Reply-To: <3ECB4EB2.9141D299@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 21 May 2003, Brian E Carpenter wrote: > Tony is correct, we need to take the big decisions first. So, I think we > have these options to consider: > > 1. For really big enterprises, leave the RIRs to set a policy that > allows such enterprises to get a /32 and negotiate appropriately > with ISPs. No work for the IETF. > > 2. Design a multi-address based solution, where an enterprise would > have multiple PA prefixes and some technology would be added to support > address selection. draft-de-launois-multi6-naros-00.txt > might be the starting point. > > --> this is a conservative approach. It doesn't change anything in > the addressing or routing architecture. We could write a WG > charter for this quite easily. > > 3. Design a two-level solution, in which a locator is used > for routing and an identifier is used end2end (and possibly > for local routing). There are several sub-options: > > 3.1 Map-and-encapsulate, i.e. tunnels driven by a distributed mapping. > In this case, both the locator and the identifier can be standard > addresses, the identifier perhaps being something like > draft-hinden-ipv6-global-local-addr-00.txt. > > 3.2 Splitting the address into two fields, and swapping routing prefixes > en route (a.k.a. GSE) > > 3.3 Swapping & restoring addresses en route. Again, both the identifier > and locator can be standard addresses. > > 3.4 Carrying the identifier, whatever it is, in an extension header. > > All of these carry the need for locator mapping. Actually, the multi-address > method also needs equivalent mapping information, it's just a bit hidden. > So that seems to be our fundamental piece of magic. 800 numbers, anybody? > > It seems to me we can plausibly pursue all three of the above approaches, > with 1) being immediate, 2) being medium term and any of 3) being long term. > > 4. Transport layer solution. My belief is that TCP is too entrenched for > this to be a reasonable approach. I think we need to realize that these four options solve different problems, and not all of them completely. Based on a quick look, it seems to me that: - being able to switch ISP's without renumbering: 1), 3.2), maybe others - redundancy due to link failures etc.: 1), maube 2), maybe 3) - connection survivability (internal connections, external connections) 1), 4), maybe some of 3) - more fine-grained (ie. not 50/50) inbound traffic engineering: maybe 1), 2) - the maximum frequency of ISP (=prefix) changes: 1), maybe some of 3) I can summarize this at least to: - even if we modify all the transport layers to be address-agile, it's not enough. - if we need connection survability (some might not), it needs to be coupled with some other solution which provides capabilities for it (ie. multiple addresses), or inherently provides it (PI address, GSE?) So, I must conclude we must be very, very careful in determining our options (and what exactly those options are good for). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Wed May 21 06:34:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14131 for ; Wed, 21 May 2003 06:34:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IQvM-00021x-00 for multi6-data@psg.com; Wed, 21 May 2003 10:34:20 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19IQvJ-00021g-00 for multi6@ops.ietf.org; Wed, 21 May 2003 10:34:17 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4LAYA609990; Wed, 21 May 2003 13:34:10 +0300 Date: Wed, 21 May 2003 13:34:09 +0300 (EEST) From: Pekka Savola To: marcelo bagnulo cc: Iljitsch van Beijnum , Tony Li , Subject: Re: tunneling [Was: Agenda for Vienna] In-Reply-To: <1053512321.766.20.camel@presto.it.uc3m.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On 21 May 2003, marcelo bagnulo wrote: > to my understanding multiple of the above solutions are based on the > loc/id separation > > That is: > - mobility > - HIP > - address agile transports > - loc/id > > Are solutions based on the separation of loc/id roles. I mean all of > them use a fixed identifier for application layer and multiple locators > for routing (in this case in the end -hosts) Agree. > Moreover, i would say that all (host) multi-address solutions are based > on loc/id split concept when they attempt to preserve established > connections Note that in all cases, preserving the connections may not be a requirement... the solution may be OK as is. > - backup path over second ISP using routing or tunnels > This may also be considered a loc/id separation, sine an alternative locator is used to reach a final destination > (so the original dest address plays the role of a locator) You could stretch the term, but I wouldn't do this: this requires zero changes in host stacks. It's just a routing thing, while those mentioned above in loc/id require modifications. > However, i think that there is some fuzziness in this, so perhaps it > would be interesting to have a more precise definition about what we are > talking about when we use the loc/id split expression I've tried but > couldn't find any short definition that i liked... Perhaps after we have > a more precise definition we could ask for opinions and reach consensus > more easily. Agree. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Wed May 21 06:55:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14539 for ; Wed, 21 May 2003 06:55:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IRF9-0002gJ-00 for multi6-data@psg.com; Wed, 21 May 2003 10:54:47 +0000 Received: from smtp03.uc3m.es ([163.117.136.123] helo=smtp.uc3m.es) by psg.com with esmtp (Exim 3.36 #1) id 19IRF4-0002g5-00 for multi6@ops.ietf.org; Wed, 21 May 2003 10:54:43 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id A691A431F9; Wed, 21 May 2003 12:54:41 +0200 (CEST) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp03.uc3m.es (Postfix) with ESMTP id 9823E2B66F; Wed, 21 May 2003 12:54:41 +0200 (CEST) Subject: Re: Options to consider [Re: tunneling [Was: Agenda for Vienna]] From: marcelo bagnulo To: Brian E Carpenter Cc: multi6@ops.ietf.org In-Reply-To: <3ECB4EB2.9141D299@hursley.ibm.com> References: <3ECB4EB2.9141D299@hursley.ibm.com> Content-Type: text/plain Organization: uc3m Message-Id: <1053514387.776.26.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 May 2003 12:53:08 +0200 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Brian, I would say that these three are not _options_ but three approaches that we should follow since the three of them are needed (i do not know if this is what you meant) Immediate solutions for big sites (option 1) and for small sites (option 2). Long term solution Option 3 we have to discuss which one of them (or others) I think we have to do the three of them and i think this is a good roadmap. Thanks for the writing, regards, marcelo On Wed, 2003-05-21 at 12:02, Brian E Carpenter wrote: > Tony is correct, we need to take the big decisions first. So, I think we > have these options to consider: > > 1. For really big enterprises, leave the RIRs to set a policy that > allows such enterprises to get a /32 and negotiate appropriately > with ISPs. No work for the IETF. > > 2. Design a multi-address based solution, where an enterprise would > have multiple PA prefixes and some technology would be added to support > address selection. draft-de-launois-multi6-naros-00.txt > might be the starting point. > > --> this is a conservative approach. It doesn't change anything in > the addressing or routing architecture. We could write a WG > charter for this quite easily. > > 3. Design a two-level solution, in which a locator is used > for routing and an identifier is used end2end (and possibly > for local routing). There are several sub-options: > > 3.1 Map-and-encapsulate, i.e. tunnels driven by a distributed mapping. > In this case, both the locator and the identifier can be standard > addresses, the identifier perhaps being something like > draft-hinden-ipv6-global-local-addr-00.txt. > > 3.2 Splitting the address into two fields, and swapping routing prefixes > en route (a.k.a. GSE) > > 3.3 Swapping & restoring addresses en route. Again, both the identifier > and locator can be standard addresses. > > 3.4 Carrying the identifier, whatever it is, in an extension header. > > All of these carry the need for locator mapping. Actually, the multi-address > method also needs equivalent mapping information, it's just a bit hidden. > So that seems to be our fundamental piece of magic. 800 numbers, anybody? > > It seems to me we can plausibly pursue all three of the above approaches, > with 1) being immediate, 2) being medium term and any of 3) being long term. > > 4. Transport layer solution. My belief is that TCP is too entrenched for > this to be a reasonable approach. > > Brian > > Tony Li wrote: > > > > | > | I don't think we can make informed decisions about the > > | > | architectural > > | > | approach unless we know how well each approach is going to > > | > | work out. That's why I keep going into detail. > > | > > | > This is a common trap. > > | > > | So then there must be a reason why it's hard to avoid it. :-) > > > > Good engineers are detail oriented. Even when they shouldn't be. > > > > | Didn't we kinda sorta agree that loc/id is our collective favorite > > | architecture and that the rest is either flawed, should be > > | worked on > > | elsewhere or no interest in working on it as a group? > > > > I think that you and I agreed that. However, if we are to truly build > > WG consensus on this issue, it's only fair that we allow supporters > > of alternatives to speak their piece. I'm hoping that if there are > > any such folks, they will speak up, so that we are not accused later > > of shouting them down. > > > > > > | Even though we get a bit sidetracked from time to time, I > > | think we're > > | having a very useful discussion on the identifier > > | semantics and mapping > > | mechanisms right now. > > > > I think that the cart belongs behind the horse. Until we get rough > > consensus on the architecture and make a decision, all other energies > > are a distraction from that milestone. > > > > Tony -- marcelo bagnulo uc3m From owner-multi6@ops.ietf.org Wed May 21 06:57:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14588 for ; Wed, 21 May 2003 06:57:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IRHv-0002rR-00 for multi6-data@psg.com; Wed, 21 May 2003 10:57:39 +0000 Received: from smtp03.uc3m.es ([163.117.136.123] helo=smtp.uc3m.es) by psg.com with esmtp (Exim 3.36 #1) id 19IRHr-0002qi-00 for multi6@ops.ietf.org; Wed, 21 May 2003 10:57:35 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 39A34432AF; Wed, 21 May 2003 12:57:34 +0200 (CEST) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp03.uc3m.es (Postfix) with ESMTP id 27B412B673; Wed, 21 May 2003 12:57:34 +0200 (CEST) Subject: Re: Options to consider [Re: tunneling [Was: Agenda for Vienna]] From: marcelo bagnulo To: Pekka Savola Cc: Brian E Carpenter , multi6@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Organization: uc3m Message-Id: <1053514560.766.30.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 May 2003 12:56:00 +0200 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_XIMIAN autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pekka, I agree that different sites will have very different requirements, so i think that within the short term solutions, multiple complementary (not competing) mechanisms are needed, so that a site can choose which mechanism to implement in order to satisfy their particular needs. Regards, marcelo > > I think we need to realize that these four options solve different > problems, and not all of them completely. > > Based on a quick look, it seems to me that: > > - being able to switch ISP's without renumbering: 1), 3.2), maybe others > - redundancy due to link failures etc.: 1), maube 2), maybe 3) > - connection survivability (internal connections, external connections) > 1), 4), maybe some of 3) > - more fine-grained (ie. not 50/50) inbound traffic engineering: maybe > 1), 2) > - the maximum frequency of ISP (=prefix) changes: 1), maybe some of 3) > > > I can summarize this at least to: > - even if we modify all the transport layers to be address-agile, it's > not enough. > - if we need connection survability (some might not), it needs to be > coupled with some other solution which provides capabilities for it (ie. > multiple addresses), or inherently provides it (PI address, GSE?) > > So, I must conclude we must be very, very careful in determining our > options (and what exactly those options are good for). -- marcelo bagnulo uc3m From owner-multi6@ops.ietf.org Wed May 21 08:12:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16187 for ; Wed, 21 May 2003 08:12:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19ISQ5-0006Vl-00 for multi6-data@psg.com; Wed, 21 May 2003 12:10:09 +0000 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #1) id 19ISQ2-0006Uk-00 for multi6@ops.ietf.org; Wed, 21 May 2003 12:10:06 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4LC9k4Z029561; Wed, 21 May 2003 05:09:47 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h4LC9kL05146; Wed, 21 May 2003 14:09:46 +0200 (MEST) Date: Wed, 21 May 2003 14:09:03 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Identifier (structure) [Was: Agenda for Vienna] To: marcelo bagnulo Cc: Erik Nordmark , Iljitsch van Beijnum , multi6@ops.ietf.org In-Reply-To: "Your message with ID" <1053448888.752.42.camel@presto.it.uc3m.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-12.2 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > Do you think that the identifier name space should be the same that the > locator address space or should be a separate one? Too early for me to have any opinion - I think we need to understand both the weak and strong id/loc separation and see what the tradeoffs are. > I mean, we could use the IPv6 address space to contain both locators and > identifiers and that any address could be used both as an identifier or > as locator. That is what I've seen others call a weak split. Similar in nature to mobile IPv6 where in some cases an address is a locator and in other cases an identifier and you can't tell (based on its syntax or based on where it appears in packets) which one it is. > The other option is to split the IPv6 address space and reserve a part > of it to identifiers > > Finally, we could use a completely separate 128 bit address space I think both of these, including an identifier which doesn't fit in 128 bits, is what I'd call strong separation. One of many tradeoffs in this space is that if the identifier is 128 bits in length there might be transition benefits to being able to tell whether a 128 bit chunk is an identifier or a locator. For instance, that would allow applications which do getaddrinfo() followed by connect()/sendto() to receive locators for old peers (those that don't have an IP identifier and don't do whatever new protocol we come up with) and receive identifiers for new peers. Then the stack under connect()/sendto() can look at some leading bits of the 128 to tell whether it needs to do an ID->locator mapping, or just send a packet. But as I said, I think this is only one of the tradeoffs. > A really good approach to this issue is JNC's Endpoint and endpoint > names (can be found http://users.exis.net/~jnc/tech/endpoints.txt) for > those few of you who has not read it yet :-) > I would even say that this should become a wg document There is also the NSRG report to look at. It at least specifies a granularity for the "stack names" which seems like a useful one to me. Erik From owner-multi6@ops.ietf.org Wed May 21 08:28:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16656 for ; Wed, 21 May 2003 08:28:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19ISgp-0007qH-00 for multi6-data@psg.com; Wed, 21 May 2003 12:27:27 +0000 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 19ISgm-0007q0-00 for multi6@ops.ietf.org; Wed, 21 May 2003 12:27:24 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4LCRKYU025900; Wed, 21 May 2003 06:27:20 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h4LCRJL06087; Wed, 21 May 2003 14:27:19 +0200 (MEST) Date: Wed, 21 May 2003 14:26:36 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: tunneling [Was: Agenda for Vienna] To: Iljitsch van Beijnum Cc: Erik Nordmark , multi6@ops.ietf.org In-Reply-To: "Your message with ID" <4176E9E6-8AF5-11D7-B7A7-00039388672E@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-12.2 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > I think the simple DNS approach is a good choice to start with unless > depending on the DNS isn't acceptable. Option 5 could be a reasonable > alternative if we decide we have to go with crypto (which I personally > don't care for). > > But it's hard to know at this stage what the best approach is, and > there probably isn't a single best approach. So what I'd like to see > happen is that we select the simplest option as a default mechanism > that everyone must implement, but keep the option open for the user to > override this default behavior in a way that doesn't make the > implementation too complex. My gut feel is that it is too early to choose a mechanism. But studying the different possible mechanisms (such as using DNS) to determine what impact that has on the architecture is a very good thing. I suspect there are two different ways to do this using DNS: 1. It is possible to lookup both identifier and locators based on a DNS name, but the DNS doesn't have a mapping from identifier to locators. 1a. Perhaps the DNS could have a reverse mapping from locators to DNS names aka ip6.arpa as today. 2. The DNS also has a mapping from identifiers to locators. Presumably this means that the identifiers must be delegated on some hiearchical boundaries. > We can make receiving stateless if we create our own mapping for > sending and depend on return routability. This wouldn't lead to worse > security problems than regular IP. So if we can make mapping from the > identifier to the locator for sending stateless we're in stateless > business. There is a difference between soft-state and hard-state. I've been silently assuming that any tunnel endpoint/receiver state would be soft i.e. have similar behavior as the mobile IPv6 state used when handling the Home Address Option - if there is no state (due to state loss) and error saying "please update my state" goes back to the sender. (The ZOD draft by Glenn Morrow was an example of how to do this with no packet overhead. Perhaps robustness would be better if there is at least a "generation" number in the header to be able to detect stale state.) Such a soft-state approach allows there to be multiple independent tunnel endpoints (useful e.g. when the site border runs this during transition) by dynamically being able to discover the state when packets arrive. But potentially having such soft-state might use up a lot of memory on the border - this is something we need to understand more. Erik From owner-multi6@ops.ietf.org Wed May 21 08:43:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17319 for ; Wed, 21 May 2003 08:43:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19ISvp-00095e-00 for multi6-data@psg.com; Wed, 21 May 2003 12:42:57 +0000 Received: from pa-monroeville1d-140.pit.adelphia.net ([24.50.190.140] helo=localhost) by psg.com with esmtp (Exim 3.36 #1) id 19ISvI-00091n-00 for multi6@ops.ietf.org; Wed, 21 May 2003 12:42:24 +0000 Received: from [192.168.1.100] (localhost [127.0.0.1]) by localhost (8.12.9/8.12.2) with ESMTP id h4LCgP9L006009 for ; Wed, 21 May 2003 08:42:27 -0400 (EDT) Date: Wed, 21 May 2003 08:42:24 -0400 From: "Michael H. Lambert" To: multi6@ops.ietf.org Subject: Re: Options to consider [Re: tunneling [Was: Agenda for Vienna]] Message-ID: <27354206.1053506543@[192.168.1.100]> In-Reply-To: <1053514560.766.30.camel@presto.it.uc3m.es> References: <1053514560.766.30.camel@presto.it.uc3m.es> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-24.8 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Wednesday, 21 May 2003 12:56 +0200 marcelo bagnulo wrote: > Hi Pekka, > > I agree that different sites will have very different requirements, so i > think that within the short term solutions, multiple complementary (not > competing) mechanisms are needed, so that a site can choose which > mechanism to implement in order to satisfy their particular needs. And for each solution there needs to be a good understanding of its performance implications. A viable mechanism over DSL might not be when used over gigabit ethernet. Michael From owner-multi6@ops.ietf.org Wed May 21 08:57:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18372 for ; Wed, 21 May 2003 08:57:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IT9N-000AC1-00 for multi6-data@psg.com; Wed, 21 May 2003 12:56:57 +0000 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #1) id 19IT9K-000ABf-00 for multi6@ops.ietf.org; Wed, 21 May 2003 12:56:54 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4LCuj4Z020449; Wed, 21 May 2003 05:56:46 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h4LCuiL07784; Wed, 21 May 2003 14:56:44 +0200 (MEST) Date: Wed, 21 May 2003 14:56:01 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: tunneling [Was: Agenda for Vienna] To: Tony Li Cc: Iljitsch van Beijnum , Erik Nordmark , multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-13.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > Meta note: if we're trying to talk architecture, I'd say that > dealing with the identifier/locator relationship is secondary. It is secondary to the list of approaches the group wants to explore. But in terms of understanding the implications of approaches that do some split between identifiers and locators the form of the identifier and how and when any mapping from ids to locators is done is extremely important. > Our primary discussion should be about alternatives to > "identifier/locator split" solutions. That's clearly one > architecture, what are others that folks find credible? With my colored glasses I've seen these classes of ideas: - short term registry policy tweak to deal with perceived immediate problem (draft-kurtis-multihoming-longprefix-00.txt) - multiaddressing. Also rather short term; trying to make hosts with multiple addresses work better than they do today for multihoming purposes (draft-huitema-multi6-hosts-01.txt) - geographic addressing schemes (which don't seem to garner much support) - loose identifier/locator split (multiple ideas here) - strict identifier/locator split (multiple ideas here as well e.g. using HIP as one part of a solution) Perhaps there are other classes I've missed. I don't think we understand the issues for the last two classes in enough detail to be able to generalize them to properties of the classes themselves. Erik From owner-multi6@ops.ietf.org Wed May 21 09:10:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19249 for ; Wed, 21 May 2003 09:10:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19ITLi-000B6J-00 for multi6-data@psg.com; Wed, 21 May 2003 13:09:42 +0000 Received: from astrolabe.info.ucl.ac.be ([130.104.229.109] helo=info.ucl.ac.be) by psg.com with esmtp (Exim 3.36 #1) id 19ITLf-000B62-00 for multi6@ops.ietf.org; Wed, 21 May 2003 13:09:40 +0000 Received: from [127.0.0.1] (astrolabe [130.104.229.109]) by info.ucl.ac.be (8.12.9/8.12.8) with ESMTP id h4LD8IgV029079; Wed, 21 May 2003 15:08:18 +0200 (MET DST) Subject: Re: Options to consider [Re: tunneling [Was: Agenda for Vienna]] From: Olivier Bonaventure To: "Michael H. Lambert" Cc: multi6@ops.ietf.org In-Reply-To: <27354206.1053506543@[192.168.1.100]> References: <1053514560.766.30.camel@presto.it.uc3m.es> <27354206.1053506543@[192.168.1.100]> Content-Type: text/plain; charset=ISO-8859-1 Message-Id: <1053522477.6047.122.camel@pcobo> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 May 2003 15:07:58 +0200 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-31.5 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_XIMIAN autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Michael, > > > > I agree that different sites will have very different requirements, so i > > think that within the short term solutions, multiple complementary (not > > competing) mechanisms are needed, so that a site can choose which > > mechanism to implement in order to satisfy their particular needs. > > And for each solution there needs to be a good understanding of its > performance implications. A viable mechanism over DSL might not be when > used over gigabit ethernet. For NAROS, Cédric de Launois has evaluated its performance by simulating the performance of the proposed protocol on a one-day trace of all the IPv4 traffic of our University (about 8000 hosts in the site and 200 GBytes of traffic, i.e. 20 Mbps on average over the whole day). This evaluation shows that the NAROS approach scales well. You can find more details on this evaluation in the following submitted paper : http://www.info.ucl.ac.be/people/delaunoi/paper/naros.pdf Best regards, Olivier Bonaventure -- CSE Dept. UCL, Belgium - http://www.info.ucl.ac.be/people/OBO/ From owner-multi6@ops.ietf.org Wed May 21 10:17:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23001 for ; Wed, 21 May 2003 10:17:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IUNz-000H4j-00 for multi6-data@psg.com; Wed, 21 May 2003 14:16:07 +0000 Received: from d12lmsgate-3.de.ibm.com ([194.196.100.236]) by psg.com with esmtp (Exim 3.36 #1) id 19IUNw-000H4W-00 for multi6@ops.ietf.org; Wed, 21 May 2003 14:16:05 +0000 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.9/8.12.8) with ESMTP id h4LEFpCi110804; Wed, 21 May 2003 16:15:55 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h4LEEsJ4271216; Wed, 21 May 2003 16:14:54 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA48668 from ; Wed, 21 May 2003 16:14:29 +0200 Message-Id: <3ECB89E1.E29BFEDD@hursley.ibm.com> Date: Wed, 21 May 2003 16:14:57 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Olivier Bonaventure Cc: multi6@ops.ietf.org Subject: Re: Options to consider [Re: tunneling [Was: Agenda for Vienna]] References: <1053514560.766.30.camel@presto.it.uc3m.es> <27354206.1053506543@[192.168.1.100]> <1053522477.6047.122.camel@pcobo> Content-Type: text/plain; charset=iso-8859-1 X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA23001 But if every NAROS message needs to be digitally signed to prevent spoofing, that might change. Brian Olivier Bonaventure wrote: > > Michael, > > > > > > I agree that different sites will have very different requirements, so i > > > think that within the short term solutions, multiple complementary (not > > > competing) mechanisms are needed, so that a site can choose which > > > mechanism to implement in order to satisfy their particular needs. > > > > And for each solution there needs to be a good understanding of its > > performance implications. A viable mechanism over DSL might not be when > > used over gigabit ethernet. > > For NAROS, Cédric de Launois has evaluated its performance by simulating > the performance of the proposed protocol on a one-day trace of all the > IPv4 traffic of our University (about 8000 hosts in the site and 200 > GBytes of traffic, i.e. 20 Mbps on average over the whole day). This > evaluation shows that the NAROS approach scales well. You can find more > details on this evaluation in the following submitted paper : > > http://www.info.ucl.ac.be/people/delaunoi/paper/naros.pdf > > Best regards, > > Olivier Bonaventure > > -- > CSE Dept. UCL, Belgium - http://www.info.ucl.ac.be/people/OBO/ From owner-multi6@ops.ietf.org Wed May 21 10:34:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23515 for ; Wed, 21 May 2003 10:34:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IUeY-000J5T-00 for multi6-data@psg.com; Wed, 21 May 2003 14:33:14 +0000 Received: from astrolabe.info.ucl.ac.be ([130.104.229.109] helo=info.ucl.ac.be) by psg.com with esmtp (Exim 3.36 #1) id 19IUeV-000J5D-00 for multi6@ops.ietf.org; Wed, 21 May 2003 14:33:11 +0000 Received: from [127.0.0.1] (astrolabe [130.104.229.109]) by info.ucl.ac.be (8.12.9/8.12.8) with ESMTP id h4LEVogV003221; Wed, 21 May 2003 16:31:50 +0200 (MET DST) Subject: Re: Options to consider [Re: tunneling [Was: Agenda for Vienna]] From: Olivier Bonaventure To: Brian E Carpenter Cc: multi6@ops.ietf.org In-Reply-To: <3ECB89E1.E29BFEDD@hursley.ibm.com> References: <1053514560.766.30.camel@presto.it.uc3m.es> <27354206.1053506543@[192.168.1.100]> <1053522477.6047.122.camel@pcobo> <3ECB89E1.E29BFEDD@hursley.ibm.com> Content-Type: text/plain Message-Id: <1053527588.6051.172.camel@pcobo> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 May 2003 16:33:08 +0200 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-35.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_XIMIAN autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2003-05-21 at 16:14, Brian E Carpenter wrote: > But if every NAROS message needs to be digitally signed to > prevent spoofing, that might change. The study measures the number of NAROS requests sent by clients to the NAROS server. With the site considered, the peak was about 300 messages per minute, but usually 100 requests per minute during the business hours. It should be noted that the study was done on a site without firewall and where we receive lots of port scans that significantly contribute to the load of the NAROS server. Of course, the CPU load would be higher if the requests sent by the client or the responses sent by the server need to be authenticated. However, there are several features of NAROS that may improve the scalability of the solution. First, the NAROS server is only used by the clients inside the site. This means that if the site has a firewall (this was not the case in our study), the firewall could easily block all packets sent towards the NAROS server. Second, the NAROS server does not maintain any state about the clients and it is based on UDP. This means that several hosts could act as a NAROS server by listening to an anycast address. This could easily decrease the per-server load. Best regards, Olivier Bonaventure From owner-multi6@ops.ietf.org Wed May 21 12:47:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27909 for ; Wed, 21 May 2003 12:47:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IWif-00091D-00 for multi6-data@psg.com; Wed, 21 May 2003 16:45:37 +0000 Received: from mail1.microsoft.com ([131.107.3.125]) by psg.com with esmtp (Exim 3.36 #1) id 19IWht-0008sO-00 for multi6@ops.ietf.org; Wed, 21 May 2003 16:44:49 +0000 Received: from mail5.microsoft.com ([157.54.6.156]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6659); Wed, 21 May 2003 09:44:35 -0700 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Wed, 21 May 2003 09:43:12 -0700 Received: from 157.54.6.197 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 21 May 2003 09:43:49 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 21 May 2003 09:43:12 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 21 May 2003 09:43:10 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Wed, 21 May 2003 09:43:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Options to consider [Re: tunneling [Was: Agenda for Vienna]] Date: Wed, 21 May 2003 09:43:06 -0700 Message-ID: Thread-Topic: Options to consider [Re: tunneling [Was: Agenda for Vienna]] Thread-Index: AcMfjGYhlJGlpzoCQw+KK8fSJPR5rAAKe23g From: "Christian Huitema" To: "Brian E Carpenter" , X-OriginalArrivalTime: 21 May 2003 16:43:07.0553 (UTC) FILETIME=[0E940110:01C31FB8] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA27909 > 2. Design a multi-address based solution, where an enterprise would > have multiple PA prefixes and some technology would be added to support > address selection. draft-de-launois-multi6-naros-00.txt > might be the starting point. > > --> this is a conservative approach. It doesn't change anything in > the addressing or routing architecture. We could write a WG > charter for this quite easily. I personally like conservative approaches. Brian, you asked in another message whether multi-addressing is desirable. I don't think that the working group should try to answer that "desirability" question. If we want to make progress, we should rather charter two groups, and then let the market choose. I would much rather see one group working on the multi-addressing solution and another working on the split locator-identifier solution, than trying to coerce everybody in a single group. As for multi-addressing itself, naros addresses one of the issues, i.e. the choice of addresses by multi-addressing aware hosts. It is definitely a possible component of the solution, but we should make sure that we have a comprehensive charter. For example, in our own multi-addressing paper, we tried to look at another issue, the behavior of hosts that are not multi-addressing aware in a multi-addressed network. Our requirement was that simple hosts should be able to configure only a fraction of the possible addresses, and still be able to function. So I guess one of the short term exercises should be to draft a comprehensive charter for a multi-addressing working group. If we could adopt that in Vienna, we would have achieved something. -- Christian Huitema From owner-multi6@ops.ietf.org Wed May 21 14:42:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01109 for ; Wed, 21 May 2003 14:42:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IYWk-0001X3-00 for multi6-data@psg.com; Wed, 21 May 2003 18:41:26 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19IYWB-0001QQ-00 for multi6@ops.ietf.org; Wed, 21 May 2003 18:40:51 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4LIedf17785; Wed, 21 May 2003 21:40:39 +0300 Date: Wed, 21 May 2003 21:40:39 +0300 (EEST) From: Pekka Savola To: Erik Nordmark cc: Tony Li , Iljitsch van Beijnum , Subject: RE: tunneling [Was: Agenda for Vienna] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 21 May 2003, Erik Nordmark wrote: > > Our primary discussion should be about alternatives to > > "identifier/locator split" solutions. That's clearly one > > architecture, what are others that folks find credible? > > With my colored glasses I've seen these classes of ideas: > - short term registry policy tweak to deal with perceived immediate > problem (draft-kurtis-multihoming-longprefix-00.txt) I think the above mechanism proposes punching holes to current aggregates, not tweaking registry policy. In that sense, it's dangerous. A separate proposal to assign e.g. PI /48's from RIR's might be useful to have on the table. I think draft-savola-multi6-asn-pi-00.txt also belongs under this category. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Wed May 21 18:03:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10327 for ; Wed, 21 May 2003 18:03:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IbdL-000JVD-00 for multi6-data@psg.com; Wed, 21 May 2003 22:00:27 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19Ibcp-000JKX-00 for multi6@ops.ietf.org; Wed, 21 May 2003 21:59:55 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h4LLwMn56885; Wed, 21 May 2003 23:58:22 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 21 May 2003 23:58:29 +0200 Subject: Re: Identifier (structure) [Was: Agenda for Vienna] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Erik Nordmark , multi6@ops.ietf.org To: marcelo bagnulo From: Iljitsch van Beijnum In-Reply-To: <1053448888.752.42.camel@presto.it.uc3m.es> Message-Id: <5B3AE6FC-8BD7-11D7-8495-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On dinsdag, mei 20, 2003, at 18:41 Europe/Amsterdam, marcelo bagnulo wrote: >> Yes, that is one approach. >> It might make it more difficult for transition schemes where an >> unmodified >> IPv6 host plus some "proxy" e.g. at the site border together >> implement things. >> In such a case I think the IPv6 host (for transition purposes) would >> send packets where IP source and destination are identifiers >> thus the "proxy" would not see such higher level "real" identifiers. When a proxy is used the identifiers must take the shape of valid IPv6 unicast addresses (or possibly IPv4 addresses). Host implementations could use any identifier they like, except that this means changing the TCP and UDP checksum calculations. So IPv6 addresses will probably be the most important identifier category for some time to come, but if we do this right we finally get to disconnect the network and transport layers so we can change the network layer protocol without too much trouble the next time around. >> Another issue to consider in this space is the goal to allow >> applications already ported to IPv6 to continue to work when >> the application uses getaddrinfo() followed by connect()/sendto(). >> This is at least easier to accomplish if the identifier fits in 128 >> bits. > Do you think that the identifier name space should be the same that the > locator address space or should be a separate one? > I mean, we could use the IPv6 address space to contain both locators > and > identifiers and that any address could be used both as an identifier or > as locator. > The other option is to split the IPv6 address space and reserve a part > of it to identifiers There are advantages to both having a separate identifier space and to being able to make each IPv6 address an identifier. Hard to say which way we should go here. > Finally, we could use a completely separate 128 bit address space Well, I argued in favor of having different kinds of identifiers so non-IPv6 128 bit identifiers would be one type. However, adopting these has the downside that you must always implicitly or explicitly know whether you're talking about an identifier or a locator, and since current implementations don't know about this that's going to be hard. Having the option of looking at an address or looking up an address and then see if it's a locator, an identifier or possibly both makes things easier. In another message you write: > to my understanding multiple of the above solutions are based on the > loc/id separation > That is: > - mobility > - HIP > - address agile transports > - loc/id > Are solutions based on the separation of loc/id roles. I mean all of > them use a fixed identifier for application layer and multiple locators > for routing (in this case in the end -hosts) Careful here: not everything that uses more than one address separates the locator and identifier functions. Address agile transports simply use multiple addresses that overload the loc+id functions the same way single addresses do in TCP and UDP. MIP uses the loc+id for the home address and just the loc for the care of address. But I'd prefer to not categorize MIP as a loc/id variant because it doesn't really address this issue (as far as I know, that draft is REALLY long). By the way, does anyone know if MIPv6 and routing optimization are supported widely yet? I seem to remember this was "mandatory" but as far as I can tell the stuff I work with doesn't support this or at least doesn't say it supports it. HIP may in fact incorporate a locator/identifier separation but it does so much more and is by its nature not suitable as a general multihoming solution so I don't want to count it as loc/id either. > A really good approach to this issue is JNC's Endpoint and endpoint > names (can be found http://users.exis.net/~jnc/tech/endpoints.txt) for > those few of you who has not read it yet :-) Yes, this is good stuff. The NSRG report was interesting too but a few too many open doors. Great the way they start the security considerations section on page 2, though. :-) One comment on the endpoint thing: this brings up the interesting question whether we care about the nature of the item being identified by an identifier. Does it matter whether an identifier points to a host, a process, a service or an interface? Those have different properties, but each may act as an endpoint at some point in time. From owner-multi6@ops.ietf.org Wed May 21 18:25:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11852 for ; Wed, 21 May 2003 18:25:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Ic08-000PVU-00 for multi6-data@psg.com; Wed, 21 May 2003 22:24:00 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19Ibzc-000PMt-00 for multi6@ops.ietf.org; Wed, 21 May 2003 22:23:28 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h4LMM4n56926; Thu, 22 May 2003 00:22:04 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 22 May 2003 00:22:11 +0200 Subject: Re: tunneling [Was: Agenda for Vienna] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Tim Chown From: Iljitsch van Beijnum In-Reply-To: <20030521082303.GF3653@login.ecs.soton.ac.uk> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On woensdag, mei 21, 2003, at 10:23 Europe/Amsterdam, Tim Chown wrote: >> Didn't we kinda sorta agree that loc/id is our collective favorite >> architecture and that the rest is either flawed, should be worked on >> elsewhere or no interest in working on it as a group? > So if you were drawing out a multihoming roadmap, where would loc/id > be on that roadmap? I don't really want to use the words "long term" as that might make people think there is no point in working on it / waiting for it. But it should solve the problem rather definitively, so in that sense it is long term. I'm not entirely sure how long it takes from draft to implementation but I think a couple of years should be doable with some tail wind so in that sense intermediate term. After that another few years before general adoption. I don't think any solution that needs changes on both ends can do much better. > The question then is whether we need to create any swamp in the interim > for large enterprises for which Christian's approach is out of scope > and > where loc/id (in the host or at the edge) is too far off. I hear some people mention giving /32s to large enterprises. I'm not going to bore you with rants about why this is morally reprehensible but rather observe that if we give the big boys a portable prefix they won't have any reason to support loc/id, and the single homed crowd doesn't either because they don't need it to talk to the big multihomed sites, so that leaves the small multihomers without anyone to talk to multihomedly. We have to all be in the same boat to get this off the ground. > Might we for example agree what the multi6 group can do now to assist > multihoming for new IPv6 deployments, and then "split off" long term > approaches (either within the group or out to IRTF if long-term really > is just that)? Should multi6 focus on what can be done now, or what > can be done in 3+ years? Well, if you really want to start multihoming quickly you should do geo. :-) Changing protocols takes time. The correlation between the amount of change and the amount of time is well below 1. Since there isn't any IPv6 deployment to speak of and there are much bigger fish yet to be fried before that will happen (where is my IPv6 root and TLD delegations?) I think we can afford to take the time to get it right. Or rather, we can't afford not to. If we can steer clear of stuff like what the next generation namespace should look like I see no reason to involve the IRTF. From owner-multi6@ops.ietf.org Wed May 21 19:20:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12798 for ; Wed, 21 May 2003 19:20:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Icqx-000E3k-00 for multi6-data@psg.com; Wed, 21 May 2003 23:18:35 +0000 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 19IcqR-000DvD-00; Wed, 21 May 2003 23:18:03 +0000 From: Masataka Ohta Message-Id: <200305212305.IAA11370@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id IAA11370; Thu, 22 May 2003 08:05:22 +0900 Subject: Re: Agenda for Vienna In-Reply-To: <06363214-8A8C-11D7-BA5E-000393A638B2@kurtis.pp.se> from Kurt Erik Lindqvist at "May 20, 2003 08:26:43 am" To: Kurt Erik Lindqvist Date: Thu, 22 May 2003 08:05:21 +0859 () CC: Randy Bush , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-11.3 required=5.0 tests=BAYES_10,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurt; > >>> So, why not have three 2H sessions and stop saying "time constraint"? > >> > >> because you will need a different AD to approve it. > > > > According to Kurt, no. > > Say again? I think I have made it pretty clear that we will not apply > for three 2h sessions. You are a (co-)chair, not an AD. That is why you, not the AD, are the problem. In addition, it is another problem that you have little understanding on IETF procedure. Randy, have you recognized that, unless the problems are solved, there is no point to trying to have a different AD to approve it. Masataka Ohta From owner-multi6@ops.ietf.org Wed May 21 23:31:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17174 for ; Wed, 21 May 2003 23:31:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Iglf-000Jvw-00 for multi6-data@psg.com; Thu, 22 May 2003 03:29:23 +0000 Received: from ran.psg.com ([209.20.253.166]) by psg.com with esmtp (Exim 3.36 #1) id 19Igl9-000JpO-00 for multi6@ops.ietf.org; Thu, 22 May 2003 03:28:51 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.14) id 19Igl8-000DQR-4e; Wed, 21 May 2003 20:28:50 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 21 May 2003 20:28:49 -0700 To: Masataka Ohta Cc: Kurt Erik Lindqvist , multi6@ops.ietf.org Subject: Re: Agenda for Vienna References: <06363214-8A8C-11D7-BA5E-000393A638B2@kurtis.pp.se> <200305212305.IAA11370@necom830.hpcl.titech.ac.jp> Message-Id: X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> Say again? I think I have made it pretty clear that we will not apply >> for three 2h sessions. > You are a (co-)chair, not an AD. > That is why you, not the AD, are the problem. > In addition, it is another problem that you have little understanding > on IETF procedure. > Randy, have you recognized that, unless the problems are solved, there > is no point to trying to have a different AD to approve it. what i recognize is a lot of rude fighting and little technical content. and it is technical content which gets meeting slots. randy From owner-multi6@ops.ietf.org Thu May 22 00:53:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18616 for ; Thu, 22 May 2003 00:53:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Ii3f-0005wA-00 for multi6-data@psg.com; Thu, 22 May 2003 04:52:03 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19Ii3R-0005t6-00 for multi6@ops.ietf.org; Thu, 22 May 2003 04:51:49 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4M4pEP22039; Thu, 22 May 2003 07:51:14 +0300 Date: Thu, 22 May 2003 07:51:14 +0300 (EEST) From: Pekka Savola To: Iljitsch van Beijnum cc: Tim Chown , Subject: Re: tunneling [Was: Agenda for Vienna] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 22 May 2003, Iljitsch van Beijnum wrote: > On woensdag, mei 21, 2003, at 10:23 Europe/Amsterdam, Tim Chown wrote: > >> Didn't we kinda sorta agree that loc/id is our collective favorite > >> architecture and that the rest is either flawed, should be worked on > >> elsewhere or no interest in working on it as a group? > > > So if you were drawing out a multihoming roadmap, where would loc/id > > be on that roadmap? > > I don't really want to use the words "long term" as that might make > people think there is no point in working on it / waiting for it. But > it should solve the problem rather definitively, so in that sense it is > long term. [...] I disagree: I don't think loc/id, a solution like HIP for instance, would solve the whole problem. Care to elaborate? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Thu May 22 03:44:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03799 for ; Thu, 22 May 2003 03:44:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IkiF-00092g-00 for multi6-data@psg.com; Thu, 22 May 2003 07:42:07 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19Ikhi-0008yl-00 for multi6@ops.ietf.org; Thu, 22 May 2003 07:41:34 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h4M7e1n57936; Thu, 22 May 2003 09:40:02 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 22 May 2003 09:40:11 +0200 Subject: Re:loc/id vs HIP (was: tunneling [Was: Agenda for Vienna]) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Pekka Savola From: Iljitsch van Beijnum In-Reply-To: Message-Id: <9E2B9BB8-8C28-11D7-B700-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On donderdag, mei 22, 2003, at 06:51 Europe/Amsterdam, Pekka Savola wrote: >> I don't really want to use the words "long term" as that might make >> people think there is no point in working on it / waiting for it. But >> it should solve the problem rather definitively, so in that sense it >> is >> long term. [...] > I disagree: I don't think loc/id, a solution like HIP for instance, > would > solve the whole problem. Care to elaborate? Elaborate why you disagree? That's going to be hard... Multihoming works by having two or more valid paths through the network between two hosts. (Valid = no administrative blocks, just having some wire isn't enough, you must also be able to route over it.) Then if one path disappears, the communication continues over the other. If we can't have routing take care of this switch, the most obvious way is to have different addresses that are each tied to a path. But then we're changing addresses in mid-session, which our transport protocols can't handle. Enter the loc/id separation: the transport protocols and applications get a stable identifier to work with, but we get to change the underlying locator when there are outages. Assuming we take care of details such as how outages are detected and how the locator<->identifier mapping is set up, this should solve the multihoming problem once and for all. Locator/identifier separation is also very useful if we want to implement a new namespace. Loc/id in itself doesn't require a new namespace. Either locators and identifiers can overlap (i.e., any IPv6 address can be either or even both) or we split the IPv6 address space in two, with parts for both purposes. This is mostly a deployment tradeoff. About HIP. I've been reading the new architecture document. It seems it pretty much does the whole loc/id thing, although it doesn't really mention failover. The problem however is that HIP does much more than just multihoming. Maybe there is some synergy between multihoming and mobility, but I don't see the advantages of leaping multihoming, mobility and encryption on one big pile. In the end, that's going to mean you're going to do at least one of those not very well. And then there is simple economics: how are you going to convince someone who multihomes in IPv6 to switch to IPv6 and then adopt HIP to retain multihoming functionality? This means lots of additional expenses because of the crypto hardware (if you can't do line rate crypto you're a sitting duck for crypto DoS) and the additional bandwidth for all the extra headers. Don't think it's so bad? I think it is. The HIP header is at least 40 bytes. Then you need ESP, which is at least 8 bytes (probably more like 16), an initialization vector and padding. But of course just encrypting isn't enough, you really should be doing authentication as well... Ignoring that for a moment the total is 64 - 95 bytes when using a block cipher with 16 byte blocks. This makes a TCP ACK 136 bytes. In plain IPv4 it's only 40 bytes... The average pacet size is typically around 500 bytes. With HIP and IPv6 adding some 92 bytes, this eats away 16% of the available bandwidth. On a related note, I've been thinking about ways to do something about all this outrageous overhead but being able to have some per-packet additional info at the same time. It occurs to me that much of the stuff we're thinking about putting in each packet really doesn't have to be in _each_ packet. Having identifiers and such in every 32th packet or once every 5 seconds or so should be more than enough. From owner-multi6@ops.ietf.org Thu May 22 03:52:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03901 for ; Thu, 22 May 2003 03:52:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Ikrk-000B8X-00 for multi6-data@psg.com; Thu, 22 May 2003 07:51:56 +0000 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74]) by psg.com with esmtp (Exim 3.36 #1) id 19IkrA-000B3N-00 for multi6@ops.ietf.org; Thu, 22 May 2003 07:51:20 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.9/8.10.2) with ESMTP id h4M7pHRp003493; Thu, 22 May 2003 09:51:18 +0200 (CEST) Date: Thu, 22 May 2003 09:51:16 +0200 Subject: Re: Thoughts for the second session in Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <68698DF3-8AD3-11D7-8982-00039388672E@muada.com> Message-Id: <2ACD5438-8C2A-11D7-B63E-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-27.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_RFCI,REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On tisdag, maj 20, 2003, at 16:57 Europe/Stockholm, Iljitsch van Beijnum wrote: > >> If we manage to get some form of consensus on the above, we need to >> decide on what do use it for, but I think that is best to spare some >> 15 minutes at the end of the second session to discuss. > > Maybe it would be a good idea to get together in a smaller group and > see if we can hammer out something workable. A little whiteboard can > go a long way. We could do this between the first and second session > and then see if there is consensus on the result in the second > session. > > This is why we are having two sessions and have asked the secretariat to have them in the beginning and the end of the week :-) - kurtis - From owner-multi6@ops.ietf.org Thu May 22 04:30:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04521 for ; Thu, 22 May 2003 04:30:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IlSB-000IvE-00 for multi6-data@psg.com; Thu, 22 May 2003 08:29:35 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19IlS5-000Ise-00 for multi6@ops.ietf.org; Thu, 22 May 2003 08:29:30 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4M8TMJ23513; Thu, 22 May 2003 11:29:22 +0300 Date: Thu, 22 May 2003 11:29:22 +0300 (EEST) From: Pekka Savola To: Iljitsch van Beijnum cc: multi6@ops.ietf.org Subject: Re:loc/id vs HIP (was: tunneling [Was: Agenda for Vienna]) In-Reply-To: <9E2B9BB8-8C28-11D7-B700-00039388672E@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 22 May 2003, Iljitsch van Beijnum wrote: > On donderdag, mei 22, 2003, at 06:51 Europe/Amsterdam, Pekka Savola > wrote: > > >> I don't really want to use the words "long term" as that might make > >> people think there is no point in working on it / waiting for it. But > >> it should solve the problem rather definitively, so in that sense it > >> is > >> long term. [...] > > > I disagree: I don't think loc/id, a solution like HIP for instance, > > would > > solve the whole problem. Care to elaborate? > > Elaborate why you disagree? That's going to be hard... Hmmm.. See below.. > Multihoming works by having two or more valid paths through the network > between two hosts. (Valid = no administrative blocks, just having some > wire isn't enough, you must also be able to route over it.) Then if one > path disappears, the communication continues over the other. If we > can't have routing take care of this switch, So far so good. > the most obvious way is to > have different addresses that are each tied to a path. Again: this doesn't solve the whole problem. Consider e.g. Craig's traffic engineering requirements, or (to a lesser degree) requirements that the nodes should not have to renumbered ("deploying/retiring locators") when the ISP's are changing. > But then we're > changing addresses in mid-session, which our transport protocols can't > handle. Sure, but that's only one part of the problem: ensuring that connections do not break. In some cases it may be completely acceptable to have connections break (e.g. outbound connections to the Internet) -- due to the nature of traffic, the failure events happening so infrequently, etc. Of course, connection survivability is very desirable. Especially if switchovers are frequent, or happen during important "business" hours. For example, in home/SOHO use, it might be completely acceptable. It's just tradeoffs. > Enter the loc/id separation: the transport protocols and > applications get a stable identifier to work with, but we get to change > the underlying locator when there are outages. Assuming we take care of > details such as how outages are detected and how the > locator<->identifier mapping is set up, Sure. > this should solve the > multihoming problem once and for all. No, it would "only" take care of "connection survivability" once and for all. [snip] > About HIP. I've been reading the new architecture document. It seems it > pretty much does the whole loc/id thing, although it doesn't really > mention failover. The problem however is that HIP does much more than > just multihoming. Maybe there is some synergy between multihoming and > mobility, but I don't see the advantages of leaping multihoming, > mobility and encryption on one big pile. In the end, that's going to > mean you're going to do at least one of those not very well. Yes, it may be a problem -- I could easily imagine there being resistance to full cryptography, but there are workarounds for that. > And then there is simple economics: how are you going to convince > someone who multihomes in IPv6 to switch to IPv6 and then adopt HIP to > retain multihoming functionality? This means lots of additional > expenses because of the crypto hardware (if you can't do line rate > crypto you're a sitting duck for crypto DoS) and the additional > bandwidth for all the extra headers. Don't think it's so bad? I think > it is. The HIP header is at least 40 bytes. Then you need ESP, which is > at least 8 bytes (probably more like 16), an initialization vector and > padding. But of course just encrypting isn't enough, you really should > be doing authentication as well... Ignoring that for a moment the total > is 64 - 95 bytes when using a block cipher with 16 byte blocks. This > makes a TCP ACK 136 bytes. In plain IPv4 it's only 40 bytes... The > average pacet size is typically around 500 bytes. With HIP and IPv6 > adding some 92 bytes, this eats away 16% of the available bandwidth. Perhaps someone better versed in HIP or IPsec could correct the above, but on a quick glance there seem to have been a few things (at least) to note: 1) HIP header (~40B) is used only in the four-way handshake 2) when you start using ESP, it already includes everything needed (material needed was established using HIP), so you don't send HIP headers then. 3) ESP already includes authentication 4) it may be possible to include data in the parts of the HIP exchange by piggybacking (TBD) 5) only authenticated users could create an encryption DoS attack, because in the HIP handshake, the initiator has to solve a puzzle before the responder ("server") commits any resources to anything. But that's bad thing too, because it could happen unintentionally too. > On a related note, I've been thinking about ways to do something about > all this outrageous overhead but being able to have some per-packet > additional info at the same time. It occurs to me that much of the > stuff we're thinking about putting in each packet really doesn't have > to be in _each_ packet. Having identifiers and such in every 32th > packet or once every 5 seconds or so should be more than enough. Welcome to the world of connectionless protocols. :-) But seriously, you really can't drop out stuff like IP addresses without major changes. Not without any assumptions that is. If we could assume all traffic is encrypted (or something), we might be able to drop off some data and replace them with some sort of labels (so that the spoofing and data injection, etc. problems would not be an issue), but I'm a realist and don't expect much... -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Thu May 22 04:35:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04576 for ; Thu, 22 May 2003 04:35:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IlXK-000KBk-00 for multi6-data@psg.com; Thu, 22 May 2003 08:34:54 +0000 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74]) by psg.com with esmtp (Exim 3.36 #1) id 19IlWo-000K7U-00 for multi6@ops.ietf.org; Thu, 22 May 2003 08:34:23 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.9/8.10.2) with ESMTP id h4M8YMRp003506; Thu, 22 May 2003 10:34:22 +0200 (CEST) Date: Thu, 22 May 2003 10:34:21 +0200 Subject: Re: tunneling [Was: Agenda for Vienna] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Tony Li" , multi6@ops.ietf.org To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <0EA27AB2-8B0E-11D7-B7A7-00039388672E@muada.com> Message-Id: <2F73EC72-8C30-11D7-B63E-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-27.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_RFCI,REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On tisdag, maj 20, 2003, at 23:57 Europe/Stockholm, Iljitsch van Beijnum wrote: > Kurt, is that what you want in your first proposed Vienna meeting or > do you only want "active" solutions discussed there? I was thinking only about active proposals (read that have submitted drafts to the IETF and that haven't expired too long ago). Also, I was mostly looking at the actual proposals to be presented. - kurtis - From owner-multi6@ops.ietf.org Thu May 22 04:41:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04702 for ; Thu, 22 May 2003 04:41:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Ilce-000LEi-00 for multi6-data@psg.com; Thu, 22 May 2003 08:40:24 +0000 Received: from d12lmsgate.de.ibm.com ([194.196.100.234]) by psg.com with esmtp (Exim 3.36 #1) id 19Ilc8-000KyW-00 for multi6@ops.ietf.org; Thu, 22 May 2003 08:39:53 +0000 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h4M8dfu9097372 for ; Thu, 22 May 2003 10:39:45 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h4M8dXSB228172 for ; Thu, 22 May 2003 10:39:35 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA27570 from ; Thu, 22 May 2003 10:39:31 +0200 Message-Id: <3ECC8CDF.5F4F50C8@hursley.ibm.com> Date: Thu, 22 May 2003 10:39:59 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: multi6@ops.ietf.org Subject: Re: Identifier (structure) [Was: Agenda for Vienna] References: <5B3AE6FC-8BD7-11D7-8495-00039388672E@muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: ... > > One comment on the endpoint thing: this brings up the interesting > question whether we care about the nature of the item being identified > by an identifier. Does it matter whether an identifier points to a > host, a process, a service or an interface? Those have different > properties, but each may act as an endpoint at some point in time. This is why the NSRG decided to focus on the "stack" as the entity to be identified (and located). For an IP address, the stack is the right level, for reasons that the NSRG draft explains. My opinion is that IPv6 addresses are fine both as stack identifiers and stack locators, and that identifiers and locators should *not* be syntactically distinguished - we will simply know from context whether we are using an address as an identifier, a locator, or both. Anything else takes us off into computer science discussions, and I don't think that is a good use of our time. (In fact, that is why the NSRG took so long to come up with a draft, which isn't even a consensus.) Brian From owner-multi6@ops.ietf.org Thu May 22 04:41:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04719 for ; Thu, 22 May 2003 04:41:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IldW-000LWP-00 for multi6-data@psg.com; Thu, 22 May 2003 08:41:18 +0000 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74]) by psg.com with esmtp (Exim 3.36 #1) id 19Ilcz-000LFn-00 for multi6@ops.ietf.org; Thu, 22 May 2003 08:40:45 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.9/8.10.2) with ESMTP id h4M8ejRp003515; Thu, 22 May 2003 10:40:45 +0200 (CEST) Date: Thu, 22 May 2003 10:40:44 +0200 Subject: Re: tunneling [Was: Agenda for Vienna] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Iljitsch van Beijnum" , To: "Tony Li" From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <13E2A395-8C31-11D7-B63E-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-14.9 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > | Even though we get a bit sidetracked from time to time, I > | think we're > | having a very useful discussion on the identifier > | semantics and mapping > | mechanisms right now. > > > I think that the cart belongs behind the horse. Until we get rough > consensus on the architecture and make a decision, all other energies > are a distraction from that milestone. From the mailinglist and previous discussions, I would say we have, or are very close to having WG consensus on loc/id mapping. Is this something that we should bring to the table for the second session in Vienna and vote on? Or should we have this sorted before then? - kurtis - From owner-multi6@ops.ietf.org Thu May 22 04:45:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04769 for ; Thu, 22 May 2003 04:45:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IlgX-000MRi-00 for multi6-data@psg.com; Thu, 22 May 2003 08:44:25 +0000 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74]) by psg.com with esmtp (Exim 3.36 #1) id 19Ilg1-000MFL-00 for multi6@ops.ietf.org; Thu, 22 May 2003 08:43:53 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.9/8.10.2) with ESMTP id h4M8hqRp003518; Thu, 22 May 2003 10:43:52 +0200 (CEST) Date: Thu, 22 May 2003 10:43:50 +0200 Subject: Re: tunneling [Was: Agenda for Vienna] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Tim Chown From: Kurt Erik Lindqvist In-Reply-To: <20030521082303.GF3653@login.ecs.soton.ac.uk> Message-Id: <82F22668-8C31-11D7-B63E-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-14.9 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > So if you were drawing out a multihoming roadmap, where would loc/id > be on that roadmap? > > I ask because we should consider what we can do short-term and > long-term. > Is the loc/id approach long-term? Christian's multi-address > "challenge" > is much more short-term, and I think is something we should push > forward > on now. I used to be a strong proponent of the road-map and gradual migration approach. That is also why I wrote the road-map draft. However, I am no longer sure that is a good approach. As was pointed out here, that risks distracting us. Also, the goal of multi6 is to come up with the solution. Not the protocol details, and probably not the migration scenarios. If we start looking at this now there is a risk that we will dug into all kind of side issues. This might be a role for multi6 in the future, but I would say not now. - kurtis - From owner-multi6@ops.ietf.org Thu May 22 04:46:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04809 for ; Thu, 22 May 2003 04:46:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Ili8-000MeU-00 for multi6-data@psg.com; Thu, 22 May 2003 08:46:04 +0000 Received: from smtp01.uc3m.es ([163.117.136.121] helo=smtp.uc3m.es) by psg.com with esmtp (Exim 3.36 #1) id 19Ilhb-000MYg-00 for multi6@ops.ietf.org; Thu, 22 May 2003 08:45:31 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id C64EA43402; Thu, 22 May 2003 10:45:30 +0200 (CEST) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp01.uc3m.es (Postfix) with ESMTP id B59CC99E68; Thu, 22 May 2003 10:45:30 +0200 (CEST) Subject: Re: Identifier (structure) [Was: Agenda for Vienna] From: marcelo bagnulo To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org In-Reply-To: <5B3AE6FC-8BD7-11D7-8495-00039388672E@muada.com> References: <5B3AE6FC-8BD7-11D7-8495-00039388672E@muada.com> Content-Type: text/plain Organization: uc3m Message-Id: <1053593031.762.31.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 May 2003 10:43:52 +0200 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-32.9 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Iljitsch, > In another message you write: > > > to my understanding multiple of the above solutions are based on the > > loc/id separation > > > That is: > > - mobility > > - HIP > > - address agile transports > > - loc/id > > > Are solutions based on the separation of loc/id roles. I mean all of > > them use a fixed identifier for application layer and multiple locators > > for routing (in this case in the end -hosts) > > Careful here: not everything that uses more than one address separates > the locator and identifier functions. Agree, but i would say that any multi-address solution that preserves established communications does implements some sort of loc/id split. more below... > Address agile transports simply > use multiple addresses that overload the loc+id functions the same way > single addresses do in TCP and UDP. I am not so sure about this. I guess that any proposal of address agile transport layer must present only ONE single address to the application layer, which plays the role of identifier, while all the others address plus this one are the locators. The difference here is that the distinction is made in the transport layer and not in the IP layer, but from the application POV there is still only one identifier and from the routing POV there are multiple locators. There is still the option of letting the application to manage multiple addresses. In this case, you can say that the identifier is the set of locators, but i digress... > MIP uses the loc+id for the home > address and just the loc for the care of address. But I'd prefer to not > categorize MIP as a loc/id variant because it doesn't really address > this issue (as far as I know, that draft is REALLY long). > I do not understand what you mean here... HoA is an identifier and one of the possible locators and CoAs are alternative locators, do you have an alternative interpretation? > By the way, does anyone know if MIPv6 and routing optimization are > supported widely yet? I seem to remember this was "mandatory" I think route optimization support on CN is a SHOULD. > but as > far as I can tell the stuff I work with doesn't support this or at > least doesn't say it supports it. > > HIP may in fact incorporate a locator/identifier separation but it does > so much more and is by its nature not suitable as a general multihoming > solution so I don't want to count it as loc/id either. > I have to disagree here... HIP splits Loc and id and it can be used to solve the mh problem, so i see no reason to not consider it as such I think that many folks agree that the problem is that the a loc and an id are univocaly mapped since there is a single name (IP address) that performs both functions. So, the solution would be to extend the mapping to support the relation between one identifier and multiple locators. Perhaps there is some agreement in this. How to actually implement it? Well, all the above proposals do this in very different ways, so we still have to discuss this. But As Tony already proposed, we should first reach consensus on the Loc/id split approach is the way to go. Well, at least the long term approach. > > A really good approach to this issue is JNC's Endpoint and endpoint > > names (can be found http://users.exis.net/~jnc/tech/endpoints.txt) for > > those few of you who has not read it yet :-) > > Yes, this is good stuff. The NSRG report was interesting too but a few > too many open doors. Great the way they start the security > considerations section on page 2, though. :-) > > One comment on the endpoint thing: this brings up the interesting > question whether we care about the nature of the item being identified > by an identifier. Does it matter whether an identifier points to a > host, a process, a service or an interface? Those have different > properties, but each may act as an endpoint at some point in time. I think that the first decision is to decide where to implement the loc/id split. IMHO it should be done between the IP layer and the transport layer (or by the upper part of the IP layer, if you wish) Then, i guess that multiple identifier can be supported so that you can associate with any element residing above the IP layer that you consider useful. Regards, marcelo -- marcelo bagnulo uc3m From owner-multi6@ops.ietf.org Thu May 22 04:51:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04941 for ; Thu, 22 May 2003 04:51:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Ilmj-000NZo-00 for multi6-data@psg.com; Thu, 22 May 2003 08:50:49 +0000 Received: from d12lmsgate-4.de.ibm.com ([194.196.100.237]) by psg.com with esmtp (Exim 3.36 #1) id 19IlmD-000NV5-00 for multi6@ops.ietf.org; Thu, 22 May 2003 08:50:17 +0000 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-4.de.ibm.com (8.12.9/8.12.8) with ESMTP id h4M8o3DI099836 for ; Thu, 22 May 2003 10:50:06 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h4M8iArQ218966 for ; Thu, 22 May 2003 10:44:11 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA21712 from ; Thu, 22 May 2003 10:44:09 +0200 Message-Id: <3ECC8DF6.6962DC6C@hursley.ibm.com> Date: Thu, 22 May 2003 10:44:38 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: multi6@ops.ietf.org Subject: Re: loc/id vs HIP (was: tunneling [Was: Agenda for Vienna]) References: <9E2B9BB8-8C28-11D7-B700-00039388672E@muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: ... > On a related note, I've been thinking about ways to do something about > all this outrageous overhead but being able to have some per-packet > additional info at the same time. It occurs to me that much of the > stuff we're thinking about putting in each packet really doesn't have > to be in _each_ packet. Having identifiers and such in every 32th > packet or once every 5 seconds or so should be more than enough. We can just use fairly standard approaches to smart compression. If the same bit pattern appears in the same place in every packet of a flow, it is well known how to save the bits. Probably, most of the hosts we would care about will be using ROHC anyway. Brian From owner-multi6@ops.ietf.org Thu May 22 05:00:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05078 for ; Thu, 22 May 2003 05:00:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Iluz-000Pfm-00 for multi6-data@psg.com; Thu, 22 May 2003 08:59:21 +0000 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #1) id 19IluT-000Pca-00 for multi6@ops.ietf.org; Thu, 22 May 2003 08:58:49 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA19314 for ; Thu, 22 May 2003 09:58:47 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id JAA25555 for ; Thu, 22 May 2003 09:58:47 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h4M8wlk22055 for multi6@ops.ietf.org; Thu, 22 May 2003 09:58:47 +0100 Date: Thu, 22 May 2003 09:58:47 +0100 From: Tim Chown To: multi6@ops.ietf.org Subject: Re: tunneling [Was: Agenda for Vienna] Message-ID: <20030522085847.GG20739@login.ecs.soton.ac.uk> Mail-Followup-To: multi6@ops.ietf.org References: <4176E9E6-8AF5-11D7-B7A7-00039388672E@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, May 21, 2003 at 02:26:36PM +0200, Erik Nordmark wrote: > > I suspect there are two different ways to do this using DNS: > 1. It is possible to lookup both identifier and locators based on a DNS > name, but the DNS doesn't have a mapping from identifier to locators. > 1a. Perhaps the DNS could have a reverse mapping from locators to DNS names > aka ip6.arpa as today. > 2. The DNS also has a mapping from identifiers to locators. > Presumably this means that the identifiers must be delegated on some > hiearchical boundaries. Well, we do have ENUM as an example of a DNS system which maps from a type of identifier (E.164 number) to a locator (URI for service+FQDN) via the returned NAPTR record in the .e164.arpa space. Tim From owner-multi6@ops.ietf.org Thu May 22 05:25:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05721 for ; Thu, 22 May 2003 05:25:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19ImIz-0006Cl-00 for multi6-data@psg.com; Thu, 22 May 2003 09:24:09 +0000 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #1) id 19ImIU-0006Bf-00 for multi6@ops.ietf.org; Thu, 22 May 2003 09:23:38 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id KAA19894 for ; Thu, 22 May 2003 10:23:36 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id KAA26604 for ; Thu, 22 May 2003 10:23:36 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h4M9NaA23623 for multi6@ops.ietf.org; Thu, 22 May 2003 10:23:36 +0100 Date: Thu, 22 May 2003 10:23:36 +0100 From: Tim Chown To: multi6@ops.ietf.org Subject: Re: tunneling [Was: Agenda for Vienna] Message-ID: <20030522092336.GN20739@login.ecs.soton.ac.uk> Mail-Followup-To: multi6@ops.ietf.org References: <20030521082303.GF3653@login.ecs.soton.ac.uk> <82F22668-8C31-11D7-B63E-000393A638B2@kurtis.pp.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82F22668-8C31-11D7-B63E-000393A638B2@kurtis.pp.se> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, May 22, 2003 at 10:43:50AM +0200, Kurt Erik Lindqvist wrote: > > I used to be a strong proponent of the road-map and gradual migration > approach. That is also why I wrote the road-map draft. However, I am no > longer sure that is a good approach. As was pointed out here, that > risks distracting us. Also, the goal of multi6 is to come up with the > solution. Not the protocol details, and probably not the migration > scenarios. If we start looking at this now there is a risk that we will > dug into all kind of side issues. This might be a role for multi6 in > the future, but I would say not now. OK, so I shouldn't have used the R-word. The point is to focus on what we can meaningfully do now to address certain scenarios, and what (architecture-wise) we would like to work on longer term. Multi-addressing can be tackled now for some scenarios, in particular the SOHO/SME v6 networks which will account for a big chunk of all v6 networks. We have many of the pieces we need. I don't see that it needs a spin-off WG, but if that gets us some focus that we otherwise will not get in multi6, it's worth considering, in which case we'd want a BoF slot for a multi-addressing charter bashing in Vienna. We have two sessions. Multi-addressing and loc/id seem to be the two main consensus topics to work on? Tim From owner-multi6@ops.ietf.org Thu May 22 05:37:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06153 for ; Thu, 22 May 2003 05:37:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19ImVv-0009YY-00 for multi6-data@psg.com; Thu, 22 May 2003 09:37:31 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19ImVr-0009VA-00 for multi6@ops.ietf.org; Thu, 22 May 2003 09:37:28 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4M9bEm24391; Thu, 22 May 2003 12:37:14 +0300 Date: Thu, 22 May 2003 12:37:14 +0300 (EEST) From: Pekka Savola To: Erik Nordmark cc: multi6@ops.ietf.org Subject: RE: tunneling [Was: Agenda for Vienna] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 21 May 2003, Erik Nordmark wrote: > With my colored glasses I've seen these classes of ideas: > - multiaddressing. Also rather short term; trying to make hosts > with multiple addresses work better than they do today for > multihoming purposes (draft-huitema-multi6-hosts-01.txt) Also ohta's proposal, which isn't short-term, of course.. but, still. Btw, Erik, your mail is bouncing due to too many hops.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Thu May 22 05:42:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06315 for ; Thu, 22 May 2003 05:42:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19ImaH-000AXB-00 for multi6-data@psg.com; Thu, 22 May 2003 09:42:01 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19ImaE-000AWu-00 for multi6@ops.ietf.org; Thu, 22 May 2003 09:41:58 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4M9fPw24452; Thu, 22 May 2003 12:41:25 +0300 Date: Thu, 22 May 2003 12:41:25 +0300 (EEST) From: Pekka Savola To: Tim Chown cc: multi6@ops.ietf.org Subject: Re: tunneling [Was: Agenda for Vienna] In-Reply-To: <20030522092336.GN20739@login.ecs.soton.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-15.5 required=5.0 tests=BAYES_01,IN_REP_TO,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 22 May 2003, Tim Chown wrote: [...] > We have two sessions. Multi-addressing and loc/id seem to be the two main > consensus topics to work on? I'm not sure if a split would be meaningful. Host-based loc/id requires multi-addressing. And host-based loc/id is probably the simplest of the solutions to achieve. (Damn.. we really should have some better, more exact terminology here.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Thu May 22 06:14:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07148 for ; Thu, 22 May 2003 06:14:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19In3d-000IOE-00 for multi6-data@psg.com; Thu, 22 May 2003 10:12:21 +0000 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #1) id 19In37-000IGu-00 for multi6@ops.ietf.org; Thu, 22 May 2003 10:11:49 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA21264 for ; Thu, 22 May 2003 11:11:47 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id LAA29113 for ; Thu, 22 May 2003 11:11:47 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h4MABl425704 for multi6@ops.ietf.org; Thu, 22 May 2003 11:11:47 +0100 Date: Thu, 22 May 2003 11:11:47 +0100 From: Tim Chown To: multi6@ops.ietf.org Subject: Re: tunneling [Was: Agenda for Vienna] Message-ID: <20030522101147.GP20739@login.ecs.soton.ac.uk> Mail-Followup-To: multi6@ops.ietf.org References: <20030522092336.GN20739@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, May 22, 2003 at 12:41:25PM +0300, Pekka Savola wrote: > > (Damn.. we really should have some better, more exact terminology here.) That would be useful :) Tim From owner-multi6@ops.ietf.org Thu May 22 06:52:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07771 for ; Thu, 22 May 2003 06:52:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Ineo-0002aE-00 for multi6-data@psg.com; Thu, 22 May 2003 10:50:46 +0000 Received: from smtp03.uc3m.es ([163.117.136.123] helo=smtp.uc3m.es) by psg.com with esmtp (Exim 3.36 #1) id 19IneH-0002Hg-00 for multi6@ops.ietf.org; Thu, 22 May 2003 10:50:13 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 9D658432AB; Thu, 22 May 2003 12:50:10 +0200 (CEST) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp03.uc3m.es (Postfix) with ESMTP id 7F7FB2B664; Thu, 22 May 2003 12:50:08 +0200 (CEST) Subject: Re: Re:loc/id vs HIP (was: tunneling [Was: Agenda for Vienna]) From: marcelo bagnulo To: Pekka Savola Cc: multi6@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Organization: uc3m Message-Id: <1053600512.789.12.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 May 2003 12:48:33 +0200 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_XIMIAN autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pekka, > Again: this doesn't solve the whole problem. Consider e.g. Craig's > traffic engineering requirements, or (to a lesser degree) requirements > that the nodes should not have to renumbered ("deploying/retiring > locators") when the ISP's are changing. A comment about the renumbering issue. First i do not think this is part of the multi-homing issue, so if we find a solution that does not solve this i would say it is ok. However, i do think that it is a related problem and it would be interesting to find a solution that also support this (just as it would be nice that the split loc/id provides support for mobility) In the particular case of HIP, i think that it does facilitates renumbering. Renumbering involves changing addresses in hosts but it also involves changing ACLs and other configurations that involve IP address as identifier. Since HIP provides a stable identifier, those configurations could use the stable identifier instead of the address. I agree that this does not completely solve the issue. The cost of this is that the identifier has to be carried in every packet, i guess. regards, marcelo -- marcelo bagnulo uc3m From owner-multi6@ops.ietf.org Thu May 22 07:02:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08030 for ; Thu, 22 May 2003 07:02:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19InpM-0005QS-00 for multi6-data@psg.com; Thu, 22 May 2003 11:01:40 +0000 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74]) by psg.com with esmtp (Exim 3.36 #1) id 19Inoq-0005HL-00 for multi6@ops.ietf.org; Thu, 22 May 2003 11:01:09 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.9/8.10.2) with ESMTP id h4MB11Rp003568; Thu, 22 May 2003 13:01:01 +0200 (CEST) Date: Thu, 22 May 2003 13:01:00 +0200 Subject: Re: Options to consider [Re: tunneling [Was: Agenda for Vienna]] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Brian E Carpenter" , To: "Christian Huitema" From: Kurt Erik Lindqvist In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-14.9 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I personally like conservative approaches. Brian, you asked in another > message whether multi-addressing is desirable. I don't think that the > working group should try to answer that "desirability" question. If we > want to make progress, we should rather charter two groups, and then > let > the market choose. I would much rather see one group working on the > multi-addressing solution and another working on the split > locator-identifier solution, than trying to coerce everybody in a > single > group. I agree with you that we should explore both solutions, but I don't think having two groups and eventually two standards will benefit anyone. Especially from a operational perspective where we would end up having to maintain both solutions. I would rather suggest to form two design teams then. > So I guess one of the short term exercises should be to > draft a comprehensive charter for a multi-addressing working group. If > we could adopt that in Vienna, we would have achieved something. > See above. - kurtis - From owner-multi6@ops.ietf.org Thu May 22 07:06:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08270 for ; Thu, 22 May 2003 07:06:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IntI-0006ug-00 for multi6-data@psg.com; Thu, 22 May 2003 11:05:44 +0000 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74]) by psg.com with esmtp (Exim 3.36 #1) id 19Insm-0006mh-00 for multi6@ops.ietf.org; Thu, 22 May 2003 11:05:12 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.9/8.10.2) with ESMTP id h4MB57Rp003574; Thu, 22 May 2003 13:05:08 +0200 (CEST) Date: Thu, 22 May 2003 13:05:06 +0200 Subject: Re: tunneling [Was: Agenda for Vienna] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Tim Chown , multi6@ops.ietf.org To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <3ED23ABE-8C45-11D7-B63E-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-14.9 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > If we can steer clear of stuff like what the next generation namespace > should look like I see no reason to involve the IRTF. Even then I would say we can stay clear. - kurtis - From owner-multi6@ops.ietf.org Thu May 22 07:14:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08675 for ; Thu, 22 May 2003 07:14:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Io0X-0008nQ-00 for multi6-data@psg.com; Thu, 22 May 2003 11:13:13 +0000 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74]) by psg.com with esmtp (Exim 3.36 #1) id 19Io01-0008XR-00; Thu, 22 May 2003 11:12:41 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.9/8.10.2) with ESMTP id h4MBCZRp003577; Thu, 22 May 2003 13:12:35 +0200 (CEST) Date: Thu, 22 May 2003 13:12:33 +0200 Subject: Re: Agenda for Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Randy Bush , multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200305212305.IAA11370@necom830.hpcl.titech.ac.jp> Message-Id: <4970C2A8-8C46-11D7-B63E-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-15.5 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, RCVD_IN_RFCI,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> So, why not have three 2H sessions and stop saying "time >>>>> constraint"? >>>> >>>> because you will need a different AD to approve it. >>> >>> According to Kurt, no. >> >> Say again? I think I have made it pretty clear that we will not apply >> for three 2h sessions. > > You are a (co-)chair, not an AD. Yes. > > That is why you, not the AD, are the problem. Ok, let's take this one last time. In order to have any more than one slot, you need approval by the AD. In order to have three slots, you need to have IESG approval. In order for this to reach the IESG, you need to have the AD bring there. Randy, correct me if I am wrong. I as co-chair do not support having three slots. Even if I did, Randy as AD does not support having three slots. So, as it stands, you would have to convince both be and Randy (and probably Sean) that three slots would be useful. After that you need the IESG to approve it. If you don't like this, there are ways to appeal. From what I see on the mailinglist, there have been support for having ONLY two sessions. Only you have asked us to hold a third session. Also, from what I have understood you wanted the third session so that we could have more time for people to present their proposals. Again, my understanding of the IETF process and the IETF meetings are that you present proposals by writing drafts. The sessions are there for general architectural discussions and to sort out details of the drafts. > In addition, it is another problem that you have little understanding > on IETF procedure. I don't know what part of the process I am failing to understand. The above is my understanding, and I am sure that Randy or Erik as ADs and IESG members or any of the former IAB and IESG members on this list can help me understand this if I am wrong. Please point out any misunderstandings. - kurtis - From owner-multi6@ops.ietf.org Thu May 22 07:16:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08779 for ; Thu, 22 May 2003 07:16:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Io36-0009kx-00 for multi6-data@psg.com; Thu, 22 May 2003 11:15:52 +0000 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74]) by psg.com with esmtp (Exim 3.36 #1) id 19Io2y-0009kU-00 for multi6@ops.ietf.org; Thu, 22 May 2003 11:15:44 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.9/8.10.2) with ESMTP id h4MBFhRp003580 for ; Thu, 22 May 2003 13:15:43 +0200 (CEST) Date: Thu, 22 May 2003 13:15:42 +0200 Subject: Slot requested Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Kurt Erik Lindqvist To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-27.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_RFCI,REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On torsdag, maj 22, 2003, at 05:28 Europe/Stockholm, Randy Bush wrote: >>> Say again? I think I have made it pretty clear that we will not apply >>> for three 2h sessions. >> You are a (co-)chair, not an AD. >> That is why you, not the AD, are the problem. >> In addition, it is another problem that you have little understanding >> on IETF procedure. >> Randy, have you recognized that, unless the problems are solved, there >> is no point to trying to have a different AD to approve it. > > what i recognize is a lot of rude fighting and little technical > content. and it is technical content which gets meeting slots. > Agreed. For the FYI of everyone I have requested the two meeting slots as described in my original mail. The two slots have been approved by the AD (Randy). I am waiting for the next update mail from the IETF secretariat to acknowledge it. If anyone still disagrees, please let's take that off-line from the mailing list. Either to me or through other channels you feel appropriate. - kurtis - From owner-multi6@ops.ietf.org Thu May 22 07:28:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09072 for ; Thu, 22 May 2003 07:28:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IoEZ-000DON-00 for multi6-data@psg.com; Thu, 22 May 2003 11:27:43 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19IoEW-000DO5-00 for multi6@ops.ietf.org; Thu, 22 May 2003 11:27:40 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4MBRSK25400; Thu, 22 May 2003 14:27:33 +0300 Date: Thu, 22 May 2003 14:27:28 +0300 (EEST) From: Pekka Savola To: marcelo bagnulo cc: multi6@ops.ietf.org Subject: Re: Re:loc/id vs HIP (was: tunneling [Was: Agenda for Vienna]) In-Reply-To: <1053600512.789.12.camel@presto.it.uc3m.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On 22 May 2003, marcelo bagnulo wrote: > > Again: this doesn't solve the whole problem. Consider e.g. Craig's > > traffic engineering requirements, or (to a lesser degree) requirements > > that the nodes should not have to renumbered ("deploying/retiring > > locators") when the ISP's are changing. > > A comment about the renumbering issue. > First i do not think this is part of the multi-homing issue, so if we > find a solution that does not solve this i would say it is ok. Well, I think it is, practically, to an extent. If Site is multihomed using two prefixes to two providers, and wishes to switch the second one to a better one, this should not be an overwhelming task (otherwise folks might not want a multi-address solution in the first place). > However, i do think that it is a related problem and it would be > interesting to find a solution that also support this (just as it would > be nice that the split loc/id provides support for mobility) Yep. > In the particular case of HIP, i think that it does facilitates > renumbering. Renumbering involves changing addresses in hosts but it > also involves changing ACLs and other configurations that involve IP > address as identifier. Yes, HIP makes it much easier. However, the backward interoperability might require checking for locators anyway, or a way to ensure that bad guys don't spoof identifiers. > Since HIP provides a stable identifier, those configurations could use > the stable identifier instead of the address. I agree that this does not > completely solve the issue. The cost of this is that the identifier has > to be carried in every packet, i guess. Of course, many of those ACL's could be obsolete by then, right.. Or one could have locator-to-identifier and identifier-to-locator mapping functions. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Thu May 22 08:09:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10505 for ; Thu, 22 May 2003 08:09:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Iorv-000P9G-00 for multi6-data@psg.com; Thu, 22 May 2003 12:08:23 +0000 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 19Ior1-000P79-00; Thu, 22 May 2003 12:07:27 +0000 From: Masataka Ohta Message-Id: <200305221154.UAA06455@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id UAA06455; Thu, 22 May 2003 20:54:31 +0900 Subject: Re: Agenda for Vienna In-Reply-To: from Randy Bush at "May 21, 2003 08:28:49 pm" To: Randy Bush Date: Thu, 22 May 2003 20:54:30 +0859 () CC: Kurt Erik Lindqvist , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Randy; > >> Say again? I think I have made it pretty clear that we will not apply > >> for three 2h sessions. > > You are a (co-)chair, not an AD. > > That is why you, not the AD, are the problem. > > In addition, it is another problem that you have little understanding > > on IETF procedure. > > Randy, have you recognized that, unless the problems are solved, there > > is no point to trying to have a different AD to approve it. > > what i recognize is a lot of rude fighting and little technical > content. and it is technical content which gets meeting slots. Technical content? The first step is to write drafts. The second step is to read them. Then, discussions could begin. As you know, I have wrote a draft with techncal contents long ago. Relatively recently, as discussions not on a requirement draft has been strongly discouraged, Sean asked several questions and I gave answers. Kurt said he has never read it and, even though he said he would read it, I have received nothing from him, yet. For newer proposals, it is not so clear yet, at which level of abstraction we will be expected to spend most of the time at Vienna, even though I explicitely asked Kurt to clarify the target. So, how, do you think, we can move forward with technical content? Masataka Ohta From owner-multi6@ops.ietf.org Thu May 22 09:04:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12015 for ; Thu, 22 May 2003 09:04:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IpiU-000EQv-00 for multi6-data@psg.com; Thu, 22 May 2003 13:02:42 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19Iphy-000EPs-00 for multi6@ops.ietf.org; Thu, 22 May 2003 13:02:10 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h4MD0jn67892 for ; Thu, 22 May 2003 15:00:45 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 22 May 2003 15:00:55 +0200 Subject: Re: Options to consider [Re: tunneling [Was: Agenda for Vienna]] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Iljitsch van Beijnum To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <6C812BA7-8C55-11D7-B700-00039388672E@muada.com> X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On woensdag, mei 21, 2003, at 18:43 Europe/Amsterdam, Christian Huitema wrote: >> 2. Design a multi-address based solution, where an enterprise would >> have multiple PA prefixes and some technology would be added to >> support >> address selection. draft-de-launois-multi6-naros-00.txt >> might be the starting point. >> --> this is a conservative approach. It doesn't change anything in >> the addressing or routing architecture. We could write a WG >> charter for this quite easily. > I personally like conservative approaches. :-) Me, I'm al in favor of conservatism as long as it doesn't get in the way of progress. > As for multi-addressing itself, naros addresses one of the issues, i.e. > the choice of addresses by multi-addressing aware hosts. Christian, could you (again) send some pointers to what it is you're talking about when you say "multi-adressing"? (It has been a long time since Atlanta.) Obviously all IPv6 hosts know about having more than one address. Which immediately poses the problem of both source and destination address selection. NAROS is a good approach to start solving this problem but there is more work to be done there, IMO. It occurs to me that the address selection problem isn't so different between loc/id and other multiaddress solutions. It's just that in loc/id it isn't as vital to get it right as you can change your mind later. So it's probably useful to make something that can help with address selection, regardless whether a host implements naive multiaddressing, your proposal or loc/id. On woensdag, mei 21, 2003, at 12:25 Europe/Amsterdam, Pekka Savola wrote: > Based on a quick look, it seems to me that: > - being able to switch ISP's without renumbering: 1), 3.2), maybe > others > - redundancy due to link failures etc.: 1), maube 2), maybe 3) > - connection survivability (internal connections, external > connections) > 1), 4), maybe some of 3) > - more fine-grained (ie. not 50/50) inbound traffic engineering: maybe > 1), 2) > - the maximum frequency of ISP (=prefix) changes: 1), maybe some of 3) Ok, let's have a look here. First of all, what is "switching" ISPs? Dropping an existing ISP should be trivial: just disconnect and stop your routers from advertising the prefix. This should work well even with current implmentations because IPv6 applications are reasonably smart in trying several addresses until they find one that works. (They have to try v6 and fall back to v4 anyway, so multiple v6 isn't that much more work.) Adding a new ISP isn't all that hard either: add connectivity, start prefix announcements and change the DNS. There is one caveat, though: access filters. More on that later. And obviously all of this assumes you can work with multiple ISPs to start with. That means either hosts know how to select the right source address (in practice that means they must have a routing table) or source address dependent routing. NAROS or something similar could help here for traditional multiaddressing. Note that source address dependent routing (SADR) is superior as this survives routing changes where a certain destination is suddenly preferred over ISP 2 rather than ISP 1. Without SADR your session dies. Loc/id can solve this with heuristics and/or rewriting source addresses at egress, which is of course even better. The same thing but worse happens when a link or ISP fails. Only loc/id can save your ongoing sessions then. Note that for many applications (web browsing and normal length email) this isn't much of an issue as the layer 4 sessions are very short. But then sometimes they are long (downloads) so we can't ignore this problem. (If you need an hour to transfer a file then 55 minutes of connectivity over one ISP and no failover is actually worse than no connectivity: then you wouldn't have wasted your time.) There are many ways to traffic engineer. Something like NAROS that also looks at the destination address would be a good way. Selectively dropping TCP SYNs to get hosts to connect over the other line would be another. With loc/id + SADR we are in traffic engineering heaven as it becomes possible to load balance a single session over more than one ISP. So I'd like to reserve two of Tony's maximum of 9 top level subsystems: - a mechanism to order possible combinations of source and destination addresses (locators) on expected connectivity and "cost" - a mechanism to determine the actual connectivity properties of a source and destination address (locator) pair On the filtering thing: If we do loc/id in the host firewalls have a hard time seeing who packets are really coming from. Who they are going may also be a problem but this one should be solvable as you can control the who<->where mapping in your own site, but obviously there is no way to know about this for the entire net. And even if we don't do loc/id, filtering on remote addresses is evil as it makes renumbering virtually impossible. But do we really need the option of filtering on remote addresses? I'm saying we don't. However, this means people will have to use other authentication mechanisms, such as IPsec or TLS. Is this reasonable? From owner-multi6@ops.ietf.org Thu May 22 09:21:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12836 for ; Thu, 22 May 2003 09:21:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Ipzu-000Hy7-00 for multi6-data@psg.com; Thu, 22 May 2003 13:20:42 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by psg.com with esmtp (Exim 3.36 #1) id 19IpzO-000HwT-00 for multi6@ops.ietf.org; Thu, 22 May 2003 13:20:10 +0000 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4MDJlOP027397; Thu, 22 May 2003 09:19:47 -0400 (EDT) Date: Thu, 22 May 2003 09:19:47 -0400 (EDT) From: Ralph Droms To: Pekka Savola cc: marcelo bagnulo , multi6@ops.ietf.org Subject: Re: Re:loc/id vs HIP (was: tunneling [Was: Agenda for Vienna]) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-38.2 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Pekka, On Thu, 22 May 2003, Pekka Savola wrote: > On 22 May 2003, marcelo bagnulo wrote: > > > Again: this doesn't solve the whole problem. Consider e.g. Craig's > > > traffic engineering requirements, or (to a lesser degree) requirements > > > that the nodes should not have to renumbered ("deploying/retiring > > > locators") when the ISP's are changing. > > > > A comment about the renumbering issue. > > First i do not think this is part of the multi-homing issue, so if we > > find a solution that does not solve this i would say it is ok. > > Well, I think it is, practically, to an extent. If Site is multihomed > using two prefixes to two providers, and wishes to switch the second one > to a better one, this should not be an overwhelming task (otherwise folks > might not want a multi-address solution in the first place). How is the scenario you describe (switching one of two prefixes) different - in its effect on renumbering - from switching a site's only prefix? Multi-homing might make renumbering *easier* - providing one reliable address while renumbering the second... > > > However, i do think that it is a related problem and it would be > > interesting to find a solution that also support this (just as it would > > be nice that the split loc/id provides support for mobility) > > Yep. > > > In the particular case of HIP, i think that it does facilitates > > renumbering. Renumbering involves changing addresses in hosts but it > > also involves changing ACLs and other configurations that involve IP > > address as identifier. > > Yes, HIP makes it much easier. However, the backward > interoperability might require checking for locators anyway, or > a way to ensure that bad guys don't spoof identifiers. > > > Since HIP provides a stable identifier, those configurations could use > > the stable identifier instead of the address. I agree that this does not > > completely solve the issue. The cost of this is that the identifier has > > to be carried in every packet, i guess. > > Of course, many of those ACL's could be obsolete by then, right.. > > Or one could have locator-to-identifier and identifier-to-locator mapping > functions. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > > From owner-multi6@ops.ietf.org Thu May 22 10:15:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15824 for ; Thu, 22 May 2003 10:15:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Iqon-0002Bo-00 for multi6-data@psg.com; Thu, 22 May 2003 14:13:17 +0000 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #1) id 19IqoH-0001rQ-00 for multi6@ops.ietf.org; Thu, 22 May 2003 14:12:45 +0000 Received: from x17.ripe.net (x17.ripe.net [193.0.1.17]) by birch.ripe.net (8.12.9/8.11.6) with ESMTP id h4MECcVn014242; Thu, 22 May 2003 16:12:38 +0200 Received: (from shane@localhost) by x17.ripe.net (8.12.9/8.12.6) id h4MECckM007855; Thu, 22 May 2003 16:12:38 +0200 Date: Thu, 22 May 2003 16:12:38 +0200 From: Shane Kerr To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org Subject: Re: Two Prefixes in One Address (was: new draft) Message-ID: <20030522141237.GA7593@x17.ripe.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Status: No, hits=-38.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Iljitsch, On 2003-05-11 15:30:42 +0200, Iljitsch van Beijnum wrote: > After friday's discussion I wanted to see what could be accomplished > without any kind of negotiation. What I came up with: > > http://www.muada.com/drafts/draft-van-beijnum-multi6-2pi1a.txt I had a read of your draft, and it's very nice. I have some specific comments: pg 3. Why specify "no more than 1 per minute" for ICMP packets? This seems kind of arbritrary. Note that if you *required* some sort of KEEPALIVE on all locators then it could help with poor middleboxes. :) What does "in the absense of better knowledge" mean? Again, if you required some sort of KEEPALIVE, then you could build an RTT-style mechanism into the protocol. pg 4. I suggest that you recommend people *not* use the identifier address as the regular address. It seems like a great potential source of confusion. pg 6. It might be better for a multihomed-aware but single-homed client to use the same information for locator 1 and locator 2? As in, "prefix from ISP A" and "prefix from ISP B" are the same. No special handling would be needed on the multihomed server side then - it can merely use the same algorithm for all clients. pg 7. "Note that multihomed communication without involvement from the DNS isnt' psossible." overstates the case, and not really pertinent. I suggest removing it. pg 11. I think there may be some security issue, in that a client can generate packets to another client by sending a packet with the prefix from a 3rd party in the multihomed client address. Haven't thought too much about this.... General comments: This seems simple, and requires no new infrastructure. I like the NAROS technique also because it abstracts a lot of decision making (too much really from the current draft, IMHO). I'd be interested in seeing the two work together in some way, esp. regarding server-side traffic preferencing. -- Shane Kerr RIPE NCC From owner-multi6@ops.ietf.org Thu May 22 10:33:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16420 for ; Thu, 22 May 2003 10:33:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Ir7L-0006en-00 for multi6-data@psg.com; Thu, 22 May 2003 14:32:27 +0000 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 19Ir6p-0006ce-00 for multi6@ops.ietf.org; Thu, 22 May 2003 14:31:55 +0000 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h4MEVktU029158; Thu, 22 May 2003 10:31:46 -0400 Message-Id: <200305221431.h4MEVktU029158@ginger.lcs.mit.edu> From: Tim Shepard To: Iljitsch van Beijnum cc: Pekka Savola , multi6@ops.ietf.org Subject: Re: loc/id vs HIP (was: tunneling [Was: Agenda for Vienna]) In-reply-to: Your message of Thu, 22 May 2003 09:40:11 +0200. <9E2B9BB8-8C28-11D7-B700-00039388672E@muada.com> Date: Thu, 22 May 2003 10:31:45 -0400 X-Spam-Status: No, hits=-13.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk I'm a big fan of HIP, and your comments about HIP in the context of multi6 have prodded me into speaking up... > About HIP. I've been reading the new architecture document. It seems it > pretty much does the whole loc/id thing, although it doesn't really > mention failover. The problem however is that HIP does much more than > just multihoming. Maybe there is some synergy between multihoming and > mobility, but I don't see the advantages of leaping multihoming, > mobility and encryption on one big pile. In the end, that's going to > mean you're going to do at least one of those not very well. I think your understanding may be accurate. Those of us who are fond of HIP like it because we think it knocks off a bunch of problems together. But while we already have implementations that do substantial parts of HIP, I don't believe we have any automatic handling of failover or switchover implemented yet, and we're still imagining how some of the details will be handled. (And I understand that we've recently realized that there's a lot more to document about how mutihoming and mobility will be handled by HIP that in the next round of HIP drafts, and these details will be split out into multiple drafts.) The fact that we're still imagining the details and that the drafts don't tell you exactly how everything will be done could be considered a problem or a feature. rfc793.txt (September 1981) has perhaps lasted as long as it has without being obsoleted precisely because it is somewhat vague about some areas of implementation behavior. I doubt we have any hope of doing as well as it did, but it does serve as an example of where providing a solid framework while leaving some details to the implementor's imagination and creativity can be useful. Regarding "you're going to do at least one of those not very well", It seems to me that by starting with security and using it to boostrap identity, it will make the securing of all "of those" much easier. We'll see. Perhaps HIP is not *the* solution for the internet, but I believe it has the potential to become very popular if we can get freely available (hopefully open-source) implementations available for all the popular platforms, and HIP is usable between consenting end-nodes (without requiring the network to explicitly support HIP). > And then there is simple economics: how are you going to convince > someone who multihomes in IPv6 to switch to IPv6 and then adopt HIP to > retain multihoming functionality? This means lots of additional > expenses because of the crypto hardware (if you can't do line rate > crypto you're a sitting duck for crypto DoS) and the additional > bandwidth for all the extra headers. Don't think it's so bad? I think > it is. The HIP header is at least 40 bytes. Then you need ESP, which is > at least 8 bytes (probably more like 16), an initialization vector and > padding. But of course just encrypting isn't enough, you really should > be doing authentication as well... Ignoring that for a moment the total > is 64 - 95 bytes when using a block cipher with 16 byte blocks. This > makes a TCP ACK 136 bytes. In plain IPv4 it's only 40 bytes... The > average pacet size is typically around 500 bytes. With HIP and IPv6 > adding some 92 bytes, this eats away 16% of the available bandwidth. Note that the HIP header, for most all of the traffic after the first 2 round trips, is ommitted entirely. This is because its contents are completely implied by the SPI in the ESP header. So the per-packet HIP overhead is a non-issue. The larger IPv6 headers and the ESP overhead (both in bytes and in crypto work) are not HIP problems per-se. Your comments about the need for fast crypto (whether it be seperate hardware, or just a screamingly fast main CPU which I understand will be available at your nearby discount store sometime late next year) are right on. But that again is a problem with doing ESP or any other crypto, and is not unique to HIP. Regarding the adoption of HIP, I expect (hope) that it will become popular like ssh became popular: end users adopting it by grabbing free software and adding it to their systems. I personally want HIP on the computer I carry around with me so that I can suspend, walk to a different network (perhaps an IPv6-only network), resume, and have all my connections continue (perhaps having been migrated from IPv4 to IPv6 (or vice versa)). The hope of being able to do this is what first drew me into HIP a couple of years ago. I expect I'll have this functionality for myself by the end of the year if not before Vienna. > On a related note, I've been thinking about ways to do something about > all this outrageous overhead but being able to have some per-packet > additional info at the same time. It occurs to me that much of the > stuff we're thinking about putting in each packet really doesn't have > to be in _each_ packet. Having identifiers and such in every 32th > packet or once every 5 seconds or so should be more than enough. That's already sort of what HIP does, since it uses the SPI in the ESP header to lookup the (unchanging) HIP header and (conceptually) reinsert it. (In practice, you don't need to reinsert it, because the SPI in the ESP header tells you what ESP transform (and with what parameters) to stuff the packet through, and whatever pops out the other side of the ESP transform is what you continue processing in the stack. So even though you conceptually put the HIP header back on the packet, in the actual code, you don't do anything at all.) -Tim Shepard shep@alum.mit.edu From owner-multi6@ops.ietf.org Thu May 22 11:11:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17923 for ; Thu, 22 May 2003 11:11:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Iri4-000HWe-00 for multi6-data@psg.com; Thu, 22 May 2003 15:10:24 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19Iri0-000HUq-00 for multi6@ops.ietf.org; Thu, 22 May 2003 15:10:20 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4MFA4U27342; Thu, 22 May 2003 18:10:04 +0300 Date: Thu, 22 May 2003 18:10:04 +0300 (EEST) From: Pekka Savola To: Ralph Droms cc: marcelo bagnulo , Subject: Re: Re:loc/id vs HIP (was: tunneling [Was: Agenda for Vienna]) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 22 May 2003, Ralph Droms wrote: > > On 22 May 2003, marcelo bagnulo wrote: > > > > Again: this doesn't solve the whole problem. Consider e.g. Craig's > > > > traffic engineering requirements, or (to a lesser degree) requirements > > > > that the nodes should not have to renumbered ("deploying/retiring > > > > locators") when the ISP's are changing. > > > > > > A comment about the renumbering issue. > > > First i do not think this is part of the multi-homing issue, so if we > > > find a solution that does not solve this i would say it is ok. > > > > Well, I think it is, practically, to an extent. If Site is multihomed > > using two prefixes to two providers, and wishes to switch the second one > > to a better one, this should not be an overwhelming task (otherwise folks > > might not want a multi-address solution in the first place). > > How is the scenario you describe (switching one of two prefixes) > different - in its effect on renumbering - from switching a site's only > prefix? > > Multi-homing might make renumbering *easier* - providing one reliable > address while renumbering the second... This depends on what you count in in the renumbering issue. There are two cases when you switch one ISP: 1) completely removing the first ("disconnecting from the Internet"), then adding the second, and 2) trying to run the first simultaneously with the second, and when the second works, disconnect the first. 1) above is "easier" to accomplish as the connections will die by definition, you have to spend time with configuration etc. -- but more harmful for the network. You really don't have to care about complex things such as which prefixes are used etc. 2) is actually quite similar to "multihomed continuum" where you change only one of them, with the difference that you're not going to remove the first prefix in the end. After some thinking, I can't quickly find major differences between multihomed renumbering and 2). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Thu May 22 11:26:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18382 for ; Thu, 22 May 2003 11:26:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Irw5-000Lg3-00 for multi6-data@psg.com; Thu, 22 May 2003 15:24:53 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19Irvz-000Lfh-00 for multi6@ops.ietf.org; Thu, 22 May 2003 15:24:47 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4MFOhf27484; Thu, 22 May 2003 18:24:43 +0300 Date: Thu, 22 May 2003 18:24:43 +0300 (EEST) From: Pekka Savola To: Iljitsch van Beijnum cc: multi6@ops.ietf.org Subject: Re: Options to consider [Re: tunneling [Was: Agenda for Vienna]] In-Reply-To: <6C812BA7-8C55-11D7-B700-00039388672E@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 22 May 2003, Iljitsch van Beijnum wrote: > > - being able to switch ISP's without renumbering: 1), 3.2), maybe > > others > > - redundancy due to link failures etc.: 1), maube 2), maybe 3) > > - connection survivability (internal connections, external > > connections) > > 1), 4), maybe some of 3) > > - more fine-grained (ie. not 50/50) inbound traffic engineering: maybe > > 1), 2) > > - the maximum frequency of ISP (=prefix) changes: 1), maybe some of 3) > > Ok, let's have a look here. > > First of all, what is "switching" ISPs? Having a PI address which is globally reachable: not having to change addresses used by hosts in your site if you wish to change your network service provider. > Dropping an existing ISP should > be trivial: just disconnect and stop your routers from advertising the > prefix. This should work well even with current implmentations because > IPv6 applications are reasonably smart in trying several addresses > until they find one that works. (They have to try v6 and fall back to > v4 anyway, so multiple v6 isn't that much more work.) Adding a new ISP > isn't all that hard either: add connectivity, start prefix > announcements and change the DNS. Uh, oh. It isn't as simple as that, and gets even more complicated the bigger the site becomes. I can the required operations in my home network manually in 10-15 minutes, maybe; and I have just one router and a few computers. But I'm not as optimistic about bigger sites.. > There is one caveat, though: access filters. More on that later. > > And obviously all of this assumes you can work with multiple ISPs to > start with. That means either hosts know how to select the right source > address (in practice that means they must have a routing table) or > source address dependent routing. NAROS or something similar could help > here for traditional multiaddressing. Note that source address > dependent routing (SADR) is superior as this survives routing changes > where a certain destination is suddenly preferred over ISP 2 rather > than ISP 1. Indeed. > Without SADR your session dies. Loc/id can solve this with > heuristics and/or rewriting source addresses at egress, which is of > course even better. I'm not sure how loc/id could solve this (by guessing to try another locators when one doesn't get acks, I suppose), but no matter. > The same thing but worse happens when a link or ISP fails. Only loc/id > can save your ongoing sessions then. Nope. Heard of "multihoming at site-exit routers"? Of course, this doesn't help you if the whole ISP melts down (and not just their border router towards you or whateveR). But that's IMO such a rare occurrence with real ISP's that you shouldn't be too worried. > There are many ways to traffic engineer. Something like NAROS that also > looks at the destination address would be a good way. Selectively > dropping TCP SYNs to get hosts to connect over the other line would be > another. With loc/id + SADR we are in traffic engineering heaven as it > becomes possible to load balance a single session over more than one > ISP. I'd like to agree that the traffic engineering with more specific route advertisements is rather lousy tool at best.. but the options seem to be to do it with that way or in the application layer (with some application-specific intelligence and redirection) at the moment.. > If we do loc/id in the host firewalls have a hard time seeing who > packets are really coming from. Who they are going may also be a > problem but this one should be solvable as you can control the > who<->where mapping in your own site, but obviously there is no way to > know about this for the entire net. Agree. > And even if we don't do loc/id, > filtering on remote addresses is evil as it makes renumbering virtually > impossible. > > But do we really need the option of filtering on remote addresses? Maybe not -- but on on remote identities -- might be useful. One thing is sure: network managers won't want to relinquish security control of their nets to the hosts, or host operating systems. This may be mitigated by the new distributed end-host firewalls WG, though -- but I haven't had time to look at the direction they're heading. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Thu May 22 11:35:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18561 for ; Thu, 22 May 2003 11:35:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Is5r-000Nmx-00 for multi6-data@psg.com; Thu, 22 May 2003 15:34:59 +0000 Received: from mail2.microsoft.com ([131.107.3.124]) by psg.com with esmtp (Exim 3.36 #1) id 19Is4h-000NeP-00 for multi6@ops.ietf.org; Thu, 22 May 2003 15:33:47 +0000 Received: from mail5.microsoft.com ([157.54.6.156]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 22 May 2003 08:33:44 -0700 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 22 May 2003 08:33:36 -0700 Received: from 157.54.8.23 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 22 May 2003 08:34:11 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 22 May 2003 08:33:35 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 22 May 2003 08:33:35 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Thu, 22 May 2003 08:33:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Options to consider [Re: tunneling [Was: Agenda for Vienna]] Date: Thu, 22 May 2003 08:33:30 -0700 Message-ID: Thread-Topic: Options to consider [Re: tunneling [Was: Agenda for Vienna]] Thread-Index: AcMgZB1YTtBQtOxkRgGBSIwoQq+4BgAESinQ From: "Christian Huitema" To: "Iljitsch van Beijnum" , X-OriginalArrivalTime: 22 May 2003 15:33:33.0350 (UTC) FILETIME=[80F8EC60:01C32077] X-Spam-Status: No, hits=-10.4 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA18561 > > As for multi-addressing itself, naros addresses one of the issues, i.e. > > the choice of addresses by multi-addressing aware hosts. > > Christian, could you (again) send some pointers to what it is you're > talking about when you say "multi-adressing"? (It has been a long time > since Atlanta.) Obviously all IPv6 hosts know about having more than > one address. Which immediately poses the problem of both source and > destination address selection. NAROS is a good approach to start > solving this problem but there is more work to be done there, IMO. I intend to submit as a draft the doc that David Kessens and I sent to the group at the time of the San Francisco IETF. The basic notion is that a site is connected through several providers, and receives a different addressing prefix from each provider. Hosts in the site receive multiple prefixes announcement through the standard auto-configuration mechanisms. They configure addresses using one or several of these prefixes. The major rule of engagement in the multi-addressing scenario is backward compatibility: hosts that would have functioned well using standard implementations should continue functioning well even when connected to a multi-addressed site. Hosts that have been augmented with some multi-addressing support capability function better in a multi-addressed site, for example ensuring that their sessions survive or that their packets follow the most efficient path. The doc pointed out the need to solve several issues, the most pressing of which being the interaction between multi-addressing and ingress filtering. > It occurs to me that the address selection problem isn't so different > between loc/id and other multiaddress solutions. It's just that in > loc/id it isn't as vital to get it right as you can change your mind > later. It could be argued that the loc/id split is a form of multi-homing, where the "id" is in fact a "virtual provider" address. It is possible to use the distributed hash table technology to enable overlay routing of these addresses, in which case the "virtual provider" is just another provider. -- Christian Huitema From owner-multi6@ops.ietf.org Sun May 25 12:25:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05498 for ; Sun, 25 May 2003 12:25:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19JyFC-000Ecr-00 for multi6-data@psg.com; Sun, 25 May 2003 16:21:10 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19JyF9-000Ece-00 for multi6@ops.ietf.org; Sun, 25 May 2003 16:21:08 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h4PGKuxS012044; Sun, 25 May 2003 18:20:56 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sun, 25 May 2003 18:19:58 +0200 Subject: Re: Options to consider [Re: tunneling [Was: Agenda for Vienna]] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Christian Huitema" From: Iljitsch van Beijnum In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-28.3 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On donderdag, mei 22, 2003, at 17:33 Europe/Amsterdam, Christian Huitema wrote: >> Christian, could you (again) send some pointers to what it is you're >> talking about when you say "multi-adressing"? > I intend to submit as a draft the doc that David Kessens and I sent to > the group at the time of the San Francisco IETF. The basic notion is > that a site is connected through several providers, and receives a > different addressing prefix from each provider. Hosts in the site > receive multiple prefixes announcement through the standard > auto-configuration mechanisms. They configure addresses using one or > several of these prefixes. Ok. This is what I tried to do a couple of years ago with little success (I mean actually do, not write a draft or something). > The major rule of engagement in the multi-addressing scenario is > backward compatibility: hosts that would have functioned well using > standard implementations should continue functioning well even when > connected to a multi-addressed site. Hosts that have been augmented > with > some multi-addressing support capability function better in a > multi-addressed site, for example ensuring that their sessions survive > or that their packets follow the most efficient path. Ok, this is a big problem. Let's call existing hosts that have multiple addresses but don't know how to handle them "naive" multiaddressed hosts. > The doc pointed out the need to solve several issues, the most pressing > of which being the interaction between multi-addressing and ingress > filtering. Exactly. Naive MA hosts don't get this, so they select the wrong source/dest combinations that can't work in the presence of ingress filtering. I see three solutions: 1. Source address based routing. Since this is helpful in other, related areas as well it would be good to implement this. 2. Giving hosts a routing table. This can work for some hosts under some circumstances, but it doesn't scale, certainly not in the long run, and there's still the problem of breaking sessions when there are routing changes. 3. Give naive hosts only a single address. This should work for those hosts, but then either autoconfiguration has to change or lots of manual configuration for smarter multiaddressed hosts. >> It occurs to me that the address selection problem isn't so different >> between loc/id and other multiaddress solutions. It's just that in >> loc/id it isn't as vital to get it right as you can change your mind >> later. > It could be argued that the loc/id split is a form of multi-homing, > where the "id" is in fact a "virtual provider" address. It is possible > to use the distributed hash table technology to enable overlay routing > of these addresses, in which case the "virtual provider" is just > another > provider. That is one way of looking at it. And some discovery or negotiation methods may in fact need those vitual providers. From owner-multi6@ops.ietf.org Sun May 25 12:40:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05765 for ; Sun, 25 May 2003 12:40:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19JyWi-000FNB-00 for multi6-data@psg.com; Sun, 25 May 2003 16:39:16 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19JyWg-000FMG-00 for multi6@ops.ietf.org; Sun, 25 May 2003 16:39:14 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h4PGd3xS012069; Sun, 25 May 2003 18:39:03 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sun, 25 May 2003 18:38:05 +0200 Subject: Re: Two Prefixes in One Address (was: new draft) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Shane Kerr From: Iljitsch van Beijnum In-Reply-To: <20030522141237.GA7593@x17.ripe.net> Message-Id: <42864084-8ECF-11D7-9FEF-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-28.3 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On donderdag, mei 22, 2003, at 16:12 Europe/Amsterdam, Shane Kerr wrote: >> http://www.muada.com/drafts/draft-van-beijnum-multi6-2pi1a.txt > I had a read of your draft, and it's very nice. Thanks! > I have some specific comments: > Why specify "no more than 1 per minute" for ICMP packets? This seems > kind of arbritrary. The value is arbitrary, of course. What I want to do is make sure implementers don't just keep pinging to see if the other side is up. That would make for way too much control traffic and there are much smarter ways to do this. > Note that if you *required* some sort of KEEPALIVE on all locators > then it could help with poor middleboxes. :) Too bad for the poor middleboxes, let them earn their keep. (-: > What does "in the absense of better knowledge" mean? If the client knows one locator address is reachable and the other isn't, it should use the reachable address of course. But if it doesn't know, then it may as well use the last address used by the correspondent. This way the correspondent gets to prefer one of the incoming paths rather than have to depend on coin tosses elsewhere. > Again, if you required some sort of KEEPALIVE, then you could build an > RTT-style > mechanism into the protocol. I hate keepalives. See my exchanges with the SCTP people last year. This mechanism works at the IP layer, but I assume that if and when it's implemented, it will be integrated with TCP processing. Then it makes sense to keep RTT timing results for each virtual path. This could help the TCPs with choosing the best path, or even load balance the session over more than one path. But even without this it should be possible to get around periodic keepalives by simply monitoring what's going out and what's coming in. When a non-ACK packet has been sent out but nothing has come back for X seconds, then it makes sense to send a keepalive. But not when packets are flowing anyway. > I suggest that you recommend people *not* use the identifier address > as the regular address. It seems like a great potential source of > confusion. I think you're right. I had the idea that it might be possible to simply send packets and only bother with the multihoming thing when the session turns out to be long-lived, but that didn't make it in this draft so there is no advantage in making identifiers and the associated locators overlap. > It might be better for a multihomed-aware but single-homed client to > use the same information for locator 1 and locator 2? As in, "prefix > from ISP A" and "prefix from ISP B" are the same. No special handling > would be needed on the multihomed server side then - it can merely use > the same algorithm for all clients. True, but then non-multihomed clients also can't use autoconfiguration. Just setting the top byte to 0 or something like that doesn't entirely break autoconfiguration. > "Note that multihomed communication without involvement from the DNS > isnt' psossible." overstates the case, and not really pertinent. I > suggest removing it. The client needs the DNS to find locators for the server. So without the ability to query the DNS, multihomed communication isn't possible. We may be able to repair this by using something like "identifier+loc1+loc2+loc3" as the hostname, though. > I think there may be some security issue, in that a client can > generate packets to another client by sending a packet with the prefix > from a 3rd party in the multihomed client address. Haven't thought > too much about this.... Shouldn't be worse than regular spoofing. However, it does give clients a way to get around anti-spoofing filters to some degree so I guess this should go in the security considerations. Iljitsch From owner-multi6@ops.ietf.org Mon May 26 03:13:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04343 for ; Mon, 26 May 2003 03:13:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19KC8P-000GqB-00 for multi6-data@psg.com; Mon, 26 May 2003 07:11:05 +0000 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74]) by psg.com with esmtp (Exim 3.36 #1) id 19KC8N-000Gpz-00 for multi6@ops.ietf.org; Mon, 26 May 2003 07:11:03 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.9/8.10.2) with ESMTP id h4Q7B3Rp005636; Mon, 26 May 2003 09:11:04 +0200 (CEST) Date: Mon, 26 May 2003 09:11:02 +0200 Subject: Re: tunneling [Was: Agenda for Vienna] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Tim Chown From: Kurt Erik Lindqvist In-Reply-To: <20030522092336.GN20739@login.ecs.soton.ac.uk> Message-Id: <35942F56-8F49-11D7-857A-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-8.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > , so I shouldn't have used the R-word. The point is to focus on what > we can meaningfully do now to address certain scenarios, and what > (architecture-wise) we would like to work on longer term. > Multi-addressing > can be tackled now for some scenarios, in particular the SOHO/SME v6 > networks > which will account for a big chunk of all v6 networks. We have many > of the > pieces we need. In many cases I would assume that we even don't have to do anything, or very little for multiaddressing to work. AMS-IX are already running their services in this fashion.... > I don't see that it needs a spin-off WG, but if that gets us some focus > that we otherwise will not get in multi6, it's worth considering, in > which > case we'd want a BoF slot for a multi-addressing charter bashing in > Vienna. I seriously think that having multiple WGs working on the same problem is a mistake. > We have two sessions. Multi-addressing and loc/id seem to be the two > main > consensus topics to work on? > Yes. And I hope that we will have both discussed at the first session and then continue this at the second session (that is with focus on the architecture at the second session). - kurtis - From owner-multi6@ops.ietf.org Mon May 26 03:17:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04460 for ; Mon, 26 May 2003 03:17:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19KCEW-000IJf-00 for multi6-data@psg.com; Mon, 26 May 2003 07:17:24 +0000 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74]) by psg.com with esmtp (Exim 3.36 #1) id 19KCET-000IFg-00; Mon, 26 May 2003 07:17:21 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.9/8.10.2) with ESMTP id h4Q7HIRp005639; Mon, 26 May 2003 09:17:18 +0200 (CEST) Date: Mon, 26 May 2003 09:17:16 +0200 Subject: Re: Agenda for Vienna Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Randy Bush , multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200305221154.UAA06455@necom830.hpcl.titech.ac.jp> Message-Id: <14B9F012-8F4A-11D7-857A-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-14.1 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > For newer proposals, it is not so clear yet, at which level of > abstraction we will be expected to spend most of the time at > Vienna, even though I explicitely asked Kurt to clarify the target. The first session we have said that we want the submitted drafts to be presented briefly and then discussed. See this as a catalyst for further discussions in the hallways until the second session. For the second sessions we should concentrate on the architecture and the way forward. - kurtis - From owner-multi6@ops.ietf.org Tue May 27 08:37:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09985 for ; Tue, 27 May 2003 08:37:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19KdfD-0007u1-00 for multi6-data@psg.com; Tue, 27 May 2003 12:34:47 +0000 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 19Kdf9-0007ko-00 for multi6@ops.ietf.org; Tue, 27 May 2003 12:34:43 +0000 From: Masataka Ohta Message-Id: <200305271229.VAA05995@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id VAA05995; Tue, 27 May 2003 21:29:07 +0900 Subject: An architectural draft To: multi6@ops.ietf.org Date: Tue, 27 May 2003 21:29:04 +0859 () X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.7 required=5.0 tests=BAYES_30,MSG_ID_ADDED_BY_MTA_2 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Attached is a very rough draft ID on what can, or actually must, be changed with the current IPv6 specification. Masataka Ohta -- INTERNET DRAFT M. Ohta draft-ohta-sipa-00.txt Tokyo Institute of Technology May 2003 Simple Internet Protocol, Again Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract IPv6 has failed to be deployed partly because of its complexity. IPv6 mostly is a descendant of SIP (Simple Internet Protocol) but has fatally bloated merging with other proposals and trying to make IPv6 has better functionality than IPv4, which makes IPv6 unnecessarily complex and, thus, worse than IPv4. SIPA (Simple Internet Protocol, Again) is a proposal attempting to restore simplicity to IPv6 sticking to the real world operational requirements for the IPv4 Internet to make IPv6 more acceptable to ISPs and end users. 1. Introduction IPv6 has failed to be deployed partly because of its complexity. It is a complexity of not only coding but also operation. It should be noted that, even though running code may be widely available, it is not because IPv6 is so simple that implementors enjoyed coding M. Ohta Expires on November 25, 2003 [Page 1] INTERNET DRAFT Simple Internet Protocol, Again May 2003 (which was why, in good old days, running code principle was a good measure of protocol quality) but because governments and vendors put large amount of effort and money on it. Still, among so many IPv4 ISPs, few operate it and ratio of IPv6 end users to IPv4 ones are even smaller. Deployment is an operational issue and IPv6 has failed and will continue to be failing to be deployed. IPv6 mostly is a descendant of SIP (Simple Internet Protocol) but has fatally bloated merging with other proposals and trying to make IPv6 have better functionality than IPv4, which makes IPv6 unnecessarily complex and, thus, worse than IPv4. SIPA (Simple Internet Protocol, Again) is a proposal attempting to restore simplicity to IPv6 sticking to the real world operational requirements for the IPv4 Internet, to make IPv6 more acceptable to ISPs and end users. With SIPA, IPv6 should become easy to code and operate. In this memo, legacy IPv6 is called CIP (Complex IP), "the Internet" means one in the real world, that is, the IPv4 Internet, and a router is a host. 2. Requirements The original requirement for CIP was: Support large number of hosts large enough to make the IPv6 Internet for everyone. which resulted in bloated CIP. The followings are the additional requirements to SIPA based on the operational reality of the Internet. Suppress the number of global routing table entries even if everyone are multihomed to the IPv6 Internet. Make packet format compatible to CIP to make SIPA work over legacy routers. Remove all the features of CIP against the end to end principle. Remove all the features of CIP not present in IPv4. No applications on the Internet use them. M. Ohta Expires on November 25, 2003 [Page 2] INTERNET DRAFT Simple Internet Protocol, Again May 2003 Remove all the features of CIP not used in IPv4 Internet. No applications on the Internet use them. Remove all the features of CIP not useful in IPv4 Internet. No applications on the Internet need them. 3. Removed Features The following subsections list features of IPv6 removed to make IPv6 simpler and more deployable. 3.1 IP Header Options Optional headers are not used on the Internet and is forbidden. Except for an optional fragmentation header, which is used on the Internet, a transport header follows immediately after an IP header. Options visible to routers is a direct violation of the end to end principle and just harmful. Note that use of a routing header by MIPv6 is architecturally wrong, as a home agent is, like mail relays, an end system that it should be an destination option. In addition, except for a fragmentation header, destination option is still forbidden. It should be implemented at protocol (see section 3.3, for example) or transport level. 3.2 ToS & Flow Labels ToS & flow labels are forbidden. RSVP is far less deployed than IPv6. Even if it is deployed, removal of IP header options makes it easy for routers access port numbers or SPI (see section 3.3) that flow labels are not unnecessary. While the field for ToS & flow labels is large enough to hold fragmentation information (because MTU is large) not as an optional header, it makes SIPA not compatible to CIP. So, for possible future extension (such as that ECN is proven to be useful over the Internet), the field should contain 0 at the source and ignored by routers and the destination. 3.3 IPSEC ESP is purely optional and should be implemented as Protocol 50. SPI works as port numbers for resource reservation (if any). AH is forbidden because its functionality overridden by ESP and its SPI is M. Ohta Expires on November 25, 2003 [Page 3] INTERNET DRAFT Simple Internet Protocol, Again May 2003 not located at port number part. 3.4 Path MTU Discoverly Path MTU discoverly is forbidden. It often does not work over the Internet for various reasons. As the MTU of the Internet is mostly 1500 that minimum MTU of 1280 is good enough. Routers are encouraged to silently drop packets lager than 1280 byte without generating ICMP. 3.5 Stateless Autoconfiguration IPv6 specific stateless autoconfiguration is ignored. Use DHCP. All the possible autoconfiguration can be (and is already, for most of the case) implemented with DHCP over the Internet. The remaining autoconfiguration features may work in an isolated private LAN but is not meaningful over the Internet. Note, for example, that both dentists' offices and cars have preconfigured locks and keys. Issues on autoconfiguration in an isolated private LAN may still be solved, but in a way not affecting the development of the Internet protocol nor, hopefully, IETF. 3.6 Automatic Renumbering Automatic renumbering of IP addresses of DNS glue is ignored. On the Internet, automatic renumbering is trivially easy, as long as domain names, not raw IP addresses, are used to designate hosts. However, automatic renumbering of DNS glue is impossible, because relationship between DNS servers has nothing to do with ISP topology. 3.7 Hosts and Routers It is a direct violation of the end to end principle to assume intermediate systems intelligent and end systems dumb. Routers are hosts relay packets between multiple interfaces, thus, actively engages in generating routing tables. As has been the tradition of early days of the Internet, hosts with single interface are still expected to listen to IGP (e.g. routed -q). Note that DHCP can tell hosts which IGP to use. Note also that global routing table is assumed to be small. 3.8 Neighbor Discovery M. Ohta Expires on November 25, 2003 [Page 4] INTERNET DRAFT Simple Internet Protocol, Again May 2003 Neighbor discovery is not used on the Internet and is forbidden. It has hopelessly bloated, partly because of a failed attempt to support ATM (IPv6 thought multicast over ATM were easy) and partly because of another failed attempt to support stateless autoconfiguration. As for address resolution, the original purpose of ND, except for the last hop, address resolution information for next hop routers become available from IGP exchange. In other cases, use ARP or let hosts speak IGP. 3.9 Jumbograms Jumbograms are not used on the Internet and is forbidden. Super computers today are massively parallel ones that it has enough scalar power to handle streams of 64KB of packets. 3.10 Link & Site Local Address Link and site local address is not used on the Internet and is forbidden. Note that a network behind NAT is not a part of the Internet. One may still use NAT with IPv6, but it has nothing to do with IPv4 or IPv6 specification. 4. Other Restriction to CIP To ease implementations, a router can forward packets to the next hop by looking at upper 64 bits of an destination address only. Multicast address format should be reconsidered accordingly. A host can accept packets to it by looking at lower 64 bits of an destination address only. 5. Remaining Works Multi6 WG is working on site multihoming of IPv6, at least theoretically. However, as there can be limited number of ASes operated at TLAs, support for NLA level ASes multihomed to TLA level ASes must be discussed somewhere. Mobility must be tightly integrated with multihoming, as both treats multiple IP addresses of a host, that current specifications on MIPv6 must be ignored. 6. Security Considerations M. Ohta Expires on November 25, 2003 [Page 5] INTERNET DRAFT Simple Internet Protocol, Again May 2003 IPSEC sucks. 7. Author's Address Masataka Ohta Graduate School of Information Science and Engineering Tokyo Institute of Technology 2-12-1, O-okayama, Meguro-ku, Tokyo 152-8552, JAPAN Phone: +81-3-5734-3299 Fax: +81-3-5734-3299 EMail: mohta@necom830.hpcl.titech.ac.jp M. Ohta Expires on November 25, 2003 [Page 6] From owner-multi6@ops.ietf.org Tue May 27 09:42:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11320 for ; Tue, 27 May 2003 09:42:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Kehx-000NYn-00 for multi6-data@psg.com; Tue, 27 May 2003 13:41:41 +0000 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238]) by psg.com with esmtp (Exim 3.36 #1) id 19Kehv-000NYZ-00 for multi6@ops.ietf.org; Tue, 27 May 2003 13:41:39 +0000 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-5.de.ibm.com (8.12.9/8.12.8) with ESMTP id h4RDf1lr014358 for ; Tue, 27 May 2003 15:41:10 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h4RDcBCp149862 for ; Tue, 27 May 2003 15:38:13 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA34724 from ; Tue, 27 May 2003 15:38:09 +0200 Message-Id: <3ED36A5C.BD8D227A@hursley.ibm.com> Date: Tue, 27 May 2003 15:38:36 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: multi6@ops.ietf.org Subject: Re: An architectural draft References: <200305271229.VAA05995@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-8.1 required=5.0 tests=BAYES_30,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This document appears to be about 56 days late, or perhaps 309 days early. Ohta-san asserts that IPv6 will not be deployed in its present form. That isn't consistent with the evidence I see, and it isn't a relevant issue for multi6, which deals with IPv6 in its present form, as far as I can understand the charter. The detailed assertions in the draft are mainly wrong, but since they are irrelevant to multi6, I hope we will not waste bits here on them. Brian From owner-multi6@ops.ietf.org Tue May 27 09:59:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11808 for ; Tue, 27 May 2003 09:59:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Key9-0001Nw-00 for multi6-data@psg.com; Tue, 27 May 2003 13:58:25 +0000 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #1) id 19Kexz-0001M8-00 for multi6@ops.ietf.org; Tue, 27 May 2003 13:58:15 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id OAA21416 for ; Tue, 27 May 2003 14:58:04 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id OAA08727 for ; Tue, 27 May 2003 14:58:03 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h4RDw3K30212 for multi6@ops.ietf.org; Tue, 27 May 2003 14:58:03 +0100 Date: Tue, 27 May 2003 14:58:03 +0100 From: Tim Chown To: multi6@ops.ietf.org Subject: Re: An architectural draft Message-ID: <20030527135803.GL28716@login.ecs.soton.ac.uk> Mail-Followup-To: multi6@ops.ietf.org References: <200305271229.VAA05995@necom830.hpcl.titech.ac.jp> <3ED36A5C.BD8D227A@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3ED36A5C.BD8D227A@hursley.ibm.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-35.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, May 27, 2003 at 03:38:36PM +0200, Brian E Carpenter wrote: > This document appears to be about 56 days late, or perhaps 309 days early. Well, he could have suggested setting the RFC3514 Evil Bit on all of his "Complex IP" packets? :) But agreed for sure. Tim From owner-multi6@ops.ietf.org Tue May 27 17:27:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03205 for ; Tue, 27 May 2003 17:27:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Klx5-000BGU-00 for multi6-data@psg.com; Tue, 27 May 2003 21:25:47 +0000 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #1) id 19Klwt-000BG2-00 for multi6@ops.ietf.org; Tue, 27 May 2003 21:25:35 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 3844E34450; Tue, 27 May 2003 13:40:22 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h4RLPYYB028345; Tue, 27 May 2003 14:25:34 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: An architectural draft Date: Tue, 27 May 2003 14:25:33 -0700 Message-ID: Thread-Topic: An architectural draft Thread-Index: AcMkWeTAWozdoaLPQl6gO2SochtnUAAPG9rA From: "Tony Li" To: "Brian E Carpenter" , X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA03205 | This document appears to be about 56 days late, or perhaps | 309 days early. | | Ohta-san asserts that IPv6 will not be deployed in its | present form. That | isn't consistent with the evidence I see, and it isn't a | relevant issue for | multi6, which deals with IPv6 in its present form, as far as I can | understand the charter. | | The detailed assertions in the draft are mainly wrong, but | since they | are irrelevant to multi6, I hope we will not waste bits | here on them. Yes, but one has to truly appreciate and applaud the minimalist sentiment. And, IMHO, that's worth these few bits. ;-) Tony From owner-multi6@ops.ietf.org Tue May 27 17:37:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03629 for ; Tue, 27 May 2003 17:37:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Km8G-000FZD-00 for multi6-data@psg.com; Tue, 27 May 2003 21:37:20 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19Km89-000FYp-00 for multi6@ops.ietf.org; Tue, 27 May 2003 21:37:13 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h4RLb1xS016670; Tue, 27 May 2003 23:37:01 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 27 May 2003 23:36:06 +0200 Subject: Re: An architectural draft Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: "Tony Li" From: Iljitsch van Beijnum In-Reply-To: Message-Id: <38F5F468-908B-11D7-81E4-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-28.3 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On dinsdag, mei 27, 2003, at 23:25 Europe/Amsterdam, Tony Li wrote: > | The detailed assertions in the draft are mainly wrong, but > | since they are irrelevant to multi6, I hope we will not waste bits > | here on them. > Yes, but one has to truly appreciate and applaud the minimalist > sentiment. > And, IMHO, that's worth these few bits. ;-) And the security considerations section alone is worth these addtional bits. (-: From owner-multi6@ops.ietf.org Tue May 27 19:19:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08667 for ; Tue, 27 May 2003 19:19:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Knhf-000OGr-00 for multi6-data@psg.com; Tue, 27 May 2003 23:17:59 +0000 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 19Knhd-000OGf-00 for multi6@ops.ietf.org; Tue, 27 May 2003 23:17:57 +0000 From: Masataka Ohta Message-Id: <200305272308.IAA08717@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id IAA08717; Wed, 28 May 2003 08:08:32 +0900 Subject: RE: An architectural draft To: Tony.Li@procket.com (Tony Li) Date: Wed, 28 May 3 8:08:31 JST Cc: brian@hursley.ibm.com, multi6@ops.ietf.org In-Reply-To: ; from "Tony Li" at May 28, 103 6:32 am X-Mailer: ELM [version 2.3 PL11] X-Spam-Status: No, hits=-11.6 required=5.0 tests=BAYES_01,INVALID_DATE,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2, QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Tony; > | =20 > | The detailed assertions in the draft are mainly wrong, but=20 > | since they > | are irrelevant to multi6, I hope we will not waste bits=20 > | here on them. > > > Yes, but one has to truly appreciate and applaud the minimalist > sentiment. It is just based on an observation of the current Internet that designers, ISPs and end users of the IPv4 Internet should be appreciated and applauded for their minimalism. Masataka Ohta From owner-multi6@ops.ietf.org Tue May 27 19:19:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08686 for ; Tue, 27 May 2003 19:19:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19KnhO-000OBg-00 for multi6-data@psg.com; Tue, 27 May 2003 23:17:42 +0000 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 19KnhM-000OBO-00 for multi6@ops.ietf.org; Tue, 27 May 2003 23:17:40 +0000 From: Masataka Ohta Message-Id: <200305272302.IAA08684@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id IAA08684; Wed, 28 May 2003 08:02:16 +0900 Subject: Re: An architectural draft In-Reply-To: <3ED36A5C.BD8D227A@hursley.ibm.com> from Brian E Carpenter at "May 27, 2003 03:38:36 pm" To: Brian E Carpenter Date: Wed, 28 May 2003 08:02:15 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Brian; > This document appears to be about 56 days late, or perhaps 309 days early. Considering that IPv6 document is about 56 years late, or perhps 309 years early, maybe. For the next round to claim IPv6 is deployed? > Ohta-san asserts that IPv6 will not be deployed in its present form. That > isn't consistent with the evidence I see, Evidence? Note that it has been a stated that "IPv6 will be deployed in its present form. That is consistent with the evidence I see." for these 8 years. So, let's have a reality check. What evidence do you have? If you don't have it, as an evidence of deployment, how many end users, can you say, are using IPv6? > and it isn't a relevant issue for > multi6, which deals with IPv6 in its present form, as far as I can > understand the charter. No. We did discuss some changes. > The detailed assertions in the draft are mainly wrong, but since they > are irrelevant to multi6, I hope we will not waste bits here on them. Removal of autoconfiguration, for example, does affect multi6. As all the useless features of IPv6 have complex interrelationships, if you think some of the assertions are wrong, it's your turn to state so with evidences on the part you want to refute. Masataka Ohta From owner-multi6@ops.ietf.org Wed May 28 05:21:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22832 for ; Wed, 28 May 2003 05:21:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Kx6n-000CnN-00 for multi6-data@psg.com; Wed, 28 May 2003 09:20:33 +0000 Received: from tyo202.gate.nec.co.jp ([202.32.8.202]) by psg.com with esmtp (Exim 3.36 #1) id 19Kx6l-000CnA-00 for multi6@ops.ietf.org; Wed, 28 May 2003 09:20:31 +0000 Received: from mailgate3.nec.co.jp ([10.7.69.194]) by TYO202.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id h4S9KSS05950 for ; Wed, 28 May 2003 18:20:28 +0900 (JST) Received: from mailsv3.nec.co.jp (mailgate52.nec.co.jp [10.7.69.198]) by mailgate3.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id h4S9KRf14466 for ; Wed, 28 May 2003 18:20:27 +0900 (JST) Received: from togyo.jp.nec.com (togyo.jp.nec.com [10.26.220.4]) by mailsv3.nec.co.jp (8.11.6p2/3.7W-MAILSV4-NEC) with ESMTP id h4S9KQA23436 for ; Wed, 28 May 2003 18:20:26 +0900 (JST) Received: from [10.41.211.53] by mail.jp.nec.com with ESMTP; Wed, 28 May 2003 18:20:23 +0900 Date: Wed, 28 May 2003 18:20:21 +0900 From: Hiroki Ishibashi Subject: Re: An architectural draft To: multi6@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: TuruKame 2.83 (WinNT,500) Organization: NEC Corporation In-Reply-To: <200305271229.VAA05995@necom830.hpcl.titech.ac.jp> References: <200305271229.VAA05995@necom830.hpcl.titech.ac.jp> Message-Id: <7CC324FA5CA109bashi@ipv6.nec.co.jp> X-Spam-Status: No, hits=-25.2 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > >3.3 IPSEC > > ESP is purely optional and should be implemented as Protocol 50. SPI > works as port numbers for resource reservation (if any). AH is > forbidden because its functionality overridden by ESP and its SPI is > not located at port number part. If my understanding is correct, integrity check including IP header cannot be done with ESP. AH can do that. Hiroki Ishibashi From owner-multi6@ops.ietf.org Wed May 28 10:30:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06108 for ; Wed, 28 May 2003 10:30:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19L1uG-0008iM-00 for multi6-data@psg.com; Wed, 28 May 2003 14:27:56 +0000 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 19L1ty-0008hZ-00 for multi6@ops.ietf.org; Wed, 28 May 2003 14:27:38 +0000 From: Masataka Ohta Message-Id: <200305281418.XAA13444@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id XAA13444; Wed, 28 May 2003 23:18:40 +0900 Subject: Re: An architectural draft In-Reply-To: <7CC324FA5CA109bashi@ipv6.nec.co.jp> from Hiroki Ishibashi at "May 28, 2003 06:20:21 pm" To: Hiroki Ishibashi Date: Wed, 28 May 2003 23:18:39 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Ishibashi san; > >3.3 IPSEC > > > > ESP is purely optional and should be implemented as Protocol 50. SPI > > works as port numbers for resource reservation (if any). AH is > > forbidden because its functionality overridden by ESP and its SPI is > > not located at port number part. > > > If my understanding is correct, integrity check including IP header > cannot be done with ESP. AH can do that. An interesting point (on how IPSEC sucks). First, which part of IP header, do you want to check the integrity? Once a host receives a packet and delivers it to some application using SPI (which is why SPI is equivalent to port information), no information in IP header is no longer necessary and it is too late to check integrity of information in IP header. Note that, unlike CIP, SIPA does not have IP options which could have complex and unpredicatable interaction with IPSEC. Secondely, it is my understanding of IPSEC that, while a mandatory transform, DES-CBC, does not provide integrity check (involving IP headers), other transforms can. And, who use DES, these days? Masataka Ohta From owner-multi6@ops.ietf.org Wed May 28 10:50:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06864 for ; Wed, 28 May 2003 10:50:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19L2FK-0009pJ-00 for multi6-data@psg.com; Wed, 28 May 2003 14:49:42 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19L2FE-0009op-00 for multi6@ops.ietf.org; Wed, 28 May 2003 14:49:36 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h4SEnKxS018410; Wed, 28 May 2003 16:49:20 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 28 May 2003 16:48:15 +0200 Subject: Re: An architectural draft Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Masataka Ohta From: Iljitsch van Beijnum In-Reply-To: <200305281418.XAA13444@necom830.hpcl.titech.ac.jp> Message-Id: <69A25524-911B-11D7-9944-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-25.6 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On woensdag, mei 28, 2003, at 16:19 Europe/Amsterdam, Masataka Ohta wrote: >>> AH is >>> forbidden because its functionality overridden by ESP and its SPI >>> is >>> not located at port number part. >> If my understanding is correct, integrity check including IP header >> cannot be done with ESP. AH can do that. > First, which part of IP header, do you want to check the integrity? The source address is something I'd really like to check. When I get around to it, I plan to write a draft about how ISPs can do proxy IPsec AH processing for their customers to eliminate denial of service traffic. > Once a host receives a packet and delivers it to some application > using SPI (which is why SPI is equivalent to port information), no > information in IP header is no longer necessary and it is too > late to check integrity of information in IP header. That's why we do AH first and reject the packet if it doesn't check out. Applications are not involved in IPsec, that's the whole point. Otherwise you could just as well use TLS. From owner-multi6@ops.ietf.org Wed May 28 13:09:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12197 for ; Wed, 28 May 2003 13:09:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19L4Oo-000KBb-00 for multi6-data@psg.com; Wed, 28 May 2003 17:07:38 +0000 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by psg.com with esmtp (Exim 3.36 #1) id 19L4Of-000KB2-00 for multi6@ops.ietf.org; Wed, 28 May 2003 17:07:29 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id D2517A0F2; Wed, 28 May 2003 13:07:28 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Wed, 28 May 2003 13:07:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: An architectural draft Date: Wed, 28 May 2003 13:07:26 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B04284657@tayexc13.americas.cpqcorp.net> Thread-Topic: An architectural draft Thread-Index: AcMkXIE3WU1iPPPSTGeUazD0U16oOwA3x7tw From: "Bound, Jim" To: "Tim Chown" , X-OriginalArrivalTime: 28 May 2003 17:07:28.0810 (UTC) FILETIME=[9E7260A0:01C3253B] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA12197 I agree too. /jim > -----Original Message----- > From: Tim Chown [mailto:tjc@ecs.soton.ac.uk] > Sent: Tuesday, May 27, 2003 9:58 AM > To: multi6@ops.ietf.org > Subject: Re: An architectural draft > > > On Tue, May 27, 2003 at 03:38:36PM +0200, Brian E Carpenter wrote: > > This document appears to be about 56 days late, or perhaps 309 days > > early. > > Well, he could have suggested setting the RFC3514 Evil Bit on > all of his "Complex IP" packets? :) > > But agreed for sure. > > Tim > > From owner-multi6@ops.ietf.org Wed May 28 19:02:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28849 for ; Wed, 28 May 2003 19:02:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19L9ts-0006Cx-00 for multi6-data@psg.com; Wed, 28 May 2003 23:00:04 +0000 Received: from sj-core-1.cisco.com ([171.71.177.237]) by psg.com with esmtp (Exim 3.36 #1) id 19L9to-0006Bj-00 for multi6@ops.ietf.org; Wed, 28 May 2003 23:00:00 +0000 Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4SMxkFW008174; Wed, 28 May 2003 15:59:47 -0700 (PDT) Received: from cisco.com (dhcp-171-71-119-122.cisco.com [171.71.119.122]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA25325; Wed, 28 May 2003 15:59:46 -0700 (PDT) Message-ID: <3ED53F61.8090200@cisco.com> Date: Wed, 28 May 2003 15:59:45 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Masataka Ohta , multi6@ops.ietf.org Subject: Re: An architectural draft References: <69A25524-911B-11D7-9944-00039388672E@muada.com> In-Reply-To: <69A25524-911B-11D7-9944-00039388672E@muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-22.6 required=5.0 tests=BAYES_01,IN_REP_TO,REFERENCES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit When you say proxy AH do you mean the ISP actually creating the AH or just discarding invalid/bad AHs? Eliot From owner-multi6@ops.ietf.org Wed May 28 19:17:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29273 for ; Wed, 28 May 2003 19:17:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19LA8p-0008N2-00 for multi6-data@psg.com; Wed, 28 May 2003 23:15:31 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19LA8e-0008Mm-00 for multi6@ops.ietf.org; Wed, 28 May 2003 23:15:20 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h4SNF4xS019226; Thu, 29 May 2003 01:15:05 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 29 May 2003 01:14:01 +0200 Subject: Re: proxy AH (was: An architectural draft) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Eliot Lear From: Iljitsch van Beijnum In-Reply-To: <3ED53F61.8090200@cisco.com> Message-Id: <11490F84-9162-11D7-9944-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-25.6 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On donderdag, mei 29, 2003, at 00:59 Europe/Amsterdam, Eliot Lear wrote: > When you say proxy AH do you mean the ISP actually creating the AH or > just discarding invalid/bad AHs? The idea is that the customer gives to its correspondents a key to be used in calculating the authentication header. This key is derived from one of a small set of possible "master keys" combined with the correspondents source address. The master keys are communicated to the ISP (for instance by inserting them in a BGP attribute) so the ISP can calculate the key used for a packet and then check the authentication header. Then packets that don't have an AH or for which the AH check fails are severely rate limited while packets that pass the check can flow freely. When a key is abused the master keys are rotated and the abuser simply doesn't get a new key. This requires some serious hardware at the ISP side but it should get rid of DoS real good. The main problem is allowing control traffic in order to distribute the keys to the correspondents. Depending on whether we can/want to use unmodified IKE or not this should either be backward compatible or easy to fix, but probably not both. From owner-multi6@ops.ietf.org Thu May 29 01:30:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07654 for ; Thu, 29 May 2003 01:30:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19LFwx-0007kB-00 for multi6-data@psg.com; Thu, 29 May 2003 05:27:39 +0000 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 19LFwu-0007jw-00 for multi6@ops.ietf.org; Thu, 29 May 2003 05:27:36 +0000 From: Masataka Ohta Message-Id: <200305290521.OAA00485@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id OAA00485; Thu, 29 May 2003 14:20:52 +0859 Subject: Re: An architectural draft In-Reply-To: <69A25524-911B-11D7-9944-00039388672E@muada.com> from Iljitsch van Beijnum at "May 28, 2003 04:48:15 pm" To: Iljitsch van Beijnum Date: Thu, 29 May 2003 14:20:51 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-7.7 required=5.0 tests=BAYES_30,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Iljitsch; > >>> AH is > >>> forbidden because its functionality overridden by ESP and its SPI > >>> is > >>> not located at port number part. > > >> If my understanding is correct, integrity check including IP header > >> cannot be done with ESP. AH can do that. > > > First, which part of IP header, do you want to check the integrity? > > The source address is something I'd really like to check. You don't. If payload passes authentication check, the payload is considered to be reliable regardless of the source address. > When I get around to it, I plan to write a draft about how ISPs can do > proxy IPsec AH processing for their customers to eliminate denial of > service traffic. It is an utter violation of the end to end principle and assured not to scale, which, for example, means poor performance. In this case, a proxy box of an ISP is an easy victim of the DoS attack. The protection against DoS is to let distribute the load to end systems of ISP's customers. > > Once a host receives a packet and delivers it to some application > > using SPI (which is why SPI is equivalent to port information), no > > information in IP header is no longer necessary and it is too > > late to check integrity of information in IP header. > > That's why we do AH first and reject the packet if it doesn't check > out. Applications are not involved in IPsec, that's the whole point. > Otherwise you could just as well use TLS. I'm afraid you are assuming authentication check by ESP is much slower than that by AH. It is true that, in general, encryption/decryption is a little bit slower than authentication check. So, you don't gain so much, even if authentication by ESP is as slow as decryption. Moreover, it is possible to have an ESP transform which first performs authentication check and, only if the check is successful, decryption (or do nothing, if encryption is not necessary) that there is no difference. Note that, by trying to protect things which do not have to be protected, you can have an unmanagably complex multi6 solution. Masataka Ohta From owner-multi6@ops.ietf.org Thu May 29 01:48:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08026 for ; Thu, 29 May 2003 01:48:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19LGGN-0009Vd-00 for multi6-data@psg.com; Thu, 29 May 2003 05:47:43 +0000 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 19LGGL-0009UQ-00 for multi6@ops.ietf.org; Thu, 29 May 2003 05:47:41 +0000 From: Masataka Ohta Message-Id: <200305290538.OAA00591@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id OAA00591; Thu, 29 May 2003 14:38:07 +0900 Subject: Re: proxy AH (was: An architectural draft) In-Reply-To: <11490F84-9162-11D7-9944-00039388672E@muada.com> from Iljitsch van Beijnum at "May 29, 2003 01:14:01 am" To: Iljitsch van Beijnum Date: Thu, 29 May 2003 14:38:06 +0859 () CC: Eliot Lear , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-11.3 required=5.0 tests=BAYES_10,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Iljitsch; The only thing you can do against DoS is to detect its origin. Complex attempt of protection with larger number of components and more computation makes DoS more effective. > The master keys are communicated to the > ISP (for instance by inserting them in a BGP attribute) in plain text? > Then packets that don't have an AH or for which the AH check > fails are severely rate limited > This requires some serious hardware at the ISP side You are saying you must provide high performance hardware to get severely limited rate, even though there is no attackers, which is a lot worse than DoS. Masataka Ohta From owner-multi6@ops.ietf.org Thu May 29 04:09:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22596 for ; Thu, 29 May 2003 04:09:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19LIRk-000Nao-00 for multi6-data@psg.com; Thu, 29 May 2003 08:07:36 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19LIRh-000NaJ-00 for multi6@ops.ietf.org; Thu, 29 May 2003 08:07:33 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h4T87GxS020139; Thu, 29 May 2003 10:07:16 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 29 May 2003 10:06:11 +0200 Subject: Re: proxy AH (was: An architectural draft) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Masataka Ohta From: Iljitsch van Beijnum In-Reply-To: <200305290538.OAA00591@necom830.hpcl.titech.ac.jp> Message-Id: <6917422A-91AC-11D7-9B54-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-28.3 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Masataka, On donderdag, mei 29, 2003, at 07:21 Europe/Amsterdam, Masataka Ohta wrote: >> The source address is something I'd really like to check. > You don't. > If payload passes authentication check, the payload is considered > to be reliable regardless of the source address. Re the spam discussion on the IETF list: I'd rather know I'm dealing with a "good" source rather than check the content of everything I receive. >> When I get around to it, I plan to write a draft about how ISPs can do >> proxy IPsec AH processing for their customers to eliminate denial of >> service traffic. > It is an utter violation of the end to end principle and assured > not to scale, which, for example, means poor performance. Writeups of e2e that I've seen explicitly state that something that should be done end-to-end MAY also be done in the network as an optimization. As long as it's an optimization and not shifting of responsibility it's ok. I don't see why this shouldn't scale: 10 times more traffic means 10 times more crypto chips. O(n) scaling isn't that bad. > In this case, a proxy box of an ISP is an easy victim of the DoS > attack. Good luck DoSing a box that can do crypto at line rate. :-) Obviously DoSers can raise the stakes by trying to DoS (some part of) the ISP rather than the customer, but I'm not worried about that. ISPs typically have bandwidth in the order of gigabits, while customers may only have a few megabits. Flooding a 10 Mbps pipe is trivial, and done so often stopping it is a problem. Flooding a few 1 Gbps pipes is hard and should show up on the radar screens of even the most uncooperative source networks so stopping this is much, much easier. >> That's why we do AH first and reject the packet if it doesn't check >> out. Applications are not involved in IPsec, that's the whole point. >> Otherwise you could just as well use TLS. > I'm afraid you are assuming authentication check by ESP is much > slower than that by AH. No. What I'm saying is that porting all your applications to support SSL is much slower than porting your OS to support IPsec. On donderdag, mei 29, 2003, at 07:39 Europe/Amsterdam, Masataka Ohta wrote: > The only thing you can do against DoS is to detect its origin. That's why we make them get a key that only works for a single origin address and use that key in each packet. >> The master keys are communicated to the >> ISP (for instance by inserting them in a BGP attribute) > in plain text? Why not? Obviously the BGP attribute wouldn't be transitive, so the master keys would stay within the ISP network. >> This requires some serious hardware at the ISP side > You are saying you must provide high performance hardware to get > severely limited rate, even though there is no attackers, which > is a lot worse than DoS. ISPs would need enough of these boxes to easily handle the maximum expected DoS traffic. The system would only have to be enabled for a certain customer when the customer is under attack. But even if the system is enabled all the time there might be situations where the protection is worth the extra cost. Obviously this would be an extra value added service on top of regular IP transit, rather than a standard part of IP. From owner-multi6@ops.ietf.org Thu May 29 08:08:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29754 for ; Thu, 29 May 2003 08:08:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19LMC3-0004gc-00 for multi6-data@psg.com; Thu, 29 May 2003 12:07:39 +0000 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 19LMBz-0004eu-00 for multi6@ops.ietf.org; Thu, 29 May 2003 12:07:35 +0000 From: Masataka Ohta Message-Id: <200305291154.UAA02269@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id UAA02269; Thu, 29 May 2003 20:54:22 +0900 Subject: Simple Internet and The End to End Principle In-Reply-To: <6917422A-91AC-11D7-9B54-00039388672E@muada.com> from Iljitsch van Beijnum at "May 29, 2003 10:06:11 am" To: Iljitsch van Beijnum Date: Thu, 29 May 2003 20:54:21 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-11.9 required=5.0 tests=BAYES_10,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Iljitsch; Thank you for demonstrating how a simple "optimization" harms the Internet without really improving anything. > >> The source address is something I'd really like to check. > > > You don't. > > > If payload passes authentication check, the payload is considered > > to be reliable regardless of the source address. > > Re the spam discussion on the IETF list: I'd rather know I'm dealing > with a "good" source rather than check the content of everything I > receive. How can you check source without cheking the content? Note that ICV of AH is computed over both IP header and the conent. > >> When I get around to it, I plan to write a draft about how ISPs can do > >> proxy IPsec AH processing for their customers to eliminate denial of > >> service traffic. > > > It is an utter violation of the end to end principle and assured > > not to scale, which, for example, means poor performance. > > Writeups of e2e that I've seen explicitly state that something that > should be done end-to-end MAY also be done in the network as an > optimization. As long as it's an optimization and not shifting of > responsibility it's ok. The good source on the end to end principle is RFC1958, which is, thanks to Brian, very carefully worded. It does not state: "as long as it's an optimization and not shifting of responsibility it's ok". In the RFC, it is stated that: To quote from [Saltzer], "The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the endpoints of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.") So, it is assured to be "incomplete" and it is of course that hosts are expected to have the functionality. For example, TCP takes care of lost packets, though ethernet may perform local retransmission of packets lost in collision. > I don't see why this shouldn't scale: 10 times more traffic means 10 > times more crypto chips. O(n) scaling isn't that bad. The RFC continues as: This principle has important consequences if we require applications to survive partial network failures. An end-to-end protocol design should not rely on the maintenance of state (i.e. information about the state of the end-to-end communication) inside the network. Such state should be maintained only in the endpoints, in such a way that the state can only be destroyed when the endpoint itself breaks (known as fate-sharing). An immediate consequence of this is that datagrams are better than classical virtual circuits. and The network's job is to transmit datagrams as efficiently and flexibly as possible. Everything else should be done at the fringes. As you should know, common line rate today is 10G, because people want routers operate at the rate at which hardware can barely perform the simplest job of forwarding packets. > Good luck DoSing a box that can do crypto at line rate. :-) See above. :-) Note that a performance bottleneck is retrieval of SA. Now, the RFC also state: To perform its services, the network maintains some state information: routes, QoS guarantees that it makes, session information where that is used in header compression, compression histories for data compression, and the like. This state must be self-healing; adaptive procedures or protocols must exist to derive and maintain that state, and change it when the topology or activity of the network changes. and, what, do you think, will happen, if your AH use serial number and your site is multihomed? > > In this case, a proxy box of an ISP is an easy victim of the DoS > > attack. > > > Obviously DoSers can raise the stakes by trying to DoS (some part of) > the ISP rather than the customer, but I'm not worried about that. ISPs > typically have bandwidth in the order of gigabits, while customers may > only have a few megabits. Flooding a 10 Mbps pipe is trivial, and done > so often stopping it is a problem. Flooding a few 1 Gbps pipes is hard > and should show up on the radar screens of even the most uncooperative > source networks so stopping this is much, much easier. These days, it costs about $50 a month to have 100Mbps access, though ISP backbone is only as fast as 10G. > >> The master keys are communicated to the > >> ISP (for instance by inserting them in a BGP attribute) > > > in plain text? > > Why not? Obviously the BGP attribute wouldn't be transitive, so the > master keys would stay within the ISP network. Are you seriously saying that you distribute plain text keys to multiple ISPs you are conneted and can still feel safe? > >> This requires some serious hardware at the ISP side > > > You are saying you must provide high performance hardware to get > > severely limited rate, even though there is no attackers, which > > is a lot worse than DoS. > > ISPs would need enough of these boxes to easily handle the maximum > expected DoS traffic. The system would only have to be enabled for a > certain customer when the customer is under attack. Wrong. Another problem of your approach is that it is not local optimization. ISP or hosts at another end of the communication is involved, which can not be controlled by your ISP. On the other hand, a host naturally controls behaviour of its peer, which is why the end to end principle is great. > But even if the > system is enabled all the time there might be situations where the > protection is worth the extra cost. Obviously this would be an extra > value added service on top of regular IP transit, rather than a > standard part of IP. Again, it is not a local service. Another problem of non-local optimization is reduced MTU, which makes 1280B of packets from your host dropped somewhere in the Internet. And there should be a lot more. Masataka Ohta