From autoconf-bounces@ietf.org Thu Nov 02 19:09:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfmca-0000S6-Pw; Thu, 02 Nov 2006 19:09:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfmcY-0000RX-Ff; Thu, 02 Nov 2006 19:09:18 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfmcX-0007vP-6O; Thu, 02 Nov 2006 19:09:18 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id kA309B4E010948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 2 Nov 2006 18:09:12 -0600 (CST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id kA309BCE011020; Thu, 2 Nov 2006 16:09:11 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id kA3092p7010845; Thu, 2 Nov 2006 16:09:10 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 16:09:07 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Nov 2006 16:09:06 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10177444D@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multilink subnet issues and proxy/relay DAD Thread-Index: Acb9/1Jcu7VswjOiRc2V9F+kW889RwA1oUuA From: "Templin, Fred L" To: , , , , X-OriginalArrivalTime: 03 Nov 2006 00:09:07.0508 (UTC) FILETIME=[47A7D740:01C6FEDC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: James Kempf , Dave Thaler Subject: [Autoconf] Multilink subnet issues and proxy/relay DAD X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org The question of proxy/relay DAD for multilink networks that comprise shared links has come up on the NETLMM and Autoconf mailing lists. Proxy/relay DAD is a mechanism whereby NS(DAD) messages are relayed to the link on which a node with a colliding address resides, with the colliding node's NA(DAD) being relayed back to the link on which the soliciting node resides. (The Target Link Layer Address Option in the relayed NA(DAD) must not be changed by the relays to ensure proper SEND operation in this process.) James Kempf has twice indicated that there have been prior discussions on this subject between Jari Arkko and Dave Thaler, and that they should be consulted for further information (see below), but several attempts to contact them have so far produced no results. To ensure a fair and open dialogue at IETF67, I am requesting that Jari, Dave, James and others with firsthand information address the following questions on the lists prior to the meetings: 1. What are the issues wrt proxy/relay DAD that would interfere with its adoption as a standard mechanism? 2. What harmful on-link assumptions could there be for IPv6 Prefix Information Options that advertise a shared prefix with 'L=3D0'? 3. Does the RFC1812 "subnet forwarding model" still apply to IPv6, when there are no IPv6 documents that reference RFC1812 normatively? 4. What other non-obvious issues relating to multilink subnets for shared links need to be observed for NETLMM, Autoconf and other contexts? Fred Templin fred.l.templin@boeing.com =20 -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com]=20 Sent: Wednesday, November 01, 2006 1:50 PM To: Templin, Fred L; Behcet Sarikaya; Alexandru Petrescu Cc: netlmm@ietf.org Subject: Re: How does "per-MN prefix model" simplify things? (was: RE:[netlmm]Re: PMIP follow-up questions) >You mentioned a while back that there were some discussions >involving IAB and/or IESG members that indicated there might >be some barrier to acceptance of a proxy/relay DAD solution. >Can you say anything more about that? Primarily DaveT's multi-link subnet draft. I think it would be prudent to=20 discuss the issue with him before the WG makes a decision. Also, I think we=20 should check with Jari to find out what he thinks. It is necessary that Jari=20 agree with anything the WG comes up with if we are to get IESG approval. jak=20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 03 04:02:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfuvt-0003Of-N4; Fri, 03 Nov 2006 04:01:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfuvs-0003NY-GN for autoconf@ietf.org; Fri, 03 Nov 2006 04:01:48 -0500 Received: from maile.telecomitalia.it ([156.54.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfuvj-0004EL-7C for autoconf@ietf.org; Fri, 03 Nov 2006 04:01:48 -0500 Received: from ptpxch007ba020.idc.cww.telecomitalia.it ([156.54.240.50]) by maile.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 10:01:34 +0100 Received: from PTPEVS108BA020.idc.cww.telecomitalia.it ([156.54.241.228]) by ptpxch007ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 10:01:33 +0100 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 Content-Class: urn:content-classes:message Importance: normal Priority: normal MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Autoconf] MANET subnet model Date: Fri, 3 Nov 2006 10:01:33 +0100 Message-ID: In-Reply-To: <007401c6fd0f$5646dfe0$165cfa84@SEXTANT> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] MANET subnet model thread-index: Acb88vAdFAfs5i6qSvaUpwAh6WpynQAELSygAAIuJgAAhi66EA== From: "Ruffino Simone" To: X-OriginalArrivalTime: 03 Nov 2006 09:01:33.0722 (UTC) FILETIME=[A9153FA0:01C6FF26] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: Thomas Clausen , Shubhranshu X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Dear all, I agree that is useful to enumerate all prefix assignment cases.=20 I was wondering, if it would be possible to schedule a short = presentation, during IETF67 AUTOCONF meeting, that explains the = differences and implications of each approach (if it is not already in = the agenda), maybe with examples for each one of them?=20 I feel it would be beneficial for the group to have a common = understanding, before proposing solutions that might be based on = one/some/all of the alternatives.=20 Do you think it is feasable/reasonable ? Thanks, Simone > -----Original Message----- > From: Joe Macker [mailto:joseph.macker@nrl.navy.mil]=20 > Sent: marted=EC 31 ottobre 2006 18.10 > To: 'Templin, Fred L'; 'Jari Arkko'; 'Yi, Seung' > Cc: autoconf@ietf.org > Subject: RE: [Autoconf] MANET subnet model >=20 > Fred: >=20 > It's a good idea to enumerate prefix assignment cases to=20 > help scope the work. >=20 > Do we really need to REQUIRE multi-hop DAD for all=20 > deployments? Having mechanisms TO SUPPORT IT defined is ok,=20 > but requiring it is not IMHO. So can we talk about prefix=20 > assignment cases without DAD off-link issues for now. Just a thought. >=20 > -joe >=20 > >-----Original Message----- > >From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > >Sent: Tuesday, October 31, 2006 11:39 AM > >To: Jari Arkko; Yi, Seung > >Cc: autoconf@ietf.org > >Subject: RE: [Autoconf] MANET subnet model > > > >Jari, > > > >> If it is the case that you have a well understood approach > >that avoids > >> the multilink subnet issues you should go for that. You have a=20 > >> complicated enough problem in your hands even without having to=20 > >> support multiple ways to do things. If you have a solution > >that works > >> and has no major drawbacks, standardize that. > > > >Can you clarify what you mean by this? I believe Seung's post is=20 > >essentially listing the following options for prefix assignment to=20 > >MANET interfaces: > > > > 1) shared prefix for both address configuration and on-link > > determination (i.e., prefix length shorter than 128) - > > requires that all MANET interfaces that assign the prefix > > and configure addresses from the prefix be attached to > > the same link always and run DAD on the link > > 2) shared prefix for address configuration but not on-link > > determination (i.e., prefix length =3D 128) - requires > > MANET-wide proxy-DAD in case multiple MANET interfaces > > configure duplicate addresses, but does not require > > attachment to same link > > 3) unique prefix for each MANET interface - DAD avoidance > > through operational assurance against duplication > > 4) link-local-only - requires MANET-wide proxy-DAD in case > > multiple MANET interfaces that configure the same link-local > > address might move onto the same link at some point in time. > > > >There would seem to be potential use-cases for all of these=20 > options, so=20 > >why do you say "pick one" when it seems like all may have their=20 > >appropriate use-cases? > > > >Note 1: option 4) also needs to be considered along with > > options 1) thru 3) since all MANET interfaces must > > configure a link-local address. > >Note 2: DAD can be avoided through operational assurance > > against duplication in all cases, but that would > > tend to negate SEND. > > > >Thanks - Fred > >fred.l.templin@boeing.com > > -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons = above and may contain confidential information. If you have received the = message in error, be informed that any use of the content hereof is = prohibited. Please return it immediately to the sender and delete the = message. Should you have any questions, please contact us by replying to = webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- =20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 03 09:54:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg0R2-0001A4-7u; Fri, 03 Nov 2006 09:54:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg0R1-00019z-KK for autoconf@ietf.org; Fri, 03 Nov 2006 09:54:19 -0500 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg0Qx-00051y-Cf for autoconf@ietf.org; Fri, 03 Nov 2006 09:54:19 -0500 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.6+Sun/8.12.8) with SMTP id kA3Es2wW024050; Fri, 3 Nov 2006 09:54:02 -0500 (EST) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2006110309545732422 ; Fri, 03 Nov 2006 09:54:57 -0500 From: "Joe Macker" To: "'Ruffino Simone'" , Subject: RE: [Autoconf] MANET subnet model Date: Fri, 3 Nov 2006 09:53:59 -0500 Message-ID: <00bf01c6ff57$e5441600$165cfa84@SEXTANT> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acb88vAdFAfs5i6qSvaUpwAh6WpynQAELSygAAIuJgAAhi66EAAMgP3Q X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: 'Thomas Clausen' , 'Shubhranshu' X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org A few of us have discussed having a slide or two on some basic = assumptions and cases. I think this is planned and your comment is well taken. We would also likely discuss the configuration/bahavior model for the MANET wireless interface. -Joe >-----Original Message----- >From: Ruffino Simone [mailto:simone.ruffino@telecomitalia.it]=20 >Sent: Friday, November 03, 2006 4:02 AM >To: autoconf@ietf.org >Cc: Thomas Clausen; Shubhranshu >Subject: RE: [Autoconf] MANET subnet model > >Dear all, > >I agree that is useful to enumerate all prefix assignment cases.=20 > >I was wondering, if it would be possible to schedule a short=20 >presentation, during IETF67 AUTOCONF meeting, that explains=20 >the differences and implications of each approach (if it is=20 >not already in the agenda), maybe with examples for each one of them?=20 > >I feel it would be beneficial for the group to have a common=20 >understanding, before proposing solutions that might be based=20 >on one/some/all of the alternatives.=20 > >Do you think it is feasable/reasonable ? > >Thanks, >Simone > > > -----Original Message----- > > From: Joe Macker [mailto:joseph.macker@nrl.navy.mil] > > Sent: marted=EC 31 ottobre 2006 18.10 > > To: 'Templin, Fred L'; 'Jari Arkko'; 'Yi, Seung' > > Cc: autoconf@ietf.org > > Subject: RE: [Autoconf] MANET subnet model > > Fred: > > > > It's a good idea to enumerate prefix assignment cases to >=20 >help scope the work. > > > > Do we really need to REQUIRE multi-hop DAD for all >=20 >deployments? Having mechanisms TO SUPPORT IT defined is ok, =20 >> but requiring it is not IMHO. So can we talk about prefix =20 >> assignment cases without DAD off-link issues for now. Just a thought. > > > > -joe > > > > >-----Original Message----- > > >From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > >Sent: Tuesday, October 31, 2006 11:39 AM > >To: Jari=20 >Arkko; Yi, Seung > >Cc: autoconf@ietf.org > >Subject: RE:=20 >[Autoconf] MANET subnet model > > > >Jari, > > > >> If it=20 >is the case that you have a well understood approach > >that=20 >avoids > >> the multilink subnet issues you should go for=20 >that. You have a > >> complicated enough problem in your=20 >hands even without having to > >> support multiple ways to do=20 >things. If you have a solution > >that works > >> and has no=20 >major drawbacks, standardize that. > > > > > >Can you clarify what you mean by this? I believe Seung's=20 >post is > >essentially listing the following options for=20 >prefix assignment to > >MANET interfaces: > > > > > > 1) shared prefix for both address configuration and on-link > > > determination (i.e., prefix length shorter than 128) - > > > requires that all MANET interfaces that assign the prefix > > > and configure addresses from the prefix be attached to > > > the same link always and run DAD on the link > > > 2) shared prefix for address configuration but not on-link > > > determination (i.e., prefix length =3D 128) - requires > > > MANET-wide proxy-DAD in case multiple MANET interfaces > > > configure duplicate addresses, but does not require > > > attachment to same link > > > 3) unique prefix for each MANET interface - DAD avoidance > > > through operational assurance against duplication > > > 4) link-local-only - requires MANET-wide proxy-DAD in case > > > multiple MANET interfaces that configure the same link-local > > > address might move onto the same link at some point in time. > > > > > >There would seem to be potential use-cases for all of=20 >these > options, so > >why do you say "pick one" when it=20 >seems like all may have their > >appropriate use-cases? > > > > > >Note 1: option 4) also needs to be considered along with > > > options 1) thru 3) since all MANET interfaces must > > > configure a link-local address. > > >Note 2: DAD can be avoided through operational assurance > > > against duplication in all cases, but that would > > > tend to negate SEND. > > > > > >Thanks - Fred > > >fred.l.templin@boeing.com > > > >-------------------------------------------------------------------- > >CONFIDENTIALITY NOTICE > >This message and its attachments are addressed solely to the=20 >persons above and may contain confidential information. If you=20 >have received the message in error, be informed that any use=20 >of the content hereof is prohibited. Please return it=20 >immediately to the sender and delete the message. Should you=20 >have any questions, please contact us by replying to=20 >webmaster@telecomitalia.it. > > Thank you > > www.telecomitalia.it > >-------------------------------------------------------------------- > =20 > >_______________________________________________ >Autoconf mailing list >Autoconf@ietf.org >https://www1.ietf.org/mailman/listinfo/autoconf > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 03 13:02:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg3MT-0006YJ-2i; Fri, 03 Nov 2006 13:01:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg3MR-0006Y6-SW for autoconf@ietf.org; Fri, 03 Nov 2006 13:01:47 -0500 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg3MO-00021h-Gc for autoconf@ietf.org; Fri, 03 Nov 2006 13:01:47 -0500 Received: from [192.168.0.1] (ras75-3-82-226-221-97.fbx.proxad.net [82.226.221.97]) (authenticated bits=0) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id kA3I1M1X031855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 3 Nov 2006 19:01:22 +0100 Message-ID: <454B83DB.6060307@inria.fr> Date: Fri, 03 Nov 2006 19:00:59 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: autoconf@ietf.org Content-Type: multipart/mixed; boundary="------------010507010707020200030801" X-j-chkmail-Score: MSGID : 454B83F2.000 on concorde : j-chkmail score : XX : 5/20 0 X-Miltered: at concorde with ID 454B83F2.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: a60b9377a676a0ce7ebd0e0cef6ba8d6 Subject: [Autoconf] draft-baccelli-autoconf-problem-statement-01.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org This is a multi-part message in MIME format. --------------010507010707020200030801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, I'd like to announce the ps-01 document. Please review it, send comments, and bring discussion to the mailing list. Thanks. Emmanuel Baccelli --------------010507010707020200030801 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="draft-baccelli-autoconf-problem-statement-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-baccelli-autoconf-problem-statement-01.txt" MANET Autoconfiguration (Autoconf) E. Baccelli (Ed.) Internet-Draft INRIA Expires: April 4, 2007 K. Mase Niigata University S. Ruffino Telecom Italia S. Singh Samsung October 2006 Address Autoconfiguration for MANET: Terminology and Problem Statement draft-baccelli-autoconf-statement-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 April 4, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Traditional dynamic IP address assignment solutions are not adapted to mobile ad hoc networks. This document elaborates on this problem, states the need for a new solution, and provides guidelines and Baccelli (Ed.), et al. Expires April 4, 2007 [Page 1] Internet-Draft MANET Autoconf Problem Statement October 2006 requirements for its design. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Overview of the Problem . . . . . . . . . . . . . . . . . 3 1.2. Specification of Requirements . . . . . . . . . . . . . . 3 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 5 2.1. Standalone MANET . . . . . . . . . . . . . . . . . . . . . 5 2.2. MANET Connected to an External Network . . . . . . . . . . 5 2.3. Deployment Scenarios Selection . . . . . . . . . . . . . . 5 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Specific Broacast Characteristics . . . . . . . . . . . . 6 3.2. Dynamic Topology . . . . . . . . . . . . . . . . . . . . . 6 3.3. Locally Unique Addresses, Globally Unique Addresses . . . 7 3.4. Multiple Gateways . . . . . . . . . . . . . . . . . . . . 7 4. Solution Guidelines . . . . . . . . . . . . . . . . . . . . . 8 4.1. Solution Model . . . . . . . . . . . . . . . . . . . . . . 8 4.2. General Requirements . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Baccelli (Ed.), et al. Expires April 4, 2007 [Page 2] Internet-Draft MANET Autoconf Problem Statement October 2006 1. Introduction Mobile ad hoc networks (i.e. MANETs, refer to RFC 2501) are networks composed of mobile devices, that communicate over wireless media, and which dynamically self-organize multi-hop communication between each other. Each device may generate and forward control traffic, and forward user traffic (thus potentially behaving like a router). Each device may also use the network by generating user traffic (and thus potentially behaving like a host). We will call such devices MANET routers in the rest of the document. Some mobile ad hoc network may function regardless of the availability of a connection to the infrastructure (i.e. the Internet). More precisely, a MANET may either be disconnected from the fixed IP infrastructure (then called a standalone MANET), or connected to the fixed IP infrastructure (through one or more gateways). 1.1. Overview of the Problem Prior to participation in IP communication, each router's interface on a MANET that does not beneficiate from appropriate static configuration needs to be automatically assigned at least one IP address, that SHOULD be unique (i) locally, for communication inside the MANET, or (ii) globally, for communication accross the Internet. However, standard automatic IP address assignment solutions do not work "as-is" on MANETs due to ad hoc networks' characteristics, and new mechanisms are therefore needed. The goal of this document is to detail these problems, and to provide guidelines and requirements for solutions to be designed. 1.2. Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.3. Terminology In addition to the specific wording described in the previous section, this document uses the following terminology : MANET Router - A device with one or more wireless interfaces and associated IP address(es) which is used by the MANET routing protocol in use. Baccelli (Ed.), et al. Expires April 4, 2007 [Page 3] Internet-Draft MANET Autoconf Problem Statement October 2006 Local address - An IP address configured on a MANET router and valid for communication among MANET routers that are part of the same ad hoc network. Routers MUST NOT communicate with other routers outside the MANET using this address. Global address - An IP address configured on a MANET router and valid for communication with routers in the Internet, as well as internally within the MANET. Internet gateway - An edge router connected to MANET as well as to the Internet and capable of providing bidirectional connectivity between the Internet and MANET . These gateways are expected to provide topologically correct IPv6 prefixes. Internet gateways mostly run ad hoc routing protocols, but they can also run infrastructure network protocols (e.g. OSPF). Duplicate Address Detection (DAD) - The process by which a router confirms the uniqueness of an address it wishes to configure or has already configured. A router already equipped with an IP address participates in DAD in order to protect its IP address from being used by another router. Pre-service DAD - The process verifying that a tentative new IP address assignment will not create a conflict with other MANET devices. In-service DAD - The process of continuously checking that an IP address already in use has not become duplicated in the MANET. Standalone MANET - An independent ad hoc network which has no connectivity, either direct of via Internet gateways, to any other IP networks such as the Internet. Network merger - The process by which two or more ad hoc networks, previously disjoint, get connected. In general, network merger happens as a consequence of router mobility and/or wireless link environment. Network partitioning - The process by which an ad hoc network splits into two or more disconnected ad hoc networks. In general, this proccess happens as a consequence of router mobility and/or wireless link environment. Baccelli (Ed.), et al. Expires April 4, 2007 [Page 4] Internet-Draft MANET Autoconf Problem Statement October 2006 2. Deployment Scenarios Automatic configuration of IP addresses of MANET routers (AUTOCONF) may be necessary in a number of deployment scenarios. In this section, we outline the use cases that concern and reveal problems related to the Autoconfiguration of MANET routers. 2.1. Standalone MANET In this kind of scenario, the MANET is not connected to any external network: all traffic is generated by MANET routers and destined to routers in the same MANET. Routers joining a standalone MANET can either (i) have no previous configuration, or (ii) already have one or more MANET local and/or global addresses, statically or dynamically pre-configured, to be used for IP communication. Due to partitions and mergers, standalone MANETs can often be composed with both kinds of routers. Typical applications of this scenario include private or temporary networks, set-up in areas where neither wireless coverage nor network infrastructure exist (e.g. emergency networks for disaster recovery, or conference-room networks). 2.2. MANET Connected to an External Network In this scenario, the MANET is connected to an external network, (e.g. the Internet), by means of one or more gateways. MANET routers can generate traffic directed to remote hosts accross the Internet. As in Section 2.1, routers in a connected MANET could either (i) already own a global IP address, which could be used for external traffic, or (ii) have no previous configuration. Examples include public wireless networks of scattered fixed WLAN Access Points participating in the MANET of mobile users, and acting as Internet Gateways. Another example of such a scenario is the coverage extension of a fixed wide-area wireless network, where one or more mobile routers in the MANET are connected to the Internet through technologies such as UMTS or WiMAX. 2.3. Deployment Scenarios Selection Both the standalone MANET scenario and the connected MANET scenario are to be addressed by solutions for MANET autoconfiguration. Baccelli (Ed.), et al. Expires April 4, 2007 [Page 5] Internet-Draft MANET Autoconf Problem Statement October 2006 3. Problem Statement MANET routers that do not beneficiate from appropriate static IP address configuration may need to automatically configure at least one unique local IPv6 address, in order to enable IP communication within the MANET. To communicate with hosts across the Internet, configuration mechanism may also need to provide one or more global IPv6 addresses. Internet Gateways typically manage topologically correct IPv6 prefixes that can be used to configure global address. They are usually managed by an administrative entity (i.e. a network operator or service provider), however they can also be opportunistic and unmanaged. Internet Gateways are typically fixed, but may also be mobile. Their presence in the MANET may be intermittent (the number of gateways may vary), and thus the availability of an Internet connection in the MANET may also be intermittent. 3.1. Specific Broacast Characteristics Traditional dynamic IP address assignment solutions, such as RFC 2462, 3315 and 2461, do not work as-is in MANETs due to these networks' unique properties, as elaborated in the following sections. These solutions assume that a broadcast direclty reaches every device on the network, whereas it is generally not the case in MANETs. Indeed, some routers in the MANET will typically be indirectly connected to the source of the broadcast, through several intermediate peer mobile ad hoc routers (see [2]). In that respect, it is worth noting that IPv6 does not currently specify an address scope that is applicable for MANET scope. 3.2. Dynamic Topology A significant proportion of the routers in the MANET may be mobile with wireless interface(s), leading to ever changing neighbors and neighbor sets for most MANET routers. Therefore network topology may change rather dynamically compared to traditional networks. In particular, phenomena such as MANET paritionning (i.e. a MANET separating into two or more disconnected MANETs) and MANET merging (i.e. two or more disconnected MANETs suddenly being connected) are potential events that may greatly disrupt the uniqueness of IP addresses in use (see [2]). For instance, a standalone MANET A may feature routers that use IP addresses that are locally unique within MANET A, but this uniqueness is not guaranteed anymore if MANET A merges at some point with another MANET B. Baccelli (Ed.), et al. Expires April 4, 2007 [Page 6] Internet-Draft MANET Autoconf Problem Statement October 2006 3.3. Locally Unique Addresses, Globally Unique Addresses Moreover, even if a router uses an IP address that is locally unique within its MANET, this address may not be fit for Internet communication. Indeed, in order to be able to communicate with outside the MANET (i.e. the Internet), a router must use an IP address that must be both globally unique, as well as topologically correct, reflecting it's current location. 3.4. Multiple Gateways In the case where multiple gateways are available in the MANET, specific problems arise. One problem is the way in which global prefixes are managed within the MANET. If *one* prefix is used for the whole MANET, partitioning of the MANET may invalid routes in the Internet towards MANET routers. On the other hand, use of *multiple* network prefixes guarantees traffic is unambiguously routed towards the gateway owning one particular prefix, but asymmetry in the routers' choice of ingress/egress gateway can lead to non-optimal paths followed by inbound/outbound data traffic. Additional problems come from issues with current IPv6 specifications. For example, the strict application of RFC2462 may lead to check every IPv6 unicast for uniqueness : in a multiple-gateway / multiple-prefixes MANET, this could bring to a large amount of control signalling, due to frequent reconfiguration. Baccelli (Ed.), et al. Expires April 4, 2007 [Page 7] Internet-Draft MANET Autoconf Problem Statement October 2006 4. Solution Guidelines 4.1. Solution Model This section proposes a high-level conceptual view of generic MANET autoconfiguration. The different phases of the autoconfiguration process are abstracted by means of diagrams (Fig. 1 - 4), that propose different approaches to the process of autoconfiguration, which can be applied in different scenarios. The purpose of this framework is to derive a checklist of autoconfiguration functionalities, in order to build solutions taylored for different scenarios. In the "Full DAD" model, depicted in Fig 1, both in-service and pre- service DAD aspects are present. Basically, with regards to IP addressing, a device MAY find itself into any of the three different phases depicted in Fig 1. : The NO ADDRESS phase - In this phase a device does not have its own IP address. It does not participate in user data forwarding. If a routing protocol is in use in the MANET, the router does not process, generate or forward routing control messages generated by other devices. At some point, the router MAY generate a (tentative) address by means of a given address generation method. When it generates its address, the device should enter the ADVERTISING phase. The ADVERTISING phase - In this phase, a device does not participate in user data forwarding. If a routing protocol is in use in the MANET, the router does not forward routing control messages generated by other routers. In this phase, the router MAY perform pre-service DAD by means of a given mechanism (for instance by using specific control signalling, that could be embeded in the ad hoc routing signalling in use). If pre-service DAD is used, and the device detects that its tentative address creates a conflict with other MANET devices, it should re-enters the NO ADDRESS phase. Else, if pre-service DAD completes without any address conflict being detected, or if pre-service DAD is not required, the router should enter the NORMAL phase. Note that if pre- service DAD is used, the ADVERTISING phase MAY have incremental substates in order to reduce the risks of routing table pollution with duplicate addresses. In the LOCAL ADVERTISEMENT phase, pre- service DAD control signalling reaches only a TTL-limited neighborhood, whereas in the GLOBAL ADVERTISEMENT phase, pre- service DAD control signalling reaches the whole MANET. Baccelli (Ed.), et al. Expires April 4, 2007 [Page 8] Internet-Draft MANET Autoconf Problem Statement October 2006 The NORMAL phase - In this phase, the device participates in IP communication normally. If a routing protocol is in use in the MANET, the device MAY process, generate or forward routing control messages as specified by the routing protocol in use, and MAY generate or forward user data. A device in this phase MAY perform in-service DAD by means of a given mechanism (for instance by using specific control messages that can be embeded in the routing control messages). If in-service DAD is used and if the device detects an address conflict that forces it to acquire a new address to resolve this conflict, the router should return to the NO ADDRESS phase. Note that the phases in this model are cyclic, and that a router can pop up in the MANET in any phase. For instance, a router that beneficiated from appropriate static preconfiguration MAY start directly in the NORMAL phase. (Address generation) (In-service DAD) Duplicate address +--------------+ detected +--------------+ | NO ADDRESS |<-------------------| NORMAL | +----------| phase | | phase |<--+ | +--------------+ +--------------+ | | ^ | | | Duplicate address | |(Tentative) address | detected Address | | generated +--------+ checked | | | | | +--------------------------------------------------------+ | | | ADVERTISING phase | | | | | | | | +--------------+ +-------------+ | | | | | LOCAL AD. | | GLOBAL AD. | | | +--->| | phase |----------------->| phase | |---+ | +--------------+ +-------------+ | +--------------------------------------------------------+ (Pre-service DAD) Fig. 1 Phases model with full DAD. This conceptual framework reveals three specific potential aspects of the MANET autoconfiguration problem: - The (tentative) IP addresses generation and assignment aspect. Baccelli (Ed.), et al. Expires April 4, 2007 [Page 9] Internet-Draft MANET Autoconf Problem Statement October 2006 - The pre-service DAD aspect, to somehow ensure a reasonalble belief in the fact that an address about to be assigned does not create a conflict. - The in-service DAD aspect, to deal with conflicts that are detected between already assigned addresses. These distinct aspects MAY be combined in order to build solutions taylored for different requirements with regards to DAD, as shown in Fig. 1 - 4. +--------------+ +--------------+ | NO ADDRESS | | NORMAL | | phase |------------------->| phase | +--------------+ address +--------------+ generation Fig. 2 Phases model without DAD. Pre-service DAD +-------------------------------------+ | | | | | +--------------+ +---------------+ +--------------+ | | NO ADDRESS | | ADVERTISING | | NORMAL | +--->| phase |-------->| phase |-------->| phase | +--------------+ +---------------+ +--------------+ Fig. 3 Phases model without in-service DAD. Baccelli (Ed.), et al. Expires April 4, 2007 [Page 10] Internet-Draft MANET Autoconf Problem Statement October 2006 In-service DAD +----------------------------------------------------------+ | | | | | +--------------+ +--------------+ | | | NO ADDRESS | | NORMAL | | +--->| phase |------------------>| phase |---+ +--------------+ +--------------+ Fig. 4 Phases model without pre-service DAD. 4.2. General Requirements A solution for IP address autoconfiguration for MANETs is needed for mobile ad hoc router to acquire a correct IP address prior to their full participation in the mobile ad hoc routing protocol(s) in use. Such a solution must address the distributed, multi-hop nature of mobile ad hoc networks. Autoconfiguration mechanisms must be able to follow changes in the MANET and react to gateway connectivity loss, or to the event of new gateways becoming available, (re)configuring addresses accordingly. A solution must achieve its task with minimal overhead, due to scarse bandwidth, and minimal delay, due to the dynamicity of the topology. Baccelli (Ed.), et al. Expires April 4, 2007 [Page 11] Internet-Draft MANET Autoconf Problem Statement October 2006 5. Security Considerations Address configuration in MANET could be prone to security attacks, as in other type of IPv6 networks. Security threats to IPv6 neighbor discovery are discussed in RFC 3756: in particular, analysis includes trust model and threats for a specific ad hoc network scenario, where all the routers share a common link (i.e. they are one hop away from each other, full-meshed connectivity is available). Although the document does not explicitly address MANETs, where routers can be multiple hop away from each other, the trust model it provides could be valid also in the context of AUTOCONF. It is also worth noting that, in case of MANET connected to the Internet, other threats defined in RFC3756 could apply here, e.g. attacks involving routers and DoS attacks on Duplicate Address Detection procedures. Analysis has to be further extended to include threats, specific to multi-hop networks and, in particular, related to the address configuration process: security issues of routing protocol operations (e.g. how to secure routing protocol messages) are out of scope of AUTOCONF WG. Baccelli (Ed.), et al. Expires April 4, 2007 [Page 12] Internet-Draft MANET Autoconf Problem Statement October 2006 6. IANA Considerations This document does currently not specify IANA considerations. 7. References [1] Macker, J. and S. Corson, "MANET Routing Protocol Performance Issues and Evaluation Considerations", RFC 2501, January 1999. [2] Macker, J., Chakeres, I., and T. Clausen, "Mobile Ad hoc Network Architecture", ID draft-chakeres-manet-arch, October 2006. [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IPv6", RFC 2461, December 1998. [4] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6", RFC 3315, July 2003. [5] Narten, T. and S. Thomson, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. Baccelli (Ed.), et al. Expires April 4, 2007 [Page 13] Internet-Draft MANET Autoconf Problem Statement October 2006 Contributors This document is the result of joint efforts, including those of the following contributers, listed in alphabetical order: C. Adjih (INRIA), T. Clausen (Ecole Polytechnique), C. Perkins (Nokia), P. Ruiz (University of Murcia), P. Stupar (Telecom Italia), D. Thaler (Microsoft). Baccelli (Ed.), et al. Expires April 4, 2007 [Page 14] Internet-Draft MANET Autoconf Problem Statement October 2006 Authors' Addresses Emmanuel Baccelli INRIA Phone: +33 1 69 33 55 11 Email: Emmanuel.Baccelli@inria.fr Kenichi Mase Niigata University Phone: +81 25 262 7446 Email: Mase@ie.niigata-u.ac.jp Simone Ruffino Telecom Italia Phone: +39 011 228 7566 Email: Simone.Ruffino@telecomitalia.it Shubhranshu Singh Samsung Phone: +82 31 280 9569 Email: Shubranshu@gmail.com Baccelli (Ed.), et al. Expires April 4, 2007 [Page 15] Internet-Draft MANET Autoconf Problem Statement October 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Baccelli (Ed.), et al. Expires April 4, 2007 [Page 16] --------------010507010707020200030801 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf --------------010507010707020200030801-- From autoconf-bounces@ietf.org Sun Nov 05 01:30:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgbWJ-0003Hq-Gr; Sun, 05 Nov 2006 01:30:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgbWI-0003HE-VI; Sun, 05 Nov 2006 01:30:14 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgbWH-0004Mc-Bl; Sun, 05 Nov 2006 01:30:14 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8EDD589883; Sun, 5 Nov 2006 08:30:05 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 0675A89879; Sun, 5 Nov 2006 08:30:02 +0200 (EET) Message-ID: <454D84E8.8010709@piuha.net> Date: Sat, 04 Nov 2006 22:30:00 -0800 From: Jari Arkko User-Agent: Thunderbird 1.5.0.7 (X11/20060922) MIME-Version: 1.0 To: "Templin, Fred L" References: <39C363776A4E8C4A94691D2BD9D1C9A10177444D@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A10177444D@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: int-area@ietf.org, Dave Thaler , James Kempf , netlmm@ietf.org, dhcwg@ietf.org, autoconf@ietf.org, ipv6@ietf.org Subject: [Autoconf] Re: Multilink subnet issues and proxy/relay DAD X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Hi Fred, > 1. What are the issues wrt proxy/relay DAD that would > interfere with its adoption as a standard mechanism? > Almost anything can be made to work, but often the question is what works best or with least changes. In particular, we can make proxy DAD work, probably even with SEND. But I would still prefer an approach that does not require that. Also, if you need proxy DAD, does that mean that link local multicast does not work on the link as expected? > 2. What harmful on-link assumptions could there be for > IPv6 Prefix Information Options that advertise a > shared prefix with 'L=0'? > None that I know of. > 3. Does the RFC1812 "subnet forwarding model" still apply > to IPv6, when there are no IPv6 documents that reference > RFC1812 normatively? > 4. What other non-obvious issues relating to multilink > subnets for shared links need to be observed for NETLMM, > Autoconf and other contexts? > I am not sure I have an answer. But let me ask you a question about something which has been unclear to me during the NETLMM discussion. What is the real-world functionality that you would like to have? Media where this is needed? Employing just one prefix per a number of hosts? Special requirements on what the scope of link local multicast should be? Also, my understanding of the NETLMM decision is that the working group wants to limit initial design to per-host prefix model, but that this could be extended in the future. As for AUTOCONF, there are no decisions yet, but my main requirement for them has been that they must define their architecture, including addressing and how links are seen from IP. And avoid issues from Dave's draft if possible. The architecture needs to be concrete enough so that we can determine what protocol work is needed for, e.g., prefix allocation, prefix/address uniqueness checking, and gateway selection. --Jari _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 06 17:58:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhDQH-0003Vc-7m; Mon, 06 Nov 2006 17:58:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhDQE-0003UQ-Va; Mon, 06 Nov 2006 17:58:30 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhDNE-00011p-J2; Mon, 06 Nov 2006 17:55:27 -0500 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id kA6Mt6xY017008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 Nov 2006 16:55:07 -0600 (CST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id kA6Mt6nJ005837; Mon, 6 Nov 2006 14:55:06 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id kA6Mt3Ds005680; Mon, 6 Nov 2006 14:55:05 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 14:55:03 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Nov 2006 14:55:01 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774465@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <454D84E8.8010709@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multilink subnet issues and proxy/relay DAD Thread-Index: AccAo9aWwf7k2oIqQQuUWlotoTstFwBT7cKw From: "Templin, Fred L" To: "Jari Arkko" X-OriginalArrivalTime: 06 Nov 2006 22:55:03.0208 (UTC) FILETIME=[984C7A80:01C701F6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: int-area@ietf.org, Dave Thaler , James Kempf , netlmm@ietf.org, dhcwg@ietf.org, autoconf@ietf.org, ipv6@ietf.org Subject: [Autoconf] RE: Multilink subnet issues and proxy/relay DAD X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Jari - see below for follow-up:=20 > Hi Fred, >> 1. What are the issues wrt proxy/relay DAD that would >> interfere with its adoption as a standard mechanism? >> =20 > Almost anything can be made to work, but often > the question is what works best or with least > changes. In particular, we can make proxy DAD > work, probably even with SEND. But I would > still prefer an approach that does not require > that. Also, if you need proxy DAD, does that > mean that link local multicast does not work > on the link as expected? The question is coming from the context of what to do about two nodes connected to different links that configure colliding addresses and then move onto the same link at some later point in time. It seems that a pre-service DAD procedure like proxy/relay DAD would be preferrable to an in-service DAD, e.g., (re)marking addresses as tentative and (re)running DAD on link change.=20 >> 2. What harmful on-link assumptions could there be for >> IPv6 Prefix Information Options that advertise a >> shared prefix with 'L=3D0'? > =20 > None that I know of. OK. If a node receives a PIO with 'L=3D0' and then configures a /128 on an interface, could applications get confused and assume that all destinations covered by the /64 that also covers the /128 are on-link? Is this something that should be added to an "on-link assumption considered harmful" document? (The latest version of the 'multilink-subnet' draft also says something about this.) =20 >> 3. Does the RFC1812 "subnet forwarding model" still apply >> to IPv6, when there are no IPv6 documents that reference >> RFC1812 normatively? >> 4. What other non-obvious issues relating to multilink >> subnets for shared links need to be observed for NETLMM, >> Autoconf and other contexts? > =20 > I am not sure I have an answer. But let me ask you a > question about something which has been unclear > to me during the NETLMM discussion. What is the > real-world functionality that you would like to have? > Media where this is needed? Employing just one > prefix per a number of hosts? Special requirements > on what the scope of link local multicast should be? Aside from the question of shared prefixes for the moment, even in just the link-local case the concern is for nodes that can move within a region between shared media links on which there may be neighbors other than just the provider's router. Proxy/relay-DAD is a pre-service DAD procedure for ensuring that no two nodes in the region will configure the same LL address prior to operation. Another possible method which has been suggested by James and others is to somehow enforce virtual point-to-point links as overlays on the shared media such that the (mobile) nodes would only ever see their provider's router on the link and no other neighbors. Such an arrangement might not be appropriate for all media types and/or deployments. > Also, my understanding of the NETLMM decision > is that the working group wants to limit initial > design to per-host prefix model, but that this > could be extended in the future. Well, the relay/proxy-DAD is also about link-locals; not just non-link-locals configured from a shared prefix. So, this is somewhat independent from the per-host prefix question. > As for AUTOCONF, there are no decisions yet, > but my main requirement for them has been > that they must define their architecture, including > addressing and how links are seen from IP. And > avoid issues from Dave's draft if possible. The > architecture needs to be concrete enough so > that we can determine what protocol work is > needed for, e.g., prefix allocation, prefix/address > uniqueness checking, and gateway selection. Thanks for this and for the other perspectives, Fred fred.l.templin@boeing.com --Jari _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 06 19:51:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhFBS-000155-SC; Mon, 06 Nov 2006 19:51:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhFBQ-00012Q-3x; Mon, 06 Nov 2006 19:51:20 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhFBM-0005Av-LT; Mon, 06 Nov 2006 19:51:18 -0500 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id kA70p7X8014840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 Nov 2006 16:51:07 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id kA70p7UA002055; Mon, 6 Nov 2006 16:51:07 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id kA70p7fn002050; Mon, 6 Nov 2006 16:51:07 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 16:51:07 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Nov 2006 16:51:06 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774468@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <200611061558.35045.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] RE: Multilink subnet issues and proxy/relay DAD Thread-Index: AccB/4jk7gUh6gS4TZeOUFLjG+YsDwAAjP+g From: "Templin, Fred L" To: "Julien Laganier" , X-OriginalArrivalTime: 07 Nov 2006 00:51:07.0339 (UTC) FILETIME=[CF3E89B0:01C70206] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: int-area@ietf.org, Dave Thaler , dhcwg@ietf.org, autoconf@ietf.org, ipv6@ietf.org Subject: [Autoconf] RE: [netlmm] RE: Multilink subnet issues and proxy/relay DAD X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Hi Julien, This all sounds good, but in terms of a node moving between routers on p2p links I have seen some proposals that all routers would configure the same LL address thereby avoiding collisions after an initial DAD test with the first router. (I guess that wouldn't be appropriate for shared links, since there couldn't be multiple routers on the link with the same LL address?) Is there a problem with assigning the same LL address to different routers whereby that shouldn't be done and we need proxy/relay-DAD instead? Fred fred.l.templin@boeing.com =20 -----Original Message----- From: Julien Laganier [mailto:julien.IETF@laposte.net]=20 Sent: Monday, November 06, 2006 3:59 PM To: netlmm@ietf.org Cc: Templin, Fred L; Jari Arkko; int-area@ietf.org; Dave Thaler; dhcwg@ietf.org; autoconf@ietf.org; ipv6@ietf.org Subject: Re: [netlmm] RE: Multilink subnet issues and proxy/relay DAD Fred, My follow-up inlined below, On Monday 06 November 2006 14:55, Templin, Fred L=20 wrote: > Jari - see below for follow-up: > > Hi Fred, > > > >> 1. What are the issues wrt proxy/relay DAD that > >> would interfere with its adoption as a standard > >> mechanism? > > > > Almost anything can be made to work, but often > > the question is what works best or with least > > changes. In particular, we can make proxy DAD > > work, probably even with SEND. But I would > > still prefer an approach that does not require > > that. Also, if you need proxy DAD, does that > > mean that link local multicast does not work > > on the link as expected? > > The question is coming from the context of what to > do about two nodes connected to different links that > configure colliding addresses and then move onto the > same link at some later point in time. It seems that > a pre-service DAD procedure like proxy/relay DAD > would be preferrable to an in-service DAD, e.g., > (re)marking addresses as tentative and (re)running > DAD on link change. Especially since this the default DNA behavior is to=20 not redo DAD when DNA concludes that the link did not=20 change -- because in the NetLMM case the landmark=20 prefix won't change even though the link indeed=20 changed. Regarding the implications on link-local multicast,=20 there's none since there's no change in the=20 communication service model: Normal address resolution=20 isn't impacted by proxy DAD, only NS and NA part of=20 DAD would be proxied when a collision is detected by=20 the NetLMM fabric, otherwise they won't. > [...]=20 > > >> 3. Does the RFC1812 "subnet forwarding model" > >> still apply to IPv6, when there are no IPv6 > >> documents that reference RFC1812 normatively? > >> 4. What other non-obvious issues relating to > >> multilink subnets for shared links need to be > >> observed for NETLMM, Autoconf and other contexts? > > > > I am not sure I have an answer. But let me ask you > > a question about something which has been unclear > > to me during the NETLMM discussion. What is the > > real-world functionality that you would like to > > have? Media where this is needed? Employing just > > one prefix per a number of hosts? Special > > requirements on what the scope of link local > > multicast should be? > > Aside from the question of shared prefixes for the > moment, even in just the link-local case the concern > is for nodes that can move within a region between > shared media links on which there may be neighbors > other than just the provider's router. I think the concern apply even when links are=20 point-to-point and the only neighbor to a MN is the=20 provider's router. If a MN happens to move to a link where the router has=20 a colliding link-local address, and the MN doesn't=20 re-run DAD (as per default DNA behavior) then a=20 collision will occur and won't be detected. That's orthogonal to the link type, be it=20 point-to-point or shared, I think. > Proxy/relay-DAD is a pre-service DAD procedure for > ensuring that no two nodes in the region will > configure the same LL address prior to operation. > Another possible method which has been suggested by > James and others is to somehow enforce virtual > point-to-point links as overlays on the shared media > such that the (mobile) nodes would only ever see > their provider's router on the link and no other > neighbors.=20 See my comment above. > Such an arrangement might not be appropriate for all > media types and/or deployments.=20 > > > Also, my understanding of the NETLMM decision > > is that the working group wants to limit initial > > design to per-host prefix model, but that this > > could be extended in the future. > > Well, the relay/proxy-DAD is also about link-locals; > not just non-link-locals configured from a shared > prefix. So, this is somewhat independent from the > per-host prefix question. Agree. > > [...] Best, --julien _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 07 13:48:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhVzP-0001x8-Kp; Tue, 07 Nov 2006 13:48:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhVzN-0001w7-UC for autoconf@ietf.org; Tue, 07 Nov 2006 13:48:01 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhVzJ-0005tj-KD for autoconf@ietf.org; Tue, 07 Nov 2006 13:48:01 -0500 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id kA7IluUN013434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 7 Nov 2006 10:47:57 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id kA7Ilur3023754 for ; Tue, 7 Nov 2006 10:47:56 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id kA7IlmZK023407 for ; Tue, 7 Nov 2006 10:47:51 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 10:47:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Nov 2006 10:47:50 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774472@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <00bf01c6ff57$e5441600$165cfa84@SEXTANT> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MANET architecture discussion follow-up Thread-Index: Acb88vAdFAfs5i6qSvaUpwAh6WpynQAELSygAAIuJgAAhi66EAAMgP3QAM/IBEA= From: "Templin, Fred L" To: X-OriginalArrivalTime: 07 Nov 2006 18:47:51.0469 (UTC) FILETIME=[3A4E75D0:01C7029D] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Autoconf] MANET architecture discussion follow-up X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Hi, Some follow-up on a couple of things I thought I heard during the MANET architecture discussion in the Autoconf wg meeting last nite: 1) For the case of the MANET router obtaining prefixes for assignment on non-MANET interfaces, the MR needs to have some sort of prefix delegation mechanism, e.g., DHCP PD. But, that would require some extra mechanism for MRs beyond what is specified in IPv6 node requirements. I'm OK with that, but does that cause problems for anyone? 2) For IPv6, it was suggested that the MR's MANET interface(s) will configure a link-local and may also configure a /128 (non-link-local assumed). Again, I'm OK with that, but would assigning a /128 cause a problem for anyone? 3) For IPv4, it was suggested that the MR's MANET interface(s) would either be unnumbered or configure a /32 (again, non- link-local assumed). But, why not have the MANET interface configure an IPv4 link-local address/prefix per RFC3927? Can we consider that for the MANET architecture model? Thanks - Fred fred.l.templin@boeing.com _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 07 14:09:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWKP-000805-5l; Tue, 07 Nov 2006 14:09:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWKN-0007zz-Ci for autoconf@ietf.org; Tue, 07 Nov 2006 14:09:43 -0500 Received: from wx-out-0506.google.com ([66.249.82.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhWKM-0008NK-6L for autoconf@ietf.org; Tue, 07 Nov 2006 14:09:43 -0500 Received: by wx-out-0506.google.com with SMTP id t4so1536910wxc for ; Tue, 07 Nov 2006 11:09:41 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=ULWQs/SUqy6F1J2KBwvVQ8P5YU6B919z0dTIUPSR4xalEhYGV7wzp9cuoyaQiGAGm0riH/qimqrvXys5CZOb3gcWbVuFyqTaFxLJ1ukdkjg//qpy6AD2xoIoX7YsYhmcor5CsBf2IBbQulchFULzt7pR63ThxrxK13ddxsq0J+Y= Received: by 10.90.78.1 with SMTP id a1mr2438756agb.1162926581764; Tue, 07 Nov 2006 11:09:41 -0800 (PST) Received: by 10.90.89.3 with HTTP; Tue, 7 Nov 2006 11:09:41 -0800 (PST) Message-ID: Date: Tue, 7 Nov 2006 11:09:41 -0800 From: "Seung Yi" To: "Templin, Fred L" Subject: Re: [Autoconf] MANET architecture discussion follow-up In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A101774472@XCH-NW-7V2.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <00bf01c6ff57$e5441600$165cfa84@SEXTANT> <39C363776A4E8C4A94691D2BD9D1C9A101774472@XCH-NW-7V2.nw.nos.boeing.com> X-Google-Sender-Auth: fd9bfd993e451462 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Hi, Fred, On 11/7/06, Templin, Fred L wrote: > Hi, > > Some follow-up on a couple of things I thought I heard during > the MANET architecture discussion in the Autoconf wg meeting > last nite: > > > 3) For IPv4, it was suggested that the MR's MANET interface(s) > would either be unnumbered or configure a /32 (again, non- > link-local assumed). But, why not have the MANET interface > configure an IPv4 link-local address/prefix per RFC3927? > Can we consider that for the MANET architecture model? What would be the point for having this provision? I understand that a link-local address MUST be configured for IPv6 case and also is used for IPv6 ND but I don't see why one would want to configure RFC3927 address for a MANET interface. Do you see any particular use case? Thanks, - Seung _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 07 14:13:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWO5-0002lX-Nf; Tue, 07 Nov 2006 14:13:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWO4-0002lQ-Fu for autoconf@ietf.org; Tue, 07 Nov 2006 14:13:32 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhWO3-0000NK-7b for autoconf@ietf.org; Tue, 07 Nov 2006 14:13:32 -0500 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id kA7JDUJn001351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 7 Nov 2006 11:13:30 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id kA7JDUx9012157; Tue, 7 Nov 2006 13:13:30 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id kA7JDKhG011888; Tue, 7 Nov 2006 13:13:29 -0600 (CST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 11:13:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Autoconf] MANET architecture discussion follow-up Date: Tue, 7 Nov 2006 11:13:28 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774473@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] MANET architecture discussion follow-up Thread-Index: AccCoEgUWFwNzKTrRR+s/M/Lq9OM6QAAB69A From: "Templin, Fred L" To: "Seung Yi" X-OriginalArrivalTime: 07 Nov 2006 19:13:29.0712 (UTC) FILETIME=[CF2BB700:01C702A0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Hi Seung, > What would be the point for having this provision? I understand that a > link-local address MUST be configured for IPv6 case and also is used > for IPv6 ND but I don't see why one would want to configure RFC3927 > address for a MANET interface. Do you see any particular use case? For the same reasons one would use an RFC3927 address on an ordinary IPv4 node, i.e., to be able to do some basic networking on the local link until a dynamically-assigned non-link-local address is available via DHCP. Thanks - Fred fred.l.templin@boeing.com=20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 07 14:36:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWk2-0005mJ-Nx; Tue, 07 Nov 2006 14:36:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWk1-0005jn-FT for autoconf@ietf.org; Tue, 07 Nov 2006 14:36:13 -0500 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhWjz-0002go-Pi for autoconf@ietf.org; Tue, 07 Nov 2006 14:36:13 -0500 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.6+Sun/8.12.8) with SMTP id kA7JaBZI004876; Tue, 7 Nov 2006 14:36:11 -0500 (EST) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2006110714370612043 ; Tue, 07 Nov 2006 14:37:06 -0500 From: "Joe Macker" To: "'Templin, Fred L'" , Subject: RE: [Autoconf] MANET architecture discussion follow-up Date: Tue, 7 Nov 2006 14:36:08 -0500 Message-ID: <01d501c702a3$f8edd750$165cfa84@SEXTANT> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A101774472@XCH-NW-7V2.nw.nos.boeing.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acb88vAdFAfs5i6qSvaUpwAh6WpynQAELSygAAIuJgAAhi66EAAMgP3QAM/IBEAAAyu3sA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org re (3) I believe if address ambiguity conditions are met that seems to fit the model. I believe it is more challenging in practice to meet those conditions with IPv4. -Joe >-----Original Message----- >From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] >Sent: Tuesday, November 07, 2006 1:48 PM >To: autoconf@ietf.org >Subject: [Autoconf] MANET architecture discussion follow-up > >Hi, > >Some follow-up on a couple of things I thought I heard during >the MANET architecture discussion in the Autoconf wg meeting last nite: > >1) For the case of the MANET router obtaining prefixes for > assignment on non-MANET interfaces, the MR needs to have > some sort of prefix delegation mechanism, e.g., DHCP PD. > But, that would require some extra mechanism for MRs > beyond what is specified in IPv6 node requirements. I'm > OK with that, but does that cause problems for anyone? > >2) For IPv6, it was suggested that the MR's MANET interface(s) > will configure a link-local and may also configure a /128 > (non-link-local assumed). Again, I'm OK with that, but > would assigning a /128 cause a problem for anyone? > >3) For IPv4, it was suggested that the MR's MANET interface(s) > would either be unnumbered or configure a /32 (again, non- > link-local assumed). But, why not have the MANET interface > configure an IPv4 link-local address/prefix per RFC3927? > Can we consider that for the MANET architecture model? > >Thanks - Fred >fred.l.templin@boeing.com > >_______________________________________________ >Autoconf mailing list >Autoconf@ietf.org >https://www1.ietf.org/mailman/listinfo/autoconf > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 08 10:26:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhpJf-0004Mk-OE; Wed, 08 Nov 2006 10:26:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhpJe-0004MW-Ua for autoconf@ietf.org; Wed, 08 Nov 2006 10:26:14 -0500 Received: from wx-out-0506.google.com ([66.249.82.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhpJd-0003tI-7J for autoconf@ietf.org; Wed, 08 Nov 2006 10:26:14 -0500 Received: by wx-out-0506.google.com with SMTP id t4so1819896wxc for ; Wed, 08 Nov 2006 07:26:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Np2WEdmhQ5oFQiMhKUpZacyJiYHd4RiZEnrysWP+wADNMENZ+w0jU2tgbaOIhzWIa22/ZeTOCo1hImJSJPOC1mhISSHSLlYW3WUrE0vd1iq08iB4N81a1zGhMO8QZSTxmPUgh6YaIOk0UwAfNcAGNnvMuW9G7Wj6EFDfrKC8fGY= Received: by 10.90.28.12 with SMTP id b12mr2397982agb.1162999572449; Wed, 08 Nov 2006 07:26:12 -0800 (PST) Received: by 10.90.89.3 with HTTP; Wed, 8 Nov 2006 07:26:12 -0800 (PST) Message-ID: Date: Wed, 8 Nov 2006 07:26:12 -0800 From: "Seung Yi" To: "Templin, Fred L" Subject: Re: [Autoconf] MANET architecture discussion follow-up In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A101774473@XCH-NW-7V2.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <39C363776A4E8C4A94691D2BD9D1C9A101774473@XCH-NW-7V2.nw.nos.boeing.com> X-Google-Sender-Auth: 747191ea948b7f0f X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Fred, On 11/7/06, Templin, Fred L wrote: > Hi Seung, > > > What would be the point for having this provision? I understand that a > > link-local address MUST be configured for IPv6 case and also is used > > for IPv6 ND but I don't see why one would want to configure RFC3927 > > address for a MANET interface. Do you see any particular use case? > > For the same reasons one would use an RFC3927 address on an > ordinary IPv4 node, i.e., to be able to do some basic networking > on the local link until a dynamically-assigned non-link-local > address is available via DHCP. > My view on this is, both RFC3927 addresses and IPv6 link-local addresses don't have much use in MANET since they can be only used to communicate with transmission-range neighbors that can frequently change. They fit the model but I'm not quite sure if one would want to configure them. Rather, I think it is crucial to go for a MANET-wide addresses (doesn't have to follow the MLA draft but some kind of address that is supposed to be unique across the MANET). I can see the need for IPv6 link-local for ND purpose but don't quite see the similar cases for v4. Thanks, - Seung _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 08 11:57:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghqjq-0000Os-7S; Wed, 08 Nov 2006 11:57:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghqjo-0000Oa-Vx for autoconf@ietf.org; Wed, 08 Nov 2006 11:57:20 -0500 Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghqjk-0000NI-EE for autoconf@ietf.org; Wed, 08 Nov 2006 11:57:20 -0500 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id kA8GvFkL002156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 8 Nov 2006 08:57:15 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id kA8GvEdc018604; Wed, 8 Nov 2006 10:57:15 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id kA8Guogg017941; Wed, 8 Nov 2006 10:57:14 -0600 (CST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 08:57:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Autoconf] MANET architecture discussion follow-up Date: Wed, 8 Nov 2006 08:57:08 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10177447A@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] MANET architecture discussion follow-up Thread-Index: AccDSjotprumcJLTQl2MY54HUhjQfQAC1FrQ From: "Templin, Fred L" To: "Seung Yi" X-OriginalArrivalTime: 08 Nov 2006 16:57:08.0828 (UTC) FILETIME=[ED65A1C0:01C70356] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Hi Seung,=20 > My view on this is, both RFC3927 addresses and IPv6 link-local > addresses don't have much use in MANET since they can be only used to > communicate with transmission-range neighbors that can frequently > change. Well, there is also the case in which the entire MANET is represented as a single link, i.e., when the MANET routing is based on L2 addresses or when using IP-in-IP tunneling. So the scope of the link-locals would be the entire MANET in that case. > They fit the model but I'm not quite sure if one would want to > configure them. There is certainly a point to be made that random assignment of IPv4 link locals is prone to collisions since there are only 2^16 unique possibilities for identifers. I don't know what the options are for some managed assignment scheme, but I think RFC3927 has a duplicate address detection mechanism that could ensure uniqueness when the entire MANET appears as a single link. > Rather, I think it is crucial to go for a MANET-wide > addresses (doesn't have to follow the MLA draft but some kind of > address that is supposed to be unique across the MANET). I can see the > need for IPv6 link-local for ND purpose but don't quite see the > similar cases for v4. I'll certainly go with the need for MANET-wide (site-scoped?) addresses. But, for IPv4 what would they be? And, could RFC3927 addresses somehow be used to fit the need? Fred fred.l.templin@boeing.com Thanks, - Seung _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 08 13:11:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhrtS-0004me-UU; Wed, 08 Nov 2006 13:11:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhrtO-0004jM-BD for autoconf@ietf.org; Wed, 08 Nov 2006 13:11:18 -0500 Received: from mailf.telecomitalia.it ([156.54.233.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhrtG-0002hQ-Qm for autoconf@ietf.org; Wed, 08 Nov 2006 13:11:18 -0500 Received: from ptpxch008ba020.idc.cww.telecomitalia.it ([156.54.240.51]) by mailf.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 19:10:59 +0100 Received: from PTPEVS108BA020.idc.cww.telecomitalia.it ([156.54.241.228]) by ptpxch008ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 19:10:58 +0100 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 Importance: normal Content-Class: urn:content-classes:message Priority: normal MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Nov 2006 19:10:58 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Simple MANET node model with new architecture thread-index: AccC6X1ZrrV4x3EKSzy2XpoXzNMAAQ== From: "Ruffino Simone" To: X-OriginalArrivalTime: 08 Nov 2006 18:10:58.0917 (UTC) FILETIME=[3DEF9150:01C70361] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: [Autoconf] Simple MANET node model with new architecture X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Hi all, I was wondering how the architecture we discussed during the meeting can = be applied, to model a very simple type of MANET deployment, where all = nodes are laptops, with only one wireless interface (e.g 802.11). The = laptops run a routing protocol and also run applications, like e-mail, = browsing, IM etc. I assume here they are IPv6 only. =20 If I correctly understood, in this case, each MANET node should be = modeled with a R(outer) with an attached virtual (H)ost. It is virtual, = since no real host is attached to the laptop. Accordingly, one can say a = virtual link connects R and H. =20 Now, my question is: how many addresses does the node need, in order for = a host application to send and receive traffic to/from other nodes in = the MANET ? =20 My temptative answer would be (not counting multicast addresses here): =20 On the MANET interface of R (the weird one): - One LLA and one non-link-local /128 address (maybe a MLA), to be used = for joining the RP =20 On the link between the virtual Host and R (R--H): - one /128 on H's interface, derived from prefix 'p', assigned to R. = Every node own a unique prefix 'p'. =20 But, what about other addresses on this virtual link (R--H) ? Is it seen = as a single entity, or should it be modeled as a traditional IPv6 link ? = Or, in other words: are the following addresses needed ? - one LLA on R's interface on the link and one LLA on H's interface on = the link - one /128 on R's interface on the link =20 I guess that some of these addresses are not needed, if the interfaces = are virtual. The ones really needed, IMHO, are the two addresses on the = MANET interface and one /128 for H, to be used by host applications. =20 Is this correct ? Am I missing anything ? =20 Thanks for your help, Simone -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons = above and may contain confidential information. If you have received the = message in error, be informed that any use of the content hereof is = prohibited. Please return it immediately to the sender and delete the = message. Should you have any questions, please contact us by replying to = webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- =20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 08 17:13:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghvfn-0001CO-OU; Wed, 08 Nov 2006 17:13:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghvfm-0001Ba-CY for autoconf@ietf.org; Wed, 08 Nov 2006 17:13:30 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghvfi-0007dt-Ri for autoconf@ietf.org; Wed, 08 Nov 2006 17:13:30 -0500 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id kA8MDNY7029661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 8 Nov 2006 16:13:24 -0600 (CST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id kA8MDNj8017563; Wed, 8 Nov 2006 14:13:23 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id kA8MDFt9017185; Wed, 8 Nov 2006 14:13:22 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 14:13:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Autoconf] Simple MANET node model with new architecture Date: Wed, 8 Nov 2006 14:13:20 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774484@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Simple MANET node model with new architecture Thread-Index: AccC6X1ZrrV4x3EKSzy2XpoXzNMAAQAl1Tmw From: "Templin, Fred L" To: "Ruffino Simone" , X-OriginalArrivalTime: 08 Nov 2006 22:13:22.0451 (UTC) FILETIME=[1A8EBE30:01C70383] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Hi Simone,=20 > On the MANET interface of R (the weird one): > - One LLA and one non-link-local /128 address (maybe a MLA), > to be used for joining the RP It seems like a non-link-local address-plus-prefix will be useful for intra-MANET communications, but the prefix assigned to the interface does not necessarily have to be a /128. It could be, e.g., /64 *as long as no other MANET interface in the MANET configures the same prefix*. I'm also not even sure that an MLA is needed to operate the routing protocol; it could just be some non-IP Router ID instead as long as it is unique within the MANET. So, maybe link-local-only on the MANET interface is fine too.=20 =20 > On the link between the virtual Host and R (R--H): > - one /128 on H's interface, derived from prefix 'p', > assigned to R. Every node own a unique prefix 'p'. That's OK, but I think your laptop's router function then has to be responsible for the *rest* of the prefix 'p' from which the /128 was taken. By that, I mean that it needs to send, e.g., ICMP destination unreachable for pkts destined to addresses covered by 'p' but not assigned to an interface. > But, what about other addresses on this virtual link (R--H) ? > Is it seen as a single entity, or should it be modeled as a > traditional IPv6 link ? Or, in other words: are the following > addresses needed ? > - one LLA on R's interface on the link and one LLA on H's > interface on the link > - one /128 on R's interface on the link It depends on the nature of the virtual link, but a loopback interface is an example of an interface attached to a virtual link that goes nowhere and could be used for communications btw your laptop's router function and host function. Loopback interfaces configure the single link-local address ::1. Fred fred.l.templin@boeing.com =20 > I guess that some of these addresses are not needed, if > the interfaces are virtual. The ones really needed, IMHO, > are the two addresses on the MANET interface and one /128 > for H, to be used by host applications. > > Is this correct ? Am I missing anything ? =20 Thanks for your help, Simone -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- =20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 14 11:09:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0pF-00030n-HP; Tue, 14 Nov 2006 11:07:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0pA-0002xa-QH for autoconf@ietf.org; Tue, 14 Nov 2006 11:07:48 -0500 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk0gW-0007eR-5w for autoconf@ietf.org; Tue, 14 Nov 2006 10:58:53 -0500 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.6+Sun/8.12.8) with SMTP id kAEFwRhH012156; Tue, 14 Nov 2006 10:58:38 -0500 (EST) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2006111410593422741 ; Tue, 14 Nov 2006 10:59:34 -0500 From: "Joe Macker" To: "'Templin, Fred L'" , "'Ruffino Simone'" , Subject: RE: [Autoconf] Simple MANET node model with new architecture Date: Tue, 14 Nov 2006 10:58:35 -0500 Message-ID: <049601c70805$bdffb8e0$165cfa84@SEXTANT> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A101774484@XCH-NW-7V2.nw.nos.boeing.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccC6X1ZrrV4x3EKSzy2XpoXzNMAAQAl1TmwASDpkyA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org If non-overlapping uniqueness is satisfied you can assign. It is not really a new model as was discussed at the meeting. It is perhaps better explained with specific addressing examples. -Joe >-----Original Message----- >From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] >Sent: Wednesday, November 08, 2006 5:13 PM >To: Ruffino Simone; autoconf@ietf.org >Subject: RE: [Autoconf] Simple MANET node model with new architecture > >Hi Simone, > >> On the MANET interface of R (the weird one): >> - One LLA and one non-link-local /128 address (maybe a MLA), to be >> used for joining the RP > >It seems like a non-link-local address-plus-prefix will be >useful for intra-MANET communications, but the prefix assigned >to the interface does not necessarily have to be a /128. It >could be, e.g., /64 *as long as no other MANET interface in >the MANET configures the same prefix*. I'm also not even sure >that an MLA is needed to operate the routing protocol; it >could just be some non-IP Router ID instead as long as it is >unique within the MANET. So, maybe link-local-only on the >MANET interface is fine too. > >> On the link between the virtual Host and R (R--H): >> - one /128 on H's interface, derived from prefix 'p', assigned to R. >> Every node own a unique prefix 'p'. > >That's OK, but I think your laptop's router function then has >to be responsible for the *rest* of the prefix 'p' >from which the /128 was taken. By that, I mean that it needs >to send, e.g., ICMP destination unreachable for pkts destined >to addresses covered by 'p' but not assigned to an interface. > >> But, what about other addresses on this virtual link (R--H) ? >> Is it seen as a single entity, or should it be modeled as a >> traditional IPv6 link ? Or, in other words: are the following >> addresses needed ? >> - one LLA on R's interface on the link and one LLA on H's >interface on >> the link >> - one /128 on R's interface on the link > >It depends on the nature of the virtual link, but a loopback >interface is an example of an interface attached to a virtual >link that goes nowhere and could be used for communications >btw your laptop's router function and host function. Loopback >interfaces configure the single link-local address ::1. > >Fred >fred.l.templin@boeing.com > >> I guess that some of these addresses are not needed, if the >interfaces >> are virtual. The ones really needed, IMHO, are the two addresses on >> the MANET interface and one /128 for H, to be used by host >> applications. >> >> Is this correct ? Am I missing anything ? > >Thanks for your help, >Simone >-------------------------------------------------------------------- > >CONFIDENTIALITY NOTICE > >This message and its attachments are addressed solely to the >persons above and may contain confidential information. If you >have received the message in error, be informed that any use >of the content hereof is prohibited. Please return it >immediately to the sender and delete the message. Should you >have any questions, please contact us by replying to >webmaster@telecomitalia.it. > > Thank you > > www.telecomitalia.it > >-------------------------------------------------------------------- > > >_______________________________________________ >Autoconf mailing list >Autoconf@ietf.org >https://www1.ietf.org/mailman/listinfo/autoconf > >_______________________________________________ >Autoconf mailing list >Autoconf@ietf.org >https://www1.ietf.org/mailman/listinfo/autoconf > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf