From autoconf-bounces@ietf.org Sat Dec 01 13:09:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyWmr-0004v9-VV; Sat, 01 Dec 2007 13:09:57 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IyWmr-0004v4-Fd for autoconf-confirm+ok@megatron.ietf.org; Sat, 01 Dec 2007 13:09:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyWmr-0004uv-4y for autoconf@ietf.org; Sat, 01 Dec 2007 13:09:57 -0500 Received: from rv-out-0910.google.com ([209.85.198.190]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyWmq-0003sE-Hz for autoconf@ietf.org; Sat, 01 Dec 2007 13:09:57 -0500 Received: by rv-out-0910.google.com with SMTP id l15so2111698rvb for ; Sat, 01 Dec 2007 10:09:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; bh=joRpT2uQum2Yc5J3lfNKzxdeRIpwYvxZjCvdlhPcoQY=; b=R3VGA4hb0onZhUdeq9MIN+aT5vg15gHeQvTWjjNhjIFxMoDSSVd2lv8brCH7G0AKzF4ImfpH1OdgocOkdqTnohOgvb+5v9TFTZ59dNtCMksROiESUwtttGOuc3fhXsUld1ajCpe1OgDfiCNBJpiwjuYWeSXg4UkGlXTpKk+MaAo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; b=SEb6J92f4VOr2jHYRK1/wVMJR1q5VoqrUjgiUq4gUlqXLIsw/eJdt1hVv0hS/fc7U7FhTvYxyGKwvVrZZaL7YmsY8+j+jW3rvTEcs4+W7qIK7XSx1fZfZ3NrZ6mOOCfzUc7F2oKhB4zjAYRpm5ImRKsBfANRkhmLSlgeFDZ1+XA= Received: by 10.140.251.1 with SMTP id y1mr4717987rvh.1196532595713; Sat, 01 Dec 2007 10:09:55 -0800 (PST) Received: from ?192.168.0.6? ( [124.102.52.215]) by mx.google.com with ESMTPS id f28sm2803811rvb.2007.12.01.10.09.53 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 01 Dec 2007 10:09:54 -0800 (PST) From: RYUJI WAKIKAWA To: Alexandru Petrescu In-Reply-To: <474FED1B.4060107@gmail.com> Subject: Re: [Autoconf] comments to autoconf PS References: <474FED1B.4060107@gmail.com> Message-Id: <49C5EC4A-EF28-46B3-BA04-6A1688085EFA@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Sun, 2 Dec 2007 03:09:50 +0900 X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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 Alex, On 2007/11/30, at 19:59, Alexandru Petrescu wrote: > RYUJI WAKIKAWA wrote: > [...] > Snipping much of the text you wrote to which I already agree. > >> - In section 4.1.2, it said Fig. 1, even if MR1 would be able to >> provision MR3 with prefixes, using DHCP [4], it cannot be assumed >> that MR1 or MR3 will not move and become unable to communicate >> directly. On the other hand, frequent reconfiguration may cause IPv6 >> Stateless Address Autoconfiguration [5] to be much less efficient >> than expected, due to large amounts of control signalling. >> This paragraph assume running DHCP and AUTOCONF over multihop. >> Do you assume that MR1 is DHCP relay ?? There is no way to forward >> DHCP messages by MR1. > > If MR1 is right next to MR3 (no dots) then MR1 can be a DHCP Relay and > the ISP Edge Router can be a DHCP Server, and MR3 the DHCP Client. > This OK. If this is the intentional operation, authors should describe this in the draft. > > DHCPv6-PD is specified to work ok. In implementation there are > however some issues with some DHCPv6-PD implementations. For > example, this works ok with addresses (DHCPv6 for addresses not > prefixes), but for delegating a prefix: one implementation crashes > the Relay and another implementation does not add a route on the > Server, IIRC. I see. I also think that DHCP behaviors are sometime different between implementations.. regards, ryuji > > > For reference the figure is: >> ----- MR1...MR3 >> / . >> +-------------+ +------------+ / . >> | | p2p | |/ . >> (MANET) >> | ISP Edge | Link | Border | . >> | Router +---------+ Router |\ . >> | | | | \ . >> +-------------+ +------------+ \----- MR2 >> Fig. 1. Connected MANET router topology. > > >> The document repeated to say that "as-is" existing solution does not >> fit to manet environment. I don't think these texts are useful >> explanation in this document. If you want to explain the constraints >> of existing solutions, you should have independent section how >> DHCP/NDP cannot fit to manet more in detail, please. Problem >> statement document should not suggest or assume any solutions. > > I kind of agree. > >> - I'm not sure but "broadcast" may be IPv4 term!? > > I saw very little 'broadcast' in IPv6 contexts. I mainly see > 'multicast' when discussing IPv6. 'Multicast' is also largely used > when talking link-layer MAC scope multicast. > > [...] > >> - Section 6, if you mention the security issue specific to AUTOCONF >> (Not NDP), you should write in the section 4. You can refer the >> section in the security consideration section. It will be nice if you >> can list up all possible security threats regarding AUTOCONF >> solutions (rather than referring security considerations of >> existing solutions). > > I agree. > > Alex > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Sun Dec 02 04:24:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyl3e-0006Zs-HH; Sun, 02 Dec 2007 04:24:14 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Iyl3d-0006Xs-BO for autoconf-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 04:24:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyl3c-0006Uj-Vl for autoconf@ietf.org; Sun, 02 Dec 2007 04:24:13 -0500 Received: from ccmail.cc.niigata-u.ac.jp ([133.35.23.1] helo=mxav01.cc.niigata-u.ac.jp) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iyl3a-0000Y8-Gp for autoconf@ietf.org; Sun, 02 Dec 2007 04:24:12 -0500 Received: from mxav01.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 146484F805F for ; Sun, 2 Dec 2007 18:24:08 +0900 (JST) Received: from mxav01.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by mxav01.cc.niigata-u.ac.jp (Postfix) with SMTP id 00E064F805B for ; Sun, 2 Dec 2007 18:24:08 +0900 (JST) Received: (qmail 4737 invoked from network); 2 Dec 2007 18:24:07 +0900 Received: from unknown (HELO chamame.ie.niigata-u.ac.jp) (133.35.169.34) by mxav01.cc.niigata-u.ac.jp with SMTP; 2 Dec 2007 18:24:07 +0900 Received: (qmail 18501 invoked from network); 2 Dec 2007 18:24:07 +0900 Received: from unknown (HELO neccomputer.ie.niigata-u.ac.jp) (133.35.156.66) by chamame.ie.niigata-u.ac.jp with SMTP; 2 Dec 2007 18:24:07 +0900 Message-Id: <7.0.0.16.2.20071202181233.04971348@ie.niigata-u.ac.jp> X-Mailer: QUALCOMM Windows Eudora Version 7J rev1.0 Date: Sun, 02 Dec 2007 18:24:12 +0900 To: RYUJI WAKIKAWA , autoconf@ietf.org From: mase Subject: Re: [Autoconf] comments to autoconf PS In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 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 Dear Ryuji, Thank you for your good comments. I agree that it is very important to make clear the scope when discussing autoconfiguration. With regard to the definition of MANET-local address, I am also not satisfied with the current definition. My proposal is as follows: MANET-local address an address having MANET-only scope that can be used to reach destinations in the MANET. All MANET interfaces have a MANET-local unicast address. What is MANET is given in the manetarch document, so I think that the above definition is clear. In reality, I think that we may use unique local IPv6 unicast address for MANET-local address. I think that we cannot depend on link-local address, since MANET interface is SBI. In this context, I think that link-local address must not be used in MANET routing messages as well as data forwarding. This is my personal opinion at this time and need to discuss with the co-authors. Anyway, these points must be clearly described in the PS domument, as you suggested. Sorry for the only partial answer to your comments. Regards, Kenichi At 03:33 07/11/30, RYUJI WAKIKAWA wrote: >Hi Emmanuel and all, > >First of all, i am sorry for my long silence, I needed some time to >recover from MANEMO wars in previous IETFs:-p > >I finally reviewed this document and have a lot of comments, though >some of my comments may be overlapped with others or already be >discussed in ML. > >To be honest, I am not such comfortable with this document >(except for the description of uniqueness issue which is well >explained!). >There are so many unclear explanation. Let me explain the >general comments first and then detail my comments later. > >- Do you assume DHCP and RA(NDP) as solutions of AUTOCONF? >NDP does not deal with prefix assignment. If you want to assign >prefix, stateless approach defined in RFC4862 is impossible, IMO. >A "stateful" mechanism using NDP might be possible if we can design so. > >- Scope Issue >There is nowhere to discuss which scope of address/prefix should be >assigned to which interface. It is very important to consider the >address scope in IPv6. For example, there is no discussion whether >manet nodes in a same manet uses the same scope for MLP/MLA. Can >MANET-A having link-local sends packets to MANET-B having only global >? This goes against IPv6 spec. > >According to manet-arch, each manet node needs to obtain "unique >prefix" instead of address for its local network and also must obtain >"unique prefix or address" for manet interface, too. Am I right? >For the first prefix, there are two possibility: global prefix or >uniquelocal prefix. >For the second, five possibility: global prefix, global address, >uniquelocal prefix, uniquelocal address, link local address. > >How can AUTOCONF deal with these scope and differences? I think it's >very important to use the same scope specially for MANET interface. >You can not send packets from link-local scope to global scope over >link. Other direction is OK. Do we agree on relaxing this scope >limitation in manet? > >Is there any definition that the same scope MUST be used for > MLP/MLA? > Does the word "valid" below indicate this? It should explicitly > write so. > >" MANET Local Prefix (MLP) - An IP prefix delegated to a MANET >router, > consisting in chunks of IP addresses valid for communications > inside the MANET. > MANET Local Address (MLA) - An IP address configured on a MANET > interface, and valid for communications inside the MANET." > >Actually, I am not clear what is MLA/MLP... >The document said in section 4.1 >"a MANET router needs to configure at least one IP address on its > MANET interface, this being a link local address, an MLA or a > global address." > >Does it mean MLA is unique local address?? > >- How can each manet node decide whether it can obtain prefix or >address on a manet interface? In IPv6, it is simpler that every node >generates a link-local address on its interface, while manet node may >not assign a link-local address on manet interface. How can this node >decide whether it should wait for prefix or simply generate a >link-local address? > >There is related question. How can a manet node detects whether it >attaches to manet or not? In IPv6, as soon as an interface becomes >active, it will start assigning a link-local address. However, a manet >node may wait this operation until it detects characteristics of >attached network (regular IPv6 or manet)... This is also one of issue >how a node can deploy both in manet and regular IPv6. In addition to >this, a manet node may need to detect connected or standalone manet >when it attaches to a network in order to discover ICP?!. > >- Last general question: for the prefix assignment to manet (not manet >interface), There are two possibility depending on ICP availability: >topologically correct prefix or non correct prefix. I think this is >two different things though the goal is same assigning prefix to >manet. Shall a solution support both scenarios? > >-------------------------------------------------------------------------------- >Detailed comments > >- In section 4.1.1, it only said >" IPv6 Stateless Address Autoconfiguration [5] and Neighbor Discovery > for IPv6 [3] do not account for potential address duplication beyond > a single multicast-capable link." > >NDP actually does not consider "multi-hop" support at all. I think >this address duplication is side-effect of no multi-hop consideration. > >- Why do you say "p2p link" between border router and ISP edge router > in figure 1??? > >- In section 4.1.2, it said > Fig. 1, even if MR1 would be able to provision MR3 with prefixes, > using DHCP [4], it cannot be assumed that MR1 or MR3 will not move > and become unable to communicate directly. On the other hand, > frequent reconfiguration may cause IPv6 Stateless Address > Autoconfiguration [5] to be much less efficient than expected, due >to > large amounts of control signalling. > >This paragraph assume running DHCP and AUTOCONF over multihop. > >Do you assume that MR1 is DHCP relay ?? There is no way to forward >DHCP messages by MR1. The document repeated to say that "as-is" >existing solution does not fit to manet environment. I don't think >these texts are useful explanation in this document. If you want to >explain the constraints of existing solutions, you should have >independent section how DHCP/NDP cannot fit to manet more in detail, >please. Problem statement document should not suggest or assume any >solutions. > >- I'm not sure but "broadcast" may be IPv4 term!? > >- Section 4.2.3 > When a router changes its ICP affiliation, some routes may be >broken, > affecting MANET packet forwarding performance and applications. >In a > multiple border router / multiple-prefixes MANET, frequent > reconfiguration could cause a large amount of control signalling >(for > instance if [5] is used). > >Isn't this problem of DHCP? >Do you assume that a manet node can unicast renew message over >connected ICP to the previous ICP and continue using the same >address?!:-p >Or you just mention NDP? It is no clear to me what is the intention >you refer only NDP here. > >- Section 5, It contains only general considerations. >Not specific to AUTOCONF solutions. > >- Section 6, if you mention the security issue specific to AUTOCONF > (Not NDP), you should write in the section 4. You can refer the > section in the security consideration section. It will be nice if > you can list up all possible security threats regarding AUTOCONF > solutions (rather than referring security considerations of existing > solutions). > > > > > > > >_______________________________________________ >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 Sun Dec 02 16:30:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IywNz-0001Yb-4u; Sun, 02 Dec 2007 16:29:59 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IywNy-0001YM-9X for autoconf-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 16:29:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IywNx-0001YC-VI for autoconf@ietf.org; Sun, 02 Dec 2007 16:29:57 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IywNw-0001Zi-7k for autoconf@ietf.org; Sun, 02 Dec 2007 16:29:57 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-128.messagelabs.com!1196630994!18383246!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 6185 invoked from network); 2 Dec 2007 21:29:54 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-128.messagelabs.com with SMTP; 2 Dec 2007 21:29:54 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lB2LTsDd002578; Sun, 2 Dec 2007 14:29:54 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id lB2LTrmH001964; Sun, 2 Dec 2007 15:29:53 -0600 (CST) Received: from [127.0.0.1] ([10.19.244.75]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id lB2LTqjX001951; Sun, 2 Dec 2007 15:29:52 -0600 (CST) Message-ID: <475323CF.4080604@gmail.com> Date: Sun, 02 Dec 2007 22:29:51 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: mase Subject: Re: [Autoconf] comments to autoconf PS References: <7.0.0.16.2.20071202181233.04971348@ie.niigata-u.ac.jp> In-Reply-To: <7.0.0.16.2.20071202181233.04971348@ie.niigata-u.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071128-0, 28/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 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 mase, I have some opinions compared to your opinions, just some discussion. I mainly agree with your suggestions to define addresses. mase wrote: > Dear Ryuji, > > Thank you for your good comments. I agree that it is very important > to make clear the scope when discussing autoconfiguration. > > With regard to the definition of MANET-local address, I am also not > satisfied with the current definition. My proposal is as follows: > MANET-local address an address having MANET-only scope that can be > used to reach destinations in the MANET. All MANET interfaces have a > MANET-local unicast address. But looks as it is a recursive definition? When you say 'reach' do you mean the packet can be forwarded by a intermediary router? Or is it that the packet is reaching the destination without being forwarded by any router? Otherwise all packets have to reach their destinations. I'm tempted to define like this: MANET-local address An IPv6 link-local address. This has pretty good semantics in my understanding. Opinions? > What is MANET is given in the manetarch document, so I think that the > above definition is clear. In reality, I think that we may use > unique local IPv6 unicast address for MANET-local address. I think ULA (Unique Local Addresses) don't have a scope related to the link. I think a ULA addressed packet can reach a destination in a MANET and sometimes it has to be forwarded to achieve that goal. You seem to say: MANET-local address A Unique Local Address (ULA RFCxxxx) If so, then I agree with you. > I think that we cannot depend on link-local address, since MANET > interface is SBI. I think it is strange to assume that a MANET uses _only_ SBI interfaces. I think I can build a MANET that does _not_ use SBI interfaces. In such a case I think IPv6 link-local addresses can be useful. Alex > In this context, I think that link-local address must not be used in > MANET routing messages as well as data forwarding. This is my > personal opinion at this time and need to discuss with the > co-authors. Anyway, these points must be clearly described in the PS > domument, as you suggested. Sorry for the only partial answer to your > comments. > > Regards, Kenichi > > At 03:33 07/11/30, RYUJI WAKIKAWA wrote: >> Hi Emmanuel and all, >> >> First of all, i am sorry for my long silence, I needed some time to >> recover from MANEMO wars in previous IETFs:-p >> >> I finally reviewed this document and have a lot of comments, though >> some of my comments may be overlapped with others or already be >> discussed in ML. >> >> To be honest, I am not such comfortable with this document (except >> for the description of uniqueness issue which is well explained!). >> There are so many unclear explanation. Let me explain the general >> comments first and then detail my comments later. >> >> - Do you assume DHCP and RA(NDP) as solutions of AUTOCONF? NDP does >> not deal with prefix assignment. If you want to assign prefix, >> stateless approach defined in RFC4862 is impossible, IMO. A >> "stateful" mechanism using NDP might be possible if we can design >> so. >> >> - Scope Issue There is nowhere to discuss which scope of >> address/prefix should be assigned to which interface. It is very >> important to consider the address scope in IPv6. For example, >> there is no discussion whether manet nodes in a same manet uses the >> same scope for MLP/MLA. Can MANET-A having link-local sends >> packets to MANET-B having only global ? This goes against IPv6 >> spec. >> >> According to manet-arch, each manet node needs to obtain "unique >> prefix" instead of address for its local network and also must >> obtain "unique prefix or address" for manet interface, too. Am I >> right? For the first prefix, there are two possibility: global >> prefix or uniquelocal prefix. For the second, five possibility: >> global prefix, global address, uniquelocal prefix, uniquelocal >> address, link local address. >> >> How can AUTOCONF deal with these scope and differences? I think >> it's very important to use the same scope specially for MANET >> interface. You can not send packets from link-local scope to global >> scope over link. Other direction is OK. Do we agree on relaxing >> this scope limitation in manet? >> >> Is there any definition that the same scope MUST be used for >> MLP/MLA? Does the word "valid" below indicate this? It should >> explicitly write so. >> >> " MANET Local Prefix (MLP) - An IP prefix delegated to a MANET >> router, consisting in chunks of IP addresses valid for >> communications inside the MANET. MANET Local Address (MLA) - An IP >> address configured on a MANET interface, and valid for >> communications inside the MANET." >> >> Actually, I am not clear what is MLA/MLP... The document said in >> section 4.1 "a MANET router needs to configure at least one IP >> address on its MANET interface, this being a link local address, an >> MLA or a global address." >> >> Does it mean MLA is unique local address?? >> >> - How can each manet node decide whether it can obtain prefix or >> address on a manet interface? In IPv6, it is simpler that every >> node generates a link-local address on its interface, while manet >> node may not assign a link-local address on manet interface. How >> can this node decide whether it should wait for prefix or simply >> generate a link-local address? >> >> There is related question. How can a manet node detects whether it >> attaches to manet or not? In IPv6, as soon as an interface becomes >> active, it will start assigning a link-local address. However, a >> manet node may wait this operation until it detects characteristics >> of attached network (regular IPv6 or manet)... This is also one of >> issue how a node can deploy both in manet and regular IPv6. In >> addition to this, a manet node may need to detect connected or >> standalone manet when it attaches to a network in order to discover >> ICP?!. >> >> - Last general question: for the prefix assignment to manet (not >> manet interface), There are two possibility depending on ICP >> availability: topologically correct prefix or non correct prefix. I >> think this is two different things though the goal is same >> assigning prefix to manet. Shall a solution support both >> scenarios? >> >> -------------------------------------------------------------------------------- >> >> >> >> Detailed comments >> >> - In section 4.1.1, it only said " IPv6 Stateless Address >> Autoconfiguration [5] and Neighbor Discovery for IPv6 [3] do not >> account for potential address duplication beyond a single >> multicast-capable link." >> >> NDP actually does not consider "multi-hop" support at all. I think >> this address duplication is side-effect of no multi-hop >> consideration. >> >> - Why do you say "p2p link" between border router and ISP edge >> router in figure 1??? >> >> - In section 4.1.2, it said Fig. 1, even if MR1 would be able to >> provision MR3 with prefixes, using DHCP [4], it cannot be assumed >> that MR1 or MR3 will not move and become unable to communicate >> directly. On the other hand, frequent reconfiguration may cause >> IPv6 Stateless Address Autoconfiguration [5] to be much less >> efficient than expected, due to large amounts of control >> signalling. >> >> This paragraph assume running DHCP and AUTOCONF over multihop. >> >> Do you assume that MR1 is DHCP relay ?? There is no way to forward >> DHCP messages by MR1. The document repeated to say that "as-is" >> existing solution does not fit to manet environment. I don't think >> these texts are useful explanation in this document. If you want >> to explain the constraints of existing solutions, you should have >> independent section how DHCP/NDP cannot fit to manet more in >> detail, please. Problem statement document should not suggest or >> assume any solutions. >> >> - I'm not sure but "broadcast" may be IPv4 term!? >> >> - Section 4.2.3 When a router changes its ICP affiliation, some >> routes may be broken, affecting MANET packet forwarding performance >> and applications. In a multiple border router / multiple-prefixes >> MANET, frequent reconfiguration could cause a large amount of >> control signalling (for instance if [5] is used). >> >> Isn't this problem of DHCP? Do you assume that a manet node can >> unicast renew message over connected ICP to the previous ICP and >> continue using the same address?!:-p Or you just mention NDP? It >> is no clear to me what is the intention you refer only NDP here. >> >> - Section 5, It contains only general considerations. Not specific >> to AUTOCONF solutions. >> >> - Section 6, if you mention the security issue specific to AUTOCONF >> (Not NDP), you should write in the section 4. You can refer the >> section in the security consideration section. It will be nice if >> you can list up all possible security threats regarding AUTOCONF >> solutions (rather than referring security considerations of >> existing solutions). >> >> >> >> >> >> >> >> _______________________________________________ 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 > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Sun Dec 02 22:21:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz1rf-0000jM-SC; Sun, 02 Dec 2007 22:20:59 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Iz1re-0000g0-RQ for autoconf-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 22:20:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz1re-0000dU-FF for autoconf@ietf.org; Sun, 02 Dec 2007 22:20:58 -0500 Received: from ccmail.cc.niigata-u.ac.jp ([133.35.23.1] helo=mxav02.cc.niigata-u.ac.jp) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iz1rc-00018c-Hf for autoconf@ietf.org; Sun, 02 Dec 2007 22:20:58 -0500 Received: from mxav02.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8B506454F0B for ; Mon, 3 Dec 2007 12:19:18 +0900 (JST) Received: from mxav02.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by mxav02.cc.niigata-u.ac.jp (Postfix) with SMTP id 79AA34585DD for ; Mon, 3 Dec 2007 12:19:18 +0900 (JST) Received: (qmail 10312 invoked from network); 3 Dec 2007 12:19:18 +0900 Received: from unknown (HELO chamame.ie.niigata-u.ac.jp) (133.35.169.34) by mxav02.cc.niigata-u.ac.jp with SMTP; 3 Dec 2007 12:19:18 +0900 Received: (qmail 28542 invoked from network); 3 Dec 2007 12:19:18 +0900 Received: from unknown (HELO neccomputer.ie.niigata-u.ac.jp) (133.35.156.66) by chamame.ie.niigata-u.ac.jp with SMTP; 3 Dec 2007 12:19:18 +0900 Message-Id: <7.0.0.16.2.20071203115230.04bda790@ie.niigata-u.ac.jp> X-Mailer: QUALCOMM Windows Eudora Version 7J rev1.0 Date: Mon, 03 Dec 2007 12:19:24 +0900 To: Alexandru Petrescu From: mase Subject: Re: [Autoconf] comments to autoconf PS In-Reply-To: <475323CF.4080604@gmail.com> References: <7.0.0.16.2.20071202181233.04971348@ie.niigata-u.ac.jp> <475323CF.4080604@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b 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, Alex, At 06:29 07/12/03, Alexandru Petrescu wrote: >Hi mase, I have some opinions compared to your opinions, just some >discussion. I mainly agree with your suggestions to define addresses. Thanks. >mase wrote: >>Dear Ryuji, >>Thank you for your good comments. I agree that it is very >>important to make clear the scope when discussing autoconfiguration. >>With regard to the definition of MANET-local address, I am also >>not satisfied with the current definition. My proposal is as >>follows: MANET-local address an address having MANET-only scope >>that can be used to reach destinations in the MANET. All MANET >>interfaces have a MANET-local unicast address. > >But looks as it is a recursive definition? I have a suggestion of this style from the definition of link-local address of RFC4862. >When you say 'reach' do you mean the packet can be forwarded by a >intermediary router? Right. >Or is it that the packet is reaching the >destination without being forwarded by any router? > >Otherwise all packets have to reach their destinations. > >I'm tempted to define like this: > > MANET-local address > > An IPv6 link-local address. IMHO, this is not reasonalbe because forwarding is necessary to deliver packets to the destination, when source and destinatio MANET routers are not neighbors to each other. >This has pretty good semantics in my understanding. Opinions? > >>What is MANET is given in the manetarch document, so I think that the >> above definition is clear. In reality, I think that we may use >> unique local IPv6 unicast address for MANET-local address. > >I think ULA (Unique Local Addresses) don't have a scope related to the >link. I think a ULA addressed packet can reach a destination in a MANET >and sometimes it has to be forwarded to achieve that goal. > >You seem to say: > > MANET-local address > > A Unique Local Address (ULA RFCxxxx) > >If so, then I agree with you. I think that unique local address is a good candidate to be used in the MANET. >>I think that we cannot depend on link-local address, since MANET >>interface is SBI. > >I think it is strange to assume that a MANET uses _only_ SBI interfaces. > I think I can build a MANET that does _not_ use SBI interfaces. In >such a case I think IPv6 link-local addresses can be useful. As mentioned above, packet forwarding is necessary in general in a MANET. Thus link-local address is not appropriate as the source/destination address. Kenichi >Alex > >>In this context, I think that link-local address must not be used in >>MANET routing messages as well as data forwarding. This is my >>personal opinion at this time and need to discuss with the >>co-authors. Anyway, these points must be clearly described in the >>PS domument, as you suggested. Sorry for the only partial answer to your >>comments. >>Regards, Kenichi >>At 03:33 07/11/30, RYUJI WAKIKAWA wrote: >>>Hi Emmanuel and all, >>>First of all, i am sorry for my long silence, I needed some time to >>> recover from MANEMO wars in previous IETFs:-p >>>I finally reviewed this document and have a lot of comments, though >>> some of my comments may be overlapped with others or already >>> be discussed in ML. >>>To be honest, I am not such comfortable with this document >>>(except for the description of uniqueness issue which is well explained!). >>> There are so many unclear explanation. Let me explain the >>> general comments first and then detail my comments later. >>>- Do you assume DHCP and RA(NDP) as solutions of AUTOCONF? NDP does >>> not deal with prefix assignment. If you want to assign >>> prefix, stateless approach defined in RFC4862 is impossible, IMO. >>> A "stateful" mechanism using NDP might be possible if we can design so. >>>- Scope Issue There is nowhere to discuss which scope of >>>address/prefix should be assigned to which interface. It is very >>>important to consider the address scope in IPv6. For example, >>>there is no discussion whether manet nodes in a same manet uses the >>> same scope for MLP/MLA. Can MANET-A having link-local sends >>> packets to MANET-B having only global ? This goes against IPv6 spec. >>>According to manet-arch, each manet node needs to obtain >>>"unique prefix" instead of address for its local network and also >>>must obtain "unique prefix or address" for manet interface, too. >>>Am I right? For the first prefix, there are two possibility: >>>global prefix or uniquelocal prefix. For the second, five >>>possibility: global prefix, global address, uniquelocal prefix, >>>uniquelocal address, link local address. >>>How can AUTOCONF deal with these scope and differences? I >>>think it's very important to use the same scope specially for >>>MANET interface. You can not send packets from link-local scope to global >>> scope over link. Other direction is OK. Do we agree on >>> relaxing this scope limitation in manet? >>>Is there any definition that the same scope MUST be used for >>>MLP/MLA? Does the word "valid" below indicate this? It should >>>explicitly write so. >>>" MANET Local Prefix (MLP) - An IP prefix delegated to a >>>MANET router, consisting in chunks of IP addresses valid for >>>communications inside the MANET. MANET Local Address (MLA) - An IP >>> address configured on a MANET interface, and valid for >>> communications inside the MANET." >>>Actually, I am not clear what is MLA/MLP... The document said >>>in section 4.1 "a MANET router needs to configure at least one IP >>>address on its MANET interface, this being a link local address, an >>> MLA or a global address." >>>Does it mean MLA is unique local address?? >>>- How can each manet node decide whether it can obtain prefix >>>or address on a manet interface? In IPv6, it is simpler that >>>every node generates a link-local address on its interface, while >>>manet node may not assign a link-local address on manet interface. >>>How can this node decide whether it should wait for prefix or >>>simply generate a link-local address? >>>There is related question. How can a manet node detects whether it >>> attaches to manet or not? In IPv6, as soon as an interface becomes >>> active, it will start assigning a link-local address. >>> However, a manet node may wait this operation until it detects characteristics >>> of attached network (regular IPv6 or manet)... This is also one of >>> issue how a node can deploy both in manet and regular IPv6. >>> In addition to this, a manet node may need to detect connected or >>> standalone manet when it attaches to a network in order to discover >>> ICP?!. >>>- Last general question: for the prefix assignment to manet >>>(not manet interface), There are two possibility depending on ICP >>>availability: topologically correct prefix or non correct prefix. I >>>think this is two different things though the goal is same >>>assigning prefix to manet. Shall a solution support both scenarios? >>>-------------------------------------------------------------------------------- >>> >>>Detailed comments >>>- In section 4.1.1, it only said " IPv6 Stateless Address >>>Autoconfiguration [5] and Neighbor Discovery for IPv6 [3] do not >>>account for potential address duplication beyond a single >>>multicast-capable link." >>>NDP actually does not consider "multi-hop" support at all. I think >>> this address duplication is side-effect of no multi-hop consideration. >>>- Why do you say "p2p link" between border router and ISP edge >>>router in figure 1??? >>>- In section 4.1.2, it said Fig. 1, even if MR1 would be able >>>to provision MR3 with prefixes, using DHCP [4], it cannot be >>>assumed that MR1 or MR3 will not move and become unable to >>>communicate directly. On the other hand, frequent reconfiguration >>>may cause IPv6 Stateless Address Autoconfiguration [5] to be much >>>less efficient than expected, due to large amounts of control signalling. >>>This paragraph assume running DHCP and AUTOCONF over multihop. >>>Do you assume that MR1 is DHCP relay ?? There is no way to forward >>> DHCP messages by MR1. The document repeated to say that >>> "as-is" existing solution does not fit to manet environment. I don't think >>> these texts are useful explanation in this document. If you want >>>to explain the constraints of existing solutions, you should >>>have independent section how DHCP/NDP cannot fit to manet more in >>>detail, please. Problem statement document should not suggest or >>>assume any solutions. >>>- I'm not sure but "broadcast" may be IPv4 term!? >>>- Section 4.2.3 When a router changes its ICP affiliation, some >>>routes may be broken, affecting MANET packet forwarding performance >>> and applications. In a multiple border router / >>> multiple-prefixes MANET, frequent reconfiguration could cause a >>> large amount of control signalling (for instance if [5] is used). >>>Isn't this problem of DHCP? Do you assume that a manet node >>>can unicast renew message over connected ICP to the previous ICP >>>and continue using the same address?!:-p Or you just mention NDP? >>>It is no clear to me what is the intention you refer only NDP here. >>>- Section 5, It contains only general considerations. Not >>>specific to AUTOCONF solutions. >>>- Section 6, if you mention the security issue specific to AUTOCONF >>> (Not NDP), you should write in the section 4. You can refer >>> the section in the security consideration section. It will be >>> nice if you can list up all possible security threats regarding >>> AUTOCONF solutions (rather than referring security considerations >>> of existing solutions). >>> >>> >>> >>>_______________________________________________ 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 > > >______________________________________________________________________ >This email has been scanned by the MessageLabs Email Security System. >For more information please visit >http://www.messagelabs.com/email >______________________________________________________________________ > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Sun Dec 02 22:41:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz2Bv-00038v-7X; Sun, 02 Dec 2007 22:41:55 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Iz2Bt-00038i-FK for autoconf-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 22:41:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz2Bt-00038H-3l for autoconf@ietf.org; Sun, 02 Dec 2007 22:41:53 -0500 Received: from mail.globalsuite.net ([69.46.103.200]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iz2Bp-00038G-Mr for autoconf@ietf.org; Sun, 02 Dec 2007 22:41:50 -0500 X-AuditID: c0a8013c-aff27bb000001e2e-a7-47537aea4776 Received: from M90Teco (unknown [207.236.117.226]) by mail.globalsuite.net (Symantec Mail Security) with ESMTP id 2AA044DC003; Sun, 2 Dec 2007 20:41:24 -0700 (MST) From: "Teco Boot" To: "'mase'" , "'Alexandru Petrescu'" References: <7.0.0.16.2.20071202181233.04971348@ie.niigata-u.ac.jp> <475323CF.4080604@gmail.com> <7.0.0.16.2.20071203115230.04bda790@ie.niigata-u.ac.jp> In-Reply-To: <7.0.0.16.2.20071203115230.04bda790@ie.niigata-u.ac.jp> Subject: RE: [Autoconf] comments to autoconf PS Date: Mon, 3 Dec 2007 04:41:08 +0100 Message-ID: <002301c8355e$639a3e70$2acebb50$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg1W6QCUmMfVnowRL6q3XynOkx+sAAAbcaQ Content-Language: nl X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 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 Alex, Kenichi, I want to share my thoughts on link-local addresses and MLA with you. I think link-locals are essential to IPv6. I do not understand why we have a discussion on this. It is to be used for single hop communication, which is also very applicable in MANET. I think MLA's are to be used for multi hop communications in the MANET. I agree ULA is an obvious candidate for MLA. Teco. > -----Oorspronkelijk bericht----- > Van: mase [mailto:mase@ie.niigata-u.ac.jp] > Verzonden: maandag 3 december 2007 4:19 > Aan: Alexandru Petrescu > CC: autoconf@ietf.org > Onderwerp: Re: [Autoconf] comments to autoconf PS > > Hi, Alex, > > At 06:29 07/12/03, Alexandru Petrescu wrote: > >Hi mase, I have some opinions compared to your opinions, just some > >discussion. I mainly agree with your suggestions to define addresses. > > Thanks. > > > >mase wrote: > >>Dear Ryuji, > >>Thank you for your good comments. I agree that it is very > >>important to make clear the scope when discussing autoconfiguration. > >>With regard to the definition of MANET-local address, I am also > >>not satisfied with the current definition. My proposal is as > >>follows: MANET-local address an address having MANET-only scope > >>that can be used to reach destinations in the MANET. All MANET > >>interfaces have a MANET-local unicast address. > > > >But looks as it is a recursive definition? > > I have a suggestion of this style from the definition of link-local > address of RFC4862. > > > >When you say 'reach' do you mean the packet can be forwarded by a > >intermediary router? > > Right. > > >Or is it that the packet is reaching the > >destination without being forwarded by any router? > > > >Otherwise all packets have to reach their destinations. > > > >I'm tempted to define like this: > > > > MANET-local address > > > > An IPv6 link-local address. > > IMHO, this is not reasonalbe because forwarding is necessary to > deliver packets to the destination, when source and destinatio > MANET routers are not neighbors to each other. > > > >This has pretty good semantics in my understanding. Opinions? > > > >>What is MANET is given in the manetarch document, so I think that the > >> above definition is clear. In reality, I think that we may use > >> unique local IPv6 unicast address for MANET-local address. > > > >I think ULA (Unique Local Addresses) don't have a scope related to the > >link. I think a ULA addressed packet can reach a destination in a > MANET > >and sometimes it has to be forwarded to achieve that goal. > > > >You seem to say: > > > > MANET-local address > > > > A Unique Local Address (ULA RFCxxxx) > > > >If so, then I agree with you. > > I think that unique local address is a good candidate to be used in the > MANET. > > > >>I think that we cannot depend on link-local address, since MANET > >>interface is SBI. > > > >I think it is strange to assume that a MANET uses _only_ SBI > interfaces. > > I think I can build a MANET that does _not_ use SBI interfaces. In > >such a case I think IPv6 link-local addresses can be useful. > > As mentioned above, packet forwarding is necessary in general in a > MANET. Thus link-local address is not appropriate as the > source/destination address. > > Kenichi > > > >Alex > > > >>In this context, I think that link-local address must not be used in > >>MANET routing messages as well as data forwarding. This is my > >>personal opinion at this time and need to discuss with the > >>co-authors. Anyway, these points must be clearly described in the > >>PS domument, as you suggested. Sorry for the only partial answer to > your > >>comments. > >>Regards, Kenichi > >>At 03:33 07/11/30, RYUJI WAKIKAWA wrote: > >>>Hi Emmanuel and all, > >>>First of all, i am sorry for my long silence, I needed some time to > >>> recover from MANEMO wars in previous IETFs:-p > >>>I finally reviewed this document and have a lot of comments, though > >>> some of my comments may be overlapped with others or already > >>> be discussed in ML. > >>>To be honest, I am not such comfortable with this document > >>>(except for the description of uniqueness issue which is well > explained!). > >>> There are so many unclear explanation. Let me explain the > >>> general comments first and then detail my comments later. > >>>- Do you assume DHCP and RA(NDP) as solutions of AUTOCONF? NDP does > >>> not deal with prefix assignment. If you want to assign > >>> prefix, stateless approach defined in RFC4862 is impossible, IMO. > >>> A "stateful" mechanism using NDP might be possible if we can design > so. > >>>- Scope Issue There is nowhere to discuss which scope of > >>>address/prefix should be assigned to which interface. It is very > >>>important to consider the address scope in IPv6. For example, > >>>there is no discussion whether manet nodes in a same manet uses the > >>> same scope for MLP/MLA. Can MANET-A having link-local sends > >>> packets to MANET-B having only global ? This goes against IPv6 > spec. > >>>According to manet-arch, each manet node needs to obtain > >>>"unique prefix" instead of address for its local network and also > >>>must obtain "unique prefix or address" for manet interface, too. > >>>Am I right? For the first prefix, there are two possibility: > >>>global prefix or uniquelocal prefix. For the second, five > >>>possibility: global prefix, global address, uniquelocal prefix, > >>>uniquelocal address, link local address. > >>>How can AUTOCONF deal with these scope and differences? I > >>>think it's very important to use the same scope specially for > >>>MANET interface. You can not send packets from link-local scope to > global > >>> scope over link. Other direction is OK. Do we agree on > >>> relaxing this scope limitation in manet? > >>>Is there any definition that the same scope MUST be used for > >>>MLP/MLA? Does the word "valid" below indicate this? It should > >>>explicitly write so. > >>>" MANET Local Prefix (MLP) - An IP prefix delegated to a > >>>MANET router, consisting in chunks of IP addresses valid for > >>>communications inside the MANET. MANET Local Address (MLA) - An IP > >>> address configured on a MANET interface, and valid for > >>> communications inside the MANET." > >>>Actually, I am not clear what is MLA/MLP... The document said > >>>in section 4.1 "a MANET router needs to configure at least one IP > >>>address on its MANET interface, this being a link local address, an > >>> MLA or a global address." > >>>Does it mean MLA is unique local address?? > >>>- How can each manet node decide whether it can obtain prefix > >>>or address on a manet interface? In IPv6, it is simpler that > >>>every node generates a link-local address on its interface, while > >>>manet node may not assign a link-local address on manet interface. > >>>How can this node decide whether it should wait for prefix or > >>>simply generate a link-local address? > >>>There is related question. How can a manet node detects whether it > >>> attaches to manet or not? In IPv6, as soon as an interface becomes > >>> active, it will start assigning a link-local address. > >>> However, a manet node may wait this operation until it detects > characteristics > >>> of attached network (regular IPv6 or manet)... This is also one of > >>> issue how a node can deploy both in manet and regular IPv6. > >>> In addition to this, a manet node may need to detect connected or > >>> standalone manet when it attaches to a network in order to discover > >>> ICP?!. > >>>- Last general question: for the prefix assignment to manet > >>>(not manet interface), There are two possibility depending on ICP > >>>availability: topologically correct prefix or non correct prefix. I > >>>think this is two different things though the goal is same > >>>assigning prefix to manet. Shall a solution support both scenarios? > >>>-------------------------------------------------------------------- > ------------ > >>> > >>>Detailed comments > >>>- In section 4.1.1, it only said " IPv6 Stateless Address > >>>Autoconfiguration [5] and Neighbor Discovery for IPv6 [3] do not > >>>account for potential address duplication beyond a single > >>>multicast-capable link." > >>>NDP actually does not consider "multi-hop" support at all. I think > >>> this address duplication is side-effect of no multi-hop > consideration. > >>>- Why do you say "p2p link" between border router and ISP edge > >>>router in figure 1??? > >>>- In section 4.1.2, it said Fig. 1, even if MR1 would be able > >>>to provision MR3 with prefixes, using DHCP [4], it cannot be > >>>assumed that MR1 or MR3 will not move and become unable to > >>>communicate directly. On the other hand, frequent reconfiguration > >>>may cause IPv6 Stateless Address Autoconfiguration [5] to be much > >>>less efficient than expected, due to large amounts of control > signalling. > >>>This paragraph assume running DHCP and AUTOCONF over multihop. > >>>Do you assume that MR1 is DHCP relay ?? There is no way to forward > >>> DHCP messages by MR1. The document repeated to say that > >>> "as-is" existing solution does not fit to manet environment. I > don't think > >>> these texts are useful explanation in this document. If you want > >>>to explain the constraints of existing solutions, you should > >>>have independent section how DHCP/NDP cannot fit to manet more in > >>>detail, please. Problem statement document should not suggest or > >>>assume any solutions. > >>>- I'm not sure but "broadcast" may be IPv4 term!? > >>>- Section 4.2.3 When a router changes its ICP affiliation, some > >>>routes may be broken, affecting MANET packet forwarding performance > >>> and applications. In a multiple border router / > >>> multiple-prefixes MANET, frequent reconfiguration could cause a > >>> large amount of control signalling (for instance if [5] is used). > >>>Isn't this problem of DHCP? Do you assume that a manet node > >>>can unicast renew message over connected ICP to the previous ICP > >>>and continue using the same address?!:-p Or you just mention NDP? > >>>It is no clear to me what is the intention you refer only NDP here. > >>>- Section 5, It contains only general considerations. Not > >>>specific to AUTOCONF solutions. > >>>- Section 6, if you mention the security issue specific to AUTOCONF > >>> (Not NDP), you should write in the section 4. You can refer > >>> the section in the security consideration section. It will be > >>> nice if you can list up all possible security threats regarding > >>> AUTOCONF solutions (rather than referring security considerations > >>> of existing solutions). > >>> > >>> > >>> > >>>_______________________________________________ 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 > > > > > >______________________________________________________________________ > >This email has been scanned by the MessageLabs Email Security System. > >For more information please visit > >http://www.messagelabs.com/email > >______________________________________________________________________ > > > > > > > _______________________________________________ > 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 Sun Dec 02 23:23:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz2q0-0003Qi-7V; Sun, 02 Dec 2007 23:23:20 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Iz2py-0003QP-FE for autoconf-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 23:23:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz2py-0003QB-3Y for autoconf@ietf.org; Sun, 02 Dec 2007 23:23:18 -0500 Received: from ccmail.cc.niigata-u.ac.jp ([133.35.23.1] helo=mxav01.cc.niigata-u.ac.jp) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iz2pv-0006dU-Kv for autoconf@ietf.org; Sun, 02 Dec 2007 23:23:17 -0500 Received: from mxav01.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E754F4F6927 for ; Mon, 3 Dec 2007 13:21:49 +0900 (JST) Received: from mxav01.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by mxav01.cc.niigata-u.ac.jp (Postfix) with SMTP id 2C2834F6E4D for ; Mon, 3 Dec 2007 13:04:37 +0900 (JST) Received: (qmail 21821 invoked from network); 3 Dec 2007 13:04:36 +0900 Received: from unknown (HELO chamame.ie.niigata-u.ac.jp) (133.35.169.34) by mxav01.cc.niigata-u.ac.jp with SMTP; 3 Dec 2007 13:04:36 +0900 Received: (qmail 31325 invoked from network); 3 Dec 2007 13:04:36 +0900 Received: from unknown (HELO neccomputer.ie.niigata-u.ac.jp) (133.35.156.66) by chamame.ie.niigata-u.ac.jp with SMTP; 3 Dec 2007 13:04:36 +0900 Message-Id: <7.0.0.16.2.20071203125837.049dbf18@ie.niigata-u.ac.jp> X-Mailer: QUALCOMM Windows Eudora Version 7J rev1.0 Date: Mon, 03 Dec 2007 13:04:42 +0900 To: "Teco Boot" , "'Alexandru Petrescu'" From: mase Subject: RE: [Autoconf] comments to autoconf PS In-Reply-To: <002301c8355e$639a3e70$2acebb50$@nl> References: <7.0.0.16.2.20071202181233.04971348@ie.niigata-u.ac.jp> <475323CF.4080604@gmail.com> <7.0.0.16.2.20071203115230.04bda790@ie.niigata-u.ac.jp> <002301c8355e$639a3e70$2acebb50$@nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb 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 Teco, Thank you for your comments. See in line. At 12:41 07/12/03, Teco Boot wrote: >Alex, Kenichi, > >I want to share my thoughts on link-local addresses and MLA with you. >I think link-locals are essential to IPv6. I do not understand why we have a >discussion on this. It is to be used for single hop communication, which is >also very applicable in MANET. Yes, but your former neighbor may be now out-of-transmission range and only communicated over multi-hop. Do you prefer to change your source/destination address from a link-local address to MLA? >I think MLA's are to be used for multi hop communications in the MANET. Right. >I agree ULA is an obvious candidate for MLA. Thanks, Kenichi >Teco. > > > -----Oorspronkelijk bericht----- > > Van: mase [mailto:mase@ie.niigata-u.ac.jp] > > Verzonden: maandag 3 december 2007 4:19 > > Aan: Alexandru Petrescu > > CC: autoconf@ietf.org > > Onderwerp: Re: [Autoconf] comments to autoconf PS > > > > Hi, Alex, > > > > At 06:29 07/12/03, Alexandru Petrescu wrote: > > >Hi mase, I have some opinions compared to your opinions, just some > > >discussion. I mainly agree with your suggestions to define addresses. > > > > Thanks. > > > > > > >mase wrote: > > >>Dear Ryuji, > > >>Thank you for your good comments. I agree that it is very > > >>important to make clear the scope when discussing autoconfiguration. > > >>With regard to the definition of MANET-local address, I am also > > >>not satisfied with the current definition. My proposal is as > > >>follows: MANET-local address an address having MANET-only scope > > >>that can be used to reach destinations in the MANET. All MANET > > >>interfaces have a MANET-local unicast address. > > > > > >But looks as it is a recursive definition? > > > > I have a suggestion of this style from the definition of link-local > > address of RFC4862. > > > > > > >When you say 'reach' do you mean the packet can be forwarded by a > > >intermediary router? > > > > Right. > > > > >Or is it that the packet is reaching the > > >destination without being forwarded by any router? > > > > > >Otherwise all packets have to reach their destinations. > > > > > >I'm tempted to define like this: > > > > > > MANET-local address > > > > > > An IPv6 link-local address. > > > > IMHO, this is not reasonalbe because forwarding is necessary to > > deliver packets to the destination, when source and destinatio > > MANET routers are not neighbors to each other. > > > > > > >This has pretty good semantics in my understanding. Opinions? > > > > > >>What is MANET is given in the manetarch document, so I think that the > > >> above definition is clear. In reality, I think that we may use > > >> unique local IPv6 unicast address for MANET-local address. > > > > > >I think ULA (Unique Local Addresses) don't have a scope related to the > > >link. I think a ULA addressed packet can reach a destination in a > > MANET > > >and sometimes it has to be forwarded to achieve that goal. > > > > > >You seem to say: > > > > > > MANET-local address > > > > > > A Unique Local Address (ULA RFCxxxx) > > > > > >If so, then I agree with you. > > > > I think that unique local address is a good candidate to be used in the > > MANET. > > > > > > >>I think that we cannot depend on link-local address, since MANET > > >>interface is SBI. > > > > > >I think it is strange to assume that a MANET uses _only_ SBI > > interfaces. > > > I think I can build a MANET that does _not_ use SBI interfaces. In > > >such a case I think IPv6 link-local addresses can be useful. > > > > As mentioned above, packet forwarding is necessary in general in a > > MANET. Thus link-local address is not appropriate as the > > source/destination address. > > > > Kenichi > > > > > > >Alex > > > > > >>In this context, I think that link-local address must not be used in > > >>MANET routing messages as well as data forwarding. This is my > > >>personal opinion at this time and need to discuss with the > > >>co-authors. Anyway, these points must be clearly described in the > > >>PS domument, as you suggested. Sorry for the only partial answer to > > your > > >>comments. > > >>Regards, Kenichi > > >>At 03:33 07/11/30, RYUJI WAKIKAWA wrote: > > >>>Hi Emmanuel and all, > > >>>First of all, i am sorry for my long silence, I needed some time to > > >>> recover from MANEMO wars in previous IETFs:-p > > >>>I finally reviewed this document and have a lot of comments, though > > >>> some of my comments may be overlapped with others or already > > >>> be discussed in ML. > > >>>To be honest, I am not such comfortable with this document > > >>>(except for the description of uniqueness issue which is well > > explained!). > > >>> There are so many unclear explanation. Let me explain the > > >>> general comments first and then detail my comments later. > > >>>- Do you assume DHCP and RA(NDP) as solutions of AUTOCONF? NDP does > > >>> not deal with prefix assignment. If you want to assign > > >>> prefix, stateless approach defined in RFC4862 is impossible, IMO. > > >>> A "stateful" mechanism using NDP might be possible if we can design > > so. > > >>>- Scope Issue There is nowhere to discuss which scope of > > >>>address/prefix should be assigned to which interface. It is very > > >>>important to consider the address scope in IPv6. For example, > > >>>there is no discussion whether manet nodes in a same manet uses the > > >>> same scope for MLP/MLA. Can MANET-A having link-local sends > > >>> packets to MANET-B having only global ? This goes against IPv6 > > spec. > > >>>According to manet-arch, each manet node needs to obtain > > >>>"unique prefix" instead of address for its local network and also > > >>>must obtain "unique prefix or address" for manet interface, too. > > >>>Am I right? For the first prefix, there are two possibility: > > >>>global prefix or uniquelocal prefix. For the second, five > > >>>possibility: global prefix, global address, uniquelocal prefix, > > >>>uniquelocal address, link local address. > > >>>How can AUTOCONF deal with these scope and differences? I > > >>>think it's very important to use the same scope specially for > > >>>MANET interface. You can not send packets from link-local scope to > > global > > >>> scope over link. Other direction is OK. Do we agree on > > >>> relaxing this scope limitation in manet? > > >>>Is there any definition that the same scope MUST be used for > > >>>MLP/MLA? Does the word "valid" below indicate this? It should > > >>>explicitly write so. > > >>>" MANET Local Prefix (MLP) - An IP prefix delegated to a > > >>>MANET router, consisting in chunks of IP addresses valid for > > >>>communications inside the MANET. MANET Local Address (MLA) - An IP > > >>> address configured on a MANET interface, and valid for > > >>> communications inside the MANET." > > >>>Actually, I am not clear what is MLA/MLP... The document said > > >>>in section 4.1 "a MANET router needs to configure at least one IP > > >>>address on its MANET interface, this being a link local address, an > > >>> MLA or a global address." > > >>>Does it mean MLA is unique local address?? > > >>>- How can each manet node decide whether it can obtain prefix > > >>>or address on a manet interface? In IPv6, it is simpler that > > >>>every node generates a link-local address on its interface, while > > >>>manet node may not assign a link-local address on manet interface. > > >>>How can this node decide whether it should wait for prefix or > > >>>simply generate a link-local address? > > >>>There is related question. How can a manet node detects whether it > > >>> attaches to manet or not? In IPv6, as soon as an interface becomes > > >>> active, it will start assigning a link-local address. > > >>> However, a manet node may wait this operation until it detects > > characteristics > > >>> of attached network (regular IPv6 or manet)... This is also one of > > >>> issue how a node can deploy both in manet and regular IPv6. > > >>> In addition to this, a manet node may need to detect connected or > > >>> standalone manet when it attaches to a network in order to discover > > >>> ICP?!. > > >>>- Last general question: for the prefix assignment to manet > > >>>(not manet interface), There are two possibility depending on ICP > > >>>availability: topologically correct prefix or non correct prefix. I > > >>>think this is two different things though the goal is same > > >>>assigning prefix to manet. Shall a solution support both scenarios? > > >>>-------------------------------------------------------------------- > > ------------ > > >>> > > >>>Detailed comments > > >>>- In section 4.1.1, it only said " IPv6 Stateless Address > > >>>Autoconfiguration [5] and Neighbor Discovery for IPv6 [3] do not > > >>>account for potential address duplication beyond a single > > >>>multicast-capable link." > > >>>NDP actually does not consider "multi-hop" support at all. I think > > >>> this address duplication is side-effect of no multi-hop > > consideration. > > >>>- Why do you say "p2p link" between border router and ISP edge > > >>>router in figure 1??? > > >>>- In section 4.1.2, it said Fig. 1, even if MR1 would be able > > >>>to provision MR3 with prefixes, using DHCP [4], it cannot be > > >>>assumed that MR1 or MR3 will not move and become unable to > > >>>communicate directly. On the other hand, frequent reconfiguration > > >>>may cause IPv6 Stateless Address Autoconfiguration [5] to be much > > >>>less efficient than expected, due to large amounts of control > > signalling. > > >>>This paragraph assume running DHCP and AUTOCONF over multihop. > > >>>Do you assume that MR1 is DHCP relay ?? There is no way to forward > > >>> DHCP messages by MR1. The document repeated to say that > > >>> "as-is" existing solution does not fit to manet environment. I > > don't think > > >>> these texts are useful explanation in this document. If you want > > >>>to explain the constraints of existing solutions, you should > > >>>have independent section how DHCP/NDP cannot fit to manet more in > > >>>detail, please. Problem statement document should not suggest or > > >>>assume any solutions. > > >>>- I'm not sure but "broadcast" may be IPv4 term!? > > >>>- Section 4.2.3 When a router changes its ICP affiliation, some > > >>>routes may be broken, affecting MANET packet forwarding performance > > >>> and applications. In a multiple border router / > > >>> multiple-prefixes MANET, frequent reconfiguration could cause a > > >>> large amount of control signalling (for instance if [5] is used). > > >>>Isn't this problem of DHCP? Do you assume that a manet node > > >>>can unicast renew message over connected ICP to the previous ICP > > >>>and continue using the same address?!:-p Or you just mention NDP? > > >>>It is no clear to me what is the intention you refer only NDP here. > > >>>- Section 5, It contains only general considerations. Not > > >>>specific to AUTOCONF solutions. > > >>>- Section 6, if you mention the security issue specific to AUTOCONF > > >>> (Not NDP), you should write in the section 4. You can refer > > >>> the section in the security consideration section. It will be > > >>> nice if you can list up all possible security threats regarding > > >>> AUTOCONF solutions (rather than referring security considerations > > >>> of existing solutions). > > >>> > > >>> > > >>> > > >>>_______________________________________________ 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 > > > > > > > > >______________________________________________________________________ > > >This email has been scanned by the MessageLabs Email Security System. > > >For more information please visit > > >http://www.messagelabs.com/email > > >______________________________________________________________________ > > > > > > > > > > > > > _______________________________________________ > > 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 Mon Dec 03 03:09:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz6N5-0004ab-M9; Mon, 03 Dec 2007 03:09:43 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Iz6N5-0004aV-9v for autoconf-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 03:09:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz6My-0004Yl-GE for autoconf@ietf.org; Mon, 03 Dec 2007 03:09:36 -0500 Received: from mail.globalsuite.net ([69.46.103.200]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iz6Mw-0005Vy-Kp for autoconf@ietf.org; Mon, 03 Dec 2007 03:09:35 -0500 X-AuditID: c0a8013c-ac720bb000001e2e-89-4753b9ac2192 Received: from M90Teco (unknown [207.236.117.226]) by mail.globalsuite.net (Symantec Mail Security) with ESMTP id 3944A4DC007; Mon, 3 Dec 2007 01:09:13 -0700 (MST) From: "Teco Boot" To: "'Shubhranshu'" , References: In-Reply-To: Subject: RE: [Autoconf] Some Thoughts on Problem Statement. Date: Mon, 3 Dec 2007 09:09:01 +0100 Message-ID: <002901c83583$cb347620$619d6260$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acgt7bqHUibjurIUQrOkwzJ3iNnDRwHgwVHw Content-Language: nl X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 3be09dac38eaa50f02d21c7fcee1128c 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 Here some late comments, inline. Some of the comments are made earlier by myself and others. > -----Oorspronkelijk bericht----- > Van: Shubhranshu [mailto:shubranshu@gmail.com] > Verzonden: vrijdag 23 november 2007 17:26 > Aan: autoconf@ietf.org > Onderwerp: [Autoconf] Some Thoughts on Problem Statement. > > All, > > Below are some thoughts that might help us a more focused discussion > and clarify some of the issues. Please send your comments such that > we can further refine / clarify them. > > > > A MANET router needs to configure an IPv6 prefix(es) on its host > interface I think we are still looking for a term for this interface. We could borrow Ingress Interface from NEMO. Manetarch uses "behind the router" or "non-MANET interfaces(s)". Problem Statement uses "non-MANET interfaces". > and/or an IPv6 address on its loopback interface. Besides, > it needs to configure a /128 (or /32 in case of IPv4) and/or a link > local address on its MANET interface. As mentioned before, I want to keep link-locals. So I would say "and a link-local address on its MANET interface". And I do not see a reason for distinguish prefix length for loopback and MANET interface. Both have the same requirements: the prefix is assigned to a single router. In manetarch, a /64 is used for loopback (is OK, but /128 can be used also) and a /128 is to be used for MANET interface, although it is mentioned that shorter prefix lengths are possible. I think the last paragraph in 5.1 is not correct, a /64 prefix may be used for MANET interface, and the summary /62 may be added in the MANET Routing protocol, instead of a couple of /64 and /128 prefixes. Why not aggregating prefixes at the source? > A MANET router may also > configure a prefix shorter than /128 (or /32) on its MANET interface > provided prefix uniqueness is guaranteed [MANET-Arch I-D]. MANET node > needs to configure "MANET scope" address to communicate among > themselves. "MANET Scope" addresses are currently not specified / > standardized within / outside the IETF. Currently I do not see a reason for defining a new scope. I think ULAs can be used. And "MANET scope" is natural, connectivity is limited by connectivity;-) > > As mentioned above, there are three interfaces under consideration for > address auto-configuration. Further detail related to these address > auto-configuration is provided below: > > 1) Configuration of loopback interface: > > It is possible that a MANET Router does not have any host attached to > its network interface or it has only MANET interface which can be used > for intra-manet communication. In the absence of any "external" host, > MANET router may configure an IPv6 global address on its loopback > interface. The traditional auto configuration procedure such as RFC > 2462, can be used for this purpose provided the MANET router has been > assigned a suitable prefix. As usual, this interface is expected to > send multicast RA/RS messages. However, in this case, these messages > would be limited to the Router's loopback interface only. I think a loopback interface needs MLA and/or global address. Link-local address on a loopback interface is not very useful, nor sending RA/RS messages. I think using loopback interfaces is optional and not really needed. Addresses assigned on MANET Interface(s) or non-MANET Interface(s) can be used for communication within or outside the MANET. > > 2) Configuration of MANET interface: > > MANET Router uses this interface to communicate with other MANET > Routers. I do not see a reason for this limitation. There could be communication with all other nodes, as long as these are reachable and an appropriate address is used. > MANET routing and other MANET specific protocols are expected > to run on this interface. This interface SHOULD be configured with a > link local address and/or a /128 (in case of IPv6) or with /32 (in > case of IPv4) address. I think we are emphasizing using /128 too much. And I suggest sticking on IPv6. > MANET interface may also use smaller prefix > provided the prefix uniqueness is guaranteed. > Configuration of MANET > interface with a link local address and/or a /128 address is > straightforward, as it can use existing mechanisms, except the issue > of address uniqueness test over "multi-hop network". > > The probability of address duplication is quite low if most of the > /128 bits are randomly generated and so a node may skip address > uniqueness test. However, address uniqueness detection / resolution is > a requirement when smaller prefixes are used and also in military & > other critical MANET application scenarios. Mixed usage of "address" and "prefix". I do not see reasoning for different approach "military & other critical MANET application scenarios". Maybe we won't use active uniqueness detection / resolution there because DoS attack vulnerability. > The address uniqueness > detection / resolution should be done across the entire network thus > requiring that the specific broadcast/multicast messages used for this > purpose be propagated "even to MANET Routers that are multi-hop away". > Currently there is no standard specification that addresses this > requirement. This will make the MANET Router vulnerable for DAD DoS attacks from the whole MANET. Passive DAD is no problem. > > 3) Configuration of Host interface: > > MANET router needs an unique prefix(es) such that it can configure the > prefix on its host interface. This prefix may further be subnetted and > used for address configuration of the hosts attached to the MANET > router. What is subnetted? Do hosts need a subnet? I have more comments when I know what was intended. > In this scenario a MANET Router should receive one or more > unique prefix(es). This is further explained below for the scenario > where DHCP server is available (i.e connected MANET) and for the > scenario where there is no server available (i.e. Standalone MANET): Why can't there be a DHCP server be available in a Standalone MANET? > > - Scenario where DHCP server is available. > > In this case the DHCP server could be either co-located or directly > reachable to the MANET Boarder Router. If the server is directly > reachable, as shown in the figure 1 below, then MANET Boarder Router > can use existing DHCP request-reply messages (RFC 3315) between > itself and the DHCP server in order to receive prefix(es). The MANET > Boarder Router can then delegate those prefixes to the MANET routers > connected to it either directly or over multi-hop routes. It should be > noted that the link between the MANET router and its attached host > follows the classic link model and SHOULD use the relevant traditional > protocols for address configuration. This will work with SBI also. > > The above mentioned DHCP request-reply mechanism normally assumes > direct or stable i.e. not a dynamic multi-hop route connectivity > expected between the requesting node and the DHCP server. This works with DHCP Relay also. > MANET > routers dynamically update routes & frequently change neighborhood and > are multi-hop away from the DHCP server e.g. MR3 in Fig 1. These, > however, does not require a complete protocol design but rather puts > some requirements on the existing protocols [e.g. RFC 3633]. Currently > there is no standard to address these requirements or that allows that > MANET nodes should act as a dynamic DHCP relay. Another problem is: which ISP is being used, via which Border Router? In the example of Fig 3, MR3 sends to All_DHCP_Relay_Agents_and_Servers. Then, first hop MNR (configured with Global Address) sends to All_DHCP_Servers or to a DHCP unicast address. Sending to All_DHCP_Servers should work, as long as MANET supports multicast. I do not think this mechanism is optimal. In a dense MANET, there could be an awful lot of All_DHCP_Servers site-local multicasts. Also the large number of relayed unicast messages could be unacceptable. The problems shall be further analyzed. > > ----- > MR1...MR3 > / . > +-------------+ +------------+ | / . > | | p2p | MANET |/ . > | ISP Edge| Link | Border | . > | Router +---------+ Router |\ . > | | | | \ . > +-------------+ +------------+ \----- MR2 > > > Fig 1 (same as fig 1 in draft-ietf-autoconf-statement-02) > > - Scenario where no DHCP server is available. > > By its very nature, MANET environment does not always assume > availability of any pre-configured server. Even in such scenarios a > MANET router needs to configure an unique prefix. Traditionally, > protocols such as RFC 2462 are used for address configuration of nodes > in stateless manner. However, RFC 2462 defines address auto > configuration mechanisms for nodes (host and router) and as such it > does not provide any mechanism for allocating "unique prefix(es)" to > the routers. For example, in Figure 2 below, a MANET Router, say MR3, > may need to receive prefix(es) (which can be further subnetted and > used for address configuration of its attached host nodes) from the > MANET Boarder Router /Access Router. Currently no specification exists > that addresses this requirement. ULAs can be generated very easily. Each MNR gets its own /48, or own /64 to reduce collision probability. Bytheway, MR is Mobile Router, not MANET Router. > > -- MR1...MR3 ....MR5 > / > / . > / . > MR4 . > \ > \ > \ -- MR2 ... > > Fig 2. (same as Fig 2 in draft-ietf-autoconf-statement-02) > > > Mobile and wireless nature of MANET routers result in dynamic network > topology [MANET-Arch ID, RFC 2501] which has the property of changing > neighbor nodes. These MANET properties result in network partitioning > and merger of initially isolated networks. Normally, once an address > is allocated to a node, it continues using it and collaborating to > detect and resolve duplicates in case its address is allocated to any > other node. Since initially isolated MANETs had allocated addresses > independent with each other, there remains probability of more than > one node using same address. Currently there is no specification that > solves problem of MANET "network merger detection" and duplicate > address detection/ resolution resulting due to two / more MANETs > merger. I like to see the analysis of the probability for collisions. > > It is desirable that network partitioning is also detected such that > resources / prefixes that were allocated to the outgoing nodes could > be re-used. Currently there is no specification to solve the problem > of MANET "network merger detection". Last words: What I am missing here is a reference to PacketBB. In MANET, usage of compressible addresses is highly preferred. Therefore, prefixes need to have a shared prefix (and suffix). Well coordinated prefix delegation is required to arrange this. And we should think of methods for prefix aggregation, for advertisement of a single prefix by a MANET Router. I think we have two Autoconf categories: 1: SLAAC / ULA Only to be used in cases where self-generation of address / prefix generation is required, e.g. option 2 is not applicable. Random addresses and prefixes are unique with very high probability. Address compression is typically not possible. DAD is normally not really needed (to be analyzed). 2: Manual / DHCP / AAA / MIPv6 bootstrap / NEMO MNP delegation / other Used whenever possible, e.g. connectivity to a Delegating Router (RFC3633 terminology) exists. Managed addresses and prefixes should be unique, depending on manual configuration or implemented protocols and platforms. Address compression is possible, depending on (to be analyzed). DAD is normally not really needed (to be analyzed). Teco. > > > _______________________________________________ > 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 Mon Dec 03 03:35:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz6mK-0004ej-8Z; Mon, 03 Dec 2007 03:35:48 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Iz6mI-0004RG-HB for autoconf-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 03:35:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz6mI-0004OU-5V for autoconf@ietf.org; Mon, 03 Dec 2007 03:35:46 -0500 Received: from mail.globalsuite.net ([69.46.103.200]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iz6mG-0007CJ-7r for autoconf@ietf.org; Mon, 03 Dec 2007 03:35:45 -0500 X-AuditID: c0a8013c-adf23bb000001e2e-63-4753bfcd1a56 Received: from M90Teco (unknown [207.236.117.226]) by mail.globalsuite.net (Symantec Mail Security) with ESMTP id 3BCCB4DC002; Mon, 3 Dec 2007 01:35:22 -0700 (MST) From: "Teco Boot" To: "'mase'" , "'Alexandru Petrescu'" References: <7.0.0.16.2.20071202181233.04971348@ie.niigata-u.ac.jp> <475323CF.4080604@gmail.com> <7.0.0.16.2.20071203115230.04bda790@ie.niigata-u.ac.jp> <002301c8355e$639a3e70$2acebb50$@nl> <7.0.0.16.2.20071203125837.049dbf18@ie.niigata-u.ac.jp> In-Reply-To: <7.0.0.16.2.20071203125837.049dbf18@ie.niigata-u.ac.jp> Subject: RE: [Autoconf] comments to autoconf PS Date: Mon, 3 Dec 2007 09:35:06 +0100 Message-ID: <003001c83587$72dc33b0$58949b10$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg1YbLsmVKmCiD9SbCVqRQzKbnb/wAIqpKQ Content-Language: nl X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a630332fa112280ecc4c4186b5c9ea83 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 Comments inline. > -----Oorspronkelijk bericht----- > Van: mase [mailto:mase@ie.niigata-u.ac.jp] > Verzonden: maandag 3 december 2007 5:05 > Aan: Teco Boot; 'Alexandru Petrescu' > CC: autoconf@ietf.org > Onderwerp: RE: [Autoconf] comments to autoconf PS > > Teco, > > Thank you for your comments. See in line. > > At 12:41 07/12/03, Teco Boot wrote: > >Alex, Kenichi, > > > >I want to share my thoughts on link-local addresses and MLA with you. > >I think link-locals are essential to IPv6. I do not understand why we > have a > >discussion on this. It is to be used for single hop communication, > which is > >also very applicable in MANET. > > Yes, but your former neighbor may be now out-of-transmission range > and only communicated over multi-hop. > Do you prefer to change your source/destination address from a > link-local address to MLA? No. I prefer using Global Address over MLA over link-local address. With Global Addresses, inner-MANET communication is to be used whenever possible (there is a weak link problem, for this discussion: out-of-scope). In case of partitioning, communication can continue if NEMO (or equivalent) is used and both partitions are still part of the Internet (or connected to Internet, this is a definition question). Maybe we need some interaction between MANET routing and NEMO, but in principle, this should work. If traffic is bound to single-hop, link-local addresses shall be used and connectivity is broken when getting out of transmission range. Teco. > > >I think MLA's are to be used for multi hop communications in the > MANET. > > Right. > > >I agree ULA is an obvious candidate for MLA. > > Thanks, > Kenichi > > > >Teco. > > > > > -----Oorspronkelijk bericht----- > > > Van: mase [mailto:mase@ie.niigata-u.ac.jp] > > > Verzonden: maandag 3 december 2007 4:19 > > > Aan: Alexandru Petrescu > > > CC: autoconf@ietf.org > > > Onderwerp: Re: [Autoconf] comments to autoconf PS > > > > > > Hi, Alex, > > > > > > At 06:29 07/12/03, Alexandru Petrescu wrote: > > > >Hi mase, I have some opinions compared to your opinions, just some > > > >discussion. I mainly agree with your suggestions to define > addresses. > > > > > > Thanks. > > > > > > > > > >mase wrote: > > > >>Dear Ryuji, > > > >>Thank you for your good comments. I agree that it is very > > > >>important to make clear the scope when discussing > autoconfiguration. > > > >>With regard to the definition of MANET-local address, I am also > > > >>not satisfied with the current definition. My proposal is as > > > >>follows: MANET-local address an address having MANET-only scope > > > >>that can be used to reach destinations in the MANET. All MANET > > > >>interfaces have a MANET-local unicast address. > > > > > > > >But looks as it is a recursive definition? > > > > > > I have a suggestion of this style from the definition of link-local > > > address of RFC4862. > > > > > > > > > >When you say 'reach' do you mean the packet can be forwarded by a > > > >intermediary router? > > > > > > Right. > > > > > > >Or is it that the packet is reaching the > > > >destination without being forwarded by any router? > > > > > > > >Otherwise all packets have to reach their destinations. > > > > > > > >I'm tempted to define like this: > > > > > > > > MANET-local address > > > > > > > > An IPv6 link-local address. > > > > > > IMHO, this is not reasonalbe because forwarding is necessary to > > > deliver packets to the destination, when source and destinatio > > > MANET routers are not neighbors to each other. > > > > > > > > > >This has pretty good semantics in my understanding. Opinions? > > > > > > > >>What is MANET is given in the manetarch document, so I think that > the > > > >> above definition is clear. In reality, I think that we may use > > > >> unique local IPv6 unicast address for MANET-local address. > > > > > > > >I think ULA (Unique Local Addresses) don't have a scope related to > the > > > >link. I think a ULA addressed packet can reach a destination in a > > > MANET > > > >and sometimes it has to be forwarded to achieve that goal. > > > > > > > >You seem to say: > > > > > > > > MANET-local address > > > > > > > > A Unique Local Address (ULA RFCxxxx) > > > > > > > >If so, then I agree with you. > > > > > > I think that unique local address is a good candidate to be used in > the > > > MANET. > > > > > > > > > >>I think that we cannot depend on link-local address, since MANET > > > >>interface is SBI. > > > > > > > >I think it is strange to assume that a MANET uses _only_ SBI > > > interfaces. > > > > I think I can build a MANET that does _not_ use SBI interfaces. > In > > > >such a case I think IPv6 link-local addresses can be useful. > > > > > > As mentioned above, packet forwarding is necessary in general in a > > > MANET. Thus link-local address is not appropriate as the > > > source/destination address. > > > > > > Kenichi > > > > > > > > > >Alex > > > > > > > >>In this context, I think that link-local address must not be used > in > > > >>MANET routing messages as well as data forwarding. This is my > > > >>personal opinion at this time and need to discuss with the > > > >>co-authors. Anyway, these points must be clearly described in the > > > >>PS domument, as you suggested. Sorry for the only partial answer > to > > > your > > > >>comments. > > > >>Regards, Kenichi > > > >>At 03:33 07/11/30, RYUJI WAKIKAWA wrote: > > > >>>Hi Emmanuel and all, > > > >>>First of all, i am sorry for my long silence, I needed some time > to > > > >>> recover from MANEMO wars in previous IETFs:-p > > > >>>I finally reviewed this document and have a lot of comments, > though > > > >>> some of my comments may be overlapped with others or already > > > >>> be discussed in ML. > > > >>>To be honest, I am not such comfortable with this document > > > >>>(except for the description of uniqueness issue which is well > > > explained!). > > > >>> There are so many unclear explanation. Let me explain the > > > >>> general comments first and then detail my comments later. > > > >>>- Do you assume DHCP and RA(NDP) as solutions of AUTOCONF? NDP > does > > > >>> not deal with prefix assignment. If you want to assign > > > >>> prefix, stateless approach defined in RFC4862 is impossible, > IMO. > > > >>> A "stateful" mechanism using NDP might be possible if we can > design > > > so. > > > >>>- Scope Issue There is nowhere to discuss which scope of > > > >>>address/prefix should be assigned to which interface. It is > very > > > >>>important to consider the address scope in IPv6. For example, > > > >>>there is no discussion whether manet nodes in a same manet uses > the > > > >>> same scope for MLP/MLA. Can MANET-A having link-local sends > > > >>> packets to MANET-B having only global ? This goes against IPv6 > > > spec. > > > >>>According to manet-arch, each manet node needs to obtain > > > >>>"unique prefix" instead of address for its local network and > also > > > >>>must obtain "unique prefix or address" for manet interface, too. > > > >>>Am I right? For the first prefix, there are two possibility: > > > >>>global prefix or uniquelocal prefix. For the second, five > > > >>>possibility: global prefix, global address, uniquelocal prefix, > > > >>>uniquelocal address, link local address. > > > >>>How can AUTOCONF deal with these scope and differences? I > > > >>>think it's very important to use the same scope specially for > > > >>>MANET interface. You can not send packets from link-local scope > to > > > global > > > >>> scope over link. Other direction is OK. Do we agree on > > > >>> relaxing this scope limitation in manet? > > > >>>Is there any definition that the same scope MUST be used for > > > >>>MLP/MLA? Does the word "valid" below indicate this? It should > > > >>>explicitly write so. > > > >>>" MANET Local Prefix (MLP) - An IP prefix delegated to a > > > >>>MANET router, consisting in chunks of IP addresses valid for > > > >>>communications inside the MANET. MANET Local Address (MLA) - An > IP > > > >>> address configured on a MANET interface, and valid for > > > >>> communications inside the MANET." > > > >>>Actually, I am not clear what is MLA/MLP... The document said > > > >>>in section 4.1 "a MANET router needs to configure at least one > IP > > > >>>address on its MANET interface, this being a link local address, > an > > > >>> MLA or a global address." > > > >>>Does it mean MLA is unique local address?? > > > >>>- How can each manet node decide whether it can obtain prefix > > > >>>or address on a manet interface? In IPv6, it is simpler that > > > >>>every node generates a link-local address on its interface, > while > > > >>>manet node may not assign a link-local address on manet > interface. > > > >>>How can this node decide whether it should wait for prefix or > > > >>>simply generate a link-local address? > > > >>>There is related question. How can a manet node detects whether > it > > > >>> attaches to manet or not? In IPv6, as soon as an interface > becomes > > > >>> active, it will start assigning a link-local address. > > > >>> However, a manet node may wait this operation until it detects > > > characteristics > > > >>> of attached network (regular IPv6 or manet)... This is also > one of > > > >>> issue how a node can deploy both in manet and regular IPv6. > > > >>> In addition to this, a manet node may need to detect connected > or > > > >>> standalone manet when it attaches to a network in order to > discover > > > >>> ICP?!. > > > >>>- Last general question: for the prefix assignment to manet > > > >>>(not manet interface), There are two possibility depending on > ICP > > > >>>availability: topologically correct prefix or non correct > prefix. I > > > >>>think this is two different things though the goal is same > > > >>>assigning prefix to manet. Shall a solution support both > scenarios? > > > >>>---------------------------------------------------------------- > ---- > > > ------------ > > > >>> > > > >>>Detailed comments > > > >>>- In section 4.1.1, it only said " IPv6 Stateless Address > > > >>>Autoconfiguration [5] and Neighbor Discovery for IPv6 [3] do not > > > >>>account for potential address duplication beyond a single > > > >>>multicast-capable link." > > > >>>NDP actually does not consider "multi-hop" support at all. I > think > > > >>> this address duplication is side-effect of no multi-hop > > > consideration. > > > >>>- Why do you say "p2p link" between border router and ISP edge > > > >>>router in figure 1??? > > > >>>- In section 4.1.2, it said Fig. 1, even if MR1 would be able > > > >>>to provision MR3 with prefixes, using DHCP [4], it cannot be > > > >>>assumed that MR1 or MR3 will not move and become unable to > > > >>>communicate directly. On the other hand, frequent > reconfiguration > > > >>>may cause IPv6 Stateless Address Autoconfiguration [5] to be > much > > > >>>less efficient than expected, due to large amounts of control > > > signalling. > > > >>>This paragraph assume running DHCP and AUTOCONF over multihop. > > > >>>Do you assume that MR1 is DHCP relay ?? There is no way to > forward > > > >>> DHCP messages by MR1. The document repeated to say that > > > >>> "as-is" existing solution does not fit to manet environment. I > > > don't think > > > >>> these texts are useful explanation in this document. If you > want > > > >>>to explain the constraints of existing solutions, you should > > > >>>have independent section how DHCP/NDP cannot fit to manet more > in > > > >>>detail, please. Problem statement document should not suggest > or > > > >>>assume any solutions. > > > >>>- I'm not sure but "broadcast" may be IPv4 term!? > > > >>>- Section 4.2.3 When a router changes its ICP affiliation, some > > > >>>routes may be broken, affecting MANET packet forwarding > performance > > > >>> and applications. In a multiple border router / > > > >>> multiple-prefixes MANET, frequent reconfiguration could cause a > > > >>> large amount of control signalling (for instance if [5] is > used). > > > >>>Isn't this problem of DHCP? Do you assume that a manet node > > > >>>can unicast renew message over connected ICP to the previous ICP > > > >>>and continue using the same address?!:-p Or you just mention > NDP? > > > >>>It is no clear to me what is the intention you refer only NDP > here. > > > >>>- Section 5, It contains only general considerations. Not > > > >>>specific to AUTOCONF solutions. > > > >>>- Section 6, if you mention the security issue specific to > AUTOCONF > > > >>> (Not NDP), you should write in the section 4. You can refer > > > >>> the section in the security consideration section. It will be > > > >>> nice if you can list up all possible security threats regarding > > > >>> AUTOCONF solutions (rather than referring security > considerations > > > >>> of existing solutions). > > > >>> > > > >>> > > > >>> > > > >>>_______________________________________________ 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 > > > > > > > > > > > > >______________________________________________________________________ > > > >This email has been scanned by the MessageLabs Email Security > System. > > > >For more information please visit > > > >http://www.messagelabs.com/email > > > > >______________________________________________________________________ > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > 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 Mon Dec 03 03:51:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz71u-0008Gt-OA; Mon, 03 Dec 2007 03:51:54 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Iz71t-0008Gk-Tb for autoconf-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 03:51:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz71t-0008Gc-Jz for autoconf@ietf.org; Mon, 03 Dec 2007 03:51:53 -0500 Received: from ccmail.cc.niigata-u.ac.jp ([133.35.23.1] helo=mxav01.cc.niigata-u.ac.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iz71p-0007YF-Py for autoconf@ietf.org; Mon, 03 Dec 2007 03:51:53 -0500 Received: from mxav01.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E17B74F5758 for ; Mon, 3 Dec 2007 17:49:11 +0900 (JST) Received: from mxav01.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by mxav01.cc.niigata-u.ac.jp (Postfix) with SMTP id 8D5134F6F4F for ; Mon, 3 Dec 2007 17:49:02 +0900 (JST) Received: (qmail 20662 invoked from network); 3 Dec 2007 17:49:02 +0900 Received: from unknown (HELO chamame.ie.niigata-u.ac.jp) (133.35.169.34) by mxav01.cc.niigata-u.ac.jp with SMTP; 3 Dec 2007 17:49:02 +0900 Received: (qmail 9306 invoked from network); 3 Dec 2007 17:49:01 +0900 Received: from unknown (HELO neccomputer.ie.niigata-u.ac.jp) (133.35.156.66) by chamame.ie.niigata-u.ac.jp with SMTP; 3 Dec 2007 17:49:01 +0900 Message-Id: <7.0.0.16.2.20071203174016.04b66058@ie.niigata-u.ac.jp> X-Mailer: QUALCOMM Windows Eudora Version 7J rev1.0 Date: Mon, 03 Dec 2007 17:49:08 +0900 To: "Teco Boot" , "'Alexandru Petrescu'" From: mase Subject: RE: [Autoconf] comments to autoconf PS In-Reply-To: <003001c83587$72dc33b0$58949b10$@nl> References: <7.0.0.16.2.20071202181233.04971348@ie.niigata-u.ac.jp> <475323CF.4080604@gmail.com> <7.0.0.16.2.20071203115230.04bda790@ie.niigata-u.ac.jp> <002301c8355e$639a3e70$2acebb50$@nl> <7.0.0.16.2.20071203125837.049dbf18@ie.niigata-u.ac.jp> <003001c83587$72dc33b0$58949b10$@nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f0ea5880a0890be2408609376fa519aa 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 Comments in line. At 17:35 07/12/03, Teco Boot wrote: >Comments inline. > > > -----Oorspronkelijk bericht----- > > Van: mase [mailto:mase@ie.niigata-u.ac.jp] > > Verzonden: maandag 3 december 2007 5:05 > > Aan: Teco Boot; 'Alexandru Petrescu' > > CC: autoconf@ietf.org > > Onderwerp: RE: [Autoconf] comments to autoconf PS > > > > Teco, > > > > Thank you for your comments. See in line. > > > > At 12:41 07/12/03, Teco Boot wrote: > > >Alex, Kenichi, > > > > > >I want to share my thoughts on link-local addresses and MLA with you. > > >I think link-locals are essential to IPv6. I do not understand why we > > have a > > >discussion on this. It is to be used for single hop communication, > > which is > > >also very applicable in MANET. > > > > Yes, but your former neighbor may be now out-of-transmission range > > and only communicated over multi-hop. > > Do you prefer to change your source/destination address from a > > link-local address to MLA? > >No. I prefer using Global Address over MLA over link-local address. > >With Global Addresses, inner-MANET communication is to be used whenever >possible (there is a weak link problem, for this discussion: out-of-scope). >In case of partitioning, communication can continue if NEMO (or equivalent) >is used and both partitions are still part of the Internet (or connected to >Internet, this is a definition question). Maybe we need some interaction >between MANET routing and NEMO, but in principle, this should work. Agree, if global address is available. In the stand-alone MANET, MLA should be used. >If traffic is bound to single-hop, link-local addresses shall be used and >connectivity is broken when getting out of transmission range. If we use MLA and MANET routing, connectivity may not be broken even when getting out of transmission range thanks to multihop connectivity. This is the MANET. Kenichi >Teco. > > > > > > >I think MLA's are to be used for multi hop communications in the > > MANET. > > > > Right. > > > > >I agree ULA is an obvious candidate for MLA. > > > > Thanks, > > Kenichi > > > > > > >Teco. > > > > > > > -----Oorspronkelijk bericht----- > > > > Van: mase [mailto:mase@ie.niigata-u.ac.jp] > > > > Verzonden: maandag 3 december 2007 4:19 > > > > Aan: Alexandru Petrescu > > > > CC: autoconf@ietf.org > > > > Onderwerp: Re: [Autoconf] comments to autoconf PS > > > > > > > > Hi, Alex, > > > > > > > > At 06:29 07/12/03, Alexandru Petrescu wrote: > > > > >Hi mase, I have some opinions compared to your opinions, just some > > > > >discussion. I mainly agree with your suggestions to define > > addresses. > > > > > > > > Thanks. > > > > > > > > > > > > >mase wrote: > > > > >>Dear Ryuji, > > > > >>Thank you for your good comments. I agree that it is very > > > > >>important to make clear the scope when discussing > > autoconfiguration. > > > > >>With regard to the definition of MANET-local address, I am also > > > > >>not satisfied with the current definition. My proposal is as > > > > >>follows: MANET-local address an address having MANET-only scope > > > > >>that can be used to reach destinations in the MANET. All MANET > > > > >>interfaces have a MANET-local unicast address. > > > > > > > > > >But looks as it is a recursive definition? > > > > > > > > I have a suggestion of this style from the definition of link-local > > > > address of RFC4862. > > > > > > > > > > > > >When you say 'reach' do you mean the packet can be forwarded by a > > > > >intermediary router? > > > > > > > > Right. > > > > > > > > >Or is it that the packet is reaching the > > > > >destination without being forwarded by any router? > > > > > > > > > >Otherwise all packets have to reach their destinations. > > > > > > > > > >I'm tempted to define like this: > > > > > > > > > > MANET-local address > > > > > > > > > > An IPv6 link-local address. > > > > > > > > IMHO, this is not reasonalbe because forwarding is necessary to > > > > deliver packets to the destination, when source and destinatio > > > > MANET routers are not neighbors to each other. > > > > > > > > > > > > >This has pretty good semantics in my understanding. Opinions? > > > > > > > > > >>What is MANET is given in the manetarch document, so I think that > > the > > > > >> above definition is clear. In reality, I think that we may use > > > > >> unique local IPv6 unicast address for MANET-local address. > > > > > > > > > >I think ULA (Unique Local Addresses) don't have a scope related to > > the > > > > >link. I think a ULA addressed packet can reach a destination in a > > > > MANET > > > > >and sometimes it has to be forwarded to achieve that goal. > > > > > > > > > >You seem to say: > > > > > > > > > > MANET-local address > > > > > > > > > > A Unique Local Address (ULA RFCxxxx) > > > > > > > > > >If so, then I agree with you. > > > > > > > > I think that unique local address is a good candidate to be used in > > the > > > > MANET. > > > > > > > > > > > > >>I think that we cannot depend on link-local address, since MANET > > > > >>interface is SBI. > > > > > > > > > >I think it is strange to assume that a MANET uses _only_ SBI > > > > interfaces. > > > > > I think I can build a MANET that does _not_ use SBI interfaces. > > In > > > > >such a case I think IPv6 link-local addresses can be useful. > > > > > > > > As mentioned above, packet forwarding is necessary in general in a > > > > MANET. Thus link-local address is not appropriate as the > > > > source/destination address. > > > > > > > > Kenichi > > > > > > > > > > > > >Alex > > > > > > > > > >>In this context, I think that link-local address must not be used > > in > > > > >>MANET routing messages as well as data forwarding. This is my > > > > >>personal opinion at this time and need to discuss with the > > > > >>co-authors. Anyway, these points must be clearly described in the > > > > >>PS domument, as you suggested. Sorry for the only partial answer > > to > > > > your > > > > >>comments. > > > > >>Regards, Kenichi > > > > >>At 03:33 07/11/30, RYUJI WAKIKAWA wrote: > > > > >>>Hi Emmanuel and all, > > > > >>>First of all, i am sorry for my long silence, I needed some time > > to > > > > >>> recover from MANEMO wars in previous IETFs:-p > > > > >>>I finally reviewed this document and have a lot of comments, > > though > > > > >>> some of my comments may be overlapped with others or already > > > > >>> be discussed in ML. > > > > >>>To be honest, I am not such comfortable with this document > > > > >>>(except for the description of uniqueness issue which is well > > > > explained!). > > > > >>> There are so many unclear explanation. Let me explain the > > > > >>> general comments first and then detail my comments later. > > > > >>>- Do you assume DHCP and RA(NDP) as solutions of AUTOCONF? NDP > > does > > > > >>> not deal with prefix assignment. If you want to assign > > > > >>> prefix, stateless approach defined in RFC4862 is impossible, > > IMO. > > > > >>> A "stateful" mechanism using NDP might be possible if we can > > design > > > > so. > > > > >>>- Scope Issue There is nowhere to discuss which scope of > > > > >>>address/prefix should be assigned to which interface. It is > > very > > > > >>>important to consider the address scope in IPv6. For example, > > > > >>>there is no discussion whether manet nodes in a same manet uses > > the > > > > >>> same scope for MLP/MLA. Can MANET-A having link-local sends > > > > >>> packets to MANET-B having only global ? This goes against IPv6 > > > > spec. > > > > >>>According to manet-arch, each manet node needs to obtain > > > > >>>"unique prefix" instead of address for its local network and > > also > > > > >>>must obtain "unique prefix or address" for manet interface, too. > > > > >>>Am I right? For the first prefix, there are two possibility: > > > > >>>global prefix or uniquelocal prefix. For the second, five > > > > >>>possibility: global prefix, global address, uniquelocal prefix, > > > > >>>uniquelocal address, link local address. > > > > >>>How can AUTOCONF deal with these scope and differences? I > > > > >>>think it's very important to use the same scope specially for > > > > >>>MANET interface. You can not send packets from link-local scope > > to > > > > global > > > > >>> scope over link. Other direction is OK. Do we agree on > > > > >>> relaxing this scope limitation in manet? > > > > >>>Is there any definition that the same scope MUST be used for > > > > >>>MLP/MLA? Does the word "valid" below indicate this? It should > > > > >>>explicitly write so. > > > > >>>" MANET Local Prefix (MLP) - An IP prefix delegated to a > > > > >>>MANET router, consisting in chunks of IP addresses valid for > > > > >>>communications inside the MANET. MANET Local Address (MLA) - An > > IP > > > > >>> address configured on a MANET interface, and valid for > > > > >>> communications inside the MANET." > > > > >>>Actually, I am not clear what is MLA/MLP... The document said > > > > >>>in section 4.1 "a MANET router needs to configure at least one > > IP > > > > >>>address on its MANET interface, this being a link local address, > > an > > > > >>> MLA or a global address." > > > > >>>Does it mean MLA is unique local address?? > > > > >>>- How can each manet node decide whether it can obtain prefix > > > > >>>or address on a manet interface? In IPv6, it is simpler that > > > > >>>every node generates a link-local address on its interface, > > while > > > > >>>manet node may not assign a link-local address on manet > > interface. > > > > >>>How can this node decide whether it should wait for prefix or > > > > >>>simply generate a link-local address? > > > > >>>There is related question. How can a manet node detects whether > > it > > > > >>> attaches to manet or not? In IPv6, as soon as an interface > > becomes > > > > >>> active, it will start assigning a link-local address. > > > > >>> However, a manet node may wait this operation until it detects > > > > characteristics > > > > >>> of attached network (regular IPv6 or manet)... This is also > > one of > > > > >>> issue how a node can deploy both in manet and regular IPv6. > > > > >>> In addition to this, a manet node may need to detect connected > > or > > > > >>> standalone manet when it attaches to a network in order to > > discover > > > > >>> ICP?!. > > > > >>>- Last general question: for the prefix assignment to manet > > > > >>>(not manet interface), There are two possibility depending on > > ICP > > > > >>>availability: topologically correct prefix or non correct > > prefix. I > > > > >>>think this is two different things though the goal is same > > > > >>>assigning prefix to manet. Shall a solution support both > > scenarios? > > > > >>>---------------------------------------------------------------- > > ---- > > > > ------------ > > > > >>> > > > > >>>Detailed comments > > > > >>>- In section 4.1.1, it only said " IPv6 Stateless Address > > > > >>>Autoconfiguration [5] and Neighbor Discovery for IPv6 [3] do not > > > > >>>account for potential address duplication beyond a single > > > > >>>multicast-capable link." > > > > >>>NDP actually does not consider "multi-hop" support at all. I > > think > > > > >>> this address duplication is side-effect of no multi-hop > > > > consideration. > > > > >>>- Why do you say "p2p link" between border router and ISP edge > > > > >>>router in figure 1??? > > > > >>>- In section 4.1.2, it said Fig. 1, even if MR1 would be able > > > > >>>to provision MR3 with prefixes, using DHCP [4], it cannot be > > > > >>>assumed that MR1 or MR3 will not move and become unable to > > > > >>>communicate directly. On the other hand, frequent > > reconfiguration > > > > >>>may cause IPv6 Stateless Address Autoconfiguration [5] to be > > much > > > > >>>less efficient than expected, due to large amounts of control > > > > signalling. > > > > >>>This paragraph assume running DHCP and AUTOCONF over multihop. > > > > >>>Do you assume that MR1 is DHCP relay ?? There is no way to > > forward > > > > >>> DHCP messages by MR1. The document repeated to say that > > > > >>> "as-is" existing solution does not fit to manet environment. I > > > > don't think > > > > >>> these texts are useful explanation in this document. If you > > want > > > > >>>to explain the constraints of existing solutions, you should > > > > >>>have independent section how DHCP/NDP cannot fit to manet more > > in > > > > >>>detail, please. Problem statement document should not suggest > > or > > > > >>>assume any solutions. > > > > >>>- I'm not sure but "broadcast" may be IPv4 term!? > > > > >>>- Section 4.2.3 When a router changes its ICP affiliation, some > > > > >>>routes may be broken, affecting MANET packet forwarding > > performance > > > > >>> and applications. In a multiple border router / > > > > >>> multiple-prefixes MANET, frequent reconfiguration could cause a > > > > >>> large amount of control signalling (for instance if [5] is > > used). > > > > >>>Isn't this problem of DHCP? Do you assume that a manet node > > > > >>>can unicast renew message over connected ICP to the previous ICP > > > > >>>and continue using the same address?!:-p Or you just mention > > NDP? > > > > >>>It is no clear to me what is the intention you refer only NDP > > here. > > > > >>>- Section 5, It contains only general considerations. Not > > > > >>>specific to AUTOCONF solutions. > > > > >>>- Section 6, if you mention the security issue specific to > > AUTOCONF > > > > >>> (Not NDP), you should write in the section 4. You can refer > > > > >>> the section in the security consideration section. It will be > > > > >>> nice if you can list up all possible security threats regarding > > > > >>> AUTOCONF solutions (rather than referring security > > considerations > > > > >>> of existing solutions). > > > > >>> > > > > >>> > > > > >>> > > > > >>>_______________________________________________ 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 > > > > > > > > > > > > > > > > >______________________________________________________________________ > > > > >This email has been scanned by the MessageLabs Email Security > > System. > > > > >For more information please visit > > > > >http://www.messagelabs.com/email > > > > > > >______________________________________________________________________ > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 Mon Dec 03 12:39:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFGX-0001vI-3p; Mon, 03 Dec 2007 12:39:33 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IzFGV-0001hT-Hq for autoconf-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 12:39:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFGV-0001ec-5W for autoconf@ietf.org; Mon, 03 Dec 2007 12:39:31 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IzFGU-00050e-NI for autoconf@ietf.org; Mon, 03 Dec 2007 12:39:31 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-2.tower-153.messagelabs.com!1196703569!13918315!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 10216 invoked from network); 3 Dec 2007 17:39:29 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-2.tower-153.messagelabs.com with SMTP; 3 Dec 2007 17:39:29 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id lB3HdSih016427; Mon, 3 Dec 2007 10:39:28 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id lB3HdRhs003581; Mon, 3 Dec 2007 11:39:28 -0600 (CST) Received: from [127.0.0.1] ([10.19.242.12]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id lB3HdPfx003560; Mon, 3 Dec 2007 11:39:26 -0600 (CST) Message-ID: <47543F4C.6060808@gmail.com> Date: Mon, 03 Dec 2007 18:39:24 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: mase Subject: Re: [Autoconf] comments to autoconf PS References: <7.0.0.16.2.20071202181233.04971348@ie.niigata-u.ac.jp> <475323CF.4080604@gmail.com> <7.0.0.16.2.20071203115230.04bda790@ie.niigata-u.ac.jp> In-Reply-To: <7.0.0.16.2.20071203115230.04bda790@ie.niigata-u.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071128-0, 28/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 mase wrote: [...] >> When you say 'reach' do you mean the packet can be forwarded by a >> intermediary router? > > Right. In this sense I agree with you. There are links with link-local scope (with link-local addresses) and IP routers between these links. >> Or is it that the packet is reaching the >> destination without being forwarded by any router? >> >> Otherwise all packets have to reach their destinations. >> >> I'm tempted to define like this: >> >> MANET-local address >> >> An IPv6 link-local address. > > IMHO, this is not reasonalbe because forwarding is necessary to deliver > packets to the destination, when source and destinatio MANET routers are > not neighbors to each other. In this sense, I agree. So a MANET-local address (ULA candidate) has a scope larger than the link. >> You seem to say: >> >> MANET-local address >> >> A Unique Local Address (ULA RFCxxxx) >> >> If so, then I agree with you. > > I think that unique local address is a good candidate to be used in the > MANET. I agree it's a good candidate. > As mentioned above, packet forwarding is necessary in general in a > MANET. Thus link-local address is not appropriate as the > source/destination address. right... Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Dec 03 12:47:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFNu-00089S-V7; Mon, 03 Dec 2007 12:47:10 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IzFNt-00088y-My for autoconf-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 12:47:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFNt-000877-BJ for autoconf@ietf.org; Mon, 03 Dec 2007 12:47:09 -0500 Received: from server9.hosting2go.nl ([83.137.192.232]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzFNq-0005uf-TS for autoconf@ietf.org; Mon, 03 Dec 2007 12:47:08 -0500 Received: (qmail 31815 invoked from network); 3 Dec 2007 18:47:02 +0100 Received: from unknown (HELO M90Teco) (130.129.82.92) by server9.hosting2go.nl with SMTP; 3 Dec 2007 18:47:01 +0100 From: "Teco Boot" To: "'mase'" , "'Alexandru Petrescu'" References: <7.0.0.16.2.20071202181233.04971348@ie.niigata-u.ac.jp> <475323CF.4080604@gmail.com> <7.0.0.16.2.20071203115230.04bda790@ie.niigata-u.ac.jp> <002301c8355e$639a3e70$2acebb50$@nl> <7.0.0.16.2.20071203125837.049dbf18@ie.niigata-u.ac.jp> <003001c83587$72dc33b0$58949b10$@nl> <7.0.0.16.2.20071203174016.04b66058@ie.niigata-u.ac.jp> In-Reply-To: <7.0.0.16.2.20071203174016.04b66058@ie.niigata-u.ac.jp> Subject: RE: [Autoconf] comments to autoconf PS Date: Mon, 3 Dec 2007 18:46:25 +0100 Message-ID: <004001c835d4$80effed0$82cffc70$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg1ico/BkrpoNnXRMGjG7VvcAugigASbl3g Content-Language: nl X-Spam-Score: 0.0 (/) X-Scan-Signature: 9aa22b77adc37e7d33e29644e4dc0b33 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 Comments inline. > -----Oorspronkelijk bericht----- > Van: mase [mailto:mase@ie.niigata-u.ac.jp] > Verzonden: maandag 3 december 2007 9:49 > Aan: Teco Boot; 'Alexandru Petrescu' > CC: autoconf@ietf.org > Onderwerp: RE: [Autoconf] comments to autoconf PS > > Comments in line. > > At 17:35 07/12/03, Teco Boot wrote: > >Comments inline. > > > > > -----Oorspronkelijk bericht----- > > > Van: mase [mailto:mase@ie.niigata-u.ac.jp] > > > Verzonden: maandag 3 december 2007 5:05 > > > Aan: Teco Boot; 'Alexandru Petrescu' > > > CC: autoconf@ietf.org > > > Onderwerp: RE: [Autoconf] comments to autoconf PS > > > > > > Teco, > > > > > > Thank you for your comments. See in line. > > > > > > At 12:41 07/12/03, Teco Boot wrote: > > > >Alex, Kenichi, > > > > > > > >I want to share my thoughts on link-local addresses and MLA with > you. > > > >I think link-locals are essential to IPv6. I do not understand why > we > > > have a > > > >discussion on this. It is to be used for single hop communication, > > > which is > > > >also very applicable in MANET. > > > > > > Yes, but your former neighbor may be now out-of-transmission range > > > and only communicated over multi-hop. > > > Do you prefer to change your source/destination address from a > > > link-local address to MLA? > > > >No. I prefer using Global Address over MLA over link-local address. > > > >With Global Addresses, inner-MANET communication is to be used > whenever > >possible (there is a weak link problem, for this discussion: out-of- > scope). > >In case of partitioning, communication can continue if NEMO (or > equivalent) > >is used and both partitions are still part of the Internet (or > connected to > >Internet, this is a definition question). Maybe we need some > interaction > >between MANET routing and NEMO, but in principle, this should work. > > Agree, if global address is available. In the stand-alone MANET, MLA > should be used. I prefer global addresses, when available. A connection using global addresses is maintained in the following scenario: 1) connection setup, in isolated manet, using global addresses 2) manet gets connected 3) mamet gets partitioned, the two parts are both still connected > > >If traffic is bound to single-hop, link-local addresses shall be used > and > >connectivity is broken when getting out of transmission range. > > If we use MLA and MANET routing, connectivity may not be broken even > when getting out of transmission range thanks to multihop > connectivity. This is the MANET. Ok, but only for traffic that is not bound to single-hop. I meant traffic that _is_ bound to single-hop, e.g. routing protocols. Teco. > > Kenichi > > > >Teco. > > > > > > > > > > >I think MLA's are to be used for multi hop communications in the > > > MANET. > > > > > > Right. > > > > > > >I agree ULA is an obvious candidate for MLA. > > > > > > Thanks, > > > Kenichi > > > > > > > > > >Teco. > > > > > > > > > -----Oorspronkelijk bericht----- > > > > > Van: mase [mailto:mase@ie.niigata-u.ac.jp] > > > > > Verzonden: maandag 3 december 2007 4:19 > > > > > Aan: Alexandru Petrescu > > > > > CC: autoconf@ietf.org > > > > > Onderwerp: Re: [Autoconf] comments to autoconf PS > > > > > > > > > > Hi, Alex, > > > > > > > > > > At 06:29 07/12/03, Alexandru Petrescu wrote: > > > > > >Hi mase, I have some opinions compared to your opinions, just > some > > > > > >discussion. I mainly agree with your suggestions to define > > > addresses. > > > > > > > > > > Thanks. > > > > > > > > > > > > > > > >mase wrote: > > > > > >>Dear Ryuji, > > > > > >>Thank you for your good comments. I agree that it is very > > > > > >>important to make clear the scope when discussing > > > autoconfiguration. > > > > > >>With regard to the definition of MANET-local address, I am > also > > > > > >>not satisfied with the current definition. My proposal is as > > > > > >>follows: MANET-local address an address having MANET-only > scope > > > > > >>that can be used to reach destinations in the MANET. All > MANET > > > > > >>interfaces have a MANET-local unicast address. > > > > > > > > > > > >But looks as it is a recursive definition? > > > > > > > > > > I have a suggestion of this style from the definition of link- > local > > > > > address of RFC4862. > > > > > > > > > > > > > > > >When you say 'reach' do you mean the packet can be forwarded > by a > > > > > >intermediary router? > > > > > > > > > > Right. > > > > > > > > > > >Or is it that the packet is reaching the > > > > > >destination without being forwarded by any router? > > > > > > > > > > > >Otherwise all packets have to reach their destinations. > > > > > > > > > > > >I'm tempted to define like this: > > > > > > > > > > > > MANET-local address > > > > > > > > > > > > An IPv6 link-local address. > > > > > > > > > > IMHO, this is not reasonalbe because forwarding is necessary to > > > > > deliver packets to the destination, when source and destinatio > > > > > MANET routers are not neighbors to each other. > > > > > > > > > > > > > > > >This has pretty good semantics in my understanding. Opinions? > > > > > > > > > > > >>What is MANET is given in the manetarch document, so I think > that > > > the > > > > > >> above definition is clear. In reality, I think that we may > use > > > > > >> unique local IPv6 unicast address for MANET-local address. > > > > > > > > > > > >I think ULA (Unique Local Addresses) don't have a scope > related to > > > the > > > > > >link. I think a ULA addressed packet can reach a destination > in a > > > > > MANET > > > > > >and sometimes it has to be forwarded to achieve that goal. > > > > > > > > > > > >You seem to say: > > > > > > > > > > > > MANET-local address > > > > > > > > > > > > A Unique Local Address (ULA RFCxxxx) > > > > > > > > > > > >If so, then I agree with you. > > > > > > > > > > I think that unique local address is a good candidate to be > used in > > > the > > > > > MANET. > > > > > > > > > > > > > > > >>I think that we cannot depend on link-local address, since > MANET > > > > > >>interface is SBI. > > > > > > > > > > > >I think it is strange to assume that a MANET uses _only_ SBI > > > > > interfaces. > > > > > > I think I can build a MANET that does _not_ use SBI > interfaces. > > > In > > > > > >such a case I think IPv6 link-local addresses can be useful. > > > > > > > > > > As mentioned above, packet forwarding is necessary in general > in a > > > > > MANET. Thus link-local address is not appropriate as the > > > > > source/destination address. > > > > > > > > > > Kenichi > > > > > > > > > > > > > > > >Alex > > > > > > > > > > > >>In this context, I think that link-local address must not be > used > > > in > > > > > >>MANET routing messages as well as data forwarding. This is my > > > > > >>personal opinion at this time and need to discuss with the > > > > > >>co-authors. Anyway, these points must be clearly described in > the > > > > > >>PS domument, as you suggested. Sorry for the only partial > answer > > > to > > > > > your > > > > > >>comments. > > > > > >>Regards, Kenichi > > > > > >>At 03:33 07/11/30, RYUJI WAKIKAWA wrote: > > > > > >>>Hi Emmanuel and all, > > > > > >>>First of all, i am sorry for my long silence, I needed some > time > > > to > > > > > >>> recover from MANEMO wars in previous IETFs:-p > > > > > >>>I finally reviewed this document and have a lot of comments, > > > though > > > > > >>> some of my comments may be overlapped with others or > already > > > > > >>> be discussed in ML. > > > > > >>>To be honest, I am not such comfortable with this document > > > > > >>>(except for the description of uniqueness issue which is > well > > > > > explained!). > > > > > >>> There are so many unclear explanation. Let me explain the > > > > > >>> general comments first and then detail my comments later. > > > > > >>>- Do you assume DHCP and RA(NDP) as solutions of AUTOCONF? > NDP > > > does > > > > > >>> not deal with prefix assignment. If you want to assign > > > > > >>> prefix, stateless approach defined in RFC4862 is > impossible, > > > IMO. > > > > > >>> A "stateful" mechanism using NDP might be possible if we > can > > > design > > > > > so. > > > > > >>>- Scope Issue There is nowhere to discuss which scope of > > > > > >>>address/prefix should be assigned to which interface. It is > > > very > > > > > >>>important to consider the address scope in IPv6. For > example, > > > > > >>>there is no discussion whether manet nodes in a same manet > uses > > > the > > > > > >>> same scope for MLP/MLA. Can MANET-A having link-local > sends > > > > > >>> packets to MANET-B having only global ? This goes against > IPv6 > > > > > spec. > > > > > >>>According to manet-arch, each manet node needs to obtain > > > > > >>>"unique prefix" instead of address for its local network and > > > also > > > > > >>>must obtain "unique prefix or address" for manet interface, > too. > > > > > >>>Am I right? For the first prefix, there are two possibility: > > > > > >>>global prefix or uniquelocal prefix. For the second, five > > > > > >>>possibility: global prefix, global address, uniquelocal > prefix, > > > > > >>>uniquelocal address, link local address. > > > > > >>>How can AUTOCONF deal with these scope and differences? I > > > > > >>>think it's very important to use the same scope specially > for > > > > > >>>MANET interface. You can not send packets from link-local > scope > > > to > > > > > global > > > > > >>> scope over link. Other direction is OK. Do we agree on > > > > > >>> relaxing this scope limitation in manet? > > > > > >>>Is there any definition that the same scope MUST be used for > > > > > >>>MLP/MLA? Does the word "valid" below indicate this? It > should > > > > > >>>explicitly write so. > > > > > >>>" MANET Local Prefix (MLP) - An IP prefix delegated to a > > > > > >>>MANET router, consisting in chunks of IP addresses valid for > > > > > >>>communications inside the MANET. MANET Local Address (MLA) > - An > > > IP > > > > > >>> address configured on a MANET interface, and valid for > > > > > >>> communications inside the MANET." > > > > > >>>Actually, I am not clear what is MLA/MLP... The document > said > > > > > >>>in section 4.1 "a MANET router needs to configure at least > one > > > IP > > > > > >>>address on its MANET interface, this being a link local > address, > > > an > > > > > >>> MLA or a global address." > > > > > >>>Does it mean MLA is unique local address?? > > > > > >>>- How can each manet node decide whether it can obtain > prefix > > > > > >>>or address on a manet interface? In IPv6, it is simpler > that > > > > > >>>every node generates a link-local address on its interface, > > > while > > > > > >>>manet node may not assign a link-local address on manet > > > interface. > > > > > >>>How can this node decide whether it should wait for prefix > or > > > > > >>>simply generate a link-local address? > > > > > >>>There is related question. How can a manet node detects > whether > > > it > > > > > >>> attaches to manet or not? In IPv6, as soon as an interface > > > becomes > > > > > >>> active, it will start assigning a link-local address. > > > > > >>> However, a manet node may wait this operation until it > detects > > > > > characteristics > > > > > >>> of attached network (regular IPv6 or manet)... This is > also > > > one of > > > > > >>> issue how a node can deploy both in manet and regular > IPv6. > > > > > >>> In addition to this, a manet node may need to detect > connected > > > or > > > > > >>> standalone manet when it attaches to a network in order to > > > discover > > > > > >>> ICP?!. > > > > > >>>- Last general question: for the prefix assignment to manet > > > > > >>>(not manet interface), There are two possibility depending > on > > > ICP > > > > > >>>availability: topologically correct prefix or non correct > > > prefix. I > > > > > >>>think this is two different things though the goal is same > > > > > >>>assigning prefix to manet. Shall a solution support both > > > scenarios? > > > > > >>>------------------------------------------------------------ > ---- > > > ---- > > > > > ------------ > > > > > >>> > > > > > >>>Detailed comments > > > > > >>>- In section 4.1.1, it only said " IPv6 Stateless Address > > > > > >>>Autoconfiguration [5] and Neighbor Discovery for IPv6 [3] do > not > > > > > >>>account for potential address duplication beyond a single > > > > > >>>multicast-capable link." > > > > > >>>NDP actually does not consider "multi-hop" support at all. > I > > > think > > > > > >>> this address duplication is side-effect of no multi-hop > > > > > consideration. > > > > > >>>- Why do you say "p2p link" between border router and ISP > edge > > > > > >>>router in figure 1??? > > > > > >>>- In section 4.1.2, it said Fig. 1, even if MR1 would be > able > > > > > >>>to provision MR3 with prefixes, using DHCP [4], it cannot be > > > > > >>>assumed that MR1 or MR3 will not move and become unable to > > > > > >>>communicate directly. On the other hand, frequent > > > reconfiguration > > > > > >>>may cause IPv6 Stateless Address Autoconfiguration [5] to be > > > much > > > > > >>>less efficient than expected, due to large amounts of > control > > > > > signalling. > > > > > >>>This paragraph assume running DHCP and AUTOCONF over > multihop. > > > > > >>>Do you assume that MR1 is DHCP relay ?? There is no way to > > > forward > > > > > >>> DHCP messages by MR1. The document repeated to say that > > > > > >>> "as-is" existing solution does not fit to manet > environment. I > > > > > don't think > > > > > >>> these texts are useful explanation in this document. If > you > > > want > > > > > >>>to explain the constraints of existing solutions, you should > > > > > >>>have independent section how DHCP/NDP cannot fit to manet > more > > > in > > > > > >>>detail, please. Problem statement document should not > suggest > > > or > > > > > >>>assume any solutions. > > > > > >>>- I'm not sure but "broadcast" may be IPv4 term!? > > > > > >>>- Section 4.2.3 When a router changes its ICP affiliation, > some > > > > > >>>routes may be broken, affecting MANET packet forwarding > > > performance > > > > > >>> and applications. In a multiple border router / > > > > > >>> multiple-prefixes MANET, frequent reconfiguration could > cause a > > > > > >>> large amount of control signalling (for instance if [5] is > > > used). > > > > > >>>Isn't this problem of DHCP? Do you assume that a manet node > > > > > >>>can unicast renew message over connected ICP to the previous > ICP > > > > > >>>and continue using the same address?!:-p Or you just mention > > > NDP? > > > > > >>>It is no clear to me what is the intention you refer only > NDP > > > here. > > > > > >>>- Section 5, It contains only general considerations. Not > > > > > >>>specific to AUTOCONF solutions. > > > > > >>>- Section 6, if you mention the security issue specific to > > > AUTOCONF > > > > > >>> (Not NDP), you should write in the section 4. You can > refer > > > > > >>> the section in the security consideration section. It will > be > > > > > >>> nice if you can list up all possible security threats > regarding > > > > > >>> AUTOCONF solutions (rather than referring security > > > considerations > > > > > >>> of existing solutions). > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>>_______________________________________________ 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 > > > > > > > > > > > > > > > > > > > > > >______________________________________________________________________ > > > > > >This email has been scanned by the MessageLabs Email Security > > > System. > > > > > >For more information please visit > > > > > >http://www.messagelabs.com/email > > > > > > > > > >______________________________________________________________________ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 Mon Dec 03 13:05:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFfA-00068o-4S; Mon, 03 Dec 2007 13:05:00 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IzFf3-000646-Ip for autoconf-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 13:04:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFf3-00063p-5e for autoconf@ietf.org; Mon, 03 Dec 2007 13:04:53 -0500 Received: from ug-out-1314.google.com ([66.249.92.174]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzFf1-0007ly-TJ for autoconf@ietf.org; Mon, 03 Dec 2007 13:04:53 -0500 Received: by ug-out-1314.google.com with SMTP id u2so4090055uge for ; Mon, 03 Dec 2007 10:04:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; bh=oqExJ8NYtyMI7m1btq7c3e38yz7Jt2HTQGD7m3OqK9M=; b=w1uvrs+5iBN+2iiBnME1dP7PiHq+QaPgb7IQ0rhdD/YkwrjN4Q2+Wk3Yy3ODeeeH2vToMvQBwEvovvjiD7EyxkC6JFTvTbWi28Yp1vokpRtM+BB8CoRApYdT9ZH4+PQ8lkrz6LP8d6pP4Zjg3du6s1TE0bu6aOfHIKVK4xGiP0Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; b=AcezwwULHtDc5/Etxw6YNGjJ8RHdIIpC/h3vkoipCeXxZB48kqQqMdSp4Ox8yInaHR0AlDTggwr6NtoknDenmb+N9m24osHn+oUg0CGhmpw8DyI5M00E/3AekQiUiRV5rvkn3UMst2m02L0cAjEPQ0RtTWQBLukzt2QyOJmFXcc= Received: by 10.78.129.16 with SMTP id b16mr7740543hud.1196705091044; Mon, 03 Dec 2007 10:04:51 -0800 (PST) Received: from ?130.129.87.241? ( [130.129.87.241]) by mx.google.com with ESMTPS id j9sm17819837mue.2007.12.03.10.04.44 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 03 Dec 2007 10:04:47 -0800 (PST) From: RYUJI WAKIKAWA To: mase In-Reply-To: <7.0.0.16.2.20071202181233.04971348@ie.niigata-u.ac.jp> Subject: Re: [Autoconf] comments to autoconf PS References: <7.0.0.16.2.20071202181233.04971348@ie.niigata-u.ac.jp> Message-Id: <62022ED1-47D5-4704-AC53-01738CD75027@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Mon, 3 Dec 2007 10:04:42 -0800 X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c 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 Mase-san On 2007/12/02, at 1:24, mase wrote: > Dear Ryuji, > > Thank you for your good comments. > I agree that it is very important to make clear the scope when > discussing autoconfiguration. > > With regard to the definition of MANET-local address, I am also not > satisfied with the current definition. My proposal is as follows: > MANET-local address an address having MANET-only scope that can be > used to reach destinations in the MANET. All MANET interfaces have a > MANET-local unicast address. I was asking what is the MANET-local scope? :-) How can you map this manet-local into the current IPv6 scoping? Do you suggest to define new address scope for MANET-local? > What is MANET is given in the manetarch document, so I think that > the above definition is clear. In reality, I think that we may use > unique local IPv6 unicast address for MANET-local address. The use of ULA is fine, but I expect this document help understanding the possible issues when using ULA. And I want to see the reason why you call this as manet-local. What is the difference between ULA and manet-local? This is really confusing... > I think that we cannot depend on link-local address, since MANET > interface is SBI. In this context, I think that link-local address > must not be used in MANET routing messages as well as data > forwarding. This is my personal opinion at this time and need to > discuss with the co-authors. Anyway, these points must be clearly > described in the PS domument, as you suggested. Sorry for the only > partial answer to your comments. ok. regards, ryuji > Regards, > Kenichi > > At 03:33 07/11/30, RYUJI WAKIKAWA wrote: >> Hi Emmanuel and all, >> >> First of all, i am sorry for my long silence, I needed some time to >> recover from MANEMO wars in previous IETFs:-p >> >> I finally reviewed this document and have a lot of comments, though >> some of my comments may be overlapped with others or already be >> discussed in ML. >> >> To be honest, I am not such comfortable with this document >> (except for the description of uniqueness issue which is well >> explained!). >> There are so many unclear explanation. Let me explain the >> general comments first and then detail my comments later. >> >> - Do you assume DHCP and RA(NDP) as solutions of AUTOCONF? >> NDP does not deal with prefix assignment. If you want to assign >> prefix, stateless approach defined in RFC4862 is impossible, IMO. >> A "stateful" mechanism using NDP might be possible if we can design >> so. >> >> - Scope Issue >> There is nowhere to discuss which scope of address/prefix should be >> assigned to which interface. It is very important to consider the >> address scope in IPv6. For example, there is no discussion whether >> manet nodes in a same manet uses the same scope for MLP/MLA. Can >> MANET-A having link-local sends packets to MANET-B having only global >> ? This goes against IPv6 spec. >> >> According to manet-arch, each manet node needs to obtain "unique >> prefix" instead of address for its local network and also must obtain >> "unique prefix or address" for manet interface, too. Am I right? >> For the first prefix, there are two possibility: global prefix or >> uniquelocal prefix. >> For the second, five possibility: global prefix, global address, >> uniquelocal prefix, uniquelocal address, link local address. >> >> How can AUTOCONF deal with these scope and differences? I think it's >> very important to use the same scope specially for MANET interface. >> You can not send packets from link-local scope to global scope over >> link. Other direction is OK. Do we agree on relaxing this scope >> limitation in manet? >> >> Is there any definition that the same scope MUST be used for >> MLP/MLA? >> Does the word "valid" below indicate this? It should explicitly >> write so. >> >> " MANET Local Prefix (MLP) - An IP prefix delegated to a MANET >> router, >> consisting in chunks of IP addresses valid for communications >> inside the MANET. >> MANET Local Address (MLA) - An IP address configured on a MANET >> interface, and valid for communications inside the MANET." >> >> Actually, I am not clear what is MLA/MLP... >> The document said in section 4.1 >> "a MANET router needs to configure at least one IP address on its >> MANET interface, this being a link local address, an MLA or a >> global address." >> >> Does it mean MLA is unique local address?? >> >> - How can each manet node decide whether it can obtain prefix or >> address on a manet interface? In IPv6, it is simpler that every node >> generates a link-local address on its interface, while manet node may >> not assign a link-local address on manet interface. How can this node >> decide whether it should wait for prefix or simply generate a >> link-local address? >> >> There is related question. How can a manet node detects whether it >> attaches to manet or not? In IPv6, as soon as an interface becomes >> active, it will start assigning a link-local address. However, a >> manet >> node may wait this operation until it detects characteristics of >> attached network (regular IPv6 or manet)... This is also one of issue >> how a node can deploy both in manet and regular IPv6. In addition to >> this, a manet node may need to detect connected or standalone manet >> when it attaches to a network in order to discover ICP?!. >> >> - Last general question: for the prefix assignment to manet (not >> manet >> interface), There are two possibility depending on ICP availability: >> topologically correct prefix or non correct prefix. I think this is >> two different things though the goal is same assigning prefix to >> manet. Shall a solution support both scenarios? >> >> -------------------------------------------------------------------------------- >> Detailed comments >> >> - In section 4.1.1, it only said >> " IPv6 Stateless Address Autoconfiguration [5] and Neighbor >> Discovery >> for IPv6 [3] do not account for potential address duplication >> beyond >> a single multicast-capable link." >> >> NDP actually does not consider "multi-hop" support at all. I think >> this address duplication is side-effect of no multi-hop >> consideration. >> >> - Why do you say "p2p link" between border router and ISP edge router >> in figure 1??? >> >> - In section 4.1.2, it said >> Fig. 1, even if MR1 would be able to provision MR3 with prefixes, >> using DHCP [4], it cannot be assumed that MR1 or MR3 will not move >> and become unable to communicate directly. On the other hand, >> frequent reconfiguration may cause IPv6 Stateless Address >> Autoconfiguration [5] to be much less efficient than expected, due >> to >> large amounts of control signalling. >> >> This paragraph assume running DHCP and AUTOCONF over multihop. >> >> Do you assume that MR1 is DHCP relay ?? There is no way to forward >> DHCP messages by MR1. The document repeated to say that "as-is" >> existing solution does not fit to manet environment. I don't think >> these texts are useful explanation in this document. If you want to >> explain the constraints of existing solutions, you should have >> independent section how DHCP/NDP cannot fit to manet more in detail, >> please. Problem statement document should not suggest or assume any >> solutions. >> >> - I'm not sure but "broadcast" may be IPv4 term!? >> >> - Section 4.2.3 >> When a router changes its ICP affiliation, some routes may be >> broken, >> affecting MANET packet forwarding performance and applications. >> In a >> multiple border router / multiple-prefixes MANET, frequent >> reconfiguration could cause a large amount of control signalling >> (for >> instance if [5] is used). >> >> Isn't this problem of DHCP? >> Do you assume that a manet node can unicast renew message over >> connected ICP to the previous ICP and continue using the same >> address?!:-p >> Or you just mention NDP? It is no clear to me what is the intention >> you refer only NDP here. >> >> - Section 5, It contains only general considerations. >> Not specific to AUTOCONF solutions. >> >> - Section 6, if you mention the security issue specific to AUTOCONF >> (Not NDP), you should write in the section 4. You can refer the >> section in the security consideration section. It will be nice if >> you can list up all possible security threats regarding AUTOCONF >> solutions (rather than referring security considerations of existing >> solutions). >> >> >> >> >> >> >> >> _______________________________________________ >> 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 Mon Dec 03 13:10:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFkh-0002Pk-1t; Mon, 03 Dec 2007 13:10:43 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IzFkf-0002PX-Mz for autoconf-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 13:10:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFkf-0002P9-3o for autoconf@ietf.org; Mon, 03 Dec 2007 13:10:41 -0500 Received: from mu-out-0910.google.com ([209.85.134.185]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzFkd-0008JO-II for autoconf@ietf.org; Mon, 03 Dec 2007 13:10:41 -0500 Received: by mu-out-0910.google.com with SMTP id i10so1449087mue for ; Mon, 03 Dec 2007 10:10:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; bh=+JJeIe0M/9Q3C7Cc0K/CsHYQ3U2dluplrtkUaB5BRhU=; b=BYVvtKTNH2b0VrGpNl9QVV5Em9Ai5vWxGUYH9mTVGMkF9clf/jhFNJsxJPTmPCD0t7H/qOYFwrkaq2okpyojf0ZqF2DWEs9mvm55MUcNocmzD5Lq8pxgHiUmvlPr7EoA1Q8Y4Q2M8f72gMxpdrL5HlCOQcVlimic6gmIC0MSILY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; b=ZqPsZ8PtR6+hjxqjmZxQasBHC0yrRYOgNNanQekoaW8JI4lihRv35YVkZhXUoaeieFZTad4ZmQZLzfEbLnkWkl+9+YEd5hnyPmCVczthm4A0xkMcn8/MFX3ev9Mvt4zWHliIay405Hqoz+nqp6SNYCSkD4s1qHhpSRquCHM4Juw= Received: by 10.82.140.20 with SMTP id n20mr11912488bud.1196705436421; Mon, 03 Dec 2007 10:10:36 -0800 (PST) Received: from ?130.129.87.241? ( [130.129.87.241]) by mx.google.com with ESMTPS id q9sm4605420gve.2007.12.03.10.10.31 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 03 Dec 2007 10:10:34 -0800 (PST) From: RYUJI WAKIKAWA To: mase In-Reply-To: <7.0.0.16.2.20071203125837.049dbf18@ie.niigata-u.ac.jp> Subject: Re: [Autoconf] comments to autoconf PS References: <7.0.0.16.2.20071202181233.04971348@ie.niigata-u.ac.jp> <475323CF.4080604@gmail.com> <7.0.0.16.2.20071203115230.04bda790@ie.niigata-u.ac.jp> <002301c8355e$639a3e70$2acebb50$@nl> <7.0.0.16.2.20071203125837.049dbf18@ie.niigata-u.ac.jp> Message-Id: <9CDEB610-8E7E-47F9-BB02-AD714E8D0CB7@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Mon, 3 Dec 2007 10:10:29 -0800 X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 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 On 2007/12/02, at 20:04, mase wrote: > Teco, > > Thank you for your comments. See in line. > > At 12:41 07/12/03, Teco Boot wrote: >> Alex, Kenichi, >> >> I want to share my thoughts on link-local addresses and MLA with you. >> I think link-locals are essential to IPv6. I do not understand why >> we have a >> discussion on this. It is to be used for single hop communication, >> which is >> also very applicable in MANET. > > Yes, but your former neighbor may be now out-of-transmission range > and only communicated over multi-hop. > Do you prefer to change your source/destination address from a link- > local address to MLA? The link-lcoal is still useful for any traffic transmitted only to 1- hop neighbor like NS/NA. ryuji >> I think MLA's are to be used for multi hop communications in the >> MANET. > > Right. > >> I agree ULA is an obvious candidate for MLA. > > Thanks, > Kenichi > > >> Teco. >> >> > -----Oorspronkelijk bericht----- >> > Van: mase [mailto:mase@ie.niigata-u.ac.jp] >> > Verzonden: maandag 3 december 2007 4:19 >> > Aan: Alexandru Petrescu >> > CC: autoconf@ietf.org >> > Onderwerp: Re: [Autoconf] comments to autoconf PS >> > >> > Hi, Alex, >> > >> > At 06:29 07/12/03, Alexandru Petrescu wrote: >> > >Hi mase, I have some opinions compared to your opinions, just some >> > >discussion. I mainly agree with your suggestions to define >> addresses. >> > >> > Thanks. >> > >> > >> > >mase wrote: >> > >>Dear Ryuji, >> > >>Thank you for your good comments. I agree that it is very >> > >>important to make clear the scope when discussing >> autoconfiguration. >> > >>With regard to the definition of MANET-local address, I am also >> > >>not satisfied with the current definition. My proposal is as >> > >>follows: MANET-local address an address having MANET-only scope >> > >>that can be used to reach destinations in the MANET. All MANET >> > >>interfaces have a MANET-local unicast address. >> > > >> > >But looks as it is a recursive definition? >> > >> > I have a suggestion of this style from the definition of link-local >> > address of RFC4862. >> > >> > >> > >When you say 'reach' do you mean the packet can be forwarded by a >> > >intermediary router? >> > >> > Right. >> > >> > >Or is it that the packet is reaching the >> > >destination without being forwarded by any router? >> > > >> > >Otherwise all packets have to reach their destinations. >> > > >> > >I'm tempted to define like this: >> > > >> > > MANET-local address >> > > >> > > An IPv6 link-local address. >> > >> > IMHO, this is not reasonalbe because forwarding is necessary to >> > deliver packets to the destination, when source and destinatio >> > MANET routers are not neighbors to each other. >> > >> > >> > >This has pretty good semantics in my understanding. Opinions? >> > > >> > >>What is MANET is given in the manetarch document, so I think >> that the >> > >> above definition is clear. In reality, I think that we may use >> > >> unique local IPv6 unicast address for MANET-local address. >> > > >> > >I think ULA (Unique Local Addresses) don't have a scope related >> to the >> > >link. I think a ULA addressed packet can reach a destination in a >> > MANET >> > >and sometimes it has to be forwarded to achieve that goal. >> > > >> > >You seem to say: >> > > >> > > MANET-local address >> > > >> > > A Unique Local Address (ULA RFCxxxx) >> > > >> > >If so, then I agree with you. >> > >> > I think that unique local address is a good candidate to be used >> in the >> > MANET. >> > >> > >> > >>I think that we cannot depend on link-local address, since MANET >> > >>interface is SBI. >> > > >> > >I think it is strange to assume that a MANET uses _only_ SBI >> > interfaces. >> > > I think I can build a MANET that does _not_ use SBI >> interfaces. In >> > >such a case I think IPv6 link-local addresses can be useful. >> > >> > As mentioned above, packet forwarding is necessary in general in a >> > MANET. Thus link-local address is not appropriate as the >> > source/destination address. >> > >> > Kenichi >> > >> > >> > >Alex >> > > >> > >>In this context, I think that link-local address must not be >> used in >> > >>MANET routing messages as well as data forwarding. This is my >> > >>personal opinion at this time and need to discuss with the >> > >>co-authors. Anyway, these points must be clearly described in the >> > >>PS domument, as you suggested. Sorry for the only partial >> answer to >> > your >> > >>comments. >> > >>Regards, Kenichi >> > >>At 03:33 07/11/30, RYUJI WAKIKAWA wrote: >> > >>>Hi Emmanuel and all, >> > >>>First of all, i am sorry for my long silence, I needed some >> time to >> > >>> recover from MANEMO wars in previous IETFs:-p >> > >>>I finally reviewed this document and have a lot of comments, >> though >> > >>> some of my comments may be overlapped with others or already >> > >>> be discussed in ML. >> > >>>To be honest, I am not such comfortable with this document >> > >>>(except for the description of uniqueness issue which is well >> > explained!). >> > >>> There are so many unclear explanation. Let me explain the >> > >>> general comments first and then detail my comments later. >> > >>>- Do you assume DHCP and RA(NDP) as solutions of AUTOCONF? NDP >> does >> > >>> not deal with prefix assignment. If you want to assign >> > >>> prefix, stateless approach defined in RFC4862 is impossible, >> IMO. >> > >>> A "stateful" mechanism using NDP might be possible if we can >> design >> > so. >> > >>>- Scope Issue There is nowhere to discuss which scope of >> > >>>address/prefix should be assigned to which interface. It is >> very >> > >>>important to consider the address scope in IPv6. For example, >> > >>>there is no discussion whether manet nodes in a same manet >> uses the >> > >>> same scope for MLP/MLA. Can MANET-A having link-local sends >> > >>> packets to MANET-B having only global ? This goes against IPv6 >> > spec. >> > >>>According to manet-arch, each manet node needs to obtain >> > >>>"unique prefix" instead of address for its local network and >> also >> > >>>must obtain "unique prefix or address" for manet interface, too. >> > >>>Am I right? For the first prefix, there are two possibility: >> > >>>global prefix or uniquelocal prefix. For the second, five >> > >>>possibility: global prefix, global address, uniquelocal prefix, >> > >>>uniquelocal address, link local address. >> > >>>How can AUTOCONF deal with these scope and differences? I >> > >>>think it's very important to use the same scope specially for >> > >>>MANET interface. You can not send packets from link-local >> scope to >> > global >> > >>> scope over link. Other direction is OK. Do we agree on >> > >>> relaxing this scope limitation in manet? >> > >>>Is there any definition that the same scope MUST be used for >> > >>>MLP/MLA? Does the word "valid" below indicate this? It should >> > >>>explicitly write so. >> > >>>" MANET Local Prefix (MLP) - An IP prefix delegated to a >> > >>>MANET router, consisting in chunks of IP addresses valid for >> > >>>communications inside the MANET. MANET Local Address (MLA) - >> An IP >> > >>> address configured on a MANET interface, and valid for >> > >>> communications inside the MANET." >> > >>>Actually, I am not clear what is MLA/MLP... The document said >> > >>>in section 4.1 "a MANET router needs to configure at least one >> IP >> > >>>address on its MANET interface, this being a link local >> address, an >> > >>> MLA or a global address." >> > >>>Does it mean MLA is unique local address?? >> > >>>- How can each manet node decide whether it can obtain prefix >> > >>>or address on a manet interface? In IPv6, it is simpler that >> > >>>every node generates a link-local address on its interface, >> while >> > >>>manet node may not assign a link-local address on manet >> interface. >> > >>>How can this node decide whether it should wait for prefix or >> > >>>simply generate a link-local address? >> > >>>There is related question. How can a manet node detects >> whether it >> > >>> attaches to manet or not? In IPv6, as soon as an interface >> becomes >> > >>> active, it will start assigning a link-local address. >> > >>> However, a manet node may wait this operation until it detects >> > characteristics >> > >>> of attached network (regular IPv6 or manet)... This is also >> one of >> > >>> issue how a node can deploy both in manet and regular IPv6. >> > >>> In addition to this, a manet node may need to detect >> connected or >> > >>> standalone manet when it attaches to a network in order to >> discover >> > >>> ICP?!. >> > >>>- Last general question: for the prefix assignment to manet >> > >>>(not manet interface), There are two possibility depending on >> ICP >> > >>>availability: topologically correct prefix or non correct >> prefix. I >> > >>>think this is two different things though the goal is same >> > >>>assigning prefix to manet. Shall a solution support both >> scenarios? >> > >> > >> > >> >-------------------------------------------------------------------- >> > ------------ >> > >>> >> > >>>Detailed comments >> > >>>- In section 4.1.1, it only said " IPv6 Stateless Address >> > >>>Autoconfiguration [5] and Neighbor Discovery for IPv6 [3] do not >> > >>>account for potential address duplication beyond a single >> > >>>multicast-capable link." >> > >>>NDP actually does not consider "multi-hop" support at all. I >> think >> > >>> this address duplication is side-effect of no multi-hop >> > consideration. >> > >>>- Why do you say "p2p link" between border router and ISP edge >> > >>>router in figure 1??? >> > >>>- In section 4.1.2, it said Fig. 1, even if MR1 would be able >> > >>>to provision MR3 with prefixes, using DHCP [4], it cannot be >> > >>>assumed that MR1 or MR3 will not move and become unable to >> > >>>communicate directly. On the other hand, frequent >> reconfiguration >> > >>>may cause IPv6 Stateless Address Autoconfiguration [5] to be >> much >> > >>>less efficient than expected, due to large amounts of control >> > signalling. >> > >>>This paragraph assume running DHCP and AUTOCONF over multihop. >> > >>>Do you assume that MR1 is DHCP relay ?? There is no way to >> forward >> > >>> DHCP messages by MR1. The document repeated to say that >> > >>> "as-is" existing solution does not fit to manet environment. I >> > don't think >> > >>> these texts are useful explanation in this document. If you >> want >> > >>>to explain the constraints of existing solutions, you should >> > >>>have independent section how DHCP/NDP cannot fit to manet more >> in >> > >>>detail, please. Problem statement document should not suggest >> or >> > >>>assume any solutions. >> > >>>- I'm not sure but "broadcast" may be IPv4 term!? >> > >>>- Section 4.2.3 When a router changes its ICP affiliation, some >> > >>>routes may be broken, affecting MANET packet forwarding >> performance >> > >>> and applications. In a multiple border router / >> > >>> multiple-prefixes MANET, frequent reconfiguration could cause a >> > >>> large amount of control signalling (for instance if [5] is >> used). >> > >>>Isn't this problem of DHCP? Do you assume that a manet node >> > >>>can unicast renew message over connected ICP to the previous ICP >> > >>>and continue using the same address?!:-p Or you just mention >> NDP? >> > >>>It is no clear to me what is the intention you refer only NDP >> here. >> > >>>- Section 5, It contains only general considerations. Not >> > >>>specific to AUTOCONF solutions. >> > >>>- Section 6, if you mention the security issue specific to >> AUTOCONF >> > >>> (Not NDP), you should write in the section 4. You can refer >> > >>> the section in the security consideration section. It will be >> > >>> nice if you can list up all possible security threats regarding >> > >>> AUTOCONF solutions (rather than referring security >> considerations >> > >>> of existing solutions). >> > >>> >> > >>> >> > >>> >> > >>>_______________________________________________ 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 >> > > >> > > >> > >> > >> ______________________________________________________________________ >> > >This email has been scanned by the MessageLabs Email Security >> System. >> > >For more information please visit >> > >http://www.messagelabs.com/email >> > >> > >> ______________________________________________________________________ >> > > >> > >> > >> > >> > >> > _______________________________________________ >> > 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 From autoconf-bounces@ietf.org Mon Dec 03 13:16:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFpp-00081P-Jn; Mon, 03 Dec 2007 13:16:01 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IzFpm-0007zQ-Oa for autoconf-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 13:15:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFpm-0007yg-Dy for autoconf@ietf.org; Mon, 03 Dec 2007 13:15:58 -0500 Received: from py-out-1112.google.com ([64.233.166.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzFpk-0006mO-T3 for autoconf@ietf.org; Mon, 03 Dec 2007 13:15:58 -0500 Received: by py-out-1112.google.com with SMTP id d32so12436305pye for ; Mon, 03 Dec 2007 10:15:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; bh=o2d78p7Fu2FvaMa1F/1tk5Lw356YcKgl0w7ITB7k+xQ=; b=LjEJJkRJ6Ks0ff7x/RYwx4XLOgZM0MZSx1pON5D8cIzXQsQYzUA4ufqbklpA4zB5W+6DO8EclSfS4hP/5SN/DQM8T2otfl00XJu7TZYUaARfIkjn/cFXg6OG3EaUxYMkVI2ooWxuUgNjn9eCVFiutdZRkx5nMCL0n3V91Mb9kfY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; b=o0SX//fTAjE7oKXES+/LjEluP9q69KrkawA3ompDXXu0v2yuchHWvAQBuDTFTCTUUxMgLcrv+FljlIOydMnaIarfRaKGbB2bJmF6x67LimVPviCGd5s/uTjNHkRHPCwoHYA/rG66OkiebxHNeQ9Q2cfJ+QzeLrBp6xznjvrSLYo= Received: by 10.64.149.15 with SMTP id w15mr1233687qbd.1196705754189; Mon, 03 Dec 2007 10:15:54 -0800 (PST) Received: from ?130.129.87.241? ( [130.129.87.241]) by mx.google.com with ESMTPS id e18sm7053691qba.2007.12.03.10.15.51 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 03 Dec 2007 10:15:52 -0800 (PST) From: RYUJI WAKIKAWA To: mase In-Reply-To: <7.0.0.16.2.20071203174016.04b66058@ie.niigata-u.ac.jp> Subject: Re: [Autoconf] comments to autoconf PS References: <7.0.0.16.2.20071202181233.04971348@ie.niigata-u.ac.jp> <475323CF.4080604@gmail.com> <7.0.0.16.2.20071203115230.04bda790@ie.niigata-u.ac.jp> <002301c8355e$639a3e70$2acebb50$@nl> <7.0.0.16.2.20071203125837.049dbf18@ie.niigata-u.ac.jp> <003001c83587$72dc33b0$58949b10$@nl> <7.0.0.16.2.20071203174016.04b66058@ie.niigata-u.ac.jp> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Mon, 3 Dec 2007 10:15:50 -0800 X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: ba9cd4f9acda58dbe142afff7265daff 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 On 2007/12/03, at 0:49, mase wrote: > Comments in line. > > At 17:35 07/12/03, Teco Boot wrote: >> Comments inline. >> >> > -----Oorspronkelijk bericht----- >> > Van: mase [mailto:mase@ie.niigata-u.ac.jp] >> > Verzonden: maandag 3 december 2007 5:05 >> > Aan: Teco Boot; 'Alexandru Petrescu' >> > CC: autoconf@ietf.org >> > Onderwerp: RE: [Autoconf] comments to autoconf PS >> > >> > Teco, >> > >> > Thank you for your comments. See in line. >> > >> > At 12:41 07/12/03, Teco Boot wrote: >> > >Alex, Kenichi, >> > > >> > >I want to share my thoughts on link-local addresses and MLA with >> you. >> > >I think link-locals are essential to IPv6. I do not understand >> why we >> > have a >> > >discussion on this. It is to be used for single hop communication, >> > which is >> > >also very applicable in MANET. >> > >> > Yes, but your former neighbor may be now out-of-transmission range >> > and only communicated over multi-hop. >> > Do you prefer to change your source/destination address from a >> > link-local address to MLA? >> >> No. I prefer using Global Address over MLA over link-local address. >> >> With Global Addresses, inner-MANET communication is to be used >> whenever >> possible (there is a weak link problem, for this discussion: out-of- >> scope). >> In case of partitioning, communication can continue if NEMO (or >> equivalent) >> is used and both partitions are still part of the Internet (or >> connected to >> Internet, this is a definition question). Maybe we need some >> interaction >> between MANET routing and NEMO, but in principle, this should work. > > Agree, if global address is available. Do you say that if global address is available, global address is treated as MLA? I think global address cannot be MLA, since some signaling (ex. DHCP!?) over mult-hop to obtain global address are required. chicken-egg problem !? > In the stand-alone MANET, MLA > should be used. do you mean ULA as MLA? regards, ryuji > >> If traffic is bound to single-hop, link-local addresses shall be >> used and >> connectivity is broken when getting out of transmission range. > > If we use MLA and MANET routing, connectivity may not be broken even > when getting out of transmission range thanks to multihop > connectivity. This is the MANET. > > Kenichi > > >> Teco. >> >> >> > >> > >I think MLA's are to be used for multi hop communications in the >> > MANET. >> > >> > Right. >> > >> > >I agree ULA is an obvious candidate for MLA. >> > >> > Thanks, >> > Kenichi >> > >> > >> > >Teco. >> > > >> > > > -----Oorspronkelijk bericht----- >> > > > Van: mase [mailto:mase@ie.niigata-u.ac.jp] >> > > > Verzonden: maandag 3 december 2007 4:19 >> > > > Aan: Alexandru Petrescu >> > > > CC: autoconf@ietf.org >> > > > Onderwerp: Re: [Autoconf] comments to autoconf PS >> > > > >> > > > Hi, Alex, >> > > > >> > > > At 06:29 07/12/03, Alexandru Petrescu wrote: >> > > > >Hi mase, I have some opinions compared to your opinions, >> just some >> > > > >discussion. I mainly agree with your suggestions to define >> > addresses. >> > > > >> > > > Thanks. >> > > > >> > > > >> > > > >mase wrote: >> > > > >>Dear Ryuji, >> > > > >>Thank you for your good comments. I agree that it is very >> > > > >>important to make clear the scope when discussing >> > autoconfiguration. >> > > > >>With regard to the definition of MANET-local address, I am >> also >> > > > >>not satisfied with the current definition. My proposal is as >> > > > >>follows: MANET-local address an address having MANET-only >> scope >> > > > >>that can be used to reach destinations in the MANET. All >> MANET >> > > > >>interfaces have a MANET-local unicast address. >> > > > > >> > > > >But looks as it is a recursive definition? >> > > > >> > > > I have a suggestion of this style from the definition of link- >> local >> > > > address of RFC4862. >> > > > >> > > > >> > > > >When you say 'reach' do you mean the packet can be forwarded >> by a >> > > > >intermediary router? >> > > > >> > > > Right. >> > > > >> > > > >Or is it that the packet is reaching the >> > > > >destination without being forwarded by any router? >> > > > > >> > > > >Otherwise all packets have to reach their destinations. >> > > > > >> > > > >I'm tempted to define like this: >> > > > > >> > > > > MANET-local address >> > > > > >> > > > > An IPv6 link-local address. >> > > > >> > > > IMHO, this is not reasonalbe because forwarding is necessary to >> > > > deliver packets to the destination, when source and destinatio >> > > > MANET routers are not neighbors to each other. >> > > > >> > > > >> > > > >This has pretty good semantics in my understanding. Opinions? >> > > > > >> > > > >>What is MANET is given in the manetarch document, so I >> think that >> > the >> > > > >> above definition is clear. In reality, I think that we >> may use >> > > > >> unique local IPv6 unicast address for MANET-local address. >> > > > > >> > > > >I think ULA (Unique Local Addresses) don't have a scope >> related to >> > the >> > > > >link. I think a ULA addressed packet can reach a >> destination in a >> > > > MANET >> > > > >and sometimes it has to be forwarded to achieve that goal. >> > > > > >> > > > >You seem to say: >> > > > > >> > > > > MANET-local address >> > > > > >> > > > > A Unique Local Address (ULA RFCxxxx) >> > > > > >> > > > >If so, then I agree with you. >> > > > >> > > > I think that unique local address is a good candidate to be >> used in >> > the >> > > > MANET. >> > > > >> > > > >> > > > >>I think that we cannot depend on link-local address, since >> MANET >> > > > >>interface is SBI. >> > > > > >> > > > >I think it is strange to assume that a MANET uses _only_ SBI >> > > > interfaces. >> > > > > I think I can build a MANET that does _not_ use SBI >> interfaces. >> > In >> > > > >such a case I think IPv6 link-local addresses can be useful. >> > > > >> > > > As mentioned above, packet forwarding is necessary in general >> in a >> > > > MANET. Thus link-local address is not appropriate as the >> > > > source/destination address. >> > > > >> > > > Kenichi >> > > > >> > > > >> > > > >Alex >> > > > > >> > > > >>In this context, I think that link-local address must not >> be used >> > in >> > > > >>MANET routing messages as well as data forwarding. This is my >> > > > >>personal opinion at this time and need to discuss with the >> > > > >>co-authors. Anyway, these points must be clearly described >> in the >> > > > >>PS domument, as you suggested. Sorry for the only partial >> answer >> > to >> > > > your >> > > > >>comments. >> > > > >>Regards, Kenichi >> > > > >>At 03:33 07/11/30, RYUJI WAKIKAWA wrote: >> > > > >>>Hi Emmanuel and all, >> > > > >>>First of all, i am sorry for my long silence, I needed >> some time >> > to >> > > > >>> recover from MANEMO wars in previous IETFs:-p >> > > > >>>I finally reviewed this document and have a lot of comments, >> > though >> > > > >>> some of my comments may be overlapped with others or >> already >> > > > >>> be discussed in ML. >> > > > >>>To be honest, I am not such comfortable with this document >> > > > >>>(except for the description of uniqueness issue which is >> well >> > > > explained!). >> > > > >>> There are so many unclear explanation. Let me explain the >> > > > >>> general comments first and then detail my comments later. >> > > > >>>- Do you assume DHCP and RA(NDP) as solutions of AUTOCONF? >> NDP >> > does >> > > > >>> not deal with prefix assignment. If you want to assign >> > > > >>> prefix, stateless approach defined in RFC4862 is >> impossible, >> > IMO. >> > > > >>> A "stateful" mechanism using NDP might be possible if we >> can >> > design >> > > > so. >> > > > >>>- Scope Issue There is nowhere to discuss which scope of >> > > > >>>address/prefix should be assigned to which interface. It is >> > very >> > > > >>>important to consider the address scope in IPv6. For >> example, >> > > > >>>there is no discussion whether manet nodes in a same manet >> uses >> > the >> > > > >>> same scope for MLP/MLA. Can MANET-A having link-local >> sends >> > > > >>> packets to MANET-B having only global ? This goes against >> IPv6 >> > > > spec. >> > > > >>>According to manet-arch, each manet node needs to obtain >> > > > >>>"unique prefix" instead of address for its local network and >> > also >> > > > >>>must obtain "unique prefix or address" for manet >> interface, too. >> > > > >>>Am I right? For the first prefix, there are two possibility: >> > > > >>>global prefix or uniquelocal prefix. For the second, five >> > > > >>>possibility: global prefix, global address, uniquelocal >> prefix, >> > > > >>>uniquelocal address, link local address. >> > > > >>>How can AUTOCONF deal with these scope and differences? I >> > > > >>>think it's very important to use the same scope specially >> for >> > > > >>>MANET interface. You can not send packets from link-local >> scope >> > to >> > > > global >> > > > >>> scope over link. Other direction is OK. Do we agree on >> > > > >>> relaxing this scope limitation in manet? >> > > > >>>Is there any definition that the same scope MUST be used for >> > > > >>>MLP/MLA? Does the word "valid" below indicate this? It >> should >> > > > >>>explicitly write so. >> > > > >>>" MANET Local Prefix (MLP) - An IP prefix delegated to a >> > > > >>>MANET router, consisting in chunks of IP addresses valid for >> > > > >>>communications inside the MANET. MANET Local Address >> (MLA) - An >> > IP >> > > > >>> address configured on a MANET interface, and valid for >> > > > >>> communications inside the MANET." >> > > > >>>Actually, I am not clear what is MLA/MLP... The document >> said >> > > > >>>in section 4.1 "a MANET router needs to configure at least >> one >> > IP >> > > > >>>address on its MANET interface, this being a link local >> address, >> > an >> > > > >>> MLA or a global address." >> > > > >>>Does it mean MLA is unique local address?? >> > > > >>>- How can each manet node decide whether it can obtain >> prefix >> > > > >>>or address on a manet interface? In IPv6, it is simpler >> that >> > > > >>>every node generates a link-local address on its interface, >> > while >> > > > >>>manet node may not assign a link-local address on manet >> > interface. >> > > > >>>How can this node decide whether it should wait for prefix >> or >> > > > >>>simply generate a link-local address? >> > > > >>>There is related question. How can a manet node detects >> whether >> > it >> > > > >>> attaches to manet or not? In IPv6, as soon as an interface >> > becomes >> > > > >>> active, it will start assigning a link-local address. >> > > > >>> However, a manet node may wait this operation until it >> detects >> > > > characteristics >> > > > >>> of attached network (regular IPv6 or manet)... This is >> also >> > one of >> > > > >>> issue how a node can deploy both in manet and regular >> IPv6. >> > > > >>> In addition to this, a manet node may need to detect >> connected >> > or >> > > > >>> standalone manet when it attaches to a network in order to >> > discover >> > > > >>> ICP?!. >> > > > >>>- Last general question: for the prefix assignment to manet >> > > > >>>(not manet interface), There are two possibility depending >> on >> > ICP >> > > > >>>availability: topologically correct prefix or non correct >> > prefix. I >> > > > >>>think this is two different things though the goal is same >> > > > >>>assigning prefix to manet. Shall a solution support both >> > scenarios? >> > > > >> >>>---------------------------------------------------------------- >> > ---- >> > > > ------------ >> > > > >>> >> > > > >>>Detailed comments >> > > > >>>- In section 4.1.1, it only said " IPv6 Stateless Address >> > > > >>>Autoconfiguration [5] and Neighbor Discovery for IPv6 [3] >> do not >> > > > >>>account for potential address duplication beyond a single >> > > > >>>multicast-capable link." >> > > > >>>NDP actually does not consider "multi-hop" support at >> all. I >> > think >> > > > >>> this address duplication is side-effect of no multi-hop >> > > > consideration. >> > > > >>>- Why do you say "p2p link" between border router and ISP >> edge >> > > > >>>router in figure 1??? >> > > > >>>- In section 4.1.2, it said Fig. 1, even if MR1 would be >> able >> > > > >>>to provision MR3 with prefixes, using DHCP [4], it cannot be >> > > > >>>assumed that MR1 or MR3 will not move and become unable to >> > > > >>>communicate directly. On the other hand, frequent >> > reconfiguration >> > > > >>>may cause IPv6 Stateless Address Autoconfiguration [5] to be >> > much >> > > > >>>less efficient than expected, due to large amounts of >> control >> > > > signalling. >> > > > >>>This paragraph assume running DHCP and AUTOCONF over >> multihop. >> > > > >>>Do you assume that MR1 is DHCP relay ?? There is no way to >> > forward >> > > > >>> DHCP messages by MR1. The document repeated to say that >> > > > >>> "as-is" existing solution does not fit to manet >> environment. I >> > > > don't think >> > > > >>> these texts are useful explanation in this document. If >> you >> > want >> > > > >>>to explain the constraints of existing solutions, you should >> > > > >>>have independent section how DHCP/NDP cannot fit to manet >> more >> > in >> > > > >>>detail, please. Problem statement document should not >> suggest >> > or >> > > > >>>assume any solutions. >> > > > >>>- I'm not sure but "broadcast" may be IPv4 term!? >> > > > >>>- Section 4.2.3 When a router changes its ICP affiliation, >> some >> > > > >>>routes may be broken, affecting MANET packet forwarding >> > performance >> > > > >>> and applications. In a multiple border router / >> > > > >>> multiple-prefixes MANET, frequent reconfiguration could >> cause a >> > > > >>> large amount of control signalling (for instance if [5] is >> > used). >> > > > >>>Isn't this problem of DHCP? Do you assume that a manet node >> > > > >>>can unicast renew message over connected ICP to the >> previous ICP >> > > > >>>and continue using the same address?!:-p Or you just mention >> > NDP? >> > > > >>>It is no clear to me what is the intention you refer only >> NDP >> > here. >> > > > >>>- Section 5, It contains only general considerations. Not >> > > > >>>specific to AUTOCONF solutions. >> > > > >>>- Section 6, if you mention the security issue specific to >> > AUTOCONF >> > > > >>> (Not NDP), you should write in the section 4. You can >> refer >> > > > >>> the section in the security consideration section. It >> will be >> > > > >>> nice if you can list up all possible security threats >> regarding >> > > > >>> AUTOCONF solutions (rather than referring security >> > considerations >> > > > >>> of existing solutions). >> > > > >>> >> > > > >>> >> > > > >>> >> > > > >>>_______________________________________________ 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 >> > > > > >> > > > > >> > > > >> > >> > >> ______________________________________________________________________ >> > > > >This email has been scanned by the MessageLabs Email Security >> > System. >> > > > >For more information please visit >> > > > >http://www.messagelabs.com/email >> > > > >> > >> > >> ______________________________________________________________________ >> > > > > >> > > > >> > > > >> > > > >> > > > >> > > > _______________________________________________ >> > > > 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 From autoconf-bounces@ietf.org Mon Dec 03 20:09:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzMI7-0005SY-7M; Mon, 03 Dec 2007 20:09:39 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IzMI6-0005SS-J5 for autoconf-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 20:09:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzMI6-0005SI-8n for autoconf@ietf.org; Mon, 03 Dec 2007 20:09:38 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IzMI5-0000d8-SD for autoconf@ietf.org; Mon, 03 Dec 2007 20:09:38 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-128.messagelabs.com!1196730576!28744000!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 3359 invoked from network); 4 Dec 2007 01:09:36 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-6.tower-128.messagelabs.com with SMTP; 4 Dec 2007 01:09:36 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id lB419SSW019959; Mon, 3 Dec 2007 18:09:28 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id lB419RmV029454; Mon, 3 Dec 2007 19:09:28 -0600 (CST) Received: from [127.0.0.1] ([10.19.252.252]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id lB419PMi029432; Mon, 3 Dec 2007 19:09:26 -0600 (CST) Message-ID: <4754A8C5.8020804@gmail.com> Date: Tue, 04 Dec 2007 02:09:25 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: RYUJI WAKIKAWA Subject: Re: scope of multicast address (was: [Autoconf] comments to autoconf PS) References: <7.0.0.16.2.20071202181233.04971348@ie.niigata-u.ac.jp> <62022ED1-47D5-4704-AC53-01738CD75027@gmail.com> In-Reply-To: <62022ED1-47D5-4704-AC53-01738CD75027@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071203-0, 03/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.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 RYUJI WAKIKAWA wrote: [...] >> With regard to the definition of MANET-local address, I am also not >> satisfied with the current definition. My proposal is as follows: >> MANET-local address an address having MANET-only scope that can be >> used to reach destinations in the MANET. All MANET interfaces have a >> MANET-local unicast address. > > I was asking what is the MANET-local scope? :-) > How can you map this manet-local into the current IPv6 scoping? > Do you suggest to define new address scope for MANET-local? There is this 'LL-MANET-Routers' address FF02:0:0:0:0:0:0:TBD4 defined in draft-ietf-manet-iana-07.txt. This address has link-local scope. A link-local scope is number '2', defined by RFC4291 "IPv6 Addressing Architecture". That RFC defines other scopes as well: 0, 1, 4, 5, 8, E, F. I'm not sure whether people really want/need to define another scope for MANET, not clear to me. My personal opinion is to go with already reserved scopes. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Dec 03 20:21:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzMTr-00057R-Ru; Mon, 03 Dec 2007 20:21:47 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IzMTp-00057C-Oq for autoconf-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 20:21:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzMTp-000573-De for autoconf@ietf.org; Mon, 03 Dec 2007 20:21:45 -0500 Received: from server9.hosting2go.nl ([83.137.192.232]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzMTo-00042I-R3 for autoconf@ietf.org; Mon, 03 Dec 2007 20:21:45 -0500 Received: (qmail 12265 invoked from network); 4 Dec 2007 02:21:43 +0100 Received: from unknown (HELO M90Teco) (130.129.82.92) by server9.hosting2go.nl with SMTP; 4 Dec 2007 02:21:42 +0100 From: "Teco Boot" To: "'Emmanuel Baccelli'" , References: <4742FB0D.40208@gmail.com> <7877C5C0B5CC894AB26113CF06CF88631EA662@ms-dt01thalia.tsn.tno.nl> <4743074E.5060309@gmail.com> <00cf01c82b92$6bd57530$43805f90$@nl> <47430E9F.8010507@gmail.com> <00d801c82b95$57e36160$07aa2420$@nl> <47431810.1010909@gmail.com> <00e701c82b9b$2babbe20$83033a60$@nl> <47432D4D.9000106@gmail.com> <00ef01c82baa$436471b0$ca2d5510$@nl> <4743F7B9.8000907@inria.fr> In-Reply-To: <4743F7B9.8000907@inria.fr> Subject: RE: [Autoconf] Multicast confusion between MANET Arch and AUTOCONF Problem Statement Date: Tue, 4 Dec 2007 02:21:07 +0100 Message-ID: <006d01c83614$064ca030$12e5e090$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgsH3gQYrlUspqsSGKij6x+qA70DgJ7PnIw Content-Language: nl X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 Late response, sorry. > -----Oorspronkelijk bericht----- > Van: Emmanuel Baccelli [mailto:Emmanuel.Baccelli@inria.fr] > Verzonden: woensdag 21 november 2007 10:18 > Aan: autoconf@ietf.org > Onderwerp: Re: [Autoconf] Multicast confusion between MANET Arch and > AUTOCONFProblem Statement >=20 >=20 >=20 > Teco Boot a =E9crit : > > Hi Alex, > > > > I think we agree on that the current PS is focused on "classical > MANET". And > > it misses another ad-hoc network type, e.g. using ad-hoc multihop > > connectivity to the Internet. >=20 >=20 > I do not agree with this judgement. Can you tell me what is the > difference between the connected MANET scenario explicitely described > in > th scope of the PS, and what you mean by"ad hoc multihop connectivity > to > the Internet"? When rereading 3.1 Connected MANET, it is about MANET. This is expected = from the title for that section. But what about this example: - smartphone connected to Internet - laptop connected to smartphone Smartphone and laptop do not run a MANET routing protocol. Classical protocols may be used (or static).=20 There is also not an SBI interface. Only a P2P link is used which is perfectly stable. For the time using this ad hoc setup, smartphone and laptop do not move. I think this is more "ad hoc" and less "MANET". It is terminology. I would use MANET for something that is mobile (or = links to neighbors have varying asymmetric reachability for other reasons) = and runs a MANET protocol. Manetarch: MANET =3D=3D routing domain containing MANET routers MANET router =3D=3D router having one or more MANET interfaces MANET interface =3D=3D interface with potentially significant = time-varying asymmetric reachability (e.g., SBI) Following these definitions, the example topology is strictly spoken not = a MANET. Laptop is host (or router), smartphone is router, but not a MANET router because no interface is SBI or have time-varying asymmetric reachability. To refer to the charter, terms "ad hoc" and "MANET" are used quite = often. Reading RFC2501, the MANET definition is somewhat wider. Here, a MANET = is an autonomous system of mobile nodes. In further explanation, the = time-varying reachability characteristic of wireless links pops up, but not by definition.=20 And I think some layer-2 technologies provides symmetric links only. I do not want to discuss about these definitions a lot.=20 What is important, is do we work on scenarios as described above? Teco.=20 >=20 > Emmanuel >=20 >=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 Mon Dec 03 20:23:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzMVv-000695-NJ; Mon, 03 Dec 2007 20:23:55 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IzMVu-00067m-7w for autoconf-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 20:23:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzMVt-00067c-TL for autoconf@ietf.org; Mon, 03 Dec 2007 20:23:53 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IzMVt-0004Gb-Ix for autoconf@ietf.org; Mon, 03 Dec 2007 20:23:53 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-119.messagelabs.com!1196731252!30621384!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 10546 invoked from network); 4 Dec 2007 01:20:52 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-5.tower-119.messagelabs.com with SMTP; 4 Dec 2007 01:20:52 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id lB41KhWD012216; Mon, 3 Dec 2007 18:20:47 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id lB41Kgo8005118; Mon, 3 Dec 2007 19:20:42 -0600 (CST) Received: from [127.0.0.1] ([10.19.252.252]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id lB41Kc57005071; Mon, 3 Dec 2007 19:20:39 -0600 (CST) Message-ID: <4754AB65.2090800@gmail.com> Date: Tue, 04 Dec 2007 02:20:37 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: mase Subject: Re: movement scenario (was: [Autoconf] comments to autoconf PS) References: <7.0.0.16.2.20071202181233.04971348@ie.niigata-u.ac.jp> <475323CF.4080604@gmail.com> <7.0.0.16.2.20071203115230.04bda790@ie.niigata-u.ac.jp> <002301c8355e$639a3e70$2acebb50$@nl> <7.0.0.16.2.20071203125837.049dbf18@ie.niigata-u.ac.jp> In-Reply-To: <7.0.0.16.2.20071203125837.049dbf18@ie.niigata-u.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071203-0, 03/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 mase wrote: >> I want to share my thoughts on link-local addresses and MLA with >> you. I think link-locals are essential to IPv6. I do not understand >> why we have a discussion on this. It is to be used for single hop >> communication, which is also very applicable in MANET. > > Yes, but your former neighbor may be now out-of-transmission range > and only communicated over multi-hop. Do you prefer to change your > source/destination address from a link-local address to MLA? Ha! That's right... Src/dst address rewriting makes immediately think of NAT :-) I think the case you describe above (former neighbor moves from a link to another) deserves deep analysis. What are the mobility scenarios considered? How do entities move, from where to where? After a node moves from one subnet to another: does it keep its address? Does it keep both its address _and_ its prefix? When it keeps its address - nobody else on the previous link can use that address on that previous link? Despite the apparent complexity of describing this, I think it's not so difficult - as long as two or more people have encountered the same movement scenario. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Dec 03 20:57:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzN2C-00078h-Lo; Mon, 03 Dec 2007 20:57:16 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IzN2C-00078P-14 for autoconf-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 20:57:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzN2B-00078C-NR for autoconf@ietf.org; Mon, 03 Dec 2007 20:57:15 -0500 Received: from an-out-0708.google.com ([209.85.132.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzN2B-0005TC-H7 for autoconf@ietf.org; Mon, 03 Dec 2007 20:57:15 -0500 Received: by an-out-0708.google.com with SMTP id d11so899196and for ; Mon, 03 Dec 2007 17:57:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=VVBL9Sa4niR1ENaGdFmnF5USBMohLMv6L/nBB+XP4Lo=; b=Zu9s3Zcsn137lDntrUWSsvmu75/vzqqkXpyWb9wQBWuTfgec9VAOa/3pQrRBGyYJip7eniFV+1f21PUE78pSRLouSY8BZAg5kk0EhjdM5ZETqFMyGwg0Qjo5Jn14Um8dmOJgtZ0LY9BIkagL51oOdFnVGvOe5vPnZmZQFRVZyrQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=fm2OsE0ueiMQ/YRQ9jTRKkNgrMu8XCGmOhPlZICPIquUyuhgHbthi2hVsL8lEjAph2a7lFWRaOTg1qN35A0fuX8Fd63XMALdcj39jS5saeYlhXLZnDIlDKmjbZZsQ51dvNNL3Ozs3jYK6XRxPVK8YHeDp9fYDY/XgrD7830JsXo= Received: by 10.100.201.16 with SMTP id y16mr139238anf.1196733435266; Mon, 03 Dec 2007 17:57:15 -0800 (PST) Received: by 10.100.229.8 with HTTP; Mon, 3 Dec 2007 17:57:15 -0800 (PST) Message-ID: Date: Tue, 4 Dec 2007 07:27:15 +0530 From: Shubhranshu To: autoconf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [Autoconf] Agenda & Presentation Material 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 Agenda and Presentation slides (except PS slides, which I haven't yet received) are available at https://datatracker.ietf.org/meeting/70/materials.html - Shubhranshu _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Dec 03 22:29:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzOTF-0000tv-SO; Mon, 03 Dec 2007 22:29:17 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IzOTE-0000l8-O5 for autoconf-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 22:29:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzOTE-0000eD-62 for autoconf@ietf.org; Mon, 03 Dec 2007 22:29:16 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IzOTD-0007hP-Nt for autoconf@ietf.org; Mon, 03 Dec 2007 22:29:16 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-153.messagelabs.com!1196738954!18054784!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 15140 invoked from network); 4 Dec 2007 03:29:14 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-153.messagelabs.com with SMTP; 4 Dec 2007 03:29:14 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lB43TEvI019106 for ; Mon, 3 Dec 2007 20:29:14 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id lB43TEMs029692 for ; Mon, 3 Dec 2007 21:29:14 -0600 (CST) Received: from [127.0.0.1] (mvp-10-19-254-132.corp.mot.com [10.19.254.132]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id lB43TDAT029678 for ; Mon, 3 Dec 2007 21:29:13 -0600 (CST) Message-ID: <4754C98A.5000707@gmail.com> Date: Tue, 04 Dec 2007 04:29:14 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: autoconf@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071203-0, 03/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Autoconf] Per request of scenarios 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 During the AUTOCONF WG meeting I asked whether we consider including 1 or more more precise scenarios of mobility in the Problem Statement discussion. I meant to say how do the mobiles move, how are they structured. I'm suggesting discussing with figures as support. One possible figure is the following (extracted from an expired draft of MANEMO): Vehicle 1 Vehicle 2 egress| egress| ---- ---- ---- ---- ---- ---- | MR | |LFN | |LFN | | MR | |LFN | |LFN | ---- ---- ---- ---- ---- ---- ingress| | Ether | ingress| | Ether | --------------------- --------------------- 2001:1::/24 2001:2::/24 The two vehicles connect their egress interfaces; the LFNs (Local Fixed Node) don't move with respect to their respective MR (Mobile Router). The vehicles move independently, and at one point meet and stay connected for a while. LFN in one vehicle needs to talk to another LFN in another vehicle. There's no Internet connectivity and the boxes need to run widely IPv6 available software. This is the kind of scenario I was asking whether it deserves inclusion in discussion of problem statement. There are more MANEMO scenarios discussed during the MANEMO pre-BoF. Should we include this above scenario in the AUTOCONF discussion? Should we discuss AUTOCONF scenarios in this way? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Dec 03 23:35:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzPUr-0006nV-Fb; Mon, 03 Dec 2007 23:35:01 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IzPUo-0006jM-V8 for autoconf-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 23:34:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzPUo-0006ic-Kr for autoconf@ietf.org; Mon, 03 Dec 2007 23:34:58 -0500 Received: from ccmail.cc.niigata-u.ac.jp ([133.35.23.1] helo=mxav03.cc.niigata-u.ac.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzPUl-0001gy-Lg for autoconf@ietf.org; Mon, 03 Dec 2007 23:34:58 -0500 Received: from mxav03.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9A1962916F7 for ; Tue, 4 Dec 2007 13:32:19 +0900 (JST) Received: from mxav03.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by mxav03.cc.niigata-u.ac.jp (Postfix) with SMTP id F23BE29127B for ; Tue, 4 Dec 2007 13:32:18 +0900 (JST) Received: (qmail 26041 invoked from network); 4 Dec 2007 13:32:18 +0900 Received: from unknown (HELO chamame.ie.niigata-u.ac.jp) (133.35.169.34) by mxav03.cc.niigata-u.ac.jp with SMTP; 4 Dec 2007 13:32:18 +0900 Received: (qmail 21050 invoked from network); 4 Dec 2007 13:32:18 +0900 Received: from unknown (HELO neccomputer.ie.niigata-u.ac.jp) (133.35.156.66) by chamame.ie.niigata-u.ac.jp with SMTP; 4 Dec 2007 13:32:18 +0900 Message-Id: <7.0.0.16.2.20071204130327.0473d858@ie.niigata-u.ac.jp> X-Mailer: QUALCOMM Windows Eudora Version 7J rev1.0 Date: Tue, 04 Dec 2007 13:32:25 +0900 To: RYUJI WAKIKAWA From: mase Subject: Re: [Autoconf] comments to autoconf PS In-Reply-To: <62022ED1-47D5-4704-AC53-01738CD75027@gmail.com> References: <7.0.0.16.2.20071202181233.04971348@ie.niigata-u.ac.jp> <62022ED1-47D5-4704-AC53-01738CD75027@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 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, Ryuji, Comments in line. At 03:04 07/12/04, RYUJI WAKIKAWA wrote: >Hi Mase-san > >On 2007/12/02, at 1:24, mase wrote: > >>Dear Ryuji, >> >>Thank you for your good comments. >>I agree that it is very important to make clear the scope when >>discussing autoconfiguration. >> >>With regard to the definition of MANET-local address, I am also not >>satisfied with the current definition. My proposal is as follows: >>MANET-local address an address having MANET-only scope that can be >>used to reach destinations in the MANET. All MANET interfaces have a >>MANET-local unicast address. > >I was asking what is the MANET-local scope? :-) >How can you map this manet-local into the current IPv6 scoping? >Do you suggest to define new address scope for MANET-local? MANET is a routing domain containing MANET routers, as defined in manetarch document. MANET-local sope is thus same as the set of MANET routers in a MANET. Whether to define a new address scope for addresses of MANET-local scope is another issue. We may define a new address scope for MANET-local or use unique-local address. This is one of the problems, which shold be clearly described in the PS draft. >>What is MANET is given in the manetarch document, so I think that >>the above definition is clear. In reality, I think that we may use >>unique local IPv6 unicast address for MANET-local address. > >The use of ULA is fine, but I expect this document help understanding >the possible issues when using ULA. >And I want to see the reason why you call this as manet-local. >What is the difference between ULA and manet-local? >This is really confusing... IMHO, MANET scope and address scope to be used for MANET scope is different issue. ULA can be used for addresses of MANET scope, but ULA can be also used for another scope such as sites. Kenichi >>I think that we cannot depend on link-local address, since MANET >>interface is SBI. In this context, I think that link-local address >>must not be used in MANET routing messages as well as data >>forwarding. This is my personal opinion at this time and need to >>discuss with the co-authors. Anyway, these points must be clearly >>described in the PS domument, as you suggested. Sorry for the only >>partial answer to your comments. > >ok. > >regards, >ryuji > >>Regards, >>Kenichi >> >>At 03:33 07/11/30, RYUJI WAKIKAWA wrote: >>>Hi Emmanuel and all, >>> >>>First of all, i am sorry for my long silence, I needed some time to >>>recover from MANEMO wars in previous IETFs:-p >>> >>>I finally reviewed this document and have a lot of comments, though >>>some of my comments may be overlapped with others or already be >>>discussed in ML. >>> >>>To be honest, I am not such comfortable with this document >>>(except for the description of uniqueness issue which is well >>>explained!). >>>There are so many unclear explanation. Let me explain the >>>general comments first and then detail my comments later. >>> >>>- Do you assume DHCP and RA(NDP) as solutions of AUTOCONF? >>>NDP does not deal with prefix assignment. If you want to assign >>>prefix, stateless approach defined in RFC4862 is impossible, IMO. >>>A "stateful" mechanism using NDP might be possible if we can design >>>so. >>> >>>- Scope Issue >>>There is nowhere to discuss which scope of address/prefix should be >>>assigned to which interface. It is very important to consider the >>>address scope in IPv6. For example, there is no discussion whether >>>manet nodes in a same manet uses the same scope for MLP/MLA. Can >>>MANET-A having link-local sends packets to MANET-B having only global >>>? This goes against IPv6 spec. >>> >>>According to manet-arch, each manet node needs to obtain "unique >>>prefix" instead of address for its local network and also must obtain >>>"unique prefix or address" for manet interface, too. Am I right? >>>For the first prefix, there are two possibility: global prefix or >>>uniquelocal prefix. >>>For the second, five possibility: global prefix, global address, >>>uniquelocal prefix, uniquelocal address, link local address. >>> >>>How can AUTOCONF deal with these scope and differences? I think it's >>>very important to use the same scope specially for MANET interface. >>>You can not send packets from link-local scope to global scope over >>>link. Other direction is OK. Do we agree on relaxing this scope >>>limitation in manet? >>> >>>Is there any definition that the same scope MUST be used for >>> MLP/MLA? >>> Does the word "valid" below indicate this? It should explicitly >>> write so. >>> >>>" MANET Local Prefix (MLP) - An IP prefix delegated to a MANET >>>router, >>> consisting in chunks of IP addresses valid for communications >>> inside the MANET. >>> MANET Local Address (MLA) - An IP address configured on a MANET >>> interface, and valid for communications inside the MANET." >>> >>>Actually, I am not clear what is MLA/MLP... >>>The document said in section 4.1 >>>"a MANET router needs to configure at least one IP address on its >>> MANET interface, this being a link local address, an MLA or a >>> global address." >>> >>>Does it mean MLA is unique local address?? >>> >>>- How can each manet node decide whether it can obtain prefix or >>>address on a manet interface? In IPv6, it is simpler that every node >>>generates a link-local address on its interface, while manet node may >>>not assign a link-local address on manet interface. How can this node >>>decide whether it should wait for prefix or simply generate a >>>link-local address? >>> >>>There is related question. How can a manet node detects whether it >>>attaches to manet or not? In IPv6, as soon as an interface becomes >>>active, it will start assigning a link-local address. However, a >>>manet >>>node may wait this operation until it detects characteristics of >>>attached network (regular IPv6 or manet)... This is also one of issue >>>how a node can deploy both in manet and regular IPv6. In addition to >>>this, a manet node may need to detect connected or standalone manet >>>when it attaches to a network in order to discover ICP?!. >>> >>>- Last general question: for the prefix assignment to manet (not >>>manet >>>interface), There are two possibility depending on ICP availability: >>>topologically correct prefix or non correct prefix. I think this is >>>two different things though the goal is same assigning prefix to >>>manet. Shall a solution support both scenarios? >>> >>>-------------------------------------------------------------------------------- >>>Detailed comments >>> >>>- In section 4.1.1, it only said >>>" IPv6 Stateless Address Autoconfiguration [5] and Neighbor >>>Discovery >>> for IPv6 [3] do not account for potential address duplication >>>beyond >>> a single multicast-capable link." >>> >>>NDP actually does not consider "multi-hop" support at all. I think >>>this address duplication is side-effect of no multi-hop >>>consideration. >>> >>>- Why do you say "p2p link" between border router and ISP edge router >>> in figure 1??? >>> >>>- In section 4.1.2, it said >>> Fig. 1, even if MR1 would be able to provision MR3 with prefixes, >>> using DHCP [4], it cannot be assumed that MR1 or MR3 will not move >>> and become unable to communicate directly. On the other hand, >>> frequent reconfiguration may cause IPv6 Stateless Address >>> Autoconfiguration [5] to be much less efficient than expected, due >>>to >>> large amounts of control signalling. >>> >>>This paragraph assume running DHCP and AUTOCONF over multihop. >>> >>>Do you assume that MR1 is DHCP relay ?? There is no way to forward >>>DHCP messages by MR1. The document repeated to say that "as-is" >>>existing solution does not fit to manet environment. I don't think >>>these texts are useful explanation in this document. If you want to >>>explain the constraints of existing solutions, you should have >>>independent section how DHCP/NDP cannot fit to manet more in detail, >>>please. Problem statement document should not suggest or assume any >>>solutions. >>> >>>- I'm not sure but "broadcast" may be IPv4 term!? >>> >>>- Section 4.2.3 >>> When a router changes its ICP affiliation, some routes may be >>>broken, >>> affecting MANET packet forwarding performance and applications. >>>In a >>> multiple border router / multiple-prefixes MANET, frequent >>> reconfiguration could cause a large amount of control signalling >>>(for >>> instance if [5] is used). >>> >>>Isn't this problem of DHCP? >>>Do you assume that a manet node can unicast renew message over >>>connected ICP to the previous ICP and continue using the same >>>address?!:-p >>>Or you just mention NDP? It is no clear to me what is the intention >>>you refer only NDP here. >>> >>>- Section 5, It contains only general considerations. >>>Not specific to AUTOCONF solutions. >>> >>>- Section 6, if you mention the security issue specific to AUTOCONF >>> (Not NDP), you should write in the section 4. You can refer the >>> section in the security consideration section. It will be nice if >>> you can list up all possible security threats regarding AUTOCONF >>> solutions (rather than referring security considerations of existing >>> solutions). >>> >>> >>> >>> >>> >>> >>> >>>_______________________________________________ >>>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 Mon Dec 03 23:36:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzPVo-0007Vl-CU; Mon, 03 Dec 2007 23:36:00 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IzPVm-0007VK-JT for autoconf-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 23:35:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzPVm-0007VA-7A for autoconf@ietf.org; Mon, 03 Dec 2007 23:35:58 -0500 Received: from ccmail.cc.niigata-u.ac.jp ([133.35.23.1] helo=mxav03.cc.niigata-u.ac.jp) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzPVk-0004SY-3r for autoconf@ietf.org; Mon, 03 Dec 2007 23:35:58 -0500 Received: from mxav03.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 54765290372 for ; Tue, 4 Dec 2007 13:35:54 +0900 (JST) Received: from mxav03.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by mxav03.cc.niigata-u.ac.jp (Postfix) with SMTP id 42801290258 for ; Tue, 4 Dec 2007 13:35:54 +0900 (JST) Received: (qmail 28577 invoked from network); 4 Dec 2007 13:35:54 +0900 Received: from unknown (HELO chamame.ie.niigata-u.ac.jp) (133.35.169.34) by mxav03.cc.niigata-u.ac.jp with SMTP; 4 Dec 2007 13:35:54 +0900 Received: (qmail 21229 invoked from network); 4 Dec 2007 13:35:52 +0900 Received: from unknown (HELO neccomputer.ie.niigata-u.ac.jp) (133.35.156.66) by chamame.ie.niigata-u.ac.jp with SMTP; 4 Dec 2007 13:35:52 +0900 Message-Id: <7.0.0.16.2.20071204133323.04812060@ie.niigata-u.ac.jp> X-Mailer: QUALCOMM Windows Eudora Version 7J rev1.0 Date: Tue, 04 Dec 2007 13:36:00 +0900 To: RYUJI WAKIKAWA From: mase Subject: Re: [Autoconf] comments to autoconf PS In-Reply-To: <9CDEB610-8E7E-47F9-BB02-AD714E8D0CB7@gmail.com> References: <7.0.0.16.2.20071202181233.04971348@ie.niigata-u.ac.jp> <475323CF.4080604@gmail.com> <7.0.0.16.2.20071203115230.04bda790@ie.niigata-u.ac.jp> <002301c8355e$639a3e70$2acebb50$@nl> <7.0.0.16.2.20071203125837.049dbf18@ie.niigata-u.ac.jp> <9CDEB610-8E7E-47F9-BB02-AD714E8D0CB7@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 96e0f8497f38c15fbfc8f6f315bcdecb 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 Comments in line. At 03:10 07/12/04, RYUJI WAKIKAWA wrote: >On 2007/12/02, at 20:04, mase wrote: > >>Teco, >> >>Thank you for your comments. See in line. >> >>At 12:41 07/12/03, Teco Boot wrote: >>>Alex, Kenichi, >>> >>>I want to share my thoughts on link-local addresses and MLA with you. >>>I think link-locals are essential to IPv6. I do not understand why >>>we have a >>>discussion on this. It is to be used for single hop communication, >>>which is >>>also very applicable in MANET. >> >>Yes, but your former neighbor may be now out-of-transmission range >>and only communicated over multi-hop. >>Do you prefer to change your source/destination address from a >>link- local address to MLA? > >The link-lcoal is still useful for any traffic transmitted only to >1- hop neighbor like NS/NA. Yes, but when this neighbor moves away far, address information obtained through NS/NA cannot work. Kenichi >ryuji > >>>I think MLA's are to be used for multi hop communications in the >>>MANET. >> >>Right. >> >>>I agree ULA is an obvious candidate for MLA. >> >>Thanks, >>Kenichi >> >> >>>Teco. >>> >>> > -----Oorspronkelijk bericht----- >>> > Van: mase [mailto:mase@ie.niigata-u.ac.jp] >>> > Verzonden: maandag 3 december 2007 4:19 >>> > Aan: Alexandru Petrescu >>> > CC: autoconf@ietf.org >>> > Onderwerp: Re: [Autoconf] comments to autoconf PS >>> > >>> > Hi, Alex, >>> > >>> > At 06:29 07/12/03, Alexandru Petrescu wrote: >>> > >Hi mase, I have some opinions compared to your opinions, just some >>> > >discussion. I mainly agree with your suggestions to define >>>addresses. >>> > >>> > Thanks. >>> > >>> > >>> > >mase wrote: >>> > >>Dear Ryuji, >>> > >>Thank you for your good comments. I agree that it is very >>> > >>important to make clear the scope when discussing >>>autoconfiguration. >>> > >>With regard to the definition of MANET-local address, I am also >>> > >>not satisfied with the current definition. My proposal is as >>> > >>follows: MANET-local address an address having MANET-only scope >>> > >>that can be used to reach destinations in the MANET. All MANET >>> > >>interfaces have a MANET-local unicast address. >>> > > >>> > >But looks as it is a recursive definition? >>> > >>> > I have a suggestion of this style from the definition of link-local >>> > address of RFC4862. >>> > >>> > >>> > >When you say 'reach' do you mean the packet can be forwarded by a >>> > >intermediary router? >>> > >>> > Right. >>> > >>> > >Or is it that the packet is reaching the >>> > >destination without being forwarded by any router? >>> > > >>> > >Otherwise all packets have to reach their destinations. >>> > > >>> > >I'm tempted to define like this: >>> > > >>> > > MANET-local address >>> > > >>> > > An IPv6 link-local address. >>> > >>> > IMHO, this is not reasonalbe because forwarding is necessary to >>> > deliver packets to the destination, when source and destinatio >>> > MANET routers are not neighbors to each other. >>> > >>> > >>> > >This has pretty good semantics in my understanding. Opinions? >>> > > >>> > >>What is MANET is given in the manetarch document, so I think >>>that the >>> > >> above definition is clear. In reality, I think that we may use >>> > >> unique local IPv6 unicast address for MANET-local address. >>> > > >>> > >I think ULA (Unique Local Addresses) don't have a scope related >>>to the >>> > >link. I think a ULA addressed packet can reach a destination in a >>> > MANET >>> > >and sometimes it has to be forwarded to achieve that goal. >>> > > >>> > >You seem to say: >>> > > >>> > > MANET-local address >>> > > >>> > > A Unique Local Address (ULA RFCxxxx) >>> > > >>> > >If so, then I agree with you. >>> > >>> > I think that unique local address is a good candidate to be used >>>in the >>> > MANET. >>> > >>> > >>> > >>I think that we cannot depend on link-local address, since MANET >>> > >>interface is SBI. >>> > > >>> > >I think it is strange to assume that a MANET uses _only_ SBI >>> > interfaces. >>> > > I think I can build a MANET that does _not_ use SBI >>>interfaces. In >>> > >such a case I think IPv6 link-local addresses can be useful. >>> > >>> > As mentioned above, packet forwarding is necessary in general in a >>> > MANET. Thus link-local address is not appropriate as the >>> > source/destination address. >>> > >>> > Kenichi >>> > >>> > >>> > >Alex >>> > > >>> > >>In this context, I think that link-local address must not be >>>used in >>> > >>MANET routing messages as well as data forwarding. This is my >>> > >>personal opinion at this time and need to discuss with the >>> > >>co-authors. Anyway, these points must be clearly described in the >>> > >>PS domument, as you suggested. Sorry for the only partial >>>answer to >>> > your >>> > >>comments. >>> > >>Regards, Kenichi >>> > >>At 03:33 07/11/30, RYUJI WAKIKAWA wrote: >>> > >>>Hi Emmanuel and all, >>> > >>>First of all, i am sorry for my long silence, I needed some >>>time to >>> > >>> recover from MANEMO wars in previous IETFs:-p >>> > >>>I finally reviewed this document and have a lot of comments, >>>though >>> > >>> some of my comments may be overlapped with others or already >>> > >>> be discussed in ML. >>> > >>>To be honest, I am not such comfortable with this document >>> > >>>(except for the description of uniqueness issue which is well >>> > explained!). >>> > >>> There are so many unclear explanation. Let me explain the >>> > >>> general comments first and then detail my comments later. >>> > >>>- Do you assume DHCP and RA(NDP) as solutions of AUTOCONF? NDP >>>does >>> > >>> not deal with prefix assignment. If you want to assign >>> > >>> prefix, stateless approach defined in RFC4862 is impossible, >>>IMO. >>> > >>> A "stateful" mechanism using NDP might be possible if we can >>>design >>> > so. >>> > >>>- Scope Issue There is nowhere to discuss which scope of >>> > >>>address/prefix should be assigned to which interface. It is >>>very >>> > >>>important to consider the address scope in IPv6. For example, >>> > >>>there is no discussion whether manet nodes in a same manet >>>uses the >>> > >>> same scope for MLP/MLA. Can MANET-A having link-local sends >>> > >>> packets to MANET-B having only global ? This goes against IPv6 >>> > spec. >>> > >>>According to manet-arch, each manet node needs to obtain >>> > >>>"unique prefix" instead of address for its local network and >>>also >>> > >>>must obtain "unique prefix or address" for manet interface, too. >>> > >>>Am I right? For the first prefix, there are two possibility: >>> > >>>global prefix or uniquelocal prefix. For the second, five >>> > >>>possibility: global prefix, global address, uniquelocal prefix, >>> > >>>uniquelocal address, link local address. >>> > >>>How can AUTOCONF deal with these scope and differences? I >>> > >>>think it's very important to use the same scope specially for >>> > >>>MANET interface. You can not send packets from link-local >>>scope to >>> > global >>> > >>> scope over link. Other direction is OK. Do we agree on >>> > >>> relaxing this scope limitation in manet? >>> > >>>Is there any definition that the same scope MUST be used for >>> > >>>MLP/MLA? Does the word "valid" below indicate this? It should >>> > >>>explicitly write so. >>> > >>>" MANET Local Prefix (MLP) - An IP prefix delegated to a >>> > >>>MANET router, consisting in chunks of IP addresses valid for >>> > >>>communications inside the MANET. MANET Local Address (MLA) - >>>An IP >>> > >>> address configured on a MANET interface, and valid for >>> > >>> communications inside the MANET." >>> > >>>Actually, I am not clear what is MLA/MLP... The document said >>> > >>>in section 4.1 "a MANET router needs to configure at least one >>>IP >>> > >>>address on its MANET interface, this being a link local >>>address, an >>> > >>> MLA or a global address." >>> > >>>Does it mean MLA is unique local address?? >>> > >>>- How can each manet node decide whether it can obtain prefix >>> > >>>or address on a manet interface? In IPv6, it is simpler that >>> > >>>every node generates a link-local address on its interface, >>>while >>> > >>>manet node may not assign a link-local address on manet >>>interface. >>> > >>>How can this node decide whether it should wait for prefix or >>> > >>>simply generate a link-local address? >>> > >>>There is related question. How can a manet node detects >>>whether it >>> > >>> attaches to manet or not? In IPv6, as soon as an interface >>>becomes >>> > >>> active, it will start assigning a link-local address. >>> > >>> However, a manet node may wait this operation until it detects >>> > characteristics >>> > >>> of attached network (regular IPv6 or manet)... This is also >>>one of >>> > >>> issue how a node can deploy both in manet and regular IPv6. >>> > >>> In addition to this, a manet node may need to detect >>>connected or >>> > >>> standalone manet when it attaches to a network in order to >>>discover >>> > >>> ICP?!. >>> > >>>- Last general question: for the prefix assignment to manet >>> > >>>(not manet interface), There are two possibility depending on >>>ICP >>> > >>>availability: topologically correct prefix or non correct >>>prefix. I >>> > >>>think this is two different things though the goal is same >>> > >>>assigning prefix to manet. Shall a solution support both >>>scenarios? >>> > >>> > > >-------------------------------------------------------------------- >>> > ------------ >>> > >>> >>> > >>>Detailed comments >>> > >>>- In section 4.1.1, it only said " IPv6 Stateless Address >>> > >>>Autoconfiguration [5] and Neighbor Discovery for IPv6 [3] do not >>> > >>>account for potential address duplication beyond a single >>> > >>>multicast-capable link." >>> > >>>NDP actually does not consider "multi-hop" support at all. I >>>think >>> > >>> this address duplication is side-effect of no multi-hop >>> > consideration. >>> > >>>- Why do you say "p2p link" between border router and ISP edge >>> > >>>router in figure 1??? >>> > >>>- In section 4.1.2, it said Fig. 1, even if MR1 would be able >>> > >>>to provision MR3 with prefixes, using DHCP [4], it cannot be >>> > >>>assumed that MR1 or MR3 will not move and become unable to >>> > >>>communicate directly. On the other hand, frequent >>>reconfiguration >>> > >>>may cause IPv6 Stateless Address Autoconfiguration [5] to be >>>much >>> > >>>less efficient than expected, due to large amounts of control >>> > signalling. >>> > >>>This paragraph assume running DHCP and AUTOCONF over multihop. >>> > >>>Do you assume that MR1 is DHCP relay ?? There is no way to >>>forward >>> > >>> DHCP messages by MR1. The document repeated to say that >>> > >>> "as-is" existing solution does not fit to manet environment. I >>> > don't think >>> > >>> these texts are useful explanation in this document. If you >>>want >>> > >>>to explain the constraints of existing solutions, you should >>> > >>>have independent section how DHCP/NDP cannot fit to manet more >>>in >>> > >>>detail, please. Problem statement document should not suggest >>>or >>> > >>>assume any solutions. >>> > >>>- I'm not sure but "broadcast" may be IPv4 term!? >>> > >>>- Section 4.2.3 When a router changes its ICP affiliation, some >>> > >>>routes may be broken, affecting MANET packet forwarding >>>performance >>> > >>> and applications. In a multiple border router / >>> > >>> multiple-prefixes MANET, frequent reconfiguration could cause a >>> > >>> large amount of control signalling (for instance if [5] is >>>used). >>> > >>>Isn't this problem of DHCP? Do you assume that a manet node >>> > >>>can unicast renew message over connected ICP to the previous ICP >>> > >>>and continue using the same address?!:-p Or you just mention >>>NDP? >>> > >>>It is no clear to me what is the intention you refer only NDP >>>here. >>> > >>>- Section 5, It contains only general considerations. Not >>> > >>>specific to AUTOCONF solutions. >>> > >>>- Section 6, if you mention the security issue specific to >>>AUTOCONF >>> > >>> (Not NDP), you should write in the section 4. You can refer >>> > >>> the section in the security consideration section. It will be >>> > >>> nice if you can list up all possible security threats regarding >>> > >>> AUTOCONF solutions (rather than referring security >>>considerations >>> > >>> of existing solutions). >>> > >>> >>> > >>> >>> > >>> >>> > >>>_______________________________________________ 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 >>> > > >>> > > >>> > >>> > ______________________________________________________________________ >>> > >This email has been scanned by the MessageLabs Email Security >>>System. >>> > >For more information please visit >>> > >http://www.messagelabs.com/email >>> > >>> > ______________________________________________________________________ >>> > > >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > 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 From autoconf-bounces@ietf.org Mon Dec 03 23:46:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzPg7-0004PA-4L; Mon, 03 Dec 2007 23:46:39 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IzPg5-0004Ox-Hy for autoconf-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 23:46:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzPg5-0004Oo-8K for autoconf@ietf.org; Mon, 03 Dec 2007 23:46:37 -0500 Received: from ccmail.cc.niigata-u.ac.jp ([133.35.23.1] helo=mxav03.cc.niigata-u.ac.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzPg2-0002RO-Ns for autoconf@ietf.org; Mon, 03 Dec 2007 23:46:37 -0500 Received: from mxav03.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id AA8D62917FF for ; Tue, 4 Dec 2007 13:46:33 +0900 (JST) Received: from mxav03.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by mxav03.cc.niigata-u.ac.jp (Postfix) with SMTP id 97DDB291648 for ; Tue, 4 Dec 2007 13:46:33 +0900 (JST) Received: (qmail 3066 invoked from network); 4 Dec 2007 13:46:33 +0900 Received: from unknown (HELO chamame.ie.niigata-u.ac.jp) (133.35.169.34) by mxav03.cc.niigata-u.ac.jp with SMTP; 4 Dec 2007 13:46:33 +0900 Received: (qmail 21576 invoked from network); 4 Dec 2007 13:46:33 +0900 Received: from unknown (HELO neccomputer.ie.niigata-u.ac.jp) (133.35.156.66) by chamame.ie.niigata-u.ac.jp with SMTP; 4 Dec 2007 13:46:33 +0900 Message-Id: <7.0.0.16.2.20071204133626.04755a98@ie.niigata-u.ac.jp> X-Mailer: QUALCOMM Windows Eudora Version 7J rev1.0 Date: Tue, 04 Dec 2007 13:46:41 +0900 To: RYUJI WAKIKAWA From: mase Subject: Re: [Autoconf] comments to autoconf PS In-Reply-To: References: <7.0.0.16.2.20071202181233.04971348@ie.niigata-u.ac.jp> <475323CF.4080604@gmail.com> <7.0.0.16.2.20071203115230.04bda790@ie.niigata-u.ac.jp> <002301c8355e$639a3e70$2acebb50$@nl> <7.0.0.16.2.20071203125837.049dbf18@ie.niigata-u.ac.jp> <003001c83587$72dc33b0$58949b10$@nl> <7.0.0.16.2.20071203174016.04b66058@ie.niigata-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6c15d82a53e26283536b4a751453103 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, At 03:15 07/12/04, RYUJI WAKIKAWA wrote: >Hi > >On 2007/12/03, at 0:49, mase wrote: > >>Comments in line. >> >>At 17:35 07/12/03, Teco Boot wrote: >>>Comments inline. >>> >>> > -----Oorspronkelijk bericht----- >>> > Van: mase [mailto:mase@ie.niigata-u.ac.jp] >>> > Verzonden: maandag 3 december 2007 5:05 >>> > Aan: Teco Boot; 'Alexandru Petrescu' >>> > CC: autoconf@ietf.org >>> > Onderwerp: RE: [Autoconf] comments to autoconf PS >>> > >>> > Teco, >>> > >>> > Thank you for your comments. See in line. >>> > >>> > At 12:41 07/12/03, Teco Boot wrote: >>> > >Alex, Kenichi, >>> > > >>> > >I want to share my thoughts on link-local addresses and MLA with >>>you. >>> > >I think link-locals are essential to IPv6. I do not understand >>>why we >>> > have a >>> > >discussion on this. It is to be used for single hop communication, >>> > which is >>> > >also very applicable in MANET. >>> > >>> > Yes, but your former neighbor may be now out-of-transmission range >>> > and only communicated over multi-hop. >>> > Do you prefer to change your source/destination address from a >>> > link-local address to MLA? >>> >>>No. I prefer using Global Address over MLA over link-local address. >>> >>>With Global Addresses, inner-MANET communication is to be used >>>whenever >>>possible (there is a weak link problem, for this discussion: out-of- scope). >>>In case of partitioning, communication can continue if NEMO (or >>>equivalent) >>>is used and both partitions are still part of the Internet (or >>>connected to >>>Internet, this is a definition question). Maybe we need some >>>interaction >>>between MANET routing and NEMO, but in principle, this should work. >> >>Agree, if global address is available. > >Do you say that if global address is available, global address is >treated as MLA? No, but global address can be used for intra-MANET communication, if they are maintained by MANET routers. >I think global address cannot be MLA, since some signaling (ex. >DHCP!?) over mult-hop >to obtain global address are required. chicken-egg problem !? Right. a MANET router must therefore configure a MLA address first, then it may obtain a global prefix and configure a global address in principle. >>In the stand-alone MANET, MLA >>should be used. > >do you mean ULA as MLA? ULA is one of the candidates. I am not sure we should create a new address scope for MLA at this time. This may be answered in solution space. Kenichi >regards, >ryuji > >> >>>If traffic is bound to single-hop, link-local addresses shall be >>>used and >>>connectivity is broken when getting out of transmission range. >> >>If we use MLA and MANET routing, connectivity may not be broken even >>when getting out of transmission range thanks to multihop >>connectivity. This is the MANET. >> >>Kenichi >> >> >>>Teco. >>> >>> >>> > >>> > >I think MLA's are to be used for multi hop communications in the >>> > MANET. >>> > >>> > Right. >>> > >>> > >I agree ULA is an obvious candidate for MLA. >>> > >>> > Thanks, >>> > Kenichi >>> > >>> > >>> > >Teco. >>> > > >>> > > > -----Oorspronkelijk bericht----- >>> > > > Van: mase [mailto:mase@ie.niigata-u.ac.jp] >>> > > > Verzonden: maandag 3 december 2007 4:19 >>> > > > Aan: Alexandru Petrescu >>> > > > CC: autoconf@ietf.org >>> > > > Onderwerp: Re: [Autoconf] comments to autoconf PS >>> > > > >>> > > > Hi, Alex, >>> > > > >>> > > > At 06:29 07/12/03, Alexandru Petrescu wrote: >>> > > > >Hi mase, I have some opinions compared to your opinions, >>>just some >>> > > > >discussion. I mainly agree with your suggestions to define >>> > addresses. >>> > > > >>> > > > Thanks. >>> > > > >>> > > > >>> > > > >mase wrote: >>> > > > >>Dear Ryuji, >>> > > > >>Thank you for your good comments. I agree that it is very >>> > > > >>important to make clear the scope when discussing >>> > autoconfiguration. >>> > > > >>With regard to the definition of MANET-local address, I am >>>also >>> > > > >>not satisfied with the current definition. My proposal is as >>> > > > >>follows: MANET-local address an address having MANET-only >>>scope >>> > > > >>that can be used to reach destinations in the MANET. All >>>MANET >>> > > > >>interfaces have a MANET-local unicast address. >>> > > > > >>> > > > >But looks as it is a recursive definition? >>> > > > >>> > > > I have a suggestion of this style from the definition of link- local >>> > > > address of RFC4862. >>> > > > >>> > > > >>> > > > >When you say 'reach' do you mean the packet can be forwarded >>>by a >>> > > > >intermediary router? >>> > > > >>> > > > Right. >>> > > > >>> > > > >Or is it that the packet is reaching the >>> > > > >destination without being forwarded by any router? >>> > > > > >>> > > > >Otherwise all packets have to reach their destinations. >>> > > > > >>> > > > >I'm tempted to define like this: >>> > > > > >>> > > > > MANET-local address >>> > > > > >>> > > > > An IPv6 link-local address. >>> > > > >>> > > > IMHO, this is not reasonalbe because forwarding is necessary to >>> > > > deliver packets to the destination, when source and destinatio >>> > > > MANET routers are not neighbors to each other. >>> > > > >>> > > > >>> > > > >This has pretty good semantics in my understanding. Opinions? >>> > > > > >>> > > > >>What is MANET is given in the manetarch document, so I >>>think that >>> > the >>> > > > >> above definition is clear. In reality, I think that we >>>may use >>> > > > >> unique local IPv6 unicast address for MANET-local address. >>> > > > > >>> > > > >I think ULA (Unique Local Addresses) don't have a scope >>>related to >>> > the >>> > > > >link. I think a ULA addressed packet can reach a >>>destination in a >>> > > > MANET >>> > > > >and sometimes it has to be forwarded to achieve that goal. >>> > > > > >>> > > > >You seem to say: >>> > > > > >>> > > > > MANET-local address >>> > > > > >>> > > > > A Unique Local Address (ULA RFCxxxx) >>> > > > > >>> > > > >If so, then I agree with you. >>> > > > >>> > > > I think that unique local address is a good candidate to be >>>used in >>> > the >>> > > > MANET. >>> > > > >>> > > > >>> > > > >>I think that we cannot depend on link-local address, since >>>MANET >>> > > > >>interface is SBI. >>> > > > > >>> > > > >I think it is strange to assume that a MANET uses _only_ SBI >>> > > > interfaces. >>> > > > > I think I can build a MANET that does _not_ use SBI >>>interfaces. >>> > In >>> > > > >such a case I think IPv6 link-local addresses can be useful. >>> > > > >>> > > > As mentioned above, packet forwarding is necessary in general >>>in a >>> > > > MANET. Thus link-local address is not appropriate as the >>> > > > source/destination address. >>> > > > >>> > > > Kenichi >>> > > > >>> > > > >>> > > > >Alex >>> > > > > >>> > > > >>In this context, I think that link-local address must not >>>be used >>> > in >>> > > > >>MANET routing messages as well as data forwarding. This is my >>> > > > >>personal opinion at this time and need to discuss with the >>> > > > >>co-authors. Anyway, these points must be clearly described >>>in the >>> > > > >>PS domument, as you suggested. Sorry for the only partial >>>answer >>> > to >>> > > > your >>> > > > >>comments. >>> > > > >>Regards, Kenichi >>> > > > >>At 03:33 07/11/30, RYUJI WAKIKAWA wrote: >>> > > > >>>Hi Emmanuel and all, >>> > > > >>>First of all, i am sorry for my long silence, I needed >>>some time >>> > to >>> > > > >>> recover from MANEMO wars in previous IETFs:-p >>> > > > >>>I finally reviewed this document and have a lot of comments, >>> > though >>> > > > >>> some of my comments may be overlapped with others or >>>already >>> > > > >>> be discussed in ML. >>> > > > >>>To be honest, I am not such comfortable with this document >>> > > > >>>(except for the description of uniqueness issue which is >>>well >>> > > > explained!). >>> > > > >>> There are so many unclear explanation. Let me explain the >>> > > > >>> general comments first and then detail my comments later. >>> > > > >>>- Do you assume DHCP and RA(NDP) as solutions of AUTOCONF? >>>NDP >>> > does >>> > > > >>> not deal with prefix assignment. If you want to assign >>> > > > >>> prefix, stateless approach defined in RFC4862 is >>>impossible, >>> > IMO. >>> > > > >>> A "stateful" mechanism using NDP might be possible if we >>>can >>> > design >>> > > > so. >>> > > > >>>- Scope Issue There is nowhere to discuss which scope of >>> > > > >>>address/prefix should be assigned to which interface. It is >>> > very >>> > > > >>>important to consider the address scope in IPv6. For >>>example, >>> > > > >>>there is no discussion whether manet nodes in a same manet >>>uses >>> > the >>> > > > >>> same scope for MLP/MLA. Can MANET-A having link-local >>>sends >>> > > > >>> packets to MANET-B having only global ? This goes against >>>IPv6 >>> > > > spec. >>> > > > >>>According to manet-arch, each manet node needs to obtain >>> > > > >>>"unique prefix" instead of address for its local network and >>> > also >>> > > > >>>must obtain "unique prefix or address" for manet >>>interface, too. >>> > > > >>>Am I right? For the first prefix, there are two possibility: >>> > > > >>>global prefix or uniquelocal prefix. For the second, five >>> > > > >>>possibility: global prefix, global address, uniquelocal >>>prefix, >>> > > > >>>uniquelocal address, link local address. >>> > > > >>>How can AUTOCONF deal with these scope and differences? I >>> > > > >>>think it's very important to use the same scope specially >>>for >>> > > > >>>MANET interface. You can not send packets from link-local >>>scope >>> > to >>> > > > global >>> > > > >>> scope over link. Other direction is OK. Do we agree on >>> > > > >>> relaxing this scope limitation in manet? >>> > > > >>>Is there any definition that the same scope MUST be used for >>> > > > >>>MLP/MLA? Does the word "valid" below indicate this? It >>>should >>> > > > >>>explicitly write so. >>> > > > >>>" MANET Local Prefix (MLP) - An IP prefix delegated to a >>> > > > >>>MANET router, consisting in chunks of IP addresses valid for >>> > > > >>>communications inside the MANET. MANET Local Address >>>(MLA) - An >>> > IP >>> > > > >>> address configured on a MANET interface, and valid for >>> > > > >>> communications inside the MANET." >>> > > > >>>Actually, I am not clear what is MLA/MLP... The document >>>said >>> > > > >>>in section 4.1 "a MANET router needs to configure at least >>>one >>> > IP >>> > > > >>>address on its MANET interface, this being a link local >>>address, >>> > an >>> > > > >>> MLA or a global address." >>> > > > >>>Does it mean MLA is unique local address?? >>> > > > >>>- How can each manet node decide whether it can obtain >>>prefix >>> > > > >>>or address on a manet interface? In IPv6, it is simpler >>>that >>> > > > >>>every node generates a link-local address on its interface, >>> > while >>> > > > >>>manet node may not assign a link-local address on manet >>> > interface. >>> > > > >>>How can this node decide whether it should wait for prefix >>>or >>> > > > >>>simply generate a link-local address? >>> > > > >>>There is related question. How can a manet node detects >>>whether >>> > it >>> > > > >>> attaches to manet or not? In IPv6, as soon as an interface >>> > becomes >>> > > > >>> active, it will start assigning a link-local address. >>> > > > >>> However, a manet node may wait this operation until it >>>detects >>> > > > characteristics >>> > > > >>> of attached network (regular IPv6 or manet)... This is >>>also >>> > one of >>> > > > >>> issue how a node can deploy both in manet and regular >>>IPv6. >>> > > > >>> In addition to this, a manet node may need to detect >>>connected >>> > or >>> > > > >>> standalone manet when it attaches to a network in order to >>> > discover >>> > > > >>> ICP?!. >>> > > > >>>- Last general question: for the prefix assignment to manet >>> > > > >>>(not manet interface), There are two possibility depending >>>on >>> > ICP >>> > > > >>>availability: topologically correct prefix or non correct >>> > prefix. I >>> > > > >>>think this is two different things though the goal is same >>> > > > >>>assigning prefix to manet. Shall a solution support both >>> > scenarios? >>> > > > >>> >>>---------------------------------------------------------------- >>> > ---- >>> > > > ------------ >>> > > > >>> >>> > > > >>>Detailed comments >>> > > > >>>- In section 4.1.1, it only said " IPv6 Stateless Address >>> > > > >>>Autoconfiguration [5] and Neighbor Discovery for IPv6 [3] >>>do not >>> > > > >>>account for potential address duplication beyond a single >>> > > > >>>multicast-capable link." >>> > > > >>>NDP actually does not consider "multi-hop" support at >>>all. I >>> > think >>> > > > >>> this address duplication is side-effect of no multi-hop >>> > > > consideration. >>> > > > >>>- Why do you say "p2p link" between border router and ISP >>>edge >>> > > > >>>router in figure 1??? >>> > > > >>>- In section 4.1.2, it said Fig. 1, even if MR1 would be >>>able >>> > > > >>>to provision MR3 with prefixes, using DHCP [4], it cannot be >>> > > > >>>assumed that MR1 or MR3 will not move and become unable to >>> > > > >>>communicate directly. On the other hand, frequent >>> > reconfiguration >>> > > > >>>may cause IPv6 Stateless Address Autoconfiguration [5] to be >>> > much >>> > > > >>>less efficient than expected, due to large amounts of >>>control >>> > > > signalling. >>> > > > >>>This paragraph assume running DHCP and AUTOCONF over >>>multihop. >>> > > > >>>Do you assume that MR1 is DHCP relay ?? There is no way to >>> > forward >>> > > > >>> DHCP messages by MR1. The document repeated to say that >>> > > > >>> "as-is" existing solution does not fit to manet >>>environment. I >>> > > > don't think >>> > > > >>> these texts are useful explanation in this document. If >>>you >>> > want >>> > > > >>>to explain the constraints of existing solutions, you should >>> > > > >>>have independent section how DHCP/NDP cannot fit to manet >>>more >>> > in >>> > > > >>>detail, please. Problem statement document should not >>>suggest >>> > or >>> > > > >>>assume any solutions. >>> > > > >>>- I'm not sure but "broadcast" may be IPv4 term!? >>> > > > >>>- Section 4.2.3 When a router changes its ICP affiliation, >>>some >>> > > > >>>routes may be broken, affecting MANET packet forwarding >>> > performance >>> > > > >>> and applications. In a multiple border router / >>> > > > >>> multiple-prefixes MANET, frequent reconfiguration could >>>cause a >>> > > > >>> large amount of control signalling (for instance if [5] is >>> > used). >>> > > > >>>Isn't this problem of DHCP? Do you assume that a manet node >>> > > > >>>can unicast renew message over connected ICP to the >>>previous ICP >>> > > > >>>and continue using the same address?!:-p Or you just mention >>> > NDP? >>> > > > >>>It is no clear to me what is the intention you refer only >>>NDP >>> > here. >>> > > > >>>- Section 5, It contains only general considerations. Not >>> > > > >>>specific to AUTOCONF solutions. >>> > > > >>>- Section 6, if you mention the security issue specific to >>> > AUTOCONF >>> > > > >>> (Not NDP), you should write in the section 4. You can >>>refer >>> > > > >>> the section in the security consideration section. It >>>will be >>> > > > >>> nice if you can list up all possible security threats >>>regarding >>> > > > >>> AUTOCONF solutions (rather than referring security >>> > considerations >>> > > > >>> of existing solutions). >>> > > > >>> >>> > > > >>> >>> > > > >>> >>> > > > >>>_______________________________________________ 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 >>> > > > > >>> > > > > >>> > > > >>> > >>> > ______________________________________________________________________ >>> > > > >This email has been scanned by the MessageLabs Email Security >>> > System. >>> > > > >For more information please visit >>> > > > >http://www.messagelabs.com/email >>> > > > >>> > >>> > ______________________________________________________________________ >>> > > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > _______________________________________________ >>> > > > 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 From autoconf-bounces@ietf.org Mon Dec 03 23:58:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzPrS-00033U-NL; Mon, 03 Dec 2007 23:58:22 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IzPrR-00033G-EX for autoconf-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 23:58:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzPrR-000336-3a for autoconf@ietf.org; Mon, 03 Dec 2007 23:58:21 -0500 Received: from ccmail.cc.niigata-u.ac.jp ([133.35.23.1] helo=mxav03.cc.niigata-u.ac.jp) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzPrQ-0005us-Bv for autoconf@ietf.org; Mon, 03 Dec 2007 23:58:21 -0500 Received: from mxav03.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7D4732906B0 for ; Tue, 4 Dec 2007 13:58:19 +0900 (JST) Received: from mxav03.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by mxav03.cc.niigata-u.ac.jp (Postfix) with SMTP id 6AF7C290507 for ; Tue, 4 Dec 2007 13:58:19 +0900 (JST) Received: (qmail 10514 invoked from network); 4 Dec 2007 13:58:19 +0900 Received: from unknown (HELO chamame.ie.niigata-u.ac.jp) (133.35.169.34) by mxav03.cc.niigata-u.ac.jp with SMTP; 4 Dec 2007 13:58:19 +0900 Received: (qmail 22005 invoked from network); 4 Dec 2007 13:58:19 +0900 Received: from unknown (HELO neccomputer.ie.niigata-u.ac.jp) (133.35.156.66) by chamame.ie.niigata-u.ac.jp with SMTP; 4 Dec 2007 13:58:19 +0900 Message-Id: <7.0.0.16.2.20071204134958.0476dac8@ie.niigata-u.ac.jp> X-Mailer: QUALCOMM Windows Eudora Version 7J rev1.0 Date: Tue, 04 Dec 2007 13:58:27 +0900 To: Alexandru Petrescu From: mase Subject: Re: movement scenario (was: [Autoconf] comments to autoconf PS) In-Reply-To: <4754AB65.2090800@gmail.com> References: <7.0.0.16.2.20071202181233.04971348@ie.niigata-u.ac.jp> <475323CF.4080604@gmail.com> <7.0.0.16.2.20071203115230.04bda790@ie.niigata-u.ac.jp> <002301c8355e$639a3e70$2acebb50$@nl> <7.0.0.16.2.20071203125837.049dbf18@ie.niigata-u.ac.jp> <4754AB65.2090800@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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, At 10:20 07/12/04, Alexandru Petrescu wrote: >mase wrote: >>>I want to share my thoughts on link-local addresses and MLA with >>>you. I think link-locals are essential to IPv6. I do not understand >>>why we have a discussion on this. It is to be used for single hop >>>communication, which is also very applicable in MANET. >>Yes, but your former neighbor may be now out-of-transmission range >>and only communicated over multi-hop. Do you prefer to change your >>source/destination address from a link-local address to MLA? > >Ha! That's right... > >Src/dst address rewriting makes immediately think of NAT :-) > >I think the case you describe above (former neighbor moves from a >link to another) deserves deep analysis. What are the mobility >scenarios considered? How do entities move, from where to where? Any mobility. We do not assume a particular mobility scenario when designing MANET routing protocols. >After a node moves from one subnet to another: does it keep its >address? Does it keep both its address _and_ its prefix? When it >keeps its address - nobody else on the previous link can use that >address on that previous link? Yes, in the same MANET. We thus need to define MANET-local address. Kenichi >Despite the apparent complexity of describing this, I think it's >not so difficult - as long as two or more people have encountered >the same movement scenario. > >Alex > > >______________________________________________________________________ >This email has been scanned by the MessageLabs Email Security System. >For more information please visit http://www.messagelabs.com/email >______________________________________________________________________ > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Dec 04 00:05:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzPym-0001PU-BC; Tue, 04 Dec 2007 00:05:56 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IzPyl-0001PL-5o for autoconf-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 00:05:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzPyk-0001PB-R7 for autoconf@ietf.org; Tue, 04 Dec 2007 00:05:54 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IzPyk-0006Rp-Bg for autoconf@ietf.org; Tue, 04 Dec 2007 00:05:54 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-128.messagelabs.com!1196744751!28767245!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 16169 invoked from network); 4 Dec 2007 05:05:51 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-128.messagelabs.com with SMTP; 4 Dec 2007 05:05:51 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lB455pk9006581; Mon, 3 Dec 2007 22:05:51 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id lB455opN028726; Mon, 3 Dec 2007 23:05:50 -0600 (CST) Received: from [127.0.0.1] ([10.19.242.73]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id lB455nqM028702; Mon, 3 Dec 2007 23:05:49 -0600 (CST) Message-ID: <4754E02D.2030906@gmail.com> Date: Tue, 04 Dec 2007 06:05:49 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: mase Subject: Re: [Autoconf] comments to autoconf PS References: <7.0.0.16.2.20071202181233.04971348@ie.niigata-u.ac.jp> <62022ED1-47D5-4704-AC53-01738CD75027@gmail.com> <7.0.0.16.2.20071204130327.0473d858@ie.niigata-u.ac.jp> In-Reply-To: <7.0.0.16.2.20071204130327.0473d858@ie.niigata-u.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071203-0, 03/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 Kenichi, mase wrote: [...] >>> With regard to the definition of MANET-local address, I am also >>> not satisfied with the current definition. My proposal is as >>> follows: MANET-local address an address having MANET-only scope >>> that can be used to reach destinations in the MANET. All MANET >>> interfaces have a MANET-local unicast address. >> >> I was asking what is the MANET-local scope? :-) How can you map >> this manet-local into the current IPv6 scoping? Do you suggest to >> define new address scope for MANET-local? > > MANET is a routing domain containing MANET routers, as defined in > manetarch document. MANET-local sope is thus same as the set of MANET > routers in a MANET. Along this line: because the LL-MANET-Routers address (ff02::tbd4) has link-local multicast scope (draft-ietf-manet-iana), can we say that MANET-local scope is actually the IPv6 link-local scope? > Whether to define a new address scope for addresses of MANET-local > scope is another issue. We may define a new address scope for > MANET-local or use unique-local address. This is one of the problems, > which shold be clearly described in the PS draft. Right... that's a question. >>> What is MANET is given in the manetarch document, so I think that >>> the above definition is clear. In reality, I think that we may >>> use unique local IPv6 unicast address for MANET-local address. >> >> The use of ULA is fine, but I expect this document help >> understanding the possible issues when using ULA. And I want to see >> the reason why you call this as manet-local. What is the difference >> between ULA and manet-local? This is really confusing... > > IMHO, MANET scope and address scope to be used for MANET scope is > different issue. ULA can be used for addresses of MANET scope, but > ULA can be also used for another scope such as sites. I understand by 'scope' the scope of an address, as per the IPv6 Addressing Architecture RFC. Terminology... :-) Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Dec 04 00:12:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzQ4i-0005DQ-G1; Tue, 04 Dec 2007 00:12:04 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IzQ4h-0005A5-6l for autoconf-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 00:12:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzQ4g-00057Z-Qa for autoconf@ietf.org; Tue, 04 Dec 2007 00:12:02 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IzQ4g-0006nD-6Z for autoconf@ietf.org; Tue, 04 Dec 2007 00:12:02 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-153.messagelabs.com!1196745120!5180993!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 14522 invoked from network); 4 Dec 2007 05:12:00 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-12.tower-153.messagelabs.com with SMTP; 4 Dec 2007 05:12:00 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id lB45BtNe007363; Mon, 3 Dec 2007 22:11:55 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id lB45BsiL001679; Mon, 3 Dec 2007 23:11:54 -0600 (CST) Received: from [127.0.0.1] ([10.19.242.73]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id lB45Bpxu001659; Mon, 3 Dec 2007 23:11:52 -0600 (CST) Message-ID: <4754E18D.3080302@gmail.com> Date: Tue, 04 Dec 2007 06:11:41 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: mase References: <7.0.0.16.2.20071202181233.04971348@ie.niigata-u.ac.jp> <475323CF.4080604@gmail.com> <7.0.0.16.2.20071203115230.04bda790@ie.niigata-u.ac.jp> <002301c8355e$639a3e70$2acebb50$@nl> <7.0.0.16.2.20071203125837.049dbf18@ie.niigata-u.ac.jp> <4754AB65.2090800@gmail.com> <7.0.0.16.2.20071204134958.0476dac8@ie.niigata-u.ac.jp> In-Reply-To: <7.0.0.16.2.20071204134958.0476dac8@ie.niigata-u.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071203-0, 03/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: autoconf@ietf.org Subject: [Autoconf] Re: movement scenario 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 mase wrote: > Hi, > > At 10:20 07/12/04, Alexandru Petrescu wrote: >> mase wrote: >>>> I want to share my thoughts on link-local addresses and MLA >>>> with you. I think link-locals are essential to IPv6. I do not >>>> understand why we have a discussion on this. It is to be used >>>> for single hop communication, which is also very applicable in >>>> MANET. >>> Yes, but your former neighbor may be now out-of-transmission >>> range and only communicated over multi-hop. Do you prefer to >>> change your source/destination address from a link-local address >>> to MLA? >> >> Ha! That's right... >> >> Src/dst address rewriting makes immediately think of NAT :-) >> >> I think the case you describe above (former neighbor moves from a >> link to another) deserves deep analysis. What are the mobility >> scenarios considered? How do entities move, from where to where? > > Any mobility. We do not assume a particular mobility scenario when > designing MANET routing protocols. I think that is a problem. If we don't know the landmarks, the movement patterns, the dependencies... then it's very difficult to design something meaningful, that fits some initial goals and requirements. I think people who have prototyped MANETs have always tested certain movement scenarios. At least these could be documented. It's really very tough to design something that acomodates _any_ mobility... Besides, such thing risks of not being able to be qualified, can not be evaluated, can not be compared. Of course, it _can_ be designed _and_ prototyped but how would one compare it. Alex >> After a node moves from one subnet to another: does it keep its >> address? Does it keep both its address _and_ its prefix? When it >> keeps its address - nobody else on the previous link can use that >> address on that previous link? > > Yes, in the same MANET. We thus need to define MANET-local address. > > Kenichi > >> Despite the apparent complexity of describing this, I think it's >> not so difficult - as long as two or more people have encountered >> the same movement scenario. >> >> Alex >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security >> System. For more information please visit >> http://www.messagelabs.com/email >> ______________________________________________________________________ >> >> > > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Dec 04 00:27:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzQJd-00022G-04; Tue, 04 Dec 2007 00:27:29 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IzQJb-0001ze-Pe for autoconf-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 00:27:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzQJb-0001zU-Fx for autoconf@ietf.org; Tue, 04 Dec 2007 00:27:27 -0500 Received: from ccmail.cc.niigata-u.ac.jp ([133.35.23.1] helo=mxav02.cc.niigata-u.ac.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzQJZ-0004o1-Ag for autoconf@ietf.org; Tue, 04 Dec 2007 00:27:27 -0500 Received: from mxav02.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0E0FF454B41 for ; Tue, 4 Dec 2007 14:27:24 +0900 (JST) Received: from mxav02.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by mxav02.cc.niigata-u.ac.jp (Postfix) with SMTP id EEC014540F1 for ; Tue, 4 Dec 2007 14:27:23 +0900 (JST) Received: (qmail 16394 invoked from network); 4 Dec 2007 14:27:23 +0900 Received: from unknown (HELO chamame.ie.niigata-u.ac.jp) (133.35.169.34) by mxav02.cc.niigata-u.ac.jp with SMTP; 4 Dec 2007 14:27:23 +0900 Received: (qmail 24529 invoked from network); 4 Dec 2007 14:27:23 +0900 Received: from unknown (HELO neccomputer.ie.niigata-u.ac.jp) (133.35.156.66) by chamame.ie.niigata-u.ac.jp with SMTP; 4 Dec 2007 14:27:23 +0900 Message-Id: <7.0.0.16.2.20071204141715.047a72d0@ie.niigata-u.ac.jp> X-Mailer: QUALCOMM Windows Eudora Version 7J rev1.0 Date: Tue, 04 Dec 2007 14:27:29 +0900 To: Alexandru Petrescu From: mase Subject: Re: [Autoconf] comments to autoconf PS In-Reply-To: <4754E02D.2030906@gmail.com> References: <7.0.0.16.2.20071202181233.04971348@ie.niigata-u.ac.jp> <62022ED1-47D5-4704-AC53-01738CD75027@gmail.com> <7.0.0.16.2.20071204130327.0473d858@ie.niigata-u.ac.jp> <4754E02D.2030906@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 Alex, At 14:05 07/12/04, Alexandru Petrescu wrote: >Hi Kenichi, > >mase wrote: >[...] >>>>With regard to the definition of MANET-local address, I am also >>>>not satisfied with the current definition. My proposal is as >>>>follows: MANET-local address an address having MANET-only scope >>>>that can be used to reach destinations in the MANET. All MANET >>>>interfaces have a MANET-local unicast address. >>>I was asking what is the MANET-local scope? :-) How can you map >>>this manet-local into the current IPv6 scoping? Do you suggest to >>>define new address scope for MANET-local? >>MANET is a routing domain containing MANET routers, as defined in >>manetarch document. MANET-local sope is thus same as the set of MANET >> routers in a MANET. > >Along this line: because the LL-MANET-Routers address (ff02::tbd4) has >link-local multicast scope (draft-ietf-manet-iana), can we say that >MANET-local scope is actually the IPv6 link-local scope? No. not all MANET routers are neighbors to each other. LL-MANET-Routers address is used only to reach neighbors. Kenichi >>Whether to define a new address scope for addresses of MANET-local >>scope is another issue. We may define a new address scope for >>MANET-local or use unique-local address. This is one of the problems, >>which shold be clearly described in the PS draft. > >Right... that's a question. > >>>>What is MANET is given in the manetarch document, so I think that >>>> the above definition is clear. In reality, I think that we may >>>>use unique local IPv6 unicast address for MANET-local address. >>>The use of ULA is fine, but I expect this document help >>>understanding the possible issues when using ULA. And I want to see >>>the reason why you call this as manet-local. What is the difference >>>between ULA and manet-local? This is really confusing... >>IMHO, MANET scope and address scope to be used for MANET scope is >>different issue. ULA can be used for addresses of MANET scope, but >>ULA can be also used for another scope such as sites. > >I understand by 'scope' the scope of an address, as per the IPv6 >Addressing Architecture RFC. > >Terminology... :-) > >Alex > > >______________________________________________________________________ >This email has been scanned by the MessageLabs Email Security System. >For more information please visit http://www.messagelabs.com/email >______________________________________________________________________ > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Dec 04 00:38:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzQU3-0001dI-9L; Tue, 04 Dec 2007 00:38:15 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IzQU1-0001ax-9m for autoconf-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 00:38:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzQU0-0001aE-MX for autoconf@ietf.org; Tue, 04 Dec 2007 00:38:12 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IzQU0-0005Nr-7V for autoconf@ietf.org; Tue, 04 Dec 2007 00:38:12 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-4.tower-128.messagelabs.com!1196746690!23544203!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 32059 invoked from network); 4 Dec 2007 05:38:11 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-4.tower-128.messagelabs.com with SMTP; 4 Dec 2007 05:38:11 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lB45c7Cp012049; Mon, 3 Dec 2007 22:38:10 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id lB45c71S006751; Mon, 3 Dec 2007 23:38:07 -0600 (CST) Received: from [127.0.0.1] (mvp-10-19-252-26.corp.mot.com [10.19.252.26]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id lB45c6ZR006739; Mon, 3 Dec 2007 23:38:06 -0600 (CST) Message-ID: <4754E7BD.3010803@gmail.com> Date: Tue, 04 Dec 2007 06:38:05 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: mase Subject: Re: [Autoconf] comments to autoconf PS References: <7.0.0.16.2.20071202181233.04971348@ie.niigata-u.ac.jp> <62022ED1-47D5-4704-AC53-01738CD75027@gmail.com> <7.0.0.16.2.20071204130327.0473d858@ie.niigata-u.ac.jp> <4754E02D.2030906@gmail.com> <7.0.0.16.2.20071204141715.047a72d0@ie.niigata-u.ac.jp> In-Reply-To: <7.0.0.16.2.20071204141715.047a72d0@ie.niigata-u.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071203-0, 03/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 mase wrote: > Hi Alex, > > At 14:05 07/12/04, Alexandru Petrescu wrote: >> Hi Kenichi, >> >> mase wrote: >> [...] >>>>> With regard to the definition of MANET-local address, I am also >>>>> not satisfied with the current definition. My proposal is as >>>>> follows: MANET-local address an address having MANET-only scope >>>>> that can be used to reach destinations in the MANET. All MANET >>>>> interfaces have a MANET-local unicast address. >>>> I was asking what is the MANET-local scope? :-) How can you map >>>> this manet-local into the current IPv6 scoping? Do you suggest to >>>> define new address scope for MANET-local? >>> MANET is a routing domain containing MANET routers, as defined in >>> manetarch document. MANET-local sope is thus same as the set of MANET >>> routers in a MANET. >> >> Along this line: because the LL-MANET-Routers address (ff02::tbd4) has >> link-local multicast scope (draft-ietf-manet-iana), can we say that >> MANET-local scope is actually the IPv6 link-local scope? > > No. not all MANET routers are neighbors to each other. LL-MANET-Routers > address is used only to reach neighbors. So MANET Routers which are not part of the LL-MANET-Routers scope (link-local scope) are part of another scope. Which scope? Is this the MANET-local scope? I think we may need to find another term for the "-local" part because it too easily leads to think it's the link-local scope, especially because of the LL-MANET-Routers address having the link-local scope. Or maybe we want to suggest "MANET-local" scope to be a new scope suggested to the IPv6 Addressing Architecture RFC? Sounds complicated :-) to me. I don't know what you think. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Dec 04 00:46:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzQbZ-0001Ip-Fr; Tue, 04 Dec 2007 00:46:01 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IzQbW-0001IX-L5 for autoconf-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 00:45:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzQbW-0001IL-BT for autoconf@ietf.org; Tue, 04 Dec 2007 00:45:58 -0500 Received: from ccmail.cc.niigata-u.ac.jp ([133.35.23.1] helo=mxav01.cc.niigata-u.ac.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzQbU-0005qn-4F for autoconf@ietf.org; Tue, 04 Dec 2007 00:45:58 -0500 Received: from mxav01.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0E7FB4F5BE7 for ; Tue, 4 Dec 2007 14:45:55 +0900 (JST) Received: from mxav01.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by mxav01.cc.niigata-u.ac.jp (Postfix) with SMTP id F100F4F5A79 for ; Tue, 4 Dec 2007 14:45:54 +0900 (JST) Received: (qmail 12591 invoked from network); 4 Dec 2007 14:45:54 +0900 Received: from unknown (HELO chamame.ie.niigata-u.ac.jp) (133.35.169.34) by mxav01.cc.niigata-u.ac.jp with SMTP; 4 Dec 2007 14:45:54 +0900 Received: (qmail 25084 invoked from network); 4 Dec 2007 14:45:54 +0900 Received: from unknown (HELO neccomputer.ie.niigata-u.ac.jp) (133.35.156.66) by chamame.ie.niigata-u.ac.jp with SMTP; 4 Dec 2007 14:45:54 +0900 Message-Id: <7.0.0.16.2.20071204143038.047a72d0@ie.niigata-u.ac.jp> X-Mailer: QUALCOMM Windows Eudora Version 7J rev1.0 Date: Tue, 04 Dec 2007 14:46:02 +0900 To: Alexandru Petrescu From: mase In-Reply-To: <4754E18D.3080302@gmail.com> References: <7.0.0.16.2.20071202181233.04971348@ie.niigata-u.ac.jp> <475323CF.4080604@gmail.com> <7.0.0.16.2.20071203115230.04bda790@ie.niigata-u.ac.jp> <002301c8355e$639a3e70$2acebb50$@nl> <7.0.0.16.2.20071203125837.049dbf18@ie.niigata-u.ac.jp> <4754AB65.2090800@gmail.com> <7.0.0.16.2.20071204134958.0476dac8@ie.niigata-u.ac.jp> <4754E18D.3080302@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: autoconf@ietf.org Subject: [Autoconf] Re: movement scenario 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 Alex, At 14:11 07/12/04, Alexandru Petrescu wrote: >mase wrote: >>Hi, >>At 10:20 07/12/04, Alexandru Petrescu wrote: >>>mase wrote: >>>>>I want to share my thoughts on link-local addresses and MLA >>>>>with you. I think link-locals are essential to IPv6. I do not >>>>>understand why we have a discussion on this. It is to be used >>>>>for single hop communication, which is also very applicable in >>>>>MANET. >>>>Yes, but your former neighbor may be now out-of-transmission >>>>range and only communicated over multi-hop. Do you prefer to >>>>change your source/destination address from a link-local address >>>>to MLA? >>>Ha! That's right... >>>Src/dst address rewriting makes immediately think of NAT :-) >>>I think the case you describe above (former neighbor moves from a >>>link to another) deserves deep analysis. What are the mobility >>>scenarios considered? How do entities move, from where to where? >>Any mobility. We do not assume a particular mobility scenario when >>designing MANET routing protocols. > >I think that is a problem. If we don't know the landmarks, the movement >patterns, the dependencies... then it's very difficult to design >something meaningful, that fits some initial goals and requirements. > >I think people who have prototyped MANETs have always tested certain >movement scenarios. At least these could be documented. > >It's really very tough to design something that acomodates _any_ mobility... > >Besides, such thing risks of not being able to be qualified, can not be >evaluated, can not be compared. Of course, it _can_ be designed _and_ >prototyped but how would one compare it. I understand your concern. "Any mobility" may not be adequate. pedestrian ad hoc networks, vehicular ad hoc networks, ... Different ad hoc networks may have different mobility models (maximum speed, etc.). I only wanted to point out we do not assume a particular mobility model in developing autoconfiguration solutions. In general, we do not assume apriori knowledge on locations and movement of MANET routers. Kenichi >Alex > >>>After a node moves from one subnet to another: does it keep its >>>address? Does it keep both its address _and_ its prefix? When it >>> keeps its address - nobody else on the previous link can use that >>> address on that previous link? >>Yes, in the same MANET. We thus need to define MANET-local address. >>Kenichi >> >>>Despite the apparent complexity of describing this, I think it's >>>not so difficult - as long as two or more people have encountered >>>the same movement scenario. >>>Alex >>> >>>______________________________________________________________________ >>> This email has been scanned by the MessageLabs Email Security >>>System. For more information please visit >>>http://www.messagelabs.com/email >>>______________________________________________________________________ >> > > >______________________________________________________________________ >This email has been scanned by the MessageLabs Email Security System. >For more information please visit >http://www.messagelabs.com/email >______________________________________________________________________ > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Dec 04 01:52:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzRdh-000858-Qb; Tue, 04 Dec 2007 01:52:17 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IzRdh-00084e-DO for autoconf-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 01:52:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzRdh-00084L-0v for autoconf@ietf.org; Tue, 04 Dec 2007 01:52:17 -0500 Received: from ccmail.cc.niigata-u.ac.jp ([133.35.23.1] helo=mxav01.cc.niigata-u.ac.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzRde-0001CW-18 for autoconf@ietf.org; Tue, 04 Dec 2007 01:52:16 -0500 Received: from mxav01.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 753F84F488C for ; Tue, 4 Dec 2007 15:52:12 +0900 (JST) Received: from mxav01.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by mxav01.cc.niigata-u.ac.jp (Postfix) with SMTP id 6193B4F4754 for ; Tue, 4 Dec 2007 15:52:12 +0900 (JST) Received: (qmail 21986 invoked from network); 4 Dec 2007 15:52:12 +0900 Received: from unknown (HELO chamame.ie.niigata-u.ac.jp) (133.35.169.34) by mxav01.cc.niigata-u.ac.jp with SMTP; 4 Dec 2007 15:52:12 +0900 Received: (qmail 27734 invoked from network); 4 Dec 2007 15:52:12 +0900 Received: from unknown (HELO neccomputer.ie.niigata-u.ac.jp) (133.35.156.66) by chamame.ie.niigata-u.ac.jp with SMTP; 4 Dec 2007 15:52:12 +0900 Message-Id: <7.0.0.16.2.20071204144651.047b1b40@ie.niigata-u.ac.jp> X-Mailer: QUALCOMM Windows Eudora Version 7J rev1.0 Date: Tue, 04 Dec 2007 15:52:18 +0900 To: Alexandru Petrescu From: mase Subject: Re: [Autoconf] comments to autoconf PS In-Reply-To: <4754E7BD.3010803@gmail.com> References: <7.0.0.16.2.20071202181233.04971348@ie.niigata-u.ac.jp> <62022ED1-47D5-4704-AC53-01738CD75027@gmail.com> <7.0.0.16.2.20071204130327.0473d858@ie.niigata-u.ac.jp> <4754E02D.2030906@gmail.com> <7.0.0.16.2.20071204141715.047a72d0@ie.niigata-u.ac.jp> <4754E7BD.3010803@gmail.com> Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a 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: , Content-Type: multipart/mixed; boundary="===============1365311762==" Errors-To: autoconf-bounces@ietf.org --===============1365311762== Content-Type: multipart/alternative; boundary="=====================_15525843==.ALT" --=====================_15525843==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit At 14:38 07/12/04, Alexandru Petrescu wrote: >mase wrote: >>Hi Alex, >>At 14:05 07/12/04, Alexandru Petrescu wrote: >>>Hi Kenichi, >>> >>>mase wrote: >>>[...] >>>>>>With regard to the definition of MANET-local address, I am also >>>>>>not satisfied with the current definition. My proposal is as >>>>>>follows: MANET-local address an address having MANET-only scope >>>>>>that can be used to reach destinations in the MANET. All MANET >>>>>>interfaces have a MANET-local unicast address. >>>>>I was asking what is the MANET-local scope? :-) How can you map >>>>>this manet-local into the current IPv6 scoping? Do you suggest to >>>>>define new address scope for MANET-local? >>>>MANET is a routing domain containing MANET routers, as defined in >>>>manetarch document. MANET-local sope is thus same as the set of MANET >>>> routers in a MANET. >>> >>>Along this line: because the LL-MANET-Routers address (ff02::tbd4) has >>>link-local multicast scope (draft-ietf-manet-iana), can we say that >>>MANET-local scope is actually the IPv6 link-local scope? >>No. not all MANET routers are neighbors to each other. >>LL-MANET-Routers address is used only to reach neighbors. > >So MANET Routers which are not part of the LL-MANET-Routers scope >(link-local scope) are part of another scope. Which scope? Is this >the MANET-local scope? Right. >I think we may need to find another term for the "-local" part >because it too easily leads to think it's the link-local scope, >especially because of the LL-MANET-Routers address having the link-local scope. > >Or maybe we want to suggest "MANET-local" scope to be a new scope >suggested to the IPv6 Addressing Architecture RFC? Sounds complicated :-) to me. > >I don't know what you think. According to RFC4862, link-local address - an address having link-only scope that can be used to reach neighboring nodes attached to the same link. All interfaces have a link-local unicast address. Here the term link-only scope is used. Similarly, MANET-local address and MANET-only scope can be meaningful, since a definition of MANET is given in the manetarch document. Kenichi >Alex > > >______________________________________________________________________ >This email has been scanned by the MessageLabs Email Security System. >For more information please visit http://www.messagelabs.com/email >______________________________________________________________________ > --=====================_15525843==.ALT Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
At 14:38 07/12/04, Alexandru Petrescu wrote:
mase wrote:
Hi Alex,
At 14:05 07/12/04, Alexandru Petrescu wrote:
Hi Kenichi,

mase wrote:
[...]
With regard to the definition of MANET-local address, I am also
not satisfied with the current definition. My proposal is as
follows: MANET-local address   an address having MANET-only scope
that can be used to reach destinations in the MANET. All MANET
interfaces have a MANET-local unicast address.
I was asking what is the MANET-local scope? :-) How can you map
this manet-local into the current IPv6 scoping? Do you suggest to
define new address scope for MANET-local?
MANET is a routing domain containing MANET routers, as defined in manetarch document. MANET-local sope is thus same as the set of MANET
 routers in a MANET.

Along this line: because the LL-MANET-Routers address (ff02::tbd4) has
link-local multicast scope (draft-ietf-manet-iana), can we say that
MANET-local scope is actually the IPv6 link-local scope?
No. not all MANET routers are neighbors to each other. LL-MANET-Routers address is used only to reach neighbors.

So MANET Routers which are not part of the LL-MANET-Routers scope (link-local scope) are part of another scope.  Which scope?  Is this the MANET-local scope?

Right.


I think we may need to find another term for the "-local" part because it too easily leads to think it's the link-local scope, especially because of the LL-MANET-Routers address having the link-local scope.

Or maybe we want to suggest "MANET-local" scope to be a new scope suggested to the IPv6 Addressing Architecture RFC?  Sounds complicated :-) to me.

I don't know what you think.

According to RFC4862, 
link-local address -  an address having link-only scope that
can be
      used to reach neighboring nodes attached
to the same link.  All
      interfaces have a link-local unicast
address.

Here the term link-only scope is used. Similarly, MANET-local address and
MANET-only scope can be meaningful, since a definition of MANET is given
in the manetarch document.

Kenichi
Alex


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

--=====================_15525843==.ALT-- --===============1365311762== 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 --===============1365311762==-- From autoconf-bounces@ietf.org Tue Dec 04 08:44:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzY4D-0004Lp-Jq; Tue, 04 Dec 2007 08:44:05 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IzY4B-0004Dw-Ta for autoconf-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 08:44:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzY4B-0004B7-E5 for autoconf@ietf.org; Tue, 04 Dec 2007 08:44:03 -0500 Received: from e1.ny.us.ibm.com ([32.97.182.141]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzY4A-0003eN-Dh for autoconf@ietf.org; Tue, 04 Dec 2007 08:44:03 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id lB4Di1ts002982 for ; Tue, 4 Dec 2007 08:44:01 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id lB4Di1S0484942 for ; Tue, 4 Dec 2007 08:44:01 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id lB4Di1Wf021984 for ; Tue, 4 Dec 2007 08:44:01 -0500 Received: from cichlid.raleigh.ibm.com (wecm-9-67-194-205.wecm.ibm.com [9.67.194.205]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id lB4Di0oY021850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Dec 2007 08:44:00 -0500 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.1/8.12.5) with ESMTP id lB4Dhwq5006349 for ; Tue, 4 Dec 2007 08:43:58 -0500 Message-Id: <200712041343.lB4Dhwq5006349@cichlid.raleigh.ibm.com> To: autoconf@ietf.org Date: Tue, 04 Dec 2007 08:43:58 -0500 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Subject: [Autoconf] comments on draft-ietf-autoconf-manetarch-07.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 2007-11-30 review of -7 Overall. I still do not think this document is ready for publication. It is still to vague/muddy on the key architectural points that it is supposed to explain. My major concern is that you still do not lay out an understandable "architecture" that allows one to understand what an IP subnet would look like in MANETs. Interface terminology is non-standard and confusing. Should use "link type". Really. If you want the rest of the community to be able to understand this stuff, you cannot redefine terminology that is already widely in use and understood to mean something different than who it is used in this document. Neighbor In the context of routing, two routers are neighbors if one can send/receive routing protocol IP packets to the other without passing through any intermediaries at the same layer. Why "router"? Definition of neighbor from from 2460 should be used instead: neighbors - nodes attached to the same link. Why (or why isn't) the RFC2460 definition sufficient? Interface A node's point of attachment to a communication link. This is mostly fine as written, but... Semi-Broadcast Interface (SBI) A broadcast capable interface that may exhibit asymmetric reachability. Multiple access wireless radio interfaces are often SBI. Note that since a SBI *may* exhibit asymmetric reachability, it also may not. Call it a "link" not an "interface". Manets provide IP with a conceptual link, that has certain properties. What I thought the MANET architecture would provide is a description of the properties of that link type. MANET Interface A MANET interface is distinguished by its potentially significant time-varying asymmetric reachability (e.g., SBI) amongst potential neighboring routers. A more detailed discussion of MANET interface characteristics is presented in Section 4.2. The addressing constraints for a MANET interface are discussed in Section 5.2. No. A MANET _link_ has these characteristics. Not the interface. Etc. MANET Router (MNR) A MANET router is distinguished by having one or more MANET interfaces. A MANET router may also have zero or more non-MANET interfaces. A MANET router is responsible for hiding MANETs' challenging characteristics from nodes that are not MANET-aware. A MANET router with a single MANET interface is illustrated in Figure 1. No. the "interface/link" hides the challenging characteristics from IP. Not the BR itself. This is a critical point (architecturally) to get right. You really (I think) need to define an abstraction that defines an link type of "manet" that handles all the "interesting" characteristics of MANETs (like non-transitive connectivity) but that also presents itself to IP as a single IP subnet that has the normal properties. MANET Neighborhood a set of neighboring routers that can communicate via MANET interfaces without passing through any other routers (intermediaries at the same layer). If A can reach B, B can reach C, but A cannot reach C, are A&C in the same neighborhood? from the wording, I think the answer is no, per the definition of "neighbor". Do I understand that correctly? MANET a routing domain containing MANET routers. A example MANET is illustrated in Figure 3. This is too vague (i.e, it's a meangless definition). If I have two manet routers connected to each other, plus 100 ethernet links connected by routers, is the entire set considered to be part the "MANET"? receive the packet from PR1 on its interface and determine that it must retransmit the packet over the same interface as the one where the packet was received, in order for the packet to reach PR3. From s/retransmit/forward/ Wireless interfaces often exhibit more challenging characteristics when compared to wired interfaces. Many protocols (e.g., IPv6 neighbor discovery [RFC4861]) were not designed to operate in wireless networks with asymmetric reachability. Wireless interfaces may also exhibit very dynamic time varying performance (e.g., packet loss, data rate), and the factors have a significant impact on local communication. Be more precise. ND assumes a standard IP subnet model that all nodes on the same subnet are neighbors. Also, it is wrong to say "wireless vs. wired". What you really mean is that the link characteristics of things like typical ethernet differ from the link characteristics of other technologies. The challenge for MANETs is to figure out how to work around that assumption. Ad hoc networking further compounds problems by allowing nodes to join and leave the network, or even form new networks, at will. Do you mean "links"? or "subnets"? Saying "network" is vague. 4.2. Challenges MANET characteristics result in many challenges. These challenges reveal themselves in many forms, and MANET specific protocols must often be developed. I don't like this wording. what is unclear here is _what_ protocols will need to do this, and to what degree these are MANET-specific (hidden under an abstraction of an interface looking like a normal IP subnet, with emulation underneath to deal with the manet challenges) or something else. In MANETs' with SBI, MANET routers within the same small geographic region are often densely connected with other nearby MANET routers. These routers form a set of extended neighbor relationships. This set is referred to as a MANET neighborhood. A MANET neighborhood is typically composed of several MANET routers, with each MANET router being densely connected to other MANET routers. Shouldn't this be in the defintion section? logical. For example, in an Ethernet network nodes are often told that a particular range of addresses are "on-link". In MANETs' a MANET router often cannot make assumptions that a particular set of MANET routers is always (directly) reachable. Instead, MANET routers must detect and determine neighboring MANET routers, and handle changes to this set over time. Again, I find the term "MR" vague here. The issues here have to do with MANET-specific things, and refer only to the MANET links. Yet, the MR definition is broader, and simply says "a router with at least one interface to a MANET". I would expect section 5.2 to clarify what the basic MANET subnet model is. But it does not. Unique Prefixes MANET interfaces that are known to exhibit the above mentioned properties must be configured with unique prefixes. The reason for this requirements is so that no two MANET interfaces are configured to appear within the same IP prefix. One way to achieve this is /128 (IPv6) or /32 (IPv4) prefixes. It is worth noting that prefix lengths shorter than /128 (IPv6) or /32 (IPv4) are possible on the MANET interfaces, as long as the prefixes are unique to a single MANET interface. Note that the above statements are not an exception, but simply a clarification that MANET are no different from other networks in this respect. Don't understand this. More specifically: MANET interfaces that are known to exhibit the above mentioned properties must be configured with unique prefixes. The reason for this requirements is so that no two MANET interfaces are configured to appear within the same IP prefix. Why? Is this a requirement specific to MANETs, or is this a more general requirement? One way to achieve this is /128 (IPv6) or /32 (IPv4) prefixes. It is worth noting that prefix lengths shorter than /128 (IPv6) or /32 (IPv4) Sorry, but a /128 or /32 is an address, not a prefix (practically speaking). If you really mean "an address", why don't you say so. are possible on the MANET interfaces, as long as the prefixes are unique to a single MANET interface. Note that the above statements are not an exception, but simply a clarification that MANET are no different from other networks in this respect. If this is really a standard requirement of IP, I still don't get what issue you are trying to raise or why you are point this out. Link-local Multicast/Broadcast Scope On a MANET interface, a packet sent to a link-local multicast or all-ones broadcast address reaches the MANET interfaces of neighboring MANET routers, regardless of their configured addresses. Link-local multicast/broadcast packets are never forwarded and since a MANET may span several hops, nodes cannot assume that a packet sent to a link-local multicast/broadcast address will reach all routers within a MANET. Sorry, this is bogus. "link-local multicast" is defined by IP and means that a packet sent to that address is delivered to all nodes on the "link". This latter part, that says "never forwarded" does not make sense. They are never forwarded beyond the link, but they may be forwarded by MRs (your terminology) if required by the "link model". You cannot just say that multicast doesn't work in MANETS, and then imply protocols at the IP layer need to take that into account. That would be changing the basic IP model. Thomas _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Dec 04 11:55:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izb3f-0006CW-Rd; Tue, 04 Dec 2007 11:55:43 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Izb3f-0006Ag-6v for autoconf-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 11:55:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izb3e-00066w-Pv for autoconf@ietf.org; Tue, 04 Dec 2007 11:55:42 -0500 Received: from server9.hosting2go.nl ([83.137.192.232]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Izb3d-0001lO-MV for autoconf@ietf.org; Tue, 04 Dec 2007 11:55:42 -0500 Received: (qmail 14441 invoked from network); 4 Dec 2007 17:55:39 +0100 Received: from unknown (HELO M90Teco) (130.129.82.92) by server9.hosting2go.nl with SMTP; 4 Dec 2007 17:55:39 +0100 From: "Teco Boot" To: "'Thomas Narten'" , References: <200712041343.lB4Dhwq5006349@cichlid.raleigh.ibm.com> In-Reply-To: <200712041343.lB4Dhwq5006349@cichlid.raleigh.ibm.com> Subject: RE: [Autoconf] comments on draft-ietf-autoconf-manetarch-07.txt Date: Tue, 4 Dec 2007 17:55:04 +0100 Message-ID: <009501c83696$7e9753a0$7bc5fae0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg2e/nOtIBRwU+xQ6uuLQWg5th/fwACoTZA Content-Language: nl X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 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 Some comments inline. > -----Oorspronkelijk bericht----- > Van: Thomas Narten [mailto:narten@us.ibm.com] > Verzonden: dinsdag 4 december 2007 14:44 > Aan: autoconf@ietf.org > Onderwerp: [Autoconf] comments on draft-ietf-autoconf-manetarch-07.txt > > 2007-11-30 review of -7 > > Overall. I still do not think this document is ready for > publication. It is still to vague/muddy on the key architectural > points that it is supposed to explain. > > My major concern is that you still do not lay out an understandable > "architecture" that allows one to understand what an IP subnet would > look like in MANETs. > > Interface terminology is non-standard and confusing. Should use "link > type". Really. If you want the rest of the community to be able to > understand this stuff, you cannot redefine terminology that is already > widely in use and understood to mean something different than who it > is used in this document. Maybe better definition could help. I think it is easy to understand that a MANET Interface is an interface that may suffer from certain link characteristics. We have similar kind of interface types, like NBMA and P2MP. Now we want to define another. Term MANET Interface is well known, e.g. it is used in MANET Routing Protocol documents, including the OSPF ones. Maybe term Semi-Broadcast Interface (SBI) should be removed, this is about the link characteristics. Hint for editer: Change SBI into MANET and some textual cleanup will do. > Interface > A node's point of attachment to a communication link. > > This is mostly fine as written, but... > > Semi-Broadcast Interface (SBI) > A broadcast capable interface that may exhibit asymmetric > reachability. Multiple access wireless radio interfaces are > often > SBI. Note that since a SBI *may* exhibit asymmetric > reachability, > it also may not. > > Call it a "link" not an "interface". > > Manets provide IP with a conceptual link, that has certain > properties. What I thought the MANET architecture would provide is a > description of the properties of that link type. > > MANET Interface > A MANET interface is distinguished by its potentially significant > time-varying asymmetric reachability (e.g., SBI) amongst > potential > neighboring routers. A more detailed discussion of MANET > interface characteristics is presented in Section 4.2. The > addressing constraints for a MANET interface are discussed in > Section 5.2. > > No. A MANET _link_ has these characteristics. Not the interface. > > Etc. > > MANET Router (MNR) > A MANET router is distinguished by having one or more MANET > interfaces. A MANET router may also have zero or more non-MANET > interfaces. A MANET router is responsible for hiding MANETs' > challenging characteristics from nodes that are not MANET-aware. > A MANET router with a single MANET interface is illustrated in > Figure 1. > > No. the "interface/link" hides the challenging characteristics from > IP. Not the BR itself. This is a critical point (architecturally) to > get right. > If this is true, we do not have to do anything special. > You really (I think) need to define an abstraction that defines an > link type of "manet" that handles all the "interesting" > characteristics of MANETs (like non-transitive connectivity) but that > also presents itself to IP as a single IP subnet that has the normal > properties. I think there are two MANET implementation models. One is hiding MANET form IP, e.g. a sub-IP MANET model. This is more or less out-of-scope for IETF. The other model is described in this document. Now we have to face the reachability issues. I think the MANET Router shall hide this for IP hosts and non-MANET routers. If this is arranged by using a single IP subnet or using another addressing model is solution space. There might be a discussion on supporting connectivity to (mobile) hosts via the MANET Interface. I will post on this separately. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Dec 04 12:08:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzbFz-0004Ey-65; Tue, 04 Dec 2007 12:08:27 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IzbFy-0004EX-IT for autoconf-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 12:08:26 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzbFy-0004Dj-5o for autoconf@ietf.org; Tue, 04 Dec 2007 12:08:26 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzbFw-0003DE-VX for autoconf@ietf.org; Tue, 04 Dec 2007 12:08:26 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id lB4H8MsP020997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Dec 2007 09:08:22 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id lB4H8LIo025112; Tue, 4 Dec 2007 09:08:21 -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.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id lB4H7IGn022521; Tue, 4 Dec 2007 09:07:27 -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, 4 Dec 2007 09:07:23 -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] comments on draft-ietf-autoconf-manetarch-07.txt Date: Tue, 4 Dec 2007 09:06:51 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029EDC7D@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <200712041343.lB4Dhwq5006349@cichlid.raleigh.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] comments on draft-ietf-autoconf-manetarch-07.txt Thread-Index: Acg2e799r5JU+w/zRNKoAiiJ4U7ujAAG+6hQ References: <200712041343.lB4Dhwq5006349@cichlid.raleigh.ibm.com> From: "Templin, Fred L" To: "Thomas Narten" , X-OriginalArrivalTime: 04 Dec 2007 17:07:23.0132 (UTC) FILETIME=[23113BC0:01C83698] X-Spam-Score: 0.0 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 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 > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com]=20 > Sent: Tuesday, December 04, 2007 5:44 AM > To: autoconf@ietf.org > Subject: [Autoconf] comments on draft-ietf-autoconf-manetarch-07.txt >=20 > 2007-11-30 review of -7 >=20 > Overall. I still do not think this document is ready for > publication. It is still to vague/muddy on the key architectural > points that it is supposed to explain. >=20 > My major concern is that you still do not lay out an understandable > "architecture" that allows one to understand what an IP subnet would > look like in MANETs. >=20 > Interface terminology is non-standard and confusing. Should use "link > type". Really. If you want the rest of the community to be able to > understand this stuff, you cannot redefine terminology that is already > widely in use and understood to mean something different than who it > is used in this document. I agree with Thomas, and I believe also confirmed by Teco. IMHO, this is an INT area document (not RTG) and it needs to speak to the terminology of the INT area. Thanks - Fred fred.l.templin@boeing.com =20 >=20 > Neighbor > In the context of routing, two routers are neighbors if one can > send/receive routing protocol IP packets to the other without > passing through any intermediaries at the same layer. >=20 > Why "router"? Definition of neighbor from from 2460 should be used > instead: >=20 > neighbors - nodes attached to the same link. >=20 > Why (or why isn't) the RFC2460 definition sufficient? >=20 > Interface > A node's point of attachment to a communication link. >=20 > This is mostly fine as written, but... >=20 > Semi-Broadcast Interface (SBI) > A broadcast capable interface that may exhibit asymmetric > reachability. Multiple access wireless radio=20 > interfaces are often > SBI. Note that since a SBI *may* exhibit asymmetric=20 > reachability, > it also may not. >=20 > Call it a "link" not an "interface". >=20 > Manets provide IP with a conceptual link, that has certain > properties. What I thought the MANET architecture would provide is a > description of the properties of that link type. >=20 > MANET Interface > A MANET interface is distinguished by its potentially=20 > significant > time-varying asymmetric reachability (e.g., SBI)=20 > amongst potential > neighboring routers. A more detailed discussion of MANET > interface characteristics is presented in Section 4.2. The > addressing constraints for a MANET interface are discussed in > Section 5.2. >=20 > No. A MANET _link_ has these characteristics. Not the interface. >=20 > Etc. >=20 > MANET Router (MNR) > A MANET router is distinguished by having one or more MANET > interfaces. A MANET router may also have zero or more non-MANET > interfaces. A MANET router is responsible for hiding MANETs' > challenging characteristics from nodes that are not MANET-aware. > A MANET router with a single MANET interface is illustrated in > Figure 1. >=20 > No. the "interface/link" hides the challenging characteristics from > IP. Not the BR itself. This is a critical point (architecturally) to > get right. >=20 > You really (I think) need to define an abstraction that defines an > link type of "manet" that handles all the "interesting" > characteristics of MANETs (like non-transitive connectivity) but that > also presents itself to IP as a single IP subnet that has the normal > properties. >=20 > MANET Neighborhood > a set of neighboring routers that can communicate via MANET > interfaces without passing through any other routers > (intermediaries at the same layer). >=20 > If A can reach B, B can reach C, but A cannot reach C, are A&C in the > same neighborhood? from the wording, I think the answer is no, per the > definition of "neighbor". Do I understand that correctly?=20 >=20 > MANET > a routing domain containing MANET routers. A example MANET is > illustrated in Figure 3. >=20 > This is too vague (i.e, it's a meangless definition). If I have two > manet routers connected to each other, plus 100 ethernet links > connected by routers, is the entire set considered to be part the > "MANET"? >=20 > receive the packet from PR1 on its interface and determine that it > must retransmit the packet over the same interface as the one where > the packet was received, in order for the packet to reach=20 > PR3. From >=20 > s/retransmit/forward/ >=20 > Wireless interfaces often exhibit more challenging characteristics > when compared to wired interfaces. Many protocols (e.g., IPv6 > neighbor discovery [RFC4861]) were not designed to operate in > wireless networks with asymmetric reachability. Wireless=20 > interfaces > may also exhibit very dynamic time varying performance=20 > (e.g., packet > loss, data rate), and the factors have a significant=20 > impact on local > communication. >=20 >=20 > Be more precise. ND assumes a standard IP subnet model that all nodes > on the same subnet are neighbors. >=20 > Also, it is wrong to say "wireless vs. wired". What you really mean is > that the link characteristics of things like typical ethernet differ > from the link characteristics of other technologies. >=20 > The challenge for MANETs is to figure out how to work around that > assumption. >=20 > Ad hoc networking further compounds problems by allowing nodes to > join and leave the network, or even form new networks, at will. >=20 > Do you mean "links"? or "subnets"? Saying "network" is vague. >=20 > 4.2. Challenges >=20 > MANET characteristics result in many challenges. These challenges > reveal themselves in many forms, and MANET specific protocols must > often be developed. >=20 > I don't like this wording. what is unclear here is _what_ protocols > will need to do this, and to what degree these are MANET-specific > (hidden under an abstraction of an interface looking like a normal IP > subnet, with emulation underneath to deal with the manet challenges) > or something else. >=20 > In MANETs' with SBI, MANET routers within the same small geographic > region are often densely connected with other nearby MANET routers. > These routers form a set of extended neighbor relationships. This > set is referred to as a MANET neighborhood. A MANET=20 > neighborhood is > typically composed of several MANET routers, with each MANET router > being densely connected to other MANET routers. >=20 > Shouldn't this be in the defintion section? >=20 > logical. For example, in an Ethernet network nodes are often told > that a particular range of addresses are "on-link". In MANETs' a > MANET router often cannot make assumptions that a particular set of > MANET routers is always (directly) reachable. Instead,=20 > MANET routers > must detect and determine neighboring MANET routers, and handle > changes to this set over time. >=20 > Again, I find the term "MR" vague here. The issues here have to do > with MANET-specific things, and refer only to the MANET links. Yet, > the MR definition is broader, and simply says "a router with at least > one interface to a MANET". >=20 > I would expect section 5.2 to clarify what the basic MANET subnet > model is. But it does not. >=20 > Unique Prefixes > MANET interfaces that are known to exhibit the above mentioned > properties must be configured with unique prefixes. The reason > for this requirements is so that no two MANET interfaces are > configured to appear within the same IP prefix. One way to > achieve this is /128 (IPv6) or /32 (IPv4) prefixes. It is worth > noting that prefix lengths shorter than /128 (IPv6) or=20 > /32 (IPv4) > are possible on the MANET interfaces, as long as the=20 > prefixes are > unique to a single MANET interface. Note that the above > statements are not an exception, but simply a clarification that > MANET are no different from other networks in this respect. >=20 >=20 > Don't understand this. More specifically: >=20 > MANET interfaces that are known to exhibit the above mentioned > properties must be configured with unique prefixes. The reason > for this requirements is so that no two MANET interfaces are > configured to appear within the same IP prefix. >=20 > Why? Is this a requirement specific to MANETs, or is this a more > general requirement? >=20 > One way to > achieve this is /128 (IPv6) or /32 (IPv4) prefixes. It is worth > noting that prefix lengths shorter than /128 (IPv6) or /32 > (IPv4) >=20 > Sorry, but a /128 or /32 is an address, not a prefix (practically > speaking). If you really mean "an address", why don't you say so.=20 > =20 > are possible on the MANET interfaces, as long as the=20 > prefixes are > unique to a single MANET interface. Note that the above > statements are not an exception, but simply a clarification that > MANET are no different from other networks in this respect. >=20 > If this is really a standard requirement of IP, I still don't get what > issue you are trying to raise or why you are point this out. =20 >=20 > Link-local Multicast/Broadcast Scope > On a MANET interface, a packet sent to a link-local multicast or > all-ones broadcast address reaches the MANET interfaces of > neighboring MANET routers, regardless of their configured > addresses. Link-local multicast/broadcast packets are never > forwarded and since a MANET may span several hops, nodes cannot > assume that a packet sent to a link-local multicast/broadcast > address will reach all routers within a MANET. >=20 > Sorry, this is bogus. "link-local multicast" is defined by IP and > means that a packet sent to that address is delivered to all nodes on > the "link". This latter part, that says "never forwarded" does not > make sense. They are never forwarded beyond the link, but they may be > forwarded by MRs (your terminology) if required by the "link > model". You cannot just say that multicast doesn't work in MANETS, and > then imply protocols at the IP layer need to take that into > account. That would be changing the basic IP model. >=20 >=20 >=20 > Thomas >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf >=20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Dec 04 12:46:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzbrD-0006kA-1V; Tue, 04 Dec 2007 12:46:55 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IzbrB-0006hY-Mh for autoconf-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 12:46:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzbrB-0006fd-8q for autoconf@ietf.org; Tue, 04 Dec 2007 12:46:53 -0500 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzbrA-0002xO-IW for autoconf@ietf.org; Tue, 04 Dec 2007 12:46:53 -0500 Received: by ug-out-1314.google.com with SMTP id u2so278044uge for ; Tue, 04 Dec 2007 09:46:51 -0800 (PST) Received: by 10.78.173.20 with SMTP id v20mr8736409hue.1196790410315; Tue, 04 Dec 2007 09:46:50 -0800 (PST) Received: by 10.78.170.19 with HTTP; Tue, 4 Dec 2007 09:46:49 -0800 (PST) Message-ID: <25c114b90712040946j47de7a71ve45b50e341ef4dc6@mail.gmail.com> Date: Tue, 4 Dec 2007 18:46:49 +0100 From: "Ulrich Herberg" To: mase Subject: Re: [Autoconf] Re: movement scenario In-Reply-To: <7.0.0.16.2.20071204143038.047a72d0@ie.niigata-u.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7.0.0.16.2.20071202181233.04971348@ie.niigata-u.ac.jp> <475323CF.4080604@gmail.com> <7.0.0.16.2.20071203115230.04bda790@ie.niigata-u.ac.jp> <002301c8355e$639a3e70$2acebb50$@nl> <7.0.0.16.2.20071203125837.049dbf18@ie.niigata-u.ac.jp> <4754AB65.2090800@gmail.com> <7.0.0.16.2.20071204134958.0476dac8@ie.niigata-u.ac.jp> <4754E18D.3080302@gmail.com> <7.0.0.16.2.20071204143038.047a72d0@ie.niigata-u.ac.jp> X-Google-Sender-Auth: 6380ee2bf78782a5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 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, I agree with Kenichi. Maybe one could mention different scenarios in the PS, but basically no particular mobility model should be considered in my opinion. For Alex's concern about comparability, I don't think this should be part of a PS (maybe more in a solution space? or something like draft-bernardos-autoconf-evaluation-considerations ?). The problem of autoconfiguration should be applicable to all mobility patterns to my understanding. Ulrich On 12/4/07, mase wrote: > Hi Alex, > > At 14:11 07/12/04, Alexandru Petrescu wrote: > >mase wrote: > >>Hi, > >>At 10:20 07/12/04, Alexandru Petrescu wrote: > >>>mase wrote: > >>>>>I want to share my thoughts on link-local addresses and MLA > >>>>>with you. I think link-locals are essential to IPv6. I do not > >>>>>understand why we have a discussion on this. It is to be used > >>>>>for single hop communication, which is also very applicable in > >>>>>MANET. > >>>>Yes, but your former neighbor may be now out-of-transmission > >>>>range and only communicated over multi-hop. Do you prefer to > >>>>change your source/destination address from a link-local address > >>>>to MLA? > >>>Ha! That's right... > >>>Src/dst address rewriting makes immediately think of NAT :-) > >>>I think the case you describe above (former neighbor moves from a > >>>link to another) deserves deep analysis. What are the mobility > >>>scenarios considered? How do entities move, from where to where? > >>Any mobility. We do not assume a particular mobility scenario when > >>designing MANET routing protocols. > > > >I think that is a problem. If we don't know the landmarks, the movement > >patterns, the dependencies... then it's very difficult to design > >something meaningful, that fits some initial goals and requirements. > > > >I think people who have prototyped MANETs have always tested certain > >movement scenarios. At least these could be documented. > > > >It's really very tough to design something that acomodates _any_ mobility... > > > >Besides, such thing risks of not being able to be qualified, can not be > >evaluated, can not be compared. Of course, it _can_ be designed _and_ > >prototyped but how would one compare it. > > I understand your concern. "Any mobility" may not be adequate. > pedestrian ad hoc networks, vehicular ad hoc networks, ... > Different ad hoc networks may have different mobility models > (maximum speed, etc.). I only wanted to point out we do not assume > a particular mobility model in developing autoconfiguration > solutions. In general, we do not assume apriori knowledge on > locations and movement of MANET routers. > > Kenichi > > > >Alex > > > >>>After a node moves from one subnet to another: does it keep its > >>>address? Does it keep both its address _and_ its prefix? When it > >>> keeps its address - nobody else on the previous link can use that > >>> address on that previous link? > >>Yes, in the same MANET. We thus need to define MANET-local address. > >>Kenichi > >> > >>>Despite the apparent complexity of describing this, I think it's > >>>not so difficult - as long as two or more people have encountered > >>>the same movement scenario. > >>>Alex > >>> > >>>______________________________________________________________________ > >>> This email has been scanned by the MessageLabs Email Security > >>>System. For more information please visit > >>>http://www.messagelabs.com/email > >>>______________________________________________________________________ > >> > > > > > >______________________________________________________________________ > >This email has been scanned by the MessageLabs Email Security System. > >For more information please visit > >http://www.messagelabs.com/email > >______________________________________________________________________ > > > > > > > _______________________________________________ > 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 Dec 04 12:47:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzbrJ-00074T-DW; Tue, 04 Dec 2007 12:47:01 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IzbrJ-00073O-4X for autoconf-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 12:47:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzbrI-00073A-QU for autoconf@ietf.org; Tue, 04 Dec 2007 12:47:00 -0500 Received: from server9.hosting2go.nl ([83.137.192.232]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzbrI-0006wQ-6Z for autoconf@ietf.org; Tue, 04 Dec 2007 12:47:00 -0500 Received: (qmail 16813 invoked from network); 4 Dec 2007 18:46:55 +0100 Received: from unknown (HELO M90Teco) (130.129.82.92) by server9.hosting2go.nl with SMTP; 4 Dec 2007 18:46:55 +0100 From: "Teco Boot" To: "'Emmanuel Baccelli'" Date: Tue, 4 Dec 2007 18:46:19 +0100 Message-ID: <009901c8369d$a7d21eb0$f7765c10$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg2nWOUOtMMbYAkTuGBZAlVjepRrQ== Content-Language: nl X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: autoconf@ietf.org Subject: [Autoconf] Remarks on PS presentation 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 Emmanual, Thanks for your presentation. I have some comments, maybe you could use it for updating the PS document. Slide 2: Please do not use MR for MANET Router. It is MNR. There are some figures in manetarch, but not one with MNR and R. I do not understand why this popped up. Slide 4: This is about a manet connected to different external networks. Is this in-scope? It is not in manetarch or charter. I suggest stick on Connected MANET and Standalone MANET. Why using new term (subordinate)? Slide 5: Why using new term (autonomous)? Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Dec 04 13:11:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcEp-0001P7-0A; Tue, 04 Dec 2007 13:11:19 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IzcEm-0001Ov-Tp for autoconf-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 13:11:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcEm-0001Oa-H5 for autoconf@ietf.org; Tue, 04 Dec 2007 13:11:16 -0500 Received: from sniper.icu.ac.kr ([210.107.128.51]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzcEl-0000r4-Hb for autoconf@ietf.org; Tue, 04 Dec 2007 13:11:16 -0500 Received: (snipe 20454 invoked by uid 0); 5 Dec 2007 03:11:41 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 1.257349 secs); Received: from unknown (HELO ?130.129.52.100?) (Z???own@130.129.52.100) by unknown with SMTP; 5 Dec 2007 03:11:40 +0900 X-SNIPER-SENDERIP: 130.129.52.100 X-SNIPER-MAILFROM: newcat@icu.ac.kr X-SNIPER-RCPTTO: ulrich.herberg@polytechnique.edu, mase@ie.niigata-u.ac.jp, autoconf@ietf.org, yangwooko@gmail.com Message-ID: <47559847.3070206@icu.ac.kr> Date: Wed, 05 Dec 2007 03:11:19 +0900 From: Yangwoo Ko User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ulrich Herberg Subject: Re: [Autoconf] Re: movement scenario References: <7.0.0.16.2.20071202181233.04971348@ie.niigata-u.ac.jp> <475323CF.4080604@gmail.com> <7.0.0.16.2.20071203115230.04bda790@ie.niigata-u.ac.jp> <002301c8355e$639a3e70$2acebb50$@nl> <7.0.0.16.2.20071203125837.049dbf18@ie.niigata-u.ac.jp> <4754AB65.2090800@gmail.com> <7.0.0.16.2.20071204134958.0476dac8@ie.niigata-u.ac.jp> <4754E18D.3080302@gmail.com> <7.0.0.16.2.20071204143038.047a72d0@ie.niigata-u.ac.jp> <25c114b90712040946j47de7a71ve45b50e341ef4dc6@mail.gmail.com> In-Reply-To: <25c114b90712040946j47de7a71ve45b50e341ef4dc6@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 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 I got lost. Can somebody clarify how mobility affects address configurations? It is very obvious that mobility affects decisions on which solutions are better than others. But it seems only related with how dynamic the characteristics of MANET-type links are rather than with what kinds of prefixes/addresses are to be given. Ulrich Herberg wrote: > Hi, > > I agree with Kenichi. Maybe one could mention different scenarios in > the PS, but basically no particular mobility model should be > considered in my opinion. For Alex's concern about comparability, I > don't think this should be part of a PS (maybe more in a solution > space? or something like > draft-bernardos-autoconf-evaluation-considerations ?). The problem of > autoconfiguration should be applicable to all mobility patterns to my > understanding. > > Ulrich > > On 12/4/07, mase wrote: > >> Hi Alex, >> >> At 14:11 07/12/04, Alexandru Petrescu wrote: >> >>> mase wrote: >>> >>>> Hi, >>>> At 10:20 07/12/04, Alexandru Petrescu wrote: >>>> >>>>> mase wrote: >>>>> >>>>>>> I want to share my thoughts on link-local addresses and MLA >>>>>>> with you. I think link-locals are essential to IPv6. I do not >>>>>>> understand why we have a discussion on this. It is to be used >>>>>>> for single hop communication, which is also very applicable in >>>>>>> MANET. >>>>>>> >>>>>> Yes, but your former neighbor may be now out-of-transmission >>>>>> range and only communicated over multi-hop. Do you prefer to >>>>>> change your source/destination address from a link-local address >>>>>> to MLA? >>>>>> >>>>> Ha! That's right... >>>>> Src/dst address rewriting makes immediately think of NAT :-) >>>>> I think the case you describe above (former neighbor moves from a >>>>> link to another) deserves deep analysis. What are the mobility >>>>> scenarios considered? How do entities move, from where to where? >>>>> >>>> Any mobility. We do not assume a particular mobility scenario when >>>> designing MANET routing protocols. >>>> >>> I think that is a problem. If we don't know the landmarks, the movement >>> patterns, the dependencies... then it's very difficult to design >>> something meaningful, that fits some initial goals and requirements. >>> >>> I think people who have prototyped MANETs have always tested certain >>> movement scenarios. At least these could be documented. >>> >>> It's really very tough to design something that acomodates _any_ mobility... >>> >>> Besides, such thing risks of not being able to be qualified, can not be >>> evaluated, can not be compared. Of course, it _can_ be designed _and_ >>> prototyped but how would one compare it. >>> >> I understand your concern. "Any mobility" may not be adequate. >> pedestrian ad hoc networks, vehicular ad hoc networks, ... >> Different ad hoc networks may have different mobility models >> (maximum speed, etc.). I only wanted to point out we do not assume >> a particular mobility model in developing autoconfiguration >> solutions. In general, we do not assume apriori knowledge on >> locations and movement of MANET routers. >> >> Kenichi >> >> >> >>> Alex >>> >>> >>>>> After a node moves from one subnet to another: does it keep its >>>>> address? Does it keep both its address _and_ its prefix? When it >>>>> keeps its address - nobody else on the previous link can use that >>>>> address on that previous link? >>>>> >>>> Yes, in the same MANET. We thus need to define MANET-local address. >>>> Kenichi >>>> >>>> >>>>> Despite the apparent complexity of describing this, I think it's >>>>> not so difficult - as long as two or more people have encountered >>>>> the same movement scenario. >>>>> Alex >>>>> >>>>> ______________________________________________________________________ >>>>> This email has been scanned by the MessageLabs Email Security >>>>> System. For more information please visit >>>>> http://www.messagelabs.com/email >>>>> ______________________________________________________________________ >>>>> >>> ______________________________________________________________________ >>> This email has been scanned by the MessageLabs Email Security System. >>> For more information please visit >>> http://www.messagelabs.com/email >>> ______________________________________________________________________ >>> >>> >> >> >> _______________________________________________ >> 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 From autoconf-bounces@ietf.org Tue Dec 04 13:16:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcJV-0008VB-OJ; Tue, 04 Dec 2007 13:16:09 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IzcJU-0008HQ-2T for autoconf-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 13:16:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcJT-0008AQ-GK for autoconf@ietf.org; Tue, 04 Dec 2007 13:16:07 -0500 Received: from nf-out-0910.google.com ([64.233.182.188]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzcJT-0001Fy-3C for autoconf@ietf.org; Tue, 04 Dec 2007 13:16:07 -0500 Received: by nf-out-0910.google.com with SMTP id d21so2603468nfb for ; Tue, 04 Dec 2007 10:16:06 -0800 (PST) Received: by 10.78.200.3 with SMTP id x3mr9360972huf.1196792165598; Tue, 04 Dec 2007 10:16:05 -0800 (PST) Received: by 10.78.170.19 with HTTP; Tue, 4 Dec 2007 10:16:04 -0800 (PST) Message-ID: <25c114b90712041016w2aba9bb6o4b3268a70ed51388@mail.gmail.com> Date: Tue, 4 Dec 2007 19:16:04 +0100 From: "Ulrich Herberg" To: "Teco Boot" Subject: Re: [Autoconf] Remarks on PS presentation In-Reply-To: <009901c8369d$a7d21eb0$f7765c10$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <009901c8369d$a7d21eb0$f7765c10$@nl> X-Google-Sender-Auth: 0d39b784c4085d25 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: autoconf@ietf.org, Emmanuel Baccelli 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 Teco, > Slide 4: > This is about a manet connected to different external networks. > Is this in-scope? It is not in manetarch or charter. > I suggest stick on Connected MANET and Standalone MANET. > Why using new term (subordinate)? > > Slide 5: > Why using new term (autonomous)? To these new terms: I think that they make more sense as a connected network. What is actually a "connected network"? Connected to what? To itself (in terms of graph theory: "an undirected graph that has a path between every pair of vertices")? A MANET is certainly "connected" in the terms of "connected component" as used in graph theory. But every MANET is! To an outside network? It certainly is... in fact, every MANET is as soon as it has something attached to any of its interfaces (so also the hosts attached to its non-MANET interface as described in the manetarch draft) To the Internet? What is the Internet? It could be defined as a network of networks. There is no difference whether a MANET is "connected" to the Internet or any other network (if there is a difference between these two terms). Instead, if we use the term "subordinated" MANET, this only means that there is some superordinate network delegating a subprefix of it to that MANET. Whether this network belongs to the Internet or to a private military network does not matter. Only when there is no "subordinate" network attached, it makes sense to speak of an "autonomous" MANET which means that there is no delegated prefix. So I am in favour of these terms. Ulrich _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Dec 04 13:31:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcXz-0004Fj-Ld; Tue, 04 Dec 2007 13:31:07 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IzcXx-0004FW-PY for autoconf-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 13:31:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcXx-0004FO-Fv for autoconf@ietf.org; Tue, 04 Dec 2007 13:31:05 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzcXx-0007Du-27 for autoconf@ietf.org; Tue, 04 Dec 2007 13:31:05 -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.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id lB4IUsGT021239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Dec 2007 10:30:59 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id lB4IUslI015255; Tue, 4 Dec 2007 12:30:54 -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.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id lB4IUrSl015228; Tue, 4 Dec 2007 12:30:54 -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, 4 Dec 2007 10:30:53 -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] Remarks on PS presentation Date: Tue, 4 Dec 2007 10:30:28 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029EDC80@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <009901c8369d$a7d21eb0$f7765c10$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Remarks on PS presentation Thread-Index: Acg2nWOUOtMMbYAkTuGBZAlVjepRrQABeRAQ References: <009901c8369d$a7d21eb0$f7765c10$@nl> From: "Templin, Fred L" To: "Teco Boot" , "Emmanuel Baccelli" X-OriginalArrivalTime: 04 Dec 2007 18:30:53.0669 (UTC) FILETIME=[CD948150:01C836A3] X-Spam-Score: -4.0 (----) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 =20 > -----Original Message----- > From: Teco Boot [mailto:teco@inf-net.nl]=20 > Sent: Tuesday, December 04, 2007 9:46 AM > To: 'Emmanuel Baccelli' > Cc: autoconf@ietf.org > Subject: [Autoconf] Remarks on PS presentation >=20 > Hi Emmanual, >=20 > Thanks for your presentation. > I have some comments, maybe you could use it for updating the=20 > PS document. >=20 > Slide 2: > Please do not use MR for MANET Router. It is MNR. > There are some figures in manetarch, but not one with MNR and R. I do not > understand why this popped up. Agree. > Slide 4: > This is about a manet connected to different external networks. > Is this in-scope? It is not in manetarch or charter. > I suggest stick on Connected MANET and Standalone MANET. > Why using new term (subordinate)? Agree also; have tried working with this term (subordinate) before, and the experience was that it becomes cumbersome and with negative connotations when it creeps into the literature. =20 > Slide 5: > Why using new term (autonomous)? No strong opinion on this one. Fred fred.l.templin@boeing.com =20 > Teco. >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf >=20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Dec 04 13:32:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcZN-0005Qj-6P; Tue, 04 Dec 2007 13:32:33 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IzcZM-0005N3-66 for autoconf-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 13:32:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcZL-0005L1-RN for autoconf@ietf.org; Tue, 04 Dec 2007 13:32:31 -0500 Received: from server9.hosting2go.nl ([83.137.192.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzcZK-0007My-76 for autoconf@ietf.org; Tue, 04 Dec 2007 13:32:31 -0500 Received: (qmail 14273 invoked from network); 4 Dec 2007 19:32:28 +0100 Received: from unknown (HELO M90Teco) (130.129.82.92) by server9.hosting2go.nl with SMTP; 4 Dec 2007 19:32:27 +0100 From: "Teco Boot" To: Date: Tue, 4 Dec 2007 19:31:51 +0100 Message-ID: <009d01c836a4$04776890$0d6639b0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg2o/ApglLsHVlsStOMycw+ubbTjg== Content-Language: nl X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Autoconf] MANET Router co-located host support 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 All, In Autoconf meeting, it was suggested that there is no use case for communication to MNR co-located hosts over the MANET interface. I strongly disagree with this statement. In fact, I have to deal with this scenario. I cannot go into details, here a general description: - MANET is vehicle based, one MANET interface for communication to outside world - Few hosts are located nearby a vehicle, where these nodes are associated with that vehicle - All traffic is from / to that vehicle (client-server, gateway, tunnel or whatever reason for this traffic pattern). There is no host-to-host traffic Current infrastructure is not IP, it is to be replaced one day. A one-to-one replacement of functionality looks reasonable to me. I am aware of the potential problems in this scenario, e.g. when new traffic patterns are introduced. Prohibiting the scenario wipes out these problems, but why do that? Promoting hosts to MANET Routers enlarges load on infrastructure, which is not needed. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Dec 04 13:35:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzccN-0007I1-40; Tue, 04 Dec 2007 13:35:39 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IzccL-0007EO-6W for autoconf-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 13:35:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzccK-0007DX-SE for autoconf@ietf.org; Tue, 04 Dec 2007 13:35:36 -0500 Received: from nf-out-0910.google.com ([64.233.182.187]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzccK-00033x-Hd for autoconf@ietf.org; Tue, 04 Dec 2007 13:35:36 -0500 Received: by nf-out-0910.google.com with SMTP id d21so2606546nfb for ; Tue, 04 Dec 2007 10:35:35 -0800 (PST) Received: by 10.78.159.7 with SMTP id h7mr1200067hue.1196793331157; Tue, 04 Dec 2007 10:35:31 -0800 (PST) Received: by 10.78.170.19 with HTTP; Tue, 4 Dec 2007 10:35:25 -0800 (PST) Message-ID: <25c114b90712041035qd9d737em2353afb594d533bd@mail.gmail.com> Date: Tue, 4 Dec 2007 19:35:25 +0100 From: "Ulrich Herberg" To: "Templin, Fred L" Subject: Re: [Autoconf] Remarks on PS presentation In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029EDC80@XCH-NW-7V2.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <009901c8369d$a7d21eb0$f7765c10$@nl> <39C363776A4E8C4A94691D2BD9D1C9A1029EDC80@XCH-NW-7V2.nw.nos.boeing.com> X-Google-Sender-Auth: 18a31d5a0825000a X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 comments inline On 12/4/07, Templin, Fred L wrote: > > Slide 4: > > This is about a manet connected to different external networks. > > Is this in-scope? It is not in manetarch or charter. > > I suggest stick on Connected MANET and Standalone MANET. > > Why using new term (subordinate)? > > Agree also; have tried working with this term (subordinate) > before, and the experience was that it becomes cumbersome > and with negative connotations when it creeps into the > literature. Can you explain this? Where and in which way can it become cumbersome? This might be interesting to discuss. Ulrich _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Dec 04 14:45:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izdi0-0001sL-4p; Tue, 04 Dec 2007 14:45:32 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Izdhz-0001qb-Eh for autoconf-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 14:45:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izdhz-0001p3-2p for autoconf@ietf.org; Tue, 04 Dec 2007 14:45:31 -0500 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Izdhy-0000ue-HC for autoconf@ietf.org; Tue, 04 Dec 2007 14:45:30 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id lB4JjR4C020108 for ; Tue, 4 Dec 2007 14:45:27 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id lB4JjQU6487660 for ; Tue, 4 Dec 2007 14:45:26 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id lB4JjQnH018482 for ; Tue, 4 Dec 2007 14:45:26 -0500 Received: from cichlid.raleigh.ibm.com (wecm-9-67-194-205.wecm.ibm.com [9.67.194.205]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id lB4JjPZg018357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Dec 2007 14:45:26 -0500 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.1/8.12.5) with ESMTP id lB4JjN83009254; Tue, 4 Dec 2007 14:45:24 -0500 Message-Id: <200712041945.lB4JjN83009254@cichlid.raleigh.ibm.com> To: "Teco Boot" Subject: Re: [Autoconf] comments on draft-ietf-autoconf-manetarch-07.txt In-reply-to: <009501c83696$7e9753a0$7bc5fae0$@nl> References: <200712041343.lB4Dhwq5006349@cichlid.raleigh.ibm.com> <009501c83696$7e9753a0$7bc5fae0$@nl> Comments: In-reply-to "Teco Boot" message dated "Tue, 04 Dec 2007 17:55:04 +0100." Date: Tue, 04 Dec 2007 14:45:23 -0500 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 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 > Maybe better definition could help. Well, yes! :-) > I think it is easy to understand that a MANET Interface is an interface that > may suffer from certain link characteristics. We have similar kind of > interface types, like NBMA and P2MP. No. NBMA is a link type, not an interface type. IPoverATM, for example, looks to IP just like a traditional IP-friendly link. There is a layer of software between IP and ATM that emulates the necessary services that IP needs (like ARP/broadcast). The ATM "interface", however, is just a normal interface. The IP layer does not know about the quirks of ATM and doesn't need to worry about the "challenges" in semantics in order for IP to work. Another way to view things. Stuff that is "interface-specific" is normally implemented by a device driver (for the specific link layer), and not by IP. > Now we want to define another. > Term MANET Interface is well known, e.g. it is used in MANET Routing > Protocol documents, including the OSPF ones. The term "interface" is also well-known outside of MANET. If you look at RFC1122, for example, interface is about the interface beween layers (e.g, between IP and the link layer). The more general term "interface" (in terms of network software) is the data abstraction used to access the facilities of a particular network. > > MANET Router (MNR) > > A MANET router is distinguished by having one or more MANET > > interfaces. A MANET router may also have zero or more non-MANET > > interfaces. A MANET router is responsible for hiding MANETs' > > challenging characteristics from nodes that are not MANET-aware. > > A MANET router with a single MANET interface is illustrated in > > Figure 1. > > > > No. the "interface/link" hides the challenging characteristics from > > IP. Not the BR itself. This is a critical point (architecturally) to > > get right. > > > If this is true, we do not have to do anything special. Well, I'm trying to understand whether this is the case or not. > > You really (I think) need to define an abstraction that defines an > > link type of "manet" that handles all the "interesting" > > characteristics of MANETs (like non-transitive connectivity) but that > > also presents itself to IP as a single IP subnet that has the normal > > properties. > I think there are two MANET implementation models. > One is hiding MANET form IP, e.g. a sub-IP MANET model. This is more or less > out-of-scope for IETF. This could be done in the IETF, and maybe this is a direction the WG may want to pursue. But is this even a model the WG is currently considering? IMO, this is the _obvious_ model to implement, or rather, if any other model is needed, the case first needs to be made why the above model is not good enough (or better). > The other model is described in this document. And what model is that? The problem I have currently is I don't understand the scope of the problem. What is the abstraction. Where is the MANET-specific stuff implemented, and what is the boundary between this and what IP sees? E.g., the MR model suggests that I can have an ethernet interface and two manet interfaces. Where does the MANET stuff sit (just above the two MANET interfaces?) What part is visible to IP (and why?) Does the MANET specific stuff get exported across the Ethernet? Why or why not? Very basic questions, but the document doesn't make this clear at all. > Now we have to face the reachability issues. I think the MANET > Router shall hide this for IP hosts and non-MANET routers. Hide it from whom? What is the scope of where this information is supposed to be exported? It's not good enough to say "within the MR". Where within the MANET router? What part of the MR code is "normal, unmodified IP" and what part has to be MANET-aware? Thomas _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Dec 04 16:52:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izfh5-0004WI-Q9; Tue, 04 Dec 2007 16:52:43 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Izfh5-0004VW-6b for autoconf-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 16:52:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izfh4-0004Uj-SH for autoconf@ietf.org; Tue, 04 Dec 2007 16:52:42 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Izfh4-0006jh-2V for autoconf@ietf.org; Tue, 04 Dec 2007 16:52:42 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-153.messagelabs.com!1196805160!16466418!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 2265 invoked from network); 4 Dec 2007 21:52:41 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-153.messagelabs.com with SMTP; 4 Dec 2007 21:52:41 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lB4LqeGY002434; Tue, 4 Dec 2007 14:52:40 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id lB4LqdJ7026057; Tue, 4 Dec 2007 15:52:40 -0600 (CST) Received: from [127.0.0.1] (mvp-10-197-20-84.corp.mot.com [10.197.20.84]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id lB4LqZg3025988; Tue, 4 Dec 2007 15:52:37 -0600 (CST) Message-ID: <4755CC22.9060300@gmail.com> Date: Tue, 04 Dec 2007 13:52:34 -0800 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Thomas Narten Subject: Re: [Autoconf] comments on draft-ietf-autoconf-manetarch-07.txt References: <200712041343.lB4Dhwq5006349@cichlid.raleigh.ibm.com> <009501c83696$7e9753a0$7bc5fae0$@nl> <200712041945.lB4JjN83009254@cichlid.raleigh.ibm.com> In-Reply-To: <200712041945.lB4JjN83009254@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071204-1, 04/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 Thomas Narten wrote: [...] >>> You really (I think) need to define an abstraction that defines >>> an link type of "manet" that handles all the "interesting" >>> characteristics of MANETs (like non-transitive connectivity) but >>> that also presents itself to IP as a single IP subnet that has >>> the normal properties. > >> I think there are two MANET implementation models. > >> One is hiding MANET form IP, e.g. a sub-IP MANET model. This is >> more or less out-of-scope for IETF. > > This could be done in the IETF, and maybe this is a direction the WG > may want to pursue. But is this even a model the WG is currently > considering? As a member of this WG I can say that I currently consider a model where the MANET protocol is run at sub-IP and offers a IP-friendly MAC already. I mean the sub-IP may run MANET, or may not. I'm interested in the interface that sub-IP provides to my stack, and needing that interface to be a Ethernet MAC. I would also like to learn from other WG members. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Dec 04 16:58:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izfmx-0002Gp-9g; Tue, 04 Dec 2007 16:58:47 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Izfmv-0002Cg-CC for autoconf-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 16:58:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izfmv-0002BT-1i for autoconf@ietf.org; Tue, 04 Dec 2007 16:58:45 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Izfms-0007FC-UK for autoconf@ietf.org; Tue, 04 Dec 2007 16:58:45 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-9.tower-119.messagelabs.com!1196805521!23609539!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 27458 invoked from network); 4 Dec 2007 21:58:42 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-9.tower-119.messagelabs.com with SMTP; 4 Dec 2007 21:58:42 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id lB4LwfL1023537; Tue, 4 Dec 2007 14:58:41 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id lB4LwdsI019862; Tue, 4 Dec 2007 15:58:40 -0600 (CST) Received: from [127.0.0.1] (mvp-10-197-20-84.corp.mot.com [10.197.20.84]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id lB4LwZUD019780; Tue, 4 Dec 2007 15:58:37 -0600 (CST) Message-ID: <4755CD8B.1020700@gmail.com> Date: Tue, 04 Dec 2007 13:58:35 -0800 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ulrich Herberg Subject: Re: [Autoconf] Re: movement scenario References: <7.0.0.16.2.20071202181233.04971348@ie.niigata-u.ac.jp> <475323CF.4080604@gmail.com> <7.0.0.16.2.20071203115230.04bda790@ie.niigata-u.ac.jp> <002301c8355e$639a3e70$2acebb50$@nl> <7.0.0.16.2.20071203125837.049dbf18@ie.niigata-u.ac.jp> <4754AB65.2090800@gmail.com> <7.0.0.16.2.20071204134958.0476dac8@ie.niigata-u.ac.jp> <4754E18D.3080302@gmail.com> <7.0.0.16.2.20071204143038.047a72d0@ie.niigata-u.ac.jp> <25c114b90712040946j47de7a71ve45b50e341ef4dc6@mail.gmail.com> In-Reply-To: <25c114b90712040946j47de7a71ve45b50e341ef4dc6@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071204-1, 04/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.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 Ulrich Herberg wrote: > Hi, > > I agree with Kenichi. Maybe one could mention different scenarios in > the PS, but basically no particular mobility model should be > considered in my opinion. What are the risks of not considering the limits of each entity's movement? Do we risk anything? Or is it just a problem of verbally/writenly communicating the movement scenario - problem that we could ignore? > For Alex's concern about comparability, I don't think this should be > part of a PS (maybe more in a solution space? or something like > draft-bernardos-autoconf-evaluation-considerations ?). The problem of > autoconfiguration should be applicable to all mobility patterns to > my understanding. I kind of agree. I'd say it should apply to a wide range of mobility patterns. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Dec 04 17:08:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzfwJ-0007Ju-7d; Tue, 04 Dec 2007 17:08:27 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IzfwH-0007Hf-Nk for autoconf-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 17:08:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzfwH-0007HU-Dw for autoconf@ietf.org; Tue, 04 Dec 2007 17:08:25 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IzfwG-00081k-OX for autoconf@ietf.org; Tue, 04 Dec 2007 17:08:25 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-119.messagelabs.com!1196806104!22689432!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 13202 invoked from network); 4 Dec 2007 22:08:24 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-119.messagelabs.com with SMTP; 4 Dec 2007 22:08:24 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lB4M8JAg006199; Tue, 4 Dec 2007 15:08:24 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id lB4M8JIh029220; Tue, 4 Dec 2007 16:08:19 -0600 (CST) Received: from [127.0.0.1] (mvp-10-197-20-84.corp.mot.com [10.197.20.84]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id lB4M8FMS029173; Tue, 4 Dec 2007 16:08:16 -0600 (CST) Message-ID: <4755CFCF.1000409@gmail.com> Date: Tue, 04 Dec 2007 14:08:15 -0800 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Yangwoo Ko Subject: Re: [Autoconf] Re: movement scenario References: <7.0.0.16.2.20071202181233.04971348@ie.niigata-u.ac.jp> <475323CF.4080604@gmail.com> <7.0.0.16.2.20071203115230.04bda790@ie.niigata-u.ac.jp> <002301c8355e$639a3e70$2acebb50$@nl> <7.0.0.16.2.20071203125837.049dbf18@ie.niigata-u.ac.jp> <4754AB65.2090800@gmail.com> <7.0.0.16.2.20071204134958.0476dac8@ie.niigata-u.ac.jp> <4754E18D.3080302@gmail.com> <7.0.0.16.2.20071204143038.047a72d0@ie.niigata-u.ac.jp> <25c114b90712040946j47de7a71ve45b50e341ef4dc6@mail.gmail.com> <47559847.3070206@icu.ac.kr> In-Reply-To: <47559847.3070206@icu.ac.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071204-1, 04/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 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 Yangwoo Ko, Yangwoo Ko wrote: > > I got lost. Can somebody clarify how mobility affects address > configurations? Well, it's simple. If we agree that mobility is when a node changes its address (remark it's different than that 'mobility' that defines a node that physically moves). We may not, probably. > It is very obvious that mobility affects decisions on which solutions > are better than others. But it seems only related with how dynamic > the characteristics of MANET-type links are rather than with what > kinds of prefixes/addresses are to be given. I kind of see what you mean. But it is often important to have a good idea about what addresses and their scopes are going to be used because that has immediate consequences on the existing protocols. Or maybe you mean something else I don't see? Alex > > Ulrich Herberg wrote: >> Hi, >> >> I agree with Kenichi. Maybe one could mention different scenarios >> in the PS, but basically no particular mobility model should be >> considered in my opinion. For Alex's concern about comparability, I >> don't think this should be part of a PS (maybe more in a solution >> space? or something like >> draft-bernardos-autoconf-evaluation-considerations ?). The problem >> of autoconfiguration should be applicable to all mobility patterns >> to my understanding. >> >> Ulrich >> >> On 12/4/07, mase wrote: >> >>> Hi Alex, >>> >>> At 14:11 07/12/04, Alexandru Petrescu wrote: >>> >>>> mase wrote: >>>> >>>>> Hi, At 10:20 07/12/04, Alexandru Petrescu wrote: >>>>> >>>>>> mase wrote: >>>>>> >>>>>>>> I want to share my thoughts on link-local addresses and >>>>>>>> MLA with you. I think link-locals are essential to >>>>>>>> IPv6. I do not understand why we have a discussion on >>>>>>>> this. It is to be used for single hop communication, >>>>>>>> which is also very applicable in MANET. >>>>>>>> >>>>>>> Yes, but your former neighbor may be now >>>>>>> out-of-transmission range and only communicated over >>>>>>> multi-hop. Do you prefer to change your >>>>>>> source/destination address from a link-local address to >>>>>>> MLA? >>>>>>> >>>>>> Ha! That's right... Src/dst address rewriting makes >>>>>> immediately think of NAT :-) I think the case you describe >>>>>> above (former neighbor moves from a link to another) >>>>>> deserves deep analysis. What are the mobility scenarios >>>>>> considered? How do entities move, from where to where? >>>>>> >>>>> Any mobility. We do not assume a particular mobility scenario >>>>> when designing MANET routing protocols. >>>>> >>>> I think that is a problem. If we don't know the landmarks, the >>>> movement patterns, the dependencies... then it's very >>>> difficult to design something meaningful, that fits some >>>> initial goals and requirements. >>>> >>>> I think people who have prototyped MANETs have always tested >>>> certain movement scenarios. At least these could be >>>> documented. >>>> >>>> It's really very tough to design something that acomodates >>>> _any_ mobility... >>>> >>>> Besides, such thing risks of not being able to be qualified, >>>> can not be evaluated, can not be compared. Of course, it _can_ >>>> be designed _and_ prototyped but how would one compare it. >>>> >>> I understand your concern. "Any mobility" may not be adequate. >>> pedestrian ad hoc networks, vehicular ad hoc networks, ... >>> Different ad hoc networks may have different mobility models >>> (maximum speed, etc.). I only wanted to point out we do not >>> assume a particular mobility model in developing >>> autoconfiguration solutions. In general, we do not assume >>> apriori knowledge on locations and movement of MANET routers. >>> >>> Kenichi >>> >>> >>> >>>> Alex >>>> >>>> >>>>>> After a node moves from one subnet to another: does it keep >>>>>> its address? Does it keep both its address _and_ its >>>>>> prefix? When it keeps its address - nobody else on the >>>>>> previous link can use that address on that previous link? >>>>>> >>>>> Yes, in the same MANET. We thus need to define MANET-local >>>>> address. Kenichi >>>>> >>>>> >>>>>> Despite the apparent complexity of describing this, I think >>>>>> it's not so difficult - as long as two or more people have >>>>>> encountered the same movement scenario. Alex >>>>>> >>>>>> ______________________________________________________________________ >>>>>> >>>>>> >>>>>> This email has been scanned by the MessageLabs Email >>>>>> Security System. For more information please visit >>>>>> http://www.messagelabs.com/email >>>>>> ______________________________________________________________________ >>>>>> >>>>>> >>>>>> >>>> ______________________________________________________________________ >>>> This email has been scanned by the MessageLabs Email Security >>>> System. For more information please visit >>>> http://www.messagelabs.com/email >>>> ______________________________________________________________________ >>>> >>>> >>>> >>> >>> >>> _______________________________________________ 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 > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Dec 04 17:09:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izfxj-0000Qa-Fn; Tue, 04 Dec 2007 17:09:55 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Izfxi-0000Pk-44 for autoconf-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 17:09:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izfxh-0000Pb-Qc for autoconf@ietf.org; Tue, 04 Dec 2007 17:09:53 -0500 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izfxh-0008A2-CF for autoconf@ietf.org; Tue, 04 Dec 2007 17:09:53 -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.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id lB4M9eKn020216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Dec 2007 14:09:41 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id lB4M9euH010455; Tue, 4 Dec 2007 16:09:40 -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.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id lB4M9dlr010425; Tue, 4 Dec 2007 16:09:39 -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, 4 Dec 2007 14:09:39 -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] comments on draft-ietf-autoconf-manetarch-07.txt Date: Tue, 4 Dec 2007 14:08:52 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029EDC83@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <4755CC22.9060300@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] comments on draft-ietf-autoconf-manetarch-07.txt Thread-Index: Acg2wANPcoB7J7r0TqCzWIJCSVmG1AAAbQUg References: <200712041343.lB4Dhwq5006349@cichlid.raleigh.ibm.com> <009501c83696$7e9753a0$7bc5fae0$@nl><200712041945.lB4JjN83009254@cichlid.raleigh.ibm.com> <4755CC22.9060300@gmail.com> From: "Templin, Fred L" To: "Alexandru Petrescu" , "Thomas Narten" X-OriginalArrivalTime: 04 Dec 2007 22:09:39.0176 (UTC) FILETIME=[5CFDEE80:01C836C2] X-Spam-Score: -4.0 (----) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 =20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > Sent: Tuesday, December 04, 2007 1:53 PM > To: Thomas Narten > Cc: autoconf@ietf.org > Subject: Re: [Autoconf] comments on=20 > draft-ietf-autoconf-manetarch-07.txt >=20 > Thomas Narten wrote: > [...] > >>> You really (I think) need to define an abstraction that defines > >>> an link type of "manet" that handles all the "interesting"=20 > >>> characteristics of MANETs (like non-transitive connectivity) but > >>> that also presents itself to IP as a single IP subnet that has > >>> the normal properties. > >=20 > >> I think there are two MANET implementation models. > >=20 > >> One is hiding MANET form IP, e.g. a sub-IP MANET model. This is > >> more or less out-of-scope for IETF. > >=20 > > This could be done in the IETF, and maybe this is a direction the WG > > may want to pursue. But is this even a model the WG is currently=20 > > considering? >=20 > As a member of this WG I can say that I currently consider a model where > the MANET protocol is run at sub-IP and offers a IP-friendly MAC > already. I mean the sub-IP may run MANET, or may not. I'm interested > in the interface that sub-IP provides to my stack, and needing that > interface to be a Ethernet MAC. We talk about sub-IP MANET model in 'draft-templin-autoconf-dhcp' (which contrary to the name is not only about dhcp solutions). It makes life nice for IP, but may not be sufficient for MANETs made up of heterogeneous link types. Fred fred.l.templin@boeing.com > I would also like to learn from other WG members. >=20 > Alex >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf >=20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Dec 04 17:10:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izfyl-0002Et-PA; Tue, 04 Dec 2007 17:10:59 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Izfyk-0002Eg-Qw for autoconf-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 17:10:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izfyk-0002EX-FA for autoconf@ietf.org; Tue, 04 Dec 2007 17:10:58 -0500 Received: from ccerelbas03.cce.hp.com ([161.114.21.106]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Izfyj-0003Ta-Jh for autoconf@ietf.org; Tue, 04 Dec 2007 17:10:58 -0500 Received: from G3W0631.americas.hpqcorp.net (g3w0631.americas.hpqcorp.net [16.233.59.15]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ccerelbas03.cce.hp.com (Postfix) with ESMTP id CB15434668; Tue, 4 Dec 2007 16:10:56 -0600 (CST) Received: from G5W0326.americas.hpqcorp.net (16.228.8.70) by G3W0631.americas.hpqcorp.net (16.233.59.15) with Microsoft SMTP Server (TLS) id 8.0.700.0; Tue, 4 Dec 2007 22:08:52 +0000 Received: from G5W0274.americas.hpqcorp.net ([16.228.8.60]) by G5W0326.americas.hpqcorp.net ([16.228.8.70]) with mapi; Tue, 4 Dec 2007 22:08:51 +0000 From: "Bound, Jim" To: Teco Boot , 'Thomas Narten' , "autoconf@ietf.org" Date: Tue, 4 Dec 2007 22:08:50 +0000 Subject: RE: [Autoconf] comments on draft-ietf-autoconf-manetarch-07.txt Thread-Topic: [Autoconf] comments on draft-ietf-autoconf-manetarch-07.txt Thread-Index: Acg2e/nOtIBRwU+xQ6uuLQWg5th/fwACoTZAAA6lHWA= Message-ID: <1AB21F94DA6EEF459F107706554433392210FA4211@G5W0274.americas.hpqcorp.net> References: <200712041343.lB4Dhwq5006349@cichlid.raleigh.ibm.com> <009501c83696$7e9753a0$7bc5fae0$@nl> In-Reply-To: <009501c83696$7e9753a0$7bc5fae0$@nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba 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 Teco, MANET is not a "link-type" as Thomas N relays it is an interface but the ch= oice of calling it that could be optimized, though it works for me as input= to the WG. For example MANET interface will have different L2 drivers to = those link types for 802.11g, 802.11s, Military Classified L2's, GSM, CDMA,= and ones not invented yet. I think the bug is in the orginal 2461 ND spec= using the term NBMA and back to ATM networks. NBMA is not a link type but= an architecture approach to operate IP over links. MANET is like NBMA in = the abstract but completely different. MANET is really to me a reference a= rchitecture for an implementation of a network architecture and that is new= to us in the IETF except in the MANET WG arena. The next order derivative= to MANET the interface is how it approaches routing, advertisements, solic= itations, etc. That is what must be written in a manner that it is comfort= able and clear to the IETF IP community. To me the spec is fine but as you= I live in the MANET world almost daily as architect and one who is concern= ed with products and time to market for MANET. We probably need to make it= more IP community friendly and that will help the market too to adopt this= spec. /jim > -----Original Message----- > From: Teco Boot [mailto:teco@inf-net.nl] > Sent: Tuesday, December 04, 2007 11:55 AM > To: 'Thomas Narten'; autoconf@ietf.org > Subject: RE: [Autoconf] comments on > draft-ietf-autoconf-manetarch-07.txt > > Some comments inline. > > > -----Oorspronkelijk bericht----- > > Van: Thomas Narten [mailto:narten@us.ibm.com] > > Verzonden: dinsdag 4 december 2007 14:44 > > Aan: autoconf@ietf.org > > Onderwerp: [Autoconf] comments on > draft-ietf-autoconf-manetarch-07.txt > > > > 2007-11-30 review of -7 > > > > Overall. I still do not think this document is ready for > publication. > > It is still to vague/muddy on the key architectural points > that it is > > supposed to explain. > > > > My major concern is that you still do not lay out an understandable > > "architecture" that allows one to understand what an IP > subnet would > > look like in MANETs. > > > > Interface terminology is non-standard and confusing. Should > use "link > > type". Really. If you want the rest of the community to be able to > > understand this stuff, you cannot redefine terminology that > is already > > widely in use and understood to mean something different > than who it > > is used in this document. > > Maybe better definition could help. > I think it is easy to understand that a MANET Interface is an > interface that may suffer from certain link characteristics. > We have similar kind of interface types, like NBMA and P2MP. > Now we want to define another. > Term MANET Interface is well known, e.g. it is used in MANET > Routing Protocol documents, including the OSPF ones. > > Maybe term Semi-Broadcast Interface (SBI) should be removed, > this is about the link characteristics. Hint for editer: > Change SBI into MANET and some textual cleanup will do. > > > > > > Interface > > A node's point of attachment to a communication link. > > > > This is mostly fine as written, but... > > > > Semi-Broadcast Interface (SBI) > > A broadcast capable interface that may exhibit asymmetric > > reachability. Multiple access wireless radio interfaces are > > often > > SBI. Note that since a SBI *may* exhibit asymmetric > > reachability, > > it also may not. > > > > Call it a "link" not an "interface". > > > > Manets provide IP with a conceptual link, that has certain > properties. > > What I thought the MANET architecture would provide is a > description > > of the properties of that link type. > > > > MANET Interface > > A MANET interface is distinguished by its potentially > significant > > time-varying asymmetric reachability (e.g., SBI) amongst > > potential > > neighboring routers. A more detailed discussion of MANET > > interface characteristics is presented in Section 4.2. The > > addressing constraints for a MANET interface are discussed in > > Section 5.2. > > > > No. A MANET _link_ has these characteristics. Not the interface. > > > > Etc. > > > > MANET Router (MNR) > > A MANET router is distinguished by having one or more MANET > > interfaces. A MANET router may also have zero or > more non-MANET > > interfaces. A MANET router is responsible for hiding MANETs' > > challenging characteristics from nodes that are not > MANET-aware. > > A MANET router with a single MANET interface is illustrated in > > Figure 1. > > > > No. the "interface/link" hides the challenging characteristics from > > IP. Not the BR itself. This is a critical point > (architecturally) to > > get right. > > > > If this is true, we do not have to do anything special. > > > > You really (I think) need to define an abstraction that defines an > > link type of "manet" that handles all the "interesting" > > characteristics of MANETs (like non-transitive > connectivity) but that > > also presents itself to IP as a single IP subnet that has > the normal > > properties. > > I think there are two MANET implementation models. > One is hiding MANET form IP, e.g. a sub-IP MANET model. This > is more or less out-of-scope for IETF. > The other model is described in this document. Now we have to > face the reachability issues. I think the MANET Router shall > hide this for IP hosts and non-MANET routers. If this is > arranged by using a single IP subnet or using another > addressing model is solution space. > > There might be a discussion on supporting connectivity to > (mobile) hosts via the MANET Interface. I will post on this > separately. > > Teco. > > > > _______________________________________________ > 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 Dec 04 17:27:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzgF3-0001re-63; Tue, 04 Dec 2007 17:27:49 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IzgF2-0001qk-FT for autoconf-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 17:27:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzgF2-0001pa-3F for autoconf@ietf.org; Tue, 04 Dec 2007 17:27:48 -0500 Received: from server9.hosting2go.nl ([83.137.192.232]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzgF1-0004qq-8D for autoconf@ietf.org; Tue, 04 Dec 2007 17:27:48 -0500 Received: (qmail 29873 invoked from network); 4 Dec 2007 23:27:45 +0100 Received: from unknown (HELO M90Teco) (130.129.82.92) by server9.hosting2go.nl with SMTP; 4 Dec 2007 23:27:45 +0100 From: "Teco Boot" To: "'Thomas Narten'" References: <200712041343.lB4Dhwq5006349@cichlid.raleigh.ibm.com> <009501c83696$7e9753a0$7bc5fae0$@nl> <200712041945.lB4JjN83009254@cichlid.raleigh.ibm.com> In-Reply-To: <200712041945.lB4JjN83009254@cichlid.raleigh.ibm.com> Subject: RE: [Autoconf] comments on draft-ietf-autoconf-manetarch-07.txt Date: Tue, 4 Dec 2007 23:27:08 +0100 Message-ID: <002101c836c4$e30d9ff0$a928dfd0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg2rk1ZR5ZPe5SkQ++dKUuLWKxeQAACUK1A Content-Language: nl X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 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 > > I think it is easy to understand that a MANET Interface is an > interface that > > may suffer from certain link characteristics. We have similar kind of > > interface types, like NBMA and P2MP. > > No. NBMA is a link type, not an interface type. IPoverATM, for > example, looks to IP just like a traditional IP-friendly link. There > is a layer of software between IP and ATM that emulates the necessary > services that IP needs (like ARP/broadcast). The ATM "interface", > however, is just a normal interface. The IP layer does not know about > the quirks of ATM and doesn't need to worry about the "challenges" in > semantics in order for IP to work. > > Another way to view things. Stuff that is "interface-specific" is > normally implemented by a device driver (for the specific link layer), > and not by IP. OK, now we have something as "IP-friendly". Fully meshed, full broadcast. If this is the case, we can use IP protocols as is. In reality, some links are not that friendly. I think this is explained in the MANET Architecture document quite well, but using some wrong terms. On wrong terms: For example section 4 "MANET Interface Characteristics" is about the links. It should be "MANET Link Characteristics". I think it is useful keeping the term MANET Interface, being used as "a MANET Router's attachment to a MANET link". I am not sure if we should use MANET Interfaces for hosts. I would like to use the RFC4861 based definition: interface - a node's attachment to a link. Any objection to: MANET Interface - a MANET Router's attachment to a MANET link ? > > Now we want to define another. > > Term MANET Interface is well known, e.g. it is used in MANET Routing > > Protocol documents, including the OSPF ones. > > The term "interface" is also well-known outside of MANET. If you look > at RFC1122, for example, interface is about the interface beween > layers (e.g, between IP and the link layer). The more general term > "interface" (in terms of network software) is the data abstraction > used to access the facilities of a particular network. > > > MANET Router (MNR) > > > A MANET router is distinguished by having one or more MANET > > > interfaces. A MANET router may also have zero or more non- > MANET > > > interfaces. A MANET router is responsible for hiding MANETs' > > > challenging characteristics from nodes that are not MANET- > aware. > > > A MANET router with a single MANET interface is illustrated > in > > > Figure 1. > > > > > > No. the "interface/link" hides the challenging characteristics from > > > IP. Not the BR itself. This is a critical point (architecturally) > to > > > get right. > > > > > > If this is true, we do not have to do anything special. > > Well, I'm trying to understand whether this is the case or not. I think it is obvious that if MANET is sub-IP, IP is not aware and all protocols run well. If you mean you want to know why this is a bad idea in some cases, I agree that this should be described. It is, in the bottom of Section 6: MANETs' Place in the Network Stack. This is also described in RFC2501 5. IP-Layer Mobile Routing. Maybe a reference to this section would help. > > > > You really (I think) need to define an abstraction that defines an > > > link type of "manet" that handles all the "interesting" > > > characteristics of MANETs (like non-transitive connectivity) but > that > > > also presents itself to IP as a single IP subnet that has the > normal > > > properties. > > > I think there are two MANET implementation models. > > > One is hiding MANET form IP, e.g. a sub-IP MANET model. This is more > or less > > out-of-scope for IETF. > > This could be done in the IETF, and maybe this is a direction the WG > may want to pursue. But is this even a model the WG is currently > considering? > > IMO, this is the _obvious_ model to implement, or rather, if any other > model is needed, the case first needs to be made why the above model > is not good enough (or better). I think there are multiple models and there are valid reasons for this. > > > The other model is described in this document. > > And what model is that? L3 MANET. I agree the readability of the document would be improved if both MANET models are introduced very early in the document. > The problem I have currently is I don't > understand the scope of the problem. What is the abstraction. Where is > the MANET-specific stuff implemented, and what is the boundary between > this and what IP sees? > > E.g., the MR model suggests that I can have an ethernet interface and > two manet interfaces. Where does the MANET stuff sit (just above the > two MANET interfaces?) What part is visible to IP (and why?) Does the > MANET specific stuff get exported across the Ethernet? Why or why not? > > Very basic questions, but the document doesn't make this clear at all. > > > Now we have to face the reachability issues. I think the MANET > > Router shall hide this for IP hosts and non-MANET routers. > > Hide it from whom? What is the scope of where this information is > supposed to be exported? Discussed in 5.3. Routers and Hosts in a MANET. Maybe we shall update RFC4294 IPv6 Node Requirements one day and add a section on MANET. > It's not good enough to say "within the > MR". Where within the MANET router? What part of the MR code is > "normal, unmodified IP" and what part has to be MANET-aware? Good questions, but more related to a Router Architecture. Do we work on this or is it up to the implementers? Teco. > > Thomas _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Dec 04 17:49:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izga0-0001SF-KF; Tue, 04 Dec 2007 17:49:28 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IzgZy-0001P5-QQ for autoconf-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 17:49:26 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzgZy-0001Op-F2 for autoconf@ietf.org; Tue, 04 Dec 2007 17:49:26 -0500 Received: from server9.hosting2go.nl ([83.137.192.232]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzgZx-0006lx-SK for autoconf@ietf.org; Tue, 04 Dec 2007 17:49:26 -0500 Received: (qmail 10107 invoked from network); 4 Dec 2007 23:49:24 +0100 Received: from unknown (HELO M90Teco) (130.129.82.92) by server9.hosting2go.nl with SMTP; 4 Dec 2007 23:49:23 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" , References: <4754C98A.5000707@gmail.com> In-Reply-To: <4754C98A.5000707@gmail.com> Subject: RE: [Autoconf] Per request of scenarios Date: Tue, 4 Dec 2007 23:48:48 +0100 Message-ID: <002201c836c7$e8efca80$bacf5f80$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg2JfTecDdb/sE5TjCI+TsvJAQTywAoG+PA Content-Language: nl X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 Alex, I wonder what AUTOCONF facility is helpful for this scenario. Both vehicles are provisioned with MNP and routing can exchange this prefix information. LL addresses on egress interfaces can be used for the routing protocol. What is missing? General remark: I prefer discussing problems on well defined scenarios. But only if we have to. Teco. > -----Oorspronkelijk bericht----- > Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Verzonden: dinsdag 4 december 2007 4:29 > Aan: autoconf@ietf.org > Onderwerp: [Autoconf] Per request of scenarios > > During the AUTOCONF WG meeting I asked whether we consider including 1 > or more more precise scenarios of mobility in the Problem Statement > discussion. > > I meant to say how do the mobiles move, how are they structured. I'm > suggesting discussing with figures as support. One possible figure is > the following (extracted from an expired draft of MANEMO): > > Vehicle 1 Vehicle 2 > > egress| egress| > ---- ---- ---- ---- ---- ---- > | MR | |LFN | |LFN | | MR | |LFN | |LFN | > ---- ---- ---- ---- ---- ---- > ingress| | Ether | ingress| | Ether | > --------------------- --------------------- > 2001:1::/24 2001:2::/24 > > > The two vehicles connect their egress interfaces; the LFNs (Local Fixed > Node) don't move with respect to their respective MR (Mobile Router). > The vehicles move independently, and at one point meet and stay > connected for a while. LFN in one vehicle needs to talk to another LFN > in another vehicle. There's no Internet connectivity and the boxes > need > to run widely IPv6 available software. > > This is the kind of scenario I was asking whether it deserves inclusion > in discussion of problem statement. There are more MANEMO scenarios > discussed during the MANEMO pre-BoF. > > Should we include this above scenario in the AUTOCONF discussion? > Should > we discuss AUTOCONF scenarios in this way? > > Alex > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > > _______________________________________________ > 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 Dec 04 18:01:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izgly-0006kv-KP; Tue, 04 Dec 2007 18:01:50 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Izglx-0006bZ-Eb for autoconf-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 18:01:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izglx-0006ZQ-1y for autoconf@ietf.org; Tue, 04 Dec 2007 18:01:49 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Izglw-0004FE-NK for autoconf@ietf.org; Tue, 04 Dec 2007 18:01:49 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-9.tower-153.messagelabs.com!1196809305!11644562!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 31299 invoked from network); 4 Dec 2007 23:01:46 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-9.tower-153.messagelabs.com with SMTP; 4 Dec 2007 23:01:46 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id lB4N1jMn028929; Tue, 4 Dec 2007 16:01:45 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id lB4N1iap001922; Tue, 4 Dec 2007 17:01:45 -0600 (CST) Received: from [127.0.0.1] (mvp-10-197-20-133.corp.mot.com [10.197.20.133]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id lB4N1bld001890; Tue, 4 Dec 2007 17:01:42 -0600 (CST) Message-ID: <4755DC50.4050209@gmail.com> Date: Tue, 04 Dec 2007 15:01:36 -0800 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Teco Boot Subject: Re: [Autoconf] Per request of scenarios References: <4754C98A.5000707@gmail.com> <002201c836c7$e8efca80$bacf5f80$@nl> In-Reply-To: <002201c836c7$e8efca80$bacf5f80$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071204-1, 04/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 Teco Boot wrote: > Hi Alex, > > I wonder what AUTOCONF facility is helpful for this scenario. Both > vehicles are provisioned with MNP and routing can exchange this > prefix information. LL addresses on egress interfaces can be used for > the routing protocol. What is missing? I agree with you saying MNP provisioned on vehicles and LL addresses used on egress interfaces. What is missing is a widely available piece of software that puts one router's MNP in the other router's routing table. This should be easily implementable as a simple extension of widely available software. In a sense, it is not about auto-configuring addresses. It is maybe about AUTOCONFing some routes in the routing table, but probably a stretch as such. > General remark: I prefer discussing problems on well defined > scenarios. But only if we have to. Well, above is a scenario. One may discard it as not enough challenging - ok with that. Or maybe not in the AUTOCONF charter - ok with that too. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Dec 04 18:39:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzhMZ-0006RI-IU; Tue, 04 Dec 2007 18:39:39 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IzhMY-0006PG-RJ for autoconf-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 18:39:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzhMY-0006P0-7I for autoconf@ietf.org; Tue, 04 Dec 2007 18:39:38 -0500 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzhMW-0007V6-UC for autoconf@ietf.org; Tue, 04 Dec 2007 18:39:38 -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.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id lB4NdJ8c012266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Dec 2007 15:39:34 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id lB4NdJUk021545; Tue, 4 Dec 2007 17:39:19 -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.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id lB4Nd62E021207; Tue, 4 Dec 2007 17:39:18 -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, 4 Dec 2007 15:39: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] comments on draft-ietf-autoconf-manetarch-07.txt Date: Tue, 4 Dec 2007 15:38:33 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029EDC84@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <002101c836c4$e30d9ff0$a928dfd0$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] comments on draft-ietf-autoconf-manetarch-07.txt Thread-Index: Acg2rk1ZR5ZPe5SkQ++dKUuLWKxeQAACUK1AAAW9VSA= References: <200712041343.lB4Dhwq5006349@cichlid.raleigh.ibm.com><009501c83696$7e9753a0$7bc5fae0$@nl><200712041945.lB4JjN83009254@cichlid.raleigh.ibm.com> <002101c836c4$e30d9ff0$a928dfd0$@nl> From: "Templin, Fred L" To: "Teco Boot" , "Thomas Narten" X-OriginalArrivalTime: 04 Dec 2007 23:39:08.0035 (UTC) FILETIME=[DD14CD30:01C836CE] X-Spam-Score: -4.0 (----) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Teco, > I think it is useful keeping the term MANET Interface, being used as "a > MANET Router's attachment to a MANET link".=20 > I am not sure if we should use MANET Interfaces for hosts. >=20 > I would like to use the RFC4861 based definition: > interface - a node's attachment to a link. > Any objection to: > MANET Interface - a MANET Router's attachment to a MANET link > ? That is what it says now in 'draft-templin-autconf-dhcp', so I have no objections. 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 Dec 04 20:22:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iziy6-000264-Lm; Tue, 04 Dec 2007 20:22:30 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Iziy6-00025o-Bj for autoconf-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 20:22:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iziy6-00025M-28 for autoconf@ietf.org; Tue, 04 Dec 2007 20:22:30 -0500 Received: from ccerelbas04.cce.hp.com ([161.114.21.107]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iziy5-0005Xb-Kr for autoconf@ietf.org; Tue, 04 Dec 2007 20:22:30 -0500 Received: from G1W0400.americas.hpqcorp.net (g1w0400.americas.hpqcorp.net [16.236.31.10]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ccerelbas04.cce.hp.com (Postfix) with ESMTP id AD849356B2; Tue, 4 Dec 2007 19:22:28 -0600 (CST) Received: from G5W0326.americas.hpqcorp.net (16.228.8.70) by G1W0400.americas.hpqcorp.net (16.236.31.10) with Microsoft SMTP Server (TLS) id 8.0.744.1; Wed, 5 Dec 2007 01:17:16 +0000 Received: from G5W0274.americas.hpqcorp.net ([16.228.8.60]) by G5W0326.americas.hpqcorp.net ([16.228.8.70]) with mapi; Wed, 5 Dec 2007 01:17:16 +0000 From: "Bound, Jim" To: "Templin, Fred L" , Teco Boot , Thomas Narten Date: Wed, 5 Dec 2007 01:17:13 +0000 Subject: RE: [Autoconf] comments on draft-ietf-autoconf-manetarch-07.txt Thread-Topic: [Autoconf] comments on draft-ietf-autoconf-manetarch-07.txt Thread-Index: Acg2rk1ZR5ZPe5SkQ++dKUuLWKxeQAACUK1AAAW9VSAAA3oEcA== Message-ID: <1AB21F94DA6EEF459F107706554433392210FA43CB@G5W0274.americas.hpqcorp.net> References: <200712041343.lB4Dhwq5006349@cichlid.raleigh.ibm.com><009501c83696$7e9753a0$7bc5fae0$@nl><200712041945.lB4JjN83009254@cichlid.raleigh.ibm.com> <002101c836c4$e30d9ff0$a928dfd0$@nl> <39C363776A4E8C4A94691D2BD9D1C9A1029EDC84@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029EDC84@XCH-NW-7V2.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: -4.0 (----) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 I agree with the update and very clear and distinct for autoconf work. It = also kills the NBMA issue I have in 4861. /jim > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > Sent: Tuesday, December 04, 2007 6:39 PM > To: Teco Boot; Thomas Narten > Cc: autoconf@ietf.org > Subject: RE: [Autoconf] comments on > draft-ietf-autoconf-manetarch-07.txt > > Teco, > > > I think it is useful keeping the term MANET Interface, being used as > "a > > MANET Router's attachment to a MANET link". > > I am not sure if we should use MANET Interfaces for hosts. > > > > I would like to use the RFC4861 based definition: > > interface - a node's attachment to a link. > > Any objection to: > > MANET Interface - a MANET Router's attachment to a > MANET link ? > > That is what it says now in 'draft-templin-autconf-dhcp', so > I have no objections. > > 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 Dec 05 17:18:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J02Zi-0003Kp-6V; Wed, 05 Dec 2007 17:18:38 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1J02Zg-0003Ad-RG for autoconf-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 17:18:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J02Zg-000385-EZ for autoconf@ietf.org; Wed, 05 Dec 2007 17:18:36 -0500 Received: from an-out-0708.google.com ([209.85.132.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J02Zg-0006LR-3f for autoconf@ietf.org; Wed, 05 Dec 2007 17:18:36 -0500 Received: by an-out-0708.google.com with SMTP id d11so1201115and for ; Wed, 05 Dec 2007 14:18:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=nSkK3l1tIhO0Dm457oB/RV7BIDoA76oeFk56gXP5pUM=; b=abpbTL2FY4DiaqotQ73O+R116XDUUDe1/kW+4KWqViQmJWn24Fh73VM48f1XHryIeSbYTL93u1KwQ7kn1X/F65G0GH0cqEMU8bwfg/20o5eIeRF60ZkRhnQwghnPrVmOy3Yqx5AqyCdGM8YszCWVn+CxYYnGWJqaDaSi7FA3GxI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=kEtAHML9lBNN9hOBmMhZx8lMuUfM5SpxJYsxlYz5IByOAva5aFoTQVuDfLttem1E+iV+aa6I+SUkbTKD0iAFgcjAYLiudpduSxGr02JfJWIaGV/+DlYwsEucXV/z+RrlWzBQlHrVPmEt05WK616hAXaovzuF0kMhVg/FyGs/9n4= Received: by 10.100.112.6 with SMTP id k6mr5165325anc.1196893115775; Wed, 05 Dec 2007 14:18:35 -0800 (PST) Received: from ?130.129.19.220? ( [130.129.19.220]) by mx.google.com with ESMTPS id c27sm1809901ana.2007.12.05.14.18.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 05 Dec 2007 14:18:32 -0800 (PST) Message-ID: <475723B6.5070401@gmail.com> Date: Wed, 05 Dec 2007 14:18:30 -0800 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Alexandru Petrescu References: <7.0.0.16.2.20071202181233.04971348@ie.niigata-u.ac.jp> <62022ED1-47D5-4704-AC53-01738CD75027@gmail.com> <4754A8C5.8020804@gmail.com> In-Reply-To: <4754A8C5.8020804@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: autoconf@ietf.org Subject: [Autoconf] Re: scope of multicast address 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 [to not follow up on my own post...] Alexandru Petrescu wrote: > RYUJI WAKIKAWA wrote: [...] >>> With regard to the definition of MANET-local address, I am also >>> not satisfied with the current definition. My proposal is as >>> follows: MANET-local address an address having MANET-only scope >>> that can be used to reach destinations in the MANET. All MANET >>> interfaces have a MANET-local unicast address. >> >> I was asking what is the MANET-local scope? :-) How can you map >> this manet-local into the current IPv6 scoping? Do you suggest to >> define new address scope for MANET-local? > > There is this 'LL-MANET-Routers' address FF02:0:0:0:0:0:0:TBD4 > defined in draft-ietf-manet-iana-07.txt. This address has link-local > scope. A link-local scope is number '2', defined by RFC4291 "IPv6 > Addressing Architecture". That RFC defines other scopes as well: 0, > 1, 4, 5, 8, E, F. > > I'm not sure whether people really want/need to define another scope > for MANET, not clear to me. > > My personal opinion is to go with already reserved scopes. I've been pointed out in private that maybe a permanent multicast Group ID could be requested for use in MANET, following guidelines in RFC3307 "IPv6 Multicast Address Guidelines". By my reading (could be wrong), an example would be to request Group ID 0x7FFFFFFE (and have an Expert Review this). This Group ID would then be used within any of the defined IPv6 multicast scopes: FF02::7FFF:FFFE - All MANET Routers on the same link FF05::7FFF:FFFE - All MANET Routers on the same site FF0E::7FFF:FFFE - All MANET Routers in the Internet This Group ID would probably also map into a Ethernet group address: 33-33-7F-FF-FF-FE - IPv6 Neighbor Discovery - MANET Not sure having got this straight. Alex _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Dec 05 17:23:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J02eC-00019b-4g; Wed, 05 Dec 2007 17:23:16 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1J02eA-00016R-2G for autoconf-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 17:23:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J02e9-00016I-Nt for autoconf@ietf.org; Wed, 05 Dec 2007 17:23:13 -0500 Received: from smtp01.uc3m.es ([163.117.176.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J02e7-0002H4-Qr for autoconf@ietf.org; Wed, 05 Dec 2007 17:23:13 -0500 Received: from [130.129.19.231] (dhcp-13e7.ietf70.org [130.129.19.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id D93F42798B3 for ; Wed, 5 Dec 2007 23:23:09 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: autoconf@ietf.org Organization: Universidad Carlos III de Madrid Date: Wed, 05 Dec 2007 23:23:07 +0100 Message-Id: <1196893387.27208.64.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 X-Spam-Score: -4.0 (----) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Subject: [Autoconf] About unique/non-overlapping prefixes terminology X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2143825700==" Errors-To: autoconf-bounces@ietf.org --===============2143825700== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-5UMNoPHrGEAD1JXBOJuD" --=-5UMNoPHrGEAD1JXBOJuD Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi all, Regarding the discussion about what a unique prefix is and what is the more appropriate term, I have some comments/questions/suggestions that I wanted to share. To my understanding, each MNR might be delegated a prefix(es) to be used to configure its(their) interfaces and further delegate (i.e., assign) addresses to attached non-MANET hosts. In that sense, I see that those prefixes should be non-overlapping, meaning that the IPv6 addresses that might be configured out of several different IPv6 prefixes must not overlap (i.e. have to be different). This does not mean that MNRs may be delegated a bigger prefix (e.g., a /48) and then delegate further this prefix to other routers (MNRs or normal routers), but at the end, the prefixes used by the end-routers must not overlap. Aggregation is a different thing. In the Internet, we have see aggregation to reduce the number of routing entries and so on, but the global prefixes that are deployed in the subnets do not overlap. A MNR can also be delegated prefixes/addresses to be used for configuring its MANET interfaces. Of course, these should also be unique in the same sense. If a MNR is delegated an address, then what "unique" means is clear (the 128 bits are different from any other address used within the MANET). If a MNR is delegated a prefix, the same comments mentioned above would apply (i.e., this prefix must not overlap with any other prefix used by any other MNR within the MANET). Is this view shared by others? Am I missing something (probably yes ;->)? Regards, Carlos --=20 =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WEEDEV 2008: 1st Workshop on Experimental Evaluation and Deployment Experiences on Vehicular networks http://www.weedev.org/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-5UMNoPHrGEAD1JXBOJuD Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHVyTLNdy6TdFwT2cRAoVKAJ9zfn/t3V7UG90lWXEDqkUOjbevCACgx9RG ru+6lmKtfRbMcpwTBE/Vvxk= =Qrh1 -----END PGP SIGNATURE----- --=-5UMNoPHrGEAD1JXBOJuD-- --===============2143825700== 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 --===============2143825700==-- From autoconf-bounces@ietf.org Wed Dec 05 17:41:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J02vt-0001v9-Ut; Wed, 05 Dec 2007 17:41:33 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1J02vs-0001uj-Ul for autoconf-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 17:41:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J02vs-0001uX-L7 for autoconf@ietf.org; Wed, 05 Dec 2007 17:41:32 -0500 Received: from nf-out-0910.google.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J02vr-0004Q5-Ur for autoconf@ietf.org; Wed, 05 Dec 2007 17:41:32 -0500 Received: by nf-out-0910.google.com with SMTP id d21so2860179nfb for ; Wed, 05 Dec 2007 14:41:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=AVEfcz1h/i9vtJFoEw0ug8KrAE1iOWFjP4EwDOnIveA=; b=Y4YOI5EAs7jbVKy+XSy9UuYhZaGyRfdlaehnbfY8i4gjoADYaBbbVsQGdIWoQ5vFawfenG7ieAUzajeQ8aWAO10pp9IsFNfCH7eyZiFICI3qeBNymia4PxrK+GRpF4sA4alHES7XOy81g9eFUE9vXmXxvmCUuxe5qnyXkpgd86k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fO6vigdKpTDnEKNdiBMru4wDF+qXdx6AXjFDNJTsA/qTN/+teVkE3/WHiOhyoZJJvliAeq/bf5VqmeovgSgCqlBsLX2T4YTkt4cIyItTjwW0Rty+VtOOM5jLiGPdYdcw8XG61OsA+jkq90yD4lRrHjoAqUczJAPfWF0sH9UUaMo= Received: by 10.78.176.20 with SMTP id y20mr1422692hue.1196894489811; Wed, 05 Dec 2007 14:41:29 -0800 (PST) Received: by 10.78.23.14 with HTTP; Wed, 5 Dec 2007 14:41:29 -0800 (PST) Message-ID: <374005f30712051441yac27531r96c55806e5c9a3d5@mail.gmail.com> Date: Thu, 6 Dec 2007 04:11:29 +0530 From: "Ian Chakeres" To: autoconf@ietf.org Subject: Re: [Autoconf] About unique/non-overlapping prefixes terminology In-Reply-To: <1196893387.27208.64.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1196893387.27208.64.camel@localhost> X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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 Based on the confusion around "unique" I've removed the use of 'unique prefix' from my local revision. I've replaced unique with distinct. Please let me know if you have another recommendation. Distinct Prefix Assignment MANET interfaces that are known to exhibit the above mentioned properties must be configured with distinct prefixes, for their non-link-local addresses. The reason for this requirement is so that no two MANET interfaces are configured to appear within the same IP prefix. Ian Chakeres On Dec 6, 2007 3:53 AM, Carlos Jes=FAs Bernardos Cano wro= te: > Hi all, > > Regarding the discussion about what a unique prefix is and what i= s the > more appropriate term, I have some comments/questions/suggestions that I > wanted to share. > > To my understanding, each MNR might be delegated a prefix(es) to = be > used to configure its(their) interfaces and further delegate (i.e., > assign) addresses to attached non-MANET hosts. In that sense, I see that > those prefixes should be non-overlapping, meaning that the IPv6 > addresses that might be configured out of several different IPv6 > prefixes must not overlap (i.e. have to be different). This does not > mean that MNRs may be delegated a bigger prefix (e.g., a /48) and then > delegate further this prefix to other routers (MNRs or normal routers), > but at the end, the prefixes used by the end-routers must not overlap. > > Aggregation is a different thing. In the Internet, we have see > aggregation to reduce the number of routing entries and so on, but the > global prefixes that are deployed in the subnets do not overlap. > > A MNR can also be delegated prefixes/addresses to be used for > configuring its MANET interfaces. Of course, these should also be unique > in the same sense. If a MNR is delegated an address, then what "unique" > means is clear (the 128 bits are different from any other address used > within the MANET). If a MNR is delegated a prefix, the same comments > mentioned above would apply (i.e., this prefix must not overlap with any > other prefix used by any other MNR within the MANET). > > Is this view shared by others? Am I missing something (probably > yes ;->)? > > Regards, > > Carlos > > -- > =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws > Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > WEEDEV 2008: 1st Workshop on Experimental Evaluation and > Deployment Experiences on Vehicular networks > http://www.weedev.org/ > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > _______________________________________________ > 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 Dec 05 17:55:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J039p-0004xo-6Y; Wed, 05 Dec 2007 17:55:57 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1J039o-0004xb-29 for autoconf-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 17:55:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J039n-0004xQ-NU for autoconf@ietf.org; Wed, 05 Dec 2007 17:55:55 -0500 Received: from smtp02.uc3m.es ([163.117.176.132]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J039m-0002MB-R4 for autoconf@ietf.org; Wed, 05 Dec 2007 17:55:55 -0500 Received: from [130.129.19.231] (dhcp-13e7.ietf70.org [130.129.19.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id C87122A50E7 for ; Wed, 5 Dec 2007 23:55:52 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: autoconf@ietf.org Organization: Universidad Carlos III de Madrid Date: Wed, 05 Dec 2007 23:55:50 +0100 Message-Id: <1196895350.27208.93.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Subject: [Autoconf] List of requirements in draft-ietf-autoconf-problem-statement X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1100735854==" Errors-To: autoconf-bounces@ietf.org --===============1100735854== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-XbU8oAwvEJ+Emd0tZ8rR" --=-XbU8oAwvEJ+Emd0tZ8rR Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi all, As expressed by me and others, it may be helpful to add a list of clear requirements of MANET IP autoconf mechanisms in the problem statement draft. This would help to understand what (and maybe how) has to be done to solve the problem of IP autoconf in MANETs. Collecting this list is not easy, and therefore this mail is a humble attempt to get other people's opinion and start discussing what this list should contain. To start, I'd propose the following: R01. The solution must be implemented at the IP layer level. (Following recent discussions, my understanding is that we are working at the IP layer...) R02. The solution must provide a MANET Router with an IPv6 address for=20 each of its MANET interfaces. R03. The solution must provide a MANET Router with an IPv6 prefix to=20 configure each of its non-MANET interfaces and be advertised for=20 configuration of non-MANET attached nodes. R04. The solution must work for MANETs using symmetric and assymetric=20 links. R05. The solution should not be independent of any particular MANET=20 routing protocol. R06. The solution must provide MANET routers with unique addresses and=20 non-overlapping IPv6 prefixes. R07. The solution should detect and resolve IP address conflicts as a=20 result of network mergers. R08. The solution must provide MANET routers with IPv6=20 addresses/prefixes topologically correct/coherent when the MANET is connected to an external network (e.g., the Internet). R09. The solution should present the same level of security than=20 existing IP autoconfiguration mechanisms. R10. The solution must ensure backward compatibility with other=20 standards defined by the IETF. In particular, this includes the=20 following: R10.1. The solution must not prevent the proper operation of Mobile IPv6 (i.e., the solution must allow MIPv6-enabled nodes attached to a MANET router to operate either the CN, HA, or MN operations defined in [RFC3775]). R11. The solution must not require modifications to any node other than=20 MANET routers and required provisioning servers. R12. The solution may be designed in such a modular way that some of the previous requirements are not met if not required by a=20 particular application scenario. As previously stated, this is mainly for discussion. I'm not even saying I agree with all of them ;-). Comments are welcome :-D. Regards, Carlos --=20 =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WEEDEV 2008: 1st Workshop on Experimental Evaluation and Deployment Experiences on Vehicular networks http://www.weedev.org/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-XbU8oAwvEJ+Emd0tZ8rR Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHVyx2Ndy6TdFwT2cRAuxCAJ4zyY9NBSdos+2Q4K08Iv0KtP16xgCeLIyf /8uhgScgEdUypdsbBQQf6V8= =Y3YN -----END PGP SIGNATURE----- --=-XbU8oAwvEJ+Emd0tZ8rR-- --===============1100735854== 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 --===============1100735854==-- From autoconf-bounces@ietf.org Wed Dec 05 18:57:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J047E-0008Ne-42; Wed, 05 Dec 2007 18:57:20 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1J047C-0008Mc-8d for autoconf-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 18:57:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J047B-0008MT-Uh for autoconf@ietf.org; Wed, 05 Dec 2007 18:57:17 -0500 Received: from mu-out-0910.google.com ([209.85.134.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J047B-0003bh-8P for autoconf@ietf.org; Wed, 05 Dec 2007 18:57:17 -0500 Received: by mu-out-0910.google.com with SMTP id i10so47718mue for ; Wed, 05 Dec 2007 15:57:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=gVXWcey5ysWnxto1AajQCKbTCMpl1GKVNoHck8FrOZ0=; b=jX1FrUkqsOykR5GeXRwmh+p2KuyRhaA9RrqEQHkBi2ex0jo1uD+eeNCq8i4X+XO8twRo9YJHpaDx8jzhZco5fRD12K/7DH7EdCpsUEtILYzFi3bfwG/r1B/JO6ULa6RsskyJMJldRMrGZFDVzUGXhhnu7rXxG08/y6YalmyYdns= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=uUblvCLSODneyc7PK/PyUx/AizbYWOtIJyMsCUx5coiKSUPaFtxPN5757hBLD5WsHbaeB6rGh/UGNGtLbn7q/evz7Nc76EQrsrFj3c95L1wJwEsqZWfQOAAXH4fMP0GYVvl0hZBVGPwPuBmrUJRDWWk1r1uTz0UXqlWup78ElQI= Received: by 10.82.162.14 with SMTP id k14mr6897122bue.1196899036087; Wed, 05 Dec 2007 15:57:16 -0800 (PST) Received: by 10.82.175.1 with HTTP; Wed, 5 Dec 2007 15:57:16 -0800 (PST) Message-ID: Date: Wed, 5 Dec 2007 18:57:16 -0500 From: "Marshall Eubanks" To: "Alexandru Petrescu" Subject: Re: [Autoconf] Re: scope of multicast address In-Reply-To: <475723B6.5070401@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7.0.0.16.2.20071202181233.04971348@ie.niigata-u.ac.jp> <62022ED1-47D5-4704-AC53-01738CD75027@gmail.com> <4754A8C5.8020804@gmail.com> <475723B6.5070401@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e 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 Hello; On 12/5/07, Alexandru Petrescu wrote: > [to not follow up on my own post...] > > Alexandru Petrescu wrote: > > RYUJI WAKIKAWA wrote: [...] > >>> With regard to the definition of MANET-local address, I am also > >>> not satisfied with the current definition. My proposal is as > >>> follows: MANET-local address an address having MANET-only scope > >>> that can be used to reach destinations in the MANET. All MANET > >>> interfaces have a MANET-local unicast address. > >> > >> I was asking what is the MANET-local scope? :-) How can you map > >> this manet-local into the current IPv6 scoping? Do you suggest to > >> define new address scope for MANET-local? > > > > There is this 'LL-MANET-Routers' address FF02:0:0:0:0:0:0:TBD4 > > defined in draft-ietf-manet-iana-07.txt. This address has link-local > > scope. A link-local scope is number '2', defined by RFC4291 "IPv6 > > Addressing Architecture". That RFC defines other scopes as well: 0, > > 1, 4, 5, 8, E, F. > > > > I'm not sure whether people really want/need to define another scope > > for MANET, not clear to me. > > > > My personal opinion is to go with already reserved scopes. > > I've been pointed out in private that maybe a permanent multicast Group > ID could be requested for use in MANET, following guidelines in RFC3307 > "IPv6 Multicast Address Guidelines". > > By my reading (could be wrong), an example would be to request Group ID > 0x7FFFFFFE (and have an Expert Review this). That could certainly be done. From http://www.iana.org/assignments/ipv6-multicast-addresses Variable Scope Multicast Addresses ---------------------------------- These permanently assigned multicast addresses are valid over all scope ranges. This is shown by an "X" in the scope field of the address that means any legal scope value. Note that, as defined in [RFC4291], IPv6 multicast addresses which are only different in scope represent different groups. Nodes must join each group individually. And, (from rfc4291) scop is a 4-bit multicast scope value used to limit the scope of the multicast group. The values are as follows: 0 reserved 1 Interface-Local scope 2 Link-Local scope 3 reserved 4 Admin-Local scope 5 Site-Local scope 6 (unassigned) 7 (unassigned) 8 Organization-Local scope 9 (unassigned) A (unassigned) B (unassigned) C (unassigned) D (unassigned) E Global scope F reserved So MANET could get an address set like : FF0X:0:0:0:0:0:0:133 This would represent 16 possible groups in total. (Note that the actual address would be assigned by IANA; I use this value just for example.) Would this request be part of an RFC ? Regards Marshall > > This Group ID would then be used within any of the defined IPv6 > multicast scopes: > > FF02::7FFF:FFFE - All MANET Routers on the same link > FF05::7FFF:FFFE - All MANET Routers on the same site > FF0E::7FFF:FFFE - All MANET Routers in the Internet > > This Group ID would probably also map into a Ethernet group address: > 33-33-7F-FF-FF-FE - IPv6 Neighbor Discovery - MANET > > Not sure having got this straight. > > Alex > > > > _______________________________________________ > 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 Dec 05 19:53:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J04zT-0001FQ-Qw; Wed, 05 Dec 2007 19:53:23 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1J04zS-0001Aa-DQ for autoconf-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 19:53:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J04zS-00018O-2D for autoconf@ietf.org; Wed, 05 Dec 2007 19:53:22 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J04zQ-0008TE-Oh for autoconf@ietf.org; Wed, 05 Dec 2007 19:53:22 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-153.messagelabs.com!1196902399!11998389!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 27558 invoked from network); 6 Dec 2007 00:53:19 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-153.messagelabs.com with SMTP; 6 Dec 2007 00:53:19 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lB60rJnt015771; Wed, 5 Dec 2007 17:53:19 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id lB60rIQh001093; Wed, 5 Dec 2007 18:53:18 -0600 (CST) Received: from [127.0.0.1] (mvp-10-19-249-241.corp.mot.com [10.19.249.241]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id lB60rHCc001077; Wed, 5 Dec 2007 18:53:18 -0600 (CST) Message-ID: <475747FD.7060306@gmail.com> Date: Wed, 05 Dec 2007 16:53:17 -0800 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Marshall Eubanks Subject: Re: [Autoconf] Re: scope of multicast address References: <7.0.0.16.2.20071202181233.04971348@ie.niigata-u.ac.jp> <62022ED1-47D5-4704-AC53-01738CD75027@gmail.com> <4754A8C5.8020804@gmail.com> <475723B6.5070401@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071205-2, 05/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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 Thanks for the message Marshall, Marshall Eubanks wrote: [...] >> By my reading (could be wrong), an example would be to request Group ID >> 0x7FFFFFFE (and have an Expert Review this). > > That could certainly be done. Great! > From > http://www.iana.org/assignments/ipv6-multicast-addresses That? > Variable Scope Multicast Addresses > ---------------------------------- > > These permanently assigned multicast addresses are valid over all scope > ranges. This is shown by an "X" in the scope field of the address that > means any legal scope value. > > Note that, as defined in [RFC4291], IPv6 multicast addresses which > are only different in scope represent different groups. Nodes must > join each group individually. > > And, (from rfc4291) scop is a 4-bit multicast scope value used to > limit the scope of > the multicast group. The values are as follows: > > 0 reserved > 1 Interface-Local scope > 2 Link-Local scope > 3 reserved > 4 Admin-Local scope > 5 Site-Local scope > 6 (unassigned) > 7 (unassigned) > 8 Organization-Local scope > 9 (unassigned) > A (unassigned) > B (unassigned) > C (unassigned) > D (unassigned) > E Global scope > F reserved > > So MANET could get an address set like : > > FF0X:0:0:0:0:0:0:133 > > This would represent 16 possible groups in total. Thanks, staying in the 'for example' discussion direction. For my understanding, I need to distinguish between a Permanent IPv6 Multicast Group Identifier (range 0x40000000-0x7fffffff) and a Permanent IPv6-only Multicast Address (0x100-0x3fffffff). You giving example '133' seems to me you mean an address (and not a Group ID). Is this so? I think there may be differences between these two possibilities, at least in which registry are they to be assigned: Group ID http://www.iana.org/assignments/perm-mcast-groupids or Address http://www.iana.org/assignments/ipv6-multicast-addresses You're obviously the expert to ask :-) Thanks, Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Dec 05 20:35:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J05eQ-0003ww-HA; Wed, 05 Dec 2007 20:35:42 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1J05eP-0003wk-QE for autoconf-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 20:35:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J05eP-0003wE-GM for autoconf@ietf.org; Wed, 05 Dec 2007 20:35:41 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J05eN-0003cI-83 for autoconf@ietf.org; Wed, 05 Dec 2007 20:35:41 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-128.messagelabs.com!1196904937!29086133!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 29702 invoked from network); 6 Dec 2007 01:35:38 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-128.messagelabs.com with SMTP; 6 Dec 2007 01:35:38 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lB61Zb9V023434; Wed, 5 Dec 2007 18:35:37 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id lB61ZbBh027461; Wed, 5 Dec 2007 19:35:37 -0600 (CST) Received: from [127.0.0.1] (mvp-10-19-249-241.corp.mot.com [10.19.249.241]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id lB61ZZPb027436; Wed, 5 Dec 2007 19:35:36 -0600 (CST) Message-ID: <475751E7.7070204@gmail.com> Date: Wed, 05 Dec 2007 17:35:35 -0800 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ian Chakeres Subject: Re: [Autoconf] About unique/non-overlapping prefixes terminology References: <1196893387.27208.64.camel@localhost> <374005f30712051441yac27531r96c55806e5c9a3d5@mail.gmail.com> In-Reply-To: <374005f30712051441yac27531r96c55806e5c9a3d5@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071205-2, 05/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 Ian Chakeres wrote: > Based on the confusion around "unique" I've removed the use of 'unique > prefix' from my local revision. I've replaced unique with distinct. > > Please let me know if you have another recommendation. > > Distinct Prefix Assignment > MANET interfaces that are known to exhibit the above mentioned > properties must be configured with distinct prefixes, for their > non-link-local addresses. The reason for this requirement is so that > no two MANET interfaces are configured to appear within the same IP > prefix. Can I assign 2001:db8::/32 on one interface and 2001:db8::/33 on another interfaces of a MANET Router? The prefixes seem distinct to me. Can I assign 2001:db8::/32 on one interface and fd67:39d:7a3a::/32 on another? They look distinct to me. Just wanted to make sure for those two examples, thanks. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Dec 05 21:09:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J06BD-0001cB-Gm; Wed, 05 Dec 2007 21:09:35 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1J06BC-0001c0-DN for autoconf-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 21:09:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J06BC-0001bp-32 for autoconf@ietf.org; Wed, 05 Dec 2007 21:09:34 -0500 Received: from mail4-relais-sop.national.inria.fr ([192.134.164.105]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J06BB-00039b-Kq for autoconf@ietf.org; Wed, 05 Dec 2007 21:09:33 -0500 X-IronPort-AV: E=Sophos;i="4.23,257,1194217200"; d="scan'208";a="20027409" Received: from dhcp-4239.ietf70.org ([130.129.66.57]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Dec 2007 03:09:31 +0100 Message-ID: <475759DA.4020004@inria.fr> Date: Thu, 06 Dec 2007 03:09:30 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: autoconf@ietf.org Subject: Re: [Autoconf] About unique/non-overlapping prefixes terminology References: <1196893387.27208.64.camel@localhost> <374005f30712051441yac27531r96c55806e5c9a3d5@mail.gmail.com> <475751E7.7070204@gmail.com> In-Reply-To: <475751E7.7070204@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 Alex, Alexandru Petrescu a écrit : > Ian Chakeres wrote: >> Based on the confusion around "unique" I've removed the use of 'unique >> prefix' from my local revision. I've replaced unique with distinct. >> >> Please let me know if you have another recommendation. >> >> Distinct Prefix Assignment >> MANET interfaces that are known to exhibit the above mentioned >> properties must be configured with distinct prefixes, for their >> non-link-local addresses. The reason for this requirement is so that >> no two MANET interfaces are configured to appear within the same IP >> prefix. > > Can I assign 2001:db8::/32 on one interface and 2001:db8::/33 on another > interfaces of a MANET Router? The prefixes seem distinct to me. > well look again. These are obviously not distinct CIDR blocks, since one is contained in the other! > Can I assign 2001:db8::/32 on one interface and fd67:39d:7a3a::/32 on > another? They look distinct to me. there we agree. Emmanuel > > Just wanted to make sure for those two examples, thanks. > > Alex > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > > _______________________________________________ > 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 Dec 05 21:17:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J06IT-0003r8-M6; Wed, 05 Dec 2007 21:17:05 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1J06IR-0003qr-Qe for autoconf-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 21:17:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J06IR-0003qh-Fb for autoconf@ietf.org; Wed, 05 Dec 2007 21:17:03 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J06IQ-0003ju-Tx for autoconf@ietf.org; Wed, 05 Dec 2007 21:17:03 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-153.messagelabs.com!1196907421!12005638!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 18008 invoked from network); 6 Dec 2007 02:17:01 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-153.messagelabs.com with SMTP; 6 Dec 2007 02:17:01 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lB62H1VH001928; Wed, 5 Dec 2007 19:17:01 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id lB62H0q3005952; Wed, 5 Dec 2007 20:17:00 -0600 (CST) Received: from [127.0.0.1] (mvp-10-19-249-241.corp.mot.com [10.19.249.241]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id lB62Gv8g005880; Wed, 5 Dec 2007 20:17:00 -0600 (CST) Message-ID: <47575B98.8010106@gmail.com> Date: Wed, 05 Dec 2007 18:16:56 -0800 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Emmanuel Baccelli Subject: Re: [Autoconf] About unique/non-overlapping prefixes terminology References: <1196893387.27208.64.camel@localhost> <374005f30712051441yac27531r96c55806e5c9a3d5@mail.gmail.com> <475751E7.7070204@gmail.com> <475759DA.4020004@inria.fr> In-Reply-To: <475759DA.4020004@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 071205-2, 05/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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 Emmanuel Baccelli wrote: > Alex, > > Alexandru Petrescu a écrit : >> Ian Chakeres wrote: >>> Based on the confusion around "unique" I've removed the use of 'unique >>> prefix' from my local revision. I've replaced unique with distinct. >>> >>> Please let me know if you have another recommendation. >>> >>> Distinct Prefix Assignment >>> MANET interfaces that are known to exhibit the above mentioned >>> properties must be configured with distinct prefixes, for their >>> non-link-local addresses. The reason for this requirement is so that >>> no two MANET interfaces are configured to appear within the same IP >>> prefix. >> >> Can I assign 2001:db8::/32 on one interface and 2001:db8::/33 on >> another interfaces of a MANET Router? The prefixes seem distinct to me. >> > > well look again. These are obviously not distinct CIDR blocks, since one > is contained in the other! I think we may have a clear contentious problem here :-) I believe these two prefixes are distinct and could as such be assigned ok on two real Ethernet interfaces of a router. Especially if these two prefixes are managed by other routers (but still assigned on the two interfaces of same router). There are a few ways out of this: -say that a MANET Router does not consider these two prefixes distinct. -say that two MANET Interfaces do not consider these two prefixes distinct. -say there may be a multilink issue problem with these two prefixes on two interfaces of same Router. -say that they are distinct. You think of other ways out of this? Alex >> Can I assign 2001:db8::/32 on one interface and fd67:39d:7a3a::/32 on >> another? They look distinct to me. > > there we agree. > Emmanuel > >> >> Just wanted to make sure for those two examples, thanks. >> >> Alex >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> ______________________________________________________________________ >> >> >> _______________________________________________ >> 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 > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Dec 05 21:39:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J06dj-0006Hy-3m; Wed, 05 Dec 2007 21:39:03 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1J06dh-0006Hl-0v for autoconf-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 21:39:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J06dg-0006Ha-NG for autoconf@ietf.org; Wed, 05 Dec 2007 21:39:00 -0500 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J06dg-00008N-8v for autoconf@ietf.org; Wed, 05 Dec 2007 21:39:00 -0500 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id lB62cvgf010608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Dec 2007 18:38:57 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id lB62cunh012695; Wed, 5 Dec 2007 18:38: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.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id lB62cuxF012692; Wed, 5 Dec 2007 18:38:56 -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, 5 Dec 2007 18:38:56 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Autoconf] About unique/non-overlapping prefixes terminology Date: Wed, 5 Dec 2007 18:38:56 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029EDC9F@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <475759DA.4020004@inria.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] About unique/non-overlapping prefixes terminology Thread-Index: Acg3rQ7ljkdadnO0R4iiBJmT1V+TNwAA9+cg References: <1196893387.27208.64.camel@localhost> <374005f30712051441yac27531r96c55806e5c9a3d5@mail.gmail.com><475751E7.7070204@gmail.com> <475759DA.4020004@inria.fr> From: "Templin, Fred L" To: "Emmanuel Baccelli" , X-OriginalArrivalTime: 06 Dec 2007 02:38:56.0680 (UTC) FILETIME=[26072280:01C837B1] X-Spam-Score: -4.0 (----) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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 =20 > -----Original Message----- > From: Emmanuel Baccelli [mailto:Emmanuel.Baccelli@inria.fr]=20 > Sent: Wednesday, December 05, 2007 6:10 PM > To: autoconf@ietf.org > Subject: Re: [Autoconf] About unique/non-overlapping prefixes=20 > terminology >=20 > Alex, >=20 > Alexandru Petrescu a =E9crit : > > Ian Chakeres wrote: > >> Based on the confusion around "unique" I've removed the=20 > use of 'unique > >> prefix' from my local revision. I've replaced unique with distinct. > >> > >> Please let me know if you have another recommendation. > >> > >> Distinct Prefix Assignment > >> MANET interfaces that are known to exhibit the above mentioned > >> properties must be configured with distinct prefixes, for their > >> non-link-local addresses. The reason for this requirement=20 > is so that > >> no two MANET interfaces are configured to appear within the same IP > >> prefix. > >=20 > > Can I assign 2001:db8::/32 on one interface and 2001:db8::/33 on = another=20 > > interfaces of a MANET Router? The prefixes seem distinct to me. > >=20 >=20 > well look again. These are obviously not distinct CIDR blocks, since = one=20 > is contained in the other! I agree, and IMHO it is clear what is meant by distinct or not. Fred fred.l.templin@boeing.com > > Can I assign 2001:db8::/32 on one interface and=20 > fd67:39d:7a3a::/32 on=20 > > another? They look distinct to me. >=20 > there we agree. > Emmanuel >=20 > >=20 > > Just wanted to make sure for those two examples, thanks. > >=20 > > Alex > >=20 > >=20 > >=20 > ______________________________________________________________________ > > This email has been scanned by the MessageLabs Email=20 > Security System. > > For more information please visit http://www.messagelabs.com/email=20 > >=20 > ______________________________________________________________________ > >=20 > >=20 > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > https://www1.ietf.org/mailman/listinfo/autoconf > >=20 > >=20 >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf >=20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Dec 05 21:44:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J06jA-0002fc-Qf; Wed, 05 Dec 2007 21:44:40 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1J06j9-0002eb-UG for autoconf-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 21:44:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J06j9-0002eQ-Ii for autoconf@ietf.org; Wed, 05 Dec 2007 21:44:39 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J06j8-0005wi-Ti for autoconf@ietf.org; Wed, 05 Dec 2007 21:44:39 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-128.messagelabs.com!1196909077!1262122!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 12308 invoked from network); 6 Dec 2007 02:44:37 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-128.messagelabs.com with SMTP; 6 Dec 2007 02:44:37 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lB62ibdY007437; Wed, 5 Dec 2007 19:44:37 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id lB62iacf007575; Wed, 5 Dec 2007 20:44:36 -0600 (CST) Received: from [127.0.0.1] (mvp-10-19-249-241.corp.mot.com [10.19.249.241]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id lB62iZX1007558; Wed, 5 Dec 2007 20:44:35 -0600 (CST) Message-ID: <47576215.9080000@gmail.com> Date: Wed, 05 Dec 2007 18:44:37 -0800 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: cjbc@it.uc3m.es Subject: Re: [Autoconf] List of requirements in draft-ietf-autoconf-problem-statement References: <1196895350.27208.93.camel@localhost> In-Reply-To: <1196895350.27208.93.camel@localhost> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 071205-2, 05/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a 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 Carlos Jesús Bernardos Cano wrote: > Hi all, > > As expressed by me and others, it may be helpful to add a list of > clear requirements of MANET IP autoconf mechanisms in the problem > statement draft. This would help to understand what (and maybe how) > has to be done to solve the problem of IP autoconf in MANETs. > > Collecting this list is not easy, and therefore this mail is a humble > attempt to get other people's opinion and start discussing what this > list should contain. To start, I'd propose the following: > > R01. The solution must be implemented at the IP layer level. Sounds good. More specifically would be: implement in the IP stack, not the MAC. To me, I don't know others. > (Following recent discussions, my understanding is that we are > working at the IP layer...) > > R02. The solution must provide a MANET Router with an IPv6 address > for each of its MANET interfaces. Reasonable. > R03. The solution must provide a MANET Router with an IPv6 prefix to > configure each of its non-MANET interfaces and be advertised for > configuration of non-MANET attached nodes. Sounds as modifiable. One would want a 'distinct' (see the other thread) prefix for each of these interfaces. Sounds as colliding with the MEXT WG looking at providing an IPv6 prefix for use as prefix in the moving network. That could be collision or happy coexistence. > R04. The solution must work for MANETs using symmetric and assymetric > links. Sounds ok. > R05. The solution should not be independent of any particular MANET > routing protocol. Right. > R06. The solution must provide MANET routers with unique addresses > and non-overlapping IPv6 prefixes. Ok, provided we can qualify these with examples. > R07. The solution should detect and resolve IP address conflicts as a > result of network mergers. Sounds reasonable. Not sure though whether there should be a mechanism for detection or some insurance from a registry. For example I as humble seller of MANETs I preconfigure them all with distinct addresses. Is this a mechanism, or a central assignment (ULA is an example). > R08. The solution must provide MANET routers with IPv6 > addresses/prefixes topologically correct/coherent when the MANET is > connected to an external network (e.g., the Internet). Right. > R09. The solution should present the same level of security than > existing IP autoconfiguration mechanisms. Sounds reasonable, and I'd enhance it with the 'do no harm' statement (don't add more insecurity than already is there). This could be refined further by a threat analysis. > R10. The solution must ensure backward compatibility with other > standards defined by the IETF. In particular, this includes the > following: > > R10.1. The solution must not prevent the proper operation of Mobile > IPv6 (i.e., the solution must allow MIPv6-enabled nodes attached to a > MANET router to operate either the CN, HA, or MN operations defined > in [RFC3775]). ok. > R11. The solution must not require modifications to any node other > than MANET routers and required provisioning servers. Sounds good, excellent to identify the entities we work on. But 'provisioning servers' is? (sounds new term to me). > R12. The solution may be designed in such a modular way that some of > the previous requirements are not met if not required by a > particular application scenario. Ha! I'd suggest R13 to recommend extension/modification of widely available software. For discussion, of course. > As previously stated, this is mainly for discussion. I'm not even > saying I agree with all of them ;-). I agree with the form of such a list, and I find it pretty useful actually. I would be very happy to learn others' opinions on this - thanks for starting it! Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Dec 05 21:48:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J06mS-0007wg-FL; Wed, 05 Dec 2007 21:48:04 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1J06mQ-0007og-KJ for autoconf-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 21:48:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J06mQ-0007nl-9F for autoconf@ietf.org; Wed, 05 Dec 2007 21:48:02 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J06mP-0006CO-NW for autoconf@ietf.org; Wed, 05 Dec 2007 21:48:02 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-153.messagelabs.com!1196909280!4872891!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 19930 invoked from network); 6 Dec 2007 02:48:00 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-153.messagelabs.com with SMTP; 6 Dec 2007 02:48:00 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lB62m0DQ008052; Wed, 5 Dec 2007 19:48:00 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id lB62lxuC023704; Wed, 5 Dec 2007 20:47:59 -0600 (CST) Received: from [127.0.0.1] (mvp-10-19-249-241.corp.mot.com [10.19.249.241]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id lB62lvta023687; Wed, 5 Dec 2007 20:47:58 -0600 (CST) Message-ID: <475762DF.8050502@gmail.com> Date: Wed, 05 Dec 2007 18:47:59 -0800 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Templin, Fred L" Subject: Re: [Autoconf] About unique/non-overlapping prefixes terminology References: <1196893387.27208.64.camel@localhost> <374005f30712051441yac27531r96c55806e5c9a3d5@mail.gmail.com><475751E7.7070204@gmail.com> <475759DA.4020004@inria.fr> <39C363776A4E8C4A94691D2BD9D1C9A1029EDC9F@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029EDC9F@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 071205-2, 05/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: autoconf@ietf.org, Emmanuel Baccelli 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 Templin, Fred L wrote: > > >> -----Original Message----- >> From: Emmanuel Baccelli [mailto:Emmanuel.Baccelli@inria.fr] >> Sent: Wednesday, December 05, 2007 6:10 PM >> To: autoconf@ietf.org >> Subject: Re: [Autoconf] About unique/non-overlapping prefixes >> terminology >> >> Alex, >> >> Alexandru Petrescu a écrit : >>> Ian Chakeres wrote: >>>> Based on the confusion around "unique" I've removed the >> use of 'unique >>>> prefix' from my local revision. I've replaced unique with distinct. >>>> >>>> Please let me know if you have another recommendation. >>>> >>>> Distinct Prefix Assignment >>>> MANET interfaces that are known to exhibit the above mentioned >>>> properties must be configured with distinct prefixes, for their >>>> non-link-local addresses. The reason for this requirement >> is so that >>>> no two MANET interfaces are configured to appear within the same IP >>>> prefix. >>> Can I assign 2001:db8::/32 on one interface and 2001:db8::/33 on another >>> interfaces of a MANET Router? The prefixes seem distinct to me. >>> >> well look again. These are obviously not distinct CIDR blocks, since one >> is contained in the other! > > I agree, and IMHO it is clear what is meant by distinct > or not. Is 2001:db8::/24 contained in 2001:db8::/32? I'd say yes. Are they distinct? I'd say yes too. Alex > > Fred > fred.l.templin@boeing.com > >>> Can I assign 2001:db8::/32 on one interface and >> fd67:39d:7a3a::/32 on >>> another? They look distinct to me. >> there we agree. >> Emmanuel >> >>> Just wanted to make sure for those two examples, thanks. >>> >>> Alex >>> >>> >>> >> ______________________________________________________________________ >>> This email has been scanned by the MessageLabs Email >> Security System. >>> For more information please visit http://www.messagelabs.com/email >>> >> ______________________________________________________________________ >>> >>> _______________________________________________ >>> 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 > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Dec 06 12:23:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0KRJ-00084k-2g; Thu, 06 Dec 2007 12:23:09 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1J0KRI-00084d-5p for autoconf-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 12:23:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0KRH-00084V-SE for autoconf@ietf.org; Thu, 06 Dec 2007 12:23:07 -0500 Received: from smtp01.uc3m.es ([163.117.176.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0KRG-00084Y-3F for autoconf@ietf.org; Thu, 06 Dec 2007 12:23:07 -0500 Received: from [130.129.19.231] (dhcp-13e7.ietf70.org [130.129.19.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 45CAE27E2D9; Thu, 6 Dec 2007 18:23:04 +0100 (CET) Subject: Re: [Autoconf] List of requirements in draft-ietf-autoconf-problem-statement From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Alexandru Petrescu In-Reply-To: <47576215.9080000@gmail.com> References: <1196895350.27208.93.camel@localhost> <47576215.9080000@gmail.com> Organization: Universidad Carlos III de Madrid Date: Thu, 06 Dec 2007 18:23:01 +0100 Message-Id: <1196961781.27208.127.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 X-Spam-Score: -4.0 (----) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0669907755==" Errors-To: autoconf-bounces@ietf.org --===============0669907755== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-PDWqs/ehUsx4/PVo8gLQ" --=-PDWqs/ehUsx4/PVo8gLQ Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Alex, Just a reply to your question below... El mi=E9, 05-12-2007 a las 18:44 -0800, Alexandru Petrescu escribi=F3: [snip] > > R11. The solution must not require modifications to any node other=20 > > than MANET routers and required provisioning servers. >=20 > Sounds good, excellent to identify the entities we work on. But > 'provisioning servers' is? (sounds new term to me). Well, I tried to mean servers, such as DHCPv6 servers or something like this that might be considered to participate in the address configuration procedure. Sorry for the new terminology, I didn't know how to call that. Regards, Carlos --=20 =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WEEDEV 2008: 1st Workshop on Experimental Evaluation and Deployment Experiences on Vehicular networks http://www.weedev.org/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-PDWqs/ehUsx4/PVo8gLQ Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHWC/1Ndy6TdFwT2cRAlXLAJwJDFRO9fZZ4gxLzUWpIV8Xgxf5ogCgge9m c+wA74jZ+pWld8sZEEs5tIY= =2l03 -----END PGP SIGNATURE----- --=-PDWqs/ehUsx4/PVo8gLQ-- --===============0669907755== 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 --===============0669907755==-- From autoconf-bounces@ietf.org Thu Dec 06 12:38:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0KgL-0001CV-Pn; Thu, 06 Dec 2007 12:38:41 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1J0KgL-000192-6G for autoconf-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 12:38:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0KgK-00018t-Qk for autoconf@ietf.org; Thu, 06 Dec 2007 12:38:40 -0500 Received: from smtp02.uc3m.es ([163.117.176.132]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0KgK-0007Uv-24 for autoconf@ietf.org; Thu, 06 Dec 2007 12:38:40 -0500 Received: from [130.129.19.231] (dhcp-13e7.ietf70.org [130.129.19.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id DB5B32A2EA6; Thu, 6 Dec 2007 18:38:37 +0100 (CET) Subject: Re: [Autoconf] About unique/non-overlapping prefixes terminology From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Alexandru Petrescu In-Reply-To: <47575B98.8010106@gmail.com> References: <1196893387.27208.64.camel@localhost> <374005f30712051441yac2753 1r96c55806e5c9a3d5@mail.gmail.com> <475751E7.7070204@gmail.com><475759DA.4020004@inria.fr> <47575B98.8010106@gmail.com> Organization: Universidad Carlos III de Madrid Date: Thu, 06 Dec 2007 18:38:30 +0100 Message-Id: <1196962710.27208.138.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 X-Spam-Score: 1.8 (+) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: autoconf@ietf.org, Emmanuel Baccelli X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0668280225==" Errors-To: autoconf-bounces@ietf.org --===============0668280225== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Sei4nb7vcb/xPhKi6mPv" --=-Sei4nb7vcb/xPhKi6mPv Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Alex, El mi=E9, 05-12-2007 a las 18:16 -0800, Alexandru Petrescu escribi=F3: > Emmanuel Baccelli wrote: > > Alex, > >=20 > > Alexandru Petrescu a =E9crit : > >> Ian Chakeres wrote: > >>> Based on the confusion around "unique" I've removed the use of 'uniqu= e > >>> prefix' from my local revision. I've replaced unique with distinct. > >>> > >>> Please let me know if you have another recommendation. > >>> > >>> Distinct Prefix Assignment > >>> MANET interfaces that are known to exhibit the above mentioned > >>> properties must be configured with distinct prefixes, for their > >>> non-link-local addresses. The reason for this requirement is so that > >>> no two MANET interfaces are configured to appear within the same IP > >>> prefix. > >> > >> Can I assign 2001:db8::/32 on one interface and 2001:db8::/33 on=20 > >> another interfaces of a MANET Router? The prefixes seem distinct to m= e. > >> > >=20 > > well look again. These are obviously not distinct CIDR blocks, since on= e=20 > > is contained in the other! >=20 > I think we may have a clear contentious problem here :-) I believe=20 > these two prefixes are distinct and could as such be assigned ok on two=20 > real Ethernet interfaces of a router. Especially if these two prefixes=20 > are managed by other routers (but still assigned on the two interfaces=20 > of same router). I think I disagree here. IMHO, it would not be ok to assign these addresses on two real Ethernet interfaces of a router. If there is a host attached to one of these interfaces, and the IPv6 address of this host is, let's say 2001:db8::3, how does the router know to which interface should deliver a packet addressed to 2001:db8::3? I guess the router will try to deliver this packet though the interface configured as 2001:db8::/33 (longest prefix match), but the host maybe as well attached to the other interface, right?. Maybe it's a stupid question and I'm missing something, sorry for the question. Thanks, Carlos >=20 > There are a few ways out of this: > -say that a MANET Router does not consider these two prefixes distinct. > -say that two MANET Interfaces do not consider these two prefixes > distinct. > -say there may be a multilink issue problem with these two prefixes on > two interfaces of same Router. > -say that they are distinct. >=20 > You think of other ways out of this? >=20 > Alex >=20 > >> Can I assign 2001:db8::/32 on one interface and fd67:39d:7a3a::/32 on=20 > >> another? They look distinct to me. > >=20 > > there we agree. > > Emmanuel > >=20 > >> > >> Just wanted to make sure for those two examples, thanks. > >> > >> Alex > >> > >> > >> ______________________________________________________________________ > >> This email has been scanned by the MessageLabs Email Security System. > >> For more information please visit http://www.messagelabs.com/email=20 > >> ______________________________________________________________________ > >> > >> > >> _______________________________________________ > >> Autoconf mailing list > >> Autoconf@ietf.org > >> https://www1.ietf.org/mailman/listinfo/autoconf > >> > >> > >=20 > >=20 > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > https://www1.ietf.org/mailman/listinfo/autoconf > >=20 >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf --=20 =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WEEDEV 2008: 1st Workshop on Experimental Evaluation and Deployment Experiences on Vehicular networks http://www.weedev.org/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-Sei4nb7vcb/xPhKi6mPv Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHWDOWNdy6TdFwT2cRAmtEAKCCBPHCpqieB5JI8QMUYVkC6UfqxgCgpAk8 PnnROZJrZlWjl1TnrXxsdaQ= =Z3Js -----END PGP SIGNATURE----- --=-Sei4nb7vcb/xPhKi6mPv-- --===============0668280225== 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 --===============0668280225==-- From autoconf-bounces@ietf.org Thu Dec 06 12:44:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Klm-00086q-MG; Thu, 06 Dec 2007 12:44:18 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1J0Kll-00086Q-Sp for autoconf-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 12:44:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Kll-00086I-JA for autoconf@ietf.org; Thu, 06 Dec 2007 12:44:17 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J0Kll-0001QN-4U for autoconf@ietf.org; Thu, 06 Dec 2007 12:44:17 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-153.messagelabs.com!1196963055!18490571!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 5195 invoked from network); 6 Dec 2007 17:44:16 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-11.tower-153.messagelabs.com with SMTP; 6 Dec 2007 17:44:16 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id lB6HiFN9013948; Thu, 6 Dec 2007 10:44:15 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id lB6HiER0018322; Thu, 6 Dec 2007 11:44:15 -0600 (CST) Received: from [127.0.0.1] (mvp-10-19-248-44.corp.mot.com [10.19.248.44]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id lB6HiCRw018302; Thu, 6 Dec 2007 11:44:13 -0600 (CST) Message-ID: <475834EB.5070508@gmail.com> Date: Thu, 06 Dec 2007 09:44:11 -0800 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: cjbc@it.uc3m.es Subject: Re: [Autoconf] List of requirements in draft-ietf-autoconf-problem-statement References: <1196895350.27208.93.camel@localhost> <47576215.9080000@gmail.com> <1196961781.27208.127.camel@localhost> In-Reply-To: <1196961781.27208.127.camel@localhost> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 071205-2, 05/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 Carlos Jesús Bernardos Cano wrote: > Hi Alex, > > Just a reply to your question below... > > El mié, 05-12-2007 a las 18:44 -0800, Alexandru Petrescu escribió: > [snip] >>> R11. The solution must not require modifications to any node other >>> than MANET routers and required provisioning servers. >> Sounds good, excellent to identify the entities we work on. But >> 'provisioning servers' is? (sounds new term to me). > > Well, I tried to mean servers, such as DHCPv6 servers or something like > this that might be considered to participate in the address > configuration procedure. Sorry for the new terminology, I didn't know > how to call that. Sounds like we need a name for that? Looks as if the MANET Router is the one who's going to use the addresses and prefixes delivered by a Server. Or maybe even if the address and prefix are to be used by the MANET Router, they are constructed in conjunction by the MANET Router and the Server. That Server seems an important entity. Maybe another MANET Router can be a Server. Alex > > Regards, > > Carlos > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Dec 06 13:35:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0LZe-0003l9-HP; Thu, 06 Dec 2007 13:35:50 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1J0LZd-0003l3-GF for autoconf-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 13:35:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0LZd-0003ku-6J for autoconf@ietf.org; Thu, 06 Dec 2007 13:35:49 -0500 Received: from server9.hosting2go.nl ([83.137.192.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0LZb-0006IU-Ag for autoconf@ietf.org; Thu, 06 Dec 2007 13:35:49 -0500 Received: (qmail 1939 invoked from network); 6 Dec 2007 19:35:45 +0100 Received: from unknown (HELO M90Teco) (130.129.82.92) by server9.hosting2go.nl with SMTP; 6 Dec 2007 19:35:44 +0100 From: "Teco Boot" To: , "'Alexandru Petrescu'" References: <1196893387.27208.64.camel@localhost> <374005f30712051441yac2753 1r96c55806e5c9a3d5@mail.gmail.com> <475751E7.7070204@gmail.com><475759DA.4020004@inria.fr> <47575B98.8010106@gmail.com> <1196962710.27208.138.camel@localhost> In-Reply-To: <1196962710.27208.138.camel@localhost> Subject: RE: [Autoconf] About unique/non-overlapping prefixes terminology Date: Thu, 6 Dec 2007 19:35:09 +0100 Message-ID: <00f001c83836$ced53d90$6c7fb8b0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg4Lu0+OygbDovXTxSS7K0DxLuNkwABSK4w Content-Language: nl X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: autoconf@ietf.org, 'Emmanuel Baccelli' 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 I would use terms unique address and non-overlapping prefix. I think these terms are well known. I think routers SHOULD NOT use overlapping prefixes and SHOULD NOT use duplicate addresses. Non-unique addresses are allowed, i.e. anycast. These are not autoconfigured. Anycast is overlapping prefixes also. Mostly one anycast address per link, to circumvent problems with ND. Another use case for duplicate addresses is router redundancy, e.g. VRRP. Only one address is active in this case. Also not autoconfigured. In NEMO, prefixes overlap. HA on home link has a prefix, this overlaps with MNP. NEMO MRHA tunnel associates those two. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Dec 06 13:41:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0LfU-000899-Nn; Thu, 06 Dec 2007 13:41:52 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1J0LfU-00085z-8h for autoconf-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 13:41:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0LfT-00083x-Uc for autoconf@ietf.org; Thu, 06 Dec 2007 13:41:51 -0500 Received: from smtp01.uc3m.es ([163.117.176.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0LfT-0006nI-DV for autoconf@ietf.org; Thu, 06 Dec 2007 13:41:51 -0500 Received: from [130.129.19.231] (dhcp-13e7.ietf70.org [130.129.19.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 7D9D827EFD4; Thu, 6 Dec 2007 19:41:49 +0100 (CET) Subject: RE: [Autoconf] About unique/non-overlapping prefixes terminology From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Teco Boot In-Reply-To: <00f001c83836$ced53d90$6c7fb8b0$@nl> References: <1196893387.27208.64.camel@localhost> <374005f30712051441yac2753 1r96c55806e5c9a3d5@mail.gmail.com> <475751E7.7070204@gmail.com><475759DA.4 020004@inria.fr> <47575B98.8010106@gmail.com> <1196962710.27208.138.camel@localhost> <00f001c83836$ced53d90$6c7fb8b0$@nl> Organization: Universidad Carlos III de Madrid Date: Thu, 06 Dec 2007 19:41:47 +0100 Message-Id: <1196966507.27208.160.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 X-Spam-Score: -4.0 (----) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: autoconf@ietf.org, 'Emmanuel Baccelli' X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0194207930==" Errors-To: autoconf-bounces@ietf.org --===============0194207930== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-vE9JRfs8wOT4AD6DPesy" --=-vE9JRfs8wOT4AD6DPesy Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Teco, El jue, 06-12-2007 a las 19:35 +0100, Teco Boot escribi=F3: > I would use terms unique address and non-overlapping prefix. > I think these terms are well known. >=20 > I think routers SHOULD NOT use overlapping prefixes and SHOULD NOT use > duplicate addresses. >=20 > Non-unique addresses are allowed, i.e. anycast. These are not > autoconfigured. > Anycast is overlapping prefixes also. Mostly one anycast address per link= , > to circumvent problems with ND. > Another use case for duplicate addresses is router redundancy, e.g. VRRP. > Only one address is active in this case. Also not autoconfigured. >=20 > In NEMO, prefixes overlap. HA on home link has a prefix, this overlaps wi= th > MNP. NEMO MRHA tunnel associates those two. Just a comment, in NEMO prefixes may overlap/be aggregated, but it's not the only possibility. RFC4887 documents that. Regards, Carlos >=20 > Teco. >=20 --=20 =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WEEDEV 2008: 1st Workshop on Experimental Evaluation and Deployment Experiences on Vehicular networks http://www.weedev.org/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-vE9JRfs8wOT4AD6DPesy Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHWEJrNdy6TdFwT2cRAug9AJ0b/VDskBTasqrYCM4XgnIot4GF8wCgnd2G 2eiKZQdlPYWP2aScWKgg8fE= =b0jx -----END PGP SIGNATURE----- --=-vE9JRfs8wOT4AD6DPesy-- --===============0194207930== 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 --===============0194207930==-- From autoconf-bounces@ietf.org Thu Dec 06 14:02:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Lzd-0005wl-MW; Thu, 06 Dec 2007 14:02:41 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1J0Lzb-0005t5-Sq for autoconf-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 14:02:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Lzb-0005rg-HN for autoconf@ietf.org; Thu, 06 Dec 2007 14:02:39 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J0Lza-0006ej-UU for autoconf@ietf.org; Thu, 06 Dec 2007 14:02:39 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-153.messagelabs.com!1196967757!12771154!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 9722 invoked from network); 6 Dec 2007 19:02:37 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-6.tower-153.messagelabs.com with SMTP; 6 Dec 2007 19:02:37 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id lB6J2aPx005678; Thu, 6 Dec 2007 12:02:37 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id lB6J2aw2028531; Thu, 6 Dec 2007 13:02:36 -0600 (CST) Received: from [127.0.0.1] ([10.19.236.139]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id lB6J2YBu028508; Thu, 6 Dec 2007 13:02:34 -0600 (CST) Message-ID: <47584749.8090404@gmail.com> Date: Thu, 06 Dec 2007 11:02:33 -0800 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: cjbc@it.uc3m.es Subject: Re: [Autoconf] About unique/non-overlapping prefixes terminology References: <1196893387.27208.64.camel@localhost> <374005f30712051441yac2753 1r96c55806e5c9a3d5@mail.gmail.com> <475751E7.7070204@gmail.com><475759DA.4020004@inria.fr> <47575B98.8010106@gmail.com> <1196962710.27208.138.camel@localhost> In-Reply-To: <1196962710.27208.138.camel@localhost> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 071205-2, 05/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: autoconf@ietf.org, Emmanuel Baccelli 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 Carlos Jesús Bernardos Cano wrote: >>> Alexandru Petrescu a écrit : >>>> Ian Chakeres wrote: >>>>> Based on the confusion around "unique" I've removed the use >>>>> of 'unique prefix' from my local revision. I've replaced >>>>> unique with distinct. >>>>> >>>>> Please let me know if you have another recommendation. >>>>> >>>>> Distinct Prefix Assignment MANET interfaces that are known to >>>>> exhibit the above mentioned properties must be configured >>>>> with distinct prefixes, for their non-link-local addresses. >>>>> The reason for this requirement is so that no two MANET >>>>> interfaces are configured to appear within the same IP >>>>> prefix. >>>> Can I assign 2001:db8::/32 on one interface and 2001:db8::/33 >>>> on another interfaces of a MANET Router? The prefixes seem >>>> distinct to me. >>>> >>> well look again. These are obviously not distinct CIDR blocks, >>> since one is contained in the other! >> I think we may have a clear contentious problem here :-) I believe >> these two prefixes are distinct and could as such be assigned ok >> on two real Ethernet interfaces of a router. Especially if these >> two prefixes are managed by other routers (but still assigned on >> the two interfaces of same router). > > I think I disagree here. IMHO, it would not be ok to assign these > addresses on two real Ethernet interfaces of a router. We may have terminology problem :-) Assigning a prefix to an interface with ifconfig also adds an entry in the routing table... which part do we disagree on? > If there is a host attached to one of these interfaces, and the IPv6 > address of this host is, let's say 2001:db8::3, how does the router > know to which interface should deliver a packet addressed to > 2001:db8::3? I guess the router will try to deliver this packet > though the interface configured as 2001:db8::/33 (longest prefix > match), Right, that's what router would do. > but the host maybe as well attached to the other interface, right?. Same host attached to two interfaces of a router? Or do you mean there may be two different hosts, each connected on one of the router's interfaces? I guess this latter? In this latter case: I wouldn't recommend two different hosts attached to two interfaces of a router to use the same 2001:db8::3 address. That's just a recommendation and people could configure the way they wish. Doing that configuration (2001:db8::3 assigned to two different hosts) is not necessarily prohibited by the assumed aggregation of prefixes nor by the routing system. Not sure how to say this better. What if there is no host attached to the router's interface, but just routers. What if one interface is the 'upstream', 'egress' interface and the other interface is the 'downstream', 'ingress' interface. Like this: | | upstream 2001:db8::/32 ------------ |MANET Router| ------------ | downstream 2001:db8::/33 | Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Dec 06 14:08:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0M51-0002dG-Eb; Thu, 06 Dec 2007 14:08:15 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1J0M50-0002d9-32 for autoconf-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 14:08:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0M4z-0002d0-OS for autoconf@ietf.org; Thu, 06 Dec 2007 14:08:13 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J0M4z-00077X-9x for autoconf@ietf.org; Thu, 06 Dec 2007 14:08:13 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-128.messagelabs.com!1196968091!1385610!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 24274 invoked from network); 6 Dec 2007 19:08:11 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-128.messagelabs.com with SMTP; 6 Dec 2007 19:08:11 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lB6J8BZE015786; Thu, 6 Dec 2007 12:08:11 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id lB6J8AhN012854; Thu, 6 Dec 2007 13:08:10 -0600 (CST) Received: from [127.0.0.1] ([10.19.236.139]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id lB6J89jv012844; Thu, 6 Dec 2007 13:08:09 -0600 (CST) Message-ID: <47584898.8090302@gmail.com> Date: Thu, 06 Dec 2007 11:08:08 -0800 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Teco Boot Subject: Re: [Autoconf] About unique/non-overlapping prefixes terminology References: <1196893387.27208.64.camel@localhost> <374005f30712051441yac2753 1r96c55806e5c9a3d5@mail.gmail.com> <475751E7.7070204@gmail.com><475759DA.4020004@inria.fr> <47575B98.8010106@gmail.com> <1196962710.27208.138.camel@localhost> <00f001c83836$ced53d90$6c7fb8b0$@nl> In-Reply-To: <00f001c83836$ced53d90$6c7fb8b0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071205-2, 05/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: autoconf@ietf.org, 'Emmanuel Baccelli' 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 Teco Boot wrote: > I would use terms unique address and non-overlapping prefix. I think > these terms are well known. > > I think routers SHOULD NOT use overlapping prefixes and SHOULD NOT > use duplicate addresses. Well I think they all use overlapping prefixes. Most prefixes overlap up to some bit limit. The only example of completely non-overlapping prefixes I can think of are the ones differing in the first bit (eg 2001:db8::/32 and fd67:39d:7a3a::/32 differ at the first bit). > In NEMO, prefixes overlap. HA on home link has a prefix, this > overlaps with MNP. NEMO MRHA tunnel associates those two. My NEMO can be configured with completely non-overlapping prefixes (home link to be 2001:db8::/32 and fd67:39d:7a3a::/32 on the ingress interface MNP). Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Dec 06 14:09:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0M6N-0003Kn-Bd; Thu, 06 Dec 2007 14:09:39 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1J0M6M-0003Kh-DA for autoconf-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 14:09:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0M6M-0003KZ-2w for autoconf@ietf.org; Thu, 06 Dec 2007 14:09:38 -0500 Received: from server9.hosting2go.nl ([83.137.192.232]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0M6L-0007Da-69 for autoconf@ietf.org; Thu, 06 Dec 2007 14:09:37 -0500 Received: (qmail 24042 invoked from network); 6 Dec 2007 20:09:35 +0100 Received: from unknown (HELO M90Teco) (130.129.82.92) by server9.hosting2go.nl with SMTP; 6 Dec 2007 20:09:33 +0100 From: "Teco Boot" To: Date: Thu, 6 Dec 2007 20:09:31 +0100 Message-ID: <012101c8383b$8932e8a0$9b98b9e0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg4OfPpcmFdlKQWQ2mNpptVYai+twAAH/XQ Content-Language: nl X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Autoconf] FW: NEMO-PD - DHCP support on Mobile Network 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 Cross-posting, as this is relevant to AUTOCONF also. The question is, do we want to support providing DHCP options to Local = Fixed Node (nodes "behind the router")? Teco. =3D=3D=3D Van: Teco Boot [mailto:teco@inf-net.nl]=20 Verzonden: donderdag 6 december 2007 19:58 Aan: 'mext@ietf.org' Onderwerp: NEMO-PD - DHCP support on Mobile Network On the two drafts for NEMO prefix delegation, I wonder how we can = support DHCP on Mobile Network. I think there are two options, DHCP Relay or = running DHCP Server on MR itself. For the latter, we need not only a prefix, but also data for DHCP options. Remark on overhead, I think the prefix delegation signaling has low overhead, depending on lifetimes. Lifetime can be a order longer than BU (PD: hours, days, months; BU: seconds, minutes). Teco. =A0 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Dec 06 14:14:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0MB3-0005SG-4l; Thu, 06 Dec 2007 14:14:29 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1J0MB1-0005Oe-Nr for autoconf-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 14:14:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0MB1-0005N0-CW for autoconf@ietf.org; Thu, 06 Dec 2007 14:14:27 -0500 Received: from server9.hosting2go.nl ([83.137.192.232]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0MB0-0007fr-SC for autoconf@ietf.org; Thu, 06 Dec 2007 14:14:27 -0500 Received: (qmail 26739 invoked from network); 6 Dec 2007 20:14:25 +0100 Received: from unknown (HELO M90Teco) (130.129.82.92) by server9.hosting2go.nl with SMTP; 6 Dec 2007 20:14:24 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <1196893387.27208.64.camel@localhost> <374005f30712051441yac2753 1r96c55806e5c9a3d5@mail.gmail.com> <475751E7.7070204@gmail.com><475759DA.4020004@inria.fr> <47575B98.8010106@gmail.com> <1196962710.27208.138.camel@localhost> <00f001c83836$ced53d90$6c7fb8b0$@nl> <47584898.8090302@gmail.com> In-Reply-To: <47584898.8090302@gmail.com> Subject: RE: [Autoconf] About unique/non-overlapping prefixes terminology Date: Thu, 6 Dec 2007 20:13:48 +0100 Message-ID: <012201c8383c$35894180$a09bc480$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg4O1m/80nX9geXRaiVdBD6VZGbBwAAHEbw Content-Language: nl X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: autoconf@ietf.org, 'Emmanuel Baccelli' 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 > -----Oorspronkelijk bericht----- > Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Verzonden: donderdag 6 december 2007 20:08 > Aan: Teco Boot > CC: cjbc@it.uc3m.es; autoconf@ietf.org; 'Emmanuel Baccelli' > Onderwerp: Re: [Autoconf] About unique/non-overlapping prefixes > terminology > > Teco Boot wrote: > > I would use terms unique address and non-overlapping prefix. I think > > these terms are well known. > > > > I think routers SHOULD NOT use overlapping prefixes and SHOULD NOT > > use duplicate addresses. > > Well I think they all use overlapping prefixes. Most prefixes overlap > up to some bit limit. The only example of completely non-overlapping > prefixes I can think of are the ones differing in the first bit (eg > 2001:db8::/32 and fd67:39d:7a3a::/32 differ at the first bit). Why are you trying to confuse all of us? > > > In NEMO, prefixes overlap. HA on home link has a prefix, this > > overlaps with MNP. NEMO MRHA tunnel associates those two. > > My NEMO can be configured with completely non-overlapping prefixes > (home > link to be 2001:db8::/32 and fd67:39d:7a3a::/32 on the ingress > interface > MNP). Great. But I think you can also configure overlapping prefixes. If not, I am not interested in your NEMO. Teco. > > Alex > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Dec 06 14:19:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0MGF-0000NL-2K; Thu, 06 Dec 2007 14:19:51 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1J0MGD-0000N6-Dl for autoconf-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 14:19:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0MGD-0000My-45 for autoconf@ietf.org; Thu, 06 Dec 2007 14:19:49 -0500 Received: from smtp02.uc3m.es ([163.117.176.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0MGC-0001Gq-3p for autoconf@ietf.org; Thu, 06 Dec 2007 14:19:49 -0500 Received: from [130.129.19.231] (dhcp-13e7.ietf70.org [130.129.19.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 4BF8F2A893B; Thu, 6 Dec 2007 20:19:46 +0100 (CET) Subject: Re: [Autoconf] About unique/non-overlapping prefixes terminology From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Alexandru Petrescu In-Reply-To: <47584749.8090404@gmail.com> References: <1196893387.27208.64.camel@localhost> <374005f30712051441yac2753 1r96c55806e5c9a3d5@mail.gmail.com> <475751E7.7070204@gmail.com><475759DA.4020004@inria.fr> <47575B98.8010106@gmail.com> <1196962710.27208.138.camel@localhost> <47584749.8090404@gmail.com> Organization: Universidad Carlos III de Madrid Date: Thu, 06 Dec 2007 20:19:43 +0100 Message-Id: <1196968783.27208.178.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 X-Spam-Score: -2.2 (--) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: autoconf@ietf.org, Emmanuel Baccelli X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0479060528==" Errors-To: autoconf-bounces@ietf.org --===============0479060528== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-5Wbaz4j7NEdeZ2ZaSNpN" --=-5Wbaz4j7NEdeZ2ZaSNpN Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Alex, See below... El jue, 06-12-2007 a las 11:02 -0800, Alexandru Petrescu escribi=F3: > Carlos Jes=FAs Bernardos Cano wrote: > >>> Alexandru Petrescu a =E9crit : > >>>> Ian Chakeres wrote: > >>>>> Based on the confusion around "unique" I've removed the use=20 > >>>>> of 'unique prefix' from my local revision. I've replaced=20 > >>>>> unique with distinct. > >>>>>=20 > >>>>> Please let me know if you have another recommendation. > >>>>>=20 > >>>>> Distinct Prefix Assignment MANET interfaces that are known to > >>>>> exhibit the above mentioned properties must be configured=20 > >>>>> with distinct prefixes, for their non-link-local addresses.=20 > >>>>> The reason for this requirement is so that no two MANET=20 > >>>>> interfaces are configured to appear within the same IP=20 > >>>>> prefix. > >>>> Can I assign 2001:db8::/32 on one interface and 2001:db8::/33=20 > >>>> on another interfaces of a MANET Router? The prefixes seem=20 > >>>> distinct to me. > >>>>=20 > >>> well look again. These are obviously not distinct CIDR blocks,=20 > >>> since one is contained in the other! > >> I think we may have a clear contentious problem here :-) I believe > >> these two prefixes are distinct and could as such be assigned ok=20 > >> on two real Ethernet interfaces of a router. Especially if these=20 > >> two prefixes are managed by other routers (but still assigned on=20 > >> the two interfaces of same router). > >=20 > > I think I disagree here. IMHO, it would not be ok to assign these=20 > > addresses on two real Ethernet interfaces of a router. >=20 > We may have terminology problem :-) Assigning a prefix to an interface > with ifconfig also adds an entry in the routing table... which part do > we disagree on? I think assigning those two addresses to two different interfaces is not a good configuration. Maybe when addressing your comments below I make myself more clear. >=20 > > If there is a host attached to one of these interfaces, and the IPv6=20 > > address of this host is, let's say 2001:db8::3, how does the router=20 > > know to which interface should deliver a packet addressed to=20 > > 2001:db8::3? I guess the router will try to deliver this packet=20 > > though the interface configured as 2001:db8::/33 (longest prefix=20 > > match), >=20 > Right, that's what router would do. >=20 > > but the host maybe as well attached to the other interface, right?. >=20 > Same host attached to two interfaces of a router? Or do you mean there=20 > may be two different hosts, each connected on one of the router's=20 > interfaces? I guess this latter? In this latter case: I wouldn't=20 > recommend two different hosts attached to two interfaces of a router to=20 > use the same 2001:db8::3 address. That's just a recommendation and=20 > people could configure the way they wish. I tried to mean that that a host with the address 2001:db8::3 may be attached to either the interface A of the router (the one with an address from 2001:db8::/32) or to the interface B (the one with an address from 2001:db8::/33), but I didn't mean the same host attached to two different interfaces or two different hosts with the same IP address. Maybe a picture helps here: | upstream (eggress) interface | -------------- ----|MANET ROUTER|---- | -------------- | 2001:db8::/32 2001:db8::/33 | | --------- | HOST | 2001:db8::3 --------- How does the MANET router knows how to send a packet to the host? This tried to be my question. Sorry if I didn't express that in a proper way (not being a native speaker doesn't help me :-( ). >=20 > Doing that configuration (2001:db8::3 assigned to two different hosts)=20 > is not necessarily prohibited by the assumed aggregation of prefixes nor=20 > by the routing system. Not sure how to say this better. >=20 > What if there is no host attached to the router's interface, but just=20 > routers. >=20 > What if one interface is the 'upstream', 'egress' interface and the=20 > other interface is the 'downstream', 'ingress' interface. Like this: >=20 > | > | upstream 2001:db8::/32 > ------------ > |MANET Router| > ------------ > | downstream 2001:db8::/33 > | >=20 This is a different scenario from what I had in mind. Anyway, IMHO I'd avoid this configuration as well, I don't like overlapping prefixes, but maybe it's just a matter of personal opinion... what do other people think? Regards, Carlos > Alex >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email=20 > ______________________________________________________________________ --=20 =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WEEDEV 2008: 1st Workshop on Experimental Evaluation and Deployment Experiences on Vehicular networks http://www.weedev.org/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-5Wbaz4j7NEdeZ2ZaSNpN Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHWEtPNdy6TdFwT2cRAmJ5AJ9ChQmS9/ksow3FhPLP5Vx+aWJktQCeNW9c SrM1D4jxp2YQCuBmYyfHAsM= =Gxyp -----END PGP SIGNATURE----- --=-5Wbaz4j7NEdeZ2ZaSNpN-- --===============0479060528== 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 --===============0479060528==-- From autoconf-bounces@ietf.org Thu Dec 06 14:24:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0ML5-0001wn-Ri; Thu, 06 Dec 2007 14:24:51 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1J0ML4-0001w0-SD for autoconf-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 14:24:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0ML4-0001vs-Ic for autoconf@ietf.org; Thu, 06 Dec 2007 14:24:50 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J0ML4-0001hn-3r for autoconf@ietf.org; Thu, 06 Dec 2007 14:24:50 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-153.messagelabs.com!1196969088!6456811!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 18592 invoked from network); 6 Dec 2007 19:24:48 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-153.messagelabs.com with SMTP; 6 Dec 2007 19:24:48 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lB6JOiqh019719; Thu, 6 Dec 2007 12:24:48 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id lB6JOhho023500; Thu, 6 Dec 2007 13:24:43 -0600 (CST) Received: from [127.0.0.1] ([10.19.236.139]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id lB6JOgsC023481; Thu, 6 Dec 2007 13:24:42 -0600 (CST) Message-ID: <47584C78.9010605@gmail.com> Date: Thu, 06 Dec 2007 11:24:40 -0800 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Teco Boot Subject: Re: [Autoconf] About unique/non-overlapping prefixes terminology References: <1196893387.27208.64.camel@localhost> <374005f30712051441yac2753 1r96c55806e5c9a3d5@mail.gmail.com> <475751E7.7070204@gmail.com><475759DA.4020004@inria.fr> <47575B98.8010106@gmail.com> <1196962710.27208.138.camel@localhost> <00f001c83836$ced53d90$6c7fb8b0$@nl> <47584898.8090302@gmail.com> <012201c8383c$35894180$a09bc480$@nl> In-Reply-To: <012201c8383c$35894180$a09bc480$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071205-2, 05/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: autoconf@ietf.org, 'Emmanuel Baccelli' 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 Teco Boot wrote: > >> -----Oorspronkelijk bericht----- Van: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Verzonden: donderdag 6 >> december 2007 20:08 Aan: Teco Boot CC: cjbc@it.uc3m.es; >> autoconf@ietf.org; 'Emmanuel Baccelli' Onderwerp: Re: [Autoconf] >> About unique/non-overlapping prefixes terminology >> >> Teco Boot wrote: >>> I would use terms unique address and non-overlapping prefix. I >>> think these terms are well known. >>> >>> I think routers SHOULD NOT use overlapping prefixes and SHOULD >>> NOT use duplicate addresses. >> Well I think they all use overlapping prefixes. Most prefixes >> overlap up to some bit limit. The only example of completely >> non-overlapping prefixes I can think of are the ones differing in >> the first bit (eg 2001:db8::/32 and fd67:39d:7a3a::/32 differ at >> the first bit). > > Why are you trying to confuse all of us? ? Sorry about that. In short: Mainly, people say that 2001:db8::/32 and 2001:db8::/33 are not distinct, thus they could not be assigned on two MANET interfaces (per Ian definition). Ian proposed a definition of Distinct Prefix Assignment. I checked two examples of prefix couples being distinct in my view. People disagree on one of these couples having distinct prefixes: they see it as one contained into another, and thus not fitting the definition of Ian. That's all. If consensus says that these two prefixes are non-distinct and can not be assigned on MANET interfaces then I'll abide to consensus. >>> In NEMO, prefixes overlap. HA on home link has a prefix, this >>> overlaps with MNP. NEMO MRHA tunnel associates those two. >> My NEMO can be configured with completely non-overlapping prefixes >> (home link to be 2001:db8::/32 and fd67:39d:7a3a::/32 on the >> ingress interface MNP). > > Great. But I think you can also configure overlapping prefixes. If > not, I am not interested in your NEMO. That's right, I can configure both overlapping and non-overlapping (distinct). However, Ian's definition only considers non-overlapping (distinct) prefixes. Thus, Ian definition excludes NEMO MR for use in MANET. (I use 'Ian definition' with no particular reference to a person, just to say what definition we talk about.) Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Dec 06 14:26:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0MMN-0005yz-Mq; Thu, 06 Dec 2007 14:26:11 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1J0MML-0005ei-V7 for autoconf-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 14:26:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0MML-0005Yr-DL for autoconf@ietf.org; Thu, 06 Dec 2007 14:26:09 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0MMK-0001oE-2K for autoconf@ietf.org; Thu, 06 Dec 2007 14:26:09 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id lB6JPaO2020233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 Dec 2007 11:25:51 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id lB6JPaOo015060; Thu, 6 Dec 2007 11:25:36 -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.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id lB6JPUMI014813; Thu, 6 Dec 2007 11:25:36 -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, 6 Dec 2007 11:25:35 -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] About unique/non-overlapping prefixes terminology Date: Thu, 6 Dec 2007 11:25:34 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029EDCAF@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <012201c8383c$35894180$a09bc480$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] About unique/non-overlapping prefixes terminology Thread-Index: Acg4O1m/80nX9geXRaiVdBD6VZGbBwAAHEbwAAB2mLA= References: <1196893387.27208.64.camel@localhost> <374005f30712051441yac27531r96c55806e5c9a3d5@mail.gmail.com> <475751E7.7070204@gmail.com><475759DA.4020004@inria.fr> <47575B98.8010106@gmail.com><1196962710.27208.138.camel@localhost><00f001c83836$ced53d90$6c7fb8b0$@nl> <47584898.8090302@gmail.com> <012201c8383c$35894180$a09bc480$@nl> From: "Templin, Fred L" To: "Teco Boot" , "Alexandru Petrescu" X-OriginalArrivalTime: 06 Dec 2007 19:25:35.0046 (UTC) FILETIME=[C6426660:01C8383D] X-Spam-Score: -4.0 (----) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: autoconf@ietf.org, Emmanuel Baccelli 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 =20 > -----Original Message----- > From: Teco Boot [mailto:teco@inf-net.nl]=20 > Sent: Thursday, December 06, 2007 11:14 AM > To: 'Alexandru Petrescu' > Cc: autoconf@ietf.org; 'Emmanuel Baccelli' > Subject: RE: [Autoconf] About unique/non-overlapping prefixes=20 > terminology >=20 >=20 >=20 > > -----Oorspronkelijk bericht----- > > Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > > Verzonden: donderdag 6 december 2007 20:08 > > Aan: Teco Boot > > CC: cjbc@it.uc3m.es; autoconf@ietf.org; 'Emmanuel Baccelli' > > Onderwerp: Re: [Autoconf] About unique/non-overlapping prefixes > > terminology > >=20 > > Teco Boot wrote: > > > I would use terms unique address and non-overlapping=20 > prefix. I think > > > these terms are well known. > > > > > > I think routers SHOULD NOT use overlapping prefixes and SHOULD NOT > > > use duplicate addresses. > >=20 > > Well I think they all use overlapping prefixes. Most=20 > prefixes overlap > > up to some bit limit. The only example of completely=20 > non-overlapping > > prefixes I can think of are the ones differing in the first bit (eg > > 2001:db8::/32 and fd67:39d:7a3a::/32 differ at the first bit). >=20 > Why are you trying to confuse all of us? +1 (at least!) Fred fred.l.templin@boeing.com _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Dec 06 14:29:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0MP7-0007k0-Ar; Thu, 06 Dec 2007 14:29:01 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1J0MP6-0007jt-2w for autoconf-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 14:29:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0MP5-0007jl-Pd for autoconf@ietf.org; Thu, 06 Dec 2007 14:28:59 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J0MP5-00020t-CA for autoconf@ietf.org; Thu, 06 Dec 2007 14:28:59 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-128.messagelabs.com!1196969337!4310648!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 3296 invoked from network); 6 Dec 2007 19:28:58 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-128.messagelabs.com with SMTP; 6 Dec 2007 19:28:58 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lB6JSvXX020827 for ; Thu, 6 Dec 2007 12:28:57 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id lB6JSvp9018976 for ; Thu, 6 Dec 2007 13:28:57 -0600 (CST) Received: from [127.0.0.1] ([10.19.236.139]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id lB6JSuDx018954 for ; Thu, 6 Dec 2007 13:28:56 -0600 (CST) Message-ID: <47584D77.3020300@gmail.com> Date: Thu, 06 Dec 2007 11:28:55 -0800 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 CC: autoconf@ietf.org Subject: Re: [Autoconf] About unique/non-overlapping prefixes terminology References: <1196893387.27208.64.camel@localhost> <374005f30712051441yac27531r96c55806e5c9a3d5@mail.gmail.com> <475751E7.7070204@gmail.com><475759DA.4020004@inria.fr> <47575B98.8010106@gmail.com><1196962710.27208.138.camel@localhost><00f001c83836$ced53d90$6c7fb8b0$@nl> <47584898.8090302@gmail.com> <012201c8383c$35894180$a09bc480$@nl> <39C363776A4E8C4A94691D2BD9D1C9A1029EDCAF@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029EDCAF@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071205-2, 05/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -2.4 (--) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 Templin, Fred L wrote: > > >> -----Original Message----- >> From: Teco Boot [mailto:teco@inf-net.nl] Sent: Thursday, December 06, 2007 11:14 AM >> To: 'Alexandru Petrescu' >> Cc: autoconf@ietf.org; 'Emmanuel Baccelli' >> Subject: RE: [Autoconf] About unique/non-overlapping prefixes terminology >> >> >> >>> -----Oorspronkelijk bericht----- >>> Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >>> Verzonden: donderdag 6 december 2007 20:08 >>> Aan: Teco Boot >>> CC: cjbc@it.uc3m.es; autoconf@ietf.org; 'Emmanuel Baccelli' >>> Onderwerp: Re: [Autoconf] About unique/non-overlapping prefixes >>> terminology >>> >>> Teco Boot wrote: >>>> I would use terms unique address and non-overlapping >> prefix. I think >>>> these terms are well known. >>>> >>>> I think routers SHOULD NOT use overlapping prefixes and SHOULD NOT >>>> use duplicate addresses. >>> Well I think they all use overlapping prefixes. Most >> prefixes overlap >>> up to some bit limit. The only example of completely >> non-overlapping >>> prefixes I can think of are the ones differing in the first bit (eg >>> 2001:db8::/32 and fd67:39d:7a3a::/32 differ at the first bit). >> Why are you trying to confuse all of us? > > +1 (at least!) Sorry about that, I'll drop it here. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Dec 06 15:03:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0MwK-0004iN-8R; Thu, 06 Dec 2007 15:03:20 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1J0MwH-0004Yz-RB for autoconf-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 15:03:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0MwH-0004Yr-Gj for autoconf@ietf.org; Thu, 06 Dec 2007 15:03:17 -0500 Received: from server9.hosting2go.nl ([83.137.192.232]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0MwG-0002K5-SO for autoconf@ietf.org; Thu, 06 Dec 2007 15:03:17 -0500 Received: (qmail 24455 invoked from network); 6 Dec 2007 21:03:15 +0100 Received: from unknown (HELO M90Teco) (130.129.82.92) by server9.hosting2go.nl with SMTP; 6 Dec 2007 21:03:14 +0100 From: "Teco Boot" To: Date: Thu, 6 Dec 2007 21:02:39 +0100 Message-ID: <013a01c83843$07d54200$177fc600$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg4QvQN7AqD0hxGRCKqvZeEHer/eA== Content-Language: nl X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Autoconf] Supporting commercial ISPs 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 I have a somewhat fundamental question on AUTOCONF requirements; do we consider commercial ISPs? I think in real world, we have two environments: private networks and Internet. Private networks could use L2 security and within the network there is no hard requirement for access control. However, even in these private networks access control is getting important. For Internet, ISP provide access to their customers. And probably to their customers only. I wonder how we can support this kind of operation. I appreciate any comment from ISPs, on what they want to be supported. I think the outcome has a large impact on the requirements. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Dec 07 14:11:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0ibN-0003gQ-Eo; Fri, 07 Dec 2007 14:11:09 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1J0ibM-0003gK-H0 for autoconf-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 14:11:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0ibM-0003gC-4s for autoconf@ietf.org; Fri, 07 Dec 2007 14:11:08 -0500 Received: from hs-out-0708.google.com ([64.233.178.251] helo=hs-out-2122.google.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0ibL-0002iY-B6 for autoconf@ietf.org; Fri, 07 Dec 2007 14:11:07 -0500 Received: by hs-out-2122.google.com with SMTP id 54so228616hsz for ; Fri, 07 Dec 2007 11:11:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=IV66B4Jqmw6RAv1m2n5GwWHr2qS0pSZPYubD3i+OwDs=; b=S3EAGZMYDv2Lxc2kQOk0R2L3RqkrxcGWKMureXyK8sCvHJzWaKYwtme1ffHF+ywAIbKXgF4KyRaq0vhZRtBKt6eqxyzCXzkOwPO6fToICFgW8/p+7Jltn2kHvMRHF7sHXU1CkFhvTdiSD1WAASeex/daEui8dIDIGC7OsgQISTA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=e4+UtRn0TnVyCYfwF4IMI/E18aeaoP8QwyzLu3knJPa2Q4gU5xz/TDTGVGV8imIjSxqlaFEPf5J7OMi4yUdvIpXGLODnqHukZQa+JyKDBUjijF96+fP7TgCejcHjUeldKUFm8ECIKdDVplJKU8ze8NImMmdKF79JiVjpUtkS0Ak= Received: by 10.78.100.1 with SMTP id x1mr4119922hub.1197054665950; Fri, 07 Dec 2007 11:11:05 -0800 (PST) Received: by 10.78.31.5 with HTTP; Fri, 7 Dec 2007 11:11:05 -0800 (PST) Message-ID: Date: Fri, 7 Dec 2007 20:11:05 +0100 From: "Hasnaa Moustafa" To: teco@inf-net.nl In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: autoconf@ietf.org Subject: [Autoconf] Re: Autoconf Digest, Vol 23, Issue 18 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: , Content-Type: multipart/mixed; boundary="===============0827133898==" Errors-To: autoconf-bounces@ietf.org --===============0827133898== Content-Type: multipart/alternative; boundary="----=_Part_12641_6974973.1197054665947" ------=_Part_12641_6974973.1197054665947 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Teco, Thanks for raising this interesting issue. Considering Commercial ISPs is the way for wide scale MANET deployments. I believe that IP autoconfiguration is one of the tough issues blocking the real MANET deployment by ISPs. Even if we think of L2 security (existing in WLAN hotspots deployed by ISPs), it is not feasible to apply it in a MANET multi-hop environment, and no standard solution existing now providing L2 security in multi-hop MANET environment. I agree with your point that ISP should provide IP autoconfiguration for their clients or even other legitimate clients (belonging to other ISPs, for instance, if there is a trust relationship between different ISPs). And there is a number of requirements that can exist in this case. But the main question (before talking about this issue) concerns the autoconf WG scope: is the WG looking for IP autoconf solutions concerning such type of scenario --> (MANETs that extends the service coverage of an ISP access network? And of coarse: this is a connected MANET.) IMHO, this is an important scenario highlighting a concrete MANET application and having special requirements. Hassnaa ---------------------------------------------------------------------------------------------------- Date: Thu, 6 Dec 2007 21:02:39 +0100 From: "Teco Boot" Subject: [Autoconf] Supporting commercial ISPs To: Message-ID: <013a01c83843$07d54200$177fc600$@nl> Content-Type: text/plain; charset="us-ascii" I have a somewhat fundamental question on AUTOCONF requirements; do we consider commercial ISPs? I think in real world, we have two environments: private networks and Internet. Private networks could use L2 security and within the network there is no hard requirement for access control. However, even in these private networks access control is getting important. For Internet, ISP provide access to their customers. And probably to their customers only. I wonder how we can support this kind of operation. I appreciate any comment from ISPs, on what they want to be supported. I think the outcome has a large impact on the requirements. Teco. ------------------------------ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf End of Autoconf Digest, Vol 23, Issue 18 **************************************** ------=_Part_12641_6974973.1197054665947 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Teco,
 
Thanks for raising this interesting issue.
 
Considering Commercial ISPs is the way for wide scale MANET deployments. I believe that IP autoconfiguration is one of the tough issues blocking the real MANET deployment by ISPs. 
 
Even if we think of L2 security (existing in WLAN hotspots deployed by ISPs), it is not feasible to apply it in a MANET multi-hop environment, and no standard solution existing now providing L2 security in multi-hop MANET environment.
 
I agree with your point that ISP should provide IP autoconfiguration for their clients or even other legitimate clients (belonging to other ISPs, for instance, if there is a trust relationship between different ISPs). And there is a number of requirements that can exist in this case.
But the main question (before talking about this issue) concerns the autoconf WG scope: is the WG looking for IP autoconf solutions concerning such type of scenario --> (MANETs that extends the service coverage of an ISP access network? And of coarse: this is a connected MANET.)  
 
IMHO, this is an important scenario highlighting a concrete MANET application and having special requirements.
 
Hassnaa
----------------------------------------------------------------------------------------------------
Date: Thu, 6 Dec 2007 21:02:39 +0100
From: "Teco Boot" <teco@inf-net.nl>
Subject: [Autoconf] Supporting commercial ISPs
To: < autoconf@ietf.org>
Message-ID: <013a01c83843$07d54200$177fc600$@nl>
Content-Type: text/plain;       charset="us-ascii"

I have a somewhat fundamental question on AUTOCONF requirements; do we
consider commercial ISPs?

I think in real world, we have two environments: private networks and
Internet.

Private networks could use L2 security and within the network there is no
hard requirement for access control. However, even in these private networks
access control is getting important.

For Internet, ISP provide access to their customers. And probably to their
customers only. I wonder how we can support this kind of operation.

I appreciate any comment from ISPs, on what they want to be supported. I
think the outcome has a large impact on the requirements.

Teco.






------------------------------

_______________________________________________
Autoconf mailing list
Autoconf@ietf.org
https://www1.ietf.org/mailman/listinfo/autoconf


End of Autoconf Digest, Vol 23, Issue 18
****************************************
 

------=_Part_12641_6974973.1197054665947-- --===============0827133898== 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 --===============0827133898==-- From autoconf-bounces@ietf.org Mon Dec 10 09:38:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1jmE-00032f-Q1; Mon, 10 Dec 2007 09:38:34 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1J1jmC-00032Y-3R for autoconf-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 09:38:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1jmB-00032Q-Px for autoconf@ietf.org; Mon, 10 Dec 2007 09:38:31 -0500 Received: from server9.hosting2go.nl ([83.137.192.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1jm9-0002Ek-Rm for autoconf@ietf.org; Mon, 10 Dec 2007 09:38:31 -0500 Received: (qmail 18226 invoked from network); 10 Dec 2007 15:38:28 +0100 Received: from unknown (HELO M90Teco) (217.169.232.211) by server9.hosting2go.nl with SMTP; 10 Dec 2007 15:38:28 +0100 From: "Teco Boot" To: "'Hasnaa Moustafa'" References: In-Reply-To: Subject: RE: [Autoconf] Supporting commercial ISPs Date: Mon, 10 Dec 2007 15:37:56 +0100 Message-ID: <000801c83b3a$53800560$fa801020$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg5BOvfvDVPaNF4SLyOGhAAaMh38ACK3jgw Content-Language: nl X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac 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 Hasnaa, Thanks for the clear response. I think we should include some scenarios on extending service coverage = area of an ISP access network in the PS document. Suggested scenarios: 1) Full trust between Access Routers and MANET Routers. MANET Links and = Access Links are protected using L2 security. Border Routers and Access Routers = can be integrated, i.e. Access Routers may run MANET routing protocol. = Access Routers may provide prefixes and addresses. The question here is, what is the added value of Autoconf? IMHO all = nodes are provisioned before deployment; e.g. security parameters and key material. Configuring addresses is not that much extra. 2) No trust between Access Routers and MANET routers. Border routers use protected L2 links to Access Routers. Border Routers are fixed or = mobile. Access Routers do typically not provide prefixes, they only provide addresses to attached nodes. In this case, assistance from NEMO functionally and HA could be used for providing prefixes to Border Routers. MANET routing protocol may run on = MRHA tunnel. The question here is, what is the trust relation between the MANET = Routers? And also what is the added value of Autoconf in case of configured = security parameters and key material? 3) New security mechanism for setting up trust relation between Access = Routers and MANET Routers. In this case, each MANET Router sets up a secured = link to one or more Access Routers. I think network operators require some kind = of hardware authentication (e.g. SIM), or maybe some form of certificates = could be used. NEMO can be used in this case also. I did not use "new terminology" Internet Configuration Provider, as I do = not know what this is. I used Access Router instead of ISP Edge Router, as this is a well known name for this entity (RFC3753).=20 What do you think? Any comment from others, familiar with ISP / network operator = requirements? Teco. -------------------------------------------------------------------------= --- ------------------------ Van: Hasnaa Moustafa [mailto:hasnaa.moustafa@gmail.com]=20 Verzonden: vrijdag 7 december 2007 20:11 Aan: teco@inf-net.nl CC: autoconf@ietf.org Onderwerp: Re: Autoconf Digest, Vol 23, Issue 18 Hi Teco, =A0 Thanks for raising this interesting issue. =A0 Considering Commercial ISPs is the way for wide scale MANET deployments. = I believe that IP autoconfiguration is one of the tough issues blocking = the real MANET deployment by ISPs.=A0 =A0 Even if we think of=A0L2 security (existing in WLAN hotspots deployed by ISPs),=A0it is not feasible to apply it in a MANET multi-hop = environment, and no standard solution existing now=A0providing L2 security in multi-hop = MANET environment.=20 =A0 I agree with your point that ISP should provide IP autoconfiguration for their clients or even other legitimate clients (belonging to other ISPs, = for instance, if there is a trust relationship between different ISPs). And there is a number of requirements that can exist in this case.=20 But the main=A0question (before talking about this issue) concerns the autoconf WG scope: is the WG looking for=A0IP autoconf solutions concerning=A0such type of scenario --> (MANETs that extends the service coverage of an ISP=A0access network? And of coarse: this is a connected MANET.)=A0=A0=20 =A0 IMHO, this is an important scenario highlighting a concrete MANET application and having special requirements. =A0 Hassnaa -------------------------------------------------------------------------= --- ------------------------ Date: Thu, 6 Dec 2007 21:02:39 +0100 From: "Teco Boot" Subject: [Autoconf] Supporting commercial ISPs To: < autoconf@ietf.org> Message-ID: <013a01c83843$07d54200$177fc600$@nl> Content-Type: text/plain;=A0=A0=A0=A0=A0=A0 charset=3D"us-ascii" I have a somewhat fundamental question on AUTOCONF requirements; do we=20 consider commercial ISPs? I think in real world, we have two environments: private networks and Internet. Private networks could use L2 security and within the network there is = no hard requirement for access control. However, even in these private = networks access control is getting important. For Internet, ISP provide access to their customers. And probably to = their customers only. I wonder how we can support this kind of operation. I appreciate any comment from ISPs, on what they want to be supported. I = think the outcome has a large impact on the requirements. Teco. ------------------------------ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf End of Autoconf Digest, Vol 23, Issue 18 ****************************************=20 =A0 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Dec 11 10:37:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J27B0-0002Pt-Mp; Tue, 11 Dec 2007 10:37:42 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1J27Ay-0002Ml-NC for autoconf-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 10:37:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J27Ax-0002Jb-MM for autoconf@ietf.org; Tue, 11 Dec 2007 10:37:40 -0500 Received: from ug-out-1314.google.com ([66.249.92.175]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J27Av-000088-Sc for autoconf@ietf.org; Tue, 11 Dec 2007 10:37:39 -0500 Received: by ug-out-1314.google.com with SMTP id u2so837318uge.46 for ; Tue, 11 Dec 2007 07:37:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=IUMbK0SZ2f5ueW6U47HI1zH5IS8N8k7OhPOVz1tf9PI=; b=kcQjBn2+6DJMsLx++JJmnZiC2fH5BaLVIZOJBg5KoCp7XgklCKtGclfla61iTJqitP2aoVwD6kXOeNIe6uazoyl9/qSHe/OjET6BLfGAfWCvDKDCqZk2CvnpOLnH+PD6WZ31nX+HKcjNncQ4XNIMfGMpSZ215mGBn7rGJM1AqEI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=pznn06kBvwrhAjDTCSluoew+8Q50LO7xSkUx5Y9DO1n8jy5c1e3OoV3yv8e38lvZDhBkBRQYLnldEAyrgaYapOPWf3u15h5I1yF6LILLeomKU21ioyyryCp6XP/ncOZzZOl1mDwdsKRGvYAhvRXnE4CWfO/vzKJ79JSngmC8Wx0= Received: by 10.78.140.17 with SMTP id n17mr3013234hud.1197387456041; Tue, 11 Dec 2007 07:37:36 -0800 (PST) Received: by 10.78.31.5 with HTTP; Tue, 11 Dec 2007 07:37:35 -0800 (PST) Message-ID: Date: Tue, 11 Dec 2007 16:37:35 +0100 From: "Hasnaa Moustafa" To: teco@inf-net.nl Subject: Re: [Autoconf] Supporting commercial ISPs In-Reply-To: <000801c83b3a$53800560$fa801020$@nl> MIME-Version: 1.0 References: <000801c83b3a$53800560$fa801020$@nl> X-Spam-Score: 0.0 (/) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 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: , Content-Type: multipart/mixed; boundary="===============1469944517==" Errors-To: autoconf-bounces@ietf.org --===============1469944517== Content-Type: multipart/alternative; boundary="----=_Part_635_9295941.1197387456033" ------=_Part_635_9295941.1197387456033 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Teco, Thanks for you reply. There are a number of points that are not so clear for me. Please see below. Hassnaa On 12/10/07, Teco Boot wrote: > > Hi Hasnaa, > > Thanks for the clear response. > I think we should include some scenarios on extending service coverage > area of an ISP access network in the PS document. Suggested scenarios: > Hassnaa: I am not so sure if we need a special scenario for this, as this type of scenario is a connected one. Then the description of the connected scenario in the PS could include such a case (MANET connected to an ISP access network). > 1) > Full trust between Access Routers and MANET Routers. MANET Links and > Access > Links are protected using L2 security. Border Routers and Access Routers > can > be integrated, i.e. Access Routers may run MANET routing protocol. Access > Routers may provide prefixes and addresses. Hassnaa: How do you differentiate between MANET links and Access links? -If Access Routers and Border Routers are integrated in one entity (as you mentioned), then there is no difference, IMO, between Access links and MANET links. - When talking about L2 Security (for instance 802.1x model), I could not see how it could take place in a multi-hop MANET environment. So far, the existing standard mechanisms function in a WLAN environment (protecting the link between a mobile node and an Access point). So saying MANET links are protected using L2 security --> implies the existence of a mechanism that assures L2 security within the multi-hop environment (which does not conform with the reality). The question here is, what is the added value of Autoconf? IMHO all nodes > are provisioned before deployment; e.g. security parameters and key > material. Configuring addresses is not that much extra. Hassnaa: I did not get, what do you mean by "added value of Autoconf" --> for me the added value of autoconf is the "IP address provision for manet routers" (Maybe I miss something!). 2) > No trust between Access Routers and MANET routers. Border routers use > protected L2 links to Access Routers. Border Routers are fixed or mobile. > Access Routers do typically not provide prefixes, they only provide > addresses to attached nodes. Hassnaa: If there is no trust between the Access Routers and the MANET routers, then this does not conform with a MANET connected to an ISP access network. For commercial deployment of MANETs, each manet router is considered as a "mobile client", and this "mobile client" could not be connected to the ISP access network if he is not legitimate (implying "trust relationship" with the Access Routers directly or indirectly. Directly, if the mobile client is a subscriber with the ISP that owns the Access routers, while indirectly if the mobile client is a subscriber with another ISP that has a trust relationship with the current ISP. In this case, assistance from NEMO functionally and HA could be used for > providing prefixes to Border Routers. MANET routing protocol may run on > MRHA > tunnel. > The question here is, what is the trust relation between the MANET > Routers? > And also what is the added value of Autoconf in case of configured > security > parameters and key material? Hassnaa: Same previous comment for the "added value of Autoconf"! 3) > New security mechanism for setting up trust relation between Access > Routers > and MANET Routers. In this case, each MANET Router sets up a secured link > to > one or more Access Routers. I think network operators require some kind of > hardware authentication (e.g. SIM), or maybe some form of certificates > could > be used. NEMO can be used in this case also. Hassnaa: I think that this point goes into details concerning the security issue (which is not sure to be in the scope of the WG). I did not use "new terminology" Internet Configuration Provider, as I do not > know what this is. > I used Access Router instead of ISP Edge Router, as this is a well known > name for this entity (RFC3753). > > What do you think? Hassnaa: IMHO, it is interesting to include the case of "a MANET connectected to an ISP access network" in the "Connected MANET subsection in the PS" --> I could eventually provide some text if there is an agreement on this point. If there is also an agreement on including a requirement section in the PS document "the point that was discussed in Vancouver, but not yet concluded" --> it would be then important to consider some requirements related to this case (this would be security requirements, as well as operational requirements). Comments and feedbacks are more than welcome. Any comment from others, familiar with ISP / network operator requirements? > > Teco. > > > ---------------------------------------------------------------------------- > ------------------------ > Van: Hasnaa Moustafa [mailto:hasnaa.moustafa@gmail.com] > Verzonden: vrijdag 7 december 2007 20:11 > Aan: teco@inf-net.nl > CC: autoconf@ietf.org > Onderwerp: Re: Autoconf Digest, Vol 23, Issue 18 > > Hi Teco, > > Thanks for raising this interesting issue. > > Considering Commercial ISPs is the way for wide scale MANET deployments. I > believe that IP autoconfiguration is one of the tough issues blocking the > real MANET deployment by ISPs. > > Even if we think ofL2 security (existing in WLAN hotspots deployed by > ISPs),it is not feasible to apply it in a MANET multi-hop environment, and > no standard solution existing nowproviding L2 security in multi-hop MANET > environment. > > I agree with your point that ISP should provide IP autoconfiguration for > their clients or even other legitimate clients (belonging to other ISPs, > for > instance, if there is a trust relationship between different ISPs). And > there is a number of requirements that can exist in this case. > But the mainquestion (before talking about this issue) concerns the > autoconf WG scope: is the WG looking forIP autoconf solutions > concerningsuch type of scenario --> (MANETs that extends the service > coverage of an ISPaccess network? And of coarse: this is a connected > MANET.) > > IMHO, this is an important scenario highlighting a concrete MANET > application and having special requirements. > > Hassnaa > > ---------------------------------------------------------------------------- > ------------------------ > Date: Thu, 6 Dec 2007 21:02:39 +0100 > From: "Teco Boot" > Subject: [Autoconf] Supporting commercial ISPs > To: < autoconf@ietf.org> > Message-ID: <013a01c83843$07d54200$177fc600$@nl> > Content-Type: text/plain; charset="us-ascii" > > I have a somewhat fundamental question on AUTOCONF requirements; do we > consider commercial ISPs? > > I think in real world, we have two environments: private networks and > Internet. > > Private networks could use L2 security and within the network there is no > hard requirement for access control. However, even in these private > networks > > access control is getting important. > > For Internet, ISP provide access to their customers. And probably to their > customers only. I wonder how we can support this kind of operation. > > I appreciate any comment from ISPs, on what they want to be supported. I > think the outcome has a large impact on the requirements. > > Teco. > > ------------------------------ > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf > > > End of Autoconf Digest, Vol 23, Issue 18 > **************************************** > > > > ------=_Part_635_9295941.1197387456033 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Teco,
 
Thanks for you reply.
 
There are a number of points that are not so clear for me.
 
Please see below.
 
Hassnaa

 
On 12/10/07, Teco Boot <teco@inf-net.nl> wrote:
Hi Hasnaa,

Thanks for the clear response.
I think we should include some scenarios on extending service coverage area of an ISP access network in the PS document. Suggested scenarios:
 
 
Hassnaa: I am not so sure if we need a special scenario for this, as this type of scenario is a connected one. Then the description of the connected scenario in the PS could include such a case (MANET connected to an ISP access network).


1)
Full trust between Access Routers and MANET Routers. MANET Links and Access
Links are protected using L2 security. Border Routers and Access Routers can
be integrated, i.e. Access Routers may run MANET routing protocol. Access
Routers may provide prefixes and addresses.
 
Hassnaa:
How do you differentiate between MANET links and Access links?
-If Access Routers and Border Routers are integrated in one entity (as you mentioned), then there is no difference, IMO, between Access links and MANET links.
- When talking about L2 Security (for instance 802.1x model), I could not see how it could take place in a multi-hop MANET environment. So far, the existing standard mechanisms function in a WLAN environment (protecting the link between a mobile node and an Access point). So saying MANET links are protected using L2 security --> implies the existence of a mechanism that assures L2 security within the multi-hop environment (which does not conform with the reality).

The question here is, what is the added value of Autoconf? IMHO all nodes
are provisioned before deployment; e.g. security parameters and key
material. Configuring addresses is not that much extra.
 
Hassnaa:
I did not get, what do you mean by "added value of Autoconf" --> for me the added value of autoconf is the "IP address provision for manet routers" (Maybe I miss something!).
 

2)
No trust between Access Routers and MANET routers. Border routers use
protected L2 links to Access Routers. Border Routers are fixed or mobile.
Access Routers do typically not provide prefixes, they only provide
addresses to attached nodes.
 
Hassnaa:
If there is no trust between the Access Routers and the MANET routers, then this does not conform with a MANET connected to an ISP access network. For commercial deployment of MANETs, each manet router is considered as a "mobile client", and this "mobile client" could not be connected to the ISP access network if he is not legitimate (implying "trust relationship" with the Access Routers directly or indirectly. Directly, if the mobile client is a subscriber with the ISP that owns the Access routers, while indirectly if the mobile client is a subscriber with another ISP that has a trust relationship with the current ISP.

In this case, assistance from NEMO functionally and HA could be used for
providing prefixes to Border Routers. MANET routing protocol may run on MRHA
tunnel.
The question here is, what is the trust relation between the MANET Routers?
And also what is the added value of Autoconf in case of configured security
parameters and key material?
 
Hassnaa: Same previous comment for the "added value of Autoconf"!

3)
New security mechanism for setting up trust relation between Access Routers
and MANET Routers. In this case, each MANET Router sets up a secured link to
one or more Access Routers. I think network operators require some kind of
hardware authentication (e.g. SIM), or maybe some form of certificates could
be used. NEMO can be used in this case also.
 
Hassnaa: I think that this point goes into details concerning the security issue (which is not sure to be in the scope of the WG).

I did not use "new terminology" Internet Configuration Provider, as I do not
know what this is.
I used Access Router instead of ISP Edge Router, as this is a well known
name for this entity (RFC3753).

What do you think?
 
Hassnaa: IMHO, it is interesting to include the case of "a MANET connectected to an ISP access network" in the "Connected MANET subsection in the PS" --> I could eventually provide some text if there is an agreement on this point.
If there is also an agreement on including a requirement section in the PS document "the point that was discussed in Vancouver, but not yet concluded" --> it would be then important to consider some requirements related to this case (this would be security requirements, as well as operational requirements).
 
Comments and feedbacks are more than welcome.
 
 

Any comment from others, familiar with ISP / network operator requirements?

Teco.

----------------------------------------------------------------------------
------------------------
Van: Hasnaa Moustafa [mailto:hasnaa.moustafa@gmail.com]
Verzonden: vrijdag 7 december 2007 20:11
Aan: teco@inf-net.nl
CC: autoconf@ietf.org
Onderwerp: Re: Autoconf Digest, Vol 23, Issue 18

Hi Teco,

Thanks for raising this interesting issue.

Considering Commercial ISPs is the way for wide scale MANET deployments. I
believe that IP autoconfiguration is one of the tough issues blocking the
real MANET deployment by ISPs.

Even if we think ofL2 security (existing in WLAN hotspots deployed by
ISPs),it is not feasible to apply it in a MANET multi-hop environment, and
no standard solution existing nowproviding L2 security in multi-hop MANET
environment.

I agree with your point that ISP should provide IP autoconfiguration for
their clients or even other legitimate clients (belonging to other ISPs, for
instance, if there is a trust relationship between different ISPs). And
there is a number of requirements that can exist in this case.
But the mainquestion (before talking about this issue) concerns the
autoconf WG scope: is the WG looking forIP autoconf solutions
concerningsuch type of scenario --> (MANETs that extends the service
coverage of an ISPaccess network? And of coarse: this is a connected
MANET.)

IMHO, this is an important scenario highlighting a concrete MANET
application and having special requirements.

Hassnaa
----------------------------------------------------------------------------
------------------------
Date: Thu, 6 Dec 2007 21:02:39 +0100
From: "Teco Boot" < teco@inf-net.nl>
Subject: [Autoconf] Supporting commercial ISPs
To: < autoconf@ietf.org>
Message-ID: <013a01c83843$07d54200$177fc600$@nl >
Content-Type: text/plain; charset="us-ascii"

I have a somewhat fundamental question on AUTOCONF requirements; do we
consider commercial ISPs?

I think in real world, we have two environments: private networks and
Internet.

Private networks could use L2 security and within the network there is no
hard requirement for access control. However, even in these private networks

access control is getting important.

For Internet, ISP provide access to their customers. And probably to their
customers only. I wonder how we can support this kind of operation.

I appreciate any comment from ISPs, on what they want to be supported. I
think the outcome has a large impact on the requirements.

Teco.

------------------------------

_______________________________________________
Autoconf mailing list
Autoconf@ietf.org
https://www1.ietf.org/mailman/listinfo/autoconf


End of Autoconf Digest, Vol 23, Issue 18
****************************************




------=_Part_635_9295941.1197387456033-- --===============1469944517== 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 --===============1469944517==-- From autoconf-bounces@ietf.org Wed Dec 12 03:53:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2NLd-00039j-Pk; Wed, 12 Dec 2007 03:53:45 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1J2NLc-00036M-JM for autoconf-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 03:53:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2NLW-00034o-Bs for autoconf@ietf.org; Wed, 12 Dec 2007 03:53:38 -0500 Received: from hpsmtp-eml19.kpnxchange.com ([213.75.38.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2NLJ-0000k3-Fa for autoconf@ietf.org; Wed, 12 Dec 2007 03:53:38 -0500 Received: from hpsmtp-eml04.kpnxchange.com ([213.75.38.104]) by hpsmtp-eml19.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 09:53:24 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml04.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 09:53:23 +0100 From: "Teco Boot" To: "'Hasnaa Moustafa'" References: <000801c83b3a$53800560$fa801020$@nl> In-Reply-To: Subject: RE: [Autoconf] Supporting commercial ISPs Date: Wed, 12 Dec 2007 09:53:21 +0100 Message-ID: <000701c83c9c$73b2edd0$5b18c970$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg8C8GS4WTdryZ7SeSttPt4C6piDAAiI7zQ Content-Language: nl X-OriginalArrivalTime: 12 Dec 2007 08:53:23.0294 (UTC) FILETIME=[73A6DFE0:01C83C9C] X-Spam-Score: -1.0 (-) X-Scan-Signature: 8d0ce21640fc4f538e61f56fff96e39d 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: , Content-Type: multipart/mixed; boundary="===============0441792085==" Errors-To: autoconf-bounces@ietf.org Dit is een meerdelig bericht met een MIME-indeling. --===============0441792085== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C83CA4.D57755D0" Content-Language: nl Dit is een meerdelig bericht met een MIME-indeling. ------=_NextPart_000_0008_01C83CA4.D57755D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Hassnaa, Comments inline. Van: Hasnaa Moustafa [mailto:hasnaa.moustafa@gmail.com] Verzonden: dinsdag 11 december 2007 16:38 Aan: teco@inf-net.nl CC: autoconf@ietf.org Onderwerp: Re: [Autoconf] Supporting commercial ISPs Hi Teco, Thanks for you reply. There are a number of points that are not so clear for me. Please see below. Hassnaa On 12/10/07, Teco Boot wrote: Hi Hasnaa, Thanks for the clear response. I think we should include some scenarios on extending service coverage area of an ISP access network in the PS document. Suggested scenarios: Hassnaa: I am not so sure if we need a special scenario for this, as this type of scenario is a connected one. Then the description of the connected scenario in the PS could include such a case (MANET connected to an ISP access network). 1) Full trust between Access Routers and MANET Routers. MANET Links and Access Links are protected using L2 security. Border Routers and Access Routers can be integrated, i.e. Access Routers may run MANET routing protocol. Access Routers may provide prefixes and addresses. Hassnaa: How do you differentiate between MANET links and Access links? -If Access Routers and Border Routers are integrated in one entity (as you mentioned), then there is no difference, IMO, between Access links and MANET links. [Teco:] In this case, there is no access link. - When talking about L2 Security (for instance 802.1x model), I could not see how it could take place in a multi-hop MANET environment. So far, the existing standard mechanisms function in a WLAN environment (protecting the link between a mobile node and an Access point). So saying MANET links are protected using L2 security --> implies the existence of a mechanism that assures L2 security within the multi-hop environment (which does not conform with the reality). [Teco:] I am not sure 802.1x cannot be used for MANET links. 802.11i-2004 describes how this should work for IBSS. I prefer using pre-shared keys in MANET. Many existing MANET products use local configured settings, for security and other. Manual provisioning of MANET Local Addresses is natural in such cases. This is why I asked what the added value of Autoconf is. The question here is, what is the added value of Autoconf? IMHO all nodes are provisioned before deployment; e.g. security parameters and key material. Configuring addresses is not that much extra. Hassnaa: I did not get, what do you mean by "added value of Autoconf" --> for me the added value of autoconf is the "IP address provision for manet routers" (Maybe I miss something!). [Teco:] Yes, but when keys (and other settings) need to be configured before deployment, why not configuring MLA also? For global addresses, Autoconf functionality can be useful. 2) No trust between Access Routers and MANET routers. Border routers use protected L2 links to Access Routers. Border Routers are fixed or mobile. Access Routers do typically not provide prefixes, they only provide addresses to attached nodes. Hassnaa: If there is no trust between the Access Routers and the MANET routers, then this does not conform with a MANET connected to an ISP access network. For commercial deployment of MANETs, each manet router is considered as a "mobile client", and this "mobile client" could not be connected to the ISP access network if he is not legitimate (implying "trust relationship" with the Access Routers directly or indirectly. Directly, if the mobile client is a subscriber with the ISP that owns the Access routers, while indirectly if the mobile client is a subscriber with another ISP that has a trust relationship with the current ISP. [Teco:] In both the "directly" and "indirectly" case, each MANET Router that can access the ISP network is also Border Router, OK? In this case, assistance from NEMO functionally and HA could be used for providing prefixes to Border Routers. MANET routing protocol may run on MRHA tunnel. The question here is, what is the trust relation between the MANET Routers? And also what is the added value of Autoconf in case of configured security parameters and key material? Hassnaa: Same previous comment for the "added value of Autoconf"! [Teco:] I am just asking myself this question on added value of Autoconf. If access to ISP network is managed on Access Router - Border Router link, current global address assignment protocols are used and Autoconf is not needed. If there is no preconfigured trust relation between the MANET Routers, but MANET Routers want to communicate with each other, MLA is needed. Here Autoconf functionality can be useful. 3) New security mechanism for setting up trust relation between Access Routers and MANET Routers. In this case, each MANET Router sets up a secured link to one or more Access Routers. I think network operators require some kind of hardware authentication (e.g. SIM), or maybe some form of certificates could be used. NEMO can be used in this case also. Hassnaa: I think that this point goes into details concerning the security issue (which is not sure to be in the scope of the WG). [Teco:] Partly agreed. I think we should not work on security solutions, but I think it is important to know what the requirements for real world deployment are. If we do not cope with it, the newly defined protocols are dead already. I think it is better to circumvent this. One of the ideas in Autoconf is, is providing a facility for multihop MANET communication between a MANET Router and the Internet. Our goal is to provide a Problem Statement document. If there is a security problem with this topology, I do not see a reason why we should not describe this. Solving the problem is another thing, it requires rechartering Autoconf or something else. I did not use "new terminology" Internet Configuration Provider, as I do not know what this is. I used Access Router instead of ISP Edge Router, as this is a well known name for this entity (RFC3753). What do you think? Hassnaa: IMHO, it is interesting to include the case of "a MANET connectected to an ISP access network" in the "Connected MANET subsection in the PS" --> I could eventually provide some text if there is an agreement on this point. [Teco:] This would be great! Teco. If there is also an agreement on including a requirement section in the PS document "the point that was discussed in Vancouver, but not yet concluded" --> it would be then important to consider some requirements related to this case (this would be security requirements, as well as operational requirements). Comments and feedbacks are more than welcome. Any comment from others, familiar with ISP / network operator requirements? Teco. ---------------------------------------------------------------------------- ------------------------ Van: Hasnaa Moustafa [mailto:hasnaa.moustafa@gmail.com] Verzonden: vrijdag 7 december 2007 20:11 Aan: teco@inf-net.nl CC: autoconf@ietf.org Onderwerp: Re: Autoconf Digest, Vol 23, Issue 18 Hi Teco, Thanks for raising this interesting issue. Considering Commercial ISPs is the way for wide scale MANET deployments. I believe that IP autoconfiguration is one of the tough issues blocking the real MANET deployment by ISPs. Even if we think ofL2 security (existing in WLAN hotspots deployed by ISPs),it is not feasible to apply it in a MANET multi-hop environment, and no standard solution existing nowproviding L2 security in multi-hop MANET environment. I agree with your point that ISP should provide IP autoconfiguration for their clients or even other legitimate clients (belonging to other ISPs, for instance, if there is a trust relationship between different ISPs). And there is a number of requirements that can exist in this case. But the mainquestion (before talking about this issue) concerns the autoconf WG scope: is the WG looking forIP autoconf solutions concerningsuch type of scenario --> (MANETs that extends the service coverage of an ISPaccess network? And of coarse: this is a connected MANET.) IMHO, this is an important scenario highlighting a concrete MANET application and having special requirements. Hassnaa ---------------------------------------------------------------------------- ------------------------ Date: Thu, 6 Dec 2007 21:02:39 +0100 From: "Teco Boot" < teco@inf-net.nl> Subject: [Autoconf] Supporting commercial ISPs To: < autoconf@ietf.org> Message-ID: <013a01c83843$07d54200$177fc600$@nl > Content-Type: text/plain; charset="us-ascii" I have a somewhat fundamental question on AUTOCONF requirements; do we consider commercial ISPs? I think in real world, we have two environments: private networks and Internet. Private networks could use L2 security and within the network there is no hard requirement for access control. However, even in these private networks access control is getting important. For Internet, ISP provide access to their customers. And probably to their customers only. I wonder how we can support this kind of operation. I appreciate any comment from ISPs, on what they want to be supported. I think the outcome has a large impact on the requirements. Teco. ------------------------------ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf End of Autoconf Digest, Vol 23, Issue 18 **************************************** ------=_NextPart_000_0008_01C83CA4.D57755D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Hassnaa,

 

Comments inline.

 

Van:<= /b> = Hasnaa Moustafa [mailto:hasnaa.moustafa@gmail.com]
Verzonden: dinsdag 11 december 2007 16:38
Aan: teco@inf-net.nl
CC: autoconf@ietf.org
Onderwerp: Re: [Autoconf] Supporting commercial = ISPs

 

Hi Teco,

 

Thanks for you reply.

 

There are a number of points that are not so clear = for me.

 

Please see below.

 

Hassnaa

 

On 12/10/07, Teco = Boot <teco@inf-net.nl> wrote: =

Hi Hasnaa,

Thanks for the clear response.
I think we should include some scenarios on extending service coverage = area of an ISP access network in the PS document. Suggested scenarios: =

 

 

Hassnaa: I am not so sure if we need a special = scenario for this, as this type of scenario is a connected one. Then the description = of the connected scenario in the PS could include such a case (MANET connected = to an ISP access network).

 


1)
Full trust between Access Routers and MANET Routers. MANET Links and = Access
Links are protected using L2 security. Border Routers and Access Routers = can
be integrated, i.e. Access Routers may run MANET routing protocol. = Access
Routers may provide prefixes and addresses.

 

Hassnaa:

How do you differentiate between MANET links and = Access links?

-If Access Routers and Border Routers are = integrated in one entity (as you mentioned), then there is no difference, = IMO, between Access links and MANET links.

[Teco:]

In this case, there is no access = link.

 

- When talking about L2 Security (for instance = 802.1x model), I could not see how it could take place in a multi-hop MANET environment. So far, the existing standard mechanisms function = in a WLAN environment (protecting the link between a mobile node and an = Access point). So saying MANET links are protected using L2 security = --> implies the existence of a mechanism that assures L2 security within the multi-hop environment (which does not conform with the reality).

[Teco:]

I am not sure 802.1x cannot be used for MANET links. = 802.11i-2004 describes how this should work for IBSS.

I prefer using pre-shared keys in = MANET.

Many existing MANET products use local configured = settings, for security and other. Manual provisioning of MANET Local Addresses is = natural in such cases. This is why I asked what the added value of Autoconf = is.

 

 

The question here is, what is the added value of = Autoconf? IMHO all nodes
are provisioned before deployment; e.g. security parameters and key
material. Configuring addresses is not that much extra.

 

Hassnaa:

I did not get, what do you mean by "added = value of Autoconf" --> for me the added value of autoconf is the "IP address provision for manet routers" (Maybe I miss = something!).

[Teco:]

Yes, but when keys (and other settings) need to be = configured before deployment, why not configuring MLA = also?

For global addresses, Autoconf functionality can be = useful.

 

 

2)
No trust between Access Routers and MANET routers. Border routers = use
protected L2 links to Access Routers. Border Routers are fixed or = mobile.
Access Routers do typically not provide prefixes, they only provide
addresses to attached nodes.

 

Hassnaa:

If there is no trust between the Access Routers and = the MANET routers, then this does not conform with a MANET connected to an = ISP access network. For commercial deployment of MANETs, each manet = router is considered as a "mobile client", and this "mobile = client" could not be connected to the ISP access network if he is not legitimate (implying "trust relationship" with the Access Routers = directly or indirectly. Directly, if the mobile client is a subscriber with the ISP = that owns the Access routers, while indirectly if the mobile client is a = subscriber with another ISP that has a trust relationship with the current = ISP.

[Teco:]

In both the  “directly” and = “indirectly” case, each MANET Router that can access the ISP network is also Border = Router, OK?

 

 

In this case, assistance from NEMO functionally and = HA could be used for
providing prefixes to Border Routers. MANET routing protocol may run on = MRHA
tunnel.
The question here is, what is the trust relation between the MANET = Routers?
And also what is the added value of Autoconf in case of configured = security
parameters and key material?

 

Hassnaa: Same previous comment for the "added = value of Autoconf"!

[Teco:]

I am just asking myself this question on added value of = Autoconf.

If access to ISP network is managed on Access Router = – Border Router link, current global address assignment protocols are used = and Autoconf is not needed.

If there is no preconfigured trust relation between the = MANET Routers, but MANET Routers want to communicate with each other, MLA is = needed. Here Autoconf functionality can be useful.

 

 

3)
New security mechanism for setting up trust relation between Access = Routers
and MANET Routers. In this case, each MANET Router sets up a secured = link to
one or more Access Routers. I think network operators require some kind = of
hardware authentication (e.g. SIM), or maybe some form of certificates = could
be used. NEMO can be used in this case also.

 

Hassnaa: I think that this point goes into details concerning the security issue (which is not sure to be in the scope of = the WG).

[Teco:]

Partly agreed. I think we should not work on security = solutions, but I think it is important to know what the requirements for real world = deployment are. If we do not cope with it, the newly defined protocols are dead = already. I think it is better to circumvent this.

 

One of the ideas in Autoconf is, is providing a facility = for multihop MANET communication between a MANET Router and the Internet. = Our goal is to provide a Problem Statement document. If there is a security = problem with this topology, I do not see a reason why we should not describe this. = Solving the problem is another thing, it requires rechartering Autoconf or = something else.

 

 

I did not use "new terminology" Internet Configuration Provider, as I do not
know what this is.
I used Access Router instead of ISP Edge Router, as this is a well = known
name for this entity (RFC3753).

What do you think?

 

Hassnaa: IMHO, it is interesting to include the = case of "a MANET connectected to an ISP access network" in the "Connected MANET subsection in the PS" --> I could = eventually provide some text if there is an agreement on this point. =

[Teco:]

This would be great!

 

Teco.

 

If there is also an agreement on including a = requirement section in the PS document "the point that was discussed in = Vancouver, but not yet concluded" --> it would be then important to consider = some requirements related to this case (this would be security requirements, = as well as operational requirements).

 

 

Comments and feedbacks are more than = welcome.

 

 

 

Any comment from = others, familiar with ISP / network operator requirements?

Teco.

-------------------------------------------------------------------------= ---
------------------------
Van: Hasnaa Moustafa [mailto:hasnaa.moustafa@gmail.com]<= br> Verzonden: vrijdag 7 december 2007 20:11
Aan: teco@inf-net.nl
CC: autoconf@ietf.org
Onderwerp: Re: Autoconf Digest, Vol 23, Issue 18

Hi Teco,

Thanks for raising this interesting issue.

Considering Commercial ISPs is the way for wide scale MANET deployments. = I
believe that IP autoconfiguration is one of the tough issues blocking = the
real MANET deployment by ISPs.

Even if we think ofL2 security (existing in WLAN hotspots deployed = by
ISPs),it is not feasible to apply it in a MANET multi-hop environment, = and
no standard solution existing nowproviding L2 security in multi-hop = MANET
environment.

I agree with your point that ISP should provide IP autoconfiguration = for
their clients or even other legitimate clients (belonging to other ISPs, = for
instance, if there is a trust relationship between different ISPs). = And
there is a number of requirements that can exist in this case.
But the mainquestion (before talking about this issue) concerns the
autoconf WG scope: is the WG looking forIP autoconf solutions
concerningsuch type of scenario --> (MANETs that extends the = service
coverage of an ISPaccess network? And of coarse: this is a connected
MANET.)

IMHO, this is an important scenario highlighting a concrete MANET
application and having special requirements.

Hassnaa
-------------------------------------------------------------------------= ---
------------------------
Date: Thu, 6 Dec 2007 21:02:39 +0100
From: "Teco Boot" < teco@inf-net.nl>
Subject: [Autoconf] Supporting commercial ISPs
To: < autoconf@ietf.org>
Message-ID: <013a01c83843$07d54200$177fc600$@nl >
Content-Type: text/plain; charset=3D"us-ascii"

I have a somewhat fundamental question on AUTOCONF requirements; do = we
consider commercial ISPs?

I think in real world, we have two environments: private networks and =
Internet.

Private networks could use L2 security and within the network there is = no
hard requirement for access control. However, even in these private = networks

access control is getting important.

For Internet, ISP provide access to their customers. And probably to = their
customers only. I wonder how we can support this kind of operation.

I appreciate any comment from ISPs, on what they want to be supported. I =
think the outcome has a large impact on the requirements.

Teco.

------------------------------

_______________________________________________
Autoconf mailing list
Autoconf@ietf.org
https://www1.iet= f.org/mailman/listinfo/autoconf


End of Autoconf Digest, Vol 23, Issue 18
****************************************


 

------=_NextPart_000_0008_01C83CA4.D57755D0-- --===============0441792085== 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 --===============0441792085==-- From autoconf-bounces@ietf.org Wed Dec 12 04:33:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Ny3-00084s-T4; Wed, 12 Dec 2007 04:33:27 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1J2Ny2-00080X-Og for autoconf-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 04:33:26 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Ny2-0007sS-6w for autoconf@ietf.org; Wed, 12 Dec 2007 04:33:26 -0500 Received: from hpsmtp-eml14.kpnxchange.com ([213.75.38.114]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2Ny1-0002MU-7J for autoconf@ietf.org; Wed, 12 Dec 2007 04:33:25 -0500 Received: from hpsmtp-eml04.kpnxchange.com ([213.75.38.104]) by hpsmtp-eml14.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 10:33:24 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml04.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 10:33:23 +0100 From: "Teco Boot" To: , References: <1196895350.27208.93.camel@localhost> In-Reply-To: <1196895350.27208.93.camel@localhost> Subject: RE: [Autoconf] List of requirements in draft-ietf-autoconf-problem-statement Date: Wed, 12 Dec 2007 10:33:23 +0100 Message-ID: <001201c83ca2$0a65ee80$1f31cb80$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg3khgmvIGi3pk0R8+sfloS4PMGmQFCrPFg Content-Language: nl X-OriginalArrivalTime: 12 Dec 2007 09:33:23.0435 (UTC) FILETIME=[0A3F53B0:01C83CA2] X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 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 Somewhat late response on this. I prefer splitting requirements in MUST / SHOULD and MAY sections. draft-eddy-nemo-aero-reqs-02.txt use sections Required Characteristics = and Desirable Characteristics. I propose a new desire: =3D=3D=3D Des# - Address generation for efficient signaling The assigned addresses may be optimized for compression when using Generalized MANET Packet/Message Format [packetbb]. Used addresses in = the MANET, with a common first set or last set of octets can be signaled = more efficient.=20 The assigned prefixes may be optimized for aggregation. Aggregation on = the MANET router reduce advertized prefixes to a minimum. In the optimal = case, only one prefix is advertized per MANET Router. =3D=3D=3D I think this functionality is needed with these large IPv6 addresses, in cases where bandwidth on MANET links is restricted or frame size is an issue. Teco. > -----Oorspronkelijk bericht----- > Van: Carlos Jes=FAs Bernardos Cano [mailto:cjbc@it.uc3m.es] > Verzonden: woensdag 5 december 2007 23:56 > Aan: autoconf@ietf.org > Onderwerp: [Autoconf] List of requirements in draft-ietf-autoconf- > problem-statement >=20 > Hi all, >=20 > As expressed by me and others, it may be helpful to add a list of > clear requirements of MANET IP autoconf mechanisms in the problem > statement draft. This would help to understand what (and maybe how) = has > to be done to solve the problem of IP autoconf in MANETs. >=20 > Collecting this list is not easy, and therefore this mail is a > humble attempt to get other people's opinion and start discussing what > this list should contain. To start, I'd propose the following: >=20 > R01. The solution must be implemented at the IP layer level. >=20 > (Following recent discussions, my understanding is that we are working > at the IP layer...) >=20 > R02. The solution must provide a MANET Router with an IPv6 address for > each of its MANET interfaces. >=20 > R03. The solution must provide a MANET Router with an IPv6 prefix to > configure each of its non-MANET interfaces and be advertised for > configuration of non-MANET attached nodes. >=20 > R04. The solution must work for MANETs using symmetric and assymetric > links. >=20 > R05. The solution should not be independent of any particular MANET > routing protocol. >=20 > R06. The solution must provide MANET routers with unique addresses and > non-overlapping IPv6 prefixes. >=20 > R07. The solution should detect and resolve IP address conflicts as a > result of network mergers. >=20 > R08. The solution must provide MANET routers with IPv6 > addresses/prefixes topologically correct/coherent when the MANET > is connected to an external network (e.g., the Internet). >=20 > R09. The solution should present the same level of security than > existing IP autoconfiguration mechanisms. >=20 > R10. The solution must ensure backward compatibility with other > standards defined by the IETF. In particular, this includes the > following: >=20 > R10.1. The solution must not prevent the proper operation of > Mobile IPv6 (i.e., the solution must allow = MIPv6-enabled > nodes attached to a MANET router to operate either the > CN, HA, or MN operations defined in [RFC3775]). >=20 > R11. The solution must not require modifications to any node other = than > MANET routers and required provisioning servers. >=20 > R12. The solution may be designed in such a modular way that some of > the previous requirements are not met if not required by a > particular application scenario. >=20 >=20 > As previously stated, this is mainly for discussion. I'm not even > saying I agree with all of them ;-). >=20 > Comments are welcome :-D. >=20 > Regards, >=20 > Carlos >=20 > -- > =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws > Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > WEEDEV 2008: 1st Workshop on Experimental Evaluation and > Deployment Experiences on Vehicular networks > http://www.weedev.org/ > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Dec 12 08:29:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Reo-0005ri-Jm; Wed, 12 Dec 2007 08:29:50 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1J2Rem-0005rH-KQ for autoconf-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 08:29:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Rel-0005pN-Qn for autoconf@ietf.org; Wed, 12 Dec 2007 08:29:47 -0500 Received: from nf-out-0910.google.com ([64.233.182.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2Rej-0001in-3w for autoconf@ietf.org; Wed, 12 Dec 2007 08:29:47 -0500 Received: by nf-out-0910.google.com with SMTP id d21so188430nfb.39 for ; Wed, 12 Dec 2007 05:29:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=9f35k6Uy0xvfG/C2mQ0LCPi9YqzQjN0jJRMe0Fxq5Ac=; b=B5pLuyRe+w4QVmz++zJy7VCyRUZCXvhdqniMkOAc4xR6dLdvGvtAHkmWZjxFbkDYVE7iuO6ctNe8r3d1rfLDJwJ7nKXFwp26JSbAAm1cGFblawWcew55gaO0g49rB9rpj99AoVhagKe9r/i+n0n4sCabfhsHStLwVzT2nBtsMJw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=JpqBkEdC00ogf4fDOKpCp1xWNNSBb1tq7hoDOC6P1Ery8lofY5IWjsiv/cL4jZ5rXKjgZW9DCGzCrl5Q350i0GLz8zTg2M9WgDt4hRHPzRToU/88xPgZJEPZKnkIMHi0EDrPLjpRY+vieXAqE60oKu+tudewjIjPn9GGK4zhNbo= Received: by 10.78.201.15 with SMTP id y15mr616798huf.38.1197466183965; Wed, 12 Dec 2007 05:29:43 -0800 (PST) Received: by 10.78.31.5 with HTTP; Wed, 12 Dec 2007 05:29:43 -0800 (PST) Message-ID: Date: Wed, 12 Dec 2007 14:29:43 +0100 From: "Hasnaa Moustafa" To: teco@inf-net.nl In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bd14a31ed5bce9138736cf0e98bb014 Cc: autoconf@ietf.org Subject: [Autoconf] Re: Autoconf Digest, Vol 23, Issue 20 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: , Content-Type: multipart/mixed; boundary="===============1170583546==" Errors-To: autoconf-bounces@ietf.org --===============1170583546== Content-Type: multipart/alternative; boundary="----=_Part_6173_20256176.1197466183955" ------=_Part_6173_20256176.1197466183955 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Teco, Thanks for your reply. Please so my comments below. Regards, Hassnaa Date: Wed, 12 Dec 2007 09:53:21 +0100 > From: "Teco Boot" > Subject: RE: [Autoconf] Supporting commercial ISPs > To: "'Hasnaa Moustafa'" > Cc: autoconf@ietf.org > Message-ID: <000701c83c9c$73b2edd0$5b18c970$@nl> > Content-Type: text/plain; charset="us-ascii" > > Hi Hassnaa, > > > > Comments inline. > > > > Van: Hasnaa Moustafa [mailto:hasnaa.moustafa@gmail.com] > Verzonden: dinsdag 11 december 2007 16:38 > Aan: teco@inf-net.nl > CC: autoconf@ietf.org > Onderwerp: Re: [Autoconf] Supporting commercial ISPs > > > > Hi Teco, > > > > Thanks for you reply. > > > > There are a number of points that are not so clear for me. > > > > Please see below. > > > > Hassnaa > > > > On 12/10/07, Teco Boot wrote: > > Hi Hasnaa, > > Thanks for the clear response. > I think we should include some scenarios on extending service coverage > area > of an ISP access network in the PS document. Suggested scenarios: > > > > > > Hassnaa: I am not so sure if we need a special scenario for this, as this > type of scenario is a connected one. Then the description of the connected > scenario in the PS could include such a case (MANET connected to an ISP > access network). > > > > > 1) > Full trust between Access Routers and MANET Routers. MANET Links and > Access > Links are protected using L2 security. Border Routers and Access Routers > can > > be integrated, i.e. Access Routers may run MANET routing protocol. Access > Routers may provide prefixes and addresses. > > > > Hassnaa: > > How do you differentiate between MANET links and Access links? > > -If Access Routers and Border Routers are integrated in one entity (as you > mentioned), then there is no difference, IMO, between Access links and > MANET > links. > > [Teco:] > > In this case, there is no access link. Hassnaa: I agree, in this case, all links can be considered as MANET links. - When talking about L2 Security (for instance 802.1x model), I could not > see how it could take place in a multi-hop MANET environment. So far, the > existing standard mechanisms function in a WLAN environment (protecting > the > link between a mobile node and an Access point). So saying MANET links are > protected using L2 security --> implies the existence of a mechanism that > assures L2 security within the multi-hop environment (which does not > conform > with the reality). > > [Teco:] > > I am not sure 802.1x cannot be used for MANET links. 802.11i-2004describes > how this should work for IBSS. Hassnaa: 802.11i is mainly for WLAN, and they define as an option the authentication using PSK for the ad hoc mode. But this concerns the peer-to-peer ad hoc communication and does not concern the multi-hop communication. Besides, the PSK proved to be a weak authentication method. I prefer using pre-shared keys in MANET. Hassnaa: As I mentioned above, PSK proved to be a weak authentication method (same weakness of the WEP security solutions) and also has its management burden. Many existing MANET products use local configured settings, for security and > other. Manual provisioning of MANET Local Addresses is natural in such > cases. This is why I asked what the added value of Autoconf is. Hassnaa: Manual provisioning is only practical for small networks configuration and closed environments, which is not the general case. Also, with nodes' mobility (partitioning and merging issues, ...), there would be a hard need for dynamic (automatic) address configuration for easier IP address assignment management. The question here is, what is the added value of Autoconf? IMHO all nodes > are provisioned before deployment; e.g. security parameters and key > material. Configuring addresses is not that much extra. > > > > Hassnaa: > > I did not get, what do you mean by "added value of Autoconf" --> for me > the > added value of autoconf is the "IP address provision for manet routers" > (Maybe I miss something!). > > [Teco:] > > Yes, but when keys (and other settings) need to be configured before > deployment, why not configuring MLA also? > > For global addresses, Autoconf functionality can be useful. Hassnaa: please see my previuos comment. 2) > No trust between Access Routers and MANET routers. Border routers use > protected L2 links to Access Routers. Border Routers are fixed or mobile. > Access Routers do typically not provide prefixes, they only provide > addresses to attached nodes. > > > > Hassnaa: > > If there is no trust between the Access Routers and the MANET routers, > then > this does not conform with a MANET connected to an ISP access network. For > commercial deployment of MANETs, each manet router is considered as a > "mobile client", and this "mobile client" could not be connected to the > ISP > access network if he is not legitimate (implying "trust relationship" with > the Access Routers directly or indirectly. Directly, if the mobile client > is > a subscriber with the ISP that owns the Access routers, while indirectly > if > the mobile client is a subscriber with another ISP that has a trust > relationship with the current ISP. > > [Teco:] > > In both the "directly" and "indirectly" case, each MANET Router that can > access the ISP network is also Border Router, OK? Hassnaa: If this MANET Router has a direct link with the Access Router, then I agree that it is a Border Router. Do you mean this? In this case, assistance from NEMO functionally and HA could be used for > providing prefixes to Border Routers. MANET routing protocol may run on > MRHA > > tunnel. > The question here is, what is the trust relation between the MANET > Routers? > And also what is the added value of Autoconf in case of configured > security > parameters and key material? > > > > Hassnaa: Same previous comment for the "added value of Autoconf"! > > [Teco:] > > I am just asking myself this question on added value of Autoconf. > > If access to ISP network is managed on Access Router - Border Router link, > current global address assignment protocols are used and Autoconf is not > needed. Hassnaa: I did not get what you mean by "current global address assignment protocol"! IMO, Autoconf is required (even in the presence of ISP) for providing unique IP addresses among the multi-hop nodes and also for managing IP addresses in case of nodes' leave. If there is no preconfigured trust relation between the MANET Routers, but > MANET Routers want to communicate with each other, MLA is needed. Here > Autoconf functionality can be useful. Hassnaa: IMO, the two issues (IP autoconf) and (Trust) should Co-exist in the case of a MANET connected to an ISP access network. 3) > New security mechanism for setting up trust relation between Access > Routers > and MANET Routers. In this case, each MANET Router sets up a secured link > to > > one or more Access Routers. I think network operators require some kind of > hardware authentication (e.g. SIM), or maybe some form of certificates > could > be used. NEMO can be used in this case also. > > > > Hassnaa: I think that this point goes into details concerning the security > issue (which is not sure to be in the scope of the WG). > > [Teco:] > > Partly agreed. I think we should not work on security solutions, but I > think > it is important to know what the requirements for real world deployment > are. > If we do not cope with it, the newly defined protocols are dead already. I > think it is better to circumvent this. Hassnaa: I totally agree that some requirements (related to real world deployment) should be highlighted. One of the ideas in Autoconf is, is providing a facility for multihop MANET > communication between a MANET Router and the Internet. Our goal is to > provide a Problem Statement document. If there is a security problem with > this topology, I do not see a reason why we should not describe this. > Solving the problem is another thing, it requires rechartering Autoconf or > something else. > > > > > > I did not use "new terminology" Internet Configuration Provider, as I do > not > know what this is. > I used Access Router instead of ISP Edge Router, as this is a well known > name for this entity (RFC3753). > > What do you think? > > > > Hassnaa: IMHO, it is interesting to include the case of "a MANET > connectected to an ISP access network" in the "Connected MANET subsection > in > the PS" --> I could eventually provide some text if there is an agreement > on > this point. > > [Teco:] > > This would be great! Hassnaa: Then, we need a general agreement on this. Teco. > > > > If there is also an agreement on including a requirement section in the PS > document "the point that was discussed in Vancouver, but not yet > concluded" > --> it would be then important to consider some requirements related to > this > case (this would be security requirements, as well as operational > requirements). > > > > > > Comments and feedbacks are more than welcome. > > > > > > > > Any comment from others, familiar with ISP / network operator > requirements? > > Teco. > > > ---------------------------------------------------------------------------- > > ------------------------ > Van: Hasnaa Moustafa [mailto:hasnaa.moustafa@gmail.com] > Verzonden: vrijdag 7 december 2007 20:11 > Aan: teco@inf-net.nl > CC: autoconf@ietf.org > Onderwerp: Re: Autoconf Digest, Vol 23, Issue 18 > > Hi Teco, > > Thanks for raising this interesting issue. > > Considering Commercial ISPs is the way for wide scale MANET deployments. I > believe that IP autoconfiguration is one of the tough issues blocking the > real MANET deployment by ISPs. > > Even if we think ofL2 security (existing in WLAN hotspots deployed by > ISPs),it is not feasible to apply it in a MANET multi-hop environment, and > no standard solution existing nowproviding L2 security in multi-hop MANET > environment. > > I agree with your point that ISP should provide IP autoconfiguration for > their clients or even other legitimate clients (belonging to other ISPs, > for > > instance, if there is a trust relationship between different ISPs). And > there is a number of requirements that can exist in this case. > But the mainquestion (before talking about this issue) concerns the > autoconf WG scope: is the WG looking forIP autoconf solutions > concerningsuch type of scenario --> (MANETs that extends the service > coverage of an ISPaccess network? And of coarse: this is a connected > MANET.) > > IMHO, this is an important scenario highlighting a concrete MANET > application and having special requirements. > > Hassnaa > > ---------------------------------------------------------------------------- > ------------------------ > Date: Thu, 6 Dec 2007 21:02:39 +0100 > From: "Teco Boot" < teco@inf-net.nl> > Subject: [Autoconf] Supporting commercial ISPs > To: < autoconf@ietf.org> > Message-ID: <013a01c83843$07d54200$177fc600$@nl > > Content-Type: text/plain; charset="us-ascii" > > I have a somewhat fundamental question on AUTOCONF requirements; do we > consider commercial ISPs? > > I think in real world, we have two environments: private networks and > Internet. > > Private networks could use L2 security and within the network there is no > hard requirement for access control. However, even in these private > networks > > access control is getting important. > > For Internet, ISP provide access to their customers. And probably to their > customers only. I wonder how we can support this kind of operation. > > I appreciate any comment from ISPs, on what they want to be supported. I > think the outcome has a large impact on the requirements. > > Teco. > > ------------------------------ > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf > > > End of Autoconf Digest, Vol 23, Issue 18 > **************************************** > > > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://www1.ietf.org/pipermail/autoconf/attachments/20071212/08abec50/attachment.html > > ------------------------------ > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf > > > End of Autoconf Digest, Vol 23, Issue 20 > **************************************** > ------=_Part_6173_20256176.1197466183955 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Teco,
 
Thanks for your reply.
 
Please so my comments below.
 
Regards,
Hassnaa

 

Date: Wed, 12 Dec 2007 09:53:21 +0100
From: "Teco Boot" < teco@inf-net.nl>
Subject: RE: [Autoconf] Supporting commercial ISPs
To: "'Hasnaa Moustafa'" <hasnaa.moustafa@gmail.com>
Cc: autoconf@ietf.org
Message-ID: <000701c83c9c$73b2edd0$5b18c970$@nl>
Content-Type: text/plain; charset="us-ascii"

Hi Hassnaa,



Comments inline.



Van: Hasnaa Moustafa [mailto: hasnaa.moustafa@gmail.com]
Verzonden: dinsdag 11 december 2007 16:38
Aan: teco@inf-net.nl
CC: autoconf@ietf.org
Onderwerp: Re: [Autoconf] Supporting commercial ISPs



Hi Teco,



Thanks for you reply.



There are a number of points that are not so clear for me.



Please see below.



Hassnaa



On 12/10/07, Teco Boot <teco@inf-net.nl> wrote:

Hi Hasnaa,

Thanks for the clear response.
I think we should include some scenarios on extending service coverage area
of an ISP access network in the PS document. Suggested scenarios:





Hassnaa: I am not so sure if we need a special scenario for this, as this
type of scenario is a connected one. Then the description of the connected
scenario in the PS could include such a case (MANET connected to an ISP
access network).




1)
Full trust between Access Routers and MANET Routers. MANET Links and Access
Links are protected using L2 security. Border Routers and Access Routers can

be integrated, i.e. Access Routers may run MANET routing protocol. Access
Routers may provide prefixes and addresses.



Hassnaa:

How do you differentiate between MANET links and Access links?

-If Access Routers and Border Routers are integrated in one entity (as you
mentioned), then there is no difference, IMO, between Access links and MANET
links.

[Teco:]

In this case, there is no access link.
 
Hassnaa: I agree, in this case, all links can be considered as MANET links.
 

- When talking about L2 Security (for instance 802.1x model), I could not
see how it could take place in a multi-hop MANET environment. So far, the
existing standard mechanisms function in a WLAN environment (protecting the
link between a mobile node and an Access point). So saying MANET links are
protected using L2 security --> implies the existence of a mechanism that
assures L2 security within the multi-hop environment (which does not conform
with the reality).

[Teco:]

I am not sure 802.1x cannot be used for MANET links. 802.11i-2004 describes
how this should work for IBSS.
 
 
Hassnaa: 802.11i is mainly for WLAN, and they define as an option the authentication using PSK for the ad hoc mode. But this concerns the peer-to-peer ad hoc communication and does not concern the multi-hop communication. Besides, the PSK proved to be a weak authentication method.

I prefer using pre-shared keys in MANET.
 
 
Hassnaa: As I mentioned above, PSK proved to be a weak authentication method (same weakness of the WEP security solutions) and also has its management burden.
 

Many existing MANET products use local configured settings, for security and
other. Manual provisioning of MANET Local Addresses is natural in such
cases. This is why I asked what the added value of Autoconf is.
 
Hassnaa: Manual provisioning is only practical for small networks configuration and closed environments, which is not the general case. Also, with nodes' mobility (partitioning and merging issues, ...), there would be a hard need for dynamic (automatic) address configuration for easier IP address assignment management.
 

The question here is, what is the added value of Autoconf? IMHO all nodes
are provisioned before deployment; e.g. security parameters and key
material. Configuring addresses is not that much extra.



Hassnaa:

I did not get, what do you mean by "added value of Autoconf" --> for me the
added value of autoconf is the "IP address provision for manet routers"
(Maybe I miss something!).

[Teco:]

Yes, but when keys (and other settings) need to be configured before
deployment, why not configuring MLA also?

For global addresses, Autoconf functionality can be useful.
 
 
Hassnaa: please see my previuos comment.
 

2)
No trust between Access Routers and MANET routers. Border routers use
protected L2 links to Access Routers. Border Routers are fixed or mobile.
Access Routers do typically not provide prefixes, they only provide
addresses to attached nodes.



Hassnaa:

If there is no trust between the Access Routers and the MANET routers, then
this does not conform with a MANET connected to an ISP access network. For
commercial deployment of MANETs, each manet router is considered as a
"mobile client", and this "mobile client" could not be connected to the ISP
access network if he is not legitimate (implying "trust relationship" with
the Access Routers directly or indirectly. Directly, if the mobile client is
a subscriber with the ISP that owns the Access routers, while indirectly if
the mobile client is a subscriber with another ISP that has a trust
relationship with the current ISP.

[Teco:]

In both the  "directly" and "indirectly" case, each MANET Router that can
access the ISP network is also Border Router, OK?
 
 
Hassnaa: If this MANET Router has a direct link with the Access Router, then I agree that it is a Border Router. Do you mean this?
 

In this case, assistance from NEMO functionally and HA could be used for
providing prefixes to Border Routers. MANET routing protocol may run on MRHA

tunnel.
The question here is, what is the trust relation between the MANET Routers?
And also what is the added value of Autoconf in case of configured security
parameters and key material?



Hassnaa: Same previous comment for the "added value of Autoconf"!

[Teco:]

I am just asking myself this question on added value of Autoconf.

If access to ISP network is managed on Access Router - Border Router link,
current global address assignment protocols are used and Autoconf is not
needed.
 
Hassnaa: I did not get what you mean by "current global address assignment protocol"!
IMO, Autoconf is required (even in the presence of ISP) for providing unique IP addresses among the multi-hop nodes and also for managing IP addresses in case of nodes' leave.

If there is no preconfigured trust relation between the MANET Routers, but
MANET Routers want to communicate with each other, MLA is needed. Here
Autoconf functionality can be useful.
 
Hassnaa: IMO, the two issues (IP autoconf) and (Trust) should Co-exist in the case of a MANET connected to an ISP access network.

3)
New security mechanism for setting up trust relation between Access Routers
and MANET Routers. In this case, each MANET Router sets up a secured link to

one or more Access Routers. I think network operators require some kind of
hardware authentication (e.g. SIM), or maybe some form of certificates could
be used. NEMO can be used in this case also.



Hassnaa: I think that this point goes into details concerning the security
issue (which is not sure to be in the scope of the WG).

[Teco:]

Partly agreed. I think we should not work on security solutions, but I think
it is important to know what the requirements for real world deployment are.
If we do not cope with it, the newly defined protocols are dead already. I
think it is better to circumvent this.
 
Hassnaa: I totally agree that some requirements (related to real world deployment) should be highlighted.
 

One of the ideas in Autoconf is, is providing a facility for multihop MANET
communication between a MANET Router and the Internet. Our goal is to
provide a Problem Statement document. If there is a security problem with
this topology, I do not see a reason why we should not describe this.
Solving the problem is another thing, it requires rechartering Autoconf or
something else.





I did not use "new terminology" Internet Configuration Provider, as I do not
know what this is.
I used Access Router instead of ISP Edge Router, as this is a well known
name for this entity (RFC3753).

What do you think?



Hassnaa: IMHO, it is interesting to include the case of "a MANET
connectected to an ISP access network" in the "Connected MANET subsection in
the PS" --> I could eventually provide some text if there is an agreement on
this point.

[Teco:]

This would be great!
 
 
Hassnaa: Then, we need a general agreement on this.
 
 

Teco.



If there is also an agreement on including a requirement section in the PS
document "the point that was discussed in Vancouver, but not yet concluded"
--> it would be then important to consider some requirements related to this
case (this would be security requirements, as well as operational
requirements).





Comments and feedbacks are more than welcome.







Any comment from others, familiar with ISP / network operator requirements?

Teco.

----------------------------------------------------------------------------

------------------------
Van: Hasnaa Moustafa [mailto:hasnaa.moustafa@gmail.com]
Verzonden: vrijdag 7 december 2007 20:11
Aan: teco@inf-net.nl  <mailto: teco@inf-net.nl>
CC: autoconf@ietf.org
Onderwerp: Re: Autoconf Digest, Vol 23, Issue 18

Hi Teco,

Thanks for raising this interesting issue.

Considering Commercial ISPs is the way for wide scale MANET deployments. I
believe that IP autoconfiguration is one of the tough issues blocking the
real MANET deployment by ISPs.

Even if we think ofL2 security (existing in WLAN hotspots deployed by
ISPs),it is not feasible to apply it in a MANET multi-hop environment, and
no standard solution existing nowproviding L2 security in multi-hop MANET
environment.

I agree with your point that ISP should provide IP autoconfiguration for
their clients or even other legitimate clients (belonging to other ISPs, for

instance, if there is a trust relationship between different ISPs). And
there is a number of requirements that can exist in this case.
But the mainquestion (before talking about this issue) concerns the
autoconf WG scope: is the WG looking forIP autoconf solutions
concerningsuch type of scenario --> (MANETs that extends the service
coverage of an ISPaccess network? And of coarse: this is a connected
MANET.)

IMHO, this is an important scenario highlighting a concrete MANET
application and having special requirements.

Hassnaa
----------------------------------------------------------------------------
------------------------
Date: Thu, 6 Dec 2007 21:02:39 +0100
From: "Teco Boot" < teco@inf-net.nl>
Subject: [Autoconf] Supporting commercial ISPs
To: < autoconf@ietf.org>
Message-ID: <013a01c83843$07d54200$177fc600$@nl >
Content-Type: text/plain; charset="us-ascii"

I have a somewhat fundamental question on AUTOCONF requirements; do we
consider commercial ISPs?

I think in real world, we have two environments: private networks and
Internet.

Private networks could use L2 security and within the network there is no
hard requirement for access control. However, even in these private networks

access control is getting important.

For Internet, ISP provide access to their customers. And probably to their
customers only. I wonder how we can support this kind of operation.

I appreciate any comment from ISPs, on what they want to be supported. I
think the outcome has a large impact on the requirements.

Teco.

------------------------------

_______________________________________________
Autoconf mailing list
Autoconf@ietf.org
https://www1.ietf.org/mailman/listinfo/autoconf


End of Autoconf Digest, Vol 23, Issue 18
****************************************






-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www1.ietf.org/pipermail/autoconf/attachments/20071212/08abec50/attachment.html

------------------------------

_______________________________________________
Autoconf mailing list
Autoconf@ietf.org
https://www1.ietf.org/mailman/listinfo/autoconf


End of Autoconf Digest, Vol 23, Issue 20
****************************************

------=_Part_6173_20256176.1197466183955-- --===============1170583546== 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 --===============1170583546==-- From autoconf-bounces@ietf.org Wed Dec 12 09:08:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2SGc-0002Hf-UW; Wed, 12 Dec 2007 09:08:54 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1J2SGb-0002HY-Ob for autoconf-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 09:08:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2SGb-0002HQ-67 for autoconf@ietf.org; Wed, 12 Dec 2007 09:08:53 -0500 Received: from hpsmtp-eml12.kpnxchange.com ([213.75.38.112]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2SGZ-000507-Oc for autoconf@ietf.org; Wed, 12 Dec 2007 09:08:52 -0500 Received: from hpsmtp-eml03.kpnxchange.com ([213.75.38.103]) by hpsmtp-eml12.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 15:08:50 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml03.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 15:08:47 +0100 From: "Teco Boot" To: "'Hasnaa Moustafa'" References: In-Reply-To: Subject: Re: [Autoconf] Supporting commercial ISPs Date: Wed, 12 Dec 2007 15:08:47 +0100 Message-ID: <002401c83cc8$847e61e0$8d7b25a0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg8ww6FsBfkt/jRR0muZGf2OJkNFgAANy2Q Content-Language: nl X-OriginalArrivalTime: 12 Dec 2007 14:08:49.0159 (UTC) FILETIME=[8458B170:01C83CC8] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0d73acca95146f46cb72e01fb974515 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: , Content-Type: multipart/mixed; boundary="===============1792062804==" Errors-To: autoconf-bounces@ietf.org Dit is een meerdelig bericht met een MIME-indeling. --===============1792062804== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0025_01C83CD0.E642C9E0" Content-Language: nl Dit is een meerdelig bericht met een MIME-indeling. ------=_NextPart_000_0025_01C83CD0.E642C9E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Once againJ, comments inline. I think this mail gets hard to read. I suggest we close this mail-discussion and take the next step on what to add in PS document. I think we have enough input now. Teco. Van: Hasnaa Moustafa [mailto:hasnaa.moustafa@gmail.com] Verzonden: woensdag 12 december 2007 14:30 Aan: teco@inf-net.nl CC: autoconf@ietf.org Onderwerp: Re: Autoconf Digest, Vol 23, Issue 20 Hi Teco, Thanks for your reply. Please so my comments below. Regards, Hassnaa Date: Wed, 12 Dec 2007 09:53:21 +0100 From: "Teco Boot" < teco@inf-net.nl> Subject: RE: [Autoconf] Supporting commercial ISPs To: "'Hasnaa Moustafa'" Cc: autoconf@ietf.org Message-ID: <000701c83c9c$73b2edd0$5b18c970$@nl> Content-Type: text/plain; charset="us-ascii" Hi Hassnaa, Comments inline. Van: Hasnaa Moustafa [mailto: hasnaa.moustafa@gmail.com] Verzonden: dinsdag 11 december 2007 16:38 Aan: teco@inf-net.nl CC: autoconf@ietf.org Onderwerp: Re: [Autoconf] Supporting commercial ISPs Hi Teco, Thanks for you reply. There are a number of points that are not so clear for me. Please see below. Hassnaa On 12/10/07, Teco Boot wrote: Hi Hasnaa, Thanks for the clear response. I think we should include some scenarios on extending service coverage area of an ISP access network in the PS document. Suggested scenarios: Hassnaa: I am not so sure if we need a special scenario for this, as this type of scenario is a connected one. Then the description of the connected scenario in the PS could include such a case (MANET connected to an ISP access network). 1) Full trust between Access Routers and MANET Routers. MANET Links and Access Links are protected using L2 security. Border Routers and Access Routers can be integrated, i.e. Access Routers may run MANET routing protocol. Access Routers may provide prefixes and addresses. Hassnaa: How do you differentiate between MANET links and Access links? -If Access Routers and Border Routers are integrated in one entity (as you mentioned), then there is no difference, IMO, between Access links and MANET links. [Teco:] In this case, there is no access link. Hassnaa: I agree, in this case, all links can be considered as MANET links. - When talking about L2 Security (for instance 802.1x model), I could not see how it could take place in a multi-hop MANET environment. So far, the existing standard mechanisms function in a WLAN environment (protecting the link between a mobile node and an Access point). So saying MANET links are protected using L2 security --> implies the existence of a mechanism that assures L2 security within the multi-hop environment (which does not conform with the reality). [Teco:] I am not sure 802.1x cannot be used for MANET links. 802.11i-2004 describes how this should work for IBSS. Hassnaa: 802.11i is mainly for WLAN, and they define as an option the authentication using PSK for the ad hoc mode. But this concerns the peer-to-peer ad hoc communication and does not concern the multi-hop communication. Besides, the PSK proved to be a weak authentication method. [Teco:] We can have long discussions on PSK. In my environment, key management other than PSK is not accepted. I suggest not to discuss this, as it is totally out-of-scope of Autoconf and our opinions on it does not help us at all. I prefer using pre-shared keys in MANET. Hassnaa: As I mentioned above, PSK proved to be a weak authentication method (same weakness of the WEP security solutions) and also has its management burden. [Teco:] Oeps. WEP is based on RC4. That is the prime cause of the weakness. I am not aware of a WPA2-PSK weakness, and maybe there are better algorithms (for sure more secret). We are still discussing case 1, where the pre-assumption is that all nodes have trusted links. Maybe this is not applicable in commercial environments, but in military and probably in public safety I think this is the current and preferred setup. Things can change here, but don't expect anything soon. Many existing MANET products use local configured settings, for security and other. Manual provisioning of MANET Local Addresses is natural in such cases. This is why I asked what the added value of Autoconf is. Hassnaa: Manual provisioning is only practical for small networks configuration and closed environments, which is not the general case. [Teco:] Agreed, but environments can be quite large. Also, with nodes' mobility (partitioning and merging issues, ...), there would be a hard need for dynamic (automatic) address configuration for easier IP address assignment management. [Teco:] For MLA, I doubt. For Global Addresses, I agree. I expect that only IPsec traffic between MANET Router and Corresponding Nodes is required and that all other traffic must be blocked. So MANET Router acts as host in this case. The question here is, what is the added value of Autoconf? IMHO all nodes are provisioned before deployment; e.g. security parameters and key material. Configuring addresses is not that much extra. Hassnaa: I did not get, what do you mean by "added value of Autoconf" --> for me the added value of autoconf is the "IP address provision for manet routers" (Maybe I miss something!). [Teco:] Yes, but when keys (and other settings) need to be configured before deployment, why not configuring MLA also? For global addresses, Autoconf functionality can be useful. Hassnaa: please see my previuos comment. 2) No trust between Access Routers and MANET routers. Border routers use protected L2 links to Access Routers. Border Routers are fixed or mobile. Access Routers do typically not provide prefixes, they only provide addresses to attached nodes. Hassnaa: If there is no trust between the Access Routers and the MANET routers, then this does not conform with a MANET connected to an ISP access network. For commercial deployment of MANETs, each manet router is considered as a "mobile client", and this "mobile client" could not be connected to the ISP access network if he is not legitimate (implying "trust relationship" with the Access Routers directly or indirectly. Directly, if the mobile client is a subscriber with the ISP that owns the Access routers, while indirectly if the mobile client is a subscriber with another ISP that has a trust relationship with the current ISP. [Teco:] In both the "directly" and "indirectly" case, each MANET Router that can access the ISP network is also Border Router, OK? Hassnaa: If this MANET Router has a direct link with the Access Router, then I agree that it is a Border Router. Do you mean this? [Teco:] Yes In this case, assistance from NEMO functionally and HA could be used for providing prefixes to Border Routers. MANET routing protocol may run on MRHA tunnel. The question here is, what is the trust relation between the MANET Routers? And also what is the added value of Autoconf in case of configured security parameters and key material? Hassnaa: Same previous comment for the "added value of Autoconf"! [Teco:] I am just asking myself this question on added value of Autoconf. If access to ISP network is managed on Access Router - Border Router link, current global address assignment protocols are used and Autoconf is not needed. Hassnaa: I did not get what you mean by "current global address assignment protocol"! IMO, Autoconf is required (even in the presence of ISP) for providing unique IP addresses among the multi-hop nodes and also for managing IP addresses in case of nodes' leave. [Teco:] I think that on the Access Router - Border Router link, address assignment is already available. So when a direct or indirect link between MANET Router and Border Router exists, this should work. Maybe there is somewhat confusion on direct links - indirect links. I think we came up in both cases the MANET Router is Border Router, and that in the indirect case there is "roaming agreement" between the serving ISP (Access Router) and the ISP where the user of the MANET Router / Border Router is subscribed. If there is no preconfigured trust relation between the MANET Routers, but MANET Routers want to communicate with each other, MLA is needed. Here Autoconf functionality can be useful. Hassnaa: IMO, the two issues (IP autoconf) and (Trust) should Co-exist in the case of a MANET connected to an ISP access network. 3) New security mechanism for setting up trust relation between Access Routers and MANET Routers. In this case, each MANET Router sets up a secured link to one or more Access Routers. I think network operators require some kind of hardware authentication (e.g. SIM), or maybe some form of certificates could be used. NEMO can be used in this case also. Hassnaa: I think that this point goes into details concerning the security issue (which is not sure to be in the scope of the WG). [Teco:] Partly agreed. I think we should not work on security solutions, but I think it is important to know what the requirements for real world deployment are. If we do not cope with it, the newly defined protocols are dead already. I think it is better to circumvent this. Hassnaa: I totally agree that some requirements (related to real world deployment) should be highlighted. One of the ideas in Autoconf is, is providing a facility for multihop MANET communication between a MANET Router and the Internet. Our goal is to provide a Problem Statement document. If there is a security problem with this topology, I do not see a reason why we should not describe this. Solving the problem is another thing, it requires rechartering Autoconf or something else. I did not use "new terminology" Internet Configuration Provider, as I do not know what this is. I used Access Router instead of ISP Edge Router, as this is a well known name for this entity (RFC3753). What do you think? Hassnaa: IMHO, it is interesting to include the case of "a MANET connectected to an ISP access network" in the "Connected MANET subsection in the PS" --> I could eventually provide some text if there is an agreement on this point. [Teco:] This would be great! Hassnaa: Then, we need a general agreement on this. Teco. If there is also an agreement on including a requirement section in the PS document "the point that was discussed in Vancouver, but not yet concluded" --> it would be then important to consider some requirements related to this case (this would be security requirements, as well as operational requirements). Comments and feedbacks are more than welcome. Any comment from others, familiar with ISP / network operator requirements? Teco. ---------------------------------------------------------------------------- ------------------------ Van: Hasnaa Moustafa [mailto:hasnaa.moustafa@gmail.com] Verzonden: vrijdag 7 december 2007 20:11 Aan: teco@inf-net.nl CC: autoconf@ietf.org Onderwerp: Re: Autoconf Digest, Vol 23, Issue 18 Hi Teco, Thanks for raising this interesting issue. Considering Commercial ISPs is the way for wide scale MANET deployments. I believe that IP autoconfiguration is one of the tough issues blocking the real MANET deployment by ISPs. Even if we think ofL2 security (existing in WLAN hotspots deployed by ISPs),it is not feasible to apply it in a MANET multi-hop environment, and no standard solution existing nowproviding L2 security in multi-hop MANET environment. I agree with your point that ISP should provide IP autoconfiguration for their clients or even other legitimate clients (belonging to other ISPs, for instance, if there is a trust relationship between different ISPs). And there is a number of requirements that can exist in this case. But the mainquestion (before talking about this issue) concerns the autoconf WG scope: is the WG looking forIP autoconf solutions concerningsuch type of scenario --> (MANETs that extends the service coverage of an ISPaccess network? And of coarse: this is a connected MANET.) IMHO, this is an important scenario highlighting a concrete MANET application and having special requirements. Hassnaa ---------------------------------------------------------------------------- ------------------------ Date: Thu, 6 Dec 2007 21:02:39 +0100 From: "Teco Boot" < teco@inf-net.nl> Subject: [Autoconf] Supporting commercial ISPs To: < autoconf@ietf.org> Message-ID: <013a01c83843$07d54200$177fc600$@nl > Content-Type: text/plain; charset="us-ascii" I have a somewhat fundamental question on AUTOCONF requirements; do we consider commercial ISPs? I think in real world, we have two environments: private networks and Internet. Private networks could use L2 security and within the network there is no hard requirement for access control. However, even in these private networks access control is getting important. For Internet, ISP provide access to their customers. And probably to their customers only. I wonder how we can support this kind of operation. I appreciate any comment from ISPs, on what they want to be supported. I think the outcome has a large impact on the requirements. Teco. ------------------------------ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf End of Autoconf Digest, Vol 23, Issue 18 **************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www1.ietf.org/pipermail/autoconf/attachments/20071212/08abec50/attach ment.html ------------------------------ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf End of Autoconf Digest, Vol 23, Issue 20 **************************************** ------=_NextPart_000_0025_01C83CD0.E642C9E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Once againJ, comments inline.

I think this mail gets hard to read. I suggest we close = this mail-discussion and take the next step on what to add in PS document. I = think we have enough input now.

 

Teco.

 

Van:<= /b> = Hasnaa Moustafa [mailto:hasnaa.moustafa@gmail.com]
Verzonden: woensdag 12 december 2007 14:30
Aan: teco@inf-net.nl
CC: autoconf@ietf.org
Onderwerp: Re: Autoconf Digest, Vol 23, Issue = 20

 

Hi Teco,

 

Thanks for your reply.

 

Please so my comments below.

 

Regards,

Hassnaa

 

 

Date: Wed, 12 Dec 2007 09:53:21 +0100
From: "Teco Boot" < teco@inf-net.nl>
Subject: RE: [Autoconf] Supporting commercial ISPs
To: "'Hasnaa Moustafa'" <hasnaa.moustafa@gmail.com&g= t;
Cc: autoconf@ietf.org
Message-ID: <000701c83c9c$73b2edd0$5b18c970$@nl>
Content-Type: text/plain; charset=3D"us-ascii"

Hi Hassnaa,



Comments inline.



Van: Hasnaa Moustafa [mailto: hasnaa.moustafa@gmail.com]<= br> Verzonden: dinsdag 11 december 2007 16:38
Aan: teco@inf-net.nl
CC: autoconf@ietf.org
Onderwerp: Re: [Autoconf] Supporting commercial ISPs



Hi Teco,



Thanks for you reply.



There are a number of points that are not so clear for me.



Please see below.



Hassnaa



On 12/10/07, Teco Boot <teco@inf-net.nl> wrote:

Hi Hasnaa,

Thanks for the clear response.
I think we should include some scenarios on extending service coverage = area
of an ISP access network in the PS document. Suggested scenarios:





Hassnaa: I am not so sure if we need a special scenario for this, as = this
type of scenario is a connected one. Then the description of the = connected
scenario in the PS could include such a case (MANET connected to an = ISP
access network).




1)
Full trust between Access Routers and MANET Routers. MANET Links and = Access
Links are protected using L2 security. Border Routers and Access Routers = can

be integrated, i.e. Access Routers may run MANET routing protocol. = Access
Routers may provide prefixes and addresses.



Hassnaa:

How do you differentiate between MANET links and Access links?

-If Access Routers and Border Routers are integrated in one entity (as = you
mentioned), then there is no difference, IMO, between Access links and = MANET
links.

[Teco:]

In this case, there is no access link.

 

Hassnaa: I agree, in this case, all links can be = considered as MANET links.

 

 

- When talking about L2 Security (for instance = 802.1x model), I could not
see how it could take place in a multi-hop MANET environment. So far, = the
existing standard mechanisms function in a WLAN environment (protecting = the
link between a mobile node and an Access point). So saying MANET links = are
protected using L2 security --> implies the existence of a mechanism = that
assures L2 security within the multi-hop environment (which does not = conform
with the reality).

[Teco:]

I am not sure 802.1x cannot be used for MANET links. 802.11i-2004 = describes
how this should work for IBSS.

 

 

Hassnaa: 802.11i is mainly for WLAN, and they = define as an option the authentication using PSK for the ad hoc mode. But this = concerns the peer-to-peer ad hoc communication and does not concern the multi-hop communication. Besides, the PSK proved to be a weak authentication = method.

[Teco:]

We can have long discussions on PSK. =

In my environment, key management other than PSK is not accepted.

I suggest not to discuss this, as it is totally = out-of-scope of Autoconf and our opinions on it does not help us at = all.

 

 

I prefer using pre-shared keys in = MANET.

 

 

Hassnaa: As I mentioned above, PSK proved to be a = weak authentication method (same weakness of the WEP security solutions) = and also has its management burden.

[Teco:]

Oeps. WEP is based on RC4. That is the prime cause of the = weakness. I am not aware of a WPA2-PSK weakness, and maybe there are better = algorithms (for sure more secret).

We are still discussing case 1, where the pre-assumption = is that all nodes have trusted links. Maybe this is not applicable in commercial environments, but in military and probably in public safety I think this = is the current and preferred setup. Things can change here, but don’t = expect anything soon.

 

 

 

Many existing MANET products use local configured = settings, for security and
other. Manual provisioning of MANET Local Addresses is natural in such =
cases. This is why I asked what the added value of Autoconf = is.

 

Hassnaa: Manual provisioning is only practical for = small networks configuration and closed environments, which is not the general = case.

[Teco:]

Agreed, but environments can be quite = large.

 

Also, with nodes' mobility (partitioning and = merging issues, ...), there would be a hard need for dynamic (automatic) address = configuration for easier IP address assignment management.

[Teco:]

For MLA, I doubt.

For Global Addresses, I agree. I expect that only IPsec = traffic between MANET Router and Corresponding Nodes is required and that all = other traffic must be blocked. So MANET Router acts as host in this = case.

 

 

The question here is, what is the added value of = Autoconf? IMHO all nodes
are provisioned before deployment; e.g. security parameters and key
material. Configuring addresses is not that much extra.



Hassnaa:

I did not get, what do you mean by "added value of Autoconf" = --> for me the
added value of autoconf is the "IP address provision for manet routers"
(Maybe I miss something!).

[Teco:]

Yes, but when keys (and other settings) need to be configured before
deployment, why not configuring MLA also?

For global addresses, Autoconf functionality can be useful. =

 

 

Hassnaa: please see my previuos = comment.

 

 

2)
No trust between Access Routers and MANET routers. Border routers = use
protected L2 links to Access Routers. Border Routers are fixed or = mobile.
Access Routers do typically not provide prefixes, they only provide
addresses to attached nodes.



Hassnaa:

If there is no trust between the Access Routers and the MANET routers, = then
this does not conform with a MANET connected to an ISP access network. = For
commercial deployment of MANETs, each manet router is considered as = a
"mobile client", and this "mobile client" could not = be connected to the ISP
access network if he is not legitimate (implying "trust = relationship" with
the Access Routers directly or indirectly. Directly, if the mobile = client is
a subscriber with the ISP that owns the Access routers, while indirectly = if
the mobile client is a subscriber with another ISP that has a trust
relationship with the current ISP.

[Teco:]

In both the  "directly" and "indirectly" = case, each MANET Router that can
access the ISP network is also Border Router, OK?

 

 

Hassnaa: If this MANET Router has a direct link = with the Access Router, then I agree that it is a Border Router. Do you mean = this?

[Teco:] Yes

 

 

In this case, assistance from NEMO functionally and = HA could be used for
providing prefixes to Border Routers. MANET routing protocol may run on = MRHA

tunnel.
The question here is, what is the trust relation between the MANET = Routers?
And also what is the added value of Autoconf in case of configured = security
parameters and key material?



Hassnaa: Same previous comment for the "added value of = Autoconf"!

[Teco:]

I am just asking myself this question on added value of Autoconf.

If access to ISP network is managed on Access Router - Border Router = link,
current global address assignment protocols are used and Autoconf is = not
needed.

 

Hassnaa: I did not get what you mean by = "current global address assignment protocol"!

IMO, Autoconf is required (even in the presence of = ISP) for providing unique IP addresses among the multi-hop nodes and also for = managing IP addresses in case of nodes' leave.

[Teco:]

I think that on the Access Router – Border Router = link, address assignment is already available. So when a direct or indirect = link between MANET Router and Border Router exists, this should = work.

Maybe there is somewhat confusion on direct links – indirect links. I think we came up in both cases the MANET Router is = Border Router, and that in the indirect case there is “roaming = agreement” between the serving ISP (Access Router) and the ISP where the user of = the MANET Router / Border Router is subscribed.

 

 

If there is no preconfigured trust relation between = the MANET Routers, but
MANET Routers want to communicate with each other, MLA is needed. Here =
Autoconf functionality can be useful.

 

Hassnaa: IMO, the two issues (IP autoconf) and = (Trust) should Co-exist in the case of a MANET connected to an ISP access = network.

 

3)
New security mechanism for setting up trust relation between Access = Routers
and MANET Routers. In this case, each MANET Router sets up a secured = link to

one or more Access Routers. I think network operators require some kind = of
hardware authentication (e.g. SIM), or maybe some form of certificates = could
be used. NEMO can be used in this case also.



Hassnaa: I think that this point goes into details concerning the = security
issue (which is not sure to be in the scope of the WG).

[Teco:]

Partly agreed. I think we should not work on security solutions, but I = think
it is important to know what the requirements for real world deployment = are.
If we do not cope with it, the newly defined protocols are dead already. = I
think it is better to circumvent this.

 

Hassnaa: I totally agree that some requirements = (related to real world deployment) should be highlighted.

 

 

One of the ideas in Autoconf is, is providing a = facility for multihop MANET
communication between a MANET Router and the Internet. Our goal is to =
provide a Problem Statement document. If there is a security problem = with
this topology, I do not see a reason why we should not describe = this.
Solving the problem is another thing, it requires rechartering Autoconf = or
something else.





I did not use "new terminology" Internet Configuration = Provider, as I do not
know what this is.
I used Access Router instead of ISP Edge Router, as this is a well known =
name for this entity (RFC3753).

What do you think?



Hassnaa: IMHO, it is interesting to include the case of "a = MANET
connectected to an ISP access network" in the "Connected MANET subsection in
the PS" --> I could eventually provide some text if there is an agreement on
this point.

[Teco:]

This would be great!

 

 

Hassnaa: Then, we need a general agreement on = this.

 

 

 

Teco.



If there is also an agreement on including a requirement section in the = PS
document "the point that was discussed in Vancouver, but not yet concluded"
--> it would be then important to consider some requirements related = to this
case (this would be security requirements, as well as operational
requirements).





Comments and feedbacks are more than welcome.







Any comment from others, familiar with ISP / network operator = requirements?

Teco.

-------------------------------------------------------------------------= ---

------------------------
Van: Hasnaa Moustafa [mailto:hasnaa.moustafa@gmail.com]<= br> Verzonden: vrijdag 7 december 2007 20:11
Aan: teco@inf-net.nl  <mailto= : teco@inf-net.nl>
CC: autoconf@ietf.org
Onderwerp: Re: Autoconf Digest, Vol 23, Issue 18

Hi Teco,

Thanks for raising this interesting issue.

Considering Commercial ISPs is the way for wide scale MANET deployments. = I
believe that IP autoconfiguration is one of the tough issues blocking = the
real MANET deployment by ISPs.

Even if we think ofL2 security (existing in WLAN hotspots deployed by =
ISPs),it is not feasible to apply it in a MANET multi-hop environment, = and
no standard solution existing nowproviding L2 security in multi-hop = MANET
environment.

I agree with your point that ISP should provide IP autoconfiguration for =
their clients or even other legitimate clients (belonging to other ISPs, = for

instance, if there is a trust relationship between different ISPs). = And
there is a number of requirements that can exist in this case.
But the mainquestion (before talking about this issue) concerns the
autoconf WG scope: is the WG looking forIP autoconf solutions
concerningsuch type of scenario --> (MANETs that extends the = service
coverage of an ISPaccess network? And of coarse: this is a connected =
MANET.)

IMHO, this is an important scenario highlighting a concrete MANET
application and having special requirements.

Hassnaa
-------------------------------------------------------------------------= ---
------------------------
Date: Thu, 6 Dec 2007 21:02:39 +0100
From: "Teco Boot" < teco@inf-net.nl>
Subject: [Autoconf] Supporting commercial ISPs
To: < autoconf@ietf.org>
Message-ID: <013a01c83843$07d54200$177fc600$@nl >
Content-Type: text/plain; charset=3D"us-ascii"

I have a somewhat fundamental question on AUTOCONF requirements; do we =
consider commercial ISPs?

I think in real world, we have two environments: private networks = and
Internet.

Private networks could use L2 security and within the network there is = no
hard requirement for access control. However, even in these private = networks

access control is getting important.

For Internet, ISP provide access to their customers. And probably to = their
customers only. I wonder how we can support this kind of operation.

I appreciate any comment from ISPs, on what they want to be supported. I =
think the outcome has a large impact on the requirements.

Teco.

------------------------------

_______________________________________________
Autoconf mailing list
Autoconf@ietf.org
https://www1.iet= f.org/mailman/listinfo/autoconf


End of Autoconf Digest, Vol 23, Issue 18
****************************************






-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www1.ietf.org/pipermail/autoconf/attachments= /20071212/08abec50/attachment.html

------------------------------

_______________________________________________
Autoconf mailing list
Autoconf@ietf.org
https://www1.iet= f.org/mailman/listinfo/autoconf


End of Autoconf Digest, Vol 23, Issue 20
****************************************

 

------=_NextPart_000_0025_01C83CD0.E642C9E0-- --===============1792062804== 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 --===============1792062804==-- From autoconf-bounces@ietf.org Fri Dec 14 02:59:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J35Rv-0006BR-VK; Fri, 14 Dec 2007 02:59:11 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1J35Rt-0005vq-R4 for autoconf-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 02:59:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J35Ro-0005l1-2v for autoconf@ietf.org; Fri, 14 Dec 2007 02:59:04 -0500 Received: from nf-out-0910.google.com ([64.233.182.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J35Rk-0006WE-NP for autoconf@ietf.org; Fri, 14 Dec 2007 02:59:04 -0500 Received: by nf-out-0910.google.com with SMTP id d21so753298nfb.39 for ; Thu, 13 Dec 2007 23:59:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=PBnOiY1OQIIB9L72DiGRShMf1Jaie3L1p+iSHQirAjk=; b=K+qiQg2+F0BM/yTNCZbdztbfSxia0Mv8CnGRh2dkiliD2HouQRiBOhPv4BQXWYD3eS3Gvrfkh/dsczJV7e30U/+QvGNjHLjD6/35lpzls/KdEcVgh9k15B56ysPxM99iIQGWzBJ2PSCo9qUiPIr8Ty7zpFB/RF83/cxlMkp6XMI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=pXnd/n90AhKEqE7iQbutPcT5YogWjw9uPo8o0nD5SgA2fSBBv57BZB7T1LnQaveJWXfq0kFHB6NFzEtgBfJ6TpXRS4ZTn6a8b9q/ow6fddsgcXPh2TNYjGrBpIks/jBd7BUTKS7N3mpFvL+l+yM4KjJunQT8/XAoBwSSZJ+v8mo= Received: by 10.78.204.1 with SMTP id b1mr3391053hug.73.1197619137242; Thu, 13 Dec 2007 23:58:57 -0800 (PST) Received: by 10.78.31.5 with HTTP; Thu, 13 Dec 2007 23:58:56 -0800 (PST) Message-ID: Date: Fri, 14 Dec 2007 08:58:56 +0100 From: "Hasnaa Moustafa" To: "Teco Boot" Subject: Re: [Autoconf] Supporting commercial ISPs In-Reply-To: <002401c83cc8$847e61e0$8d7b25a0$@nl> MIME-Version: 1.0 References: <002401c83cc8$847e61e0$8d7b25a0$@nl> X-Spam-Score: 0.0 (/) X-Scan-Signature: 32be8a281ad9c08293535a48dd468a26 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: , Content-Type: multipart/mixed; boundary="===============1313699889==" Errors-To: autoconf-bounces@ietf.org --===============1313699889== Content-Type: multipart/alternative; boundary="----=_Part_220_9439802.1197619136554" ------=_Part_220_9439802.1197619136554 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, I agree on closing this mail and concluding all these discussions with some concrete points. Then, I could provide some text concerning this issue (case of the MANET connected to the ISP access network) and also some requirements (addition o= n the list that Carlos sent before) related to this case. I could send these to the list for discussion and for checking the possibility of consideratio= n in the PS. I just need an agreement on this (especially from the PS authors), does thi= s sound good? Hassnaa On 12/12/07, Teco Boot wrote: > > Hi, > > > > Once againJ, comments inline. > > I think this mail gets hard to read. I suggest we close this > mail-discussion and take the next step on what to add in PS document. I > think we have enough input now. > > > > Teco. > > > > *Van:* Hasnaa Moustafa [mailto:hasnaa.moustafa@gmail.com] > *Verzonden:* woensdag 12 december 2007 14:30 > *Aan:* teco@inf-net.nl > *CC:* autoconf@ietf.org > *Onderwerp:* Re: Autoconf Digest, Vol 23, Issue 20 > > > > Hi Teco, > > > > Thanks for your reply. > > > > Please so my comments below. > > > > Regards, > > Hassnaa > > > > > > Date: Wed, 12 Dec 2007 09:53:21 +0100 > From: "Teco Boot" < teco@inf-net.nl> > Subject: RE: [Autoconf] Supporting commercial ISPs > To: "'Hasnaa Moustafa'" > Cc: autoconf@ietf.org > Message-ID: <000701c83c9c$73b2edd0$5b18c970$@nl> > Content-Type: text/plain; charset=3D"us-ascii" > > Hi Hassnaa, > > > > Comments inline. > > > > Van: Hasnaa Moustafa [mailto: hasnaa.moustafa@gmail.com] > Verzonden: dinsdag 11 december 2007 16:38 > Aan: teco@inf-net.nl > CC: autoconf@ietf.org > Onderwerp: Re: [Autoconf] Supporting commercial ISPs > > > > Hi Teco, > > > > Thanks for you reply. > > > > There are a number of points that are not so clear for me. > > > > Please see below. > > > > Hassnaa > > > > On 12/10/07, Teco Boot wrote: > > Hi Hasnaa, > > Thanks for the clear response. > I think we should include some scenarios on extending service coverage > area > of an ISP access network in the PS document. Suggested scenarios: > > > > > > Hassnaa: I am not so sure if we need a special scenario for this, as this > type of scenario is a connected one. Then the description of the connecte= d > > scenario in the PS could include such a case (MANET connected to an ISP > access network). > > > > > 1) > Full trust between Access Routers and MANET Routers. MANET Links and > Access > Links are protected using L2 security. Border Routers and Access Routers > can > > be integrated, i.e. Access Routers may run MANET routing protocol. Access > Routers may provide prefixes and addresses. > > > > Hassnaa: > > How do you differentiate between MANET links and Access links? > > -If Access Routers and Border Routers are integrated in one entity (as yo= u > mentioned), then there is no difference, IMO, between Access links and > MANET > links. > > [Teco:] > > In this case, there is no access link. > > > > Hassnaa: I agree, in this case, all links can be considered as MANET > links. > > > > > > - When talking about L2 Security (for instance 802.1x model), I could not > see how it could take place in a multi-hop MANET environment. So far, the > existing standard mechanisms function in a WLAN environment (protecting > the > link between a mobile node and an Access point). So saying MANET links ar= e > protected using L2 security --> implies the existence of a mechanism that > assures L2 security within the multi-hop environment (which does not > conform > with the reality). > > [Teco:] > > I am not sure 802.1x cannot be used for MANET links. 802.11i-2004describe= s > how this should work for IBSS. > > > > > > Hassnaa: 802.11i is mainly for WLAN, and they define as an option the > authentication using PSK for the ad hoc mode. But this concerns the > peer-to-peer ad hoc communication and does not concern the multi-hop > communication. Besides, the PSK proved to be a weak authentication method= . > > *[Teco:] * > > *We can have long discussions on PSK. * > > *In my environment, key management other than PSK is not accepted. * > > *I suggest not to discuss this, as it is totally out-of-scope of Autoconf > and our opinions on it does not help us at all.* > > > > > > I prefer using pre-shared keys in MANET. > > > > > > Hassnaa: As I mentioned above, PSK proved to be a weak authentication > method (same weakness of the WEP security solutions) and also has its > management burden. > > *[Teco:] * > > *Oeps. WEP is based on RC4. That is the prime cause of the weakness. I am > not aware of a WPA2-PSK weakness, and maybe there are better algorithms (= for > sure more secret).* > > *We are still discussing case 1, where the pre-assumption is that all > nodes have trusted links. Maybe this is not applicable in commercial > environments, but in military and probably in public safety I think this = is > the current and preferred setup. Things can change here, but don't expect > anything soon.* > > * * > > > > > > Many existing MANET products use local configured settings, for security > and > other. Manual provisioning of MANET Local Addresses is natural in such > cases. This is why I asked what the added value of Autoconf is. > > > > Hassnaa: Manual provisioning is only practical for small networks > configuration and closed environments, which is not the general case. > > *[Teco:] * > > *Agreed, but environments can be quite large.* > > * * > > Also, with nodes' mobility (partitioning and merging issues, ...), there > would be a hard need for dynamic (automatic) address configuration for > easier IP address assignment management. > > *[Teco:] * > > *For MLA, I doubt.* > > *For Global Addresses, I agree. I expect that only IPsec traffic between > MANET Router and Corresponding Nodes is required and that all other traff= ic > must be blocked. So MANET Router acts as host in this case.* > > > > > > The question here is, what is the added value of Autoconf? IMHO all nodes > are provisioned before deployment; e.g. security parameters and key > material. Configuring addresses is not that much extra. > > > > Hassnaa: > > I did not get, what do you mean by "added value of Autoconf" --> for me > the > added value of autoconf is the "IP address provision for manet routers" > (Maybe I miss something!). > > [Teco:] > > Yes, but when keys (and other settings) need to be configured before > deployment, why not configuring MLA also? > > For global addresses, Autoconf functionality can be useful. > > > > > > Hassnaa: please see my previuos comment. > > > > > > 2) > No trust between Access Routers and MANET routers. Border routers use > protected L2 links to Access Routers. Border Routers are fixed or mobile. > Access Routers do typically not provide prefixes, they only provide > addresses to attached nodes. > > > > Hassnaa: > > If there is no trust between the Access Routers and the MANET routers, > then > this does not conform with a MANET connected to an ISP access network. Fo= r > > commercial deployment of MANETs, each manet router is considered as a > "mobile client", and this "mobile client" could not be connected to the > ISP > access network if he is not legitimate (implying "trust relationship" wit= h > > the Access Routers directly or indirectly. Directly, if the mobile client > is > a subscriber with the ISP that owns the Access routers, while indirectly > if > the mobile client is a subscriber with another ISP that has a trust > relationship with the current ISP. > > [Teco:] > > In both the "directly" and "indirectly" case, each MANET Router that can > access the ISP network is also Border Router, OK? > > > > > > Hassnaa: If this MANET Router has a direct link with the Access Router, > then I agree that it is a Border Router. Do you mean this? > > *[Teco:] Yes* > > > > > > In this case, assistance from NEMO functionally and HA could be used for > providing prefixes to Border Routers. MANET routing protocol may run on > MRHA > > tunnel. > The question here is, what is the trust relation between the MANET > Routers? > And also what is the added value of Autoconf in case of configured > security > parameters and key material? > > > > Hassnaa: Same previous comment for the "added value of Autoconf"! > > [Teco:] > > I am just asking myself this question on added value of Autoconf. > > If access to ISP network is managed on Access Router - Border Router link= , > > current global address assignment protocols are used and Autoconf is not > needed. > > > > Hassnaa: I did not get what you mean by "current global address assignmen= t > protocol"! > > IMO, Autoconf is required (even in the presence of ISP) for providing > unique IP addresses among the multi-hop nodes and also for managing IP > addresses in case of nodes' leave. > > *[Teco:] * > > *I think that on the Access Router =96 Border Router link, address > assignment is already available. So when a direct or indirect link betwee= n > MANET Router and Border Router exists, this should work.* > > *Maybe there is somewhat confusion on direct links =96 indirect links. I > think we came up in both cases the MANET Router is Border Router, and tha= t > in the indirect case there is "roaming agreement" between the serving ISP > (Access Router) and the ISP where the user of the MANET Router / Border > Router is subscribed.* > > > > > > If there is no preconfigured trust relation between the MANET Routers, bu= t > MANET Routers want to communicate with each other, MLA is needed. Here > Autoconf functionality can be useful. > > > > Hassnaa: IMO, the two issues (IP autoconf) and (Trust) should Co-exist in > the case of a MANET connected to an ISP access network. > > > > 3) > New security mechanism for setting up trust relation between Access > Routers > and MANET Routers. In this case, each MANET Router sets up a secured link > to > > one or more Access Routers. I think network operators require some kind o= f > hardware authentication (e.g. SIM), or maybe some form of certificates > could > be used. NEMO can be used in this case also. > > > > Hassnaa: I think that this point goes into details concerning the securit= y > issue (which is not sure to be in the scope of the WG). > > [Teco:] > > Partly agreed. I think we should not work on security solutions, but I > think > it is important to know what the requirements for real world deployment > are. > If we do not cope with it, the newly defined protocols are dead already. = I > think it is better to circumvent this. > > > > Hassnaa: I totally agree that some requirements (related to real world > deployment) should be highlighted. > > > > > > One of the ideas in Autoconf is, is providing a facility for multihop > MANET > communication between a MANET Router and the Internet. Our goal is to > provide a Problem Statement document. If there is a security problem with > this topology, I do not see a reason why we should not describe this. > Solving the problem is another thing, it requires rechartering Autoconf o= r > > something else. > > > > > > I did not use "new terminology" Internet Configuration Provider, as I do > not > know what this is. > I used Access Router instead of ISP Edge Router, as this is a well known > name for this entity (RFC3753). > > What do you think? > > > > Hassnaa: IMHO, it is interesting to include the case of "a MANET > connectected to an ISP access network" in the "Connected MANET subsection > in > the PS" --> I could eventually provide some text if there is an agreement > on > this point. > > [Teco:] > > This would be great! > > > > > > Hassnaa: Then, we need a general agreement on this. > > > > > > > > Teco. > > > > If there is also an agreement on including a requirement section in the P= S > document "the point that was discussed in Vancouver, but not yet > concluded" > --> it would be then important to consider some requirements related to > this > case (this would be security requirements, as well as operational > requirements). > > > > > > Comments and feedbacks are more than welcome. > > > > > > > > Any comment from others, familiar with ISP / network operator > requirements? > > Teco. > > > -------------------------------------------------------------------------= --- > > ------------------------ > Van: Hasnaa Moustafa [mailto:hasnaa.moustafa@gmail.com] > Verzonden: vrijdag 7 december 2007 20:11 > Aan: teco@inf-net.nl > CC: autoconf@ietf.org > Onderwerp: Re: Autoconf Digest, Vol 23, Issue 18 > > Hi Teco, > > Thanks for raising this interesting issue. > > Considering Commercial ISPs is the way for wide scale MANET deployments. = I > believe that IP autoconfiguration is one of the tough issues blocking the > real MANET deployment by ISPs. > > Even if we think ofL2 security (existing in WLAN hotspots deployed by > ISPs),it is not feasible to apply it in a MANET multi-hop environment, an= d > no standard solution existing nowproviding L2 security in multi-hop MANET > environment. > > I agree with your point that ISP should provide IP autoconfiguration for > their clients or even other legitimate clients (belonging to other ISPs, > for > > instance, if there is a trust relationship between different ISPs). And > there is a number of requirements that can exist in this case. > But the mainquestion (before talking about this issue) concerns the > autoconf WG scope: is the WG looking forIP autoconf solutions > concerningsuch type of scenario --> (MANETs that extends the service > coverage of an ISPaccess network? And of coarse: this is a connected > MANET.) > > IMHO, this is an important scenario highlighting a concrete MANET > application and having special requirements. > > Hassnaa > -------------------------------------------------------------------------= --- > > ------------------------ > Date: Thu, 6 Dec 2007 21:02:39 +0100 > From: "Teco Boot" < teco@inf-net.nl> > Subject: [Autoconf] Supporting commercial ISPs > To: < autoconf@ietf.org> > Message-ID: <013a01c83843$07d54200$177fc600$@nl > > Content-Type: text/plain; charset=3D"us-ascii" > > I have a somewhat fundamental question on AUTOCONF requirements; do we > consider commercial ISPs? > > I think in real world, we have two environments: private networks and > Internet. > > Private networks could use L2 security and within the network there is no > hard requirement for access control. However, even in these private > networks > > access control is getting important. > > For Internet, ISP provide access to their customers. And probably to thei= r > customers only. I wonder how we can support this kind of operation. > > I appreciate any comment from ISPs, on what they want to be supported. I > think the outcome has a large impact on the requirements. > > Teco. > > ------------------------------ > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf > > > End of Autoconf Digest, Vol 23, Issue 18 > **************************************** > > > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://www1.ietf.org/pipermail/autoconf/attachments/20071212/08abec5= 0/attachment.html > > > ------------------------------ > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf > > > End of Autoconf Digest, Vol 23, Issue 20 > **************************************** > > > ------=_Part_220_9439802.1197619136554 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi,
I agree on closing this mail and concluding all these discussions with= some concrete points.
Then, I could provide some text concerning this issue (case of th= e MANET connected to the ISP access network) and also some requirements (ad= dition on the list that Carlos sent before) related to this case. I could s= end these to the list for discussion and for checking the possibility of co= nsideration in the PS.
 
I just need an agreement on this (especially from the PS authors), doe= s this sound good?
 
Hassnaa

 
On 12/12/07, Teco Boot <teco@inf-net.nl&g= t; wrote:

Hi,

 

Once againJ, comments inline.

I think this mail gets h= ard to read. I suggest we close this mail-discussion and take the next step= on what to add in PS document. I think we have enough input now.

 

Teco.

 

Van: Hasnaa Moustafa [mailto: hasnaa.moustafa@gmail.com]
Verzonden: woensdag 12 december 2= 007 14:30
Aan: teco@inf-net.nl
CC: autoconf@ietf.org
Onderwerp: Re: Autoconf Digest, Vol 23, Issue 20=

 

Hi Teco,

 

Thanks for your reply.

 

Please so my comments below.

 

Regards,

Hassnaa

 

 

Date: Wed, 12 Dec 2007 09:53:21 +0100
From: "T= eco Boot" < teco@inf-net.nl&= gt;
Subject: RE: [Autoconf] Supporting commercial ISPs
To: "= 'Hasnaa Moustafa'" < hasnaa.moustafa@gmail.com>
Cc: autoconf@ietf.org
Message-ID: <000701c83c9c$73b2edd0$5b18c970$= @nl >
Content-Type: text/plain; charset=3D"us-asci= i"

Hi Hassnaa,


<= br>Comments inline.



Van: Hasnaa Moustafa [mailto: hasnaa.moustafa@gmail.com]
Verzonden: dinsdag 11 december 2007 16:38=
Aan: teco@inf-net.nl
CC: autoconf@ietf.org
Onderwerp: Re: [Autoconf] Supporting commercial IS= Ps



Hi Teco,



Thanks for you reply.


=
There are a number of points that are not so clear for me.



Please see below.



Hassnaa



On 12/10/07, Te= co Boot <teco@inf-net.nl> wrot= e:

Hi Hasnaa,

Thanks for the clear response.
I think we shou= ld include some scenarios on extending service coverage area
of an ISP = access network in the PS document. Suggested scenarios:





Hassnaa: I am not so sure if we need a special scenario for this, a= s this
type of scenario is a connected one. Then the description of the = connected
scenario in the PS could include such a case (MANET connected= to an ISP
access network).




1)
Full trust between Access Rou= ters and MANET Routers. MANET Links and Access
Links are protected using= L2 security. Border Routers and Access Routers can

be integrated,= =20 i.e. Access Routers may run MANET routing protocol. Access
Routers may p= rovide prefixes and addresses.



Hassnaa:

How do you di= fferentiate between MANET links and Access links?

-If Access Router= s and Border Routers are integrated in one entity (as you
mentioned), then there is no difference, IMO, between Access links and = MANET
links.

[Teco:]

In this case, there is no access link= .

 

Hassnaa: I agree, in this case, all links can be considered as MANET lin= ks.

 

 

- When talking about L2 Security (for instance 802.1x model), I could no= t
see how it could take place in a multi-hop MANET environment. So far, = the
existing standard mechanisms function in a WLAN environment (protec= ting the
link between a mobile node and an Access point). So saying MANET links = are
protected using L2 security --> implies the existence of a mechan= ism that
assures L2 security within the multi-hop environment (which do= es not conform
with the reality).

[Teco:]

I am not sure 802.1x cannot be= used for MANET links. 802.11i-2004 describes
how this should work for I= BSS.

 

 

Hassnaa: 802.11i is mainly for WLAN, and they define as an option the au= thentication using PSK for the ad hoc mode. But this concerns the peer-to-p= eer ad hoc communication and does not concern the multi-hop communication. = Besides, the PSK proved to be a weak authentication method.=20

[Teco:]

We can have long d= iscussions on PSK.

In my environment,= key management other than PSK is not accepted.

I suggest not to d= iscuss this, as it is totally out-of-scope of Autoconf and our opinions on = it does not help us at all.

 

<= span class=3D"q">

 

I prefer using pre-shared keys in MANET.

 

 

Hassnaa: As I mentioned above, PSK proved to be a weak authentication me= thod (same weakness of the WEP security solutions) and also has its ma= nagement burden.

[Teco:]

Oeps. WEP is based= on RC4. That is the prime cause of the weakness. I am not aware of a WPA2-= PSK weakness, and maybe there are better algorithms (for sure more secret).

We are still discu= ssing case 1, where the pre-assumption is that all nodes have trusted links= . Maybe this is not applicable in commercial environments, but in military = and probably in public safety I think this is the current and preferred set= up. Things can change here, but don't expect anything soon.

 <= /b>

 

 

Many existing MANET products use local configured settings, for security= and
other. Manual provisioning of MANET Local Addresses is natural in s= uch
cases. This is why I asked what the added value of Autoconf is.

 

Hassnaa: Manual provisioning is only practical for small networks config= uration and closed environments, which is not the general case.

[Teco:]

Agreed, but enviro= nments can be quite large.

 <= /b>

Also, with nodes' mobility (partitioning and merging issues, ...), t= here would be a hard need for dynamic (automatic) address configuration for= easier IP address assignment management.

[Teco:]

For MLA, I doubt.<= /span>

For Global Address= es, I agree. I expect that only IPsec traffic between MANET Router and Corr= esponding Nodes is required and that all other traffic must be blocked. So = MANET Router acts as host in this case.

<= /div>

 

 

The question here is, what is the added value of Autoconf? IMHO all node= s
are provisioned before deployment; e.g. security parameters and keymaterial. Configuring addresses is not that much extra.



Hassnaa:

I did not get, what do you mean by "added value of Aut= oconf" --> for me the
added value of autoconf is the "IP ad= dress provision for manet routers"
(Maybe I miss something!).

[Teco:]

Yes, but when keys (and other settings) need to be confi= gured before
deployment, why not configuring MLA also?

For global= addresses, Autoconf functionality can be useful.

 

 

Hassnaa: please see my previuos comment.

 

 

2)
No trust between Access Routers and MANET routers. Border routers = use
protected L2 links to Access Routers. Border Routers are fixed or mo= bile.
Access Routers do typically not provide prefixes, they only provi= de
addresses to attached nodes.



Hassnaa:

If there is= no trust between the Access Routers and the MANET routers, then
this do= es not conform with a MANET connected to an ISP access network. For
commercial deployment of MANETs, each manet router is considered as a
&q= uot;mobile client", and this "mobile client" could not be co= nnected to the ISP
access network if he is not legitimate (implying &quo= t;trust relationship" with=20
the Access Routers directly or indirectly. Directly, if the mobile clie= nt is
a subscriber with the ISP that owns the Access routers, while indi= rectly if
the mobile client is a subscriber with another ISP that has a = trust=20
relationship with the current ISP.

[Teco:]

In both the&nb= sp; "directly" and "indirectly" case, each MANET R= outer that can
access the ISP network is also Border Router, OK?

 

 

Hassnaa: If this MANET Router has a direct link with the Access Router, = then I agree that it is a Border Router. Do you mean this?

[Teco:] Yes=

 

 

In this case, assistance from NEMO functionally and HA could be used for=
providing prefixes to Border Routers. MANET routing protocol may run on= MRHA

tunnel.
The question here is, what is the trust relation b= etween the MANET Routers?
And also what is the added value of Autoconf in case of configured secu= rity
parameters and key material?



Hassnaa: Same previous = comment for the "added value of Autoconf"!

[Teco:]

I am just asking myself this question on added value of Autoconf.
If access to ISP network is managed on Access Router - Border Router link= ,
current global address assignment protocols are used and Autoconf is = not
needed.

 

Hassnaa: I did not get what you mean by "current global addres= s assignment protocol"!

IMO, Autoconf is required (even in the presence of ISP) for providing un= ique IP addresses among the multi-hop nodes and also for managing IP addres= ses in case of nodes' leave.

[Teco:]

I think that on th= e Access Router =96 Border Router link, address assignment is already avail= able. So when a direct or indirect link between MANET Router and Border Rou= ter exists, this should work.

Maybe there is som= ewhat confusion on direct links =96 indirect links. I think we came up in b= oth cases the MANET Router is Border Router, and that in the indirect case = there is "roaming agreement" between the serving ISP (Access Router) and th= e ISP where the user of the MANET Router / Border Router is subscribed.

 

<= span class=3D"q">

 

If there is no preconfigured trust relation between the MANET Routers, b= ut
MANET Routers want to communicate with each other, MLA is needed. Her= e
Autoconf functionality can be useful.

 

Hassnaa: IMO, the two issues (IP autoconf) and (Trust) should Co-ex= ist in the case of a MANET connected to an ISP access network.

 

3)
New security mechanism for setting up trust relation between Acces= s Routers
and MANET Routers. In this case, each MANET Router sets up a s= ecured link to

one or more Access Routers. I think network operator= s require some kind of
hardware authentication (e.g. SIM), or maybe some form of certificates = could
be used. NEMO can be used in this case also.



Hassna= a: I think that this point goes into details concerning the security
issue (which is not sure to be in the scope of the WG).

[Teco:]
<= br>Partly agreed. I think we should not work on security solutions, but I t= hink
it is important to know what the requirements for real world deplo= yment are.
If we do not cope with it, the newly defined protocols are dead already= . I
think it is better to circumvent this.

 

Hassnaa: I totally agree that some requirements (related to real world d= eployment) should be highlighted.

 

 

One of the ideas in Autoconf is, is providing a facility for multihop MA= NET
communication between a MANET Router and the Internet. Our goal is t= o
provide a Problem Statement document. If there is a security problem = with
this topology, I do not see a reason why we should not describe this.Solving the problem is another thing, it requires rechartering Autoconf o= r
something else.





I did not use "new termin= ology" Internet Configuration Provider, as I do not
know what this is.
I used Access Router instead of ISP Edge Router, = as this is a well known
name for this entity (RFC3753).

What do = you think?



Hassnaa: IMHO, it is interesting to include the c= ase of "a MANET
connectected to an ISP access network" in the "Connected MANE= T subsection in
the PS" --> I could eventually provide some tex= t if there is an agreement on
this point.

[Teco:]

This wou= ld be great!

 

 

Hassnaa: Then, we need a general agreement on this.

 

 

 

Teco.



If there is also an agreement on = including a requirement section in the PS
document "the point that = was discussed in Vancouver, but not yet concluded"
--> it would= be then important to consider some requirements related to this
case (this would be security requirements, as well as operational
re= quirements).





Comments and feedbacks are more than we= lcome.







Any comment from others, familiar wi= th ISP / network operator requirements?

Teco.

------------------------------------------------------= ----------------------

------------------------
Van: Hasnaa Mous= tafa [mailto: hasnaa.moustafa@gmail.com]
Verzonden: vrijdag 7 december 2007 20:11<= br>Aan: teco@inf-net.nl =  <mailto:=20 teco@inf-net.nl>=20


CC: autoconf@ietf.org
Onderwerp: Re: Autoconf Dige= st, Vol 23, Issue 18

Hi Teco,

Thanks for raising this interesting issue.

= Considering Commercial ISPs is the way for wide scale MANET deployments. I<= br>believe that IP autoconfiguration is one of the tough issues blocking th= e
real MANET deployment by ISPs.

Even if we think ofL2 security (e= xisting in WLAN hotspots deployed by
ISPs),it is not feasible to apply = it in a MANET multi-hop environment, and
no standard solution existing n= owproviding L2 security in multi-hop MANET
environment.

I agree with your point that ISP should provide IP = autoconfiguration for
their clients or even other legitimate clients (b= elonging to other ISPs, for

instance, if there is a trust relationsh= ip between different ISPs). And
there is a number of requirements that can exist in this case.
But = the mainquestion (before talking about this issue) concerns the
autoconf= WG scope: is the WG looking forIP autoconf solutions
concerningsuch typ= e of scenario --> (MANETs that extends the service
coverage of an ISPaccess network? And of coarse: this is a connected MANET.)

IMHO, this is an important scenario highlighting a concret= e MANET
application and having special requirements.

Hassnaa
---------------------------------------------------------------------------= -
------------------------
Date: Thu, 6 Dec 2007 21:02:39 +0100
F= rom: "Teco Boot" < teco@inf-net.nl>
Subject: [Autoconf] Supporting commercial ISPsTo: < autoconf@ietf.org> Message-ID: <013a01c83843$07d54200$177fc600$@nl >
Content-Type: te= xt/plain; charset=3D"us-ascii"

I have a somewhat fundament= al question on AUTOCONF requirements; do we
consider commercial ISPs?

I think in real world, we have two environments: private networks a= nd
Internet.

Private networks could use L2 security and within th= e network there is no
hard requirement for access control. However, even= in these private networks=20

access control is getting important.

For Internet, ISP provi= de access to their customers. And probably to their
customers only. I wo= nder how we can support this kind of operation.

I appreciate any com= ment from ISPs, on what they want to be supported. I=20
think the outcome has a large impact on the requirements.

Teco.<= br>
------------------------------

______________________________= _________________
Autoconf mailing list
Autoconf@ietf.org
https://www1.ietf.org/mailman/listinfo/autoconf


= End of Autoconf Digest, Vol 23, Issue 18
****************************************






-------------- next part --------------
An HTML attachment wa= s scrubbed...
URL: http://www1.ietf.org/pipermail/autoconf/attachments/20071212/08abec50/attac= hment.html

------------------------------
=
_______________________________________________
Autoconf mailing lis= t
Autoconf@ietf.org
https://www1.ietf.org/mailman/listinfo/autoconf


End o= f Autoconf Digest, Vol 23, Issue 20
************************************= ****=20

 


------=_Part_220_9439802.1197619136554-- --===============1313699889== 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 --===============1313699889==--