From rdroms.ietf@gmail.com Tue Feb 1 18:26:04 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA3B23A7125 for ; Tue, 1 Feb 2011 18:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.487 X-Spam-Level: X-Spam-Status: No, score=-103.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFfbr5i7pu9X for ; Tue, 1 Feb 2011 18:26:03 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id C54E43A7121 for ; Tue, 1 Feb 2011 18:26:03 -0800 (PST) Received: by qwi2 with SMTP id 2so7866786qwi.31 for ; Tue, 01 Feb 2011 18:29:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:cc:to:mime-version:x-mailer; bh=EtwzQIhv1R7Po4eRv07H+aTr7bFQsLGQft5ulRWDFFM=; b=ZxShhqGX4+sOjgdkdNSP55gfHqInaubRW38tY3DA8lc7hwEEPyEFLvyk94NwXkA2vP d1eB/2lBfYREKTeMHCE/OL8L8ItEtVormRxym68GrpXSqxoam8NCfpSKsN3S9hF4YjMh Xsx+8reAs12J7suhfvNsbycVKwvlHQ/nk03rk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; b=Z4SVk4FYFqrWvfYtrANEeAikuEAqLggvQcfaSqUu3hawJTdKgwMfEDGLBP7pxjCGO5 S3WT0bC17MUzIIFC6e2INWf0IgFNCk4g+T68QLUoL6l4yugAEJppYtoZgo64XXkZUOQn 4B9somZ7ynraCxDli89/MZYlqlMgrHnCIdiok= Received: by 10.229.250.11 with SMTP id mm11mr7685165qcb.91.1296613761996; Tue, 01 Feb 2011 18:29:21 -0800 (PST) Received: from bxb-rdroms-87113.cisco.com (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id y17sm16175236qci.45.2011.02.01.18.29.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 01 Feb 2011 18:29:21 -0800 (PST) From: Ralph Droms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Feb 2011 21:29:20 -0500 Message-Id: <9B1BB59C-E0A2-4A04-8F97-199EA675CB58@gmail.com> To: Area Internet Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Cc: int-ads@tools.ietf.org Subject: [Int-area] intarea WG leadership X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 02:26:04 -0000 Jari and I have an announcement about leadership of the intarea WG. = Christian Vogt has told us that his day job responsibilities have = changed and he has stepped down as intarea WG co-chair. We greatly = appreciate Christian's efforts as intarea WG co-chair and will miss his = leadership. Now we need to find a replacement for Christian. If you're interested = in co-chairing the intarea WG, or have a suggestion for someone who you = think would be good in that role, please let us know. We hope to = replace Christian soon in anticipation of the upcoming IETF meeting. - Jari and Ralph From jari.arkko@piuha.net Tue Feb 1 18:48:46 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A0B83A6BB6 for ; Tue, 1 Feb 2011 18:48:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.595 X-Spam-Level: X-Spam-Status: No, score=-101.595 tagged_above=-999 required=5 tests=[AWL=-0.893, BAYES_00=-2.599, DATE_IN_FUTURE_06_12=1.897, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jr-Ug1+dANjL for ; Tue, 1 Feb 2011 18:48:46 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id B141A3A6BB9 for ; Tue, 1 Feb 2011 18:48:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id BC9642CC3C; Wed, 2 Feb 2011 04:52:00 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mu-CdlqAZ5k0; Wed, 2 Feb 2011 04:52:00 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id DE6ED2CC2D; Wed, 2 Feb 2011 04:51:58 +0200 (EET) Message-ID: <4D495382.60405@piuha.net> Date: Wed, 02 Feb 2011 04:52:18 -0800 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Area Internet References: <9B1BB59C-E0A2-4A04-8F97-199EA675CB58@gmail.com> In-Reply-To: <9B1BB59C-E0A2-4A04-8F97-199EA675CB58@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ron Bonica Subject: Re: [Int-area] intarea WG leadership X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 02:48:46 -0000 I should also mention that we are currently looking for chairs for the LWIG working group (to be created), ARMD working group (ongoing discussions and I think this will be created before the next IETF), and we may also need help with the RENUM BOF (to be held). Again, please talk to the ADs if you have an interest in leading these groups or have someone else in mind who would be good. I'm Ccing Ron as some of these groups may be under his area in the end. Note that we are also interested in training new people to become working group chairs, so while IETF experience is required, experience in being a chair is not always required. Jari From jari.arkko@piuha.net Fri Feb 4 12:36:15 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A57A3A69D3 for ; Fri, 4 Feb 2011 12:36:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvVwEnV+TgIj for ; Fri, 4 Feb 2011 12:36:14 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 4A4C43A69A9 for ; Fri, 4 Feb 2011 12:36:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 1CEEB2CC31; Fri, 4 Feb 2011 22:39:34 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8HR3Dy4byNW; Fri, 4 Feb 2011 22:39:33 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 99EEF2CC2D; Fri, 4 Feb 2011 22:39:33 +0200 (EET) Message-ID: <4D4C6404.4060603@piuha.net> Date: Fri, 04 Feb 2011 22:39:32 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Area Internet References: <9B1BB59C-E0A2-4A04-8F97-199EA675CB58@gmail.com> <4D495382.60405@piuha.net> In-Reply-To: <4D495382.60405@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ralph Droms Subject: Re: [Int-area] intarea WG leadership X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 20:36:15 -0000 And we are now also looking for a new chair in the SOFTWIRE working group. This is a good time to volunteer for these tasks because we have so many new positions and changes. Thanks for everyone who has already volunteered! Jari From mohamed.boucadair@orange-ftgroup.com Mon Feb 7 06:15:48 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6F803A6909 for ; Mon, 7 Feb 2011 06:15:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqxXGQFBIHbd for ; Mon, 7 Feb 2011 06:15:48 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by core3.amsl.com (Postfix) with ESMTP id AA7BC3A68F7 for ; Mon, 7 Feb 2011 06:15:47 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id DCD4019027C; Mon, 7 Feb 2011 15:15:50 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id C416738403A; Mon, 7 Feb 2011 15:15:50 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Mon, 7 Feb 2011 15:15:51 +0100 From: To: "Laganier, Julien" , "int-area@ietf.org" Date: Mon, 7 Feb 2011 15:15:49 +0100 Thread-Topic: [Int-area] I-D Action:draft-ietf-intarea-server-logging-recommendations-02.txt Thread-Index: AQHLuAeRr9aobd9Hqki8e/J8n8tjzpPlI7JAgBCZMjA= Message-ID: <31963_1297088150_4D4FFE96_31963_99436_1_94C682931C08B048B7A8645303FDC9F33C44015A86@PUEXCB1B.nanterre.francetelecom.fr> References: <20110119183002.30410.51185.idtracker@localhost> <98A16B2D00B5724F81E80EF1927A029703FC95@nasanexd01e.na.qualcomm.com> In-Reply-To: <98A16B2D00B5724F81E80EF1927A029703FC95@nasanexd01e.na.qualcomm.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.2.7.134520 Cc: "draft-ietf-intarea-server-logging-recommendations@tools.ietf.org" , "christian.vogt@ericsson.com" Subject: Re: [Int-area] I-D Action:draft-ietf-intarea-server-logging-recommendations-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 14:15:48 -0000 Dear authors, all, I read this I-D and have the following comments: * In its current state, this I-D does not add more content compared to what= is stated in http://tools.ietf.org/html/draft-ietf-intarea-shared-addressi= ng-issues-02#section-12. I understand this document aims to make a recommen= dation but IMHO it would be useful if the I-D discusses other aspects which= are not covered so far such as the behaviour of the server when some heade= rs such XFF are used. Storing the content of such headers would be useful i= n some scenarios (the port binding is not logged in the address sharing sid= e) which prefer to expose an identifier to the destination server instead o= f maintaining a binding.=20 * The I-D should mention that perceived IP address and source may not be su= fficient to find the identity of the user; in particular when anonymization= capabilities (e.g., infrastructures with onion routing or proxies, etc.) a= re used. * Section 3 is out of scope and should be removed. Cheers, Med -----Message d'origine----- De : int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] De la par= t de Laganier, Julien Envoy=E9 : jeudi 27 janvier 2011 18:52 =C0 : int-area@ietf.org Cc : draft-ietf-intarea-server-logging-recommendations@tools.ietf.org; chri= stian.vogt@ericsson.com Objet : Re: [Int-area] I-D Action:draft-ietf-intarea-server-logging-recomme= ndations-02.txt Folks, We believe that the authors of draft-ietf-intarea-server-logging-recommenda= tions have addressed comments that were made at the last IETF meeting and o= n the mailing list thereafter: Title : Logging recommendations for Internet facing servers Author(s) : A. Durand, et al. Filename : draft-ietf-intarea-server-logging-recommendations-02.txt Pages : 6 Date : 2011-01-19 URL : http://tools.ietf.org/html/draft-ietf-intarea-server-log= ging-recommendations-02 This note initiate a two weeks Working Group Last Call. Please review the d= ocument and send your comments to the list and state whether or not you thi= nk this document is ready to be forwarded to IESG. The Working Group Last C= all closes on 2010-02-10 COB PST. Thank you for your support. --julien & christian _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From jari.arkko@piuha.net Wed Feb 9 04:48:54 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 256BD3A69B8 for ; Wed, 9 Feb 2011 04:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.404 X-Spam-Level: X-Spam-Status: No, score=-102.404 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2Lp-be0SyDG for ; Wed, 9 Feb 2011 04:48:53 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 939DD3A69B3 for ; Wed, 9 Feb 2011 04:48:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2F8232CC34; Wed, 9 Feb 2011 14:49:01 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EI7nS9MJxyR7; Wed, 9 Feb 2011 14:49:00 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 751B42CC2D; Wed, 9 Feb 2011 14:49:00 +0200 (EET) Message-ID: <4D528D3C.3000606@piuha.net> Date: Wed, 09 Feb 2011 13:49:00 +0100 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: draft-zhu-mobility-survey@tools.ietf.org, Lixia Zhang , Internet Area Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Int-area] AD review of draft-zhu-mobility-survey X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 12:48:54 -0000 I was asked to AD sponsor this draft to an RFC. Sorry for the extremely long time this has taken to get to my review. But I have now reviewed it. Abstract from draft-zhu-mobility-survey: Over the last two decades many efforts have been devoted to developing solutions for mobility support over the global Internet, which resulted in a variety of proposed solutions. In this draft we conducted a systematic survey of the previous efforts to gain an overall understanding on the solution space of mobility support. This draft reports our finding and identifies remaining issues in providing ubiquitous and efficient global scale mobility support. The document is well written and a pleasure to read. It is a relevant overview of the mobility protocol design space, and its analysis is useful for thinking about the deployment issues that we've seen in this space. As far as I can tell, the document includes most of the relevant work (some exceptions noted below), and I have no major technical comments. I have sent the draft forward to IETF Last Call, and hope that you can work on the remaining issues during the last call, and get more suggestions and additional material from the last call reviewers. Technical: > 4.12. IKEv2 Mobility and Multihoming Protocol (MOBIKE) > > > MOBIKE is an extension to Internet Key Exchange (IKEv2) to support > mobility and multihoming. The main purpose of MOBIKE is to allow > roaming devices to keep the existing IKE and IPsec SAs despite of IP > address changes. The mobility support in MOBIKE allows both parties > to move, but it does not provide a rendezvous mechanism. In other > words, simultaneous movement of both parties is not supported. Hmm. While this is true, part of the simultaneous mobility support is always in a stable anchor point, even in Mobile IP. If you assume mobike device 1 = host and mobike device 2 = gateway, then the situation really is equivalent to mobile IP mobile node - home agent arrangement. Home agent stays put, but mobiles can move around and everything still works. Also, I think it would be useful to state something about multihoming support in some of these protocols. Some do support this, for instance Mobike and more recently, also Mobile IP. A feature matrix for the different protocols is not so interesting, but it would be useful to understand what scope the different protocols have. > The reachability > information of the user's machine is published in DNS, and only > accessible to the subscriber. > "published in DNS" and "only accessible to the subscriber" do not appear to be compatible statements. Can you expand on this a bit? > BTMM has millions of subscribers, which is perhaps the first large- > scale commercial host mobility support in Internet as of today. I wonder if the use of Mobile IP in CDMA/3GPP2 networks exceeds this. Please check. Also, since you are missing GTP which is essentially a non-IETF variant of PMIP, you should probably include GTP and note that that network-based mobility support is extremely widely used (to the order of a billion data users). > The second approach to mobility support is to provide a mapping > between a mobile's stable identifier and its dynamically changing IP > address. Instead of notifying the world on every movement, a mobile > only needs to update a single binding location about its location > changes. In this approach, if one level of indirection at IP layer > is used, as in the case of Mobile IP, it has a potential side effect > of introducing triangle routing; otherwise, if the two end nodes are > aware of each other's movement, it means that both ends have to > support the same mobility protocol. > > Yet there is the third case in which the protocols combine the above > approaches, in the hope of keeping the pros and eliminating some cons > of the two. WINMO is a typically protocol in this case. > This is a very nice classification. But I have a question. How would you classify designs that include support for route optimization, such as Mobile IP? They do not impact routers, but still there's a need to update more than a single entity about a new location? Also, in Section 5.2 you talk about mobility aware entities, but this does not take into account whether the CNs are aware in route optimization mode. Missing: It might be valuable to describe the limited mobility support in transport layer solutions (SCTP and MP-TCP) as well. That is, they allow a single connection to stay up even as you move around, but do not by themselves allow simultaneous mobility of both parties. What about SHIM6? I would talk about GTP (a network-based mobility protocol) as well. What about mentioning application layer mobility designs (e.g., start from the paper by Henning on SIP mobility)? It might be useful to have at least some pointers to various optimization efforts that the community has spent quite a lot of time on. It felt that FMIP was the only one that was mentioned in addition to the general idea of route optimization in Mobile IP. Look for pointers from the MIPSHOP WG's page, RFC 4651, etc. Editorial: > Xing, W., Karl, H., and A. Wolisz, "M-SCTP: Design and > Prototypical Implementaion of An End-to-End Mobility > Concept" Typo > LISP-Mobility [LISP-Mobility ] is a relatively new design, in which > the designer hopes to utilize LISP[LISP], which is designed for > routing scalability, to support mobility as well. This sentence could probably be simplified a bit. Jari From Fred.L.Templin@boeing.com Wed Feb 9 05:01:57 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 971A33A69C5 for ; Wed, 9 Feb 2011 05:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.236 X-Spam-Level: X-Spam-Status: No, score=-6.236 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uM5eEmqpVtWc for ; Wed, 9 Feb 2011 05:01:56 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 29A9B3A69B3 for ; Wed, 9 Feb 2011 05:01:56 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p19D1pWX005564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 Feb 2011 07:01:52 -0600 (CST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p19D1pME026345; Wed, 9 Feb 2011 07:01:51 -0600 (CST) Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p19D1pak026336 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 9 Feb 2011 07:01:51 -0600 (CST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Wed, 9 Feb 2011 05:01:50 -0800 From: "Templin, Fred L" To: Jari Arkko , "draft-zhu-mobility-survey@tools.ietf.org" , Lixia Zhang , Internet Area Date: Wed, 9 Feb 2011 05:01:49 -0800 Thread-Topic: [Int-area] AD review of draft-zhu-mobility-survey Thread-Index: AcvIV8+F3lE+XSHQTGG9uhsLm+1G6QAAKX7w Message-ID: References: <4D528D3C.3000606@piuha.net> In-Reply-To: <4D528D3C.3000606@piuha.net> 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 Subject: Re: [Int-area] AD review of draft-zhu-mobility-survey X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 13:01:57 -0000 Jari, With apologies that this is the first time I am seeing this document, I have to say that the survey is incomplete without an analysis of the mobility management scheme that is in-built within the IRON architecture: http://www.rfc-editor.org/internet-drafts/draft-templin-iron-17.txt=20 Please have a look at IRON and consider adding it to the analysis. Let me know if there are any questions, and if there is any help needed with adding text. Thanks - Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: int-area-bounces@ietf.org=20 > [mailto:int-area-bounces@ietf.org] On Behalf Of Jari Arkko > Sent: Wednesday, February 09, 2011 4:49 AM > To: draft-zhu-mobility-survey@tools.ietf.org; Lixia Zhang;=20 > Internet Area > Subject: [Int-area] AD review of draft-zhu-mobility-survey >=20 > I was asked to AD sponsor this draft to an RFC. Sorry for the=20 > extremely=20 > long time this has taken to get to my review. But I have now=20 > reviewed it. >=20 > Abstract from draft-zhu-mobility-survey: >=20 > Over the last two decades many efforts have been devoted to > developing solutions for mobility support over the global Internet, > which resulted in a variety of proposed solutions. In=20 > this draft we > conducted a systematic survey of the previous efforts to gain an > overall understanding on the solution space of mobility support. > This draft reports our finding and identifies remaining issues in > providing ubiquitous and efficient global scale mobility support. >=20 > The document is well written and a pleasure to read. It is a relevant=20 > overview of the mobility protocol design space, and its analysis is=20 > useful for thinking about the deployment issues that we've=20 > seen in this=20 > space. As far as I can tell, the document includes most of=20 > the relevant=20 > work (some exceptions noted below), and I have no major technical=20 > comments. I have sent the draft forward to IETF Last Call,=20 > and hope that=20 > you can work on the remaining issues during the last call,=20 > and get more=20 > suggestions and additional material from the last call reviewers. >=20 > Technical: >=20 > > 4.12. IKEv2 Mobility and Multihoming Protocol (MOBIKE) > > > > > > MOBIKE is an extension to Internet Key Exchange (IKEv2)=20 > to support > > mobility and multihoming. The main purpose of MOBIKE is to allow > > roaming devices to keep the existing IKE and IPsec SAs=20 > despite of IP > > address changes. The mobility support in MOBIKE allows=20 > both parties > > to move, but it does not provide a rendezvous mechanism.=20 > In other > > words, simultaneous movement of both parties is not supported. >=20 > Hmm. While this is true, part of the simultaneous mobility support is=20 > always in a stable anchor point, even in Mobile IP. If you=20 > assume mobike=20 > device 1 =3D host and mobike device 2 =3D gateway, then the=20 > situation really=20 > is equivalent to mobile IP mobile node - home agent arrangement. Home=20 > agent stays put, but mobiles can move around and everything=20 > still works. >=20 > Also, I think it would be useful to state something about multihoming=20 > support in some of these protocols. Some do support this, for=20 > instance=20 > Mobike and more recently, also Mobile IP. A feature matrix for the=20 > different protocols is not so interesting, but it would be useful to=20 > understand what scope the different protocols have. >=20 > > The reachability > > information of the user's machine is published in DNS, and only > > accessible to the subscriber. > > =20 >=20 > "published in DNS" and "only accessible to the subscriber" do=20 > not appear=20 > to be compatible statements. Can you expand on this a bit? >=20 > > BTMM has millions of subscribers, which is perhaps the=20 > first large- > > scale commercial host mobility support in Internet as of today. >=20 > I wonder if the use of Mobile IP in CDMA/3GPP2 networks exceeds this.=20 > Please check. Also, since you are missing GTP which is essentially a=20 > non-IETF variant of PMIP, you should probably include GTP and=20 > note that=20 > that network-based mobility support is extremely widely used (to the=20 > order of a billion data users). >=20 > > The second approach to mobility support is to provide a mapping > > between a mobile's stable identifier and its dynamically changing IP > > address. Instead of notifying the world on every movement, a mobile > > only needs to update a single binding location about its location > > changes. In this approach, if one level of indirection at IP layer > > is used, as in the case of Mobile IP, it has a potential side effect > > of introducing triangle routing; otherwise, if the two end nodes are > > aware of each other's movement, it means that both ends have to > > support the same mobility protocol. > > > > Yet there is the third case in which the protocols combine the above > > approaches, in the hope of keeping the pros and eliminating=20 > some cons > > of the two. WINMO is a typically protocol in this case. > > =20 >=20 > This is a very nice classification. But I have a question.=20 > How would you=20 > classify designs that include support for route optimization, such as=20 > Mobile IP? They do not impact routers, but still there's a need to=20 > update more than a single entity about a new location? Also,=20 > in Section=20 > 5.2 you talk about mobility aware entities, but this does not=20 > take into=20 > account whether the CNs are aware in route optimization mode. >=20 > Missing: >=20 > It might be valuable to describe the limited mobility support in=20 > transport layer solutions (SCTP and MP-TCP) as well. That is,=20 > they allow=20 > a single connection to stay up even as you move around, but do not by=20 > themselves allow simultaneous mobility of both parties. What=20 > about SHIM6? >=20 > I would talk about GTP (a network-based mobility protocol) as well. >=20 > What about mentioning application layer mobility designs (e.g., start=20 > from the paper by Henning on SIP mobility)? >=20 > It might be useful to have at least some pointers to various=20 > optimization efforts that the community has spent quite a lot of time=20 > on. It felt that FMIP was the only one that was mentioned in=20 > addition to=20 > the general idea of route optimization in Mobile IP. Look=20 > for pointers=20 > from the MIPSHOP WG's page, RFC 4651, etc. >=20 > Editorial: >=20 > > Xing, W., Karl, H., and A. Wolisz, "M-SCTP: Design and > > Prototypical Implementaion of An End-to-End Mobility > > Concept" > Typo >=20 > > LISP-Mobility [LISP-Mobility=20 > ISP-Mobility>] is a relatively new design, in which > > the designer hopes to utilize LISP[LISP], which is designed for > > routing scalability, to support mobility as well.=20 >=20 > This sentence could probably be simplified a bit. >=20 > Jari >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > = From ryuji.wakikawa@gmail.com Thu Feb 10 01:17:53 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1756E3A689C for ; Thu, 10 Feb 2011 01:17:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.284 X-Spam-Level: X-Spam-Status: No, score=-103.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHDOP9dBV0zY for ; Thu, 10 Feb 2011 01:17:52 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id C44033A69F5 for ; Thu, 10 Feb 2011 01:17:51 -0800 (PST) Received: by iwc10 with SMTP id 10so1141006iwc.31 for ; Thu, 10 Feb 2011 01:18:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=dp8vmDZJ75q4WehnK8xA1Kqa0n3DUoMcsrcXUBi2AwQ=; b=vAV7zY6HrelADfjYo3NowdqTruSOXP9IoWb0tYt5EQJ4/LKXZ/+3aDb646QsWbRU1M kyOCv3m2gpW8pj0GlbaRi8gtlSETJJHTkxJOeOcZv05fpRitAfyvyzrbfK4DuOOvjXq3 cuQ/nMdimYQyzJ3FUVBWEGZUEDZQsCDLgxTig= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=nGyeCl7aqeGjvASKK5c5KRfzLDS4I/+4XTnp2dZTpRSCpmgwl3em9cLgM2bruHQnaR A/cVtSFW2o8FUAhjcLjo2oxBApWkyh0SBmcH7Q+NgLuh1ri7dF2JPEUs9zw3Hq2sNlbo gNHNPZBDVEJoWd60vbwhFNY5EhWilS182tRlQ= Received: by 10.42.224.136 with SMTP id io8mr23447744icb.29.1297329483257; Thu, 10 Feb 2011 01:18:03 -0800 (PST) Received: from [10.0.1.5] (c-98-248-44-75.hsd1.ca.comcast.net [98.248.44.75]) by mx.google.com with ESMTPS id gy41sm1050056ibb.11.2011.02.10.01.18.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 10 Feb 2011 01:18:01 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ryuji Wakikawa In-Reply-To: <4D528D3C.3000606@piuha.net> Date: Thu, 10 Feb 2011 01:17:59 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6B8BD18E-BCE7-4DFE-901C-FD09F77E0B64@gmail.com> References: <4D528D3C.3000606@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1082) Cc: draft-zhu-mobility-survey@tools.ietf.org, Internet Area , Lixia Zhang Subject: Re: [Int-area] AD review of draft-zhu-mobility-survey X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 09:17:53 -0000 Hi Jari, Thanks for your review. Please find my comments inline. On 2011/02/09, at 4:49, Jari Arkko wrote: > I was asked to AD sponsor this draft to an RFC. Sorry for the = extremely long time this has taken to get to my review. But I have now = reviewed it. >=20 > Abstract from draft-zhu-mobility-survey: >=20 > Over the last two decades many efforts have been devoted to > developing solutions for mobility support over the global Internet, > which resulted in a variety of proposed solutions. In this draft we > conducted a systematic survey of the previous efforts to gain an > overall understanding on the solution space of mobility support. > This draft reports our finding and identifies remaining issues in > providing ubiquitous and efficient global scale mobility support. >=20 > The document is well written and a pleasure to read. It is a relevant = overview of the mobility protocol design space, and its analysis is = useful for thinking about the deployment issues that we've seen in this = space. As far as I can tell, the document includes most of the relevant = work (some exceptions noted below), and I have no major technical = comments. I have sent the draft forward to IETF Last Call, and hope that = you can work on the remaining issues during the last call, and get more = suggestions and additional material from the last call reviewers. thanks. > Technical: >=20 >> 4.12. IKEv2 Mobility and Multihoming Protocol (MOBIKE) >>=20 >>=20 >> MOBIKE is an extension to Internet Key Exchange (IKEv2) to support >> mobility and multihoming. The main purpose of MOBIKE is to allow >> roaming devices to keep the existing IKE and IPsec SAs despite of = IP >> address changes. The mobility support in MOBIKE allows both = parties >> to move, but it does not provide a rendezvous mechanism. In other >> words, simultaneous movement of both parties is not supported. >=20 > Hmm. While this is true, part of the simultaneous mobility support is = always in a stable anchor point, even in Mobile IP. If you assume mobike = device 1 =3D host and mobike device 2 =3D gateway, then the situation = really is equivalent to mobile IP mobile node - home agent arrangement. = Home agent stays put, but mobiles can move around and everything still = works. What we meant "simultaneous mobility support" here is the scenario where = two mobile nodes move at once. In your above case, mobilke device2 is = stable and don't move. We will clarify this point. > Also, I think it would be useful to state something about multihoming = support in some of these protocols. Some do support this, for instance = Mobike and more recently, also Mobile IP. A feature matrix for the = different protocols is not so interesting, but it would be useful to = understand what scope the different protocols have. Which scopes do you have in your mind?=20 I can imagine something like multihoming, dualstack, RO, network = mobility, anything else? >> The reachability >> information of the user's machine is published in DNS, and only >> accessible to the subscriber. >> =20 >=20 > "published in DNS" and "only accessible to the subscriber" do not = appear to be compatible statements. Can you expand on this a bit? >=20 >> BTMM has millions of subscribers, which is perhaps the first large- >> scale commercial host mobility support in Internet as of today. >=20 > I wonder if the use of Mobile IP in CDMA/3GPP2 networks exceeds this. = Please check. Also, since you are missing GTP which is essentially a = non-IETF variant of PMIP, you should probably include GTP and note that = that network-based mobility support is extremely widely used (to the = order of a billion data users). Right. We will update this part. >> The second approach to mobility support is to provide a mapping >> between a mobile's stable identifier and its dynamically changing IP >> address. Instead of notifying the world on every movement, a mobile >> only needs to update a single binding location about its location >> changes. In this approach, if one level of indirection at IP layer >> is used, as in the case of Mobile IP, it has a potential side effect >> of introducing triangle routing; otherwise, if the two end nodes are >> aware of each other's movement, it means that both ends have to >> support the same mobility protocol. >>=20 >> Yet there is the third case in which the protocols combine the above >> approaches, in the hope of keeping the pros and eliminating some cons >> of the two. WINMO is a typically protocol in this case. >> =20 >=20 > This is a very nice classification. But I have a question. How would = you classify designs that include support for route optimization, such = as Mobile IP? They do not impact routers, but still there's a need to = update more than a single entity about a new location? Also, in Section = 5.2 you talk about mobility aware entities, but this does not take into = account whether the CNs are aware in route optimization mode. As a base protocol design, Mobile IP works with a single binding at HA.=20= A mobile node can decide whether RO is activated or not.=20 When we discuss the protocol design in high level, Route Optimization = can be treated as an option so that we didn't mention RO here. We will try to include RO feature in this document. =20 > Missing: >=20 > It might be valuable to describe the limited mobility support in = transport layer solutions (SCTP and MP-TCP) as well. That is, they allow = a single connection to stay up even as you move around, but do not by = themselves allow simultaneous mobility of both parties. What about = SHIM6? >=20 > I would talk about GTP (a network-based mobility protocol) as well. >=20 > What about mentioning application layer mobility designs (e.g., start = from the paper by Henning on SIP mobility)? >=20 > It might be useful to have at least some pointers to various = optimization efforts that the community has spent quite a lot of time = on. It felt that FMIP was the only one that was mentioned in addition to = the general idea of route optimization in Mobile IP. Look for pointers = from the MIPSHOP WG's page, RFC 4651, etc. OK, I mostly agree with you.=20 Do we need SHIM6 here? Although SHIM6 solve ID and locator things for = multihoming purpose, it has potential to solve mobility issue, too. I remembered there were some mobility discussion, but I'm not sure there = is mobility related extension to SHIM6. regards, ryuji > Editorial: >=20 >> Xing, W., Karl, H., and A. Wolisz, "M-SCTP: Design and >> Prototypical Implementaion of An End-to-End Mobility >> Concept" > Typo >=20 >> LISP-Mobility [LISP-Mobility = ] is a relatively new design, in which >> the designer hopes to utilize LISP[LISP], which is designed for >> routing scalability, to support mobility as well.=20 >=20 > This sentence could probably be simplified a bit. >=20 > Jari >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From ford@isoc.org Thu Feb 10 01:26:32 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 911A83A69F4 for ; Thu, 10 Feb 2011 01:26:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.849 X-Spam-Level: X-Spam-Status: No, score=-99.849 tagged_above=-999 required=5 tests=[AWL=-1.250, BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJ+OVlN3OPl0 for ; Thu, 10 Feb 2011 01:26:30 -0800 (PST) Received: from smtp111.iad.emailsrvr.com (smtp111.iad.emailsrvr.com [207.97.245.111]) by core3.amsl.com (Postfix) with ESMTP id 51ED43A695C for ; Thu, 10 Feb 2011 01:26:30 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp51.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id D7C2D20DB7; Thu, 10 Feb 2011 04:26:41 -0500 (EST) X-Virus-Scanned: OK Received: by smtp51.relay.iad1a.emailsrvr.com (Authenticated sender: ford-AT-isoc.org) with ESMTPSA id 7BD4A20D49; Thu, 10 Feb 2011 04:26:40 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Matthew Ford In-Reply-To: <4D48B4EA.20503@isi.edu> Date: Thu, 10 Feb 2011 10:26:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1F32B5B8-62AC-4BC5-9412-8575599A9001@isoc.org> References: <4D48B4EA.20503@isi.edu> To: TSV Dir X-Mailer: Apple Mail (2.1082) Cc: tsv-ads@tools.ietf.org, draft-ietf-intarea-shared-addressing-issues@tools.ietf.org, Internet Area Subject: Re: [Int-area] TSVDIR review of draft-ietf-intarea-shared-addressing-issues-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 09:26:32 -0000 Hi Joe, Thanks for the detailed review. I've noted inline below where I've tried = to address these comments in the latest rev of the draft. There are some = questions for clarification below as well. The revision is here: = http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues-03 Mat On 2 Feb 2011, at 02:35, Joe Touch wrote: > Hi, all, >=20 > I've reviewed this document as part of the transport area = directorate's > ongoing effort to review key IETF documents. These comments were = written > primarily for the transport area directors, but are copied to the > document's authors for their information and to allow them to address > any issues raised. The authors should consider this review together = with > any other last-call comments they receive. Please always CC > tsv-dir@ietf.org if you reply to or forward this review. >=20 > The document describes the issues with IP address sharing approaches, = independent of approach. The document does include a number of = application issues, many of which originate from transport protocol = problems, as well as a few specific transport issues. >=20 > There are a few missing transport issues that should be addressed = prior to final publication, as noted below. Overall, the document does = discuss some such issues in various places, but the table should include = these issues, and the issue discussion should be expanded to include = some issues not currently addressed. >=20 > Some of these changes are substantive, however, and I recommend that = the changes be discussed in the transport WG (e.g. TSVWG, = tsvwg@ietf.org) before proceeding with publication of this document. >=20 > The note below includes the significant transport issues, as well as = additional comments interspersed in a copy of the text as well. Some are = editorial ("??") and should not impede doc. progress. There are a few = issues labeled "?INT?" that are Internet-area (IP), not transport = issues, but they would be very useful to also treat as substantive = rather than editorial. >=20 > I hope this feedback will be useful to the authors, and will be glad = to provide further assistance either on- or off-list as useful. >=20 > Joe >=20 > -------------------------------------------------------------- >=20 > Transport issues include: >=20 > - refers to "Well Known ports" > Throughout this document, this usually refers to the entire Assigned = range, i.e., Well-known (i.e., System) as well as Registered (i.e., = User) ports. It would be preferable to refer to them as "Assigned = ports", and include "(both System and User)". The term "Registered" = should, FWIW, be avoided as it is ambiguous (since both User and System = ports are registered with IANA). >=20 I've cleaned this up where necessary. > - omits numerous transport issues from the table > Such issues include, but may not be limited to: >=20 > - port handoff > this is included in section 6, but not in the table > and sec 6 should call out specific protocols > affected, e.g., FTP, among others) Can you clarify what part of section 6 this is referring to? > - port discovery (using a UDP port to discover a service > available on a corresponding TCP port, either > through broadcast, multicast, or unicast) > this is common, and not discussed anywhere > see "-disc" in the IANA ports listing (that > suffix has been in use recently, and helps > highlight how common the practice is) Added a new subsection to =A75 Incoming Ports to mention this case. = Added to the table. > - service discovery through the DNS (e.g., SRV records) > mentioned in 5.2.2, but not here I'm not sure I see how this is relevant for inclusion in the table. DNS = service discovery is a partial solution to the issue of enabling inbound = communications in the presence of address sharing, not an issue caused = by address sharing. > - parallel connections > i.e., that assume that a single IP address used > for multiple connections implies a single machine, > as with striping, multipath, or systems that use > multiple concurrent connections for different services > (somewhat related to load balancing in sec 16,=09 > but not necessarily) OK - added to the table, and added some text in a new section on = 'Transport Issues'. > - serial connections > i.e., that assume that returning to a given=09 > IP address returns to the same physical host, > as with stateful transactions; this may also affect > cookie-based systems, such as TCP-CT, TCP with SYN > cookies, etc. Added to table and Transport issues section. > - TCP state mechanisms > e.g., that might allow a connection that should have > been in TIME-WAIT (this is discussed in Sec 5, but > not listed as an issue) This isn't necessarily an issue caused by address sharing. It *could* be = an issue, if the address sharing mechanism is poorly implemented, but = I'm not sure we want to get into all the things that could go wrong in = that case. > - address or DNS-name-based signatures > as in some X.509 signatures >=20 I added some text to the Authentication section. > - omits some network issues from the table > This is in Sec 11, but missing from the table. See the NAT discussion = in draft-ietf-intarea-ipv4-id-update for a related discussion. There = appear to be more issues here than just the lack of port numbers. The table mentions fragmentation as an issue. I've added some text to = highlight that IPID may also be an issue. >=20 > ----------------------------------------------------------- >=20 > ... >> Issues with IP Address Sharing >> draft-ietf-intarea-shared-addressing-issues-02 >>=20 >> Abstract >>=20 >> The completion of IPv4 address allocations from IANA and the RIRs = is >> causing service providers around the world to question how they = will >> continue providing IPv4 connectivity service to their subscribers >> when there are no longer sufficient IPv4 addresses to allocate them >> one per subscriber. Several possible solutions to this problem are >> now emerging based around the idea of shared IPv4 addressing. = These >> solutions give rise to a number of issues and this memo identifies >> those common to all such address sharing approaches. Solution- >> specific discussions are out of scope. >=20 > ?? The abstract is a bit vague. It would be useful to summarize some = of the issues of note. >=20 I added a sentence calling out some of the 'buckets' of issues, but I'm = trying to keep the abstract short. > ... >> 1. Introduction > ... >>=20 >> Over the long term, deploying IPv6 is the only way to ease pressure >> on the public IPv4 address pool and thereby mitigate the need for >> address sharing mechanisms that give rise to the issues identified >> herein. >=20 > ?? This sentence is misleading. Clearly address sharing eases pressure = too, but has caveats. It should be revised to be more clear about the = options available. >=20 I've revised to say IPv6 is the only way to ease pressure without = creating the issues identified in the document. > ... >> 2. Shared Addressing Solutions >=20 > This section should define address sharing. It's implied, and two = variants given (1:N NAT, and M:N pooled sharing), but that should be = made very direct and clear. >=20 No change. > ... >> In Figure 1 we have also tried to indicate (with 'xx') where issues >> are newly created in addition to what could be expected from the >> introduction of a traditional NAT device. Issues marked with a >> single 'x' are already present today in the case of typical CPE = NAT, >> however they can be expected to be more severe and widespread in = the >> case of large-scale address sharing. >=20 > ?? The notation description could be more clear, e.g. (presuming the = description is correct): >=20 > ?? In this figure, "x" indicates issues already present with a NAT, = and "xx" are for those further issues introduced by pooled sharing. >=20 > > = +------------------------------------------------+--------+---------+ > > | Issue | 1st | 3rd = | > > | | party | parties = | > > = +------------------------------------------------+--------+---------+ >=20 > This table is useful, but the issue descriptions are subjective in = some cases, where others are objective. All issues should be objectively = described. >=20 I didn't see a lot of subjectivity, but I did a little wordsmithing. > Further, some issues overlap - "Some applications will fail to = operate" can be related to other issues, e.g., lack of reverse DNS (for = apps using DNS names for ACLs), lack of ICMP (for apps using transport = requiring PMTUD, rather than PLPMTUD), etc. >=20 Yup. > See the primary note above for items missing from this list. >=20 > ... >> | Incoming connections to Well-Known Ports will | x | = | >> | not work | | = | >=20 > This will affect both Well-Known (i.e., user) and System ports. Use = the term "Assigned Ports" to refer to the sum of both ranges. Got it - changed. >=20 >> 5. Port Allocation > ... >> IANA has classified the whole port space into three categories (as >> defined in http://www.iana.org/assignments/port-numbers): >=20 > Cite RFC 1340 here, rather than the web pages; that's where the ranges = were defined. RFC1340 doesn't speak about dynamic/private ports. I've added a = reference to RFC1340 to support definition of Assigned Ports. >=20 > It's useful here to define "Assigned" as including both Well-known and = Registered ranges as well (to refer to it later, e.g., in Sec 6). >=20 OK. > ... >> 5.2.1.2. NAT Port Mapping Protocol (NAT-PMP) >>=20 >> NAT-PMP already has a better semantic here, enabling the NAT to >> redirect the application to an available port number. >=20 > ?? This section is brief; it would be useful to explain what is = better. Is it better because it can use ANY available port number? What = defines available? >=20 I've wordsmithed this a little. >> 5.2.2. Connection to a Well-Known Port Number > ... >> For example, the use of DNS SRV records [RFC2782] provides a >> potential solution for subscribers wishing to host services in the >> presence of a shared-addressing scheme. SRV records make it = possible >> to specify a port value related to a service, thereby making = services >> accessible on ports other than the Well-Known ports. It is worth >> noting that this mechanism is not applicable to HTTP. >=20 > It's not clear why HTTP is singled out here. Few of the commonly used = services rely on SRV records. HTTP is singled out as web servers are especially popular services for = end-users to want to run. >=20 >> 6. Impact on Applications > ... >> o Applications that use fixed ports (e.g., well-known ports) - see >> Section 5.2.2 for more discussion of this; >=20 > Use the term "Assigned" here". I've removed the text in parentheses. >=20 > ... >> o Applications that do not use any port (e.g., ICMP) - where = address >> sharing solutions map subscribers to (private) IP addresses on a >> one-to-one basis this will not be an issue, otherwise such >> applications will require special handling - see Section 9 for >> more discussion of this; >=20 > ICMP does use port information, notably to demux the the signal to the = appropriate transport connection or association. An alternate example = might be useful. Some ICMP message types include a fragment of the datagram that = triggered the signal to be sent, which is assumed to include port = numbers. For some ICMP message types, the Identifier field has to be = used as a demuxing token. I've made a number of changes, additions and = clarifications to Section 9 to address this better. > ... >> 7. Geo-location and Geo-proximity >=20 > ?INT? This section is, IMO, odd; IP address never meant physical = location anyway, and tunnels obviate that meaning regardless of the = impact of NATs or other sharing techniques. I've added the point that using IP addresses in this fashion is a = heuristic at best and already challenged today by deployed capabilities, = e.g. tunnels. >=20 > ... >> 9. ICMP >>=20 >> ICMP does not carry any port information and is consequently >> problematic for address sharing mechanisms. >=20 > ICMP messages are specifically intended to include enough of the = transport header to enable port demuxing at the end receiver. When that = is not available, the demuxing fails. That can impact a number of = devices, including PMTUD. As already mentioned, I've cleaned this section up to clarify the = situation. >=20 >> 11. Fragmentation >>=20 >> When a packet is fragmented, transport-layer port information = (either >> UDP or TCP) is only present in the first fragment. Subsequent >> fragments will not carry the port information and so will require >> special handling. >=20 > ?INT? The ID will be incorrect too; it may not be unique as required = when viewed from the outside. I've added this point. > ... >> 13. Security >=20 > This section might also address the impact of sharing on X.509 = authentication, e.g., that signs the name of a host. This can be = important for some applications. >=20 Happy to include some text if you can send it this week. >> 13.4. Port Randomisation > ... >> It should be noted that guessing the port information may not be >> sufficient to carry out a successful blind attack. The exact TCP >> Sequence Number (SN) should also be known. >=20 > There are data injection attacks that are possible even without = knowing the exact SN. >=20 > Further, port randomization is just one way to protect a connection = (another includes timestamp verification, as noted in RFC4953). I've changed 'exact' to 'in-window' and included a reference to RFC5961. = The draft already notes that 'port randomisation is one protection among = others against blind attacks.' >=20 > > A TCP segment is >> processed only if all previous segments have been received, except >> for some Reset Segment implementations which immediately process = the >> Reset as long as it is within the Window. >=20 > Processing the reset if in-window is valid according to existing = standards. See Sec 1.1 of > draft-ietf-tcpm-tcpsecure-13; i.e., it is a MAY except where = specifically warranted. >=20 > ?? There's also a proposal for an experimental version of TCP-AO that = supports NAT traversal, FWIW (draft-touch-tcp-ao-nat). >=20 > ------ From Internet-Drafts@ietf.org Thu Feb 10 01:30:20 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0FEF3A6A09; Thu, 10 Feb 2011 01:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaTnmhMw+LXa; Thu, 10 Feb 2011 01:30:15 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B86313A695C; Thu, 10 Feb 2011 01:30:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110210093001.21190.55745.idtracker@localhost> Date: Thu, 10 Feb 2011 01:30:01 -0800 Cc: int-area@ietf.org Subject: [Int-area] I-D Action:draft-ietf-intarea-shared-addressing-issues-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 09:30:21 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Area Working Group Working Group of the IETF. Title : Issues with IP Address Sharing Author(s) : M. Ford, et al. Filename : draft-ietf-intarea-shared-addressing-issues-03.txt Pages : 29 Date : 2011-02-10 The completion of IPv4 address allocations from IANA and the RIRs is causing service providers around the world to question how they will continue providing IPv4 connectivity service to their subscribers when there are no longer sufficient IPv4 addresses to allocate them one per subscriber. Several possible solutions to this problem are now emerging based around the idea of shared IPv4 addressing. These solutions give rise to a number of issues and this memo identifies those common to all such address sharing approaches. Such issues include application failures, additional service monitoring complexity, new security vulnerabilities and so on. Solution- specific discussions are out of scope. Over the long term, deploying IPv6 is the only way to ease pressure on the public IPv4 address pool without the need for address sharing mechanisms that give rise to the issues identified herein. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-intarea-shared-addressing-issues-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-intarea-shared-addressing-issues-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-10012237.I-D@ietf.org> --NextPart-- From adurand@juniper.net Thu Feb 10 01:51:10 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A04703A6959 for ; Thu, 10 Feb 2011 01:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DsQqt7+5v8p for ; Thu, 10 Feb 2011 01:51:09 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id 87FD33A6929 for ; Thu, 10 Feb 2011 01:51:01 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTVO1DpQmoL2v8TOsOtxOLw50K/+aLlLs@postini.com; Thu, 10 Feb 2011 01:51:21 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 10 Feb 2011 01:48:40 -0800 From: Alain Durand To: " " Date: Thu, 10 Feb 2011 01:48:50 -0800 Thread-Topic: [Int-area] I-D Action:draft-ietf-intarea-server-logging-recommendations-02.txt Thread-Index: AcvJB7mXU4WVpP/5TZKbHbkgVdqcgg== Message-ID: References: <20110119183002.30410.51185.idtracker@localhost> <98A16B2D00B5724F81E80EF1927A029703FC95@nasanexd01e.na.qualcomm.com> <31963_1297088150_4D4FFE96_31963_99436_1_94C682931C08B048B7A8645303FDC9F33C44015A86@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <31963_1297088150_4D4FFE96_31963_99436_1_94C682931C08B048B7A8645303FDC9F33C44015A86@PUEXCB1B.nanterre.francetelecom.fr> 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 Cc: Julien Laganier , Christian, "draft-ietf-intarea-server-logging-recommendations@tools.ietf.org" , Vogt , "int-area@ietf.org" Subject: Re: [Int-area] I-D Action:draft-ietf-intarea-server-logging-recommendations-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 09:51:10 -0000 On Feb 7, 2011, at 9:15 AM, wrote: > Dear authors, all, >=20 > I read this I-D and have the following comments: >=20 > * In its current state, this I-D does not add more content compared to wh= at is stated in http://tools.ietf.org/html/draft-ietf-intarea-shared-addres= sing-issues-02#section-12. I understand this document aims to make a recomm= endation but IMHO it would be useful if the I-D discusses other aspects whi= ch are not covered so far such as the behaviour of the server when some hea= ders such XFF are used. Storing the content of such headers would be useful= in some scenarios (the port binding is not logged in the address sharing s= ide) which prefer to expose an identifier to the destination server instead= of maintaining a binding.=20 Med: draft-ietf-intarea-shared-addressing-issues was about describing issues, no= t making recommendations. - Alain. From roberta.maglione@telecomitalia.it Thu Feb 10 02:13:50 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D3E43A6956 for ; Thu, 10 Feb 2011 02:13:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cc3xfj3V25qn for ; Thu, 10 Feb 2011 02:13:49 -0800 (PST) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id 24DAE3A6947 for ; Thu, 10 Feb 2011 02:13:49 -0800 (PST) Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 10 Feb 2011 11:13:52 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Thu, 10 Feb 2011 11:13:51 +0100 From: Maglione Roberta To: "'ford@isoc.org'" Date: Thu, 10 Feb 2011 11:13:47 +0100 Thread-Topic: [Int-area] I-D Action:draft-ietf-intarea-shared-addressing-issues-03.txt Thread-Index: AcvJBU56A+Vh1tqbTKO/WTh5kN60FwABDCJg Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EB1560951@GRFMBX704BA020.griffon.local> References: <20110210093001.21190.55745.idtracker@localhost> In-Reply-To: <20110210093001.21190.55745.idtracker@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'int-area@ietf.org'" Subject: Re: [Int-area] I-D Action:draft-ietf-intarea-shared-addressing-issues-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 10:13:50 -0000 Hi Mat, I read the draft and I have a comment: in section 5.2.1 where you talk about port negotiation / port mapping when = NAT is performed in the network, (like for example DS-lite case), in my op= inion it would be useful to refer to Port Control Protocol work (draft-ietf= -pcp-base-04 currently discussed in PCP WG), as a possible way to address t= his issue; you can see PCP as an evolution of UPnP/NAT-PMP for a geographic= scenario. Thanks, Regards, Roberta -----Original Message----- From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On Behal= f Of Internet-Drafts@ietf.org Sent: gioved=EC 10 febbraio 2011 10.30 To: i-d-announce@ietf.org Cc: int-area@ietf.org Subject: [Int-area] I-D Action:draft-ietf-intarea-shared-addressing-issues-= 03.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Internet Area Working Group Working Group = of the IETF. Title : Issues with IP Address Sharing Author(s) : M. Ford, et al. Filename : draft-ietf-intarea-shared-addressing-issues-03.tx= t Pages : 29 Date : 2011-02-10 The completion of IPv4 address allocations from IANA and the RIRs is causing service providers around the world to question how they will continue providing IPv4 connectivity service to their subscribers when there are no longer sufficient IPv4 addresses to allocate them one per subscriber. Several possible solutions to this problem are now emerging based around the idea of shared IPv4 addressing. These solutions give rise to a number of issues and this memo identifies those common to all such address sharing approaches. Such issues include application failures, additional service monitoring complexity, new security vulnerabilities and so on. Solution- specific discussions are out of scope. Over the long term, deploying IPv6 is the only way to ease pressure on the public IPv4 address pool without the need for address sharing mechanisms that give rise to the issues identified herein. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-intarea-shared-addressing-is= sues-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From mohamed.boucadair@orange-ftgroup.com Thu Feb 10 02:32:39 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59B0E3A6947 for ; Thu, 10 Feb 2011 02:32:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9xOHoObfAsm for ; Thu, 10 Feb 2011 02:32:38 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id 42FAB3A68DB for ; Thu, 10 Feb 2011 02:32:37 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id A75902AC183; Thu, 10 Feb 2011 11:32:48 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 8A20AC8069; Thu, 10 Feb 2011 11:32:48 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Thu, 10 Feb 2011 11:32:48 +0100 From: To: Alain Durand Date: Thu, 10 Feb 2011 11:32:46 +0100 Thread-Topic: [Int-area] I-D Action:draft-ietf-intarea-server-logging-recommendations-02.txt Thread-Index: AcvJB7mXU4WVpP/5TZKbHbkgVdqcggABb/oQ Message-ID: <12200_1297333968_4D53BED0_12200_36165_1_94C682931C08B048B7A8645303FDC9F33C443B8C0C@PUEXCB1B.nanterre.francetelecom.fr> References: <20110119183002.30410.51185.idtracker@localhost> <98A16B2D00B5724F81E80EF1927A029703FC95@nasanexd01e.na.qualcomm.com> <31963_1297088150_4D4FFE96_31963_99436_1_94C682931C08B048B7A8645303FDC9F33C44015A86@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.2.10.85417 Cc: Julien Laganier , Christian, "draft-ietf-intarea-server-logging-recommendations@tools.ietf.org" , Vogt , "int-area@ietf.org" Subject: Re: [Int-area] I-D Action:draft-ietf-intarea-server-logging-recommendations-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 10:32:39 -0000 Dear Alain, Yes, your are right.=20=20 Still, I re-iterate my comments for this I-D: * It would be useful if the I-D discusses other aspects such as the behavio= ur of the server when some headers such XFF are used. Storing the content o= f such headers would be useful in some scenarios (the port binding is not l= ogged in the address sharing side) which prefer to expose an identifier to = the destination server instead of maintaining a binding.=20 * The I-D should mention that perceived IP address and source may not be su= fficient to find the identity of the user; in particular when anonymization= capabilities (e.g., infrastructures with onion routing or proxies, etc.) a= re used. * Section 3 is out of scope and should be removed. =20 Cheers, Med =20 -----Message d'origine----- De : Alain Durand [mailto:adurand@juniper.net]=20 Envoy=E9 : jeudi 10 f=E9vrier 2011 10:49 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Julien Laganier; int-area@ietf.org; draft-ietf-intarea-server-logging-= recommendations@tools.ietf.org; Christian Vogt; Jari Arkko Objet : Re: [Int-area] I-D Action:draft-ietf-intarea-server-logging-recomme= ndations-02.txt On Feb 7, 2011, at 9:15 AM, wrote: > Dear authors, all, >=20 > I read this I-D and have the following comments: >=20 > * In its current state, this I-D does not add more content compared to wh= at is stated in http://tools.ietf.org/html/draft-ietf-intarea-shared-addres= sing-issues-02#section-12. I understand this document aims to make a recomm= endation but IMHO it would be useful if the I-D discusses other aspects whi= ch are not covered so far such as the behaviour of the server when some hea= ders such XFF are used. Storing the content of such headers would be useful= in some scenarios (the port binding is not logged in the address sharing s= ide) which prefer to expose an identifier to the destination server instead= of maintaining a binding.=20 Med: draft-ietf-intarea-shared-addressing-issues was about describing issues, no= t making recommendations. - Alain. ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From alberto@it.uc3m.es Thu Feb 10 04:08:39 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD9603A6973 for ; Thu, 10 Feb 2011 04:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgbjQW+NrAxK for ; Thu, 10 Feb 2011 04:08:39 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 0705C3A6921 for ; Thu, 10 Feb 2011 04:08:37 -0800 (PST) X-uc3m-safe: yes Received: from BOMBO (unknown [163.117.139.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id A7ED96C308F; Thu, 10 Feb 2011 13:08:47 +0100 (CET) From: =?iso-8859-1?Q?Alberto_Garc=EDa?= To: "'Ryuji Wakikawa'" , "'Jari Arkko'" References: <4D528D3C.3000606@piuha.net> <6B8BD18E-BCE7-4DFE-901C-FD09F77E0B64@gmail.com> In-Reply-To: <6B8BD18E-BCE7-4DFE-901C-FD09F77E0B64@gmail.com> Date: Thu, 10 Feb 2011 13:08:50 +0100 Message-ID: <003e01cbc91b$46eda330$d4c8e990$@it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF8Dx4XWSZd3FGGXaAWJgagn0hCJQIniOxQlIjKD2A= Content-Language: es X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17946.003 Cc: draft-zhu-mobility-survey@tools.ietf.org, 'Internet Area' , 'Lixia Zhang' Subject: Re: [Int-area] AD review of draft-zhu-mobility-survey X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 12:08:40 -0000 Hi Ryuji, | > It might be valuable to describe the limited mobility support in transport | layer solutions (SCTP and MP-TCP) as well. That is, they allow a single | connection to stay up even as you move around, but do not by themselves | allow simultaneous mobility of both parties. What about SHIM6? | > | > I would talk about GTP (a network-based mobility protocol) as well. | > | > What about mentioning application layer mobility designs (e.g., start from | the paper by Henning on SIP mobility)? | > | > It might be useful to have at least some pointers to various optimization | efforts that the community has spent quite a lot of time on. It felt that FMIP | was the only one that was mentioned in addition to the general idea of | route optimization in Mobile IP. Look for pointers from the MIPSHOP WG's | page, RFC 4651, etc. | | OK, I mostly agree with you. | | Do we need SHIM6 here? Although SHIM6 solve ID and locator things for | multihoming purpose, it has potential to solve mobility issue, too. | I remembered there were some mobility discussion, but I'm not sure there | is mobility related extension to SHIM6. | Regarding to Shim6, it allows a node which has changed its location to inform the corresponding node about its new address(es). For this, the moving node must have a CGA configured, and the identifier used for initiating the Shim6 context (the ULID of the node) must be this CGA. Since there is no Rendezvous server defined for the Shim6 suite, 'simultaneous' movement of the communicating parties is not supported. As RFC 5533 states, Shim6 does not attempt to solve the problems of host mobility, although it may be useful in some specific scenarios. Besides, there are some guidelines (draft-ietf-shim6-applicability-08) on how to combine Shim6 and MIPv6 to allow mobile nodes benefiting from multihoming when the Multihomed Home Network is multihomed and the MN has multiple HoAs, so that Shim6 can be used between MN and CN; and when Shim6 can be used between MN and HA. A previous draft (draft-bagnulo-shim6-mip-00) went in more detail on this topic. Apart from this, there are no mobility extensions to Shim6. Regards, Alberto From ford@isoc.org Fri Feb 11 03:05:19 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B5553A696B for ; Fri, 11 Feb 2011 03:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.932 X-Spam-Level: X-Spam-Status: No, score=-101.932 tagged_above=-999 required=5 tests=[AWL=1.667, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9ZxsqeSd-sX for ; Fri, 11 Feb 2011 03:05:18 -0800 (PST) Received: from smtp151.iad.emailsrvr.com (smtp151.iad.emailsrvr.com [207.97.245.151]) by core3.amsl.com (Postfix) with ESMTP id A45433A6892 for ; Fri, 11 Feb 2011 03:05:18 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp55.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 1E4232E0272; Fri, 11 Feb 2011 06:05:33 -0500 (EST) X-Virus-Scanned: OK Received: by smtp55.relay.iad1a.emailsrvr.com (Authenticated sender: ford-AT-isoc.org) with ESMTPSA id 132512E0959; Fri, 11 Feb 2011 06:05:31 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Matthew Ford In-Reply-To: Date: Fri, 11 Feb 2011 12:05:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110119183002.30410.51185.idtracker@localhost> <98A16B2D00B5724F81E80EF1927A029703FC95@nasanexd01e.na.qualcomm.com> <31963_1297088150_4D4FFE96_31963_99436_1_94C682931C08B048B7A8645303FDC9F33C44015A86@PUEXCB1B.nanterre.francetelecom.fr> To: Alain Durand X-Mailer: Apple Mail (2.1082) Cc: Julien Laganier , "int-area@ietf.org" , "draft-ietf-intarea-server-logging-recommendations@tools.ietf.org" , Vogt , Christian@core3.amsl.com Subject: Re: [Int-area] I-D Action:draft-ietf-intarea-server-logging-recommendations-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 11:05:19 -0000 On 10 Feb 2011, at 10:48, Alain Durand wrote: >=20 > On Feb 7, 2011, at 9:15 AM, = wrote: >=20 >> Dear authors, all, >>=20 >> I read this I-D and have the following comments: >>=20 >> * In its current state, this I-D does not add more content compared = to what is stated in = http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues-02#= section-12. I understand this document aims to make a recommendation but = IMHO it would be useful if the I-D discusses other aspects which are not = covered so far such as the behaviour of the server when some headers = such XFF are used. Storing the content of such headers would be useful = in some scenarios (the port binding is not logged in the address sharing = side) which prefer to expose an identifier to the destination server = instead of maintaining a binding.=20 >=20 >=20 > Med: >=20 > draft-ietf-intarea-shared-addressing-issues was about describing = issues, not making recommendations. >=20 I agree. The shared-addressing-issues document was always intended to be = a catalogue of issues, and not to get into a large amount of detail = regarding any particular issue, and certainly not to make any specific = recommendations about how issues can be addressed. So in that light, I = think the server-logging-recommendations document is a helpful addition. Mat= From adurand@juniper.net Fri Feb 11 03:34:26 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CADE53A68B7 for ; Fri, 11 Feb 2011 03:34:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LZpYI4FzXwD for ; Fri, 11 Feb 2011 03:34:26 -0800 (PST) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id BA4FA3A6947 for ; Fri, 11 Feb 2011 03:34:16 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKTVUexP2JryYbuNsM0AqmE5jjnRNA4kQl@postini.com; Fri, 11 Feb 2011 03:34:40 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 11 Feb 2011 03:33:43 -0800 From: Alain Durand To: " " Date: Fri, 11 Feb 2011 03:33:55 -0800 Thread-Topic: [Int-area] I-D Action:draft-ietf-intarea-server-logging-recommendations-02.txt Thread-Index: AcvJ35GhurVHBoJiQ2q9vYlHUhUgQQ== Message-ID: References: <20110119183002.30410.51185.idtracker@localhost> <98A16B2D00B5724F81E80EF1927A029703FC95@nasanexd01e.na.qualcomm.com> <31963_1297088150_4D4FFE96_31963_99436_1_94C682931C08B048B7A8645303FDC9F33C44015A86@PUEXCB1B.nanterre.francetelecom.fr> <12200_1297333968_4D53BED0_12200_36165_1_94C682931C08B048B7A8645303FDC9F33C443B8C0C@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <12200_1297333968_4D53BED0_12200_36165_1_94C682931C08B048B7A8645303FDC9F33C443B8C0C@PUEXCB1B.nanterre.francetelecom.fr> 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 Cc: Julien Laganier , Christian, "draft-ietf-intarea-server-logging-recommendations@tools.ietf.org" , Vogt , "int-area@ietf.org" Subject: Re: [Int-area] I-D Action:draft-ietf-intarea-server-logging-recommendations-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 11:34:27 -0000 Dear Med On Feb 10, 2011, at 5:32 AM, wrote: >=20 >=20 > * It would be useful if the I-D discusses other aspects such as the behav= iour of the server when some headers such XFF are used. Storing the content= of such headers would be useful in some scenarios (the port binding is not= logged in the address sharing side) which prefer to expose an identifier t= o the destination server instead of maintaining a binding.=20 This should be done in a separate document as this is application specific. > * The I-D should mention that perceived IP address and source may not be = sufficient to find the identity of the user; in particular when anonymizati= on capabilities (e.g., infrastructures with onion routing or proxies, etc.)= are used. This is already the case today without carrier grade NAT... Logging is nece= ssary but not always sufficient. > * Section 3 is out of scope and should be removed. This section was requested in a previous comment I received to specifically= say that this document will not make any recommendation on the ISP NAT sid= e. - Alain.= From mohamed.boucadair@orange-ftgroup.com Fri Feb 11 04:55:27 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C53253A687C for ; Fri, 11 Feb 2011 04:55:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.081 X-Spam-Level: X-Spam-Status: No, score=-2.081 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8PrD4LVscyV for ; Fri, 11 Feb 2011 04:55:27 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by core3.amsl.com (Postfix) with ESMTP id A82853A681D for ; Fri, 11 Feb 2011 04:55:26 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 4290DC02E1; Fri, 11 Feb 2011 13:55:40 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 2791338403A; Fri, 11 Feb 2011 13:55:40 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Fri, 11 Feb 2011 13:55:39 +0100 From: To: Alain Durand Date: Fri, 11 Feb 2011 13:55:38 +0100 Thread-Topic: [Int-area] I-D Action:draft-ietf-intarea-server-logging-recommendations-02.txt Thread-Index: AcvJ35GhurVHBoJiQ2q9vYlHUhUgQQACpWVw Message-ID: <31963_1297428940_4D5531CC_31963_380837_1_94C682931C08B048B7A8645303FDC9F33C443B925D@PUEXCB1B.nanterre.francetelecom.fr> References: <20110119183002.30410.51185.idtracker@localhost> <98A16B2D00B5724F81E80EF1927A029703FC95@nasanexd01e.na.qualcomm.com> <31963_1297088150_4D4FFE96_31963_99436_1_94C682931C08B048B7A8645303FDC9F33C44015A86@PUEXCB1B.nanterre.francetelecom.fr> <12200_1297333968_4D53BED0_12200_36165_1_94C682931C08B048B7A8645303FDC9F33C443B8C0C@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.2.11.105417 Cc: Julien Laganier , Christian, "draft-ietf-intarea-server-logging-recommendations@tools.ietf.org" , Vogt , "int-area@ietf.org" Subject: Re: [Int-area] I-D Action:draft-ietf-intarea-server-logging-recommendations-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 12:55:27 -0000 Re-, Please see inline. Cheers, Med =20 -----Message d'origine----- De : Alain Durand [mailto:adurand@juniper.net]=20 Envoy=E9 : vendredi 11 f=E9vrier 2011 12:34 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Julien Laganier; int-area@ietf.org; draft-ietf-intarea-server-logging-= recommendations@tools.ietf.org; Christian Vogt; Jari Arkko Objet : Re: [Int-area] I-D Action:draft-ietf-intarea-server-logging-recomme= ndations-02.txt Dear Med On Feb 10, 2011, at 5:32 AM, wrote: >=20 >=20 > * It would be useful if the I-D discusses other aspects such as the behav= iour of the server when some headers such XFF are used. Storing the content= of such headers would be useful in some scenarios (the port binding is not= logged in the address sharing side) which prefer to expose an identifier t= o the destination server instead of maintaining a binding.=20 This should be done in a separate document as this is application specific. Med: Why not cover this in this document? These are related issues.=20 > * The I-D should mention that perceived IP address and source may not be = sufficient to find the identity of the user; in particular when anonymizati= on capabilities (e.g., infrastructures with onion routing or proxies, etc.)= are used. This is already the case today without carrier grade NAT... Logging is nece= ssary but not always sufficient. Med: Mention it in the I-D won't harm.=20=20 > * Section 3 is out of scope and should be removed. This section was requested in a previous comment I received to specifically= say that this document will not make any recommendation on the ISP NAT sid= e. Med: I checked the diffs and saw this section was there from the 00 of the = individual submission. This text is redundant with the note you have in the= introduction: " Note: this document provides recommendations for Internet facing servers logging incoming connections. It does not provide any recommendations about logging on carrier-grade NAT or other address sharing tools." - Alain. ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From julien.ietf@gmail.com Fri Feb 11 12:48:47 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C7DD3A6878 for ; Fri, 11 Feb 2011 12:48:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.322 X-Spam-Level: X-Spam-Status: No, score=-3.322 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-JYjVJk7KV9 for ; Fri, 11 Feb 2011 12:48:46 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id F18483A67B3 for ; Fri, 11 Feb 2011 12:48:45 -0800 (PST) Received: by eyd10 with SMTP id 10so1712438eyd.31 for ; Fri, 11 Feb 2011 12:49:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=M+RuXexTzRCZYQ1BA7fmCxb3fwmR73h/cElhSQ3Wioo=; b=gSRiMF1/Ysm87q644aM2rcunf6JtXXI2b5IUwq7km3joEKrwQZhbZU3mdW8sgy9B0b 9Yy89M4r1OMJMJDHcis0CRDjBl4KovyL9cvoDPwYMoqzCTeCCNXFFUWLJ9iHlLo3jOeR wJE9aOQ0yqM8uLZxYH7xZYP7Z+NrZoYnC+6SA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=LCovDv73wsma8/m8Irut484xsXuS/3zIx+f0x2MV5D58VHhEdtlh6uQR7LUgP1q3AJ owry4Y4a8l6NSsUIay4wRM7xw4xN1NhfYKHTdAKgMT+gspKZeMaI+N41EKTcJem6dO+g jmoUGmJb7ZuYP6XhJA0ufT3a/QWQfAnxMiWD8= MIME-Version: 1.0 Received: by 10.103.192.12 with SMTP id u12mr587852mup.75.1297457340607; Fri, 11 Feb 2011 12:49:00 -0800 (PST) Received: by 10.103.221.9 with HTTP; Fri, 11 Feb 2011 12:49:00 -0800 (PST) In-Reply-To: <31963_1297428940_4D5531CC_31963_380837_1_94C682931C08B048B7A8645303FDC9F33C443B925D@PUEXCB1B.nanterre.francetelecom.fr> References: <20110119183002.30410.51185.idtracker@localhost> <98A16B2D00B5724F81E80EF1927A029703FC95@nasanexd01e.na.qualcomm.com> <31963_1297088150_4D4FFE96_31963_99436_1_94C682931C08B048B7A8645303FDC9F33C44015A86@PUEXCB1B.nanterre.francetelecom.fr> <12200_1297333968_4D53BED0_12200_36165_1_94C682931C08B048B7A8645303FDC9F33C443B8C0C@PUEXCB1B.nanterre.francetelecom.fr> <31963_1297428940_4D5531CC_31963_380837_1_94C682931C08B048B7A8645303FDC9F33C443B925D@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 11 Feb 2011 12:49:00 -0800 Message-ID: From: Julien Laganier To: mohamed.boucadair@orange-ftgroup.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Julien Laganier , "int-area@ietf.org" , "draft-ietf-intarea-server-logging-recommendations@tools.ietf.org" , Vogt , Christian@core3.amsl.com Subject: Re: [Int-area] I-D Action:draft-ietf-intarea-server-logging-recommendations-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 20:48:47 -0000 Med, Please see below: wrote: > > [...] > > Alain Durand wrote: > > Dear Med > > On Feb 10, 2011, at 5:32 AM, wrote: >> >> >> * It would be useful if the I-D discusses other aspects such as the beha= viour of the server when some headers such XFF are used. Storing the conten= t of such headers would be useful in some scenarios (the port binding is no= t logged in the address sharing side) which prefer to expose an identifier = to the destination server instead of maintaining a binding. > > > This should be done in a separate document as this is application specifi= c. > > Med: Why not cover this in this document? These are related issues. Although I can agree with you that the cause and symptoms of the issues are related, they do belong to different layers and IMO it is not the role of an internet area WG to make recommendations on protocols of the application area. If you think a similar recommendation should be made w.r.t. XFF, which I actually don't think is even a standard, I believe this should be discussed in the application area. --julien From mohamed.boucadair@orange-ftgroup.com Sun Feb 13 22:55:31 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D1E83A6C82 for ; Sun, 13 Feb 2011 22:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUli-BMGjyff for ; Sun, 13 Feb 2011 22:55:30 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id 5153F3A6C81 for ; Sun, 13 Feb 2011 22:53:30 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 206E9324170; Mon, 14 Feb 2011 07:53:45 +0100 (CET) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 01CFD4C013; Mon, 14 Feb 2011 07:53:45 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Mon, 14 Feb 2011 07:53:44 +0100 From: To: Julien Laganier Date: Mon, 14 Feb 2011 07:53:43 +0100 Thread-Topic: [Int-area] I-D Action:draft-ietf-intarea-server-logging-recommendations-02.txt Thread-Index: AcvKLR1U11n7y1TvRcKDuIMGh2GZDQB5XNyw Message-ID: <3155_1297666425_4D58D179_3155_247779_1_94C682931C08B048B7A8645303FDC9F33C443B9542@PUEXCB1B.nanterre.francetelecom.fr> References: <20110119183002.30410.51185.idtracker@localhost> <98A16B2D00B5724F81E80EF1927A029703FC95@nasanexd01e.na.qualcomm.com> <31963_1297088150_4D4FFE96_31963_99436_1_94C682931C08B048B7A8645303FDC9F33C44015A86@PUEXCB1B.nanterre.francetelecom.fr> <12200_1297333968_4D53BED0_12200_36165_1_94C682931C08B048B7A8645303FDC9F33C443B8C0C@PUEXCB1B.nanterre.francetelecom.fr> <31963_1297428940_4D5531CC_31963_380837_1_94C682931C08B048B7A8645303FDC9F33C443B925D@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.2.14.52419 Cc: Julien Laganier , "int-area@ietf.org" , "draft-ietf-intarea-server-logging-recommendations@tools.ietf.org" , Vogt , "Christian@core3.amsl.com" Subject: Re: [Int-area] I-D Action:draft-ietf-intarea-server-logging-recommendations-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 06:55:31 -0000 Dear Julien, This is fair but IP-related information is conveyed sometimes at the applic= ation layer. I provided XFF as an example, other application-specific heade= rs can be considered for other internet-facing servers (e.g., SIP/SPTM/etc.= ). Having something like the following in the I-D would be fine with me: "Note that information about the identity of the source (e.g., source IP ad= dress, source port number) can be leaked in the application payload. It is = encouraged to log this information too." Cheers, Med=20 -----Message d'origine----- De : Julien Laganier [mailto:julien.ietf@gmail.com]=20 Envoy=E9 : vendredi 11 f=E9vrier 2011 21:49 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Alain Durand; Julien Laganier; Christian@core3.amsl.com; draft-ietf-in= tarea-server-logging-recommendations@tools.ietf.org; Vogt; int-area@ietf.org Objet : Re: [Int-area] I-D Action:draft-ietf-intarea-server-logging-recomme= ndations-02.txt Med, Please see below: wrote: > > [...] > > Alain Durand wrote: > > Dear Med > > On Feb 10, 2011, at 5:32 AM, wrote: >> >> >> * It would be useful if the I-D discusses other aspects such as the beha= viour of the server when some headers such XFF are used. Storing the conten= t of such headers would be useful in some scenarios (the port binding is no= t logged in the address sharing side) which prefer to expose an identifier = to the destination server instead of maintaining a binding. > > > This should be done in a separate document as this is application specifi= c. > > Med: Why not cover this in this document? These are related issues. Although I can agree with you that the cause and symptoms of the issues are related, they do belong to different layers and IMO it is not the role of an internet area WG to make recommendations on protocols of the application area. If you think a similar recommendation should be made w.r.t. XFF, which I actually don't think is even a standard, I believe this should be discussed in the application area. --julien ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From julien.ietf@gmail.com Mon Feb 14 09:03:45 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 499553A6A0F for ; Mon, 14 Feb 2011 09:03:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=-0.708, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QroDlhWJmXCD for ; Mon, 14 Feb 2011 09:03:44 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id E97593A69EB for ; Mon, 14 Feb 2011 09:03:43 -0800 (PST) Received: by fxm9 with SMTP id 9so5918606fxm.31 for ; Mon, 14 Feb 2011 09:04:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ANQWxsK48UqDVgcQvMt3Vs2D91ei5oFe0ff6Hsrg9Rs=; b=Z+dgwFtRl+ymL9TDTpQKJJT7wn4Eqdh5BZy+vV7e/PjvppSeSjE7T8c86FErLklu5R sHlhHiyKHYIaptbCdwu796z9GaSe1+8RsVZ/wughYLCVKPub0prFMgAav8EO5XiUhS9j lF/9EfLxTWc5qpZJC6i+l5X+97ZFMiFu4DfCE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=QI5We2BMauf/iTPBmN24pRaji/wSog3PtqvxFcoQwzHqGdSA3e3oZPlazbYYEQ8rqj W+tQWwa4n9DUmjQrmal9nXbyhrbuTUvLO3E+H/ySs1n2XbefXDBov49TmxMArfoK1GV4 oheJDx9igcn5VgciwQAE1t6MQZlD587ahhy5c= MIME-Version: 1.0 Received: by 10.223.103.4 with SMTP id i4mr4844661fao.123.1297703046565; Mon, 14 Feb 2011 09:04:06 -0800 (PST) Received: by 10.223.74.142 with HTTP; Mon, 14 Feb 2011 09:04:06 -0800 (PST) In-Reply-To: <3155_1297666425_4D58D179_3155_247779_1_94C682931C08B048B7A8645303FDC9F33C443B9542@PUEXCB1B.nanterre.francetelecom.fr> References: <20110119183002.30410.51185.idtracker@localhost> <98A16B2D00B5724F81E80EF1927A029703FC95@nasanexd01e.na.qualcomm.com> <31963_1297088150_4D4FFE96_31963_99436_1_94C682931C08B048B7A8645303FDC9F33C44015A86@PUEXCB1B.nanterre.francetelecom.fr> <12200_1297333968_4D53BED0_12200_36165_1_94C682931C08B048B7A8645303FDC9F33C443B8C0C@PUEXCB1B.nanterre.francetelecom.fr> <31963_1297428940_4D5531CC_31963_380837_1_94C682931C08B048B7A8645303FDC9F33C443B925D@PUEXCB1B.nanterre.francetelecom.fr> <3155_1297666425_4D58D179_3155_247779_1_94C682931C08B048B7A8645303FDC9F33C443B9542@PUEXCB1B.nanterre.francetelecom.fr> Date: Mon, 14 Feb 2011 09:04:06 -0800 Message-ID: From: Julien Laganier To: mohamed.boucadair@orange-ftgroup.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Julien Laganier , "int-area@ietf.org" , "draft-ietf-intarea-server-logging-recommendations@tools.ietf.org" , Vogt , "Christian@core3.amsl.com" Subject: Re: [Int-area] I-D Action:draft-ietf-intarea-server-logging-recommendations-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 17:03:45 -0000 Med, We can certainly have an informational statement highlighting the fact that some application layer payloads embed address and port number information. Making a recommendation on what to do with that information is however out of scope for this WG. --julien On Sun, Feb 13, 2011 at 10:53 PM, w= rote: > Dear Julien, > > This is fair but IP-related information is conveyed sometimes at the appl= ication layer. I provided XFF as an example, other application-specific hea= ders can be considered for other internet-facing servers (e.g., SIP/SPTM/et= c.). > > Having something like the following in the I-D would be fine with me: > > "Note that information about the identity of the source (e.g., source IP = address, source port number) can be leaked in the application payload. It i= s encouraged to log this information too." > > > Cheers, > Med > > -----Message d'origine----- > De : Julien Laganier [mailto:julien.ietf@gmail.com] > Envoy=E9 : vendredi 11 f=E9vrier 2011 21:49 > =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP > Cc : Alain Durand; Julien Laganier; Christian@core3.amsl.com; draft-ietf-= intarea-server-logging-recommendations@tools.ietf.org; Vogt; int-area@ietf.= org > Objet : Re: [Int-area] I-D Action:draft-ietf-intarea-server-logging-recom= mendations-02.txt > > Med, > > Please see below: > > wrote: >> >> [...] >> >> Alain Durand wrote: >> >> Dear Med >> >> On Feb 10, 2011, at 5:32 AM, wrote: >>> >>> >>> * It would be useful if the I-D discusses other aspects such as the beh= aviour of the server when some headers such XFF are used. Storing the conte= nt of such headers would be useful in some scenarios (the port binding is n= ot logged in the address sharing side) which prefer to expose an identifier= to the destination server instead of maintaining a binding. >> >> >> This should be done in a separate document as this is application specif= ic. >> >> Med: Why not cover this in this document? These are related issues. > > Although I can agree with you that the cause and symptoms of the > issues are related, they do belong to different layers and IMO it is > not the role of an internet area WG to make recommendations on > protocols of the application area. If you think a similar > recommendation should be made w.r.t. XFF, which I actually don't think > is even a standard, I believe this should be discussed in the > application area. > > --julien > > ********************************* > This message and any attachments (the "message") are confidential and int= ended solely for the addressees. > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration. > France Telecom Group shall not be liable for the message if altered, chan= ged or falsified. > If you are not the intended addressee of this message, please cancel it i= mmediately and inform the sender. > ******************************** > > From zhenkai@cs.ucla.edu Mon Feb 14 00:30:09 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57FF23A6971 for ; Mon, 14 Feb 2011 00:30:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.283 X-Spam-Level: X-Spam-Status: No, score=-6.283 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QZ6Z-fko9xK for ; Mon, 14 Feb 2011 00:30:03 -0800 (PST) Received: from out-71.smtp.ucla.edu (smtp-14.smtp.ucla.edu [IPv6:2607:f010:3fe:102:101c:23ff:fed0:956f]) by core3.amsl.com (Postfix) with ESMTP id 9C79D3A690E for ; Mon, 14 Feb 2011 00:30:02 -0800 (PST) Received: from smtp-14.smtp.ucla.edu (smtp-14.smtp.ucla.edu [169.232.46.241]) by out-71.smtp.ucla.edu with ESMTP id p1E8TqhI025208; Mon, 14 Feb 2011 00:29:53 -0800 Received: from mail.ucla.edu (mail.ucla.edu [169.232.46.157]) by smtp-14.smtp.ucla.edu (8.14.3/8.14.3) with ESMTP id p1E8TqhI025208; Mon, 14 Feb 2011 00:29:52 -0800 Received: from [192.168.1.3] (cpe-76-169-13-114.socal.res.rr.com [76.169.13.114]) (authenticated bits=0) by mail.ucla.edu (8.14.4/8.14.4) with ESMTP id p1E8TpBT015305 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 14 Feb 2011 00:29:52 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-2--610071859 From: Zhenkai Zhu In-Reply-To: <6B8BD18E-BCE7-4DFE-901C-FD09F77E0B64@gmail.com> Date: Mon, 14 Feb 2011 00:29:51 -0800 Message-Id: References: <4D528D3C.3000606@piuha.net> <6B8BD18E-BCE7-4DFE-901C-FD09F77E0B64@gmail.com> To: Jari Arkko X-Mailer: Apple Mail (2.1082) X-Probable-Spam: no X-Spam-Hits: 0.655 X-Scanned-By: smtp.ucla.edu on 169.232.46.241 X-Mailman-Approved-At: Mon, 14 Feb 2011 09:37:32 -0800 Cc: draft-zhu-mobility-survey@tools.ietf.org, Internet Area Subject: Re: [Int-area] AD review of draft-zhu-mobility-survey X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 08:30:09 -0000 --Apple-Mail-2--610071859 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello Jari Thanks for the review. Please find my comments inline.=20 On Feb 10, 2011, at 1:17 AM, Ryuji Wakikawa wrote: >>=20 >=20 >>> The reachability >>> information of the user's machine is published in DNS, and only >>> accessible to the subscriber. >>>=20 >>=20 >> "published in DNS" and "only accessible to the subscriber" do not = appear to be compatible statements. Can you expand on this a bit? BTMM uses long-lived query to allow DNS server to push changes to the = answers to the queries. TSIG is used for authentication when = establishing the long-lived query. We'll make it clear. >>=20 >>> BTMM has millions of subscribers, which is perhaps the first large- >>> scale commercial host mobility support in Internet as of today. >>=20 >> I wonder if the use of Mobile IP in CDMA/3GPP2 networks exceeds this. = Please check. Also, since you are missing GTP which is essentially a = non-IETF variant of PMIP, you should probably include GTP and note that = that network-based mobility support is extremely widely used (to the = order of a billion data users). >=20 > Right. We will update this part. I agree. >=20 >> Missing: >>=20 >> It might be valuable to describe the limited mobility support in = transport layer solutions (SCTP and MP-TCP) as well. That is, they allow = a single connection to stay up even as you move around, but do not by = themselves allow simultaneous mobility of both parties. What about = SHIM6? >>=20 >> I would talk about GTP (a network-based mobility protocol) as well. >>=20 >> What about mentioning application layer mobility designs (e.g., start = from the paper by Henning on SIP mobility)? >>=20 >> It might be useful to have at least some pointers to various = optimization efforts that the community has spent quite a lot of time = on. It felt that FMIP was the only one that was mentioned in addition to = the general idea of route optimization in Mobile IP. Look for pointers = from the MIPSHOP WG's page, RFC 4651, etc. >=20 > OK, I mostly agree with you.=20 >=20 > Do we need SHIM6 here? Although SHIM6 solve ID and locator things for = multihoming purpose, it has potential to solve mobility issue, too. > I remembered there were some mobility discussion, but I'm not sure = there is mobility related extension to SHIM6. >=20 So, in sum, We plan to briefly discuss the following in the draft: 1. GTP 2. transport protocols that can handle multiple IP addresses = (SCTP, multipath TCP) 3. applications that can handle change of IP addresses (SIP)=09 4. pointers to various optimizations for Mobile IP. We'll update the draft shortly and send it out for comments. Regards, Zhenkai --Apple-Mail-2--610071859 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hello = Jari

Thanks for the review. Please find my comments = inline. 

On Feb 10, 2011, at 1:17 AM, Ryuji = Wakikawa wrote:


The = reachability
 information of the user's = machine is published in DNS, and = only
 accessible to the = subscriber.


"published in = DNS" and "only accessible to the subscriber" do not appear to be = compatible statements. Can you expand on this a = bit?

BTMM uses = long-lived query to allow DNS server to push changes to the answers to = the queries. TSIG is used for authentication when establishing the = long-lived query.
We'll make it = clear.


 BTMM has millions of subscribers, which is perhaps = the first large-
 scale commercial host = mobility support in Internet as of = today.

I wonder if the = use of Mobile IP in CDMA/3GPP2 networks exceeds this. Please check. = Also, since you are missing GTP which is essentially a non-IETF variant = of PMIP, you should probably include GTP and note that that = network-based mobility support is extremely widely used (to the order of = a billion data users).

Right. We will update this = part.

I = agree.


Missing:

It might be = valuable to describe the limited mobility support in transport layer = solutions (SCTP and MP-TCP) as well. That is, they allow a single = connection to stay up even as you move around, but do not by themselves = allow simultaneous mobility of both parties. What about = SHIM6?

I would talk = about GTP (a network-based mobility protocol) as = well.

What about = mentioning application layer mobility designs (e.g., start from the = paper by Henning on SIP mobility)?

It might be = useful to have at least some pointers to various optimization efforts = that the community has spent quite a lot of time on. It felt that FMIP = was the only one that was mentioned in addition to the general idea of = route optimization in Mobile IP.  Look for pointers from the = MIPSHOP WG's page, RFC 4651, etc.

OK, I mostly agree = with you.

Do we need SHIM6 here? Although SHIM6 solve ID and = locator things for multihoming purpose, it has potential to solve = mobility issue, too.
I remembered there were some mobility = discussion, but I'm not sure there is mobility related extension to = SHIM6.


So, in sum,
We plan to briefly discuss the following in the = draft:
= 1. GTP
2. transport protocols that = can handle multiple IP addresses (SCTP, multipath TCP)
= 3. applications that can handle change of IP addresses =  (SIP) =
4. pointers to various = optimizations for Mobile IP.

We'll update the = draft shortly and send it out for = comments.

Regards,
Zhenkai

= --Apple-Mail-2--610071859-- From adurand@juniper.net Tue Feb 15 01:15:45 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEBDB3A6E6E for ; Tue, 15 Feb 2011 01:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlhPRVRxgD78 for ; Tue, 15 Feb 2011 01:15:45 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 905023A6B57 for ; Tue, 15 Feb 2011 01:15:44 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTVpEUCpybY2IsJKReo3740c+jPuHF2Tu@postini.com; Tue, 15 Feb 2011 01:16:10 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 15 Feb 2011 01:04:58 -0800 From: Alain Durand To: " " Date: Tue, 15 Feb 2011 01:04:57 -0800 Thread-Topic: [Int-area] I-D Action:draft-ietf-intarea-server-logging-recommendations-02.txt Thread-Index: AcvM72rIV8JFKECLTwSRAjFKuHMf8Q== Message-ID: <205ED2FF-1B67-4F9B-9A0D-1C97487D6776@juniper.net> References: <20110119183002.30410.51185.idtracker@localhost> <98A16B2D00B5724F81E80EF1927A029703FC95@nasanexd01e.na.qualcomm.com> <31963_1297088150_4D4FFE96_31963_99436_1_94C682931C08B048B7A8645303FDC9F33C44015A86@PUEXCB1B.nanterre.francetelecom.fr> <12200_1297333968_4D53BED0_12200_36165_1_94C682931C08B048B7A8645303FDC9F33C443B8C0C@PUEXCB1B.nanterre.francetelecom.fr> <31963_1297428940_4D5531CC_31963_380837_1_94C682931C08B048B7A8645303FDC9F33C443B925D@PUEXCB1B.nanterre.francetelecom.fr> <3155_1297666425_4D58D179_3155_247779_1_94C682931C08B048B7A8645303FDC9F33C443B9542@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <3155_1297666425_4D58D179_3155_247779_1_94C682931C08B048B7A8645303FDC9F33C443B9542@PUEXCB1B.nanterre.francetelecom.fr> 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 Cc: Julien Laganier , "int-area@ietf.org" , "draft-ietf-intarea-server-logging-recommendations@tools.ietf.org" , Vogt , Julien Laganier , "Christian@core3.amsl.com" Subject: Re: [Int-area] I-D Action:draft-ietf-intarea-server-logging-recommendations-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 09:15:46 -0000 On Feb 14, 2011, at 1:53 AM, wrote: > Dear Julien, >=20 > This is fair but IP-related information is conveyed sometimes at the appl= ication layer. I provided XFF as an example, other application-specific hea= ders can be considered for other internet-facing servers (e.g., SIP/SPTM/et= c.). >=20 > Having something like the following in the I-D would be fine with me: >=20 > "Note that information about the identity of the source (e.g., source IP = address, source port number) can be leaked in the application payload. It i= s encouraged to log this information too." >=20 Again, this was discussed and ruled out of scope. - Alain.= From rbarnes@bbn.com Tue Feb 15 08:50:56 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03C1A3A6C47; Tue, 15 Feb 2011 08:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.416 X-Spam-Level: X-Spam-Status: No, score=-102.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gA1sWPbJt-tS; Tue, 15 Feb 2011 08:50:53 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id BD9693A6C32; Tue, 15 Feb 2011 08:50:53 -0800 (PST) Received: from [128.89.253.66] (port=55903 helo=[192.168.5.174]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PpO7T-000EjB-8R; Tue, 15 Feb 2011 11:51:19 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <20110118150445.13842.1912.idtracker@localhost> Date: Tue, 15 Feb 2011 11:51:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <42DD8AF4-D936-479A-98E5-BF358E38425B@bbn.com> References: <20110118150445.13842.1912.idtracker@localhost> To: The IESG X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Tue, 15 Feb 2011 09:42:02 -0800 Cc: int-area@ietf.org, IETF-Announce Subject: Re: [Int-area] Last Call: (Issues with IP Address Sharing) to Informational RFC X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 16:50:56 -0000 One late comment on this: Section 7 discusses the impact of address = sharing on geolocation and geo-proximity use cases. (Nit: common usage = is "geolocation", not "geo-location") This section does a good job of = describing the impact of address sharing on the common case where an IP = address is used as a key into a generic "IP geo" database. However, there are several emerging systems that provide much more than = these generic databases. Typically, these systems tap into network = management infrastructure to map an IP address to the physical resource = to which it is assigned, using things like RADIUS databases and DHCP = lease tables. This is an important use case, for example, for ECRIT = emergency services [draft-ietf-ecrit-framework] using the HELD location = protocol [RFC5985]. (Also an issue that Law Enforcement agencies have = been known to care deeply about.) It would be good for this draft to comment on the impact of address = sharing for these high-precision IP-geo systems. Suggested text for = after the first paragraph of Section 7: " IP addresses are also used as input to higher-fidelity geolocation = services that resolve an IP address to a physical location using = information from the network infrastructure. Current systems rely on = resources such as RADIUS databases and DHCP lease tables. The use of = address sharing will prevent these systems from resolving the location = of a host based on IP address alone. It will be necessary for users of = such systems to provide more information (e.g., TCP or UDP port numbers = [I-D.ietf-geopriv-held-identity-extensions]), and for the systems to use = this information to query additional network resources (e.g., NAT-PT = binding tables). Since these new data elements tend to be more = ephemeral than those currently used for geolocation, their use by = geolocation systems may require them to be cached for some period of = time. "=20 On Jan 18, 2011, at 10:04 AM, The IESG wrote: >=20 > The IESG has received a request from the Internet Area Working Group = WG > (intarea) to consider the following document: > - 'Issues with IP Address Sharing' > as an > Informational RFC >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2011-02-01. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > The file can be obtained via > = http://datatracker.ietf.org/doc/draft-ietf-intarea-shared-addressing-issue= s/ >=20 > IESG discussion can be tracked via > = http://datatracker.ietf.org/doc/draft-ietf-intarea-shared-addressing-issue= s/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From brian.e.carpenter@gmail.com Tue Feb 15 13:26:47 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABA353A6CB9; Tue, 15 Feb 2011 13:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=-0.848, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMKDh4TGeRRH; Tue, 15 Feb 2011 13:26:46 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 5DD343A6C64; Tue, 15 Feb 2011 13:26:46 -0800 (PST) Received: by fxm9 with SMTP id 9so758029fxm.31 for ; Tue, 15 Feb 2011 13:27:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qjFO4Ce5xBiPd1P2j0B7/nPXZ1Ip6oOJkiOGyEQZ/Zs=; b=fZbw+fd/cRwI+ChRppWE7romQ0rRbU8hz+9zg2MtzlnZ7SAcnwyPXks1fWFxsLVGgu zEcrFCAWx4ZThbfHoI9raFGVqrhtfaaGKLRwvmILHyK0VWWQmkZx47uPJwl35rExHCbW fbKH+Ug28W0WSjhA07vpN/4IFu9X+jpwVdyT0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=F3Se9GW0cvT/PM7Vhp7iYk+4pYlVWkz7GwdBE4VtQLe62Lbt5oRm2moU1o3Qtg1pYK iko2gmJTQqdfSyvHrv0GswGGz5kSKxiqUqu6sy4xBRnWCBGGYRLH5aauoZs/yv/H23n4 24AHik2afTwUxXgIVi76dV0OVFgyc24iQGV8E= Received: by 10.223.83.16 with SMTP id d16mr10100176fal.148.1297805232031; Tue, 15 Feb 2011 13:27:12 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id a2sm1927008faw.22.2011.02.15.13.27.08 (version=SSLv3 cipher=OTHER); Tue, 15 Feb 2011 13:27:11 -0800 (PST) Message-ID: <4D5AEFA9.1080603@gmail.com> Date: Wed, 16 Feb 2011 10:27:05 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Richard L. Barnes" References: <20110118150445.13842.1912.idtracker@localhost> <42DD8AF4-D936-479A-98E5-BF358E38425B@bbn.com> In-Reply-To: <42DD8AF4-D936-479A-98E5-BF358E38425B@bbn.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: int-area@ietf.org, The IESG Subject: Re: [Int-area] Last Call: (Issues with IP Address Sharing) to Informational RFC X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 21:26:47 -0000 Richard, Restraining myself from commenting whether high-precision geolocation has a finite probability of working at all... > (e.g., NAT-PT binding tables) NAT-PT has been obsolete for several years. Do you mean NAPT? Brian On 2011-02-16 05:51, Richard L. Barnes wrote: > One late comment on this: Section 7 discusses the impact of address sharing on geolocation and geo-proximity use cases. (Nit: common usage is "geolocation", not "geo-location") This section does a good job of describing the impact of address sharing on the common case where an IP address is used as a key into a generic "IP geo" database. > > However, there are several emerging systems that provide much more than these generic databases. Typically, these systems tap into network management infrastructure to map an IP address to the physical resource to which it is assigned, using things like RADIUS databases and DHCP lease tables. This is an important use case, for example, for ECRIT emergency services [draft-ietf-ecrit-framework] using the HELD location protocol [RFC5985]. (Also an issue that Law Enforcement agencies have been known to care deeply about.) > > It would be good for this draft to comment on the impact of address sharing for these high-precision IP-geo systems. Suggested text for after the first paragraph of Section 7: > " > IP addresses are also used as input to higher-fidelity geolocation services that resolve an IP address to a physical location using information from the network infrastructure. Current systems rely on resources such as RADIUS databases and DHCP lease tables. The use of address sharing will prevent these systems from resolving the location of a host based on IP address alone. It will be necessary for users of such systems to provide more information (e.g., TCP or UDP port numbers [I-D.ietf-geopriv-held-identity-extensions]), and for the systems to use this information to query additional network resources (e.g., NAT-PT binding tables). Since these new data elements tend to be more ephemeral than those currently used for geolocation, their use by geolocation systems may require them to be cached for some period of time. > " > > > > On Jan 18, 2011, at 10:04 AM, The IESG wrote: > >> The IESG has received a request from the Internet Area Working Group WG >> (intarea) to consider the following document: >> - 'Issues with IP Address Sharing' >> as an >> Informational RFC >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2011-02-01. Exceptionally, comments may be >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-ietf-intarea-shared-addressing-issues/ >> >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-ietf-intarea-shared-addressing-issues/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > From touch@isi.edu Tue Feb 15 14:00:36 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 145003A6DB0; Tue, 15 Feb 2011 14:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.49 X-Spam-Level: X-Spam-Status: No, score=-103.49 tagged_above=-999 required=5 tests=[AWL=-0.891, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtsYAtHmxSwk; Tue, 15 Feb 2011 14:00:34 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id D99D83A6AB9; Tue, 15 Feb 2011 14:00:34 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p1FM0pYw023978 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 15 Feb 2011 14:00:51 -0800 (PST) Message-ID: <4D5AF793.9070204@isi.edu> Date: Tue, 15 Feb 2011 14:00:51 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Matthew Ford References: <4D48B4EA.20503@isi.edu> <1F32B5B8-62AC-4BC5-9412-8575599A9001@isoc.org> In-Reply-To: <1F32B5B8-62AC-4BC5-9412-8575599A9001@isoc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: p1FM0pYw023978 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tsv-ads@tools.ietf.org, draft-ietf-intarea-shared-addressing-issues@tools.ietf.org, Internet Area , TSV Dir Subject: Re: [Int-area] TSVDIR review of draft-ietf-intarea-shared-addressing-issues-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 22:00:36 -0000 Hi, Mat, As a followup.... On 2/10/2011 1:26 AM, Matthew Ford wrote: > Hi Joe, > > Thanks for the detailed review. I've noted inline below where I've tried to address these comments in the latest rev of the draft. There are some questions for clarification below as well. > > The revision is here: http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues-03 > > Mat > > On 2 Feb 2011, at 02:35, Joe Touch wrote: > >> Hi, all, >> >> I've reviewed this document as part of the transport area directorate's >> ongoing effort to review key IETF documents. These comments were written >> primarily for the transport area directors, but are copied to the >> document's authors for their information and to allow them to address >> any issues raised. The authors should consider this review together with >> any other last-call comments they receive. Please always CC >> tsv-dir@ietf.org if you reply to or forward this review. >> ... >> Joe >> >> -------------------------------------------------------------- >> >> Transport issues include: ... >> - omits numerous transport issues from the table >> Such issues include, but may not be limited to: >> >> - port handoff >> this is included in section 6, but not in the table >> and sec 6 should call out specific protocols >> affected, e.g., FTP, among others) > > Can you clarify what part of section 6 this is referring to? o Applications that carry address and/or port information in their payload - where translation of port and/or address information is performed at the IP and transport layers by the address sharing solution, an ALG will also be required to ensure application layer data is appropriately modified; >> - service discovery through the DNS (e.g., SRV records) >> mentioned in 5.2.2, but not here > > I'm not sure I see how this is relevant for inclusion in the table. > DNS service discovery is a partial solution to the issue of enabling > inbound communications in the presence of address sharing, not an issue > caused by address sharing. I was referring to the ways in which SRV record use can be interfered with by address sharing. I.e., this isn't included as a solution issue, but rather as another area of concern. >> - TCP state mechanisms >> e.g., that might allow a connection that should have >> been in TIME-WAIT (this is discussed in Sec 5, but >> not listed as an issue) > > This isn't necessarily an issue caused by address sharing. It > *could* be an issue, if the address sharing mechanism is poorly > implemented, but I'm not sure we want to get into all the things that > could go wrong in that case. The TCP spec - not implementation - isn't intended to support address sharing. An implementation CAN address these issues, but that's no different than a similar solution to any other entry in the table, AFAICT. The point is that merely sharing the addresses causes problems - in this case, inside the TCP stack - that need to be dealt with. >>> 5.2.2. Connection to a Well-Known Port Number >> ... >>> For example, the use of DNS SRV records [RFC2782] provides a >>> potential solution for subscribers wishing to host services in the >>> presence of a shared-addressing scheme. SRV records make it possible >>> to specify a port value related to a service, thereby making services >>> accessible on ports other than the Well-Known ports. It is worth >>> noting that this mechanism is not applicable to HTTP. >> >> It's not clear why HTTP is singled out here. Few of the commonly used services rely on SRV records. > > HTTP is singled out as web servers are especially popular services for end-users to want to run. It is then worth noting that this mechanism is applicable to few currently popular services, e.g., HTTP, SMTP, POP, IMAP, ... (no need for a long list, but it more clearly states your intent, IMO) >> ... >>> o Applications that do not use any port (e.g., ICMP) - where address >>> sharing solutions map subscribers to (private) IP addresses on a >>> one-to-one basis this will not be an issue, otherwise such >>> applications will require special handling - see Section 9 for >>> more discussion of this; >> >> ICMP does use port information, notably to demux the the signal to >> the appropriate transport connection or association. An alternate >> example might be useful. > > Some ICMP message types include a fragment of the datagram that > triggered the signal to be sent, which is assumed to include port > numbers. For some ICMP message types, the Identifier field has to be > used as a demuxing token. I've made a number of changes, additions and > clarifications to Section 9 to address this better. FWIW, the point here appears to be: ICMP does not include its own port number, and messages without a payload with its own port number (such as...) may be difficult or impossible to map in the presence of address sharing >>> 13. Security >> >> This section might also address the impact of sharing on X.509 >> authentication, e.g., that signs the name of a host. This can be >> important for some applications. > > Happy to include some text if you can send it this week. Sorry; this is a bit later than expected. I think you may already have addressed this issue in an earlier section, but the point here is as follows (in outline form): - some security IDs are based on IP addresses, which, when shared, may compromise the intended protection - some protocols rely on IP addresses for security associations, which, when shared, may compromise the protocols (e.g., not sure what happens to IPsec when the SPI database isn't coordinated across machines that share an address) Joe From julien.ietf@gmail.com Tue Feb 15 14:23:51 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA3D33A6B0B for ; Tue, 15 Feb 2011 14:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.204 X-Spam-Level: X-Spam-Status: No, score=-2.204 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXSffK2aHSCm for ; Tue, 15 Feb 2011 14:23:50 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id A40EF3A6C3B for ; Tue, 15 Feb 2011 14:23:49 -0800 (PST) Received: by fxm9 with SMTP id 9so815007fxm.31 for ; Tue, 15 Feb 2011 14:24:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EKKrJ1+WdZ1DcMkB8tqG5FtQ03/TT//zwiNb8g+iG64=; b=FpYLF/Pu6EAwJmoeUg/xnkOufwPIQsLm+HAx8qXeLLoUfZ3/JQhE5aUeMwaGFlbsTl VDQrfLiSxGVRjeCo8QdDozJ+guxaMHh0ostwRmoCObp43o/lOxEWOtbhkkS+SyqiMtMd zJZBKdIovrlc70Utdy8qy7XcdEgv21PCjRioU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=okBRmILCNS++RhOSIWxUW8X2Cz6ivTPTiY7Q0GL3RGEKGQ4svAKdh8iAoeOVqFpqUS nTNV2A4J7N3pZ4lAIwdy/uMKjRfyx3LvGn5wGcexCs+1WFkaUW7W8iotXAam34hNFLbk YEfCGcD3MFK52pMftMpJVFA0skeICex3T/XLE= MIME-Version: 1.0 Received: by 10.223.103.4 with SMTP id i4mr6874246fao.123.1297808655281; Tue, 15 Feb 2011 14:24:15 -0800 (PST) Received: by 10.223.74.142 with HTTP; Tue, 15 Feb 2011 14:24:15 -0800 (PST) In-Reply-To: <205ED2FF-1B67-4F9B-9A0D-1C97487D6776@juniper.net> References: <20110119183002.30410.51185.idtracker@localhost> <98A16B2D00B5724F81E80EF1927A029703FC95@nasanexd01e.na.qualcomm.com> <31963_1297088150_4D4FFE96_31963_99436_1_94C682931C08B048B7A8645303FDC9F33C44015A86@PUEXCB1B.nanterre.francetelecom.fr> <12200_1297333968_4D53BED0_12200_36165_1_94C682931C08B048B7A8645303FDC9F33C443B8C0C@PUEXCB1B.nanterre.francetelecom.fr> <31963_1297428940_4D5531CC_31963_380837_1_94C682931C08B048B7A8645303FDC9F33C443B925D@PUEXCB1B.nanterre.francetelecom.fr> <3155_1297666425_4D58D179_3155_247779_1_94C682931C08B048B7A8645303FDC9F33C443B9542@PUEXCB1B.nanterre.francetelecom.fr> <205ED2FF-1B67-4F9B-9A0D-1C97487D6776@juniper.net> Date: Tue, 15 Feb 2011 14:24:15 -0800 Message-ID: From: Julien Laganier To: Alain Durand Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Julien Laganier , "int-area@ietf.org" , "draft-ietf-intarea-server-logging-recommendations@tools.ietf.org" , Vogt , "Christian@core3.amsl.com" Subject: Re: [Int-area] I-D Action:draft-ietf-intarea-server-logging-recommendations-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 22:23:51 -0000 Folks, The WGLC for this draft has concluded. Med made proposed some modifications but there was no consensus to change the draft thus we considered that this draft reflects WG consensus and we will forward to IESG for publication. --julien On Tue, Feb 15, 2011 at 1:04 AM, Alain Durand wrote: > > On Feb 14, 2011, at 1:53 AM, wrote: > >> Dear Julien, >> >> This is fair but IP-related information is conveyed sometimes at the app= lication layer. I provided XFF as an example, other application-specific he= aders can be considered for other internet-facing servers (e.g., SIP/SPTM/e= tc.). >> >> Having something like the following in the I-D would be fine with me: >> >> "Note that information about the identity of the source (e.g., source IP= address, source port number) can be leaked in the application payload. It = is encouraged to log this information too." >> > > > Again, this was discussed and ruled out of scope. > > =A0- Alain. From jyoti.yaduwanshi@gmail.com Mon Feb 21 01:10:03 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DE103A6FFD for ; Mon, 21 Feb 2011 01:10:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9m3MnhWBAGr for ; Mon, 21 Feb 2011 01:09:59 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id D5F7E3A6F68 for ; Mon, 21 Feb 2011 01:09:58 -0800 (PST) Received: by iwl42 with SMTP id 42so2777730iwl.31 for ; Mon, 21 Feb 2011 01:10:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=P9g76idbIgfC/6nEA4mpv/Kuu22zEyFmCM0xFEy6tH0=; b=keC5aXFRap3YHJ6XhR72LUYdA5ESM2N4thtC3kiEkObeLfcUq2oi4oK+qkBAk6jUeR e0X+o9XxL3h22X6nTlwqUGZISRX7NSp9zL0QLdMcmyr2PelOhvy+GSWqmUo5CMiHO0A9 Ptq/+liRJGu8g3sLPdDpaJbs5MLM86sBzu52U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=v/2owMUmv9/311ep9mU5IPmGIy+HcXB1ZtulPZvUAaLkP43qPGFQgKvVQXx8sXOYOq hHaoxHdlzi0hxq7bRMNHJQqzz9X42bGdpexwjQIhnh5E664GrCMY+bO4WNp+2EEa7kKP 2HmZC4wB9Of0hb4FSjWDoEOSCDjDT8Mb24vXM= MIME-Version: 1.0 Received: by 10.231.59.213 with SMTP id m21mr1003596ibh.24.1298279439905; Mon, 21 Feb 2011 01:10:39 -0800 (PST) Received: by 10.231.37.4 with HTTP; Mon, 21 Feb 2011 01:10:39 -0800 (PST) In-Reply-To: References: Date: Mon, 21 Feb 2011 14:40:39 +0530 Message-ID: From: Jyoti Yaduwanshi To: int-area@ietf.org Content-Type: multipart/alternative; boundary=001485e7e948d5b902049cc73c68 X-Mailman-Approved-At: Mon, 21 Feb 2011 09:24:59 -0800 Subject: [Int-area] Problem with RSVP Authentication - RFC 2747 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 09:11:12 -0000 --001485e7e948d5b902049cc73c68 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi We are implementing RSVP Authentication as per RFC 2747. But there are few issues which are not clearly described in the RFC hence we believe that the= y will cause interoperability issues. Issues are described as below 1. Generation of Key Identifier =96 The RFC does not mention exact steps= a node should execute to generate the Key Identifier and hence leaving ambiguity in the whole process. In an environment when the two nodes fro= m two separate vendors will have issues with authentication as computation= of the key identifier will differ on both the nodes. Please guide as to what should be done to address this issue. 1. We also couldn=92t find definite answer to the problem which occurs w= hen a node on which authentication is enabled, and receives a non-authentica= ted packet. What should be done in such cases? Please provide an insight on the above two queries so that we can address them in our design. Thanks in advance Jyoti --001485e7e948d5b902049cc73c68 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi

=A0

We are implementing RSVP=20 Authentication as per RFC 2747. But there are few issues which are not clea= rly=20 described in the RFC hence we believe that they will cause interoperability= =20 issues.

=A0

Issues are described as=20 below

=A0

  1. Generation of Key=20 Identifier =96 The RFC does not mention exact steps a node should execute t= o=20 generate the Key Identifier and hence leaving ambiguity in the whole proces= s. In=20 an environment when the two nodes from two separate vendors will have issue= s=20 with authentication as computation of the key identifier will differ on bot= h the=20 nodes.

Please guid= e as to what should be=20 done to address this issue.

=A0<= /font>

  1. We also couldn=92t find=20 definite answer to the problem which occurs when a node on which authentica= tion=20 is enabled, and receives a non-authenticated packet. What should be done in= such=20 cases?

=A0

Please provide an insight on the=20 above two queries so that we can address them in our=20 design.

=A0

=A0

Thanks in=20 advance

Jyoti


--001485e7e948d5b902049cc73c68-- From Internet-Drafts@ietf.org Mon Feb 21 23:30:02 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD9F33A6811; Mon, 21 Feb 2011 23:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.626 X-Spam-Level: X-Spam-Status: No, score=-102.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHmn5TrOBoCk; Mon, 21 Feb 2011 23:30:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3DC73A67ED; Mon, 21 Feb 2011 23:30:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110222073001.7676.91686.idtracker@localhost> Date: Mon, 21 Feb 2011 23:30:01 -0800 Cc: int-area@ietf.org Subject: [Int-area] I-D Action:draft-ietf-intarea-shared-addressing-issues-04.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 07:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Area Working Group Working Group of the IETF. Title : Issues with IP Address Sharing Author(s) : M. Ford, et al. Filename : draft-ietf-intarea-shared-addressing-issues-04.txt Pages : 30 Date : 2011-02-21 The completion of IPv4 address allocations from IANA and the RIRs is causing service providers around the world to question how they will continue providing IPv4 connectivity service to their subscribers when there are no longer sufficient IPv4 addresses to allocate them one per subscriber. Several possible solutions to this problem are now emerging based around the idea of shared IPv4 addressing. These solutions give rise to a number of issues and this memo identifies those common to all such address sharing approaches. Such issues include application failures, additional service monitoring complexity, new security vulnerabilities and so on. Solution- specific discussions are out of scope. Deploying IPv6 is the only perennial way to ease pressure on the public IPv4 address pool without the need for address sharing mechanisms that give rise to the issues identified herein. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-intarea-shared-addressing-issues-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-intarea-shared-addressing-issues-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-21232032.I-D@ietf.org> --NextPart-- From julien.ietf@gmail.com Tue Feb 22 15:45:38 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 189943A6985 for ; Tue, 22 Feb 2011 15:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2W5mRTy33DUl for ; Tue, 22 Feb 2011 15:45:37 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 9DF853A6983 for ; Tue, 22 Feb 2011 15:45:36 -0800 (PST) Received: by fxm15 with SMTP id 15so4295616fxm.31 for ; Tue, 22 Feb 2011 15:46:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:cc :content-type; bh=y46dFzvPRAOlAlKvLORbATaTLa7GwWHMxuf8P3iuZ4E=; b=MedaFrLMbxUh7pbYaOrIUK4rVudtxTTvxdnUaVptNhbgzBY8rWbi/I9X1bmNNhAzhl G8mB/qnbwzfnnJBfCPMEvOFIadwILffyTf8BOT+vTUXOqMBnigjHKWGUiDqPtFFOHvEs /I+dbmH+9xr9GzPR9AbMvfYnqM8iQsBWq6V4A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:cc:content-type; b=E69TM4fwUVgWWmIHWMG1v+aB5HxnQtk2Ej/lZsQH+VBJXtH9UJmYYCcj6G4t1mFAeC hZsbQEm0hIsikWHMv0RPfatGoLwBd6076Bdj2/o4yexfAxFjcQQil1J3FxsU8nBhKmR8 kzSxwxtx7aec7ocTr+cl4/0jS73UO/BsFYFWM= MIME-Version: 1.0 Received: by 10.223.74.15 with SMTP id s15mt31734faj.28.1298418334038; Tue, 22 Feb 2011 15:45:34 -0800 (PST) Received: by 10.223.74.142 with HTTP; Tue, 22 Feb 2011 15:45:34 -0800 (PST) Date: Tue, 22 Feb 2011 16:45:34 -0700 Message-ID: From: Julien Laganier Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-intarea-server-logging-recommendations.all@tools.ietf.org, int-area@ietf.org Subject: [Int-area] Request to publish draft-ietf-intarea-server-logging-recommendations-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 23:45:38 -0000 Secretariat (BCC'd): This is a request to publish draft-ietf-intarea-server-logging-recommendations-02. Please find below the I-D write-up. --julien ----------------------------------------------------------------------------------------- (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Julien Laganier is the document shepherd for this document. He has personally reviewed this version of the document and believes it is ready for forwarding to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has had adequate reviews by key WG members.The document shepherd does not have any concerns regarding the depth or breadth of the reviews received. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? The document shepherd has no such concerns. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. The document shepherd has no such concerns. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is solid WG consensus behind this document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No threats of appeal or extreme discontent have been expressed regarding this document. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The document shepherd has personally verified that the document satisfies all ID nits. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. References are split into normative and informative sections. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? This document has an IANA considerations section and no IANA considerations that needs to be taken care of. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? There are no such sections. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary In the wake of IPv4 exhaustion and deployment of IP address sharing techniques, this document recommends that Internet facing servers log port number and accurate timestamps in addition to the incoming IP address. Working Group Summary There is solid WG consensus behind the recommendation being made by this document Document Quality The recommendation is already implemented in a certain number of situations. From julien.ietf@gmail.com Thu Feb 24 16:02:26 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2DC63A688A for ; Thu, 24 Feb 2011 16:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.908 X-Spam-Level: X-Spam-Status: No, score=-2.908 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTvcz0mad89R for ; Thu, 24 Feb 2011 16:02:26 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id A745D3A635F for ; Thu, 24 Feb 2011 16:02:25 -0800 (PST) Received: by fxm15 with SMTP id 15so1174871fxm.31 for ; Thu, 24 Feb 2011 16:03:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=D5I40WuIRQ3jPAEZ74kkeD2xtJEXNSCrjk+qkMvrOmY=; b=czvm0weaQxf2WcwFMiP5AFL2Fd8PpgWKHqSc3i0OaGcnd7lXMQZA7u06Q0I+k1ozKN 8O8JSWcUxxaSJ/pqK8Mn87kY/3UDkiwGTw9kKfhJ9DPL2YFO4KmKg3JtVktw1iIsDLAO H5VaEX/bj0feaOS3o8chi4InsbU/haMEnF5z0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=M0Xzf3Swc3d6S3BAORIyzuVZMIE9UXeQ5YnxITJ0220iGaNU6TTv8WJHYgtwmAYXZl k4zfjGAplDSWY594FkVnZU84yDBLqAZxTu8ifZk1DzCNaR+xYv/KzpxRhq5/fNME8i3/ L6azUR7Dm/9VRT3hZg8S7M61f+XcHI5GbrDGY= MIME-Version: 1.0 Received: by 10.223.71.200 with SMTP id i8mr1756826faj.142.1298592051216; Thu, 24 Feb 2011 16:00:51 -0800 (PST) Received: by 10.223.74.142 with HTTP; Thu, 24 Feb 2011 16:00:51 -0800 (PST) In-Reply-To: <20110224224534.D8FC63A6877@core3.amsl.com> References: <20110224224534.D8FC63A6877@core3.amsl.com> Date: Thu, 24 Feb 2011 17:00:51 -0700 Message-ID: From: Julien Laganier To: int-area@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: intarea-ads@tools.ietf.org, intarea-chairs@tools.ietf.org Subject: [Int-area] Fwd: INTAREA - Requested session has been scheduled for IETF 80 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 00:02:26 -0000 Folks, The int-area session has been scheduled and we're starting to work on the agenda. Please send slot requests to intarea-chairs@tools.ietf.org and cc: intarea-ads@tools.ietf.org Thanks, --julien ---------- Forwarded message ---------- From: IETF Secretariat Date: Thu, Feb 24, 2011 at 3:45 PM Subject: INTAREA - Requested session has been scheduled for IETF 80 To: julien.ietf@gmail.com Cc: christian.vogt@ericsson.com, rdroms.ietf@gmail.com, jari.arkko@piuha.net, session-request@ietf.org Dear Julien Laganier, The sessions that you have requested have been scheduled. Below is the scheduled session information followed by the information of sessions that you have requested. INTAREA Session 1 (2 hours) Tuesday, Afternoon Session I 1300-1500 Room Name: Congress Hall II ---------------------------------------------- Requested Information: --------------------------------------------------------- Working Group Name: intarea Area Name: Internet Area Session Requester: Julien Laganier Number of Sessions: 1 Length of Session(s): =A02 hours Number of Attendees: 200 Conflicts to Avoid: =A0First Priority: savi behave softwire v6ops 6man mext mif netext hip nete= xt =A0Second Priority: 6lowpan ancp autoconf csi dhc dnsext hip ipdvb l2tpext lisp mip4 multimob ntp pppext tictoc trill =A0tcpm tsvwg =A0BOF or IRTF Session: rrg, renum Special Requests: --------------------------------------------------------- From jari.arkko@piuha.net Fri Feb 25 04:59:00 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A131B3A69A7 for ; Fri, 25 Feb 2011 04:59:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4N6WF2uAv-sd for ; Fri, 25 Feb 2011 04:59:00 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id ABCC03A69A2 for ; Fri, 25 Feb 2011 04:58:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id DEF3D2CC2C; Fri, 25 Feb 2011 14:59:50 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPNMH18U5gHm; Fri, 25 Feb 2011 14:59:50 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 726212CC28; Fri, 25 Feb 2011 14:59:50 +0200 (EET) Message-ID: <4D67A7C6.9030905@piuha.net> Date: Fri, 25 Feb 2011 14:59:50 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: draft-ietf-intarea-server-logging-recommendations.all@tools.ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: int-area@ietf.org Subject: [Int-area] AD review of draft-ietf-intarea-server-logging-recommendations X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 12:59:00 -0000 I have reviewed this draft and I believe it is ready to move forward. IETF Last Call has been requested. But I do have two suggestions for changes, and would like to ask the authors to update the document (even during the last call that will probably start today): > According to the most recent predictions, the global IPv4 address > free pool at IANA will exhaust sometime in 2011. This could now be written in a different way. > Although the deployment of address sharing techniques is not > immediately foreseen in IPv6 I would really like to see this change: s/immediately foreseen/foreseen/ Jari From adurand@juniper.net Fri Feb 25 06:11:53 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F40F3A69D5 for ; Fri, 25 Feb 2011 06:11:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qq2QQURbsOcx for ; Fri, 25 Feb 2011 06:11:44 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id BAB2D3A69D2 for ; Fri, 25 Feb 2011 06:11:42 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTWe4xo6f0DZI23AbANX8C75ziuasV+zC@postini.com; Fri, 25 Feb 2011 06:12:35 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 25 Feb 2011 06:03:27 -0800 From: Alain Durand To: Jari Arkko Date: Fri, 25 Feb 2011 06:04:04 -0800 Thread-Topic: [Int-area] AD review of draft-ietf-intarea-server-logging-recommendations Thread-Index: AcvU9MY/SBfojzD9SX6T+NFw28iW9A== Message-ID: References: <4D67A7C6.9030905@piuha.net> In-Reply-To: <4D67A7C6.9030905@piuha.net> 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 Cc: "draft-ietf-intarea-server-logging-recommendations.all@tools.ietf.org" , "int-area@ietf.org" Subject: Re: [Int-area] AD review of draft-ietf-intarea-server-logging-recommendations X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 14:11:54 -0000 OK. New rev on its way. - Alain. On Feb 25, 2011, at 7:59 AM, Jari Arkko wrote: > I have reviewed this draft and I believe it is ready to move forward.=20 > IETF Last Call has been requested. >=20 > But I do have two suggestions for changes, and would like to ask the=20 > authors to update the document (even during the last call that will=20 > probably start today): >=20 >> According to the most recent predictions, the global IPv4 address >> free pool at IANA will exhaust sometime in 2011. >=20 > This could now be written in a different way. >=20 >> Although the deployment of address sharing techniques is not >> immediately foreseen in IPv6 > I would really like to see this change: s/immediately foreseen/foreseen/ >=20 > Jari > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From iesg-secretary@ietf.org Fri Feb 25 07:04:13 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5E763A69E8; Fri, 25 Feb 2011 07:04:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.229 X-Spam-Level: X-Spam-Status: No, score=-102.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsltNV1gKfNt; Fri, 25 Feb 2011 07:04:13 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 230A63A69C8; Fri, 25 Feb 2011 07:04:13 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110225150413.12795.84573.idtracker@localhost> Date: Fri, 25 Feb 2011 07:04:13 -0800 Cc: int-area@ietf.org Subject: [Int-area] Last Call: (Logging recommendations for Internet facing servers) to BCP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 15:04:14 -0000 The IESG has received a request from the Internet Area Working Group WG (intarea) to consider the following document: - 'Logging recommendations for Internet facing servers' as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-03-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-intarea-server-logging-recommendations/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-intarea-server-logging-recommendations/ No IPR declarations have been submitted directly on this I-D. From Internet-Drafts@ietf.org Fri Feb 25 07:15:02 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 342E33A69EB; Fri, 25 Feb 2011 07:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKBWHFV0c7wV; Fri, 25 Feb 2011 07:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CA3A3A69E2; Fri, 25 Feb 2011 07:15:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110225151501.16257.43259.idtracker@localhost> Date: Fri, 25 Feb 2011 07:15:01 -0800 Cc: int-area@ietf.org Subject: [Int-area] I-D Action:draft-ietf-intarea-server-logging-recommendations-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 15:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Area Working Group Working Group of the IETF. Title : Logging recommendations for Internet facing servers Author(s) : A. Durand, et al. Filename : draft-ietf-intarea-server-logging-recommendations-03.txt Pages : 6 Date : 2011-02-25 In the wake of IPv4 exhaustion and deployment of IP address sharing techniques, this document recommends that Internet facing servers log port number and accurate timestamps in addition to the incoming IP address. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-intarea-server-logging-recommendations-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-intarea-server-logging-recommendations-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-25071336.I-D@ietf.org> --NextPart-- From adurand@juniper.net Fri Feb 25 07:15:24 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02E283A69F4 for ; Fri, 25 Feb 2011 07:15:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8dtJbazeEJg for ; Fri, 25 Feb 2011 07:15:23 -0800 (PST) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id 17BC13A69EE for ; Fri, 25 Feb 2011 07:15:23 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTWfHug853WO0B7NWh5JMt13VWc/Oqiq5@postini.com; Fri, 25 Feb 2011 07:16:16 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 25 Feb 2011 07:14:27 -0800 From: Alain Durand To: Jari Arkko Date: Fri, 25 Feb 2011 07:15:03 -0800 Thread-Topic: [Int-area] AD review of draft-ietf-intarea-server-logging-recommendations Thread-Index: AcvU/rD/wiCKnESBQS+5TRpFxJvRWQ== Message-ID: References: <4D67A7C6.9030905@piuha.net> In-Reply-To: <4D67A7C6.9030905@piuha.net> 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 Cc: "draft-ietf-intarea-server-logging-recommendations.all@tools.ietf.org" , "int-area@ietf.org" Subject: Re: [Int-area] AD review of draft-ietf-intarea-server-logging-recommendations X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 15:15:24 -0000 -03 rev posted. Alain On Feb 25, 2011, at 7:59 AM, Jari Arkko wrote: > I have reviewed this draft and I believe it is ready to move forward.=20 > IETF Last Call has been requested. >=20 > But I do have two suggestions for changes, and would like to ask the=20 > authors to update the document (even during the last call that will=20 > probably start today): >=20 >> According to the most recent predictions, the global IPv4 address >> free pool at IANA will exhaust sometime in 2011. >=20 > This could now be written in a different way. >=20 >> Although the deployment of address sharing techniques is not >> immediately foreseen in IPv6 > I would really like to see this change: s/immediately foreseen/foreseen/ >=20 > Jari > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From jari.arkko@piuha.net Fri Feb 25 09:43:57 2011 Return-Path: X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64D193A679F for ; Fri, 25 Feb 2011 09:43:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQZX35KP+Cl6 for ; Fri, 25 Feb 2011 09:43:56 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 6C08C3A6814 for ; Fri, 25 Feb 2011 09:43:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C7D6D2CC32; Fri, 25 Feb 2011 19:44:47 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRoiBtnsQOrJ; Fri, 25 Feb 2011 19:44:47 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 25DA12CC28; Fri, 25 Feb 2011 19:44:47 +0200 (EET) Message-ID: <4D67EA8E.8000805@piuha.net> Date: Fri, 25 Feb 2011 19:44:46 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Alain Durand References: <4D67A7C6.9030905@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-ietf-intarea-server-logging-recommendations.all@tools.ietf.org" , "int-area@ietf.org" Subject: Re: [Int-area] AD review of draft-ietf-intarea-server-logging-recommendations X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 17:43:57 -0000 Alain, Thank you for your very quick action on this. Jari