From owner-multi6@ops.ietf.org Sun Jun 1 00:03: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 AAA19894 for ; Sun, 1 Jun 2003 00:03:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19MK0e-000Gpa-00 for multi6-data@psg.com; Sun, 01 Jun 2003 03:59:52 +0000 Received: from tomts16-srv.bellnexxia.net ([209.226.175.4]) by psg.com with esmtp (Exim 3.36 #1) id 19MK0c-000GpO-00 for multi6@ops.ietf.org; Sun, 01 Jun 2003 03:59:50 +0000 Received: from yahoo.com ([65.93.182.133]) by tomts16-srv.bellnexxia.net (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20030601035945.YSLP28839.tomts16-srv.bellnexxia.net@yahoo.com> for ; Sat, 31 May 2003 23:59:45 -0400 Date: Sat, 31 May 2003 23:59:39 -0400 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Fwd: [Ans-research] IRTF ANS Meeting Announcement From: S Woodside To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: <77A02011-93E5-11D7-8A63-000393414368@yahoo.com> X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-1.6 required=5.0 tests=BAYES_30,FORGED_YAHOO_RCVD,QUOTED_EMAIL_TEXT, RCVD_FAKE_HELO_DOTCOM,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'm curious if a large adhoc network would have special multihoming requirements that multi6 might consider? Put together, scalable adhoc networks with the ability to multihome in a decentralized manner would be a very desirable technology for building flexible wireless networks for last-mile (urban) / last 15 miles (rural) access. simon Begin forwarded message: > From: Elizabeth Belding-Royer > Date: Thu May 29, 2003 8:11:49 PM America/Montreal > To: ans-research@www1.ietf.org, manet@ietf.org > Cc: corson@flarion.com, ebelding@cs.ucsb.edu > Subject: [Ans-research] IRTF ANS Meeting Announcement > > Hi, > > The first meeting of the new IRTF Ad hoc Network Scalability (ANS) > research group will occur this Sunday at the Mobihoc conference > hotel. Included is the agenda for this meeting. This is a somewhat > fluid agenda as we are still finalizing the speakers. However, > the meeting will definitely start at 7pm Sunday evening. We look > forward to seeing many of you at the meeting. > > Scott and Elizabeth > > ***************************************************************** > > > Date: Sunday, June 1, 2003 > Time: 7-10pm > Location: Sheraton Barcelo Hotel (Mobihoc hotel) > I don't have the exact room at the moment - an email will be > sent later with that information. > > > Scott and Elizabeth (10 min) > - Welcome > - Overview of research group charter, objectives > > Scott and Elizabeth (30 min) > - Recap of mailing list discussion on direction of research group > - Group discussion on direction/objectives > > Presentations > > * Zygmunt Haas (20 min) > - Hybridization and Adaptivity as Means to Scalability > - Scalability Bounds in Wireless Networks > > * Joe Macker (15 min) > - Link state scaling approaches > > * Mario Gerla (15 min) > - Routing approaches and scalability metrics. > > * Radha Poovendran (15 min) > - Greedy Perimeter Routing > > * Christian Bettstetter (15 min) > - Interconnection of Ad hoc Networks to IPv6 Networks > > Open Forum for Discussions (1 hour) > > > > > _______________________________________________ > Ans-research mailing list > Ans-research@www1.ietf.org > https://www1.ietf.org/mailman/listinfo/ans-research > > -- anti-spam: do not post this address publicly www.simonwoodside.com -- 99% Devil, 1% Angel From owner-multi6@ops.ietf.org Sun Jun 1 02:12: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 CAA00827 for ; Sun, 1 Jun 2003 02:12:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19MM2g-000KxL-00 for multi6-data@psg.com; Sun, 01 Jun 2003 06:10:06 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19MM2d-000Kw7-00 for multi6@ops.ietf.org; Sun, 01 Jun 2003 06:10:03 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h5169wm10535; Sun, 1 Jun 2003 09:09:58 +0300 Date: Sun, 1 Jun 2003 09:09:57 +0300 (EEST) From: Pekka Savola To: S Woodside cc: multi6@ops.ietf.org Subject: Re: Fwd: [Ans-research] IRTF ANS Meeting Announcement In-Reply-To: <77A02011-93E5-11D7-8A63-000393414368@yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-28.2 required=5.0 tests=BAYES_20,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 Sat, 31 May 2003, S Woodside wrote: > I'm curious if a large adhoc network would have special multihoming > requirements that multi6 might consider? Put together, scalable adhoc > networks with the ability to multihome in a decentralized manner would > be a very desirable technology for building flexible wireless networks > for last-mile (urban) / last 15 miles (rural) access. Perhaps it would be best to first try to figure out how single-homed internet connectivity would work :-). But really, it's still a question on how you delegate the information about prefixes and choose your subnets. For the multihomed case with multiple PA prefixes, I guess this would mean that every MANET node would have a fixed, unique-in-the-MANET site identifier (or multiple of them). This could be used for delegating addresses and ensuring multiple nodes don't get weird ideas which parts of /48's they could use. > Begin forwarded message: > > > From: Elizabeth Belding-Royer > > Date: Thu May 29, 2003 8:11:49 PM America/Montreal > > To: ans-research@www1.ietf.org, manet@ietf.org > > Cc: corson@flarion.com, ebelding@cs.ucsb.edu > > Subject: [Ans-research] IRTF ANS Meeting Announcement > > > > Hi, > > > > The first meeting of the new IRTF Ad hoc Network Scalability (ANS) > > research group will occur this Sunday at the Mobihoc conference > > hotel. Included is the agenda for this meeting. This is a somewhat > > fluid agenda as we are still finalizing the speakers. However, > > the meeting will definitely start at 7pm Sunday evening. We look > > forward to seeing many of you at the meeting. > > > > Scott and Elizabeth > > > > ***************************************************************** > > > > > > Date: Sunday, June 1, 2003 > > Time: 7-10pm > > Location: Sheraton Barcelo Hotel (Mobihoc hotel) > > I don't have the exact room at the moment - an email will be > > sent later with that information. > > > > > > Scott and Elizabeth (10 min) > > - Welcome > > - Overview of research group charter, objectives > > > > Scott and Elizabeth (30 min) > > - Recap of mailing list discussion on direction of research group > > - Group discussion on direction/objectives > > > > Presentations > > > > * Zygmunt Haas (20 min) > > - Hybridization and Adaptivity as Means to Scalability > > - Scalability Bounds in Wireless Networks > > > > * Joe Macker (15 min) > > - Link state scaling approaches > > > > * Mario Gerla (15 min) > > - Routing approaches and scalability metrics. > > > > * Radha Poovendran (15 min) > > - Greedy Perimeter Routing > > > > * Christian Bettstetter (15 min) > > - Interconnection of Ad hoc Networks to IPv6 Networks > > > > Open Forum for Discussions (1 hour) > > > > > > > > > > _______________________________________________ > > Ans-research mailing list > > Ans-research@www1.ietf.org > > https://www1.ietf.org/mailman/listinfo/ans-research > > > > > > -- > anti-spam: do not post this address publicly > 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 Sun Jun 1 03:43: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 DAA01104 for ; Sun, 1 Jun 2003 03:43:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19MNTr-000Njy-00 for multi6-data@psg.com; Sun, 01 Jun 2003 07:42:15 +0000 Received: from tomts8.bellnexxia.net ([209.226.175.52] helo=tomts8-srv.bellnexxia.net) by psg.com with esmtp (Exim 3.36 #1) id 19MNTo-000Njl-00 for multi6@ops.ietf.org; Sun, 01 Jun 2003 07:42:12 +0000 Received: from yahoo.com ([65.93.185.91]) by tomts8-srv.bellnexxia.net (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20030601074208.SNJS9225.tomts8-srv.bellnexxia.net@yahoo.com>; Sun, 1 Jun 2003 03:42:08 -0400 Date: Sun, 1 Jun 2003 03:42:08 -0400 Subject: Re: [Ans-research] IRTF ANS Meeting Announcement 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: <8C4B98C8-9404-11D7-8128-000393414368@yahoo.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-22.0 required=5.0 tests=BAYES_10,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 Sunday, June 1, 2003, at 02:09 AM, Pekka Savola wrote: > On Sat, 31 May 2003, S Woodside wrote: >> I'm curious if a large adhoc network would have special multihoming >> requirements that multi6 might consider? Put together, scalable adhoc >> networks with the ability to multihome in a decentralized manner would >> be a very desirable technology for building flexible wireless networks >> for last-mile (urban) / last 15 miles (rural) access. > > Perhaps it would be best to first try to figure out how single-homed > internet connectivity would work :-). This is done, fortunately, for a small mesh at least. Unfortunately, the system uses centralized management to configure which (single) gateway each node uses (the system is meshAP, the management is called wiana). I don't think management is necessary though. AODV should be capable of handling single-homing by having the gateway node route all of the external packets. The existing adhoc protocol would handle the rest. > But really, it's still a question on how you delegate the information > about prefixes and choose your subnets. > > For the multihomed case with multiple PA prefixes, I guess this would > mean > that every MANET node would have a fixed, unique-in-the-MANET site > identifier (or multiple of them). This could be used for delegating > addresses and ensuring multiple nodes don't get weird ideas which > parts of > /48's they could use. Starting with a simplistic analysis, the nodes would not know the MANET is multihomed. The gateways could each all advertise the external network. It's possible that a MANEt protocol would be able to handle this, if it selects (for example) the first path that returns a route. In that case nodes would probably route to the outside through the closest gateway node. Or, the gateway nodes could discover each other and set up tunnels over the MANET to coordinate which sections of the external network they will each advertise in the MANET. That will add overhead and complexity. Or, I think what you're saying is, that each NODE would know about all of the gateways, and which prefix they have, and make its own decisions about which to use. That would require some additional information in the MANET protocol to essentially separate identity and locator, to allow multiple gateway nodes to advertise the same identities, but with different locators. (if I'm not totally confused. I just read RFC 2101) simon > >> Begin forwarded message: >> >>> From: Elizabeth Belding-Royer >>> Date: Thu May 29, 2003 8:11:49 PM America/Montreal >>> To: ans-research@www1.ietf.org, manet@ietf.org >>> Cc: corson@flarion.com, ebelding@cs.ucsb.edu >>> Subject: [Ans-research] IRTF ANS Meeting Announcement >>> >>> Hi, >>> >>> The first meeting of the new IRTF Ad hoc Network Scalability (ANS) >>> research group will occur this Sunday at the Mobihoc conference >>> hotel. Included is the agenda for this meeting. This is a somewhat >>> fluid agenda as we are still finalizing the speakers. However, >>> the meeting will definitely start at 7pm Sunday evening. We look >>> forward to seeing many of you at the meeting. >>> >>> Scott and Elizabeth >>> >>> ***************************************************************** >>> >>> >>> Date: Sunday, June 1, 2003 >>> Time: 7-10pm >>> Location: Sheraton Barcelo Hotel (Mobihoc hotel) >>> I don't have the exact room at the moment - an email will be >>> sent later with that information. >>> >>> >>> Scott and Elizabeth (10 min) >>> - Welcome >>> - Overview of research group charter, objectives >>> >>> Scott and Elizabeth (30 min) >>> - Recap of mailing list discussion on direction of research group >>> - Group discussion on direction/objectives >>> >>> Presentations >>> >>> * Zygmunt Haas (20 min) >>> - Hybridization and Adaptivity as Means to Scalability >>> - Scalability Bounds in Wireless Networks >>> >>> * Joe Macker (15 min) >>> - Link state scaling approaches >>> >>> * Mario Gerla (15 min) >>> - Routing approaches and scalability metrics. >>> >>> * Radha Poovendran (15 min) >>> - Greedy Perimeter Routing >>> >>> * Christian Bettstetter (15 min) >>> - Interconnection of Ad hoc Networks to IPv6 Networks >>> >>> Open Forum for Discussions (1 hour) >>> >>> >>> >>> -- www.simonwoodside.com -- 99% Devil, 1% Angel From owner-multi6@ops.ietf.org Sun Jun 1 15:37: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 PAA29996 for ; Sun, 1 Jun 2003 15:37:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19MYbj-000KnV-00 for multi6-data@psg.com; Sun, 01 Jun 2003 19:35:07 +0000 Received: from dhcp1.se.kurtis.pp.se ([195.43.225.70] helo=laptop2.local) by psg.com with esmtp (Exim 3.36 #1) id 19MYbg-000Kme-00 for multi6@ops.ietf.org; Sun, 01 Jun 2003 19:35:04 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.local (8.12.9/8.10.2) with ESMTP id h51JZALi001153 for ; Sun, 1 Jun 2003 21:35:10 +0200 (CEST) Date: Sun, 1 Jun 2003 21:35:06 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-27-1026979397" 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: <263CAA21-9468-11D7-8FD0-000393A638B2@kurtis.pp.se> X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-18.4 required=5.0 tests=BAYES_10,PGP_SIGNATURE_2,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 --Apple-Mail-27-1026979397 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Begin forwarded message: > From: Internet-Drafts Administrator > Date: fre maj 30, 2003 18:11:16 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 > > --Apple-Mail-27-1026979397 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-disposition: inline Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPtpVbaarNKXTPFCVEQKghwCg7gTMqEznS4biHzX/loFYivvaZesAn38c tYuCHt48CxYcyJOEo2fVU0Xp =xR9p -----END PGP SIGNATURE----- --Apple-Mail-27-1026979397-- From owner-multi6@ops.ietf.org Sun Jun 1 15:38: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 PAA00048 for ; Sun, 1 Jun 2003 15:38:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19MYbV-000KlP-00 for multi6-data@psg.com; Sun, 01 Jun 2003 19:34:53 +0000 Received: from dhcp1.se.kurtis.pp.se ([195.43.225.70] helo=laptop2.local) by psg.com with esmtp (Exim 3.36 #1) id 19MYbT-000Kl9-00 for multi6@ops.ietf.org; Sun, 01 Jun 2003 19:34:51 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.local (8.12.9/8.10.2) with ESMTP id h51JYuLi001150 for ; Sun, 1 Jun 2003 21:34:56 +0200 (CEST) Date: Sun, 1 Jun 2003 21:34:53 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-26-1026965706" Subject: Fwd: To the attention of all WG Chairs From: Kurt Erik Lindqvist To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: <1E11B895-9468-11D7-8FD0-000393A638B2@kurtis.pp.se> X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-14.2 required=5.0 tests=BAYES_30,PGP_SIGNATURE_2,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 --Apple-Mail-26-1026965706 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit If you haven't seen this. If you are planning to send something in with a short dead-line and you think it is really important to multi6, please contact me. - kurtis - Begin forwarded message: > From: Internet-Drafts Administrator > Date: fre maj 30, 2003 18:11:24 Europe/Stockholm > To: IETF-Announce: ; > Subject: To the attention of all WG Chairs > > > In order to process the many version 00 I-Ds that are received > before an IETF meeting in a timely manner, we ask that you send a LIST > OF > THE NAMES of the drafts you expect to have submitted and have approved > for > publication as WG documents to internet-drafts@ietf.org no later than > five > (5) business days prior to the cutoff date for the meeting. > > Please include the word "Permission" in the Subject field. > > This procedure will expedite the posting of version 00 I-Ds, > allowing > more time for review by the public. > > Thank you you for your cooperation in this matter. > > The IETF Secretariat > > FYI: All significant dates can be found at > http://www.ietf.org/meetings/cutoff_dates_57.html > --Apple-Mail-26-1026965706 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-disposition: inline Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPtpVX6arNKXTPFCVEQLXVwCggWjM+I9NJgC7sfkTGOBiMrJSrLMAoNS0 TSBue0Ta06ocT1NrOXwy7xaM =SL2M -----END PGP SIGNATURE----- --Apple-Mail-26-1026965706-- From owner-multi6@ops.ietf.org Wed Jun 11 15:55: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 PAA09004 for ; Wed, 11 Jun 2003 15:55:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19QBeh-000HPg-00 for multi6-data@psg.com; Wed, 11 Jun 2003 19:53:11 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19QBee-000HPK-00 for multi6@ops.ietf.org; Wed, 11 Jun 2003 19:53:09 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19QBec-000JTB-45 for multi6@ops.ietf.org; Thu, 12 Jun 2003 04:53:06 +0900 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 12 Jun 2003 04:53:05 +0900 To: multi6@ops.ietf.org Subject: RE: draft-ietf-multi6-multihoming-requirements-06.txt Message-Id: X-Spam-Status: No, hits=-1.6 required=5.0 tests=BAYES_30 version=2.53 X-Spam-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 An Ops-Dir reviewer had the appended comments. excuse the droll phrasing. any chance we could address them? randy --- Let's see: load balancing is not a realistic requirement. For the architecture to be automatic, we have to be dynamic and we've proven that we don't know how to do that yet. Even to give people some tools seems to lead to abuse. Who controls the balancing? The source? The destination? Don't say 'both'. No packet can serve two masters. Performance. Exact same arguments since the only way to affect performance is to load balance. Policy: so ill stated as to be meaningless. If this is a call for policy routing, that's fine, but it has nothing to do with multihoming. Simplicity: motherhood, apple pie and chevrolet. Transport survivability: Well, ok, but this is just a refinement of the redundancy requirement. How about we remove the redundant redundancy requirement? Compatible with DNS: meaningless Packet filtering: meaningless Scalability: see simplicity routers: create a new architecture, but don't change the routers, change the hosts hosts: create a new architecture, but don't change the hosts, change the routers Interaction between hosts & routers: tighter coupling between subsystems has never been an architectural good idea. So let's do that and change both. O&M: see pie, apple. multiple solutions: please don't give us one size fits all, that's not confusing enough security: don't break security Net: The real requirements are: - Provide multihoming - Provide scalable routing - Transport survivability From owner-multi6@ops.ietf.org Wed Jun 11 18:59: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 SAA08367 for ; Wed, 11 Jun 2003 18:59:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19QEWp-000PDu-00 for multi6-data@psg.com; Wed, 11 Jun 2003 22:57:15 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19QEWn-000PDD-00; Wed, 11 Jun 2003 22:57: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 h5BMusxS000416; Thu, 12 Jun 2003 00:56:54 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 12 Jun 2003 00:55:55 +0200 Subject: Re: draft-ietf-multi6-multihoming-requirements-06.txt 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: 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, jun 11, 2003, at 21:53 Europe/Amsterdam, Randy Bush wrote: > Let's see: load balancing is not a realistic requirement. For the > architecture to be automatic, we have to be dynamic and we've > proven that we don't know how to do that yet. Even to give people > some tools seems to lead to abuse. Who controls the balancing? > The source? The destination? Don't say 'both'. No packet can > serve two masters. No load balancing whatsoever means having a primary connection and a backup. For most multihomers paying for bandwidth you only get to use less than 1% of the time is a non-starter. > Performance. Exact same arguments since the only way to affect > performance is to load balance. Having a fast link, adding a slow one and having performance limited by the slow one is again unaccaptable. And it's not like providing some basic load balancing is a huge deal. A simple preference value for each of multiple AAAA records or some such would go a long way. > The real requirements are: > - Provide multihoming > - Provide scalable routing > - Transport survivability The real real requirement is: it must be good enough that people will want to trade in their IPv4 provider independent address space for this. If it isn't, either they'll stay in IPv4 or they'll take the IPv4 multihoming mess with them during the transition to IPv6. From owner-multi6@ops.ietf.org Thu Jun 12 02:14: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 CAA27177 for ; Thu, 12 Jun 2003 02:14:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19QLIh-000GJn-00 for multi6-data@psg.com; Thu, 12 Jun 2003 06:11:07 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19QLIf-000GJa-00; Thu, 12 Jun 2003 06:11:05 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h5C6AwR07292; Thu, 12 Jun 2003 09:10:58 +0300 Date: Thu, 12 Jun 2003 09:10:58 +0300 (EEST) From: Pekka Savola To: Iljitsch van Beijnum cc: Randy Bush , Subject: Re: draft-ietf-multi6-multihoming-requirements-06.txt 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, 12 Jun 2003, Iljitsch van Beijnum wrote: > On woensdag, jun 11, 2003, at 21:53 Europe/Amsterdam, Randy Bush wrote: > > > Let's see: load balancing is not a realistic requirement. For the > > architecture to be automatic, we have to be dynamic and we've > > proven that we don't know how to do that yet. Even to give people > > some tools seems to lead to abuse. Who controls the balancing? > > The source? The destination? Don't say 'both'. No packet can > > serve two masters. > > No load balancing whatsoever means having a primary connection and a > backup. For most multihomers paying for bandwidth you only get to use > less than 1% of the time is a non-starter. The real question was about *controlled, fine-grained* load balancing. That's entirely different than e.g. advertising identical prefix to two ISP's in an identical fashion. -- 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 Jun 12 03: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 DAA29063 for ; Thu, 12 Jun 2003 03:25:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19QMRQ-000J4v-00 for multi6-data@psg.com; Thu, 12 Jun 2003 07:24:12 +0000 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 19QMRM-000J4i-00 for multi6@ops.ietf.org; Thu, 12 Jun 2003 07:24: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 h5C7NgxS005895; Thu, 12 Jun 2003 09:23:42 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 12 Jun 2003 09:22:43 +0200 Subject: Re: draft-ietf-multi6-multihoming-requirements-06.txt 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: 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, jun 12, 2003, at 08:10 Europe/Amsterdam, Pekka Savola wrote: >> No load balancing whatsoever means having a primary connection and a >> backup. For most multihomers paying for bandwidth you only get to use >> less than 1% of the time is a non-starter. > The real question was about *controlled, fine-grained* load balancing. > That's entirely different than e.g. advertising identical prefix to two > ISP's in an identical fashion. Our anonymous friend seems opposed to any kind of load balancing: "Even to give people some tools seems to lead to abuse." The "abuse" we see today is mostly due to people wanting to prevent certain traffic from taking a certain route as long as there is full connectivity rather than trying to balance traffic over two or more connections. For the former you quickly arrive at announcing more specifics, for the latter this is seldom necessary. And also: "Who controls the balancing? The source? The destination? Don't say 'both'." This shows the author brings some assumptions to the table that don't hold up for load balancing in multihomed networks. Sure, if A and B are directly connected over two circuits and A prefers to use 1 while B wants to use 2, you have a problem. But with multihoming A's choice of the outgoing circuit doesn't automatically dictate B's incoming circuit. And even if it did, shifting the traffic where the other end doesn't care should be sufficient in most cases. From owner-multi6@ops.ietf.org Thu Jun 12 05:59: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 FAA02067 for ; Thu, 12 Jun 2003 05:59:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19QOpe-000OlP-00 for multi6-data@psg.com; Thu, 12 Jun 2003 09:57:22 +0000 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.36 #1) id 19QOpa-000OkP-00 for multi6@ops.ietf.org; Thu, 12 Jun 2003 09:57:18 +0000 Received: (qmail 75811 invoked by uid 0); 12 Jun 2003 09:57:16 -0000 Received: from localhost.automagic.org (HELO isc.org) (root@127.0.0.1) by localhost.automagic.org with SMTP; 12 Jun 2003 09:57:16 -0000 Date: Thu, 12 Jun 2003 12:58:49 +0300 Subject: Re: draft-ietf-multi6-multihoming-requirements-06.txt 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: Joe Abley In-Reply-To: Message-Id: <774108C2-9CBC-11D7-8780-00039312C852@isc.org> 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 On Wednesday, Jun 11, 2003, at 22:53 Africa/Kampala, Randy Bush quoted: > Let's see: load balancing is not a realistic requirement. For the > architecture to be automatic, we have to be dynamic and we've > proven that we don't know how to do that yet. For load balancing to be possible, the architecture does not need to be fully automatic. Load balancing is perfectly possible today using automatic mechanisms which are tuned manually. > Even to give people > some tools seems to lead to abuse. Some clarification on this sentence would be useful; I am struggling to understand it. > Who controls the balancing? > The source? The destination? Don't say 'both'. No packet can > serve two masters. If I am multi-homed, then I control the relative egress loading on my various transit circuits by managing my exit selection policies to choose exits which tend to balance traffic in a way that makes me happy. I control the relative ingress loading by supplying clues to my transit providers and thereby attempting to influence the exit selection policies of those transit providers, and so on for all inbound traffic through the chain of ASes which leads to its source. Both ingress and egress loading policies are necessarily malleable, since policy in external ASes and traffic demands vary and circuit sizes often do not. This is not a deterministic, calculable process, but it works sufficiently today that people do it. Removing the possiblity of load balancing means that N-way multi-homed ASes will suffer an increase in transit fees which approaches a factor of N, and this is not a reasonable compromise to expect people to make in the interests of architectural simplicity. Most of the world does not enjoy cheap external connectivity. > Performance. Exact same arguments since the only way to affect > performance is to load balance. In the context of current practices, the performance requirement is met by the ability of an AS to control its own exit selection policy. > Policy: so ill stated as to be meaningless. If this is a call > for policy routing, that's fine, but it has nothing to do with > multihoming. It is common practice in many ISPs to multi-home between a cheap, poorly-performing transit service and a more expensive, better-performing transit service (a common example is expensive terrestrial fibre vs. satellite). By arranging for batch, non-interactive traffic (mail, usenet, HTTP from pre-fetching web caches, FTP mirror updates, etc) to use the satellite service, there is more of the expensive-but-better capacity left for interactive services, and the quality of the user's experience is increased. In other ISPs, customers are able to buy multiple grades of service, corresponding to the quality of the transit used for their traffic (for some convenient definition of quality). Policy routing is one way to do this, but it assumes that the owner of the policy has administrative control of the router the other side of the satellite link (from the perspective of bandwidth-starved ISPs, problem traffic is inbound, not outbound). This is frequently not the case. Another approach is to bundle endpoints for batch traffic into particular netblocks which can be advertised in such a way that their inbound traffic comes exclusively over the satellite. In the v4 world this involves multihoming policy. In general, this requirement does not arrive unless the site is multihomed (since with only one transit path, there is no choice about shifting traffic according to protocol or other policy). The comment that this has nothing to do with multihoming is hence confusing. > Simplicity: motherhood, apple pie and chevrolet. Perhaps there is some cultural reference I am missing, since this means nothing to me. > Transport survivability: Well, ok, but this is just a refinement > of the redundancy requirement. How about we remove the redundant > redundancy > requirement? They are not requirements, they're goals. It is reasonable to assume that there will be multihoming architectures which do not meet all these goals (that, after all, is why we were unable to shift a draft without removing the "requirements" word). It is possible to gain protection for connectionless traffic in the case of single transit failure without providing protection for connection-oriented traffic. > Compatible with DNS: meaningless I will interpret "meaningless" as "I do not understand this, and request clarification". A multihoming solution which results in increased load on DNS servers by a factor of 10,000,000, or requires the behaviour of DNS servers to be modified (e.g. by requiring ordering of RRs in a reply to be modified according to source address for all multi-homed sites) is going to impose operational issues on the Internet. It does not seem an unreasonable goal to avoid such issues. > Packet filtering: meaningless Unicast RPF checks are commonly applied to external interfaces on ISP routers, and these filters demonstrably drop a lot of unwanted traffic. A multihoming architecture which prevented unwanted traffic from being dropped would result increased junk traffic being carried around the Internet. Similarly, to my comment above, it does not seem unreasonable to want to retain the capability to drop junk traffic at the ingress point of your network. > Scalability: see simplicity > > routers: create a new architecture, but don't change the routers, > change > the hosts The text says, in fact "the solutions may require changes to IPv6 router implementations". > hosts: create a new architecture, but don't change the hosts, change > the > routers The text says, in fact, "the solution should not destroy IPv6 connectivity for a legacy host implementing [list of RFCs]". It says nothing about not changing hosts. > Interaction between hosts & routers: tighter coupling between > subsystems > has never been an architectural good idea. So let's do that and change > both. I see no text which advocates tighter coupling between hosts and routers; I see text which does not require the coupling between hosts and routers to become looser. > O&M: see pie, apple. > > multiple solutions: please don't give us one size fits all, that's > not confusing enough In fact the text says "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". > security: don't break security If the anonymous observer thinks that the converse is more desirable, perhaps he or she could explain why. > Net: > The real requirements are: > > - Provide multihoming > - Provide scalable routing > - Transport survivability Summary: the goals that the anonymous critic finds important are covered by the draft. Other goals that the anonymous critic hasn't thought of, or doesn't find important, are also covered. Joe From owner-multi6@ops.ietf.org Thu Jun 12 08:23: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 IAA06657 for ; Thu, 12 Jun 2003 08:23:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19QR4v-0004P8-00 for multi6-data@psg.com; Thu, 12 Jun 2003 12:21:17 +0000 Received: from mx1out.umbc.edu ([130.85.25.10]) by psg.com with esmtp (Exim 3.36 #1) id 19QR4r-0004Om-00; Thu, 12 Jun 2003 12:21:13 +0000 Received: from irix2.gl.umbc.edu (guest@irix2.gl.umbc.edu [130.85.60.11]) by mx1out.umbc.edu (8.12.8/8.12.8/UMBC-Central 1.11 mxout 1.2.2.3 $) with ESMTP id h5CCL8vf016095; Thu, 12 Jun 2003 08:21:08 -0400 (EDT) Received: from localhost (vijay@localhost) by irix2.gl.umbc.edu (8.12.8/8.12.8) with ESMTP id h5CCL8aj3688501; Thu, 12 Jun 2003 08:21:08 -0400 (EDT) X-Authentication-Warning: irix2.gl.umbc.edu: vijay owned process doing -bs Date: Thu, 12 Jun 2003 08:21:08 -0400 From: Vijay Gill X-X-Sender: vijay@irix2.gl.umbc.edu To: Randy Bush cc: multi6@ops.ietf.org Subject: RE: draft-ietf-multi6-multihoming-requirements-06.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-AvMilter-Key: 1055420770:45178bdc9631da4d13736b6f427aac59 X-Avmilter: Message Skipped, too small X-Processed-By: MilterMonkey Version 0.9 -- http://www.membrain.com/miltermonkey X-Spam-Status: No, hits=-33.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE,X_AUTH_WARNING autolearn=ham version=2.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, 12 Jun 2003, Randy Bush wrote: > An Ops-Dir reviewer had the appended comments. excuse the droll > phrasing. any chance we could address them? > > randy > > --- > > Let's see: load balancing is not a realistic requirement. For the > architecture to be automatic, we have to be dynamic and we've > proven that we don't know how to do that yet. Even to give people > some tools seems to lead to abuse. Who controls the balancing? > The source? The destination? Don't say 'both'. No packet can > serve two masters. The load balancing does not have to be automagically done. For example, with the current mechanisms available to us in v4 + BGP, a large promising local dialup provider used to make extensive use of selective announcements, local preference, selective prepends etc to ensure that the traffic to its various transit providers was evenly balanced since most of the billing was done on the higher on in+out and so effectively there was the opportunity to optimize cost by moving someone's higher outbound to another provider who had a high inbound. > Performance. Exact same arguments since the only way to affect > performance is to load balance. I think this has been addressed in the satellite link for big bandwidth latency insensitive transactions (ftp, nntp) but terrestial links for interactive traffic example. > Policy: so ill stated as to be meaningless. If this is a call > for policy routing, that's fine, but it has nothing to do with > multihoming. see example above of cost optimizing using mechanisms available in the underlying protocols to move traffic around according to the policy "minimize cost" I think abley has covered the rest. /vijay From owner-multi6@ops.ietf.org Thu Jun 12 11:59: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 LAA16639 for ; Thu, 12 Jun 2003 11:59:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19QURs-000DGu-00 for multi6-data@psg.com; Thu, 12 Jun 2003 15:57:12 +0000 Received: from mail2.microsoft.com ([131.107.3.124]) by psg.com with esmtp (Exim 3.36 #1) id 19QURn-000DGf-00 for multi6@ops.ietf.org; Thu, 12 Jun 2003 15:57:07 +0000 Received: from mail5.microsoft.com ([157.54.6.156]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 12 Jun 2003 08:57:07 -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, 12 Jun 2003 08:57:07 -0700 Received: from 157.54.8.109 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 12 Jun 2003 08:57:06 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 12 Jun 2003 08:57:06 -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); Thu, 12 Jun 2003 08:56: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); Thu, 12 Jun 2003 08:57:05 -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: draft-ietf-multi6-multihoming-requirements-06.txt Date: Thu, 12 Jun 2003 08:57:04 -0700 Message-ID: Thread-Topic: draft-ietf-multi6-multihoming-requirements-06.txt Thread-Index: AcMwVUbY37TXtSf8SH6kLghvLCwoxgApUPCg From: "Christian Huitema" To: "Randy Bush" , X-OriginalArrivalTime: 12 Jun 2003 15:57:05.0542 (UTC) FILETIME=[45611260:01C330FB] 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 LAA16639 > Net: > The real requirements are: > > - Provide multihoming > - Provide scalable routing > - Transport survivability Randy, I don't believe that there is much disagreement between the anonymous reviewer and the rough consensus of the WG. IIRC, the "consensus assessment" of the WG it that this requirement document is a mixed bag of contradictory wishes, and cannot actually serve as a requirement spec in a "contractual" way. It is however mildly useful as a list of issues solution designers should be concerned with. It is also about as good as it is going to get, and we should move on. Maybe the IESG should paraphrase that in the application statement... -- Christian Huitema From owner-multi6@ops.ietf.org Thu Jun 12 12:52: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 MAA18400 for ; Thu, 12 Jun 2003 12:52:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19QVIz-000FZP-00 for multi6-data@psg.com; Thu, 12 Jun 2003 16:52:05 +0000 Received: from d12lmsgate-4.de.ibm.com ([194.196.100.237]) by psg.com with esmtp (Exim 3.36 #1) id 19QVIv-000FYz-00; Thu, 12 Jun 2003 16:52:02 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate-4.de.ibm.com (8.12.9/8.12.8) with ESMTP id h5CGpxZX027524; Thu, 12 Jun 2003 18:51:59 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h5CGpwt6215610; Thu, 12 Jun 2003 18:51:58 +0200 Received: from lig32-239-151-186.emea.lig-dial.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA62652 from ; Thu, 12 Jun 2003 18:51:56 +0200 Message-Id: <3EE8A4C9.90B41295@hursley.ibm.com> Date: Thu, 12 Jun 2003 18:05: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: Randy Bush Cc: multi6@ops.ietf.org Subject: Re: draft-ietf-multi6-multihoming-requirements-06.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Well, I'm not sure how to treat these comments as constructive. We know that there are conflicting goals here; that's exactly why the draft was downgraded from being a requirements document. I think the review is written from the viewpoint of a solution or class of solutions. The draft is written more from a utopic viewpoint. So I don't think most of the comments can actually be transformed into text changes. The best fix I can suggest is to take this sentence from the Abstract: > This document outlines a set of goals for proposed new IPv6 > site-multihoming architectures. and add to it something like It is recognized that this set of goals is ambitious and that some goals may conflict with others, and that the solution or solutions adopted will be able to satisfy only some of them. As to specifics, just one comment: > routers: create a new architecture, but don't change the routers, change > the hosts > > hosts: create a new architecture, but don't change the hosts, change the > routers That isn't what the text says. It is much more carefully written. It says make modular, backwards-compatible changes to both hosts and routers. People already shipping product tend to regard that as fundamental. Brian From owner-multi6@ops.ietf.org Thu Jun 12 17:21: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 RAA27482 for ; Thu, 12 Jun 2003 17:21:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19QZRb-0001ay-00 for multi6-data@psg.com; Thu, 12 Jun 2003 21:17:15 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19QZRY-0001ak-00; Thu, 12 Jun 2003 21:17:13 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19QZRX-0006Kt-8W; Fri, 13 Jun 2003 06:17:11 +0900 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 13 Jun 2003 06:17:10 +0900 To: "Christian Huitema" Cc: Subject: RE: draft-ietf-multi6-multihoming-requirements-06.txt References: 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 > I don't believe that there is much disagreement between the anonymous > reviewer and the rough consensus of the WG. IIRC, the "consensus > assessment" of the WG it that this requirement document is a mixed bag > of contradictory wishes, and cannot actually serve as a requirement spec > in a "contractual" way. It is however mildly useful as a list of issues > solution designers should be concerned with. It is also about as good as > it is going to get, and we should move on. Maybe the IESG should > paraphrase that in the application statement... how about cutting me a break and put that in the document. randy From owner-multi6@ops.ietf.org Thu Jun 12 17:24: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 RAA27548 for ; Thu, 12 Jun 2003 17:24:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19QZYQ-0001rL-00 for multi6-data@psg.com; Thu, 12 Jun 2003 21:24:18 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19QZYN-0001r6-00; Thu, 12 Jun 2003 21:24:16 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19QZYM-0006M0-BE; Fri, 13 Jun 2003 06:24:14 +0900 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 13 Jun 2003 06:24:13 +0900 To: Brian E Carpenter Cc: multi6@ops.ietf.org Subject: Re: draft-ietf-multi6-multihoming-requirements-06.txt References: <3EE8A4C9.90B41295@hursley.ibm.com> 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 > I think the review is written from the viewpoint of a solution > or class of solutions. The draft is written more from a utopic > viewpoint. So I don't think most of the comments can actually be > transformed into text changes. i think the fear is that solutions workers will hit "it does not meet requirement 14.3" > The best fix I can suggest is to take this sentence from the > Abstract: > >> This document outlines a set of goals for proposed new IPv6 >> site-multihoming architectures. > > and add to it something like > It is recognized that this set of goals is ambitious and that > some goals may conflict with others, and that the solution or > solutions adopted will be able to satisfy only some of them. works for me randy From owner-multi6@ops.ietf.org Thu Jun 12 18:38: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 SAA00351 for ; Thu, 12 Jun 2003 18:38:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19QahP-00058U-00 for multi6-data@psg.com; Thu, 12 Jun 2003 22:37:39 +0000 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.36 #1) id 19QahN-00058G-00 for multi6@ops.ietf.org; Thu, 12 Jun 2003 22:37:37 +0000 Received: (qmail 26603 invoked by uid 0); 12 Jun 2003 22:37:35 -0000 Received: from localhost.automagic.org (HELO isc.org) (root@127.0.0.1) by localhost.automagic.org with SMTP; 12 Jun 2003 22:37:35 -0000 Date: Fri, 13 Jun 2003 01:39:08 +0300 Subject: Re: draft-ietf-multi6-multihoming-requirements-06.txt 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: Randy Bush 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, Jun 13, 2003, at 00:24 Africa/Kampala, Randy Bush wrote: >> The best fix I can suggest is to take this sentence from the >> Abstract: >> >>> This document outlines a set of goals for proposed new IPv6 >>> site-multihoming architectures. >> >> and add to it something like >> It is recognized that this set of goals is ambitious and that >> some goals may conflict with others, and that the solution or >> solutions adopted will be able to satisfy only some of them. > > works for me I have added that sentence to the document's abstract. If now is the time to cut a -07, someone should let me know (otherwise I'll sit and wait). Joe From owner-multi6@ops.ietf.org Thu Jun 12 20:11: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 UAA02267 for ; Thu, 12 Jun 2003 20:11:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Qc83-00094e-00 for multi6-data@psg.com; Fri, 13 Jun 2003 00:09:15 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19Qc80-00093b-00; Fri, 13 Jun 2003 00:09:12 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19QbFx-0006SF-PP; Fri, 13 Jun 2003 08:13:21 +0900 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 13 Jun 2003 08:13:21 +0900 To: Joe Abley Cc: Brian E Carpenter , multi6@ops.ietf.org Subject: Re: draft-ietf-multi6-multihoming-requirements-06.txt References: 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 >>> The best fix I can suggest is to take this sentence from the >>> Abstract: >>> >>>> This document outlines a set of goals for proposed new IPv6 >>>> site-multihoming architectures. >>> >>> and add to it something like >>> It is recognized that this set of goals is ambitious and that >>> some goals may conflict with others, and that the solution or >>> solutions adopted will be able to satisfy only some of them. >> >> works for me > > I have added that sentence to the document's abstract. If now is the > time to cut a -07, someone should let me know (otherwise I'll sit and > wait). please cut it and i will put on iesg agenda randy From owner-multi6@ops.ietf.org Fri Jun 13 04:56: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 EAA25566 for ; Fri, 13 Jun 2003 04:56:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19QkJb-0000Zm-00 for multi6-data@psg.com; Fri, 13 Jun 2003 08:53:43 +0000 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.36 #1) id 19QkJW-0000ZT-00 for multi6@ops.ietf.org; Fri, 13 Jun 2003 08:53:38 +0000 Received: (qmail 67591 invoked by uid 0); 13 Jun 2003 08:53:32 -0000 Received: from localhost.automagic.org (HELO isc.org) (root@127.0.0.1) by localhost.automagic.org with SMTP; 13 Jun 2003 08:53:32 -0000 Date: Fri, 13 Jun 2003 11:54:56 +0300 Subject: Re: draft-ietf-multi6-multihoming-requirements-06.txt Content-Type: multipart/mixed; boundary=Apple-Mail-6--122114359 Mime-Version: 1.0 (Apple Message framework v552) Cc: Brian E Carpenter , multi6@ops.ietf.org To: Randy Bush From: Joe Abley In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-24.1 required=5.0 tests=BAYES_30,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 --Apple-Mail-6--122114359 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Friday, Jun 13, 2003, at 02:13 Africa/Kampala, Randy Bush wrote: >>>> The best fix I can suggest is to take this sentence from the >>>> Abstract: >>>> >>>>> This document outlines a set of goals for proposed new IPv6 >>>>> site-multihoming architectures. >>>> >>>> and add to it something like >>>> It is recognized that this set of goals is ambitious and that >>>> some goals may conflict with others, and that the solution or >>>> solutions adopted will be able to satisfy only some of them. >>> >>> works for me >> >> I have added that sentence to the document's abstract. If now is the >> time to cut a -07, someone should let me know (otherwise I'll sit and >> wait). > > please cut it and i will put on iesg agenda Done, sent to internet-drafts (authors, chairs, randy copied). Also attached below. Joe --Apple-Mail-6--122114359 Content-Disposition: attachment; filename=draft-ietf-multi6-multihoming-requirements-07.txt Content-Type: text/plain; x-unix-mode=0640; name="draft-ietf-multi6-multihoming-requirements-07.txt" Content-Transfer-Encoding: quoted-printable Network Working Group J. Abley Internet-Draft ISC Expires: December 12, 2003 B. Black Layer8 Networks V. Gill AOL Time Warner June 13, 2003 Goals for IPv6 Site-Multihoming Architectures draft-ietf-multi6-multihoming-requirements-07 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 December 12, 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. It is recognised that this set of goals is ambitious and that some goals may conflict with others. The solution or solutions adopted may only be able to satisfy some of the goals presented here. Abley, et al. Expires December 12, 2003 [Page 1] =0C Internet-Draft IPv6 Site-Multihoming Goals June 2003 1. Introduction 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 December 12, 2003 [Page 2] =0C Internet-Draft IPv6 Site-Multihoming Goals June 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 December 12, 2003 [Page 3] =0C Internet-Draft IPv6 Site-Multihoming Goals June 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 December 12, 2003 [Page 4] =0C Internet-Draft IPv6 Site-Multihoming Goals June 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 December 12, 2003 [Page 5] =0C Internet-Draft IPv6 Site-Multihoming Goals June 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 December 12, 2003 [Page 6] =0C Internet-Draft IPv6 Site-Multihoming Goals June 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 December 12, 2003 [Page 7] =0C Internet-Draft IPv6 Site-Multihoming Goals June 2003 Vijay Gill AOL Time Warner EMail: vijaygill9@aol.com Abley, et al. Expires December 12, 2003 [Page 8] =0C Internet-Draft IPv6 Site-Multihoming Goals June 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 December 12, 2003 [Page 9] =0C Internet-Draft IPv6 Site-Multihoming Goals June 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 December 12, 2003 [Page 10] =0C --Apple-Mail-6--122114359-- From owner-multi6@ops.ietf.org Sun Jun 15 09:37: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 JAA01458 for ; Sun, 15 Jun 2003 09:37:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19RXcn-000GcX-00 for multi6-data@psg.com; Sun, 15 Jun 2003 13:32:49 +0000 Received: from adsl-2-174.aland.net ([194.112.11.174] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 19RXcj-000Gc3-00 for multi6@ops.ietf.org; Sun, 15 Jun 2003 13:32: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 h5FDWoFT009626 for ; Sun, 15 Jun 2003 15:32:50 +0200 (CEST) Date: Sun, 15 Jun 2003 14:52:57 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=fixed Subject: Some notes before the WG meeting From: Kurt Erik Lindqvist To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: <49FD8066-9F30-11D7-8093-000393A638B2@kurtis.pp.se> X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-14.6 required=5.0 tests=BAYES_10,PGP_SIGNATURE,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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The following was mailed to the WG chairs mailinglist as suggested good hints for perhaps new WG members coming for the first time. As it is also a long time since the multi6 WG last met I though sending this out was a good thing : - - Newcomers can learn a lot ahead of time by reading the Tao of the IETF at . The newcomer orientation on Sunday (this year, at 1PM) is useful, but it is even more useful if they have read the Tao first. - - It is a good idea to at least skim the WG archives for the past four months before the meeting to help prevent rehashing items that have already been decided and to help focus on items that need more review. - - Similarly, it is a good idea to re-read the WG's charter before the meeting. Heck, many WG chairs could get value from this... - - Many IETF areas have area-wide meetings. People who are interested in more than just one WG can get a feel for what is happening in other areas by going to these meetings. - - The "Note Well" notice is serious. It can be found at , and will be given on paper in the registration packets. Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPuxsLKarNKXTPFCVEQKZhgCePvL4hBq8uAD74SGQMpENR1pGBIYAniIt ba4rEYAa3Y3a3JOldTUelp7D =6sKc -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Sun Jun 15 09:37: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 JAA01474 for ; Sun, 15 Jun 2003 09:37:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19RXcT-000Gbz-00 for multi6-data@psg.com; Sun, 15 Jun 2003 13:32:29 +0000 Received: from adsl-2-174.aland.net ([194.112.11.174] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 19RXcQ-000Gbn-00 for multi6@ops.ietf.org; Sun, 15 Jun 2003 13:32:26 +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 h5FDWPFT009620 for ; Sun, 15 Jun 2003 15:32:27 +0200 (CEST) Date: Sun, 15 Jun 2003 14:45:57 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=fixed Subject: Fwd: To the attention of all WG Chairs From: Kurt Erik Lindqvist To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: <4F6AB6F5-9F2F-11D7-8093-000393A638B2@kurtis.pp.se> X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-13.6 required=5.0 tests=BAYES_30,PGP_SIGNATURE,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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 If anyone are planning to publish a draft that they think will be of importance for the WG meetigns in Vienna please let me know. - - kurtis - Begin forwarded message: > From: Internet-Drafts Administrator > Date: fre jun 13, 2003 15:24:45 Europe/Stockholm > To: IETF-Announce: ; > Subject: To the attention of all WG Chairs > > > In order to process the many version 00 I-Ds that are received > before an IETF meeting in a timely manner, we ask that you send a LIST > OF > THE NAMES of the drafts you expect to have submitted and have approved > for > publication as WG documents to internet-drafts@ietf.org no later than > five > (5) business days prior to the cutoff date for the meeting. > > Please include the word "Permission" in the Subject field. > > This procedure will expedite the posting of version 00 I-Ds, > allowing > more time for review by the public. > > Thank you you for your cooperation in this matter. > > The IETF Secretariat > > FYI: All significant dates can be found at > http://www.ietf.org/meetings/cutoff_dates_57.html > -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPuxqh6arNKXTPFCVEQKiMACcCJGKGJCKcVXT1imJ7I0RrR/kKOoAmwQo HU6tqstZNGkhkiHCcRre42rI =o9a+ -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Sun Jun 15 13:31: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 NAA06175 for ; Sun, 15 Jun 2003 13:31:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19RbK6-000NlR-00 for multi6-data@psg.com; Sun, 15 Jun 2003 17:29:46 +0000 Received: from tomts7.bellnexxia.net ([209.226.175.40] helo=tomts7-srv.bellnexxia.net) by psg.com with esmtp (Exim 3.36 #1) id 19RbK4-000NlC-00 for multi6@ops.ietf.org; Sun, 15 Jun 2003 17:29:44 +0000 Received: from yahoo.com ([65.93.188.233]) by tomts7-srv.bellnexxia.net (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20030615172940.YAHK21156.tomts7-srv.bellnexxia.net@yahoo.com>; Sun, 15 Jun 2003 13:29:40 -0400 Date: Sun, 15 Jun 2003 13:29:41 -0400 Subject: Re: draft-ietf-multi6-multihoming-requirements-06.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org, Randy Bush To: Vijay Gill From: S Woodside In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-17.8 required=5.0 tests=BAYES_30,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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA06175 Preferably there would be a way to automatically load balance though. :-) (or at least it would be easy to set up even for a naïve user.) simon On Thursday, June 12, 2003, at 08:21 AM, Vijay Gill wrote: > The load balancing does not have to be automagically done. For example, > with the current mechanisms available to us in v4 + BGP, a large > promising > local dialup provider used to make extensive use of selective > announcements, local preference, selective prepends etc to ensure that > the > traffic to its various transit providers was evenly balanced since > most of > the billing was done on the higher on in+out and so effectively there > was > the opportunity to optimize cost by moving someone's higher outbound to > another provider who had a high inbound. > -- www.simonwoodside.com -- 99% Devil, 1% Angel From owner-multi6@ops.ietf.org Sun Jun 15 13:33: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 NAA06216 for ; Sun, 15 Jun 2003 13:33:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19RbNs-000Ntb-00 for multi6-data@psg.com; Sun, 15 Jun 2003 17:33:40 +0000 Received: from mx1out.umbc.edu ([130.85.25.10]) by psg.com with esmtp (Exim 3.36 #1) id 19RbNo-000NtP-00; Sun, 15 Jun 2003 17:33:36 +0000 Received: from irix2.gl.umbc.edu (guest@irix2.gl.umbc.edu [130.85.60.11]) by mx1out.umbc.edu (8.12.8/8.12.8/UMBC-Central 1.11 mxout 1.2.2.3 $) with ESMTP id h5FHXXvf028447; Sun, 15 Jun 2003 13:33:33 -0400 (EDT) Received: from localhost (vijay@localhost) by irix2.gl.umbc.edu (8.12.8/8.12.8) with ESMTP id h5FHXXsO106052; Sun, 15 Jun 2003 13:33:33 -0400 (EDT) X-Authentication-Warning: irix2.gl.umbc.edu: vijay owned process doing -bs Date: Sun, 15 Jun 2003 13:33:33 -0400 From: Vijay Gill X-X-Sender: vijay@irix2.gl.umbc.edu To: S Woodside cc: multi6@ops.ietf.org, Randy Bush Subject: Re: draft-ietf-multi6-multihoming-requirements-06.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN X-AvMilter-Key: 1055698715:52d057393dd439177c78a719df6f675b X-Avmilter: Message Skipped, too small X-Processed-By: MilterMonkey Version 0.9 -- http://www.membrain.com/miltermonkey X-Spam-Status: No, hits=-33.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE,X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-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 NAA06216 On Sun, 15 Jun 2003, S Woodside wrote: > Preferably there would be a way to automatically load balance though. > :-) (or at least it would be easy to set up even for a naïve user.) > I'd say that we do not have the control theory-fu necessary to make automagic loadbalancing work yet, so I'd leave that work for people smarter than I. /vijay From owner-multi6@ops.ietf.org Mon Jun 16 00:52: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 AAA19127 for ; Mon, 16 Jun 2003 00:52:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19RlwO-000JF1-00 for multi6-data@psg.com; Mon, 16 Jun 2003 04:50:00 +0000 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #1) id 19RlwM-000JEo-00 for multi6@ops.ietf.org; Mon, 16 Jun 2003 04:49:58 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 9E7FC3445C; Sun, 15 Jun 2003 21:05:11 -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 h5G4gPYB015550; Sun, 15 Jun 2003 21:42: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="iso-8859-1" Subject: RE: draft-ietf-multi6-multihoming-requirements-06.txt Date: Sun, 15 Jun 2003 21:42:25 -0700 Message-ID: Thread-Topic: draft-ietf-multi6-multihoming-requirements-06.txt Thread-Index: AcMzZVLVJh1rb1KOQOqCJyQYv0vGRwAXALGg From: "Tony Li" To: "Vijay Gill" , "S Woodside" Cc: , "Randy Bush" 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 AAA19127 | > Preferably there would be a way to automatically load | balance though. | > :-) (or at least it would be easy to set up even for a | naïve user.) | > | | I'd say that we do not have the control theory-fu necessary to make | automagic loadbalancing work yet, so I'd leave that work for people | smarter than I. I have to agree with Vijay here. We have yet to see a clean, practical, and scalable way to provide even static load balancing inbound or outbound. Thoughts on this more than welcome, tho probably don't belong in this WG (mebbe routing-discussion?). Doing dynamic load balancing really requires a demonstration of stability and I don't know of anyone who has made that work in a production setting. Tony From owner-multi6@ops.ietf.org Mon Jun 16 07:55: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 HAA09069 for ; Mon, 16 Jun 2003 07:55:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19RsYH-00054l-00 for multi6-data@psg.com; Mon, 16 Jun 2003 11:53:33 +0000 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 19RsYF-00054Z-00 for multi6@ops.ietf.org; Mon, 16 Jun 2003 11:53: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 h5GBrTtU021410; Mon, 16 Jun 2003 07:53:29 -0400 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id h5GBrSiS021409; Mon, 16 Jun 2003 07:53:28 -0400 Date: Mon, 16 Jun 2003 07:53:28 -0400 From: "J. Noel Chiappa" Message-Id: <200306161153.h5GBrSiS021409@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: draft-ietf-multi6-multihoming-requirements-06.txt Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.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: S Woodside > Preferably there would be a way to automatically load balance Load balancing is, fundamentally, a routing issue. You're selecting among one of several alternate paths. This is not a routing group, really - the basic consensus seems to be that we can't efficiently support lots-and-lots of multi-homing in the routing, and we're going to do it by having multiple addresses, and selecting among them. So you're asking in the wrong place. > (or at least it would be easy to set up even for a naove user.) You can do some load-balancing by ugly hacks like chosing addresses. However, I'm afraid your stated goal (load-balancing for idiots) is in fundamental conflict with one tool that people are currently using to do some load-balancing, i.e. address selection - address selection is tricky and doesn't work in all cases, and is therefore inappropriate for a "works for idiots" mechanism. Any general load-balancing scheme (i.e. one that would either work semi-automagically in all cases, or at least one that had a fairly smart user interface program that would take the user and lead them by the hand) would have to be i) based on routing, and ii) based on a routing architecture that's more powerful than the one we currently have deployed. At which point, see Figure 1. Noel From owner-multi6@ops.ietf.org Mon Jun 16 07:56: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 HAA09235 for ; Mon, 16 Jun 2003 07:56:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Rsb2-0005Dq-00 for multi6-data@psg.com; Mon, 16 Jun 2003 11:56:24 +0000 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 19Rsaz-0005Db-00 for multi6@ops.ietf.org; Mon, 16 Jun 2003 11:56:21 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09194; Mon, 16 Jun 2003 07:56:20 -0400 (EDT) Message-Id: <200306161156.HAA09194@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-07.txt Date: Mon, 16 Jun 2003 07:56:19 -0400 X-Spam-Status: No, hits=3.1 required=5.0 tests=MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Level: *** 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-07.txt Pages : 10 Date : 2003-6-13 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. It is recognised that this set of goals is ambitious and that some goals may conflict with others. The solution or solutions adopted may only be able to satisfy some of the goals presented here. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-multi6-multihoming-requirements-07.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-07.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-07.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-6-16080920.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-multi6-multihoming-requirements-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-multi6-multihoming-requirements-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-16080920.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-multi6@ops.ietf.org Mon Jun 16 13:27: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 NAA21633 for ; Mon, 16 Jun 2003 13:26:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Rxhe-000FjH-00 for multi6-data@psg.com; Mon, 16 Jun 2003 17:23:34 +0000 Received: from ran.psg.com ([209.20.253.166]) by psg.com with esmtp (Exim 3.36 #1) id 19Rxhc-000Fiu-00 for multi6@ops.ietf.org; Mon, 16 Jun 2003 17:23:32 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19Rxhb-000FYa-9Q for multi6@ops.ietf.org; Mon, 16 Jun 2003 10:23:31 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 16 Jun 2003 10:23:30 -0700 To: multi6@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-multi6-multihoming-requirements-07.txt References: <200306161156.HAA09194@ietf.org> Message-Id: X-Spam-Status: No, hits=-9.7 required=5.0 tests=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 > Title : Goals for IPv6 Site-Multihoming Architectures > Author(s) : J. Abley, B. Black, V. Gill > Filename : draft-ietf-multi6-multihoming-requirements-07.txt > Pages : 10 > Date : 2003-6-13 thanks! on iesg agenda for next week. randy From owner-multi6@ops.ietf.org Wed Jun 18 01:08: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 BAA23685 for ; Wed, 18 Jun 2003 01:08:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19SV8J-000Ffo-Vx for multi6-data@psg.com; Wed, 18 Jun 2003 05:05:19 +0000 Received: from [195.43.225.70] (helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 4.14) id 19SV8G-000Ffa-Vj for multi6@ops.ietf.org; Wed, 18 Jun 2003 05:05:17 +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 h5I55EFT012736 for ; Wed, 18 Jun 2003 07:05:14 +0200 (CEST) Date: Wed, 18 Jun 2003 07:05:10 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=fixed Subject: Design team announcement From: Kurt Erik Lindqvist To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: <6FC534EE-A14A-11D7-9791-000393A638B2@kurtis.pp.se> X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-11.3 required=5.0 tests=BAYES_20,PGP_SIGNATURE,UPPERCASE_25_50,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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, in a further effort to move the multi6 group (faster) forward, the chairs and the ADs have decided to form a design team (see http://ietf.org/IESG/STATEMENTS/Design-Teams.txt) to work on a proposal for a multihoming architecture. This team is chaired by Tony Li and other members are * Brian Carpenter * David Katz * Erik Nordmark * Iljitsch van Beijnum * Mike O'Dell * Pekka Savola * Sean Doran The goal is that the group will have something to report at the next WG meeting (the second session). Kurtis, Sean, Randy and Bert -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPu/zCKarNKXTPFCVEQL1ZACfUEpq1ikljNXyGzLT1LPaicyfvmEAn3lX K5FIdsENjMkwLzVJO42GJVyy =3g0K -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Wed Jun 18 03:34: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 DAA22658 for ; Wed, 18 Jun 2003 03:34:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19SXRX-000KRB-Q2 for multi6-data@psg.com; Wed, 18 Jun 2003 07:33:19 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 4.14) id 19SXRS-000KQz-Gp for multi6@ops.ietf.org; Wed, 18 Jun 2003 07:33:14 +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 h5I7XDFT012871 for ; Wed, 18 Jun 2003 09:33:13 +0200 (CEST) Date: Wed, 18 Jun 2003 09:33:06 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=fixed Subject: Call for presentations From: Kurt Erik Lindqvist To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: <1A243EFE-A15F-11D7-9791-000393A638B2@kurtis.pp.se> X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-14.2 required=5.0 tests=BAYES_01,PGP_SIGNATURE,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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 With this mail I would like to ask for presentations for the first slot of the multi6 WG. Please send me - - Presenters name - - Draft name - - Rough time estimate needed Again, please note that this is not supposed to be a in-depth presentation of your proposal (or multi6 related draft) it is supposed to be a opportunity to give an overview, make clarifications and ask questions. Best regrards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPvAVt6arNKXTPFCVEQIo3ACfRlGz6tAdi4teQWXLrrgELEFWo+AAoMlT SS/Ojtz+afDPu5qjRh48F7GH =1atC -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Wed Jun 18 04:29: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 EAA23726 for ; Wed, 18 Jun 2003 04:29:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19SYJ2-000M4v-Fd for multi6-data@psg.com; Wed, 18 Jun 2003 08:28:36 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.14) id 19SYIz-000M4j-Tg for multi6@ops.ietf.org; Wed, 18 Jun 2003 08:28:34 +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 h5I8THxS002850; Wed, 18 Jun 2003 10:29:17 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 18 Jun 2003 10:28:21 +0200 Subject: Re: To the attention of all WG Chairs 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: <4F6AB6F5-9F2F-11D7-8093-000393A638B2@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 zondag, jun 15, 2003, at 14:45 Europe/Amsterdam, Kurt Erik Lindqvist wrote: > If anyone are planning to publish a draft that they think will be of > importance for the WG meetigns in Vienna please let me know. I'll be sending in two or three drafts: - A new version of the provider internal thing. Previously, the addressing was a separate draft, I may include it now or maybe I'll keep this as a separate draft. - A slightly updated version of the "small" loc/id draft I wrote a little over a month ago I'm not going to pursue the work I started earlier on a "large" loc/id draft for a number of reasons. From owner-multi6@ops.ietf.org Wed Jun 18 05: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 FAA24692 for ; Wed, 18 Jun 2003 05:09:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19SYvV-000NMa-GK for multi6-data@psg.com; Wed, 18 Jun 2003 09:08:21 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 4.14) id 19SYvS-000NMI-Qc for multi6@ops.ietf.org; Wed, 18 Jun 2003 09:08:18 +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 h5I98CFT012886; Wed, 18 Jun 2003 11:08:12 +0200 (CEST) Date: Wed, 18 Jun 2003 11:08:08 +0200 Subject: Re: To the attention of all WG Chairs Content-Type: text/plain; charset=US-ASCII; format=fixed 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: <6107F758-A16C-11D7-9791-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-20.6 required=5.0 tests=BAYES_01,IN_REP_TO,PGP_SIGNATURE,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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> If anyone are planning to publish a draft that they think will be of >> importance for the WG meetigns in Vienna please let me know. > > I'll be sending in two or three drafts: > > - A new version of the provider internal thing. Previously, the > addressing was a separate draft, I may include it now or maybe I'll > keep this as a separate draft. > > - A slightly updated version of the "small" loc/id draft I wrote a > little over a month ago > If you want me to ask the secretariat to make sure it makes the cut-off date, I would need the document names. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPvAr+qarNKXTPFCVEQLgowCfUhpnSM4ni6gXO51kRbES6yVr2t4An2i7 z0BhWGrkI90iiqmK11zRY04W =2+ZF -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Wed Jun 18 05:35: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 FAA25208 for ; Wed, 18 Jun 2003 05:35:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19SZKX-000OAT-0U for multi6-data@psg.com; Wed, 18 Jun 2003 09:34:13 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19SZJW-000O8v-GD for multi6@ops.ietf.org; Wed, 18 Jun 2003 09:33:10 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h5I9WxN06354; Wed, 18 Jun 2003 12:32:59 +0300 Date: Wed, 18 Jun 2003 12:32:59 +0300 (EEST) From: Pekka Savola To: Kurt Erik Lindqvist cc: Iljitsch van Beijnum , Subject: Re: To the attention of all WG Chairs In-Reply-To: <6107F758-A16C-11D7-9791-000393A638B2@kurtis.pp.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-30.9 required=5.0 tests=BAYES_10,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, 18 Jun 2003, Kurt Erik Lindqvist wrote: > >> If anyone are planning to publish a draft that they think will be of > >> importance for the WG meetigns in Vienna please let me know. > > > > I'll be sending in two or three drafts: > > > > - A new version of the provider internal thing. Previously, the > > addressing was a separate draft, I may include it now or maybe I'll > > keep this as a separate draft. > > > > - A slightly updated version of the "small" loc/id draft I wrote a > > little over a month ago > > > > If you want me to ask the secretariat to make sure it makes the cut-off > date, I would need the document names. No, the document names aren't needed. They're only needed for draft-ietf-multi6-* submissions not draft-surname-*. Of course, when planning the agenda, having draft names would be beneficial, because it may not be apparent which drafts/ideas are being debated.. -- 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 Jun 18 11:21: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 LAA12218 for ; Wed, 18 Jun 2003 11:21:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19SejQ-000Dj9-Qz for multi6-data@psg.com; Wed, 18 Jun 2003 15:20:16 +0000 Received: from [128.255.204.16] (helo=seatpost.its.uiowa.edu) by psg.com with esmtp (Exim 4.14) id 19SejO-000Dip-5I for multi6@ops.ietf.org; Wed, 18 Jun 2003 15:20:14 +0000 Received: from jnford (helo=localhost) by seatpost.its.uiowa.edu with local-esmtp (Exim 3.36 #1 (Debian)) id 19SejH-00078G-00; Wed, 18 Jun 2003 10:20:07 -0500 Date: Wed, 18 Jun 2003 10:20:07 -0500 (CDT) From: Jay Ford X-X-Sender: jnford@seatpost.its.uiowa.edu Reply-To: Jay Ford To: "J. Noel Chiappa" cc: multi6@ops.ietf.org Subject: Re: draft-ietf-multi6-multihoming-requirements-06.txt In-Reply-To: <200306161153.h5GBrSiS021409@ginger.lcs.mit.edu> Message-ID: References: <200306161153.h5GBrSiS021409@ginger.lcs.mit.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-34.7 required=5.0 tests=BAYES_20,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 On Mon, 16 Jun 2003, J. Noel Chiappa wrote: > Load balancing is, fundamentally, a routing issue. You're selecting among one > of several alternate paths. > > This is not a routing group, really - the basic consensus seems to be that we > can't efficiently support lots-and-lots of multi-homing in the routing, and > we're going to do it by having multiple addresses, and selecting among them. > > So you're asking in the wrong place. > > > (or at least it would be easy to set up even for a naove user.) > > You can do some load-balancing by ugly hacks like chosing addresses. > > However, I'm afraid your stated goal (load-balancing for idiots) is in > fundamental conflict with one tool that people are currently using to do some > load-balancing, i.e. address selection - address selection is tricky and > doesn't work in all cases, and is therefore inappropriate for a "works for > idiots" mechanism. The problem I see is that (srcaddr,dstaddr) selection by a multihomed IPv6 host in the context of provider-based addressing can preempt the routing. That means that the loading will be determined by clueless edge hosts, which is about the worst place for such decisions to be made. This feels like a fundamental problem with the current direction of IPv6 deployment for which I haven't yet seen a solution (except possibly a beefed up version of the NAROS idea, which would effectively remove the address selection responsibility from the host). ________________________________________________________________________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-ford@uiowa.edu, phone: 319-335-5555, fax: 319-335-2951 From owner-multi6@ops.ietf.org Wed Jun 18 12:11: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 MAA14656 for ; Wed, 18 Jun 2003 12:11:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19SfWi-000FzK-LD for multi6-data@psg.com; Wed, 18 Jun 2003 16:11:12 +0000 Received: from [194.200.10.4] (helo=mxgw.highway.co.uk) by psg.com with esmtp (Exim 4.14) id 19SfWf-000Fyi-HY for multi6@ops.ietf.org; Wed, 18 Jun 2003 16:11:09 +0000 Received: from trigger.highway.co.uk (unknown [172.31.20.182]) by mxgw.highway.co.uk (Postfix) with ESMTP id 3C428180096 for ; Wed, 18 Jun 2003 17:15:48 +0100 (BST) Subject: DNS based Destination Selection From: David Gethings To: multi6@ops.ietf.org Content-Type: text/plain Message-Id: <1055952500.30027.12.camel@trigger.highway.co.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 18 Jun 2003 17:08:20 +0100 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_10,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, I understand that DNS based solutions to the IPv6 multihomed problem have been suggested before. However I believe my suggestion is a different variant to previous suggestions. Below is an overview of my suggestion. I believe it has merit and would like the groups view. Purpose The purpose of this idea is to use DNS as a means for a multihomed site to influence an external source's destination decision making. In that way the multihomed site can influence which of its ingress points traffic for a particular host will come in on. Summary Import MX priority values into AAAA and A6 records Assumptions That a multihomed site has a prefix provided by each transit provider Description of Operation A source wishes to get to a multihomed destination. When performing the DNS look up the source gets all the IP addresses that resolve to that hostname. Each IP address has a priority value attached to it (like MX records). If the source is compatible then the source used the IP address of the most preferred priority value. It then establishes a connection to that IP address. Where a host is not compatible then standard address selection is performed. In this instance the multihomed site preferrence (or policy) cannot be enforced. Where the source is compatible and receives multiple destination addresses with the same priority the source may determine (but some yet to be defined means) which IP address is preferred. The source then establishes a connection to that IP address. Problems Security wise this should introduce no new problems. It is no less secure than MX records The question is, is DNS the right place to do this? If not why not? Load balancing maybe a problem as it depends on implementation. Most of the expense is put on the multihomed site: it must manage multiple prefixes; manage the priority setting for hosts. Advantages Ensures the hierarchical nature of IPv6 stays intact Does not require any IP address rewriting, tunnelling or encapsulation Multihomed sites have a method of enforcing internal policy without using complicated routing policies The multihomed site does not require BGP routing Requirements The the DNS wg accept this idea and impliment. That hosts IPv6 stack be updated to take this into account Cheers Dg From owner-multi6@ops.ietf.org Wed Jun 18 12:32: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 MAA15345 for ; Wed, 18 Jun 2003 12:32:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Sfpv-000Gxj-5U for multi6-data@psg.com; Wed, 18 Jun 2003 16:31:03 +0000 Received: from [18.26.0.82] (helo=ginger.lcs.mit.edu) by psg.com with esmtp (Exim 4.14) id 19Sfps-000GxL-Dv for multi6@ops.ietf.org; Wed, 18 Jun 2003 16:31: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 h5IGUwtU004620; Wed, 18 Jun 2003 12:30:58 -0400 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id h5IGUws7004617; Wed, 18 Jun 2003 12:30:58 -0400 Date: Wed, 18 Jun 2003 12:30:58 -0400 From: "J. Noel Chiappa" Message-Id: <200306181630.h5IGUws7004617@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: draft-ietf-multi6-multihoming-requirements-06.txt 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: Jay Ford > The problem I see is that (srcaddr,dstaddr) selection by a multihomed > IPv6 host in the context of provider-based addressing can preempt the > routing. That means that the loading will be determined by clueless > edge hosts, which is about the worst place for such decisions to be made. First, I'm reminded of Churchill's famous line about democracy - about how it was the worst form of government, except for all the others. Similarly, having the edge-hosts make routing decisions seems like the worst place to do it - except for all the other choices! I don't understand why people get so worried about having the hosts be more involved in routing - but then perhaps my perspective helps me. E.g. way back when (i.e. the ARPANet), the network did congestion-avoidance, not the hosts, in part because "we have to protect the network and oh of course it's too complex for hosts to do". But having the network do it for the hosts turned out to have disadvantages. Now every host has very fancy congestion-avoidance algorithms in it, and it works fine, and everybody thinks its normal. Also, every human being (well, almost :-) is perfectly OK with the concept of hopping in their car/whatever and reading a map to get somewhere. It's not quantum mechanics, people. Second, you are right that (srcaddr,dstaddr) selection is something of a routing decision. However, making that choice more intelligently requires a far better routing architecture than the one we have now - one that is prepared to provide more information to hosts to allow them to make those choices. (See Figure 1.) Lacking that, flipping a virtual coin (perhaps a loaded one) is about as good as we're going to do... Noel From owner-multi6@ops.ietf.org Wed Jun 18 12:58: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 MAA16014 for ; Wed, 18 Jun 2003 12:58:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19SgG6-000Ieb-Du for multi6-data@psg.com; Wed, 18 Jun 2003 16:58:06 +0000 Received: from [128.255.204.16] (helo=seatpost.its.uiowa.edu) by psg.com with esmtp (Exim 4.14) id 19SgG3-000IeL-P3 for multi6@ops.ietf.org; Wed, 18 Jun 2003 16:58:03 +0000 Received: from jnford (helo=localhost) by seatpost.its.uiowa.edu with local-esmtp (Exim 3.36 #1 (Debian)) id 19SgG1-0007VF-00; Wed, 18 Jun 2003 11:58:01 -0500 Date: Wed, 18 Jun 2003 11:58:01 -0500 (CDT) From: Jay Ford X-X-Sender: jnford@seatpost.its.uiowa.edu Reply-To: Jay Ford To: David Gethings cc: multi6@ops.ietf.org Subject: Re: DNS based Destination Selection In-Reply-To: <1055952500.30027.12.camel@trigger.highway.co.uk> Message-ID: References: <1055952500.30027.12.camel@trigger.highway.co.uk> 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 On Wed, 18 Jun 2003, David Gethings wrote: > I understand that DNS based solutions to the IPv6 multihomed problem > have been suggested before. However I believe my suggestion is a > different variant to previous suggestions. > > Below is an overview of my suggestion. I believe it has merit and would > like the groups view. My quick reactions: o DNS is too high a level for (srcaddr,dstaddr) selection; not everything goes by name o DNS changes are difficult->impossible to get deployed globally o for some cases, relying on remotely-maintained DNS information is not sufficient or desirable o you cover dstaddr selection; what about srcaddr selection? ________________________________________________________________________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-ford@uiowa.edu, phone: 319-335-5555, fax: 319-335-2951 From owner-multi6@ops.ietf.org Wed Jun 18 13:07: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 NAA16455 for ; Wed, 18 Jun 2003 13:07:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19SgOX-000JLh-0e for multi6-data@psg.com; Wed, 18 Jun 2003 17:06:49 +0000 Received: from [128.255.204.16] (helo=seatpost.its.uiowa.edu) by psg.com with esmtp (Exim 4.14) id 19SgOU-000JLG-Ay for multi6@ops.ietf.org; Wed, 18 Jun 2003 17:06:46 +0000 Received: from jnford (helo=localhost) by seatpost.its.uiowa.edu with local-esmtp (Exim 3.36 #1 (Debian)) id 19SgOT-0007Z7-00; Wed, 18 Jun 2003 12:06:45 -0500 Date: Wed, 18 Jun 2003 12:06:45 -0500 (CDT) From: Jay Ford X-X-Sender: jnford@seatpost.its.uiowa.edu Reply-To: Jay Ford To: "J. Noel Chiappa" cc: multi6@ops.ietf.org Subject: Re: draft-ietf-multi6-multihoming-requirements-06.txt In-Reply-To: <200306181630.h5IGUws7004617@ginger.lcs.mit.edu> Message-ID: References: <200306181630.h5IGUws7004617@ginger.lcs.mit.edu> 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 On Wed, 18 Jun 2003, J. Noel Chiappa wrote: > First, I'm reminded of Churchill's famous line about democracy - about how it > was the worst form of government, except for all the others. Similarly, > having the edge-hosts make routing decisions seems like the worst place to do > it - except for all the other choices! > > I don't understand why people get so worried about having the hosts be more > involved in routing - but then perhaps my perspective helps me. E.g. way back > when (i.e. the ARPANet), the network did congestion-avoidance, not the hosts, > in part because "we have to protect the network and oh of course it's too > complex for hosts to do". But having the network do it for the hosts turned > out to have disadvantages. Now every host has very fancy congestion-avoidance > algorithms in it, and it works fine, and everybody thinks its normal. Also, > every human being (well, almost :-) is perfectly OK with the concept of > hopping in their car/whatever and reading a map to get somewhere. It's not > quantum mechanics, people. > > > Second, you are right that (srcaddr,dstaddr) selection is something of a > routing decision. However, making that choice more intelligently requires a > far better routing architecture than the one we have now - one that is > prepared to provide more information to hosts to allow them to make those > choices. (See Figure 1.) Lacking that, flipping a virtual coin (perhaps a > loaded one) is about as good as we're going to do... Call me a control freak, but I (as campus network routing guy) would like to get a little more determinism than is afforded by a virtual coin toss, even a weighted one. If the address selection must occur in the host, I at least want a hook to influence the selection process (for srcaddr *and* dstaddr). Also, what about the interaction between (srcaddr,dstaddr) selection & anti-spoofing-type filtering? The routers do the filtering, but the host does the address selection. How does that work? I don't want to have more spoofed attacks with IPv6 than we have now with IPv4. ________________________________________________________________________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-ford@uiowa.edu, phone: 319-335-5555, fax: 319-335-2951 From owner-multi6@ops.ietf.org Wed Jun 18 13:18: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 NAA16954 for ; Wed, 18 Jun 2003 13:18:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19SgYL-000Jtg-9z for multi6-data@psg.com; Wed, 18 Jun 2003 17:16:57 +0000 Received: from [171.68.223.137] (helo=sj-core-3.cisco.com) by psg.com with esmtp (Exim 4.14) id 19SgYI-000JrX-MG for multi6@ops.ietf.org; Wed, 18 Jun 2003 17:16:54 +0000 Received: from chuegen-sjcvpn-5.cisco.com (chuegen-sjcvpn-5.cisco.com [10.25.2.102]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h5IHGKTs013523; Wed, 18 Jun 2003 10:16:21 -0700 (PDT) Date: Wed, 18 Jun 2003 12:16:20 -0500 (Central Daylight Time) From: "Craig A. Huegen" To: Jay Ford cc: "J. Noel Chiappa" , Subject: Re: draft-ietf-multi6-multihoming-requirements-06.txt In-Reply-To: Message-ID: X-X-Sender: chuegen@chuegen-sun.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-22.0 required=5.0 tests=BAYES_01,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 Wed, 18 Jun 2003, Jay Ford wrote: > Call me a control freak, but I (as campus network routing guy) would like to > get a little more determinism than is afforded by a virtual coin toss, even a > weighted one. If the address selection must occur in the host, I at least > want a hook to influence the selection process (for srcaddr *and* dstaddr). There have been many similar comments (from myself as well) asserting your statement. It needs to be OS-independent as well, meaning that any device that speaks IPv6 should be able to follow my rules/hints for where traffic needs to go. Any solution without this should be deemed unacceptable. Network mechanisms *need* to have visibility into alternate paths for a particular destination so that the path selection can be chosen via policy. /cah -- Craig A. Huegen, Chief Network Architect C i s c o S y s t e m s IT Transport, Network Technology & Design || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen@cisco.com CCIE #2100 ..:||||||:..:||||||:.. From owner-multi6@ops.ietf.org Wed Jun 18 14:54: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 OAA21305 for ; Wed, 18 Jun 2003 14:54:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Si3Z-000OfL-Pz for multi6-data@psg.com; Wed, 18 Jun 2003 18:53:17 +0000 Received: from [209.226.175.35] (helo=tomts14-srv.bellnexxia.net) by psg.com with esmtp (Exim 4.14) id 19Si3X-000Oey-CM for multi6@ops.ietf.org; Wed, 18 Jun 2003 18:53:15 +0000 Received: from yahoo.com ([65.93.180.122]) by tomts14-srv.bellnexxia.net (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20030618185314.FMIL4044.tomts14-srv.bellnexxia.net@yahoo.com>; Wed, 18 Jun 2003 14:53:14 -0400 Date: Wed, 18 Jun 2003 14:53:12 -0400 Subject: Re: draft-ietf-multi6-multihoming-requirements-06.txt 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: S Woodside In-Reply-To: <200306181630.h5IGUws7004617@ginger.lcs.mit.edu> Message-Id: <1C901E4A-A1BE-11D7-84BB-000393414368@yahoo.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-17.7 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,FORGED_YAHOO_RCVD,IN_REP_TO, QUOTED_EMAIL_TEXT,RCVD_FAKE_HELO_DOTCOM,RCVD_IN_DSBL, 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, June 18, 2003, at 12:30 PM, J. Noel Chiappa wrote: > Second, you are right that (srcaddr,dstaddr) selection is something of > a > routing decision. However, making that choice more intelligently > requires a > far better routing architecture than the one we have now - one that is > prepared to provide more information to hosts to allow them to make > those > choices. (See Figure 1.) Lacking that, flipping a virtual coin > (perhaps a > loaded one) is about as good as we're going to do... If that's the routing problem that you mean, it's I think a situation where any improvement is better than the current situation where there is no auto-configure solution. The typical home DSL user, who knows enough to link to their neighbour with a Wi-Fi box but doesn't know routing, would still see (up to) a doubling of throughput. simon -- www.simonwoodside.com -- 99% Devil, 1% Angel From owner-multi6@ops.ietf.org Wed Jun 18 14:58: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 OAA21762 for ; Wed, 18 Jun 2003 14:58:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Si7a-000Oy5-6o for multi6-data@psg.com; Wed, 18 Jun 2003 18:57:26 +0000 Received: from [209.226.175.35] (helo=tomts14-srv.bellnexxia.net) by psg.com with esmtp (Exim 4.14) id 19Si7W-000Oxo-W3 for multi6@ops.ietf.org; Wed, 18 Jun 2003 18:57:23 +0000 Received: from yahoo.com ([65.93.180.122]) by tomts14-srv.bellnexxia.net (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20030618185722.FRAM4044.tomts14-srv.bellnexxia.net@yahoo.com>; Wed, 18 Jun 2003 14:57:22 -0400 Date: Wed, 18 Jun 2003 14:57:22 -0400 Subject: Re: draft-ietf-multi6-multihoming-requirements-06.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Craig A. Huegen" From: S Woodside In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-18.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,FORGED_YAHOO_RCVD,IN_REP_TO, QUOTED_EMAIL_TEXT,RCVD_FAKE_HELO_DOTCOM,RCVD_IN_DSBL, 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 understand what you are saying, however, what about the opposite end, is there a need to /always/ have management of path selection? simon On Wednesday, June 18, 2003, at 01:16 PM, Craig A. Huegen wrote: > Network mechanisms *need* to have visibility into alternate paths for a > particular destination so that the path selection can be chosen via > policy. > -- www.simonwoodside.com -- 99% Devil, 1% Angel From owner-multi6@ops.ietf.org Wed Jun 18 15: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 PAA24277 for ; Wed, 18 Jun 2003 15:25:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19SiXt-0000TV-MI for multi6-data@psg.com; Wed, 18 Jun 2003 19:24:37 +0000 Received: from [128.255.204.16] (helo=seatpost.its.uiowa.edu) by psg.com with esmtp (Exim 4.14) id 19SiXq-0000TE-GX for multi6@ops.ietf.org; Wed, 18 Jun 2003 19:24:34 +0000 Received: from jnford (helo=localhost) by seatpost.its.uiowa.edu with local-esmtp (Exim 3.36 #1 (Debian)) id 19SiXm-00086V-00; Wed, 18 Jun 2003 14:24:30 -0500 Date: Wed, 18 Jun 2003 14:24:30 -0500 (CDT) From: Jay Ford X-X-Sender: jnford@seatpost.its.uiowa.edu Reply-To: Jay Ford To: "Craig A. Huegen" , S Woodside cc: multi6@ops.ietf.org Subject: Re: draft-ietf-multi6-multihoming-requirements-06.txt 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 On Wed, 18 Jun 2003, Craig A. Huegen wrote: > > Call me a control freak, but I (as campus network routing guy) would like > > to get a little more determinism than is afforded by a virtual coin toss, > > even a weighted one. If the address selection must occur in the host, I > > at least want a hook to influence the selection process (for srcaddr > > *and* dstaddr). > > There have been many similar comments (from myself as well) asserting > your statement. It needs to be OS-independent as well, meaning that any > device that speaks IPv6 should be able to follow my rules/hints for where > traffic needs to go. Any solution without this should be deemed > unacceptable. Agreed. > Network mechanisms *need* to have visibility into alternate paths for a > particular destination so that the path selection can be chosen via > policy. Exactly. Note that the (srcaddr,dstaddr) tuple has to be chosen as a unit for a particular path in order to avoid trouble with (e.g. anti-spoofing) filtering. On Wed, 18 Jun 2003, S Woodside wrote: } I understand what you are saying, however, what about the opposite end, Is asymmetry more of an issue in IPv6 than with IPv4? (I'm really asking. It might be.) } is there a need to /always/ have management of path selection? I'm arguing that there is always a need to have the /option/ of managing the path selection. The option might not always have to be used, but if we don't build in the option now, it won't be there when needed. ________________________________________________________________________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-ford@uiowa.edu, phone: 319-335-5555, fax: 319-335-2951 From owner-multi6@ops.ietf.org Thu Jun 19 01:13: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 BAA16131 for ; Thu, 19 Jun 2003 01:13:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Srha-000PpM-Uj for multi6-data@psg.com; Thu, 19 Jun 2003 05:11:14 +0000 Received: from [209.226.175.35] (helo=tomts14-srv.bellnexxia.net) by psg.com with esmtp (Exim 4.14) id 19SrhY-000PpA-Kn for multi6@ops.ietf.org; Thu, 19 Jun 2003 05:11:12 +0000 Received: from yahoo.com ([65.93.186.123]) by tomts14-srv.bellnexxia.net (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20030619051111.YPAL4044.tomts14-srv.bellnexxia.net@yahoo.com>; Thu, 19 Jun 2003 01:11:11 -0400 Date: Thu, 19 Jun 2003 01:11:10 -0400 Subject: Re: draft-ietf-multi6-multihoming-requirements-06.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: Jay Ford From: S Woodside In-Reply-To: Message-Id: <70978BC0-A214-11D7-84BB-000393414368@yahoo.com> 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA16131 On Wednesday, June 18, 2003, at 03:24 PM, Jay Ford wrote: > On Wed, 18 Jun 2003, S Woodside wrote: > } is there a need to /always/ have management of path selection? > > I'm arguing that there is always a need to have the /option/ of > managing the > path selection. The option might not always have to be used, but if > we don't > build in the option now, it won't be there when needed. OK. That's good, because then it's possible to satisfy the naïve user with a system that allows NO management of path selection, and will "just work" (auto-configure). simon From owner-multi6@ops.ietf.org Thu Jun 19 02: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 CAA29046 for ; Thu, 19 Jun 2003 02:11:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Sscz-00029R-7F for multi6-data@psg.com; Thu, 19 Jun 2003 06:10:33 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19Sscw-00029E-GI for multi6@ops.ietf.org; Thu, 19 Jun 2003 06:10:30 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h5J6AOY15340; Thu, 19 Jun 2003 09:10:24 +0300 Date: Thu, 19 Jun 2003 09:10:23 +0300 (EEST) From: Pekka Savola To: Jay Ford cc: "J. Noel Chiappa" , Subject: Re: draft-ietf-multi6-multihoming-requirements-06.txt 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, 18 Jun 2003, Jay Ford wrote: > Call me a control freak, but I (as campus network routing guy) would like to > get a little more determinism than is afforded by a virtual coin toss, even a > weighted one. If the address selection must occur in the host, I at least > want a hook to influence the selection process (for srcaddr *and* dstaddr). What is the number of the destinations you typically want to influence the selection process? Note that if it's a rather small one, this one: Default Router Preferences, More-Specific Routes, and Load Sharing draft-ietf-ipv6-router-selection-02.txt might help you a bit. > Also, what about the interaction between (srcaddr,dstaddr) selection & > anti-spoofing-type filtering? The routers do the filtering, but the host > does the address selection. How does that work? I don't want to have more > spoofed attacks with IPv6 than we have now with IPv4. At the moment, there is no interaction. The routers have to allow both. But that's one field that in particular should be worked at. -- 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 Jun 19 02:25: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 CAA00770 for ; Thu, 19 Jun 2003 02:25:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Ssql-0002eS-4U for multi6-data@psg.com; Thu, 19 Jun 2003 06:24:47 +0000 Received: from [130.104.229.109] (helo=info.ucl.ac.be) by psg.com with esmtp (Exim 4.14) id 19Ssqh-0002eF-Ha for multi6@ops.ietf.org; Thu, 19 Jun 2003 06:24:43 +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 h5J6N6BJ007719; Thu, 19 Jun 2003 08:23:06 +0200 (MET DST) Subject: Re: DNS based Destination Selection From: Cedric de Launois To: Jay Ford Cc: David Gethings , multi6@ops.ietf.org In-Reply-To: References: <1055952500.30027.12.camel@trigger.highway.co.uk> Content-Type: text/plain; charset=iso-8859-1 Organization: Universite Catholique de Louvain Message-Id: <1056003888.19105.22.camel@descartes> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 19 Jun 2003 08:24:48 +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 mer 18/06/2003 à 18:58, Jay Ford a écrit : > On Wed, 18 Jun 2003, David Gethings wrote: > > I understand that DNS based solutions to the IPv6 multihomed problem > > have been suggested before. However I believe my suggestion is a > > different variant to previous suggestions. > > > > Below is an overview of my suggestion. I believe it has merit and would > > like the groups view. > > My quick reactions: > o DNS is too high a level for (srcaddr,dstaddr) selection; > not everything goes by name Indeed. We thought of this mechanism in the NAROS solution. We perfomed recently a quick evaluation of this solution (use of DNS to influence an external source's destination decision making). First results clearly show this is too high level : 70 to 90% of the traffic flows we analyzed were NOT preceeded by a DNS request ! (This is only an approximation since it is hard to see which DNS request is associated with which flow). This is due to the spread of p2p applications : lots of flows without any DNS lookup. From owner-multi6@ops.ietf.org Thu Jun 19 02:41: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 CAA01568 for ; Thu, 19 Jun 2003 02:41:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19St6i-0003Lx-Tv for multi6-data@psg.com; Thu, 19 Jun 2003 06:41:16 +0000 Received: from [130.104.229.109] (helo=info.ucl.ac.be) by psg.com with esmtp (Exim 4.14) id 19St6g-0003Ll-HZ for multi6@ops.ietf.org; Thu, 19 Jun 2003 06:41:14 +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 h5J6dZBJ008276; Thu, 19 Jun 2003 08:39:35 +0200 (MET DST) Subject: Re: draft-ietf-multi6-multihoming-requirements-06.txt From: Cedric de Launois To: Pekka Savola Cc: Jay Ford , "J. Noel Chiappa" , multi6@ops.ietf.org In-Reply-To: References: Content-Type: text/plain; charset=iso-8859-1 Organization: Universite Catholique de Louvain Message-Id: <1056004878.19100.37.camel@descartes> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 19 Jun 2003 08:41:18 +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 jeu 19/06/2003 à 08:10, Pekka Savola a écrit : > > Also, what about the interaction between (srcaddr,dstaddr) selection & > > anti-spoofing-type filtering? The routers do the filtering, but the host > > does the address selection. How does that work? I don't want to have more > > spoofed attacks with IPv6 than we have now with IPv4. > > At the moment, there is no interaction. The routers have to allow both. > But that's one field that in particular should be worked at. > There IS interaction between src address selection and anti-spoofing-type filtering, at least in the multiaddressing solution. Suppose a site has 2 providers : ISPA and ISPB. Each provider delegates one prefix (PA and PB) to the hosts. When sending a packet, if a hosts choose PA as src address, then the packet must be routed through ISPA, not through ISPB, to avoid anti-spoofing-type filtering. A general principle would be : IF a host receives prefix PA in a router advertisement coming from router RA THEN choose src address PA if the host sends a packet with RA as the first hop toward the destination (i.e. the packet is sent through ISPA). I would insert this rule just after the 7th rule in RFC3484. From owner-multi6@ops.ietf.org Thu Jun 19 03:18: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 DAA03181 for ; Thu, 19 Jun 2003 03:18:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Stg6-0004hO-BX for multi6-data@psg.com; Thu, 19 Jun 2003 07:17:50 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19Stg3-0004h9-CY for multi6@ops.ietf.org; Thu, 19 Jun 2003 07:17:47 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h5J7Hbl16041; Thu, 19 Jun 2003 10:17:38 +0300 Date: Thu, 19 Jun 2003 10:17:37 +0300 (EEST) From: Pekka Savola To: Cedric de Launois cc: Jay Ford , "J. Noel Chiappa" , Subject: Re: draft-ietf-multi6-multihoming-requirements-06.txt In-Reply-To: <1056004878.19100.37.camel@descartes> 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 19 Jun 2003, Cedric de Launois wrote: > > > Also, what about the interaction between (srcaddr,dstaddr) selection & > > > anti-spoofing-type filtering? The routers do the filtering, but the host > > > does the address selection. How does that work? I don't want to have more > > > spoofed attacks with IPv6 than we have now with IPv4. > > > > At the moment, there is no interaction. The routers have to allow both. > > But that's one field that in particular should be worked at. > > There IS interaction between src address selection and > anti-spoofing-type filtering, at least in the multiaddressing solution. > Suppose a site has 2 providers : ISPA and ISPB. Each provider delegates > one prefix (PA and PB) to the hosts. When sending a packet, if a hosts > choose PA as src address, then the packet must be routed through ISPA, > not through ISPB, to avoid anti-spoofing-type filtering. Yes, this is the interaction there *should* be, but currently isn't :-) > A general principle would be : > > IF a host receives prefix PA in a router advertisement coming from > router RA THEN choose src address PA if the host sends a packet with > RA as the first hop toward the destination (i.e. the packet is sent > through ISPA). > > I would insert this rule just after the 7th rule in RFC3484. This doesn't help in the most typical case, where there is a single router advertising both prefixes. (It would only help when there are two routers advertising two different prefixes to the host.) Basically the simplest fix is using policy-based routing in your site border routers. Not typically implemented for IPv6, but should be quite straightforward. See draft-savola-bcp38-multihoming-update-00.txt for more thoughts on this. -- 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 Jun 19 03:34: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 DAA03383 for ; Thu, 19 Jun 2003 03:34:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19StvY-0005Ol-Pi for multi6-data@psg.com; Thu, 19 Jun 2003 07:33:48 +0000 Received: from [130.104.229.109] (helo=info.ucl.ac.be) by psg.com with esmtp (Exim 4.14) id 19StvV-0005ON-Ez for multi6@ops.ietf.org; Thu, 19 Jun 2003 07:33:45 +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 h5J7W7BJ010395; Thu, 19 Jun 2003 09:32:07 +0200 (MET DST) Subject: Re: draft-ietf-multi6-multihoming-requirements-06.txt From: Cedric de Launois To: Pekka Savola Cc: multi6@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Organization: Universite Catholique de Louvain Message-Id: <1056008029.19100.52.camel@descartes> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 19 Jun 2003 09:33:50 +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 > > A general principle would be : > > > > IF a host receives prefix PA in a router advertisement coming from > > router RA THEN choose src address PA if the host sends a packet with > > RA as the first hop toward the destination (i.e. the packet is sent > > through ISPA). > > > > I would insert this rule just after the 7th rule in RFC3484. > > This doesn't help in the most typical case, where there is a single router > advertising both prefixes. (It would only help when there are two routers > advertising two different prefixes to the host.) When there is a single router, source-based routing can be used. The router routes all packets with src address PA through ISPA. > Basically the simplest fix is using policy-based routing in your site > border routers. Not typically implemented for IPv6, but should be quite > straightforward. Agreed. But if there are two routers, packets addressed to the wrong router need to be redirected in some way to the right router. The basic src address selection mechanism I propose just helps to avoid the redirection in this case. This is an heuristic that could help and that don't cost a lot... > See draft-savola-bcp38-multihoming-update-00.txt for more thoughts on > this. Thanks, I'll read it. From owner-multi6@ops.ietf.org Thu Jun 19 04:54: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 EAA05541 for ; Thu, 19 Jun 2003 04:54:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19SvA6-0008jg-Rx for multi6-data@psg.com; Thu, 19 Jun 2003 08:52:54 +0000 Received: from [194.200.10.4] (helo=mxgw.highway.co.uk) by psg.com with esmtp (Exim 4.14) id 19SvA3-0008jQ-Tm for multi6@ops.ietf.org; Thu, 19 Jun 2003 08:52:52 +0000 Received: from trigger.highway.co.uk (unknown [172.31.20.182]) by mxgw.highway.co.uk (Postfix) with ESMTP id 621A0180096; Thu, 19 Jun 2003 09:57:36 +0100 (BST) Subject: Re: DNS based Destination Selection From: David Gethings To: Cedric de Launois Cc: Jay Ford , multi6@ops.ietf.org In-Reply-To: <1056003888.19105.22.camel@descartes> References: <1055952500.30027.12.camel@trigger.highway.co.uk> <1056003888.19105.22.camel@descartes> Content-Type: text/plain Message-Id: <1056012605.30027.39.camel@trigger.highway.co.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 19 Jun 2003 09:50:06 +0100 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-35.3 required=5.0 tests=BAYES_20,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-06-19 at 07:24, Cedric de Launois wrote: > Indeed. We thought of this mechanism in the NAROS solution. We perfomed > recently a quick evaluation of this solution (use of DNS to influence > an external source's destination decision making). First results > clearly show this is too high level : 70 to 90% of the traffic > flows we analyzed were NOT preceeded by a DNS request ! (This > is only an approximation since it is hard to see which DNS request > is associated with which flow). This is due to the spread of p2p > applications : lots of flows without any DNS lookup. I must admit I was initially surprised by this statement. I have no reason to believe that this is untrue. However having given it a little thought this result does not really surprise me. When downloading a webpage there will only be a few DNS lookups required (usually only one or two), however there will be a number of flows as the web browser requests all the images and frames (if there are any) associated with that page. I do concede that there will be a number of applications that will never do a DNS lookup. So this obviously puts a question on whether DNS is the right place to do destination selection. The point of my suggestion is that it is a simple method of influencing which ingress path traffic could take for a multihomed site. It is simple enough for most SOHO and SME's to use and does not require much networking expertise - much less than using BGP. Will it work in every situation: no. Does it offer enough functionality that a reasonalbe proportion of multihomed sites will wish to use it: I believe so. Is the cost of changing DNS and host stacks worth it: I honestly do not know. I honestly don't believe we will find just one multihoming solution that will suit every multihomed site. I believe this method to a be good starting point for people new to multihoming in IPv6. Cheers Dg From owner-multi6@ops.ietf.org Thu Jun 19 05:05: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 FAA05730 for ; Thu, 19 Jun 2003 05:05:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19SvL5-0009Kf-5W for multi6-data@psg.com; Thu, 19 Jun 2003 09:04:15 +0000 Received: from [194.200.10.4] (helo=mxgw.highway.co.uk) by psg.com with esmtp (Exim 4.14) id 19SvL3-0009KO-2C for multi6@ops.ietf.org; Thu, 19 Jun 2003 09:04:13 +0000 Received: from trigger.highway.co.uk (unknown [172.31.20.182]) by mxgw.highway.co.uk (Postfix) with ESMTP id B08E0180096; Thu, 19 Jun 2003 10:08:59 +0100 (BST) Subject: Re: DNS based Destination Selection From: David Gethings To: Jay Ford Cc: multi6@ops.ietf.org In-Reply-To: References: <1055952500.30027.12.camel@trigger.highway.co.uk> Content-Type: text/plain Message-Id: <1056013289.30068.51.camel@trigger.highway.co.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 19 Jun 2003 10:01:29 +0100 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 Wed, 2003-06-18 at 17:58, Jay Ford wrote: > My quick reactions: > o DNS is too high a level for (srcaddr,dstaddr) selection; > not everything goes by name See my response to Cedric > o DNS changes are difficult->impossible to get deployed globally > o for some cases, relying on remotely-maintained DNS information is not > sufficient or desirable I agree that they are not easy, but this method is used for MX records. I agree that by adding the priority value to the AAAA & A6 records alters the purpose. But I do not see this as being a major sticking point. > o you cover dstaddr selection; what about srcaddr selection? One thought I have just had (so I have no idea how good or bad this idea is) is if a source is also multihomed it can perform PMTU discovery for each of the IPv6 addresses it has in that scope. The source address to use is determined by which ever returns the best PMTU and RTT. This is a slight waste of bandwidth. But if the "best" possible path is your ultimate goal there have to be trade offs. Cheers Dg From owner-multi6@ops.ietf.org Thu Jun 19 05:32: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 FAA06023 for ; Thu, 19 Jun 2003 05:32:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Svll-000Abp-8q for multi6-data@psg.com; Thu, 19 Jun 2003 09:31:49 +0000 Received: from [130.104.229.109] (helo=info.ucl.ac.be) by psg.com with esmtp (Exim 4.14) id 19Svlh-000AbR-MZ for multi6@ops.ietf.org; Thu, 19 Jun 2003 09:31:45 +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 h5J9U8BJ016054; Thu, 19 Jun 2003 11:30:08 +0200 (MET DST) Subject: Re: DNS based Destination Selection From: Cedric de Launois To: David Gethings Cc: multi6@ops.ietf.org In-Reply-To: <1056012605.30027.39.camel@trigger.highway.co.uk> References: <1055952500.30027.12.camel@trigger.highway.co.uk> <1056003888.19105.22.camel@descartes> <1056012605.30027.39.camel@trigger.highway.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Organization: Universite Catholique de Louvain Message-Id: <1056015111.19105.86.camel@descartes> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 19 Jun 2003 11:31:51 +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 jeu 19/06/2003 à 10:50, David Gethings a écrit : > I do concede that there will be a number of applications that will never > do a DNS lookup. So this obviously puts a question on whether DNS is the > right place to do destination selection. > > The point of my suggestion is that it is a simple method of influencing > which ingress path traffic could take for a multihomed site. It is > simple enough for most SOHO and SME's to use and does not require much > networking expertise - much less than using BGP. > > Will it work in every situation: no. Does it offer enough functionality > that a reasonalbe proportion of multihomed sites will wish to use it: I > believe so. Is the cost of changing DNS and host stacks worth it: I > honestly do not know. > > I honestly don't believe we will find just one multihoming solution that > will suit every multihomed site. I believe this method to a be good > starting point for people new to multihoming in IPv6. > My question is : what is the goal pursued with this mechanism ? - If the goal is to perform inbound traffic engineering, then I'd say this mechanism is not sufficient. Not enough traffic is controlled via this way to get good load-balancing. - If the goal is just to somewhat improve an external source's destination decision making, then what is the advantage of your suggestion compared to just carefully ordering the list of addresses returned in the DNS reply (solution which doesn't imply any change in the hosts) ? From owner-multi6@ops.ietf.org Thu Jun 19 07:32: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 HAA09492 for ; Thu, 19 Jun 2003 07:32:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19SxdF-000FxV-Kk for multi6-data@psg.com; Thu, 19 Jun 2003 11:31:09 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.14) id 19SxdD-000Fup-L4 for multi6@ops.ietf.org; Thu, 19 Jun 2003 11:31:07 +0000 Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id BBF951C; Thu, 19 Jun 2003 14:40:23 +0300 (EEST) Message-ID: <3EF19F1B.5040700@nomadiclab.com> Date: Thu, 19 Jun 2003 14:31:39 +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: hipsec@lists.freeswan.org, multi6@ops.ietf.org Subject: New version of HIP base protocol submitted Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_10,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 A new version of the HIP base protocol draft has been submitted to the repositories. In the meanwhile, it is available at the following URLs: http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-07.txt http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-07.html The following version contains change bars wrt. -06: http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-07-chbar.txt The following version is an HTML side-by-side comparison: http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-07-diff.html --Pekka Nikander From owner-multi6@ops.ietf.org Thu Jun 19 09:44: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 JAA17683 for ; Thu, 19 Jun 2003 09:44:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19SzhJ-000M9H-1g for multi6-data@psg.com; Thu, 19 Jun 2003 13:43:29 +0000 Received: from [128.255.204.16] (helo=seatpost.its.uiowa.edu) by psg.com with esmtp (Exim 4.14) id 19Szh7-000M8n-Bg for multi6@ops.ietf.org; Thu, 19 Jun 2003 13:43:17 +0000 Received: from jnford (helo=localhost) by seatpost.its.uiowa.edu with local-esmtp (Exim 3.36 #1 (Debian)) id 19Szh3-0003tC-00; Thu, 19 Jun 2003 08:43:13 -0500 Date: Thu, 19 Jun 2003 08:43:13 -0500 (CDT) From: Jay Ford X-X-Sender: jnford@seatpost.its.uiowa.edu Reply-To: Jay Ford To: Pekka Savola cc: "J. Noel Chiappa" , multi6@ops.ietf.org Subject: Re: draft-ietf-multi6-multihoming-requirements-06.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,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 On Thu, 19 Jun 2003, Pekka Savola wrote: > What is the number of the destinations you typically want to influence the > selection process? > > Note that if it's a rather small one, this one: > > Default Router Preferences, More-Specific Routes, and Load Sharing > draft-ietf-ipv6-router-selection-02.txt > > might help you a bit. That might work from some cases, but not my current situation. My net has a single core router for each user subnet, with the path divergence occurring in the core or border routers. Therefore, the hosts can't choose the path because they only have one. > > Also, what about the interaction between (srcaddr,dstaddr) selection & > > anti-spoofing-type filtering? The routers do the filtering, but the host > > does the address selection. How does that work? I don't want to have more > > spoofed attacks with IPv6 than we have now with IPv4. > > At the moment, there is no interaction. The routers have to allow both. > But that's one field that in particular should be worked at. This is operationally burdensome, especially because the burden propagates upstream. ________________________________________________________________________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-ford@uiowa.edu, phone: 319-335-5555, fax: 319-335-2951 From owner-multi6@ops.ietf.org Thu Jun 19 09:45: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 JAA17722 for ; Thu, 19 Jun 2003 09:45:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19SziC-000MBF-PS for multi6-data@psg.com; Thu, 19 Jun 2003 13:44:24 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.14) id 19SziA-000M9f-TP for multi6@ops.ietf.org; Thu, 19 Jun 2003 13:44:23 +0000 Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id C4EF21C; Thu, 19 Jun 2003 16:53:39 +0300 (EEST) Message-ID: <3EF1BE57.1020108@nomadiclab.com> Date: Thu, 19 Jun 2003 16:44:55 +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: hipsec@lists.freeswan.org, multi6@ops.ietf.org Subject: HIP Mobility and multihoming draft has reached the repositories 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 http://www.ietf.org/internet-drafts/draft-nikander-hip-mm-00.txt --Pekka Nikander From owner-multi6@ops.ietf.org Thu Jun 19 09:45: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 JAA17738 for ; Thu, 19 Jun 2003 09:45:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19SzjE-000MIf-PT for multi6-data@psg.com; Thu, 19 Jun 2003 13:45:28 +0000 Received: from [128.255.204.16] (helo=seatpost.its.uiowa.edu) by psg.com with esmtp (Exim 4.14) id 19SzjC-000MIM-1e for multi6@ops.ietf.org; Thu, 19 Jun 2003 13:45:26 +0000 Received: from jnford (helo=localhost) by seatpost.its.uiowa.edu with local-esmtp (Exim 3.36 #1 (Debian)) id 19Szj2-0003tQ-00; Thu, 19 Jun 2003 08:45:16 -0500 Date: Thu, 19 Jun 2003 08:45:16 -0500 (CDT) From: Jay Ford X-X-Sender: jnford@seatpost.its.uiowa.edu Reply-To: Jay Ford To: Cedric de Launois cc: David Gethings , multi6@ops.ietf.org Subject: Re: DNS based Destination Selection In-Reply-To: <1056003888.19105.22.camel@descartes> Message-ID: References: <1055952500.30027.12.camel@trigger.highway.co.uk> <1056003888.19105.22.camel@descartes> 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 On Thu, 19 Jun 2003, Cedric de Launois wrote: > > My quick reactions: > > o DNS is too high a level for (srcaddr,dstaddr) selection; > > not everything goes by name > > Indeed. We thought of this mechanism in the NAROS solution. We perfomed > recently a quick evaluation of this solution (use of DNS to influence > an external source's destination decision making). First results > clearly show this is too high level : 70 to 90% of the traffic > flows we analyzed were NOT preceeded by a DNS request ! (This > is only an approximation since it is hard to see which DNS request > is associated with which flow). This is due to the spread of p2p > applications : lots of flows without any DNS lookup. Wow. I wouldn't have expected the no-preceding-DNS percentage to be that high. I guess I was more right than I knew. ;^) ________________________________________________________________________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-ford@uiowa.edu, phone: 319-335-5555, fax: 319-335-2951 From owner-multi6@ops.ietf.org Thu Jun 19 09:56: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 JAA18243 for ; Thu, 19 Jun 2003 09:56:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Szt5-000NB9-M9 for multi6-data@psg.com; Thu, 19 Jun 2003 13:55:39 +0000 Received: from [128.255.204.16] (helo=seatpost.its.uiowa.edu) by psg.com with esmtp (Exim 4.14) id 19Szt1-000NAb-MS for multi6@ops.ietf.org; Thu, 19 Jun 2003 13:55:35 +0000 Received: from jnford (helo=localhost) by seatpost.its.uiowa.edu with local-esmtp (Exim 3.36 #1 (Debian)) id 19Szt0-0003w7-00; Thu, 19 Jun 2003 08:55:34 -0500 Date: Thu, 19 Jun 2003 08:55:34 -0500 (CDT) From: Jay Ford X-X-Sender: jnford@seatpost.its.uiowa.edu Reply-To: Jay Ford To: Cedric de Launois cc: multi6@ops.ietf.org Subject: Re: draft-ietf-multi6-multihoming-requirements-06.txt In-Reply-To: <1056008029.19100.52.camel@descartes> Message-ID: References: <1056008029.19100.52.camel@descartes> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,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 On Thu, 19 Jun 2003, Cedric de Launois wrote: > > > A general principle would be : > > > > > > IF a host receives prefix PA in a router advertisement coming from > > > router RA THEN choose src address PA if the host sends a packet with > > > RA as the first hop toward the destination (i.e. the packet is sent > > > through ISPA). > > > > > > I would insert this rule just after the 7th rule in RFC3484. > > > > This doesn't help in the most typical case, where there is a single router > > advertising both prefixes. (It would only help when there are two routers > > advertising two different prefixes to the host.) > > When there is a single router, source-based routing can be used. The > router routes all packets with src address PA through ISPA. I don't want source-based routing. I want destination-based routing, with a source address which works on the path I choose to that destination. That's the key aspect of the (srcaddr,dstaddr) selection which makes it difficult->impossible for the host to do correctly. It might end up being difficult for me to do, but I want a shot at it before giving up. (I haven't figured out how to deal with path transitions which invalidate the chosen (srcaddr,dstaddr) due to tight anti-spoofing filtering..., but I'm still pondering that angle.) > > Basically the simplest fix is using policy-based routing in your site > > border routers. Not typically implemented for IPv6, but should be quite > > straightforward. > > Agreed. But if there are two routers, packets addressed to the wrong > router need to be redirected in some way to the right router. The basic > src address selection mechanism I propose just helps to avoid the > redirection in this case. This is an heuristic that could help and that > don't cost a lot... That makes the srcaddr choice preempt the dstaddr choice. I prefer it to be the other way around. ________________________________________________________________________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-ford@uiowa.edu, phone: 319-335-5555, fax: 319-335-2951 From owner-multi6@ops.ietf.org Thu Jun 19 10:00: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 KAA18687 for ; Thu, 19 Jun 2003 10:00:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Szxo-000NhV-3H for multi6-data@psg.com; Thu, 19 Jun 2003 14:00:32 +0000 Received: from [128.255.204.16] (helo=seatpost.its.uiowa.edu) by psg.com with esmtp (Exim 4.14) id 19Szxc-000Nfa-E0 for multi6@ops.ietf.org; Thu, 19 Jun 2003 14:00:20 +0000 Received: from jnford (helo=localhost) by seatpost.its.uiowa.edu with local-esmtp (Exim 3.36 #1 (Debian)) id 19Szxb-0003wa-00; Thu, 19 Jun 2003 09:00:19 -0500 Date: Thu, 19 Jun 2003 09:00:19 -0500 (CDT) From: Jay Ford X-X-Sender: jnford@seatpost.its.uiowa.edu Reply-To: Jay Ford To: David Gethings cc: multi6@ops.ietf.org Subject: Re: DNS based Destination Selection In-Reply-To: <1056012605.30027.39.camel@trigger.highway.co.uk> Message-ID: References: <1055952500.30027.12.camel@trigger.highway.co.uk> <1056003888.19105.22.camel@descartes> <1056012605.30027.39.camel@trigger.highway.co.uk> 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 On Thu, 19 Jun 2003, David Gethings wrote: > I do concede that there will be a number of applications that will never > do a DNS lookup. So this obviously puts a question on whether DNS is the > right place to do destination selection. Right. I think it has to be lower down than the DNS. > The point of my suggestion is that it is a simple method of influencing > which ingress path traffic could take for a multihomed site. It is > simple enough for most SOHO and SME's to use and does not require much > networking expertise - much less than using BGP. Is it likely that small (home...) sites will be multihomed? I'd pretty much written them off as not pertinent. > Will it work in every situation: no. Does it offer enough functionality > that a reasonalbe proportion of multihomed sites will wish to use it: I > believe so. Is the cost of changing DNS and host stacks worth it: I > honestly do not know. > > I honestly don't believe we will find just one multihoming solution that > will suit every multihomed site. I believe this method to a be good > starting point for people new to multihoming in IPv6. We probably will end up with multiple multihome options for IPv6, just like we have with IPv4. I just don't see that a DNS-based solution puts the control at the right end or catches enough flows. ________________________________________________________________________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-ford@uiowa.edu, phone: 319-335-5555, fax: 319-335-2951 From owner-multi6@ops.ietf.org Thu Jun 19 10:08: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 KAA19402 for ; Thu, 19 Jun 2003 10:08:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19T04x-000Oct-OV for multi6-data@psg.com; Thu, 19 Jun 2003 14:07:55 +0000 Received: from [128.255.204.16] (helo=seatpost.its.uiowa.edu) by psg.com with esmtp (Exim 4.14) id 19T04u-000OcY-M1 for multi6@ops.ietf.org; Thu, 19 Jun 2003 14:07:52 +0000 Received: from jnford (helo=localhost) by seatpost.its.uiowa.edu with local-esmtp (Exim 3.36 #1 (Debian)) id 19T04t-00040n-00; Thu, 19 Jun 2003 09:07:51 -0500 Date: Thu, 19 Jun 2003 09:07:51 -0500 (CDT) From: Jay Ford X-X-Sender: jnford@seatpost.its.uiowa.edu Reply-To: Jay Ford To: David Gethings cc: multi6@ops.ietf.org Subject: Re: DNS based Destination Selection In-Reply-To: <1056013289.30068.51.camel@trigger.highway.co.uk> Message-ID: References: <1055952500.30027.12.camel@trigger.highway.co.uk> <1056013289.30068.51.camel@trigger.highway.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,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 On Thu, 19 Jun 2003, David Gethings wrote: > > o DNS changes are difficult->impossible to get deployed globally > > o for some cases, relying on remotely-maintained DNS information is not > > sufficient or desirable > I agree that they are not easy, but this method is used for MX records. > I agree that by adding the priority value to the AAAA & A6 records > alters the purpose. But I do not see this as being a major sticking > point. I think changing AAAA and/or A6 RRs at this point would be tough, but it might be possible. The second of my two above points was that the remote end (which owns the DNS) would be specifying the preferences of the sender of a packet. I'd rather decide the preferences at my end for traffic I send. Most net interactions are bidirectional, so this is admittedly not a single-ended problem, & the issue of who (sender or receiver) gets to decide path selection for a packet borders on religious, so getting consensus on this won't be easy. (By the way, we have the same issues with IPv4, but based on AS-path info... instead of addresses.) > > o you cover dstaddr selection; what about srcaddr selection? > One thought I have just had (so I have no idea how good or bad this idea > is) is if a source is also multihomed it can perform PMTU discovery for > each of the IPv6 addresses it has in that scope. The source address to > use is determined by which ever returns the best PMTU and RTT. > > This is a slight waste of bandwidth. But if the "best" possible path is > your ultimate goal there have to be trade offs. The definition of "best" is tricky. It isn't always just bandwidth & RTT. ________________________________________________________________________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-ford@uiowa.edu, phone: 319-335-5555, fax: 319-335-2951 From owner-multi6@ops.ietf.org Thu Jun 19 10:12: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 KAA19937 for ; Thu, 19 Jun 2003 10:12:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19T09C-000P8a-6d for multi6-data@psg.com; Thu, 19 Jun 2003 14:12:18 +0000 Received: from [128.255.204.16] (helo=seatpost.its.uiowa.edu) by psg.com with esmtp (Exim 4.14) id 19T098-000P8B-Ng for multi6@ops.ietf.org; Thu, 19 Jun 2003 14:12:14 +0000 Received: from jnford (helo=localhost) by seatpost.its.uiowa.edu with local-esmtp (Exim 3.36 #1 (Debian)) id 19T097-00043h-00; Thu, 19 Jun 2003 09:12:13 -0500 Date: Thu, 19 Jun 2003 09:12:13 -0500 (CDT) From: Jay Ford X-X-Sender: jnford@seatpost.its.uiowa.edu Reply-To: Jay Ford To: Cedric de Launois cc: multi6@ops.ietf.org Subject: Re: DNS based Destination Selection In-Reply-To: <1056015111.19105.86.camel@descartes> Message-ID: References: <1055952500.30027.12.camel@trigger.highway.co.uk> <1056003888.19105.22.camel@descartes> <1056012605.30027.39.camel@trigger.highway.co.uk> <1056015111.19105.86.camel@descartes> 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 On Thu, 19 Jun 2003, Cedric de Launois wrote: > My question is : what is the goal pursued with this mechanism ? > - If the goal is to perform inbound traffic engineering, then I'd say > this mechanism is not sufficient. Not enough traffic is controlled via > this way to get good load-balancing. Agreed. Further, if the choice of source address preempts the path selection, then the TE intended by the DNS preferences don't work. > - If the goal is just to somewhat improve an external source's > destination decision making, then what is the advantage of your > suggestion compared to just carefully ordering the list of addresses > returned in the DNS reply (solution which doesn't imply any change in > the hosts) ? DNS replies often don't go directly from DNS server to DNS client when they are in different administrative domains. Recursive queries, caching, secondary service... all introduce places where the RRs can get reordered. ________________________________________________________________________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-ford@uiowa.edu, phone: 319-335-5555, fax: 319-335-2951 From owner-multi6@ops.ietf.org Thu Jun 19 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 KAA20970 for ; Thu, 19 Jun 2003 10:20:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19T0Gn-00005r-Vn for multi6-data@psg.com; Thu, 19 Jun 2003 14:20:09 +0000 Received: from [130.104.229.109] (helo=info.ucl.ac.be) by psg.com with esmtp (Exim 4.14) id 19T0Gj-00004k-Bj for multi6@ops.ietf.org; Thu, 19 Jun 2003 14:20:05 +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 h5JEIRBJ028379; Thu, 19 Jun 2003 16:18:27 +0200 (MET DST) Subject: Re: DNS based Destination Selection From: Cedric de Launois To: Jay Ford Cc: David Gethings , multi6@ops.ietf.org In-Reply-To: References: <1055952500.30027.12.camel@trigger.highway.co.uk> <1056003888.19105.22.camel@descartes> Content-Type: text/plain; charset=iso-8859-1 Organization: Universite Catholique de Louvain Message-Id: <1056032411.28241.26.camel@descartes> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 19 Jun 2003 16:20:11 +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 jeu 19/06/2003 à 15:45, Jay Ford a écrit : > On Thu, 19 Jun 2003, Cedric de Launois wrote: > > > My quick reactions: > > > o DNS is too high a level for (srcaddr,dstaddr) selection; > > > not everything goes by name > > > > Indeed. We thought of this mechanism in the NAROS solution. We perfomed > > recently a quick evaluation of this solution (use of DNS to influence > > an external source's destination decision making). First results > > clearly show this is too high level : 70 to 90% of the traffic > > flows we analyzed were NOT preceeded by a DNS request ! (This > > is only an approximation since it is hard to see which DNS request > > is associated with which flow). This is due to the spread of p2p > > applications : lots of flows without any DNS lookup. > > Wow. I wouldn't have expected the no-preceding-DNS percentage to be that > high. I guess I was more right than I knew. ;^) I was also surprised. However, these values are rough approximations. Factors that can explain these high percentages are : - the trace contains lots of p2p traffic, that generates lots of flows without using DNS. - attacks from the Internet : port scans etc. The trace should be cleaned up... - caching on host applications - associating a DNS request to a flow is a non-trivial task. The evaluation method used is far from perfect. However, the values show that we can't rely on DNS to perform (srcaddr,dstaddr) selection. From owner-multi6@ops.ietf.org Thu Jun 19 11:34: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 LAA25668 for ; Thu, 19 Jun 2003 11:34:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19T1Pr-0007TL-9y for multi6-data@psg.com; Thu, 19 Jun 2003 15:33:35 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.14) id 19T1Po-0007Po-Vo for multi6@ops.ietf.org; Thu, 19 Jun 2003 15:33:32 +0000 Received: from mail5.microsoft.com ([157.54.6.156]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 19 Jun 2003 08:33:02 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 19 Jun 2003 08:33:00 -0700 Received: from 157.54.8.23 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 19 Jun 2003 08:33:00 -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, 19 Jun 2003 08:33:00 -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, 19 Jun 2003 08:32:58 -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); Thu, 19 Jun 2003 08:32:53 -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: draft-ietf-multi6-multihoming-requirements-06.txt Date: Thu, 19 Jun 2003 08:32:47 -0700 Message-ID: Thread-Topic: draft-ietf-multi6-multihoming-requirements-06.txt Thread-Index: AcM1vc99MZnjJpqoQwiOCuhkD+KnEQAuVlGQ From: "Christian Huitema" To: "Craig A. Huegen" , "Jay Ford" Cc: "J. Noel Chiappa" , X-OriginalArrivalTime: 19 Jun 2003 15:32:53.0878 (UTC) FILETIME=[0D02F960:01C33678] 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 LAA25668 > > Call me a control freak, but I (as campus network routing guy) would > like to > > get a little more determinism than is afforded by a virtual coin toss, > even a > > weighted one. If the address selection must occur in the host, I at > least > > want a hook to influence the selection process (for srcaddr *and* > dstaddr). > > There have been many similar comments (from myself as well) asserting > your statement. It needs to be OS-independent as well, meaning that any > device that speaks IPv6 should be able to follow my rules/hints for where > traffic needs to go. Any solution without this should be deemed > unacceptable. Any host implementation has to consider multiple scenarios, and site multi-homing is just one of them. In practice, many hosts are multi-homed to several sites -- think for example of a laptop with a WiFi connection to the local access point, a GPRS connection, and maybe an occasional VPN tunnel or two. Hosts do have to perform some amount of srce/dest selection, if only to decide which of the hosts' interface to use. It would be better to find a way to provide information to the host, so the host can make an appropriate decision -- hints are more efficient than rules. -- Christian Huitema From owner-multi6@ops.ietf.org Thu Jun 19 11:56: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 LAA26964 for ; Thu, 19 Jun 2003 11:56:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19T1l6-000AHH-5f for multi6-data@psg.com; Thu, 19 Jun 2003 15:55:32 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.14) id 19T1l0-000AH3-Fx for multi6@ops.ietf.org; Thu, 19 Jun 2003 15:55:26 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19T1kz-0009iZ-B6 for multi6@ops.ietf.org; Thu, 19 Jun 2003 08:55:25 -0700 Message-Id: <5.1.0.14.2.20030619102349.02d3fde8@localhost> In-Reply-To: <3EF1BE57.1020108@nomadiclab.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Date: Thu, 19 Jun 2003 10:26:37 -0400 To: hipsec@lists.freeswan.org, hipsec@lists.freeswan.org, multi6@ops.ietf.org From: Robert Moskowitz Subject: Re: [Hipsec] HIP Mobility and multihoming draft has reached the repositories X-Spam-Status: No, hits=-15.5 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk [ 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. ] At 04:44 PM 6/19/2003 +0300, Pekka Nikander wrote: >http://www.ietf.org/internet-drafts/draft-nikander-hip-mm-00.txt GREAT STUFF!!! Congrads on getting this out. I am going to bring this up in the IEEE 802 Handoff Study Group. BTW, I am NOT going to Vienna too much IEEE 802 travel required by work and hard to justify to my family yet another week on the road. Plus I expect to miss the Novemeber meeting in favor of the IEEE 802 plenary that same week... From owner-multi6@ops.ietf.org Thu Jun 19 12:00: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 MAA27419 for ; Thu, 19 Jun 2003 12:00:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19T1pb-000Acg-16 for multi6-data@psg.com; Thu, 19 Jun 2003 16:00:11 +0000 Received: from [194.196.100.236] (helo=d12lmsgate-3.de.ibm.com) by psg.com with esmtp (Exim 4.14) id 19T1pY-000AaU-5O for multi6@ops.ietf.org; Thu, 19 Jun 2003 16:00:08 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate-3.de.ibm.com (8.12.9/8.12.8) with ESMTP id h5JFxYsn088764 for ; Thu, 19 Jun 2003 17:59:35 +0200 Received: from ochsehorn.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h5JFxXpR286202 for ; Thu, 19 Jun 2003 17:59:34 +0200 Received: from dhcp22-128.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA83838 from ; Thu, 19 Jun 2003 17:59:32 +0200 Message-Id: <3EF1DDF8.5565F1F9@hursley.ibm.com> Date: Thu, 19 Jun 2003 17:59:52 +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: DNS based Destination Selection References: <1055952500.30027.12.camel@trigger.highway.co.uk> <1056003888.19105.22.camel@descartes> <1056012605.30027.39.camel@trigger.highway.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-9.6 required=5.0 tests=BAYES_20,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 A couple of comments 1. Forget A6 records. They are deprecated and pretty much dead and buried. 2. I agree with the comments suggesting that DNS cannot be the primary mechanism for address selection. However, that doesn't exclude a DNS based solution for address mapping. Applications that don't use DNS to initiate a transaction might just have to use DNS if they want to benefit from a mapping style of multihoming. Brian From owner-multi6@ops.ietf.org Thu Jun 19 12:10: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 MAA28458 for ; Thu, 19 Jun 2003 12:10:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19T1yG-000BQR-JG for multi6-data@psg.com; Thu, 19 Jun 2003 16:09:08 +0000 Received: from [194.112.11.173] (helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 4.14) id 19T1yD-000BQA-1d for multi6@ops.ietf.org; Thu, 19 Jun 2003 16:09: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 h5JG8tFT013988; Thu, 19 Jun 2003 18:08:58 +0200 (CEST) Date: Thu, 19 Jun 2003 15:41:03 +0200 Subject: Re: DNS based Destination Selection Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Cedric de Launois , Jay Ford , multi6@ops.ietf.org To: David Gethings From: Kurt Erik Lindqvist In-Reply-To: <1056012605.30027.39.camel@trigger.highway.co.uk> Message-Id: Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-35.4 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE, 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On torsdag, jun 19, 2003, at 10:50 Europe/Stockholm, David Gethings wrote: > > Will it work in every situation: no. Does it offer enough functionality > that a reasonalbe proportion of multihomed sites will wish to use it: I > believe so. Is the cost of changing DNS and host stacks worth it: I > honestly do not know. The problem with DNS for this purpose is as Brian pointed out some weeks (months?) ago - you create circular dependencies. Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPvG9d6arNKXTPFCVEQKIdwCfWMKPIM/HPnIQyA38KsAP3nqhuVgAn07R goBK2qPcACPD4GqFr09tNC3H =Vk25 -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Thu Jun 19 13:36: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 NAA03544 for ; Thu, 19 Jun 2003 13:36:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19T3J5-000Gg2-Sp for multi6-data@psg.com; Thu, 19 Jun 2003 17:34:43 +0000 Received: from [208.185.30.208] (helo=buffoon.automagic.org ident=qmailr) by psg.com with smtp (Exim 4.14) id 19T3J2-000Gfg-Qy for multi6@ops.ietf.org; Thu, 19 Jun 2003 17:34:40 +0000 Received: (qmail 72876 invoked by uid 0); 19 Jun 2003 17:34:38 -0000 Received: from localhost.automagic.org (HELO isc.org) (root@127.0.0.1) by localhost.automagic.org with SMTP; 19 Jun 2003 17:34:38 -0000 Date: Thu, 19 Jun 2003 13:34:49 -0400 Subject: Re: DNS based Destination Selection Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: David Gethings , Cedric de Launois , Jay Ford , multi6@ops.ietf.org To: Kurt Erik Lindqvist From: Joe Abley In-Reply-To: Message-Id: <5384EA9E-A27C-11D7-86B8-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 Thursday, Jun 19, 2003, at 09:41 Canada/Eastern, Kurt Erik Lindqvist wrote: > On torsdag, jun 19, 2003, at 10:50 Europe/Stockholm, David Gethings > wrote: > >> >> Will it work in every situation: no. Does it offer enough >> functionality >> that a reasonalbe proportion of multihomed sites will wish to use it: >> I >> believe so. Is the cost of changing DNS and host stacks worth it: I >> honestly do not know. > > The problem with DNS for this purpose is as Brian pointed out some > weeks (months?) ago - you create circular dependencies. But as we discussed in the thread which followed that observation, circular dependencies can be managed (e.g. by way of a bootstrap procedure). So the fact that a circular dependency might exist does not necessarily indicate a dead end. Joe From owner-multi6@ops.ietf.org Thu Jun 19 18:23: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 SAA23335 for ; Thu, 19 Jun 2003 18:23:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19T7mY-0006Cn-Gp for multi6-data@psg.com; Thu, 19 Jun 2003 22:21:26 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.14) id 19T7mU-0006CV-Mb for multi6@ops.ietf.org; Thu, 19 Jun 2003 22:21:23 +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 h5JMMExS027892; Fri, 20 Jun 2003 00:22:14 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 20 Jun 2003 00:21:21 +0200 Subject: Re: DNS based Destination Selection Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: David Gethings , multi6@ops.ietf.org To: Jay Ford From: Iljitsch van Beijnum In-Reply-To: Message-Id: <5AAB132A-A2A4-11D7-A48D-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, jun 19, 2003, at 16:07 Europe/Amsterdam, Jay Ford wrote: > The second of my two above points was that the remote end (which owns > the > DNS) would be specifying the preferences of the sender of a packet. > I'd > rather decide the preferences at my end for traffic I send. Most net > interactions are bidirectional, so this is admittedly not a > single-ended > problem, & the issue of who (sender or receiver) gets to decide path > selection for a packet borders on religious, so getting consensus on > this > won't be easy. This assumes that given the choice between two addresses for the other end, choosing address #1 will make the packet flow over ISP A and choosing address #2 will make the packet flow over ISP B. I see no reason why this assumption would hold true in the majority of cases today, and it certainly doesn't _necessarily_ hold true. >>> o you cover dstaddr selection; what about srcaddr selection? >> One thought I have just had (so I have no idea how good or bad this >> idea >> is) is if a source is also multihomed it can perform PMTU discovery >> for >> each of the IPv6 addresses it has in that scope. The source address to >> use is determined by which ever returns the best PMTU and RTT. With hop-by-hop routing you don't get to pick a source address: you must use one compatible with the ISP that is the next hop for the destination address in the packet. You get to do this with source address dependent routing, though. (This will fix the above problem as well.) >> This is a slight waste of bandwidth. But if the "best" possible path >> is >> your ultimate goal there have to be trade offs. > The definition of "best" is tricky. It isn't always just bandwidth & > RTT. Either the preference can be expressed in a policy so ask a policy server, or it can be expressed as "optimize this set of variables" in which case you try the permutations, perform measurements and ultimately decide. Or make TCP multipath-aware with window and RTT processing per path. Then you get the performance of the combined paths regardless of the features of any particular path. From owner-multi6@ops.ietf.org Thu Jun 19 20:49: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 UAA27047 for ; Thu, 19 Jun 2003 20:49:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19TA4e-000C6g-H1 for multi6-data@psg.com; Fri, 20 Jun 2003 00:48:16 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19TA4c-000C6S-6t for multi6@ops.ietf.org; Fri, 20 Jun 2003 00:48:14 +0000 From: Masataka Ohta Message-Id: <200306200036.JAA10113@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id JAA10113; Fri, 20 Jun 2003 09:36:35 +0900 Subject: Re: Call for presentations In-Reply-To: <1A243EFE-A15F-11D7-9791-000393A638B2@kurtis.pp.se> from Kurt Erik Lindqvist at "Jun 18, 2003 09:33:06 am" To: Kurt Erik Lindqvist Date: Fri, 20 Jun 2003 09:36:33 +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; > With this mail I would like to ask for presentations for the first slot > of the multi6 WG. When will the presentations for the second slot be requested? > Again, please note that this is not supposed to be a in-depth > presentation of your proposal (or multi6 related draft) it is supposed > to be a opportunity to give an overview, make clarifications and ask > questions. How are the differences between the first and the second slots? > Please send me > > - - Presenters name > - - Draft name > - - Rough time estimate needed Will do so, after it is clarified to which slot should we make presentations. Masataka Ohta From owner-multi6@ops.ietf.org Thu Jun 19 21:39: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 VAA28456 for ; Thu, 19 Jun 2003 21:39:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19TArL-000EOM-PL for multi6-data@psg.com; Fri, 20 Jun 2003 01:38:35 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.14) id 19TArH-000EO1-OI for multi6@ops.ietf.org; Fri, 20 Jun 2003 01:38:31 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19TArF-000M45-CG; Thu, 19 Jun 2003 18:38:29 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 19 Jun 2003 18:38:28 -0700 To: Masataka Ohta Cc: Kurt Erik Lindqvist , multi6@ops.ietf.org Subject: Re: Call for presentations References: <1A243EFE-A15F-11D7-9791-000393A638B2@kurtis.pp.se> <200306200036.JAA10113@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 > Will do so, after it is clarified to which slot should we make > presentations. that all depends on what your presentation is, does it not? randy From owner-multi6@ops.ietf.org Thu Jun 19 23:49: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 XAA02483 for ; Thu, 19 Jun 2003 23:49:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19TCsa-000JTk-8E for multi6-data@psg.com; Fri, 20 Jun 2003 03:48:00 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19TCsX-000JST-5o; Fri, 20 Jun 2003 03:47:57 +0000 From: Masataka Ohta Message-Id: <200306200335.MAA10897@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id MAA10897; Fri, 20 Jun 2003 12:34:51 +0859 Subject: Re: Call for presentations In-Reply-To: from Randy Bush at "Jun 19, 2003 06:38:28 pm" To: Randy Bush Date: Fri, 20 Jun 2003 12:34:51 +0859 () CC: Kurt Erik Lindqvist , 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 > > Will do so, after it is clarified to which slot should we make > > presentations. > > that all depends on what your presentation is, does it not? We, for example, have a topic on a completed design of multi6 solution. But, I'm asking what presentations are called for for the second slot. Or, do you mean any presentation is acceptable for the second slot? Masataka Ohta From owner-multi6@ops.ietf.org Fri Jun 20 04:15: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 EAA20890 for ; Fri, 20 Jun 2003 04:15:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19TH0E-0003Ln-Lt for multi6-data@psg.com; Fri, 20 Jun 2003 08:12:10 +0000 Received: from [163.117.136.121] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.14) id 19TH0B-0003Kf-BO for multi6@ops.ietf.org; Fri, 20 Jun 2003 08:12:07 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 8B24C4326C; Fri, 20 Jun 2003 10:11:36 +0200 (CEST) Received: from varpa.it.uc3m.es (varpa.it.uc3m.es [163.117.139.253]) by smtp01.uc3m.es (Postfix) with ESMTP id E5FF299E67; Fri, 20 Jun 2003 10:11:31 +0200 (CEST) Received: from localhost.localdomain (marcelo@presto.it.uc3m.es [163.117.139.134]) by varpa.it.uc3m.es (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id KAA27126; Fri, 20 Jun 2003 10:11:31 +0200 X-Authentication-Warning: varpa.it.uc3m.es: Host marcelo@presto.it.uc3m.es [163.117.139.134] claimed to be localhost.localdomain Subject: Re: DNS based Destination Selection From: marcelo bagnulo To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org In-Reply-To: <5AAB132A-A2A4-11D7-A48D-00039388672E@muada.com> References: <5AAB132A-A2A4-11D7-A48D-00039388672E@muada.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 20 Jun 2003 10:11:14 +0200 Message-Id: <1056096675.563.44.camel@presto> Mime-Version: 1.0 X-Spam-Status: No, hits=-40.2 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN, X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-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, On Fri, 2003-06-20 at 00:21, Iljitsch van Beijnum wrote: > On donderdag, jun 19, 2003, at 16:07 Europe/Amsterdam, Jay Ford wrote: > > > The second of my two above points was that the remote end (which owns > > the > > DNS) would be specifying the preferences of the sender of a packet. > > I'd > > rather decide the preferences at my end for traffic I send. Most net > > interactions are bidirectional, so this is admittedly not a > > single-ended > > problem, & the issue of who (sender or receiver) gets to decide path > > selection for a packet borders on religious, so getting consensus on > > this > > won't be easy. > > This assumes that given the choice between two addresses for the other > end, choosing address #1 will make the packet flow over ISP A and > choosing address #2 will make the packet flow over ISP B. I see no > reason why this assumption would hold true in the majority of cases > today, and it certainly doesn't _necessarily_ hold true. > If PA addressing is used, the selection of the dest address implies the selection of the provider used to reach that destination address (at least in steady state i.e. no failures). right? If this is so, what case are you considering where the selection of the dest addr does not implies the selection of the isp used to reach the multi-homed site? Regards, marcelo From owner-multi6@ops.ietf.org Fri Jun 20 12:26: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 MAA16019 for ; Fri, 20 Jun 2003 12:26:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19TOhh-000Lqu-KJ for multi6-data@psg.com; Fri, 20 Jun 2003 16:25:33 +0000 Received: from [194.112.11.173] (helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 4.14) id 19TOhd-000Lqi-49 for multi6@ops.ietf.org; Fri, 20 Jun 2003 16:25:29 +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 h5KGPGFT014280; Fri, 20 Jun 2003 18:25:22 +0200 (CEST) Date: Fri, 20 Jun 2003 18:25:04 +0200 Subject: Re: Call for presentations Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200306200036.JAA10113@necom830.hpcl.titech.ac.jp> Message-Id: Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-21.8 required=5.0 tests=BAYES_01,IN_REP_TO,PGP_SIGNATURE,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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> With this mail I would like to ask for presentations for the first >> slot >> of the multi6 WG. > > When will the presentations for the second slot be requested? To be honest, I have not planned on making a specific announcement for the second slot. > >> Again, please note that this is not supposed to be a in-depth >> presentation of your proposal (or multi6 related draft) it is supposed >> to be a opportunity to give an overview, make clarifications and ask >> questions. > > How are the differences between the first and the second slots? Our intention is to use the first slot for presentations on multi6 related topics (architecture, solutions, cookie recipes, what you want) . If we have a serious problem with time in the first slot we can let that spill into the second slot(currently this does not seem to be an issue), but the second slot is meant for discussions on how we should move forward and what the architecture should be. So the first slot is to be seen as input for the second one. Note that we expect the design team to present their work in the second slot as well. Generally the second slot is more to be seen as "open mike" tough. And also discussions on new milestones, charter etc. But that will be last and more administrative. Hope this clarifies the intentions of the agenda a bit. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPvM1ZaarNKXTPFCVEQL4CACfTWL9+V8pxygA+tW2YkizSFTarEgAoME+ pRe6jGE3LproRrhDwurS6s6y =o8hp -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Fri Jun 20 12:28: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 MAA16183 for ; Fri, 20 Jun 2003 12:28:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19TOjn-000Lxq-R5 for multi6-data@psg.com; Fri, 20 Jun 2003 16:27:43 +0000 Received: from [194.112.11.173] (helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 4.14) id 19TOji-000LxS-TF; Fri, 20 Jun 2003 16:27:40 +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 h5KGRYFT014283; Fri, 20 Jun 2003 18:27:34 +0200 (CEST) Date: Fri, 20 Jun 2003 18:27:24 +0200 Subject: Re: Call for presentations Content-Type: text/plain; charset=US-ASCII; format=fixed 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: <200306200335.MAA10897@necom830.hpcl.titech.ac.jp> Message-Id: <12FD5A89-A33C-11D7-9791-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-22.4 required=5.0 tests=BAYES_01,IN_REP_TO,PGP_SIGNATURE,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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> Will do so, after it is clarified to which slot should we make >>> presentations. >> >> that all depends on what your presentation is, does it not? > > We, for example, have a topic on a completed design of multi6 > solution. First slot. > > But, I'm asking what presentations are called for for the > second slot. > > Or, do you mean any presentation is acceptable for the second > slot? > No, we are hoping to have a discussion on the way forward in the second slot (in terms of architecture - if you think that me and Sean are doing a poor job and should start growing tomatoes instead you will have to talk to us and Randy in the bar ;-) ). Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPvM18aarNKXTPFCVEQJZIQCfYOImDJi8VrXu1WJ7Ku1+eg/Gcb0An0er N9GvG0N/ZRP9y0pgtwTkLtKy =oVt8 -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Jun 23 03: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 DAA11493 for ; Mon, 23 Jun 2003 03:28:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ULh7-000AiO-87 for multi6-data@psg.com; Mon, 23 Jun 2003 07:24:53 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 4.14) id 19ULh3-000Ahf-8r for multi6@ops.ietf.org; Mon, 23 Jun 2003 07:24:49 +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 h5N7OeFT014813; Mon, 23 Jun 2003 09:24:41 +0200 (CEST) Date: Mon, 23 Jun 2003 09:24:35 +0200 Subject: Re: Call for presentations Content-Type: text/plain; delsp=yes; charset=ISO-8859-1; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: FUJIKAWA Kenji From: Kurt Erik Lindqvist In-Reply-To: <3wwufdp8j9.wl@bmdi2216.bmobile.ne.jp> Message-Id: Content-Transfer-Encoding: quoted-printable X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-32.8 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE, 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: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I will add them. 15 mins per draft sounds a lot to me, but that will be =20= subject to total time used. Best regards, - - kurtis - On m=E5ndag, jun 23, 2003, at 09:17 Europe/Stockholm, FUJIKAWA Kenji =20 wrote: > Kurt; > > We have already submitted internet-drafts that are related > to multi6 WG. They can be downloded from > http://www.users.kudpc.kyoto-u.ac.jp/~r52802/draft-ohira-assign-=20= > select-e2e-multihome-00.txt > and > = http://hage.tori.cc/~arifumi/draft-arifumi-lin6-multihome-api-00.txt > , and will be downloded from ftp.ietf.org soon. > > We would like to make presentations abount them, so would > you assign slots for us? We'll be glad if you assign 15min > for each draft. > > FYI, we now manage more than 200 wireless APs based on > 802.11b in Kyoto city, Japan, and all of them supports > IPv6. We are also planning to multihome them. I believe our > platform is the largest IPv6 wireless environment in the > world, and will be the largest wireless multihomed > environment. > > The followings are detailed information on drafts: > > ID: draft-ohira-assign-select-e2e-multihome-00.txt > Title: IPv6 Address Assingment and Route Selection > for End-to-End Multihoming > Speaker: FUJIKAWA Kenji (Kyoto University) > Abstract: > IPv6 suppose that network is hierarchical. Though the present IP > network topology is not hierarchical at the point of multihoming. > > In this document, we clarify that > a) how to assign address blocks to ISPs and sites in order to > achieve multihome environment without destroying hierarchical > structure of IPv6 > b) requirements in order for end hosts to select an adequete route > from multiple routes when multihoming. > > ID: draft-arifumi-lin6-multihome-api-00.txt > Title: Basic Socket API Extensions for LIN6 End-to-End Multihoming > Speaker: Arifumi Matsumoto (Kyoto University) > Abstract: > This document describes a method for multihoming support in > application layer. We extend the basic socket API(Application > Programming Interface) and propose some new interfaces for > multihoming. Multihoming nodes are expected to have multiple > addresses. The existing socket APIs, however, are not designed to > manipulate multiple addresses in a connection. Proposed APIs help =20= > an > application to handle multiple addresses, to avoid connection =20 > failure > and to do load-balancing possibly. Right now, the proposed APIs = are > for LIN6 nodes, one of the mobile protocols. This is because = LIN6's > addressing architecture, which is called "8+8", is very friendly = and > consistent with multihoming. In this document, we propose a host- > based multihoming solution and which is called end-to-end > multihoming. In end-to-end multihoming, a fault-tolerant = connection > can be achieved relying not on routers but on the pair of end-nodes > only. > --------------------------------------------------------------- > FUJIKAWA, Kenji @ Grad. Sch. of Informatics, Kyoto Univ., Japan > WWW: http://www.lab1.kuis.kyoto-u.ac.jp/~fujikawa/index-e.html > TEL +81 75-753-5387 FAX +81 75-751-0482 > E-mail fujikawa@real-internet.org > -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPvarNaarNKXTPFCVEQIRhQCfZ1KlpXAXO/23BUQFkB9X6500y1cAn3J7 OGvnCmCzGmfz/PG2Oo8xAjLl =3DW0U/ -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Jun 23 05:25: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 FAA13680 for ; Mon, 23 Jun 2003 05:25:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19UNYr-000FOG-NU for multi6-data@psg.com; Mon, 23 Jun 2003 09:24:29 +0000 Received: from [163.117.136.121] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.14) id 19UNYo-000FNT-4b for multi6@ops.ietf.org; Mon, 23 Jun 2003 09:24:26 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 1390E43250; Mon, 23 Jun 2003 11:23:54 +0200 (CEST) Received: from varpa.it.uc3m.es (varpa.it.uc3m.es [163.117.139.253]) by smtp01.uc3m.es (Postfix) with ESMTP id 75BE199E6C; Mon, 23 Jun 2003 11:23:54 +0200 (CEST) Received: from localhost.localdomain (marcelo@presto.it.uc3m.es [163.117.139.134]) by varpa.it.uc3m.es (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id LAA27176; Mon, 23 Jun 2003 11:23:53 +0200 X-Authentication-Warning: varpa.it.uc3m.es: Host marcelo@presto.it.uc3m.es [163.117.139.134] claimed to be localhost.localdomain Subject: Re: HIP Mobility and multihoming draft has reached the repositories From: marcelo bagnulo To: Pekka Nikander Cc: hipsec@lists.freeswan.org, multi6@ops.ietf.org In-Reply-To: <3EF1BE57.1020108@nomadiclab.com> References: <3EF1BE57.1020108@nomadiclab.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 23 Jun 2003 11:23:33 +0200 Message-Id: <1056360213.522.64.camel@presto> Mime-Version: 1.0 X-Spam-Status: No, hits=-36.7 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN, X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-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 really liked the draft, thanks for submitting it. Some comments. - I guess that an end to end path failure detection mechanism is required in order to detect when the multi-homed node has to send the REA packet. I think that a general mechanism (meaning that it works properly with any transport layer that is being used for the communication) is needed. A possible option would be to use some sort of keepalives between the communicating hosts, you can even use ICMP packets. However, if this is the case, i guess that it would be better to define a new type of packet (perhaps a HIP packet) to avoid the ICMP filtering issues. - I fail to understand the proposed transition mechanism. If i understood it correctly, the idea is to build FAs somewhere in the Internet. These FAs will be used for mobility support, in which case they will located in the mobile node "home network". Also, these FAs will be used to support backward compatibility, so that no-hip enabled nodes can communicate with hip enabled nodes for mutli-homing support. In this case, where do you place the FA?, and what addresses does it provide) (meaning from where does it obtains the addresses) i guess you cannot put it in the mutli-homed network, since it is the one that may become unreachable. So you can place it in the ISPs network, but in this case it would obtains addresses from the isp, so the effect is similar to only use a single isp. Another option is to place it on a higher level isp, and obtain addresses from it. However, i guess that this isp will not do it for free, since it will have to carry all the traffic generated by non hip enabled hosts, that i guess will be pretty high in the beginning. And, another question related to this is which addresses are announced in the DNS? I mean suppose that a multi-homed site is using HIP and it is using a HA, then which addresses does it announce in the DNS? - A minor comment.. In page 9 "The purpose of the interfaces is to group the addresses into collections that are likely to experience fate sharing. For example, if the host needs to change its addresses on interface2, it is likely that both address21 and address22 will simultaneously become obsolete." While this section is a general section, this comment seems to me to be too mobility oriented. I mean if the mechanism is being used for multi-homing support, an address can become unreachable while the other one is not" Besides, i am not really certain that "The interfaces are logical objects.", pseudo or virtual interfaces perhaps, but i would say that real physical interfaces are the most natural interfaces. Thanks, marcelo On Thu, 2003-06-19 at 15:44, Pekka Nikander wrote: > http://www.ietf.org/internet-drafts/draft-nikander-hip-mm-00.txt > > --Pekka Nikander > > From owner-multi6@ops.ietf.org Mon Jun 23 11:15: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 LAA23998 for ; Mon, 23 Jun 2003 11:15:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19UT0o-0009U2-KJ for multi6-data@psg.com; Mon, 23 Jun 2003 15:13:42 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.14) id 19UT0j-0009Rq-Uy for multi6@ops.ietf.org; Mon, 23 Jun 2003 15:13:38 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19UT0i-000Hit-RA for multi6@ops.ietf.org; Mon, 23 Jun 2003 08:13:36 -0700 Message-ID: <3wwufdp8j9.wl@bmdi2216.bmobile.ne.jp> In-Reply-To: References: <200306200036.JAA10113@necom830.hpcl.titech.ac.jp> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Mon, 23 Jun 2003 16:17:30 +0900 From: FUJIKAWA Kenji To: Kurt Erik Lindqvist Cc: multi6@ops.ietf.org Subject: Re: Call for presentations X-Spam-Status: No, hits=-15.5 required=5.0 tests=BAYES_10,IN_REP_TO,REFERENCES version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk [ 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. ] Kurt; We have already submitted internet-drafts that are related to multi6 WG. They can be downloded from http://www.users.kudpc.kyoto-u.ac.jp/~r52802/draft-ohira-assign-select-e2e-multihome-00.txt and http://hage.tori.cc/~arifumi/draft-arifumi-lin6-multihome-api-00.txt , and will be downloded from ftp.ietf.org soon. We would like to make presentations abount them, so would you assign slots for us? We'll be glad if you assign 15min for each draft. FYI, we now manage more than 200 wireless APs based on 802.11b in Kyoto city, Japan, and all of them supports IPv6. We are also planning to multihome them. I believe our platform is the largest IPv6 wireless environment in the world, and will be the largest wireless multihomed environment. The followings are detailed information on drafts: ID: draft-ohira-assign-select-e2e-multihome-00.txt Title: IPv6 Address Assingment and Route Selection for End-to-End Multihoming Speaker: FUJIKAWA Kenji (Kyoto University) Abstract: IPv6 suppose that network is hierarchical. Though the present IP network topology is not hierarchical at the point of multihoming. In this document, we clarify that a) how to assign address blocks to ISPs and sites in order to achieve multihome environment without destroying hierarchical structure of IPv6 b) requirements in order for end hosts to select an adequete route from multiple routes when multihoming. ID: draft-arifumi-lin6-multihome-api-00.txt Title: Basic Socket API Extensions for LIN6 End-to-End Multihoming Speaker: Arifumi Matsumoto (Kyoto University) Abstract: This document describes a method for multihoming support in application layer. We extend the basic socket API(Application Programming Interface) and propose some new interfaces for multihoming. Multihoming nodes are expected to have multiple addresses. The existing socket APIs, however, are not designed to manipulate multiple addresses in a connection. Proposed APIs help an application to handle multiple addresses, to avoid connection failure and to do load-balancing possibly. Right now, the proposed APIs are for LIN6 nodes, one of the mobile protocols. This is because LIN6's addressing architecture, which is called "8+8", is very friendly and consistent with multihoming. In this document, we propose a host- based multihoming solution and which is called end-to-end multihoming. In end-to-end multihoming, a fault-tolerant connection can be achieved relying not on routers but on the pair of end-nodes only. --------------------------------------------------------------- FUJIKAWA, Kenji @ Grad. Sch. of Informatics, Kyoto Univ., Japan WWW: http://www.lab1.kuis.kyoto-u.ac.jp/~fujikawa/index-e.html TEL +81 75-753-5387 FAX +81 75-751-0482 E-mail fujikawa@real-internet.org From owner-multi6@ops.ietf.org Mon Jun 23 12:11: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 MAA26715 for ; Mon, 23 Jun 2003 12:11:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19UTuE-000Apn-Vp for multi6-data@psg.com; Mon, 23 Jun 2003 16:10:58 +0000 Received: from [163.117.136.121] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.14) id 19UTuA-000Ako-MA for multi6@ops.ietf.org; Mon, 23 Jun 2003 16:10:54 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id DA434431B0; Mon, 23 Jun 2003 18:10:23 +0200 (CEST) Received: from varpa.it.uc3m.es (varpa.it.uc3m.es [163.117.139.253]) by smtp01.uc3m.es (Postfix) with ESMTP id C909499E9C; Mon, 23 Jun 2003 18:10:23 +0200 (CEST) Received: from localhost.localdomain (marcelo@presto.it.uc3m.es [163.117.139.134]) by varpa.it.uc3m.es (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id SAA20095; Mon, 23 Jun 2003 18:10:23 +0200 X-Authentication-Warning: varpa.it.uc3m.es: Host marcelo@presto.it.uc3m.es [163.117.139.134] claimed to be localhost.localdomain Subject: About draft-arifumi-lin6-multihome-api-00.txt (was Re: Call for presentations) From: marcelo bagnulo To: FUJIKAWA Kenji Cc: multi6@ops.ietf.org In-Reply-To: <3wwufdp8j9.wl@bmdi2216.bmobile.ne.jp> References: <200306200036.JAA10113@necom830.hpcl.titech.ac.jp> <3wwufdp8j9.wl@bmdi2216.bmobile.ne.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 23 Jun 2003 18:10:02 +0200 Message-Id: <1056384603.516.22.camel@presto> Mime-Version: 1.0 X-Spam-Status: No, hits=-39.4 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN, X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-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 some questions about draft-arifumi-lin6-multihome-api-00.txt. I fail to understand the idea behind this proposal. I mean, if i understand correctly, the draft proposes an API that it is capable of handling the multiple address that result when a site is multi-homed and it uses PA addresses. However, it seems somehow linked to LIN6 (LIN6 is mentioned multiple times in the document), but i fail to understand how. AFAIK LIN6 maps multiple different addresses in a single address, making the change of address transparent to transport layer and above. So LIN6 handles multiple addresses in the IP layer making it transparent to upper layers and the proposed draft proposes a way to handle multiple addresses. How is this compatible? i mean the upper layers, see one LIN6 address or multiple addresses? If the upper layers are aware of the multiple address, what do you need LIN6 for? An additional question is about address discovery. I mean how do the end nodes find out what addresses are available at the other end? There is a mapping agent mentioned, but where is this mapping agent located? which addresses does it announce? all the available addresses or just the ones that are reachable at the moment? if the latter, how does it find out whether an address is reachable or not? Another question is related to security, i.e. how do you authenticate the addresses actually belong to the node that is claiming its ownership? This is a very important and difficult issue as far i can tell, and it should be addressed. Finally, how the multi-homed node communicates the alternative address to be used when the address that is being used fails? I hope you clarify these issues to me, thanks, marcelo On Mon, 2003-06-23 at 09:17, FUJIKAWA Kenji 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. ] > > Kurt; > > We have already submitted internet-drafts that are related > to multi6 WG. They can be downloded from > http://www.users.kudpc.kyoto-u.ac.jp/~r52802/draft-ohira-assign-select-e2e-multihome-00.txt > and > http://hage.tori.cc/~arifumi/draft-arifumi-lin6-multihome-api-00.txt > , and will be downloded from ftp.ietf.org soon. > > We would like to make presentations abount them, so would > you assign slots for us? We'll be glad if you assign 15min > for each draft. > > FYI, we now manage more than 200 wireless APs based on > 802.11b in Kyoto city, Japan, and all of them supports > IPv6. We are also planning to multihome them. I believe our > platform is the largest IPv6 wireless environment in the > world, and will be the largest wireless multihomed > environment. > > The followings are detailed information on drafts: > > ID: draft-ohira-assign-select-e2e-multihome-00.txt > Title: IPv6 Address Assingment and Route Selection > for End-to-End Multihoming > Speaker: FUJIKAWA Kenji (Kyoto University) > Abstract: > IPv6 suppose that network is hierarchical. Though the present IP > network topology is not hierarchical at the point of multihoming. > > In this document, we clarify that > a) how to assign address blocks to ISPs and sites in order to > achieve multihome environment without destroying hierarchical > structure of IPv6 > b) requirements in order for end hosts to select an adequete route > from multiple routes when multihoming. > > ID: draft-arifumi-lin6-multihome-api-00.txt > Title: Basic Socket API Extensions for LIN6 End-to-End Multihoming > Speaker: Arifumi Matsumoto (Kyoto University) > Abstract: > This document describes a method for multihoming support in > application layer. We extend the basic socket API(Application > Programming Interface) and propose some new interfaces for > multihoming. Multihoming nodes are expected to have multiple > addresses. The existing socket APIs, however, are not designed to > manipulate multiple addresses in a connection. Proposed APIs help an > application to handle multiple addresses, to avoid connection failure > and to do load-balancing possibly. Right now, the proposed APIs are > for LIN6 nodes, one of the mobile protocols. This is because LIN6's > addressing architecture, which is called "8+8", is very friendly and > consistent with multihoming. In this document, we propose a host- > based multihoming solution and which is called end-to-end > multihoming. In end-to-end multihoming, a fault-tolerant connection > can be achieved relying not on routers but on the pair of end-nodes > only. > --------------------------------------------------------------- > FUJIKAWA, Kenji @ Grad. Sch. of Informatics, Kyoto Univ., Japan > WWW: http://www.lab1.kuis.kyoto-u.ac.jp/~fujikawa/index-e.html > TEL +81 75-753-5387 FAX +81 75-751-0482 > E-mail fujikawa@real-internet.org > > > > From owner-multi6@ops.ietf.org Mon Jun 23 12:17: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 MAA27125 for ; Mon, 23 Jun 2003 12:17:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19UTza-000Cva-UO for multi6-data@psg.com; Mon, 23 Jun 2003 16:16:30 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19UTzV-000CsD-WF for multi6@ops.ietf.org; Mon, 23 Jun 2003 16:16:26 +0000 From: Masataka Ohta Message-Id: <200306231609.BAA11533@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id BAA11533; Tue, 24 Jun 2003 01:08:47 +0859 Subject: Re: Call for presentations In-Reply-To: <1A243EFE-A15F-11D7-9791-000393A638B2@kurtis.pp.se> from Kurt Erik Lindqvist at "Jun 18, 2003 09:33:06 am" To: Kurt Erik Lindqvist Date: Tue, 24 Jun 2003 01:08:46 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-7.1 required=5.0 tests=BAYES_30,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; > With this mail I would like to ask for presentations for the first slot > of the multi6 WG. > > Please send me > > - - Presenters name Masataka Ohta > - - Draft name draft-ohta-multihomed-isps-00.txt (just submitted) > - - Rough time estimate needed 10 min. The draft is attached. Masataka Ohta INTERNET DRAFT M. Ohta draft-ohta-multihomed-isps-00.txt Tokyo Institute of Technology June 2003 Multihomed ISPs and Policy Control 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 Policy control of next level ISPs, delegated address spaces from top level ISPs, is discussed. While global policy coodination requires top level aggregators, local policy can be controlled with next level aggregators. 1. Introduction Considering that some people has been arguing to have 4 byte AS numbers, the number of ISPs will grow indifinitely On the other hand, having small number of TLIs will make full routing table small that it can be expected that most hosts has full routing table, reducing the problems with destination and source address selection. An obvious solution is to have layers of ISPs, as was specified in IPv6 to have TLA (Top Level Aggregator) and NLA (Next Level Aggregator) that they can be allocated to TLIs (Top Level ISPs) and M. Ohta Expires on December 23, 2003 [Page 1] INTERNET DRAFT Multihomed ISPs and Policy Control June 2003 NLIs (Next Level ISPs, correspondingly. The probelm, however, is whethere and how the number of TLIs can be controlled. 2. Robustness An essential property of ISPs is robustness of its service that it is almost mandately that NLIs are multihomed to multiple TLIs. It is, then, expected that some sites are multihomed to multiple TLIs and/or NLIs. It is expected that NLIs have multiple prefixes each belonging to multiple TLAs, all of which is delegated to sites. 3. BGP Policy Control BGP Policy is controlled by identifying ISPs not by address prefix but by AS numbers. Thus, a next level ISP not having its own TLA can still fully control its policy. Moreover, neighbour ISPs can adjust their policy using the full prefix of the ISP. However, to limit the size of global routing table, an AS and prefixes of the next level ISP at the distance must be discarded or merged with its TLA. But, it is better than a current multihoming practice that prefix of a multihomed site is propagated locally to give robustness against local failures, because multiple TLAs give robustness against global failures. Thus, it is not essential that ISPs have their own TLAs. 4. Limiting the Number of TLAs. There should be hard upper bound on the number of TLAs in the Internet. For example, some TLA may be supplied from RIRs with bidding. Some TLA may be allocated to each country (proportional to the population of the country) and delivered with the countrie's policy. M. Ohta Expires on December 23, 2003 [Page 2] INTERNET DRAFT Multihomed ISPs and Policy Control June 2003 The proper number of TLAs, it seems to the author, should be somewhere between 1024 and 8192. 5. 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 December 23, 2003 [Page 3] From owner-multi6@ops.ietf.org Mon Jun 23 12:18: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 MAA27160 for ; Mon, 23 Jun 2003 12:18:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19UTzX-000CuH-Fl for multi6-data@psg.com; Mon, 23 Jun 2003 16:16:27 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19UTzT-000CsD-Sx for multi6@ops.ietf.org; Mon, 23 Jun 2003 16:16:24 +0000 From: Masataka Ohta Message-Id: <200306231607.BAA11529@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id BAA11529; Tue, 24 Jun 2003 01:07:19 +0900 Subject: Re: Call for presentations In-Reply-To: <1A243EFE-A15F-11D7-9791-000393A638B2@kurtis.pp.se> from Kurt Erik Lindqvist at "Jun 18, 2003 09:33:06 am" To: Kurt Erik Lindqvist Date: Tue, 24 Jun 2003 01:07:19 +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; > With this mail I would like to ask for presentations for the first slot > of the multi6 WG. > > Please send me > > - - Presenters name Masataka Ohta > - - Draft name draft-ohta-e2e-multihoming-*.txt (-04- just submitted) > - - Rough time estimate needed 20 min. Masataka Ohta From owner-multi6@ops.ietf.org Mon Jun 23 12:25: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 MAA27426 for ; Mon, 23 Jun 2003 12:25:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19UU7L-000F8c-D9 for multi6-data@psg.com; Mon, 23 Jun 2003 16:24:31 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19UU7I-000F7m-J6 for multi6@ops.ietf.org; Mon, 23 Jun 2003 16:24:28 +0000 From: Masataka Ohta Message-Id: <200306231618.BAA11664@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id BAA11664; Tue, 24 Jun 2003 01:17:59 +0859 Subject: Re: Call for presentations In-Reply-To: from Kurt Erik Lindqvist at "Jun 20, 2003 06:25:04 pm" To: Kurt Erik Lindqvist Date: Tue, 24 Jun 2003 01:17:57 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-9.2 required=5.0 tests=BAYES_20,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; > > When will the presentations for the second slot be requested? > > To be honest, I have not planned on making a specific announcement for > the second slot. > Our intention is to use the first slot for presentations on multi6 > related topics (architecture, solutions, cookie recipes, what you want) > . If we have a serious problem with time in the first slot we can let > that spill into the second slot(currently this does not seem to be an > issue), Then, it is just a call for presentation, not specifically to the first one. > but the second slot is meant for discussions on how we should > move forward and what the architecture should be. So the first slot is > to be seen as input for the second one. Note that we expect the design > team to present their work in the second slot as well. So, you have got a slot from Randy, even though the agenda is empty. Good job. Masataka Ohta From owner-multi6@ops.ietf.org Mon Jun 23 12:56: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 MAA28693 for ; Mon, 23 Jun 2003 12:56:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19UUbc-000HHD-Pk for multi6-data@psg.com; Mon, 23 Jun 2003 16:55:48 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.14) id 19UUbZ-000HEr-Df for multi6@ops.ietf.org; Mon, 23 Jun 2003 16:55:45 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id A4D5D431FC; Mon, 23 Jun 2003 18:55:14 +0200 (CEST) Received: from varpa.it.uc3m.es (varpa.it.uc3m.es [163.117.139.253]) by smtp02.uc3m.es (Postfix) with ESMTP id 947E199FAC; Mon, 23 Jun 2003 18:55:14 +0200 (CEST) Received: from localhost.localdomain (marcelo@presto.it.uc3m.es [163.117.139.134]) by varpa.it.uc3m.es (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id SAA12475; Mon, 23 Jun 2003 18:55:13 +0200 X-Authentication-Warning: varpa.it.uc3m.es: Host marcelo@presto.it.uc3m.es [163.117.139.134] claimed to be localhost.localdomain Subject: about draft-ohira-assign-select-e2e-multihome-00.txt (was :Re: Call for presentations) From: marcelo bagnulo To: FUJIKAWA Kenji Cc: multi6@ops.ietf.org In-Reply-To: <3wwufdp8j9.wl@bmdi2216.bmobile.ne.jp> References: <200306200036.JAA10113@necom830.hpcl.titech.ac.jp> <3wwufdp8j9.wl@bmdi2216.bmobile.ne.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 23 Jun 2003 18:54:53 +0200 Message-Id: <1056387293.525.31.camel@presto> Mime-Version: 1.0 X-Spam-Status: No, hits=-40.2 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN, X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-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, From the conclusions: " The proposed way of multihome does not destroy the hierarchical structure of address space nor increase routing informations explosively because the addresses which are assigned to multihome site are always subsets of address space of upstream ISPs. All routers in a network do not have to concern about the route of outside of the network. This way of multihome can deal with source address filtering" What do you mean by "the proposed way to multi-home"? I mean, I couldn't find in the draft a description of any mechanisms to multi-home... I guess that there should be a reference to a concrete mechanism proposal, Otha's e2e multihoming perhaps? but there are no references in the draft, could you clarify this form me? Besides, if i understand the draft correctly, it is about ingress filtering and source address based routing, so have you checked C. Huitema's draft about host centric multi-homing? Thanks, marcelo On Mon, 2003-06-23 at 09:17, FUJIKAWA Kenji 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. ] > > Kurt; > > We have already submitted internet-drafts that are related > to multi6 WG. They can be downloded from > http://www.users.kudpc.kyoto-u.ac.jp/~r52802/draft-ohira-assign-select-e2e-multihome-00.txt > and > http://hage.tori.cc/~arifumi/draft-arifumi-lin6-multihome-api-00.txt > , and will be downloded from ftp.ietf.org soon. > > We would like to make presentations abount them, so would > you assign slots for us? We'll be glad if you assign 15min > for each draft. > > FYI, we now manage more than 200 wireless APs based on > 802.11b in Kyoto city, Japan, and all of them supports > IPv6. We are also planning to multihome them. I believe our > platform is the largest IPv6 wireless environment in the > world, and will be the largest wireless multihomed > environment. > > The followings are detailed information on drafts: > > ID: draft-ohira-assign-select-e2e-multihome-00.txt > Title: IPv6 Address Assingment and Route Selection > for End-to-End Multihoming > Speaker: FUJIKAWA Kenji (Kyoto University) > Abstract: > IPv6 suppose that network is hierarchical. Though the present IP > network topology is not hierarchical at the point of multihoming. > > In this document, we clarify that > a) how to assign address blocks to ISPs and sites in order to > achieve multihome environment without destroying hierarchical > structure of IPv6 > b) requirements in order for end hosts to select an adequete route > from multiple routes when multihoming. > > ID: draft-arifumi-lin6-multihome-api-00.txt > Title: Basic Socket API Extensions for LIN6 End-to-End Multihoming > Speaker: Arifumi Matsumoto (Kyoto University) > Abstract: > This document describes a method for multihoming support in > application layer. We extend the basic socket API(Application > Programming Interface) and propose some new interfaces for > multihoming. Multihoming nodes are expected to have multiple > addresses. The existing socket APIs, however, are not designed to > manipulate multiple addresses in a connection. Proposed APIs help an > application to handle multiple addresses, to avoid connection failure > and to do load-balancing possibly. Right now, the proposed APIs are > for LIN6 nodes, one of the mobile protocols. This is because LIN6's > addressing architecture, which is called "8+8", is very friendly and > consistent with multihoming. In this document, we propose a host- > based multihoming solution and which is called end-to-end > multihoming. In end-to-end multihoming, a fault-tolerant connection > can be achieved relying not on routers but on the pair of end-nodes > only. > --------------------------------------------------------------- > FUJIKAWA, Kenji @ Grad. Sch. of Informatics, Kyoto Univ., Japan > WWW: http://www.lab1.kuis.kyoto-u.ac.jp/~fujikawa/index-e.html > TEL +81 75-753-5387 FAX +81 75-751-0482 > E-mail fujikawa@real-internet.org > > > > From owner-multi6@ops.ietf.org Mon Jun 23 14:44: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 OAA03631 for ; Mon, 23 Jun 2003 14:44:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19UWDe-0000m0-8F for multi6-data@psg.com; Mon, 23 Jun 2003 18:39:10 +0000 Received: from [163.117.136.121] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.14) id 19UWDZ-0000kX-0p for multi6@ops.ietf.org; Mon, 23 Jun 2003 18:39:05 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 4A21143235; Mon, 23 Jun 2003 20:38:34 +0200 (CEST) Received: from varpa.it.uc3m.es (varpa.it.uc3m.es [163.117.139.253]) by smtp01.uc3m.es (Postfix) with ESMTP id E568599E6C; Mon, 23 Jun 2003 20:38:33 +0200 (CEST) Received: from localhost.localdomain (marcelo@presto.it.uc3m.es [163.117.139.134]) by varpa.it.uc3m.es (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id UAA07801; Mon, 23 Jun 2003 20:38:33 +0200 X-Authentication-Warning: varpa.it.uc3m.es: Host marcelo@presto.it.uc3m.es [163.117.139.134] claimed to be localhost.localdomain Subject: About NAROS From: marcelo bagnulo To: Cedric de Launois Cc: multi6@ops.ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 23 Jun 2003 20:38:12 +0200 Message-Id: <1056393493.525.67.camel@presto> Mime-Version: 1.0 X-Spam-Status: No, hits=-13.5 required=5.0 tests=BAYES_10,USER_AGENT_XIMIAN,X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-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 Cedric, About NAROS for TE, i was wondering if policy table defined in RFC 3484 could provide the capabilities needed for performing TE? I mean, RFC 3484 defines a policy table that is to be used for defining policies, such as which source address to prefer when reaching a given destination address, which i think is what the NAROS TE application achieves. So i was thinking why not just complete the table with the sites policies to achieve this goal. The problem is that currently there is no way to dynamically configure the policy table, so NAROS could be used for this. In this way, once the hosts obtains the policy information, it configures its policy table and uses it for following packets. An alternative option would be to define a new dhcp option to configure the policy table, so that when the hosts boots it obtains the policy table configuration from the dhcp server. The problem with this solution would be if the policy table is too large or too dynamic, in which case, i guess that using NAROS would provide better performance. Another option would be to use the NAROS server a single point for specifying policy and that the dhcp server obtain the policy table configuration from it. Have you considered any of these options? About fault tolerance capabilities. As defined in the draft NAROS server would only be aware of direct providers outages. However, i guess that NAROS server capabilities to select the appropriate address could be improved if the NAROS server had additional information, such as the BGP routing table, moreover, i guess that it would be interesting that the NAROS server had the bgp routing table view from each of the borders routers connected to different isps. With this information, it would be capable of knowing which addresses are reachable from each provider and perform a better address selection. However, i would say that some failures would remain undetected by the NAROS server, essentially due to aggregation. This implies that an additional mechanism for failure detection is needed, probably and e2e mechanism. Thanks, marcelo From owner-multi6@ops.ietf.org Tue Jun 24 03:52: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 DAA06567 for ; Tue, 24 Jun 2003 03:51:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19UiXY-0002ui-P7 for multi6-data@psg.com; Tue, 24 Jun 2003 07:48:32 +0000 Received: from [130.54.9.41] (helo=shield.kudpc.kyoto-u.ac.jp) by psg.com with smtp (Exim 4.14) id 19UiXT-0002uJ-PJ for multi6@ops.ietf.org; Tue, 24 Jun 2003 07:48:28 +0000 Received: by shield.kudpc.kyoto-u.ac.jp; id QAA16554; Tue, 24 Jun 2003 16:47:38 +0900 Received: from mbox.kudpc.kyoto-u.ac.jp (mbox.kudpc.kyoto-u.ac.jp [130.54.9.32]) by shield.kudpc.kyoto-u.ac.jp (8.11.6p2/8.11.3) with ESMTP id h5O7lW416482; Tue, 24 Jun 2003 16:47:35 +0900 (JST) Received: from cedric.kuis.kyoto-u.ac.jp (c192-100.rd.miako.net [43.245.192.100]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mbox.kudpc.kyoto-u.ac.jp (Postfix) with ESMTP id 45EEFB4C093; Tue, 24 Jun 2003 16:47:32 +0900 (JST) Date: Tue, 24 Jun 2003 16:47:28 +0900 From: Arifumi Matsumoto To: marcelo bagnulo Cc: fujikawa@i.kyoto-u.ac.jp, multi6@ops.ietf.org Subject: Re: About draft-arifumi-lin6-multihome-api-00.txt (was Re: Call for presentations) Message-Id: <20030624164728.1d59f85a.arifumi@kuis.kyoto-u.ac.jp> In-Reply-To: <1056384603.516.22.camel@presto> References: <200306200036.JAA10113@necom830.hpcl.titech.ac.jp> <3wwufdp8j9.wl@bmdi2216.bmobile.ne.jp> <1056384603.516.22.camel@presto> X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i386-portbld-freebsd4.7) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-29.0 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,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 Hi Marcelo, thank you for reading my document. On 23 Jun 2003 18:10:02 +0200 marcelo bagnulo wrote: > Hi, > > I have some questions about draft-arifumi-lin6-multihome-api-00.txt. > > I fail to understand the idea behind this proposal. > > I mean, if i understand correctly, the draft proposes an API that it is > capable of handling the multiple address that result when a site is > multi-homed and it uses PA addresses. > > However, it seems somehow linked to LIN6 (LIN6 is mentioned multiple > times in the document), but i fail to understand how. AFAIK LIN6 maps > multiple different addresses in a single address, making the change of > address transparent to transport layer and above. > > So LIN6 handles multiple addresses in the IP layer making it transparent > to upper layers and the proposed draft proposes a way to handle multiple > addresses. How is this compatible? i mean the upper layers, see one LIN6 > address or multiple addresses? > If the upper layers are aware of the multiple address, what do you need > LIN6 for? Your understanding about LIN6 is absolutely correct. In LIN6, the locator part of an IPv6 address isn't visible to upper layers. This makes it possible to continue existing sessions even when an LIN6 node moves and its address is changed. In this model, however, upper layers cannot make any controls on outgoing packets' address and route. This model, we think, doesn't benefit from multihoming. So we make it possible to make an special socket through which multiple locators are visible to upper layers (application layer). This special socket are implemented so that it can co-exist with normal sockets. For such a socket, LIN6 is used for address resolution, notification and registration. LIN6 layer acquires target node's addresses, registers locators to its Mapping Agents and notifies address change to the corresponding nodes and also to upper layers. > An additional question is about address discovery. I mean how do the end > nodes find out what addresses are available at the other end? There is a > mapping agent mentioned, but where is this mapping agent located? which > addresses does it announce? all the available addresses or just the ones > that are reachable at the moment? if the latter, how does it find out > whether an address is reachable or not? These issues are mentioned in LIN6's draft below. http://www.lin6.net/draft/draft-teraoka-ipng-lin6-01.txt Briefly speaking, you can get the MA's address by a kind of DNS address-to-name translations. By making a query ,where an mobile node is, to the MA, a corresponding node can get all the addresses the mobile node has even if some of the addresses aren't reachable from the corresponding node. > Another question is related to security, i.e. how do you authenticate > the addresses actually belong to the node that is claiming its > ownership? This is a very important and difficult issue as far i can > tell, and it should be addressed. This is also mentioned in the LIN6's draft above. In LIN6 layer, address information are exchanged and updated in a secure manner using cookies exchanged through a location query to the MA. > Finally, how the multi-homed node communicates the alternative address > to be used when the address that is being used fails? Our APIs, mentioned in my draft, are used for this porpose. By getaddrinfo2(), an application can acquire all the addresses of the other end node and by setsockopt() an application specify the kernel which address should used for destination/source address of outgoing packets. I hope you understand what our APIs are for and why these are based on the LIN6. Any comments are welcome. -- Arifumi Matsumoto (arifumi@kuis.kyoto-u.ac.jp) Kyoto University From owner-multi6@ops.ietf.org Tue Jun 24 10: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 KAA18259 for ; Tue, 24 Jun 2003 10:27:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Uojj-000GKi-0q for multi6-data@psg.com; Tue, 24 Jun 2003 14:25:31 +0000 Received: from [130.104.229.109] (helo=info.ucl.ac.be) by psg.com with esmtp (Exim 4.14) id 19Uoje-000GKO-UZ for multi6@ops.ietf.org; Tue, 24 Jun 2003 14:25:27 +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 h5OENXJX016462; Tue, 24 Jun 2003 16:23:33 +0200 (MET DST) Subject: Re: About NAROS From: Cedric de Launois To: marcelo bagnulo Cc: multi6@ops.ietf.org In-Reply-To: <1056393493.525.67.camel@presto> References: <1056393493.525.67.camel@presto> Content-Type: text/plain; charset=iso-8859-1 Organization: Universite Catholique de Louvain Message-Id: <1056464736.2441.17.camel@descartes> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 24 Jun 2003 16:25:36 +0200 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-28.8 required=5.0 tests=BAYES_20,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 lun 23/06/2003 à 20:38, marcelo bagnulo a écrit : > Hi Cedric, > > About NAROS for TE, i was wondering if policy table defined in RFC 3484 > could provide the capabilities needed for performing TE? > I mean, RFC 3484 defines a policy table that is to be used for defining > policies, such as which source address to prefer when reaching a given > destination address, which i think is what the NAROS TE application > achieves. > So i was thinking why not just complete the table with the sites > policies to achieve this goal. > The problem is that currently there is no way to dynamically configure > the policy table, so NAROS could be used for this. In this way, once the > hosts obtains the policy information, it configures its policy table and > uses it for following packets. This is precisely what we were thinking of when we wrote in the draft "[NAROS] complements [...] the default IPv6 source address selection algorithm". > An alternative option would be to define a new dhcp option to configure > the policy table, so that when the hosts boots it obtains the policy > table configuration from the dhcp server. The problem with this solution > would be if the policy table is too large or too dynamic, in which case, > i guess that using NAROS would provide better performance. Another > option would be to use the NAROS server a single point for specifying > policy and that the dhcp server obtain the policy table configuration > from it. Have you considered any of these options? Our starting point is quite different : we require TE capabilities. So we need a system which can dynamically adapt to the situation (failure, load unbalance, etc.). And the policy table seems to be both too large and too dynamic for DHCP. If a site uses NAROS, it can get, for the same price, TE capabilities. And I feel the use of DHCP would only mitigate TE. > About fault tolerance capabilities. As defined in the draft NAROS server > would only be aware of direct providers outages. However, i guess that > NAROS server capabilities to select the appropriate address could be > improved if the NAROS server had additional information, such as the BGP > routing table, moreover, i guess that it would be interesting that the > NAROS server had the bgp routing table view from each of the borders > routers connected to different isps. Agreed ! When we evaluated the NAROS performances, we used a BGP table to find the BGP prefix associated to the destination address. This is because we imagine this solution, where a NAROS server is located on each site exit router, and so gets access to a BGP table. Using this BGP table, it can find (or not) a route towards the destination and it can somehow transmit this connectivity information to a host. However, we should not restrict ourself to BGP. NAROS could also use other mechanisms, e.g. active or passive probing of common destination, to know the best routes. > With this information, it would be > capable of knowing which addresses are reachable from each provider and > perform a better address selection. However, i would say that some > failures would remain undetected by the NAROS server, essentially due to > aggregation. Indeed. We are fully aware of that. > This implies that an additional mechanism for failure > detection is needed, probably and e2e mechanism. Agreed. We believe failure detection can only fully happen in the end hosts. NAROS only gives hints to select the best addresses. The hosts still make the final decision. Regards, Cédric From owner-multi6@ops.ietf.org Tue Jun 24 23:50: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 XAA05071 for ; Tue, 24 Jun 2003 23:50:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19V1Fa-000Knm-12 for multi6-data@psg.com; Wed, 25 Jun 2003 03:47:14 +0000 Received: from [130.54.9.41] (helo=shield.kudpc.kyoto-u.ac.jp) by psg.com with smtp (Exim 4.14) id 19V1FW-000KnW-Q0 for multi6@ops.ietf.org; Wed, 25 Jun 2003 03:47:11 +0000 Received: by shield.kudpc.kyoto-u.ac.jp; id MAA05675; Wed, 25 Jun 2003 12:46:18 +0900 Received: from mbox.kudpc.kyoto-u.ac.jp (mbox.kudpc.kyoto-u.ac.jp [130.54.9.32]) by shield.kudpc.kyoto-u.ac.jp (8.11.6p2/8.11.3) with ESMTP id h5P3kC405648; Wed, 25 Jun 2003 12:46:15 +0900 (JST) Received: from cedric.kuis.kyoto-u.ac.jp (c192-100.rd.miako.net [43.245.192.100]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mbox.kudpc.kyoto-u.ac.jp (Postfix) with ESMTP id 07F04B4C093; Wed, 25 Jun 2003 12:46:13 +0900 (JST) Date: Wed, 25 Jun 2003 12:46:06 +0900 From: Arifumi Matsumoto To: marcelo@it.uc3m.es Cc: fujikawa@i.kyoto-u.ac.jp, multi6@ops.ietf.org Subject: Re: About draft-arifumi-lin6-multihome-api-00.txt (was Re: Call for presentations) Message-Id: <20030625124606.72495f7c.arifumi@kuis.kyoto-u.ac.jp> In-Reply-To: <20030624164728.1d59f85a.arifumi@kuis.kyoto-u.ac.jp> References: <200306200036.JAA10113@necom830.hpcl.titech.ac.jp> <3wwufdp8j9.wl@bmdi2216.bmobile.ne.jp> <1056384603.516.22.camel@presto> <20030624164728.1d59f85a.arifumi@kuis.kyoto-u.ac.jp> X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i386-portbld-freebsd4.7) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-21.6 required=5.0 tests=BAYES_30,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, > > Another question is related to security, i.e. how do you authenticate > > the addresses actually belong to the node that is claiming its > > ownership? This is a very important and difficult issue as far i can > > tell, and it should be addressed. > > This is also mentioned in the LIN6's draft above. In LIN6 > layer, address information are exchanged and updated in > a secure manner using cookies exchanged through a location > query to the MA. I made a mistake at this point. This issue hasn't yet mentioned in this draft. But note that this simple cookie authentication mechanism has already implemented in LIN6 so that every LIN6 node can notify his addresses to his correspondent securely. There is a paper on this cookie authentication mechanism submitted by LIN6 developers. But, unfortunately, this is in japanese only. I'm not sure whether the LIN6 draft will be updated or not. -- Arifumi Matsumoto From owner-multi6@ops.ietf.org Wed Jun 25 12:01: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 MAA18757 for ; Wed, 25 Jun 2003 12:01:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19VCec-000KA8-Ax for multi6-data@psg.com; Wed, 25 Jun 2003 15:57:50 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.14) id 19VCeY-000K9c-Ad for multi6@ops.ietf.org; Wed, 25 Jun 2003 15:57:46 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 0952343242; Wed, 25 Jun 2003 17:57:36 +0200 (CEST) Received: from varpa.it.uc3m.es (varpa.it.uc3m.es [163.117.139.253]) by smtp02.uc3m.es (Postfix) with ESMTP id AAA7999FB6; Wed, 25 Jun 2003 17:57:35 +0200 (CEST) Received: from localhost.localdomain (marcelo@presto.it.uc3m.es [163.117.139.134]) by varpa.it.uc3m.es (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id RAA02937; Wed, 25 Jun 2003 17:57:34 +0200 X-Authentication-Warning: varpa.it.uc3m.es: Host marcelo@presto.it.uc3m.es [163.117.139.134] claimed to be localhost.localdomain Subject: Re: About NAROS From: marcelo bagnulo To: Cedric de Launois Cc: multi6@ops.ietf.org In-Reply-To: <1056464736.2441.17.camel@descartes> References: <1056393493.525.67.camel@presto> <1056464736.2441.17.camel@descartes> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailer: Ximian Evolution 1.0.5 Date: 25 Jun 2003 17:57:07 +0200 Message-Id: <1056556629.1060.62.camel@presto> Mime-Version: 1.0 X-Spam-Status: No, hits=-37.3 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_XIMIAN,X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable On Tue, 2003-06-24 at 16:25, Cedric de Launois wrote: > Le lun 23/06/2003 =E0 20:38, marcelo bagnulo a =E9crit :=20 > > Hi Cedric, > >=20 > > About NAROS for TE, i was wondering if policy table defined in RFC 348= 4 > > could provide the capabilities needed for performing TE? > > I mean, RFC 3484 defines a policy table that is to be used for defining > > policies, such as which source address to prefer when reaching a given > > destination address, which i think is what the NAROS TE application > > achieves. > > So i was thinking why not just complete the table with the sites > > policies to achieve this goal. >=20 > > The problem is that currently there is no way to dynamically configure > > the policy table, so NAROS could be used for this. In this way, once th= e > > hosts obtains the policy information, it configures its policy table an= d > > uses it for following packets. > This is precisely what we were thinking of when we wrote in the draft=20 > "[NAROS] complements [...] the default IPv6 source address selection > algorithm".=20 Ok. I guess that the response of the NAROS server could be used for adding an entry to the Policy table of the default address selections algorithm. So when a response from the NAROS server is obtained linking a given destination address (DA) with a source address (SA), the host can include an additional entry to the policy table with DA and SA and the same label. In this way, next packets for this DA will obtain a matching label and the default address selection algorithm can return a source address for DA. >=20 > > An alternative option would be to define a new dhcp option to configure > > the policy table, so that when the hosts boots it obtains the policy > > table configuration from the dhcp server. The problem with this solutio= n > > would be if the policy table is too large or too dynamic, in which case= , > > i guess that using NAROS would provide better performance. Another > > option would be to use the NAROS server a single point for specifying > > policy and that the dhcp server obtain the policy table configuration > > from it. Have you considered any of these options? >=20 > Our starting point is quite different : we require TE capabilities. > So we need a system which can dynamically adapt to the situation > (failure, load unbalance, etc.). And the policy table seems to be both > too large and too dynamic for DHCP. I am not sure of this. I guess this really depends on the case you are considering. First of all, failure issues will have to be addressed by other means, because only the end hosts can perform the e2e path failure detection. Then, about the policy table dynamics. I guess there may be site whose policy change very fast, but i would say that there are sites that have a somehow stable policy, that does not change everyday, so configuring the policy when the hosts boots (using dhcp) would be acceptable. About the size of the table, i would like to have more information about this. I mean some large site may have a very complex policy that has to be expressed in a way that can not be stored in hosts, but for these very large sites, would a multi-address solution be acceptable? I would say no, considering some comments made in this list. So, as i see it, very large sites may have complex policies that require a very high dynamic and a lot of space to store it, but i am not sure whether these sites will use a multi-address solution. OTOH, sites that could use multi-address solutions are more medium small sites, which i am not sure if they have such complex policies. In brief, i am just saying that i wouldn't discard dhcp yet, i think that both NAROS and dhcp could be used to configure the default address selection policy table. I think that a mechanism for configuring the policy table other than manual will be needed. =20 If a site uses NAROS, it can > get, for the same price, TE capabilities. And I feel the use of DHCP > would only mitigate TE. >=20 > > About fault tolerance capabilities. As defined in the draft NAROS serve= r > > would only be aware of direct providers outages. However, i guess that > > NAROS server capabilities to select the appropriate address could be > > improved if the NAROS server had additional information, such as the BG= P > > routing table, moreover, i guess that it would be interesting that the > > NAROS server had the bgp routing table view from each of the borders > > routers connected to different isps.=20 >=20 > Agreed ! When we evaluated the NAROS > performances, we used a BGP table to find the BGP prefix associated > to the destination address. This is because we imagine this solution, > where a NAROS server is located on each site exit router, and so > gets access to a BGP table. Yes, but my point is that the NAROS server need to know the bgp table of each border router in order to perform a better address selection. In this way, the NAROS server knows which addresses are reachable through each one of the border routers and can select the appropriate source address. I think that consulting the NAROS server is a more general approach than prefix deprecation. I mean, i guess that the only case where the prefix assigned by an ISP can be fully deprecated is when the link (or the router) to that isp fails. In this case, the NAROS server can detect it (for instance no bgp information) and it can deprecate the prefix. However, when other outages occur, such as an outage of the ISPs link with its own provider, deprecating the prefix may not be the better solution, since some of the destinations can only be reachable using this prefix. So if the NAROS server has the bgp view of all the all the border routers, it could provide the right source address for each case. Regards, marcelo =20 Using this BGP table, it can find (or not) > a route towards the destination and it can somehow transmit this > connectivity information to a host. > However, we should not restrict ourself to BGP. NAROS could also > use other mechanisms, e.g. active or passive probing of common > destination, to know the best routes. >=20 > > With this information, it would be > > capable of knowing which addresses are reachable from each provider and > > perform a better address selection. However, i would say that some > > failures would remain undetected by the NAROS server, essentially due t= o > > aggregation.=20 >=20 > Indeed. We are fully aware of that. >=20 > > This implies that an additional mechanism for failure > > detection is needed, probably and e2e mechanism. >=20 > Agreed. We believe failure detection can only fully happen in the end > hosts. NAROS only gives hints to select the best addresses. The hosts > still make the final decision. >=20 >=20 > Regards, >=20 > C=E9dric >=20 >=20 >=20 From owner-multi6@ops.ietf.org Wed Jun 25 12:33: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 MAA20367 for ; Wed, 25 Jun 2003 12:33:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19VDCg-000Lxn-Gr for multi6-data@psg.com; Wed, 25 Jun 2003 16:33:02 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.14) id 19VDCU-000LvT-OH for multi6@ops.ietf.org; Wed, 25 Jun 2003 16:32:50 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id CF29043272; Wed, 25 Jun 2003 18:32:27 +0200 (CEST) Received: from varpa.it.uc3m.es (varpa.it.uc3m.es [163.117.139.253]) by smtp02.uc3m.es (Postfix) with ESMTP id B8E9399F8D; Wed, 25 Jun 2003 18:32:27 +0200 (CEST) Received: from localhost.localdomain (marcelo@presto.it.uc3m.es [163.117.139.134]) by varpa.it.uc3m.es (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id SAA17562; Wed, 25 Jun 2003 18:32:27 +0200 X-Authentication-Warning: varpa.it.uc3m.es: Host marcelo@presto.it.uc3m.es [163.117.139.134] claimed to be localhost.localdomain Subject: Re: About draft-arifumi-lin6-multihome-api-00.txt (was Re: Call for presentations) From: marcelo bagnulo To: Arifumi Matsumoto Cc: fujikawa@i.kyoto-u.ac.jp, multi6@ops.ietf.org In-Reply-To: <20030625124606.72495f7c.arifumi@kuis.kyoto-u.ac.jp> References: <200306200036.JAA10113@necom830.hpcl.titech.ac.jp> <3wwufdp8j9.wl@bmdi2216.bmobile.ne.jp> <1056384603.516.22.camel@presto> <20030624164728.1d59f85a.arifumi@kuis.kyoto-u.ac.jp> <20030625124606.72495f7c.arifumi@kuis.kyoto-u.ac.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 25 Jun 2003 18:32:01 +0200 Message-Id: <1056558721.1060.82.camel@presto> Mime-Version: 1.0 X-Spam-Status: No, hits=-40.2 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN, X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-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-06-25 at 05:46, Arifumi Matsumoto wrote: > Hi, > > > > Another question is related to security, i.e. how do you authenticate > > > the addresses actually belong to the node that is claiming its > > > ownership? This is a very important and difficult issue as far i can > > > tell, and it should be addressed. > > > > This is also mentioned in the LIN6's draft above. In LIN6 > > layer, address information are exchanged and updated in > > a secure manner using cookies exchanged through a location > > query to the MA. > > I made a mistake at this point. This issue hasn't yet > mentioned in this draft. But note that this simple > cookie authentication mechanism has already implemented I do not know what do you mean by simple, but i would say that security issues related to multi-homing are very relevant and i am not sure that a so simple solution would do the job. Check the mobileip security issues which are addressing somehow related problems. > in LIN6 so that every LIN6 node can notify his addresses to > his correspondent securely. > There is a paper on this cookie authentication mechanism > submitted by LIN6 developers. But, unfortunately, this is > in japanese only. > > I'm not sure whether the LIN6 draft will be updated or not. > I guess that this would be a problem for your draft, especially if the solution relies on LIN6 undocumented security features (at least not documented in English :-) since we will not be capable to understand the security implications. Regards, marcelo > -- > Arifumi Matsumoto > From owner-multi6@ops.ietf.org Wed Jun 25 12:44: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 MAA20843 for ; Wed, 25 Jun 2003 12:44:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19VD6E-000La5-Fw for multi6-data@psg.com; Wed, 25 Jun 2003 16:26:22 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.14) id 19VD6A-000LZa-Kv for multi6@ops.ietf.org; Wed, 25 Jun 2003 16:26:18 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 6C7F743267; Wed, 25 Jun 2003 18:26:11 +0200 (CEST) Received: from varpa.it.uc3m.es (varpa.it.uc3m.es [163.117.139.253]) by smtp02.uc3m.es (Postfix) with ESMTP id C318499FBC; Wed, 25 Jun 2003 18:26:09 +0200 (CEST) Received: from localhost.localdomain (marcelo@presto.it.uc3m.es [163.117.139.134]) by varpa.it.uc3m.es (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id SAA13749; Wed, 25 Jun 2003 18:26:08 +0200 X-Authentication-Warning: varpa.it.uc3m.es: Host marcelo@presto.it.uc3m.es [163.117.139.134] claimed to be localhost.localdomain Subject: Re: About draft-arifumi-lin6-multihome-api-00.txt (was Re: Call for presentations) From: marcelo bagnulo To: Arifumi Matsumoto Cc: fujikawa@i.kyoto-u.ac.jp, multi6@ops.ietf.org In-Reply-To: <20030624164728.1d59f85a.arifumi@kuis.kyoto-u.ac.jp> References: <200306200036.JAA10113@necom830.hpcl.titech.ac.jp> <3wwufdp8j9.wl@bmdi2216.bmobile.ne.jp> <1056384603.516.22.camel@presto> <20030624164728.1d59f85a.arifumi@kuis.kyoto-u.ac.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 25 Jun 2003 18:25:41 +0200 Message-Id: <1056558342.1039.75.camel@presto> Mime-Version: 1.0 X-Spam-Status: No, hits=-33.5 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN, X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-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 Tue, 2003-06-24 at 09:47, Arifumi Matsumoto wrote: [...] > > Your understanding about LIN6 is absolutely correct. > In LIN6, the locator part of an IPv6 address isn't visible > to upper layers. This makes it possible to continue > existing sessions even when an LIN6 node moves and > its address is changed. > In this model, however, upper layers cannot make any > controls on outgoing packets' address and route. Ok. i think we a different idea about this. IMHO, addresses and routes are IP layer issues, above layers should not be aware of the route used and they should not select it. For above layers, IP addresses are plain identifiers of nodes. This > model, we think, doesn't benefit from multihoming. > I do not see what you mean. If the ip layer preserves the established sessions using a mechanism such as LIN6 or whatever, i would say that the host is benefiting from multi-homing. So we make it possible to make an special socket through > which multiple locators are visible to upper layers > (application layer). This special socket are implemented > so that it can co-exist with normal sockets. > For such a socket, LIN6 is used for address resolution, > notification and registration. LIN6 layer acquires > target node's addresses, registers locators to its > Mapping Agents and notifies address change to the > corresponding nodes and also to upper layers. > > > An additional question is about address discovery. I mean how do the end > > nodes find out what addresses are available at the other end? There is a > > mapping agent mentioned, but where is this mapping agent located? which > > addresses does it announce? all the available addresses or just the ones > > that are reachable at the moment? if the latter, how does it find out > > whether an address is reachable or not? > > These issues are mentioned in LIN6's draft below. > http://www.lin6.net/draft/draft-teraoka-ipng-lin6-01.txt > Briefly speaking, you can get the MA's address by a kind > of DNS address-to-name translations. By making a query > ,where an mobile node is, to the MA, a corresponding node > can get all the addresses the mobile node has even if some > of the addresses aren't reachable from the corresponding > node. > So in the multi-homing scenario, where would those MAs should be? Thanks, marcelo > > Another question is related to security, i.e. how do you authenticate > > the addresses actually belong to the node that is claiming its > > ownership? This is a very important and difficult issue as far i can > > tell, and it should be addressed. > > This is also mentioned in the LIN6's draft above. In LIN6 > layer, address information are exchanged and updated in > a secure manner using cookies exchanged through a location > query to the MA. > > > Finally, how the multi-homed node communicates the alternative address > > to be used when the address that is being used fails? > > Our APIs, mentioned in my draft, are used for this porpose. > By getaddrinfo2(), an application can acquire all the > addresses of the other end node and by setsockopt() > an application specify the kernel which address should > used for destination/source address of outgoing packets. > > > I hope you understand what our APIs are for and why these > are based on the LIN6. > Any comments are welcome. > > -- > Arifumi Matsumoto (arifumi@kuis.kyoto-u.ac.jp) > Kyoto University > From owner-multi6@ops.ietf.org Thu Jun 26 01:47: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 BAA27145 for ; Thu, 26 Jun 2003 01:47:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19VPYa-000NGD-Sw for multi6-data@psg.com; Thu, 26 Jun 2003 05:44:28 +0000 Received: from [130.54.22.68] (helo=century.kuis.kyoto-u.ac.jp) by psg.com with esmtp (Exim 4.14) id 19VPYX-000NG0-EH for multi6@ops.ietf.org; Thu, 26 Jun 2003 05:44:25 +0000 Received: (qmail 881 invoked by uid 0); 26 Jun 2003 14:44:22 +0900 Received: from century.kuis.kyoto-u.ac.jp (HELO bmdk3216.bmobile.ne.jp) (130.54.22.68) by century.kuis.kyoto-u.ac.jp with SMTP; 26 Jun 2003 14:44:22 +0900 Date: Thu, 26 Jun 2003 14:42:55 +0900 Message-ID: <3wd6h1e6n4.wl@bmdk3216.bmobile.ne.jp> From: FUJIKAWA Kenji To: marcelo bagnulo Cc: multi6@ops.ietf.org Subject: Re: about draft-ohira-assign-select-e2e-multihome-00.txt (was :Re: Call for presentations) In-Reply-To: <1056387293.525.31.camel@presto> References: <200306200036.JAA10113@necom830.hpcl.titech.ac.jp> <3wwufdp8j9.wl@bmdi2216.bmobile.ne.jp> <1056387293.525.31.camel@presto> User-Agent: Wanderlust/2.6.1 (Upside Down) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.3 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,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 Marcelo; I'm verry sorry for replying late. We are now revising this draft, and after that, we will answer this question. Regards, --------------------------------------------------------------- FUJIKAWA, Kenji @ Grad. Sch. of Informatics, Kyoto Univ., Japan WWW: http://www.lab1.kuis.kyoto-u.ac.jp/~fujikawa/index-e.html TEL +81 75-753-5387 FAX +81 75-751-0482 E-mail fujikawa@real-internet.org At 23 Jun 2003 18:54:53 +0200, marcelo bagnulo wrote: > > Hi, > > >From the conclusions: > > " The proposed way of multihome does not destroy the hierarchical > structure of address space nor increase routing informations > explosively because the addresses which are assigned to multihome > site are always subsets of address space of upstream ISPs. > > All routers in a network do not have to concern about the route of > outside of the network. > > This way of multihome can deal with source address filtering" > > What do you mean by "the proposed way to multi-home"? > > I mean, I couldn't find in the draft a description of any mechanisms to > multi-home... > > I guess that there should be a reference to a concrete mechanism > proposal, Otha's e2e multihoming perhaps? but there are no references in > the draft, could you clarify this form me? > > Besides, if i understand the draft correctly, it is about ingress > filtering and source address based routing, so have you checked C. > Huitema's draft about host centric multi-homing? > > Thanks, marcelo From owner-multi6@ops.ietf.org Thu Jun 26 10:56: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 KAA29089 for ; Thu, 26 Jun 2003 10:56:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19VY5Z-000HGD-Rl for multi6-data@psg.com; Thu, 26 Jun 2003 14:51:05 +0000 Received: from [130.104.229.109] (helo=info.ucl.ac.be) by psg.com with esmtp (Exim 4.14) id 19VY5W-000HG0-7n for multi6@ops.ietf.org; Thu, 26 Jun 2003 14:51:02 +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 h5QEKfJX003206; Thu, 26 Jun 2003 16:20:43 +0200 (MET DST) Subject: Re: About NAROS From: Cedric de Launois To: marcelo bagnulo Cc: multi6@ops.ietf.org In-Reply-To: <1056556629.1060.62.camel@presto> References: <1056393493.525.67.camel@presto> <1056464736.2441.17.camel@descartes> <1056556629.1060.62.camel@presto> Content-Type: text/plain; charset=iso-8859-1 Organization: Universite Catholique de Louvain Message-Id: <1056637369.16601.75.camel@descartes> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 26 Jun 2003 16:22:49 +0200 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-29.4 required=5.0 tests=BAYES_20,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: 8bit Le mer 25/06/2003 à 17:57, marcelo bagnulo a écrit : > Ok. I guess that the response of the NAROS server could be used for > adding an entry to the Policy table of the default address selections > algorithm. So when a response from the NAROS server is obtained linking > a given destination address (DA) with a source address (SA), the host > can include an additional entry to the policy table with DA and SA and > the same label. In this way, next packets for this DA will obtain a > matching label and the default address selection algorithm can return a > source address for DA. You got the idea. A NAROS client can process a NAROS response by simply filling the Policy table of the default address selections algorithm. Moreover, if an API is available to manage this policy table, (and according to RFC3484, it should) then the NAROS client-side part can be easily implemented in user-level. I am already thinking about possible extensions to NAROS. One idea is to add an option in a NAROS request to specify the type of service desired. For example, a host could ask the NAROS server which is the best link for video-conferencing or VoIP. The NAROS server could then reply so that the fastest link with the lowest delay is used. > > > An alternative option would be to define a new dhcp option to configure > > > the policy table, so that when the hosts boots it obtains the policy > > > table configuration from the dhcp server. The problem with this solution > > > would be if the policy table is too large or too dynamic, in which case, > > > i guess that using NAROS would provide better performance. Another > > > option would be to use the NAROS server a single point for specifying > > > policy and that the dhcp server obtain the policy table configuration > > > from it. Have you considered any of these options? > > > > Our starting point is quite different : we require TE capabilities. > > So we need a system which can dynamically adapt to the situation > > (failure, load unbalance, etc.). And the policy table seems to be both > > too large and too dynamic for DHCP. > > I am not sure of this. I guess this really depends on the case you are > considering. > > First of all, failure issues will have to be addressed by other means, > because only the end hosts can perform the e2e path failure detection. Agree again. The NAROS only gives hints about which addresses to use. NAROS is used when the host has no information to choose between two or more addresses otherwise equivalents. If a host knows (e.g. by a e2e path failure detection) that only 2 of its 3 allocated addresses can be used to reach the destination, then the host is free to asks the server to choose between the two remaining addresses. This is also why a client must always put in the NAROS request the source addresses it is willing to use. > Then, about the policy table dynamics. I guess there may be site whose > policy change very fast, but i would say that there are sites that have > a somehow stable policy, that does not change everyday, so configuring > the policy when the hosts boots (using dhcp) would be acceptable. This is a solution if you prefer extending DHCP instead of implementing the NAROS client. However, if a host is NAROS-aware, it can automatically get the full content of the [small] policy table by initiating connections using NAROS. We can simply put a large lifetime in the NAROS response. An advantage I see from the use of NAROS is that a host gets only the part of the policy table it is interested in. If you use DHCP, you'll have to transmit the full table. And maybe, only the half of this table is useful for the host. > About the size of the table, i would like to have more information about > this. I mean some large site may have a very complex policy that has to > be expressed in a way that can not be stored in hosts, but for these > very large sites, would a multi-address solution be acceptable? I would > say no, considering some comments made in this list. Two parameters can be used to limit the number of NAROS requests while keeping the number of entries in the hosts reasonable. In the evaluation in http://www.info.ucl.ac.be/people/delaunoi/naros/ We show that if one policy is associated with each BGP prefix (i.e. there are more than 100000 potential policy rules) and that the lifetime used is 300s, then 90% of the hosts issue less than about 300 requests during the whole day. The resulting server load essentially follows the traffic load and its average is 35 requests per second, for a site with more than 7500 active hosts. The cache size remained below 100 entries during the whole day for 95% of the hosts. Note that this evaluation is nearly a worst case : no filtering in the site, lots of active p2p hosts, attacks from the web (port scans...) factors that contribute to stress the NAROS system. > So, as i see it, very large sites may have complex policies that require > a very high dynamic and a lot of space to store it, but i am not sure > whether these sites will use a multi-address solution. > OTOH, sites that could use multi-address solutions are more medium small > sites, which i am not sure if they have such complex policies. You forget that we are using "dynamic policies" to perform traffic engineering. And even small sites could need load-balancing. However, I also think that other solutions can be imagined to perform basic load-balancing for tiny multihomed sites (e.g. using policy routing and/or router advertisement messages to tell the hosts how they should balance the traffic...) > In brief, i am just saying that i wouldn't discard dhcp yet, i think > that both NAROS and dhcp could be used to configure the default address > selection policy table. Ok. I'll be happy to discuss this point with you at the IETF meeting. > I think that a mechanism for configuring the > policy table other than manual will be needed. Agree. Regards, Cédric From owner-multi6@ops.ietf.org Mon Jun 30 02:52: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 CAA02793 for ; Mon, 30 Jun 2003 02:52:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19WsT8-0005S8-UV for multi6-data@psg.com; Mon, 30 Jun 2003 06:48:54 +0000 Received: from [130.54.9.41] (helo=shield.kudpc.kyoto-u.ac.jp) by psg.com with smtp (Exim 4.14) id 19WsT4-0005Rd-IA for multi6@ops.ietf.org; Mon, 30 Jun 2003 06:48:50 +0000 Received: by shield.kudpc.kyoto-u.ac.jp; id PAA26481; Mon, 30 Jun 2003 15:47:59 +0900 Received: from mbox.kudpc.kyoto-u.ac.jp (mbox.kudpc.kyoto-u.ac.jp [130.54.9.32]) by shield.kudpc.kyoto-u.ac.jp (8.11.6p2/8.11.3) with ESMTP id h5U6luU26474; Mon, 30 Jun 2003 15:47:57 +0900 (JST) Received: from cedric.kuis.kyoto-u.ac.jp (dhcp-62.life.jp.interop.net [45.0.8.62]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mbox.kudpc.kyoto-u.ac.jp (Postfix) with ESMTP id 453CCB4C093; Mon, 30 Jun 2003 15:47:57 +0900 (JST) Date: Mon, 30 Jun 2003 15:47:54 +0900 From: Arifumi Matsumoto To: marcelo bagnulo Cc: fujikawa@i.kyoto-u.ac.jp, multi6@ops.ietf.org Subject: Re: About draft-arifumi-lin6-multihome-api-00.txt (was Re: Call for presentations) Message-Id: <20030630154754.188a30bc.arifumi@kuis.kyoto-u.ac.jp> In-Reply-To: <1056558342.1039.75.camel@presto> References: <200306200036.JAA10113@necom830.hpcl.titech.ac.jp> <3wwufdp8j9.wl@bmdi2216.bmobile.ne.jp> <1056384603.516.22.camel@presto> <20030624164728.1d59f85a.arifumi@kuis.kyoto-u.ac.jp> <1056558342.1039.75.camel@presto> X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i386-portbld-freebsd4.7) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-27.5 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,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 Hi, marcelo. Sorry for I coundn't reply to you soon. Now I'm working for the coming Networld+Interop 2003.:) On 25 Jun 2003 18:25:41 +0200 marcelo bagnulo wrote: > On Tue, 2003-06-24 at 09:47, Arifumi Matsumoto wrote: > [...] > > > > > Your understanding about LIN6 is absolutely correct. > > In LIN6, the locator part of an IPv6 address isn't visible > > to upper layers. This makes it possible to continue > > existing sessions even when an LIN6 node moves and > > its address is changed. > > In this model, however, upper layers cannot make any > > controls on outgoing packets' address and route. > > Ok. i think we a different idea about this. IMHO, addresses and routes > are IP layer issues, above layers should not be aware of the route used > and they should not select it. For above layers, IP addresses are plain > identifiers of nodes. First of all, LIN6 originally does not show multiple addresses to an application layer. Most of applications do not need such information, but we believe some kinds of applications need such information. That's why we extended API of LIN6. For instance, in the current IPv4 Internet, most of applications rely a DNS resolving mechanism on a library provided by a system though, MTAs such as sendmail do resolve DNS by themselves in order to utilize multiple destinations. > This > > model, we think, doesn't benefit from multihoming. > > > I do not see what you mean. If the ip layer preserves the established > sessions using a mechanism such as LIN6 or whatever, i would say that > the host is benefiting from multi-homing. I mean LIN6 doesn't fully benefit from multi-homing. In LIN6 IP address addition and deletion is the only information used for mobility and multi-homing. When a link between the two end- points gets in trouble each node cannot detect it. The connection will be lost in a short time even both or either of the two end- points is multi-homed. I believe this kind of trouble has to be detected in transport or upper layer. > So we make it possible to make an special socket through > > which multiple locators are visible to upper layers > > (application layer). This special socket are implemented > > so that it can co-exist with normal sockets. > > For such a socket, LIN6 is used for address resolution, > > notification and registration. LIN6 layer acquires > > target node's addresses, registers locators to its > > Mapping Agents and notifies address change to the > > corresponding nodes and also to upper layers. > > > > > An additional question is about address discovery. I mean how do the end > > > nodes find out what addresses are available at the other end? There is a > > > mapping agent mentioned, but where is this mapping agent located? which > > > addresses does it announce? all the available addresses or just the ones > > > that are reachable at the moment? if the latter, how does it find out > > > whether an address is reachable or not? > > > > These issues are mentioned in LIN6's draft below. > > http://www.lin6.net/draft/draft-teraoka-ipng-lin6-01.txt > > Briefly speaking, you can get the MA's address by a kind > > of DNS address-to-name translations. By making a query > > ,where an mobile node is, to the MA, a corresponding node > > can get all the addresses the mobile node has even if some > > of the addresses aren't reachable from the corresponding > > node. > > > So in the multi-homing scenario, where would those MAs should be? An MA can co-exist in an MN itself, when the MN does not move and is multi-homed. We are also thinking the cases where multiple MAs are distributed for a sigle MN, each MA is multi-homed, and an MN moves with being multi-homed. In any case, LIN6 works pretty well. Thanks. -- Arifumi Matsumoto (arifumi@kuis.kyoto-u.ac.jp)