From nemo-bounces@ietf.org Mon Aug 01 09:40:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzaXI-0002T1-96; Mon, 01 Aug 2005 09:40:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzaXG-0002RK-90; Mon, 01 Aug 2005 09:40:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08900; Mon, 1 Aug 2005 09:40:52 -0400 (EDT) Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzb3X-000166-11; Mon, 01 Aug 2005 10:14:16 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id j71DlJqh018513; Mon, 1 Aug 2005 06:47:19 -0700 (MST) Received: from [10.182.10.14] (mvp-10-182-10-14.am.mot.com [10.182.10.14]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id j71DkVQx007808; Mon, 1 Aug 2005 08:46:32 -0500 (CDT) Message-ID: <42EE265A.1040202@motorola.com> Date: Mon, 01 Aug 2005 15:40:42 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: "Bound, Jim" Subject: Re: [nemo] v4 traversal slides References: <936A4045C332714F975800409DE09240B31546@tayexc14.americas.cpqcorp.net> In-Reply-To: <936A4045C332714F975800409DE09240B31546@tayexc14.americas.cpqcorp.net> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Bound, Jim wrote: > Folks, > > I think we need to at least address and discuss the scenario where > the HA is on IPv6-Dominant network, meaning IPv4 routing has been > shut off per policy of the user on that network. The MN shows up on > IPv4-Only access network. Bi-directional commo is required between > MN and HA, but MN has entered IPv4 net. We need to consider this in > our scenarios. I have communicated this to some and talking with > Pascal T. This is a real scenario that is being planned today by > several large enterpises. The above scenario (IPv6 MN on an IPv4 network, its HA on an IPv6-only network) is very relevant. A traversal protocol where an intermediary box ("gateway"?) is on both v4 and v6 is necessary. Alex From nemo-bounces@ietf.org Tue Aug 02 03:57:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzreu-0002vf-IN; Tue, 02 Aug 2005 03:57:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzres-0002tn-Pp for nemo@megatron.ietf.org; Tue, 02 Aug 2005 03:57:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28065 for ; Tue, 2 Aug 2005 03:57:52 -0400 (EDT) Received: from node-402449f2.sfo.onnet.us.uu.net ([64.36.73.242] helo=multihop.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzsBI-0000rZ-VK for nemo@ietf.org; Tue, 02 Aug 2005 04:31:26 -0400 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id 8A9996233 for ; Tue, 2 Aug 2005 00:57:08 -0700 (PDT) Received: from multihop.net ([127.0.0.1]) by localhost (deimos.multihop.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98798-16 for ; Tue, 2 Aug 2005 00:57:00 -0700 (PDT) Received: by deimos.multihop.net (Postfix, from userid 1013) id C30DF61C4; Tue, 2 Aug 2005 00:57:00 -0700 (PDT) Received: from [86.255.30.62] (open-30-62.ietf63.ietf.org [86.255.30.62]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id 283F660ED for ; Tue, 2 Aug 2005 00:56:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v733) To: nemo WG Message-Id: <0D73ED1E-6BDB-448D-8EEC-2B0C41D11B11@kniveton.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7-780838336; protocol="application/pkcs7-signature" From: "T.J. Kniveton" Date: Tue, 2 Aug 2005 09:57:22 +0200 X-Mailer: Apple Mail (2.733) X-Spam-Score: -2.7 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on deimos.multihop.net X-Spam-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.4 X-Virus-Scanned: amavisd-new at multihop.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [nemo] Anyone participating remotely? X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --Apple-Mail-7-780838336 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi, Is anyone planning to participate remotely? Please say if you are planning on using Jabber, listening to the audio stream, and if you are interested in a video stream? -TJ --Apple-Mail-7-780838336 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEEjCCBA4w ggN3oAMCAQICAQgwDQYJKoZIhvcNAQEEBQAwgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxp Zm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3Jr czEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5t dWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9wLm5ldDAeFw0wMzExMjIwMDMw MjZaFw0wODExMjAwMDMwMjZaMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEW MBQGA1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxGjAYBgNV BAsTEU1haWwgU2VuZGluZyBVbml0MRYwFAYDVQQDEw1ULkouIEtuaXZldG9uMR4wHAYJKoZIhvcN AQkBFg90akBrbml2ZXRvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMOyGVi3ZeqI A+thWuShiTnHWEBAOCPlbsX6nSssNdB4QNZWRmZfBr5I2Okj/E5flongKGToDI17j1aIakZ/FIkA +2gvTBxonCFvtySFn7sQ9JYVkw8QCFopEEvug3TTxGqsc3UfvFUgpEQ0berx4juC6bCRZoFey5Ss A68nqs9hAgMBAAGjggExMIIBLTAJBgNVHRMEAjAAMBgGCWCGSAGG+EIBDQQLFglUcnVzdCBtZS4w HQYDVR0OBBYEFJ9elKRQr9QN4AlUWPuDDDd+30e7MIHmBgNVHSMEgd4wgduAFOQDibOvWu1mlL3o 8nqpjMsx+Q5GoYG/pIG8MIG5MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQG A1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxJjAkBgNVBAsT HVNlY3VyaXR5IEluZnJhc3RydWN0dXJlIEdyb3VwMRkwFwYDVQQDExBpaW8ubXVsdGlob3AubmV0 MR4wHAYJKoZIhvcNAQkBFg9jYUBtdWx0aWhvcC5uZXSCAQAwDQYJKoZIhvcNAQEEBQADgYEAThZg UzZQwvrd6ysmFdzYC8mnfrKBiM80IOzh9o3/ZywlfduKhl70Z92WEFt8/KA3Tehu16YHm/FN0RCj DqA8agRMj0b/bjIPGxhX4QfJU/ADdhuGw+ZCPBaK3d+rbS/4+j7hCavSwqtnvXOCN7KYj+KkPm21 e8OBM6rS/wFtxYgxggNvMIIDawIBATCBvzCBuTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlm b3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28xGjAYBgNVBAoTEU11bHRpaG9wIE5ldHdvcmtz MSYwJAYDVQQLEx1TZWN1cml0eSBJbmZyYXN0cnVjdHVyZSBHcm91cDEZMBcGA1UEAxMQaWlvLm11 bHRpaG9wLm5ldDEeMBwGCSqGSIb3DQEJARYPY2FAbXVsdGlob3AubmV0AgEIMAkGBSsOAwIaBQCg ggIFMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA1MDgwMjA3NTcy M1owIwYJKoZIhvcNAQkEMRYEFJ5+8SzMBgmvYpLybmubmFGD7QxAMIHQBgkrBgEEAYI3EAQxgcIw gb8wgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJh bmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5m cmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0B CQEWD2NhQG11bHRpaG9wLm5ldAIBCDCB0gYLKoZIhvcNAQkQAgsxgcKggb8wgbkxCzAJBgNVBAYT AlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQK ExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3Jv dXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9w Lm5ldAIBCDANBgkqhkiG9w0BAQEFAASBgE7u+YFb8Ypj33nkqi42eBn3JUV48xQpHFQvcHkfflNu cjbU31tP8XGo3OR+GlwdKfvbd72xVg2LlGpaTU2cVhVZyy2H0b5W4etsTodR3sYj52ESNuDyQwQq 50PUdqt6RXgQSucYP+y5FMxWVZzIaXWoB6fqdzBwA0oau0UJfGnEAAAAAAAA --Apple-Mail-7-780838336-- From nemo-bounces@ietf.org Tue Aug 02 04:03:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzrkW-0004Rt-5Q; Tue, 02 Aug 2005 04:03:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzrkU-0004Rb-Ep for nemo@megatron.ietf.org; Tue, 02 Aug 2005 04:03:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28310 for ; Tue, 2 Aug 2005 04:03:40 -0400 (EDT) Received: from node-402449f2.sfo.onnet.us.uu.net ([64.36.73.242] helo=multihop.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzsGu-00018a-Os for nemo@ietf.org; Tue, 02 Aug 2005 04:37:14 -0400 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id 1726D6233 for ; Tue, 2 Aug 2005 01:03:08 -0700 (PDT) Received: from multihop.net ([127.0.0.1]) by localhost (deimos.multihop.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98798-20 for ; Tue, 2 Aug 2005 01:03:00 -0700 (PDT) Received: by deimos.multihop.net (Postfix, from userid 1013) id 5913361C4; Tue, 2 Aug 2005 01:03:00 -0700 (PDT) Received: from [86.255.30.62] (open-30-62.ietf63.ietf.org [86.255.30.62]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id B62B960ED for ; Tue, 2 Aug 2005 01:02:59 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v733) To: nemo WG Message-Id: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-9-781203332; protocol="application/pkcs7-signature" From: "T.J. Kniveton" Date: Tue, 2 Aug 2005 10:03:27 +0200 X-Mailer: Apple Mail (2.733) X-Spam-Score: -2.7 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on deimos.multihop.net X-Spam-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.4 X-Virus-Scanned: amavisd-new at multihop.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: [nemo] Minute takers X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --Apple-Mail-9-781203332 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi, can we have 2 volunteers to take minutes during the meeting tomorrow? Thanks. TJ --Apple-Mail-9-781203332 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEEjCCBA4w ggN3oAMCAQICAQgwDQYJKoZIhvcNAQEEBQAwgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxp Zm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3Jr czEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5t dWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9wLm5ldDAeFw0wMzExMjIwMDMw MjZaFw0wODExMjAwMDMwMjZaMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEW MBQGA1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxGjAYBgNV BAsTEU1haWwgU2VuZGluZyBVbml0MRYwFAYDVQQDEw1ULkouIEtuaXZldG9uMR4wHAYJKoZIhvcN AQkBFg90akBrbml2ZXRvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMOyGVi3ZeqI A+thWuShiTnHWEBAOCPlbsX6nSssNdB4QNZWRmZfBr5I2Okj/E5flongKGToDI17j1aIakZ/FIkA +2gvTBxonCFvtySFn7sQ9JYVkw8QCFopEEvug3TTxGqsc3UfvFUgpEQ0berx4juC6bCRZoFey5Ss A68nqs9hAgMBAAGjggExMIIBLTAJBgNVHRMEAjAAMBgGCWCGSAGG+EIBDQQLFglUcnVzdCBtZS4w HQYDVR0OBBYEFJ9elKRQr9QN4AlUWPuDDDd+30e7MIHmBgNVHSMEgd4wgduAFOQDibOvWu1mlL3o 8nqpjMsx+Q5GoYG/pIG8MIG5MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQG A1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxJjAkBgNVBAsT HVNlY3VyaXR5IEluZnJhc3RydWN0dXJlIEdyb3VwMRkwFwYDVQQDExBpaW8ubXVsdGlob3AubmV0 MR4wHAYJKoZIhvcNAQkBFg9jYUBtdWx0aWhvcC5uZXSCAQAwDQYJKoZIhvcNAQEEBQADgYEAThZg UzZQwvrd6ysmFdzYC8mnfrKBiM80IOzh9o3/ZywlfduKhl70Z92WEFt8/KA3Tehu16YHm/FN0RCj DqA8agRMj0b/bjIPGxhX4QfJU/ADdhuGw+ZCPBaK3d+rbS/4+j7hCavSwqtnvXOCN7KYj+KkPm21 e8OBM6rS/wFtxYgxggNvMIIDawIBATCBvzCBuTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlm b3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28xGjAYBgNVBAoTEU11bHRpaG9wIE5ldHdvcmtz MSYwJAYDVQQLEx1TZWN1cml0eSBJbmZyYXN0cnVjdHVyZSBHcm91cDEZMBcGA1UEAxMQaWlvLm11 bHRpaG9wLm5ldDEeMBwGCSqGSIb3DQEJARYPY2FAbXVsdGlob3AubmV0AgEIMAkGBSsOAwIaBQCg ggIFMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA1MDgwMjA4MDMy OFowIwYJKoZIhvcNAQkEMRYEFKfIpf3jnwAQ7EEGPc54xqTAXi40MIHQBgkrBgEEAYI3EAQxgcIw gb8wgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJh bmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5m cmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0B CQEWD2NhQG11bHRpaG9wLm5ldAIBCDCB0gYLKoZIhvcNAQkQAgsxgcKggb8wgbkxCzAJBgNVBAYT AlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQK ExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3Jv dXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9w Lm5ldAIBCDANBgkqhkiG9w0BAQEFAASBgJ6QtOsP7AG0ELXGPflADvEgc4Dr8H1dG3otsU3BXVu9 NKL/exSRVFTAXMj6VNcv+AFTqkq5QBr4gomF+rJE8UQwrEbWVEfLPZgUe8FG8LuYTrLYiJA85HwQ 3pZ6LtswJtdj9rW5bHCtsGZow6oKm1sdDhguYea/voZ8ibYzRZ5UAAAAAAAA --Apple-Mail-9-781203332-- From nemo-bounces@ietf.org Mon Aug 08 09:01:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E27FZ-0004Mn-ET; Mon, 08 Aug 2005 09:01:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E27FX-0004MI-FB; Mon, 08 Aug 2005 09:01:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18888; Mon, 8 Aug 2005 09:01:01 -0400 (EDT) Received: from omgo.iij.ad.jp ([202.232.30.157]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E27nD-0007C2-37; Mon, 08 Aug 2005 09:35:53 -0400 Received: OTM-MO id j78D0n7x004442; Mon, 8 Aug 2005 22:00:49 +0900 (JST) Received: OTM-MIX0 id j78D0mrH009510; Mon, 8 Aug 2005 22:00:48 +0900 (JST) Received: from localhost (jc-ssh.iij.ad.jp [192.168.174.22]) by jc-smtp.iij.ad.jp (JC-SMTP/jc-smtp) id j78D0k9u019002; Mon, 8 Aug 2005 22:00:47 +0900 (JST) Date: Mon, 08 Aug 2005 15:00:50 +0200 (CEST) Message-Id: <20050808.150050.259287104.keiichi@iijlab.net> To: mip6@ietf.org, nemo@ietf.org From: Keiichi SHIMA X-Mailer: Mew version 4.2.53 on Emacs 22.0.50 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: Subject: [nemo] carrying IPv4 traffic using MIP6/NEMO X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi all, At the IETF MIP6 WG session, the design team talked about the mechanism to bind an IPv4 home address to an IPv6 care-of address as a transission mechanism. I have submitted very similar mechanism for IPv4 networks as draft-shima-nemo-v4prefix-00.txt, which binds IPv4 prefixes to an IPv6 care-of address of a mobile router and provides IPv4 mobile network functionarity on top of NEMO. I wonder if we should consider to integrate these two mechanism to provide a single way to provide the mechanism to carry IPv4 traffic for both a mobile host and a mobile router. What do you think? --- Keiichi SHIMA IIJ Research Laboratory KAME Project From nemo-bounces@ietf.org Mon Aug 08 09:59:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E289g-0003QU-Og; Mon, 08 Aug 2005 09:59:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E289e-0003PQ-Cl; Mon, 08 Aug 2005 09:59:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21764; Mon, 8 Aug 2005 09:59:00 -0400 (EDT) Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E28hL-0000Je-N3; Mon, 08 Aug 2005 10:33:53 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id j78E5WHK010234; Mon, 8 Aug 2005 07:05:37 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id j78E6uJK010803; Mon, 8 Aug 2005 09:06:58 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 019AF865980; Mon, 8 Aug 2005 15:58:48 +0200 (CEST) Message-ID: <42F76517.8050502@motorola.com> Date: Mon, 08 Aug 2005 15:58:47 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Keiichi SHIMA Subject: Re: [nemo] carrying IPv4 traffic using MIP6/NEMO References: <20050808.150050.259287104.keiichi@iijlab.net> In-Reply-To: <20050808.150050.259287104.keiichi@iijlab.net> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello Keiichi, Keiichi SHIMA wrote: > At the IETF MIP6 WG session, the design team talked about the > mechanism to bind an IPv4 home address to an IPv6 care-of address as a > transission mechanism. > > I have submitted very similar mechanism for IPv4 networks as > draft-shima-nemo-v4prefix-00.txt, which binds IPv4 prefixes to an IPv6 > care-of address of a mobile router and provides IPv4 mobile network > functionarity on top of NEMO. > > I wonder if we should consider to integrate these two mechanism to > provide a single way to provide the mechanism to carry IPv4 traffic > for both a mobile host and a mobile router. > > What do you think? Generally it looks like an interesting idea. Why restraining the binding to a fixed /32 full v4 address when binding a variable prefix (1...32) could bring the benefit of giving v4 access to all nodes in the moving network (not only to the MR). So this may look as an obvious advantage. However, I was wondering how much would this addition extend the current scope of the DT work, whose goal was mainly to give v6 (not v4) access to MR and mobile nodes when MR connects to a v4 network. Giving continuous v4 access to mobile nodes in a moving network whose MR connects to a v4 access network can naturally be obtained by running Mobile IPv4 on the MR, too. What does the DT think? IMHO. Alex From nemo-bounces@ietf.org Mon Aug 08 10:53:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E290c-0003jp-1n; Mon, 08 Aug 2005 10:53:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E290a-0003jh-2u; Mon, 08 Aug 2005 10:53:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26378; Mon, 8 Aug 2005 10:53:41 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E29YI-0001yg-1Z; Mon, 08 Aug 2005 11:28:35 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 8 Aug 2005 10:53:27 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] carrying IPv4 traffic using MIP6/NEMO Date: Mon, 8 Aug 2005 10:53:27 -0400 Message-ID: Thread-Topic: [nemo] carrying IPv4 traffic using MIP6/NEMO Thread-Index: AcWcIbYL/CtaHmsZR0GsgMV1aBY/fwABuMjQ From: "Soliman, Hesham" To: "Alexandru Petrescu" , "Keiichi SHIMA" X-OriginalArrivalTime: 08 Aug 2005 14:53:27.0963 (UTC) FILETIME=[EF6FBEB0:01C59C28] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org >=20 > Generally it looks like an interesting idea. Why restraining the > binding to a fixed /32 full v4 address when binding a variable prefix > (1...32) could bring the benefit of giving v4 access to all=20 > nodes in the > moving network (not only to the MR). So this may look as an obvious > advantage. >=20 > However, I was wondering how much would this addition extend=20 > the current > scope of the DT work, whose goal was mainly to give v6 (not=20 > v4) access > to MR and mobile nodes when MR connects to a v4 network. >=20 > Giving continuous v4 access to mobile nodes in a moving=20 > network whose MR > connects to a v4 access network can naturally be obtained by running > Mobile IPv4 on the MR, too. >=20 > What does the DT think? =3D> We discussed this and I had extended draft-soliman to represent the IP address as : address/prefixlen, where prefixlen is anything up to 32. It's a useful feature that only adds another 5 mins of work so = why not.=20 Hesham =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D From nemo-bounces@ietf.org Mon Aug 08 11:12:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E29IR-0000cB-Vn; Mon, 08 Aug 2005 11:12:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E29IO-0000bc-Vo; Mon, 08 Aug 2005 11:12:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27448; Mon, 8 Aug 2005 11:12:06 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E29q3-0002XT-6A; Mon, 08 Aug 2005 11:47:00 -0400 Received: from [192.168.0.11] (p4080-ipbf903marunouchi.tokyo.ocn.ne.jp [58.88.27.80]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 4F1064C63D; Tue, 9 Aug 2005 00:11:31 +0900 (JST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7BFD95A3-59C8-4AA5-98DC-C81AE00379CB@sfc.wide.ad.jp> Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Subject: Re: [nemo] carrying IPv4 traffic using MIP6/NEMO Date: Tue, 9 Aug 2005 00:11:28 +0900 To: "Soliman, Hesham" X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, mip6@ietf.org, Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello Hesham I thought you were opposed to support NEMOv4 during the discussion in DT. Are there any big differences between draft-soliman(w/prefixlen) and draft-keiichi for NEMO support? regards, ryuji On 2005/08/08, at 23:53, Soliman, Hesham wrote: >> >> Generally it looks like an interesting idea. Why restraining the >> binding to a fixed /32 full v4 address when binding a variable prefix >> (1...32) could bring the benefit of giving v4 access to all >> nodes in the >> moving network (not only to the MR). So this may look as an obvious >> advantage. >> >> However, I was wondering how much would this addition extend >> the current >> scope of the DT work, whose goal was mainly to give v6 (not >> v4) access >> to MR and mobile nodes when MR connects to a v4 network. >> >> Giving continuous v4 access to mobile nodes in a moving >> network whose MR >> connects to a v4 access network can naturally be obtained by running >> Mobile IPv4 on the MR, too. >> >> What does the DT think? >> > > => We discussed this and I had extended draft-soliman to represent > the IP address as : address/prefixlen, where prefixlen is anything up > to 32. It's a useful feature that only adds another 5 mins of work > so why > not. > > Hesham > > =========================================================== > This email may contain confidential and privileged material for the > sole use > of the intended recipient. Any review or distribution by others > is strictly > prohibited. If you are not the intended recipient please contact > the sender > and delete all copies. > =========================================================== > > From nemo-bounces@ietf.org Mon Aug 08 13:37:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2BZH-0003dp-VK; Mon, 08 Aug 2005 13:37:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2BZG-0003dh-L5; Mon, 08 Aug 2005 13:37:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04932; Mon, 8 Aug 2005 13:37:39 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2C6z-0006Zw-NU; Mon, 08 Aug 2005 14:12:35 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 8 Aug 2005 13:37:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C59C3F.DAFA9498" Subject: RE: [nemo] carrying IPv4 traffic using MIP6/NEMO Date: Mon, 8 Aug 2005 13:37:32 -0400 Message-ID: X-MS-Has-Attach: yes Thread-Topic: [nemo] carrying IPv4 traffic using MIP6/NEMO Thread-Index: AcWcK3aqCs8bw2elSQa9ZTsg6BulqwAE43VA From: "Soliman, Hesham" To: "Ryuji Wakikawa" X-OriginalArrivalTime: 08 Aug 2005 17:37:32.0433 (UTC) FILETIME=[DB32A810:01C59C3F] X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: nemo@ietf.org, mip6@ietf.org, Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C59C3F.DAFA9498 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ryuji,=20 > I thought you were opposed to support NEMOv4 during the=20 > discussion in =20 > DT. =3D> I'm including my last email on that topic. What I was opposed to was discussing injecting routes over the tunnel in the=20 requirement because it's an orthogonal issue. >=20 > Are there any big differences between draft-soliman(w/prefixlen) > and draft-keiichi for NEMO support? =3D> I haven't read draft-keiichi but if it only adds an IPv4 prefix to the BU then there are differences, draft-soliman deals with=20 IPv4 HoAs/prefix as well as IPv4 CoAs for MIP6 and nemo.=20 Hesham >=20 > regards, > ryuji >=20 > On 2005/08/08, at 23:53, Soliman, Hesham wrote: >=20 > >> > >> Generally it looks like an interesting idea. Why restraining the > >> binding to a fixed /32 full v4 address when binding a=20 > variable prefix > >> (1...32) could bring the benefit of giving v4 access to all > >> nodes in the > >> moving network (not only to the MR). So this may look as=20 > an obvious > >> advantage. > >> > >> However, I was wondering how much would this addition extend > >> the current > >> scope of the DT work, whose goal was mainly to give v6 (not > >> v4) access > >> to MR and mobile nodes when MR connects to a v4 network. > >> > >> Giving continuous v4 access to mobile nodes in a moving > >> network whose MR > >> connects to a v4 access network can naturally be obtained=20 > by running > >> Mobile IPv4 on the MR, too. > >> > >> What does the DT think? > >> > > > > =3D> We discussed this and I had extended draft-soliman to = represent > > the IP address as : address/prefixlen, where prefixlen is=20 > anything up > > to 32. It's a useful feature that only adds another 5 mins=20 > of work =20 > > so why > > not. > > > > Hesham > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > This email may contain confidential and privileged=20 > material for the =20 > > sole use > > of the intended recipient. Any review or distribution by others =20 > > is strictly > > prohibited. If you are not the intended recipient please=20 > contact =20 > > the sender > > and delete all copies. > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > >=20 >=20 ------_=_NextPart_001_01C59C3F.DAFA9498 Content-Type: message/rfc822 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Received: from mail.flarion.com ([10.10.1.90]) by ftmailserver.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 22 Jul 2005 21:09:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Received: from mail.mobileip.jp ([203.178.140.166]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 22 Jul 2005 21:09:54 -0400 Received: from mobilegravity.sfc.wide.ad.jp (localhost [127.0.0.1]) by mail.mobileip.jp (Postfix) with ESMTP id B4A5264F2B; Sat, 23 Jul 2005 10:55:12 +0900 (JST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by mail.mobileip.jp (Postfix) with ESMTP id D72E864F27 for ; Sat, 23 Jul 2005 10:55:11 +0900 (JST) Received: from ftmailserver.flariontech.com ([10.10.1.140]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 22 Jul 2005 21:09:50 -0400 Content-class: urn:content-classes:message Subject: RE: [Mip6trans] Requirements 6 and 8 Date: Fri, 22 Jul 2005 21:09:50 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6trans] Requirements 6 and 8 Thread-Index: AcWO6UikaebrpZ8yR0mt1qFmA6oPCAAOb7OA List-Help: List-Subscribe: , List-Unsubscribe: , From: "Soliman, Hesham" Sender: To: "Vijay Devarapalli" , Content-Transfer-Encoding: quoted-printable > requirement 6 was about whether we should provide support > for IPv4 sessions initiated by the MN/MR without having > to use MIPv4. I guess everybody agrees that using MIPv4 > and MIPv6 at the same time is not a good idea. so if a > MIPv6 MN or a NEMO MR, irrespective of whether it is on > an IPv4 or an IPv6 access network, wants to setup an IPv4 > session with a CN we should enable it through our > mip6trans tunnel. the problem is described very clearly in > http://people.nokia.net/vijayd/mip6trans/relevant_drafts/draf > t-tsirtsis-dsmip-problem-01.txt > IMO, we should address requirement 6. =3D> Sure. >=20 > requirement 8 is about extending this to the MNNs in the > mobile network, so that the MNNs can also setup IPv4 > sessions with their CNs. this does not mean we are doing > a NEMO solution for IPv4, just using NEMO IPv6 solution > for IPv4 mobile networks too. currently NEMO assumes IPv6 > mobile network prefix. for requirement 8, we assume there > is an IPv4 mobile network prefix in addition and we are > able to carry the IPv4 traffic from the MNN to its CN over > the tunnel between the MR and the HA. >=20 > we can address requirement 8 either here in this design > team or separately. I am tending towards doing it > separately. =3D> Fine with me either way. My only comment was that the=20 requirement should not take about injecting routes because it's an orthogonal issue. Hesham >=20 > Ryuji, Hesham, does this sound good? >=20 > Vijay > _______________________________________________ > Mip6trans mailing list > Mip6trans@mobileip.jp > http://www.mobileip.jp/mailman/listinfo/mip6trans >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6trans mailing list Mip6trans@mobileip.jp http://www.mobileip.jp/mailman/listinfo/mip6trans ------_=_NextPart_001_01C59C3F.DAFA9498-- From nemo-bounces@ietf.org Mon Aug 08 15:50:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2DdS-0003xO-ON; Mon, 08 Aug 2005 15:50:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2DdK-0003qQ-N6; Mon, 08 Aug 2005 15:50:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13713; Mon, 8 Aug 2005 15:50:00 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2EB5-00029H-GJ; Mon, 08 Aug 2005 16:24:56 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E2DdJ-0003lm-Bd; Mon, 08 Aug 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 08 Aug 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-dhcpv6-pd-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Mobility Working Group of the IETF. Title : DHCPv6 Prefix Delegation for NEMO Author(s) : R. Droms, P. Thubert Filename : draft-ietf-nemo-dhcpv6-pd-00.txt Pages : 8 Date : 2005-8-8 One aspect of network mobility support is the assignment of a prefix or prefixes to a mobile router (MR) for use on the links in the mobile network. DHCPv6 prefix delegation can be used for this configuration task. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-dhcpv6-pd-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-dhcpv6-pd-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-dhcpv6-pd-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-8-8132455.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-dhcpv6-pd-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-dhcpv6-pd-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-8132455.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-bounces@ietf.org Tue Aug 09 05:31:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2QSU-0007fe-8r; Tue, 09 Aug 2005 05:31:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2QSR-0007f7-Lb; Tue, 09 Aug 2005 05:31:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24519; Tue, 9 Aug 2005 05:31:37 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2R0J-00019v-4n; Tue, 09 Aug 2005 06:06:40 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j799fGpl001554; Tue, 9 Aug 2005 02:41:20 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id j799bPjI022320; Tue, 9 Aug 2005 04:37:26 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 310EF865980; Tue, 9 Aug 2005 11:31:22 +0200 (CEST) Message-ID: <42F877E9.8010304@motorola.com> Date: Tue, 09 Aug 2005 11:31:21 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [nemo] carrying IPv4 traffic using MIP6/NEMO References: In-Reply-To: X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello Hesham, Soliman, Hesham wrote: >> >> Generally it looks like an interesting idea. Why restraining the >> binding to a fixed /32 full v4 address when binding a variable >> prefix (1...32) could bring the benefit of giving v4 access to all >> nodes in the moving network (not only to the MR). So this may look >> as an obvious advantage. >> >> However, I was wondering how much would this addition extend the >> current scope of the DT work, whose goal was mainly to give v6 (not >> v4) access to MR and mobile nodes when MR connects to a v4 >> network. >> >> Giving continuous v4 access to mobile nodes in a moving network >> whose MR connects to a v4 access network can naturally be obtained >> by running Mobile IPv4 on the MR, too. >> >> What does the DT think? > > => We discussed this Great, does the DT have a requirement for giving v4 access to nodes in a moving network whose MR runs Mobile IPv6 and connects to a v4 access network? If yes, does the requirement include v4 session continuity? Does the requirement include reachability at a permanent v4 address? These aspects are important, at least for deciding on whether or not to use NAT within the moving network (see draft-shima). > and I had extended draft-soliman to represent the IP address as : > address/prefixlen, where prefixlen is anything up to 32. It's a > useful feature that only adds another 5 mins of work so why not. Hesham, did you encode the prefixlen on 8 or 5 bits? Anyways, I don't think simply adding a v4 prefixlen into a message format is as easy as it may look. Conceptually - yes, just use a prefixlen, but from there to a protocol may be a longer way. For example, what happens when MR's v4 Home Address is independent of the Mobile Network Prefix (they differ starting at the 0th bit). I think giving v4 access to nodes in the moving network would best be done by a NEMOv4 protocol. Alex From nemo-bounces@ietf.org Tue Aug 09 09:56:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2UaW-0001sW-F7; Tue, 09 Aug 2005 09:56:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2UaT-0001sL-MB; Tue, 09 Aug 2005 09:56:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07985; Tue, 9 Aug 2005 09:56:11 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2V8N-00008f-Ob; Tue, 09 Aug 2005 10:31:16 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 9 Aug 2005 09:56:03 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] carrying IPv4 traffic using MIP6/NEMO Date: Tue, 9 Aug 2005 09:56:03 -0400 Message-ID: Thread-Topic: [nemo] carrying IPv4 traffic using MIP6/NEMO Thread-Index: AcWcxR7QtS9w1k4VT/OSe8cAMOI69gAJIZfg From: "Soliman, Hesham" To: "Alexandru Petrescu" X-OriginalArrivalTime: 09 Aug 2005 13:56:03.0577 (UTC) FILETIME=[14D5E690:01C59CEA] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org > Great, does the DT have a requirement for giving v4 access=20 > to nodes in a > moving network whose MR runs Mobile IPv6 and connects to a v4 access > network? >=20 > If yes, does the requirement include v4 session continuity? Does the > requirement include reachability at a permanent v4 address? These > aspects are important, at least for deciding on whether or not to use > NAT within the moving network (see draft-shima). =3D> I think Vijay included all our requirements so far in the=20 slides in Paris. So there is nothing more than what's in those=20 slides. > Hesham, did you encode the prefixlen on 8 or 5 bits? =20 > Anyways, I don't > think simply adding a v4 prefixlen into a message format is=20 > as easy as > it may look. Conceptually - yes, just use a prefixlen, but=20 > from there > to a protocol may be a longer way. For example, what=20 > happens when MR's > v4 Home Address is independent of the Mobile Network Prefix=20 > (they differ > starting at the 0th bit). =3D> That's no different to the IPv6 case.=20 >=20 > I think giving v4 access to nodes in the moving network would best be > done by a NEMOv4 protocol. =3D> It's not about giving v4 access to those nodes, it's about=20 updating the MR's v4 home address/prefix to its current CoA.=20 What happens inside the network is not in scope of transition = mechanisms. Hesham >=20 > Alex >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D From nemo-bounces@ietf.org Tue Aug 09 10:05:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2UjO-0005YC-Nx; Tue, 09 Aug 2005 10:05:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2UjM-0005Xf-J1; Tue, 09 Aug 2005 10:05:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08538; Tue, 9 Aug 2005 10:05:22 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2VHH-0000Nm-KQ; Tue, 09 Aug 2005 10:40:27 -0400 Received: from az33exr04.mot.com ([10.64.251.234]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j79EFGhW020779; Tue, 9 Aug 2005 07:15:16 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id j79EA1Rs003015; Tue, 9 Aug 2005 09:10:02 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 81648865980; Tue, 9 Aug 2005 16:05:20 +0200 (CEST) Message-ID: <42F8B820.1040607@motorola.com> Date: Tue, 09 Aug 2005 16:05:20 +0200 From: Alexandru Petrescu Organization: Motorola Labs, Paris, France User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [nemo] carrying IPv4 traffic using MIP6/NEMO References: In-Reply-To: X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, mip6@ietf.org, Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Soliman, Hesham wrote: >> Great, does the DT have a requirement for giving v4 access to nodes >> in a moving network whose MR runs Mobile IPv6 and connects to a v4 >> access network? >> >> If yes, does the requirement include v4 session continuity? Does >> the requirement include reachability at a permanent v4 address? >> These aspects are important, at least for deciding on whether or >> not to use NAT within the moving network (see draft-shima). > > => I think Vijay included all our requirements so far in the slides > in Paris. So there is nothing more than what's in those slides. > >> Hesham, did you encode the prefixlen on 8 or 5 bits? Anyways, I >> don't think simply adding a v4 prefixlen into a message format is >> as easy as it may look. Conceptually - yes, just use a prefixlen, >> but from there to a protocol may be a longer way. For example, >> what happens when MR's v4 Home Address is independent of the Mobile >> Network Prefix (they differ starting at the 0th bit). > > => That's no different to the IPv6 case. Yes it is. In v6 one gets the v6 Home Address from the DO, and that can be different than the address and prefixlen that is in the BU. With a NEMOv6 that supports a v4 MNP the v6 HA can't find a v4 Home Address other than the one on which you attached a prefix len. If I am making myself clear... >> I think giving v4 access to nodes in the moving network would best >> be done by a NEMOv4 protocol. > > => It's not about giving v4 access to those nodes, it's about > updating the MR's v4 home address/prefix to its current CoA. What > happens inside the network is not in scope of transition mechanisms. Is mip6trans doing a "transition mechanism"? I don't get the above. Alex From nemo-bounces@ietf.org Tue Aug 09 10:09:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2UnP-0006oY-6T; Tue, 09 Aug 2005 10:09:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2UnN-0006o3-PQ; Tue, 09 Aug 2005 10:09:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09079; Tue, 9 Aug 2005 10:09:31 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2VLH-0000WX-Pt; Tue, 09 Aug 2005 10:44:37 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 9 Aug 2005 10:09:23 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] carrying IPv4 traffic using MIP6/NEMO Date: Tue, 9 Aug 2005 10:09:23 -0400 Message-ID: Thread-Topic: [nemo] carrying IPv4 traffic using MIP6/NEMO Thread-Index: AcWc62LKIuVLYUyvTlm9otiz0t6wzgAAE+Cg From: "Soliman, Hesham" To: "Alexandru Petrescu" X-OriginalArrivalTime: 09 Aug 2005 14:09:23.0770 (UTC) FILETIME=[F1C9A9A0:01C59CEB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org > > =3D> That's no different to the IPv6 case. >=20 > Yes it is. In v6 one gets the v6 Home Address from the DO,=20 > and that can > be different than the address and prefixlen that is in the BU. =3D> And the DO can contain an IPv4-mapped IPv6 address. So again there is no difference. It is only tricky if you have both v4 and v6 addresses and need to contain more than one of those.=20 > >> I think giving v4 access to nodes in the moving network would best > >> be done by a NEMOv4 protocol. > >=20 > > =3D> It's not about giving v4 access to those nodes, it's about=20 > > updating the MR's v4 home address/prefix to its current CoA. What > > happens inside the network is not in scope of transition=20 > mechanisms. >=20 > Is mip6trans doing a "transition mechanism"? I don't get the above. =3D> That's what "trans" stands for in "miptrans". Hesham >=20 > Alex >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D From nemo-bounces@ietf.org Tue Aug 09 10:14:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2UsH-0000JE-Nt; Tue, 09 Aug 2005 10:14:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2UsF-0000J0-68; Tue, 09 Aug 2005 10:14:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09664; Tue, 9 Aug 2005 10:14:32 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2VQA-0000i5-9y; Tue, 09 Aug 2005 10:49:38 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 9 Aug 2005 10:14:26 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] RE: [nemo] carrying IPv4 traffic using MIP6/NEMO Date: Tue, 9 Aug 2005 10:14:25 -0400 Message-ID: Thread-Topic: [Mip6] RE: [nemo] carrying IPv4 traffic using MIP6/NEMO Thread-Index: AcWc7DXr18KaNS66SWmQY4m8mmxQGQAAA4HA From: "Soliman, Hesham" To: "Keiichi SHIMA" X-OriginalArrivalTime: 09 Aug 2005 14:14:26.0084 (UTC) FILETIME=[A5FB1E40:01C59CEC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, mip6@ietf.org, ryuji@sfc.wide.ad.jp, alexandru.petrescu@motorola.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org > From: "Soliman, Hesham" > Date: Mon, 8 Aug 2005 13:37:32 -0400 >=20 > > > Are there any big differences between draft-soliman(w/prefixlen) > > > and draft-keiichi for NEMO support? > >=20 > > =3D> I haven't read draft-keiichi but if it only adds an IPv4 = prefix > > to the BU then there are differences, draft-soliman deals with=20 > > IPv4 HoAs/prefix as well as IPv4 CoAs for MIP6 and nemo.=20 >=20 > The IPv4 CoAs are for IPv6 Mobility over IPv4 access=20 > networks, and the > IPv4 HoAs/Prefixes are for IPv4 Mobility over IPv6 networks, if I > understand correctly. =3D> Not really. There is no need for that binding. If you have=20 a HoA you always want to use it regardless of the access network you are on. So if you have a v6 HoA you'll use it whether you're=20 in an IPv4 or an IPv6 or dual stack access. The same goes for the=20 v4 home address.=20 >=20 > Then, the above two things are orthogonal and should be=20 > split into two > separate specifications? =3D> Not necessarily. It's one problem that the DT is trying to address. There are different permutations depending on the scenario, but that doesn't mean each permutation should be documented separately. That would make life very complex. Hesham >=20 > Regards, > --- > Keiichi SHIMA > IIJ Research Laboratory > KAME Project >=20 >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D From nemo-bounces@ietf.org Tue Aug 09 10:11:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2UpJ-0007l4-5Z; Tue, 09 Aug 2005 10:11:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2UpG-0007k7-Rh; Tue, 09 Aug 2005 10:11:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09346; Tue, 9 Aug 2005 10:11:28 -0400 (EDT) Received: from omgo.iij.ad.jp ([202.232.30.157]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2VNA-0000bu-Mq; Tue, 09 Aug 2005 10:46:34 -0400 Received: OTM-MO id j79EBFOt028449; Tue, 9 Aug 2005 23:11:15 +0900 (JST) Received: OTM-MIX0 id j79EBElY001251; Tue, 9 Aug 2005 23:11:14 +0900 (JST) Received: from localhost (jc-ssh.iij.ad.jp [192.168.174.22]) by jc-smtp.iij.ad.jp (JC-SMTP/jc-smtp) id j79EBA2D022869; Tue, 9 Aug 2005 23:11:11 +0900 (JST) Date: Tue, 09 Aug 2005 16:11:15 +0200 (CEST) Message-Id: <20050809.161115.104154887.keiichi@iijlab.net> To: H.Soliman@flarion.com Subject: Re: [Mip6] RE: [nemo] carrying IPv4 traffic using MIP6/NEMO From: Keiichi SHIMA In-Reply-To: References: X-Mailer: Mew version 4.2.53 on Emacs 22.0.50 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, mip6@ietf.org, ryuji@sfc.wide.ad.jp, alexandru.petrescu@motorola.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello Hesham, From: "Soliman, Hesham" Date: Mon, 8 Aug 2005 13:37:32 -0400 > > Are there any big differences between draft-soliman(w/prefixlen) > > and draft-keiichi for NEMO support? > > => I haven't read draft-keiichi but if it only adds an IPv4 prefix > to the BU then there are differences, draft-soliman deals with > IPv4 HoAs/prefix as well as IPv4 CoAs for MIP6 and nemo. The IPv4 CoAs are for IPv6 Mobility over IPv4 access networks, and the IPv4 HoAs/Prefixes are for IPv4 Mobility over IPv6 networks, if I understand correctly. Then, the above two things are orthogonal and should be split into two separate specifications? Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project From nemo-bounces@ietf.org Tue Aug 09 10:31:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2V8x-0007tX-1X; Tue, 09 Aug 2005 10:31:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2V8u-0007t0-Fq; Tue, 09 Aug 2005 10:31:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11300; Tue, 9 Aug 2005 10:31:46 -0400 (EDT) Received: from omgo.iij.ad.jp ([202.232.30.157]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2Vgo-0001G8-DS; Tue, 09 Aug 2005 11:06:52 -0400 Received: OTM-MO id j79EVheN029519; Tue, 9 Aug 2005 23:31:43 +0900 (JST) Received: OTM-MIX0 id j79EVggB007304; Tue, 9 Aug 2005 23:31:42 +0900 (JST) Received: from localhost (jc-ssh.iij.ad.jp [192.168.174.22]) by jc-smtp.iij.ad.jp (JC-SMTP/jc-smtp) id j79EVdMt023359; Tue, 9 Aug 2005 23:31:40 +0900 (JST) Date: Tue, 09 Aug 2005 16:31:44 +0200 (CEST) Message-Id: <20050809.163144.108677394.keiichi@iijlab.net> To: H.Soliman@flarion.com Subject: Re: [Mip6] RE: [nemo] carrying IPv4 traffic using MIP6/NEMO From: Keiichi SHIMA In-Reply-To: References: X-Mailer: Mew version 4.2.53 on Emacs 22.0.50 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, mip6@ietf.org, ryuji@sfc.wide.ad.jp, alexandru.petrescu@motorola.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Hesham, From: "Soliman, Hesham" Date: Tue, 9 Aug 2005 10:14:25 -0400 > > > > The IPv4 CoAs are for IPv6 Mobility over IPv4 access > > networks, and the > > IPv4 HoAs/Prefixes are for IPv4 Mobility over IPv6 networks, if I > > understand correctly. > > => Not really. There is no need for that binding. If you have > a HoA you always want to use it regardless of the access network > you are on. So if you have a v6 HoA you'll use it whether you're > in an IPv4 or an IPv6 or dual stack access. The same goes for the > v4 home address. I think I understand what you mean. You are trying to provide the mechanism Mobile IPv4 (network) over IPv4 access networks using MIP6/NEMO signaling mechanisms, correct? I thought that kind of configuration was not the scope of the DT team. I even thought Mobile IPv4 over IPv6 was also out of scope, since I though the DT team were discussing the mechanism to provide IPv6 mobility over IPv4 access networks. Are such configurations are still in the v4traversal DT scope? Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project From nemo-bounces@ietf.org Tue Aug 09 10:36:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2VDa-0001ud-RX; Tue, 09 Aug 2005 10:36:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2VDY-0001uQ-RB; Tue, 09 Aug 2005 10:36:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11746; Tue, 9 Aug 2005 10:36:34 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2VlT-0001Os-8N; Tue, 09 Aug 2005 11:11:40 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 9 Aug 2005 10:36:26 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] RE: [nemo] carrying IPv4 traffic using MIP6/NEMO Date: Tue, 9 Aug 2005 10:36:26 -0400 Message-ID: Thread-Topic: [Mip6] RE: [nemo] carrying IPv4 traffic using MIP6/NEMO Thread-Index: AcWc7xHOBENvg2a4SgWH8t4b9bmiQQAAC+Wg From: "Soliman, Hesham" To: "Keiichi SHIMA" X-OriginalArrivalTime: 09 Aug 2005 14:36:26.0811 (UTC) FILETIME=[B93210B0:01C59CEF] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, mip6@ietf.org, ryuji@sfc.wide.ad.jp, alexandru.petrescu@motorola.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Keichi, > > =3D> Not really. There is no need for that binding. If you have=20 > > a HoA you always want to use it regardless of the access network > > you are on. So if you have a v6 HoA you'll use it whether you're=20 > > in an IPv4 or an IPv6 or dual stack access. The same goes for the=20 > > v4 home address.=20 >=20 > I think I understand what you mean. You are trying to provide the > mechanism Mobile IPv4 (network) over IPv4 access networks using > MIP6/NEMO signaling mechanisms, correct? >=20 > I thought that kind of configuration was not the scope of=20 > the DT team. > I even thought Mobile IPv4 over IPv6 was also out of scope, since I > though the DT team were discussing the mechanism to provide IPv6 > mobility over IPv4 access networks. =3D> We're not doing anything with MIPv4 in the DT. We're trying to allow the MN (that includes MR), using MIPv6, to be able to use=20 an IPv4 or IPv6 home address in any access network that it might be=20 in. I think this summarizes the problem that the DT is addressing. Hesham =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D From nemo-bounces@ietf.org Tue Aug 09 10:53:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2VUE-0000vs-PW; Tue, 09 Aug 2005 10:53:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2VUC-0000vL-KA; Tue, 09 Aug 2005 10:53:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13070; Tue, 9 Aug 2005 10:53:46 -0400 (EDT) Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2W25-00020c-2V; Tue, 09 Aug 2005 11:28:52 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id j79F0FuR008196; Tue, 9 Aug 2005 08:00:15 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id j79EwAq5017769; Tue, 9 Aug 2005 09:58:11 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 4E038865980; Tue, 9 Aug 2005 16:53:05 +0200 (CEST) Message-ID: <42F8C351.3090502@motorola.com> Date: Tue, 09 Aug 2005 16:53:05 +0200 From: Alexandru Petrescu Organization: Motorola Labs, Paris, France User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [nemo] carrying IPv4 traffic using MIP6/NEMO References: In-Reply-To: X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, mip6@ietf.org, Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Soliman, Hesham wrote: >>> => That's no different to the IPv6 case. >> >> Yes it is. In v6 one gets the v6 Home Address from the DO, and >> that can be different than the address and prefixlen that is in the >> BU. > > => And the DO can contain an IPv4-mapped IPv6 address. So again there > is no difference. It is only tricky if you have both v4 and v6 > addresses and need to contain more than one of those. So it is acknowledged that this may become tricky. I agree. Alex From nemo-bounces@ietf.org Tue Aug 09 11:00:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2VaE-0003AJ-EH; Tue, 09 Aug 2005 11:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2VaC-00039Y-RW; Tue, 09 Aug 2005 11:00:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13729; Tue, 9 Aug 2005 10:59:58 -0400 (EDT) Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2W87-0002Jt-OX; Tue, 09 Aug 2005 11:35:04 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id j79F6dIY011667; Tue, 9 Aug 2005 08:06:39 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id j79F625e014919; Tue, 9 Aug 2005 10:06:03 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 0126A865980; Tue, 9 Aug 2005 16:59:54 +0200 (CEST) Message-ID: <42F8C4E9.7050705@motorola.com> Date: Tue, 09 Aug 2005 16:59:53 +0200 From: Alexandru Petrescu Organization: Motorola Labs, Paris, France User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mip6] RE: [nemo] carrying IPv4 traffic using MIP6/NEMO References: In-Reply-To: X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, mip6@ietf.org, ryuji@sfc.wide.ad.jp, Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Soliman, Hesham wrote: > Hi Keichi, > >>> => Not really. There is no need for that binding. If you have a >>> HoA you always want to use it regardless of the access network >>> you are on. So if you have a v6 HoA you'll use it whether you're >>> in an IPv4 or an IPv6 or dual stack access. The same goes for >>> the v4 home address. >> >> I think I understand what you mean. You are trying to provide the >> mechanism Mobile IPv4 (network) over IPv4 access networks using >> MIP6/NEMO signaling mechanisms, correct? >> >> I thought that kind of configuration was not the scope of the DT >> team. I even thought Mobile IPv4 over IPv6 was also out of scope, >> since I though the DT team were discussing the mechanism to provide >> IPv6 mobility over IPv4 access networks. > > => We're not doing anything with MIPv4 in the DT. We're trying to > allow the MN (that includes MR), using MIPv6, to be able to use an > IPv4 or IPv6 home address in any access network that it might be in. > I think this summarizes the problem that the DT is addressing. I think some of the things that are addressed by the mip6trans DT could be addressed outside the mip6trans DT. More specifically the v4 MR stuff. I also think that there is one thing to support continuous IPv6 sessions on a Mobile IPv6 MH connecting to a v4 network and it is a totally different thing to support continuous IPv4 sessions on the same node. Alex From nemo-bounces@ietf.org Tue Aug 09 11:10:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Vk4-0000f6-Ir; Tue, 09 Aug 2005 11:10:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Vk2-0000am-NY; Tue, 09 Aug 2005 11:10:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14515; Tue, 9 Aug 2005 11:10:08 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2WHx-0002hf-CV; Tue, 09 Aug 2005 11:45:14 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 9 Aug 2005 11:09:57 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] RE: [nemo] carrying IPv4 traffic using MIP6/NEMO Date: Tue, 9 Aug 2005 11:09:57 -0400 Message-ID: Thread-Topic: [Mip6] RE: [nemo] carrying IPv4 traffic using MIP6/NEMO Thread-Index: AcWc8wIiemeI4YrxSaihzpSf08zE9gAASCqA From: "Soliman, Hesham" To: "Alexandru Petrescu" X-OriginalArrivalTime: 09 Aug 2005 15:09:57.0574 (UTC) FILETIME=[67B42660:01C59CF4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, mip6@ietf.org, ryuji@sfc.wide.ad.jp X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org > > =3D> We're not doing anything with MIPv4 in the DT. We're trying to = > > allow the MN (that includes MR), using MIPv6, to be able to use an > > IPv4 or IPv6 home address in any access network that it=20 > might be in.=20 > > I think this summarizes the problem that the DT is addressing. >=20 > I think some of the things that are addressed by the=20 > mip6trans DT could > be addressed outside the mip6trans DT. More specifically=20 > the v4 MR stuff. =3D> So let me explain it again: We're *not* doing "v4 MR stuff". We're allowing the MR to have a v4 HoA/P. There is no difference between that and allowing a host to have a v4 HoA.. Hesham >=20 > I also think that there is one thing to support continuous=20 > IPv6 sessions > on a Mobile IPv6 MH connecting to a v4 network and it is a totally > different thing to support continuous IPv4 sessions on the same node. >=20 > Alex >=20 >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D From nemo-bounces@ietf.org Tue Aug 09 11:27:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2W0R-0007ML-Az; Tue, 09 Aug 2005 11:27:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2W0P-0007Ll-O9; Tue, 09 Aug 2005 11:27:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15642; Tue, 9 Aug 2005 11:27:02 -0400 (EDT) Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2WYK-0003FE-1Z; Tue, 09 Aug 2005 12:02:09 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id j79FQxtZ012580; Tue, 9 Aug 2005 08:26:59 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id j79FZ8TY001527; Tue, 9 Aug 2005 10:35:10 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 8EA6C8637E6; Tue, 9 Aug 2005 17:26:56 +0200 (CEST) Message-ID: <42F8CB40.3060405@motorola.com> Date: Tue, 09 Aug 2005 17:26:56 +0200 From: Alexandru Petrescu Organization: Motorola Labs, Paris, France User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mip6] RE: [nemo] carrying IPv4 traffic using MIP6/NEMO References: In-Reply-To: X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, mip6@ietf.org, ryuji@sfc.wide.ad.jp, Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Soliman, Hesham wrote: >>> => We're not doing anything with MIPv4 in the DT. We're trying to >>> allow the MN (that includes MR), using MIPv6, to be able to use >>> an IPv4 or IPv6 home address in any access network that it >> might be in. >>> I think this summarizes the problem that the DT is addressing. >> >> I think some of the things that are addressed by the mip6trans DT >> could be addressed outside the mip6trans DT. More specifically the >> v4 MR stuff. > > => So let me explain it again: We're *not* doing "v4 MR stuff". We're > allowing the MR to have a v4 HoA/P. There is no difference between > that and allowing a host to have a v4 HoA.. Yes there is. We've both just said it may become tricky. Why is the DT looking into the complexity (that was previously named "tricky") to allow the MR to have a v4 HoA/P? Isn't the DT facing enough complexity in allowing MH to have a permanent v6 Home Address when connected to a v4 network? To me, at least the NAT traversal part gives enough headache. Alex From nemo-bounces@ietf.org Tue Aug 09 11:39:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2WCk-0004eO-LE; Tue, 09 Aug 2005 11:39:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2WCi-0004eG-Aj; Tue, 09 Aug 2005 11:39:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16290; Tue, 9 Aug 2005 11:39:45 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2Wkd-0003cO-Q5; Tue, 09 Aug 2005 12:14:52 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 9 Aug 2005 11:39:38 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] RE: [nemo] carrying IPv4 traffic using MIP6/NEMO Date: Tue, 9 Aug 2005 11:39:38 -0400 Message-ID: Thread-Topic: [Mip6] RE: [nemo] carrying IPv4 traffic using MIP6/NEMO Thread-Index: AcWc9snsEZ/n5nHZSzibLQCXwnjXXAAATvqw From: "Soliman, Hesham" To: "Alexandru Petrescu" X-OriginalArrivalTime: 09 Aug 2005 15:39:38.0195 (UTC) FILETIME=[8D095A30:01C59CF8] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, mip6@ietf.org, ryuji@sfc.wide.ad.jp X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org > >>> =3D> We're not doing anything with MIPv4 in the DT. We're trying = to > >>> allow the MN (that includes MR), using MIPv6, to be able to use > >>> an IPv4 or IPv6 home address in any access network that it > >> might be in. > >>> I think this summarizes the problem that the DT is addressing. > >>=20 > >> I think some of the things that are addressed by the mip6trans DT > >> could be addressed outside the mip6trans DT. More=20 > specifically the > >> v4 MR stuff. > >=20 > > =3D> So let me explain it again: We're *not* doing "v4 MR=20 > stuff". We're > > allowing the MR to have a v4 HoA/P. There is no difference between > > that and allowing a host to have a v4 HoA.. >=20 > Yes there is. We've both just said it may become tricky. =3D> You're confusing two separate issues. I said it's tricky to=20 have multiple instances of the HAO. For example today we're not=20 allowed to have multiple HAOs for an IPv6 address... This has nothing to do with whether you can support an IPv4 prefix. There are lots of tricky issues in mobility and it doesn't mean we can't do it.=20 >=20 > Why is the DT looking into the complexity (that was previously named > "tricky") to allow the MR to have a v4 HoA/P? Isn't the DT facing > enough complexity in allowing MH to have a permanent v6 Home Address > when connected to a v4 network? To me, at least the NAT=20 > traversal part > gives enough headache. =3D> When you see the solution you can assess whether it's complex or = not.=20 For now I was referring to an update to draft-soliman. The DT hasn't decided what the solution is based on, so I was referring to = draft-soliman as an example of how this is done, whether it is the final solution or = not is not up to me obviously.=20 Hesham >=20 > Alex >=20 >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D From nemo-bounces@ietf.org Tue Aug 09 12:27:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Wwj-0002tv-NN; Tue, 09 Aug 2005 12:27:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Wwh-0002tL-01; Tue, 09 Aug 2005 12:27:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20610; Tue, 9 Aug 2005 12:27:15 -0400 (EDT) Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2XUc-0005ct-Uu; Tue, 09 Aug 2005 13:02:23 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id j79GYlEC004126; Tue, 9 Aug 2005 09:34:47 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id j79GViWZ018411; Tue, 9 Aug 2005 11:31:45 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 024DB865980; Tue, 9 Aug 2005 18:27:02 +0200 (CEST) Message-ID: <42F8D955.9010605@motorola.com> Date: Tue, 09 Aug 2005 18:27:01 +0200 From: Alexandru Petrescu Organization: Motorola Labs, Paris, France User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mip6] RE: [nemo] carrying IPv4 traffic using MIP6/NEMO References: In-Reply-To: X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by motgate4.mot.com id j79GYlEC004126 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, mip6@ietf.org, ryuji@sfc.wide.ad.jp, Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Soliman, Hesham wrote: >=20 >>>>> =3D> We're not doing anything with MIPv4 in the DT. We're=20 >>>>> trying to allow the MN (that includes MR), using MIPv6, to be >>>>> able to use an IPv4 or IPv6 home address in any access=20 >>>>> network that it >>>> might be in. >>>>> I think this summarizes the problem that the DT is=20 >>>>> addressing. >>>>=20 >>>> I think some of the things that are addressed by the mip6trans >>>> DT could be addressed outside the mip6trans DT. More >> specifically the >>>> v4 MR stuff. >>>=20 >>> =3D> So let me explain it again: We're *not* doing "v4 MR >> stuff". We're >>> allowing the MR to have a v4 HoA/P. There is no difference=20 >>> between that and allowing a host to have a v4 HoA.. >>=20 >> Yes there is. We've both just said it may become tricky. >=20 > =3D> You're confusing two separate issues. I said it's tricky to have=20 > multiple instances of the HAO. For example today we're not allowed to > have multiple HAOs for an IPv6 address... I see, you're right. Having a v6-mapped v4 address in the HAO would probably lead to sending two BUs: one for v4, one for v6. But then draft-dsmip-problem would be failing too because dsmip suddenly does double signalling. > There are lots of tricky issues in mobility and it doesn't mean we=20 > can't do it. That sounds like overconfidence to me, IMHO. Or I may be confused, as you say. >> Why is the DT looking into the complexity (that was previously=20 >> named "tricky") to allow the MR to have a v4 HoA/P? Isn't the DT=20 >> facing enough complexity in allowing MH to have a permanent v6 Home >> Address when connected to a v4 network? To me, at least the NAT=20 >> traversal part gives enough headache. >=20 > =3D> When you see the solution you can assess whether it's complex or=20 > not. When I see arguments adding a prefixlen field is 5 minutes work I tend to believe complexity is still hidden. > For now I was referring to an update to draft-soliman. The DT hasn't > decided what the solution is based on, so I was referring to=20 > draft-soliman as an example of how this is done, whether it is the=20 > final solution or not is not up to me obviously. Ok, so we'd probably be more productive on feeding back about the Vijay Paris slides, about which requirements and scenarios are needed immediately, rather than pitting documents one against another. Paris slides: > Connect an IPv6 mobile node to its IPv6 Home Agent and services from > an IPv4-only access network > 1 Support NAT traversal, NAT detection and the ability to turn offthe > NAT traversal mechanism when not required > 2 Support the scenario where the Home Agent is behind a NAT and not > accessible through a public address > 3 Support dynamic discovery of the HA=92s IPv4 address > 4 Enable IPsec protection for the mip6trans tunnel. The Home Agentand > the mobile node must be able to negotiate tunnel security > associations for the mip6trans tunnel > 5 Enable the mobile node to use its IPv4 Home Address for IPv4 > sessions over the mip6trans tunnel > 6 Support dynamic allocation of the IPv4 Home Address I'm for 1 and 4 and not for 2, 3, 5, 6. And I'd like to add requirement 0: support IPv6 session continuity at a permanent publicly-routable v6 Home Address when the MH connects to a v4-exclusively network. The requirements 2, 3, 5 and 6 are interesting - ok - but may represent too much work. Alex From nemo-bounces@ietf.org Wed Aug 10 08:49:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2q1I-00041a-3O; Wed, 10 Aug 2005 08:49:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2q1B-00040x-6g; Wed, 10 Aug 2005 08:49:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24917; Wed, 10 Aug 2005 08:49:11 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2qZH-0005Bj-Hf; Wed, 10 Aug 2005 09:24:28 -0400 Received: from [10.0.2.15] (unknown [168.126.248.3]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 31C414CA55; Wed, 10 Aug 2005 21:49:02 +0900 (JST) In-Reply-To: <42F8D955.9010605@motorola.com> References: <42F8D955.9010605@motorola.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=SHIFT_JIS; delsp=yes; format=flowed Message-Id: <7F1AD8E3-716A-45C3-9F03-179CA14E38B5@sfc.wide.ad.jp> Content-Transfer-Encoding: quoted-printable From: Ryuji Wakikawa Subject: Re: [Mip6] RE: [nemo] carrying IPv4 traffic using MIP6/NEMO Date: Wed, 10 Aug 2005 21:48:52 +0900 To: Alexandru Petrescu X-Mailer: Apple Mail (2.733) X-Spam-Score: 2.9 (++) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: quoted-printable Cc: "Soliman, Hesham" , nemo@ietf.org, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Alex and Hesham On 2005/08/10, at 1:27, Alexandru Petrescu wrote: > Soliman, Hesham wrote: > > >> >> >>>>>> =3D> We're not doing anything with MIPv4 in the DT. We're >>>>>> trying to allow the MN (that includes MR), using MIPv6, to be >>>>>> able to use an IPv4 or IPv6 home address in any access >>>>>> network that it >>>>>> >>>>> might be in. >>>>> >>>>>> I think this summarizes the problem that the DT is >>>>>> addressing. >>>>>> >>>>> >>>>> I think some of the things that are addressed by the mip6trans >>>>> DT could be addressed outside the mip6trans DT. More >>>>> >>> specifically the >>> >>>>> v4 MR stuff. >>>>> >>>> >>>> =3D> So let me explain it again: We're *not* doing "v4 MR >>>> >>> stuff". We're >>> >>>> allowing the MR to have a v4 HoA/P. There is no difference >>>> between that and allowing a host to have a v4 HoA.. >>>> >>> >>> Yes there is. We've both just said it may become tricky. >>> >> >> =3D> You're confusing two separate issues. I said it's tricky to have >> multiple instances of the HAO. For example today we're not allowed to >> have multiple HAOs for an IPv6 address... >> > > I see, you're right. > > Having a v6-mapped v4 address in the HAO would probably lead to =20 > sending > two BUs: one for v4, one for v6. But then draft-dsmip-problem =20 > would be > failing too because dsmip suddenly does double signalling. We are not discussing a solution yet. So it is irrelevant to discuss =20= such details. > >> There are lots of tricky issues in mobility and it doesn't mean we >> can't do it. >> > > That sounds like overconfidence to me, IMHO. Or I may be confused, as > you say. > > >>> Why is the DT looking into the complexity (that was previously >>> named "tricky") to allow the MR to have a v4 HoA/P? Isn't the DT >>> facing enough complexity in allowing MH to have a permanent v6 Home >>> Address when connected to a v4 network? To me, at least the NAT >>> traversal part gives enough headache. >>> >> >> =3D> When you see the solution you can assess whether it's complex or >> not. >> > > When I see arguments adding a prefixlen field is 5 minutes work I tend > to believe complexity is still hidden. > > >> For now I was referring to an update to draft-soliman. The DT hasn't >> decided what the solution is based on, so I was referring to >> draft-soliman as an example of how this is done, whether it is the >> final solution or not is not up to me obviously. >> > > Ok, so we'd probably be more productive on feeding back about the =20 > Vijay > Paris slides, about which requirements and scenarios are needed > immediately, rather than pitting documents one against another. > > Paris slides: > >> Connect an IPv6 mobile node to its IPv6 Home Agent and services from >> an IPv4-only access network >> > > >> 1 Support NAT traversal, NAT detection and the ability to turn offthe >> NAT traversal mechanism when not required >> > > >> 2 Support the scenario where the Home Agent is behind a NAT and not >> accessible through a public address >> > > >> 3 Support dynamic discovery of the HA=81fs IPv4 address >> > > >> 4 Enable IPsec protection for the mip6trans tunnel. The Home Agentand >> the mobile node must be able to negotiate tunnel security >> associations for the mip6trans tunnel >> > > >> 5 Enable the mobile node to use its IPv4 Home Address for IPv4 >> sessions over the mip6trans tunnel >> > > >> 6 Support dynamic allocation of the IPv4 Home Address >> > > I'm for 1 and 4 and not for 2, 3, 5, 6. And I'd like to add =20 > requirement > 0: support IPv6 session continuity at a permanent publicly-routable v6 > Home Address when the MH connects to a v4-exclusively network. > > The requirements 2, 3, 5 and 6 are interesting - ok - but may =20 > represent > too much work. Alex, I disagree on your proposition. I don't know how do you line between 1,4 and 2,3,5,6. The requirements listed here were from the DT consensus. On the other hand, one thing where keiichi pointed out is whether we should include IPv4 MNP in No.5. And Hesham agreed. Then, the next question was that should we split documents for v4 =20 traversal and v4 session continuity. regards, ryuji From nemo-bounces@ietf.org Wed Aug 10 08:55:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2q74-0005XV-MT; Wed, 10 Aug 2005 08:55:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2q72-0005VD-LQ; Wed, 10 Aug 2005 08:55:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25148; Wed, 10 Aug 2005 08:55:15 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2qf6-0005KJ-RH; Wed, 10 Aug 2005 09:30:32 -0400 Received: from [10.0.2.15] (unknown [168.126.248.3]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id B073A4C6B7; Wed, 10 Aug 2005 21:55:02 +0900 (JST) In-Reply-To: <42F877E9.8010304@motorola.com> References: <42F877E9.8010304@motorola.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6ED12209-2B69-4F0D-84FA-489A5AC05E49@sfc.wide.ad.jp> Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Subject: Re: [Mip6] Re: [nemo] carrying IPv4 traffic using MIP6/NEMO Date: Wed, 10 Aug 2005 21:54:54 +0900 To: Alexandru Petrescu X-Mailer: Apple Mail (2.733) X-Spam-Score: 2.9 (++) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Content-Transfer-Encoding: 7bit Cc: "Soliman, Hesham" , nemo@ietf.org, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Alex. On 2005/08/09, at 18:31, Alexandru Petrescu wrote: > Hello Hesham, > > Soliman, Hesham wrote: > >>> >>> Generally it looks like an interesting idea. Why restraining the >>> binding to a fixed /32 full v4 address when binding a variable >>> prefix (1...32) could bring the benefit of giving v4 access to all >>> nodes in the moving network (not only to the MR). So this may look >>> as an obvious advantage. >>> >>> However, I was wondering how much would this addition extend the >>> current scope of the DT work, whose goal was mainly to give v6 (not >>> v4) access to MR and mobile nodes when MR connects to a v4 >>> network. >>> >>> Giving continuous v4 access to mobile nodes in a moving network >>> whose MR connects to a v4 access network can naturally be obtained >>> by running Mobile IPv4 on the MR, too. >>> >>> What does the DT think? >>> >> >> => We discussed this >> > > Great, does the DT have a requirement for giving v4 access to nodes > in a > moving network whose MR runs Mobile IPv6 and connects to a v4 access > network? > > If yes, does the requirement include v4 session continuity? Does the > requirement include reachability at a permanent v4 address? These > aspects are important, at least for deciding on whether or not to use > NAT within the moving network (see draft-shima). Using NAT in the mobile network is possible if MR has at least one global v4 address. I attach discussion in DT ML. ryuji > >> and I had extended draft-soliman to represent the IP address as : >> address/prefixlen, where prefixlen is anything up to 32. It's a >> useful feature that only adds another 5 mins of work so why not. >> > > Hesham, did you encode the prefixlen on 8 or 5 bits? Anyways, I don't > think simply adding a v4 prefixlen into a message format is as easy as > it may look. Conceptually - yes, just use a prefixlen, but from there > to a protocol may be a longer way. For example, what happens when > MR's > v4 Home Address is independent of the Mobile Network Prefix (they > differ > starting at the 0th bit). > > I think giving v4 access to nodes in the moving network would best be > done by a NEMOv4 protocol. > > Alex > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > On 2005/07/22, at 8:26, Soliman, Hesham wrote: > > > >>>> If a MR uses IPv4 feature of MIP6, it may use the IPv4 >>>> global address >>>> for NATed mobile network. >>>> This is one way to provide v4 connectivity to NEMO, but I prefer >>>> clean solution. >>>> >>>> >>> >>> => Please elaborate on the scenario you're describing, a picture >>> might help. If the MR has an IPv4 prefix for the MNNs behind it, >>> >> >> something like this. >> >> IPv4 global IPv4 private >> HA----Internet --- MR (NAT) -------Mobile Networks >> >> MR sends BU including IPv4 global address to HA as you proposed and >> uses the IPv4 global address for NATed mobile network. >> MR acts as NAT BOX for mobile network. >> > > => Ok, this is exactly the same as a mobile host. The same should > work regardless of it being an MR. > > >> If NEMO is operated with implicit mode and dynamic routing protocol >> like OSPF, >> it fines. However, if MR sends BU with MNP options (no OSPF >> running), >> how can MR notify the IPv4 prefix to HA? >> This is the same problem with MIP6, isn't this? >> > > => You just showed an example where the MR is a NAT. If > you want to propose a nemo basic solution for IPv4 then > this is not the right place to solve it. IF there is a nemo > solution for v4 we can easily add the IPv4 prefix option. > This is a 5 min job, *if* that solution exists. > > Hesham > > =========================================================== > This email may contain confidential and privileged material for the > sole use > of the intended recipient. Any review or distribution by others > is strictly > prohibited. If you are not the intended recipient please contact > the sender > and delete all copies. > =========================================================== > From nemo-bounces@ietf.org Wed Aug 10 09:17:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2qST-0002iw-0H; Wed, 10 Aug 2005 09:17:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2qSR-0002iM-5m; Wed, 10 Aug 2005 09:17:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26587; Wed, 10 Aug 2005 09:17:21 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2r0X-0005yO-91; Wed, 10 Aug 2005 09:52:38 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j7ADQvVp012046; Wed, 10 Aug 2005 06:26:57 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (8.13.1/8.13.0) with ESMTP id j7ADO17i014247; Wed, 10 Aug 2005 08:24:02 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 9674C865980; Wed, 10 Aug 2005 15:17:01 +0200 (CEST) Message-ID: <42F9FE4D.6030406@motorola.com> Date: Wed, 10 Aug 2005 15:17:01 +0200 From: Alexandru Petrescu Organization: Motorola Labs, Paris, France User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Ryuji Wakikawa Subject: Re: [Mip6] Re: [nemo] carrying IPv4 traffic using MIP6/NEMO References: <42F877E9.8010304@motorola.com> <6ED12209-2B69-4F0D-84FA-489A5AC05E49@sfc.wide.ad.jp> In-Reply-To: <6ED12209-2B69-4F0D-84FA-489A5AC05E49@sfc.wide.ad.jp> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: "Soliman, Hesham" , nemo@ietf.org, Alexandru Petrescu , mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Ryuji, Ryuji Wakikawa wrote: > Hi Alex. > > On 2005/08/09, at 18:31, Alexandru Petrescu wrote: > >> Hello Hesham, >> >> Soliman, Hesham wrote: >> >>>> >>>> Generally it looks like an interesting idea. Why restraining >>>> the binding to a fixed /32 full v4 address when binding a >>>> variable prefix (1...32) could bring the benefit of giving v4 >>>> access to all nodes in the moving network (not only to the MR). >>>> So this may look as an obvious advantage. >>>> >>>> However, I was wondering how much would this addition extend >>>> the current scope of the DT work, whose goal was mainly to give >>>> v6 (not v4) access to MR and mobile nodes when MR connects to a >>>> v4 network. >>>> >>>> Giving continuous v4 access to mobile nodes in a moving network >>>> whose MR connects to a v4 access network can naturally be >>>> obtained by running Mobile IPv4 on the MR, too. >>>> >>>> What does the DT think? >>>> >>> >>> => We discussed this >>> >> >> Great, does the DT have a requirement for giving v4 access to nodes >> in a moving network whose MR runs Mobile IPv6 and connects to a v4 >> access network? >> >> If yes, does the requirement include v4 session continuity? Does >> the requirement include reachability at a permanent v4 address? >> These aspects are important, at least for deciding on whether or >> not to use NAT within the moving network (see draft-shima). > > > Using NAT in the mobile network is possible if MR has at least one > global v4 address. I agree using NAT in the mobile network is possible. I also agree that if NAT is used in the mobile network then there can be no mip6trans requirement for reachability at a permanent v4 address (behind NAT the v4 nodes are not reachable, somebody can't connect() to them). All in all, IMHO, mip6trans should not waste effort on giving v4 access to nodes in the moving network; if it does (because consensus) then shouldn't do it with NAT. My oppinion, Alex From nemo-bounces@ietf.org Wed Aug 10 09:30:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2qey-0006VP-EW; Wed, 10 Aug 2005 09:30:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2qew-0006Uo-37; Wed, 10 Aug 2005 09:30:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27235; Wed, 10 Aug 2005 09:30:16 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2rD0-0006ML-Uz; Wed, 10 Aug 2005 10:05:33 -0400 Received: from [192.168.1.2] (unknown [168.126.248.3]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id D3C4A4CBF0; Wed, 10 Aug 2005 22:30:04 +0900 (JST) In-Reply-To: <42F9FE4D.6030406@motorola.com> References: <42F877E9.8010304@motorola.com> <6ED12209-2B69-4F0D-84FA-489A5AC05E49@sfc.wide.ad.jp> <42F9FE4D.6030406@motorola.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4CC22A36-030D-4816-B86F-9E3D0BB3B345@sfc.wide.ad.jp> Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Subject: Re: [Mip6] Re: [nemo] carrying IPv4 traffic using MIP6/NEMO Date: Wed, 10 Aug 2005 22:29:57 +0900 To: Alexandru Petrescu X-Mailer: Apple Mail (2.733) X-Spam-Score: 2.9 (++) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit Cc: "Soliman, Hesham" , nemo@ietf.org, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Alex On 2005/08/10, at 22:17, Alexandru Petrescu wrote: > Hi Ryuji, > > Ryuji Wakikawa wrote: > > >> Hi Alex. >> >> On 2005/08/09, at 18:31, Alexandru Petrescu wrote: >> >> >>> Hello Hesham, >>> >>> Soliman, Hesham wrote: >>> >>> >>>>> >>>>> Generally it looks like an interesting idea. Why restraining >>>>> the binding to a fixed /32 full v4 address when binding a >>>>> variable prefix (1...32) could bring the benefit of giving v4 >>>>> access to all nodes in the moving network (not only to the MR). >>>>> So this may look as an obvious advantage. >>>>> >>>>> However, I was wondering how much would this addition extend >>>>> the current scope of the DT work, whose goal was mainly to give >>>>> v6 (not v4) access to MR and mobile nodes when MR connects to a >>>>> v4 network. >>>>> >>>>> Giving continuous v4 access to mobile nodes in a moving network >>>>> whose MR connects to a v4 access network can naturally be >>>>> obtained by running Mobile IPv4 on the MR, too. >>>>> >>>>> What does the DT think? >>>>> >>>>> >>>> >>>> => We discussed this >>>> >>>> >>> >>> Great, does the DT have a requirement for giving v4 access to nodes >>> in a moving network whose MR runs Mobile IPv6 and connects to a v4 >>> access network? >>> >>> If yes, does the requirement include v4 session continuity? Does >>> the requirement include reachability at a permanent v4 address? >>> These aspects are important, at least for deciding on whether or >>> not to use NAT within the moving network (see draft-shima). >>> >> >> >> Using NAT in the mobile network is possible if MR has at least one >> global v4 address. >> > > I agree using NAT in the mobile network is possible. I also agree > that > if NAT is used in the mobile network then there can be no mip6trans > requirement for reachability at a permanent v4 address (behind NAT the > v4 nodes are not reachable, somebody can't connect() to them). Well, that is limitation of NAT... > All in all, IMHO, mip6trans should not waste effort on giving v4 > access > to nodes in the moving network; if it does (because consensus) then We should work on v4 reachability, because MIP6 WG already has the problem statement draft (draft-ietf-dsmip), And It makes sense to have a similar/common solution, because both goals are to establish tunnel between HA-MN after all. The question may be whether we should split document or not?! > shouldn't do it with NAT. Do you mean doing NAT in mobile networks? ryuji > My oppinion, > > Alex > > From nemo-bounces@ietf.org Wed Aug 10 09:54:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2r2T-000535-1l; Wed, 10 Aug 2005 09:54:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2r2P-00052Y-2k; Wed, 10 Aug 2005 09:54:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28921; Wed, 10 Aug 2005 09:54:31 -0400 (EDT) Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2raV-0007Ow-8h; Wed, 10 Aug 2005 10:29:48 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id j7AE7QGv000845; Wed, 10 Aug 2005 07:07:27 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id j7ADxG98027397; Wed, 10 Aug 2005 08:59:17 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 26255865980; Wed, 10 Aug 2005 15:54:18 +0200 (CEST) Message-ID: <42FA0709.1060208@motorola.com> Date: Wed, 10 Aug 2005 15:54:17 +0200 From: Alexandru Petrescu Organization: Motorola Labs, Paris, France User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Ryuji Wakikawa References: <42F8D955.9010605@motorola.com> <7F1AD8E3-716A-45C3-9F03-179CA14E38B5@sfc.wide.ad.jp> In-Reply-To: <7F1AD8E3-716A-45C3-9F03-179CA14E38B5@sfc.wide.ad.jp> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=Shift_JIS Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by motgate3.mot.com id j7AE7QGv000845 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Cc: "Soliman, Hesham" , nemo@ietf.org, Alexandru Petrescu , mip6@ietf.org Subject: [nemo] Re: mip6trans requirements (was: carrying IPv4 traffic using MIP6/NEMO) X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Vijay Paris slides and Ryuji Wakikawa wrote: >>> 1 Support NAT traversal, NAT detection and the ability to turn=20 >>> offthe NAT traversal mechanism when not required >>=20 >>> 2 Support the scenario where the Home Agent is behind a NAT and=20 >>> not accessible through a public address >>=20 >>> 3 Support dynamic discovery of the HA=81fs IPv4 address >>=20 >>> 4 Enable IPsec protection for the mip6trans tunnel. The Home=20 >>> Agentand the mobile node must be able to negotiate tunnel=20 >>> security associations for the mip6trans tunnel >>=20 >>> 5 Enable the mobile node to use its IPv4 Home Address for IPv4=20 >>> sessions over the mip6trans tunnel >>=20 >>> 6 Support dynamic allocation of the IPv4 Home Address >>>=20 >>=20 >> I'm for 1 and 4 and not for 2, 3, 5, 6. And I'd like to add=20 >> requirement 0: support IPv6 session continuity at a permanent=20 >> publicly-routable v6 Home Address when the MH connects to a=20 >> v4-exclusively network. >>=20 >> The requirements 2, 3, 5 and 6 are interesting - ok - but may=20 >> represent too much work. >=20 > Alex, I disagree on your proposition. I don't know how do you line=20 > between 1,4 and 2,3,5,6. I draw the line like this. 2 (Support HA behind NAT) has no potential solution as far as I know. 3 (DHAADv4) is an unknown protocol. 5 (v4 Home Address for MH) was out of scope initially, the scope was enable v6 Home Address for MH. 6 (dynamic allocation for v4 Home Address) is something that DHCP can do. Otherwise, do you agree with inserting a requirement number 0 that says "give IPv6 Home Address for session continuity and reachability to a MH that connects to an IPv4 access network"? Another requirement that was agreeingly proposed on the MIP6 mailing list was to support v6 HA that has no v4 connectivity. Do you agree with this requirement? > The requirements listed here were from the DT consensus. I acknowledge that. That's the way they were presented to the WG meeting. > On the other hand, one thing where keiichi pointed out is whether we > should include IPv4 MNP in No.5. And Hesham agreed. I agree they may have agreed on that point. > Then, the next question was that should we split documents for v4=20 > traversal and v4 session continuity. Let me try to understand. Do you mean splitting DT documents? Initially the DT was supposed to produce 1 scenario/reqs draft and 1 solution draft. Do you mean that instead of the one solution draft there'd be two complimentary solution drafts? I understand draft-soliman and draft-dsmip are not DT output. Alex From nemo-bounces@ietf.org Wed Aug 10 10:04:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2rCR-0000Mc-R0; Wed, 10 Aug 2005 10:04:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2rCP-0000M2-9b; Wed, 10 Aug 2005 10:04:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29604; Wed, 10 Aug 2005 10:04:51 -0400 (EDT) Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2rkS-0007jq-TJ; Wed, 10 Aug 2005 10:40:09 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate.mot.com (Motorola/Motgate) with ESMTP id j7AE4lLZ004405; Wed, 10 Aug 2005 07:04:47 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id j7AEAsGP023239; Wed, 10 Aug 2005 09:10:55 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id DCF64865980; Wed, 10 Aug 2005 16:04:43 +0200 (CEST) Message-ID: <42FA097B.1070904@motorola.com> Date: Wed, 10 Aug 2005 16:04:43 +0200 From: Alexandru Petrescu Organization: Motorola Labs, Paris, France User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Ryuji Wakikawa Subject: Re: [Mip6] Re: [nemo] carrying IPv4 traffic using MIP6/NEMO References: <42F877E9.8010304@motorola.com> <6ED12209-2B69-4F0D-84FA-489A5AC05E49@sfc.wide.ad.jp> <42F9FE4D.6030406@motorola.com> <4CC22A36-030D-4816-B86F-9E3D0BB3B345@sfc.wide.ad.jp> In-Reply-To: <4CC22A36-030D-4816-B86F-9E3D0BB3B345@sfc.wide.ad.jp> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: "Soliman, Hesham" , nemo@ietf.org, Alexandru Petrescu , mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Ryuji Wakikawa wrote: >> All in all, IMHO, mip6trans should not waste effort on giving v4 >> access to nodes in the moving network; if it does (because >> consensus) then > > We should work on v4 reachability, because MIP6 WG already has the > problem statement draft (draft-ietf-dsmip), And It makes sense to > have a similar/common solution, because both goals are to establish > tunnel between HA-MN after all. I am confused. dsmip problem statement is not mip6trans problem-statement/reqs/scenarios. The mip6trans and dsmip problem statements are different at least in size. In my understanding, I was thinking that the problem mip6trans is trying to solve was to give IPv6 access to a MH connecting to a v4 network. Or, this requirement is not even listed now in the mp6trans requirements. dsmip problem statement looks more wider reach, doing all v4/v6 mobility by extending only the Mobile IPv6 protocol. > The question may be whether we should split document or not?! If "split" means separate the dsmip documents and the mip6trans documents, goals, requirements, scenarios, I'd vote for it. If "split" means separate draft-soliman from draft-shima with respect to v4 access, I'd vote against. Better have a unique document that does Mobile IPv6-based dsmip-v4-access than two. But not for mip6trans. >> shouldn't do it with NAT. > > > Do you mean doing NAT in mobile networks? Yes, that's what I meant. In detail, if v4 access to nodes in the mobile network is to be developped anywhere, then don't do it in mip6trans and don't do it with NAT in the mobile network. Alex From nemo-bounces@ietf.org Wed Aug 10 10:08:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2rFU-00010t-63; Wed, 10 Aug 2005 10:08:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2rFT-00010M-3J; Wed, 10 Aug 2005 10:08:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00083; Wed, 10 Aug 2005 10:08:01 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2rnX-0007pe-Qn; Wed, 10 Aug 2005 10:43:19 -0400 Received: from [192.168.1.2] (unknown [168.126.248.3]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 8584C4CD21; Wed, 10 Aug 2005 23:07:40 +0900 (JST) In-Reply-To: <42FA0709.1060208@motorola.com> References: <42F8D955.9010605@motorola.com> <7F1AD8E3-716A-45C3-9F03-179CA14E38B5@sfc.wide.ad.jp> <42FA0709.1060208@motorola.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=SHIFT_JIS; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Ryuji Wakikawa Subject: Re: [nemo] Re: mip6trans requirements (was: carrying IPv4 traffic using MIP6/NEMO) Date: Wed, 10 Aug 2005 23:07:34 +0900 To: Alexandru Petrescu X-Mailer: Apple Mail (2.733) X-Spam-Score: 2.9 (++) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: quoted-printable Cc: "Soliman, Hesham" , nemo@ietf.org, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Alex On 2005/08/10, at 22:54, Alexandru Petrescu wrote: > Vijay Paris slides and Ryuji Wakikawa wrote: > >>>> 1 Support NAT traversal, NAT detection and the ability to turn >>>> offthe NAT traversal mechanism when not required >>>> >>> >>> >>>> 2 Support the scenario where the Home Agent is behind a NAT and >>>> not accessible through a public address >>>> >>> >>> >>>> 3 Support dynamic discovery of the HA=81fs IPv4 address >>>> >>> >>> >>>> 4 Enable IPsec protection for the mip6trans tunnel. The Home >>>> Agentand the mobile node must be able to negotiate tunnel >>>> security associations for the mip6trans tunnel >>>> >>> >>> >>>> 5 Enable the mobile node to use its IPv4 Home Address for IPv4 >>>> sessions over the mip6trans tunnel >>>> >>> >>> >>>> 6 Support dynamic allocation of the IPv4 Home Address >>>> >>>> >>> >>> I'm for 1 and 4 and not for 2, 3, 5, 6. And I'd like to add >>> requirement 0: support IPv6 session continuity at a permanent >>> publicly-routable v6 Home Address when the MH connects to a >>> v4-exclusively network. >>> >>> The requirements 2, 3, 5 and 6 are interesting - ok - but may >>> represent too much work. >>> >> >> Alex, I disagree on your proposition. I don't know how do you line >> between 1,4 and 2,3,5,6. >> > > I draw the line like this. 2 (Support HA behind NAT) has no potential > solution as far as I know. There were some comments to support this scenario. > 3 (DHAADv4) is an unknown protocol. we never say DHAADv4:-) > 5 (v4 > Home Address for MH) was out of scope initially, the scope was =20 > enable v6 > Home Address for MH. OK > 6 (dynamic allocation for v4 Home Address) is > something that DHCP can do. We may give just guideline how to acquire the address with existing =20 solutions. Nobody knows yet. > Otherwise, do you agree with inserting a requirement number 0 that =20 > says > "give IPv6 Home Address for session continuity and reachability to =20 > a MH > that connects to an IPv4 access network"? this is the base requirement. > Another requirement that was agreeingly proposed on the MIP6 mailing > list was to support v6 HA that has no v4 connectivity. Do you agree > with this requirement? No, I personally don't. > >> The requirements listed here were from the DT consensus. >> > > I acknowledge that. That's the way they were presented to the WG =20 > meeting. > > >> On the other hand, one thing where keiichi pointed out is whether we >> should include IPv4 MNP in No.5. And Hesham agreed. >> > > I agree they may have agreed on that point. > > >> Then, the next question was that should we split documents for v4 >> traversal and v4 session continuity. >> > > Let me try to understand. Do you mean splitting DT documents? > Initially the DT was supposed to produce 1 scenario/reqs draft and 1 > solution draft. Do you mean that instead of the one solution draft > there'd be two complimentary solution drafts? Sorry, it was not so clear. I refer the comment of Keiichi. What i thought was that DT produce a base spec for v4 traversal =20 (maybe tunnel establishment) and define additional document how to bind v4 HoA/MNP to the tunnel (MIP =20 tunnel/v4 traversal tunnel, whatever). This is just personal idea and hopefully catch the intention of keiichi. ryuji > I understand draft-soliman and draft-dsmip are not DT output. > > Alex > > From nemo-bounces@ietf.org Wed Aug 10 10:21:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2rSL-00069O-Mx; Wed, 10 Aug 2005 10:21:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2rSJ-00068o-3t; Wed, 10 Aug 2005 10:21:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01702; Wed, 10 Aug 2005 10:21:17 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2s0N-0008I3-IJ; Wed, 10 Aug 2005 10:56:35 -0400 Received: from [192.168.1.2] (unknown [168.126.248.3]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 49E344CCBB; Wed, 10 Aug 2005 23:20:59 +0900 (JST) In-Reply-To: <42FA097B.1070904@motorola.com> References: <42F877E9.8010304@motorola.com> <6ED12209-2B69-4F0D-84FA-489A5AC05E49@sfc.wide.ad.jp> <42F9FE4D.6030406@motorola.com> <4CC22A36-030D-4816-B86F-9E3D0BB3B345@sfc.wide.ad.jp> <42FA097B.1070904@motorola.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Subject: Re: [Mip6] Re: [nemo] carrying IPv4 traffic using MIP6/NEMO Date: Wed, 10 Aug 2005 23:20:52 +0900 To: Alexandru Petrescu X-Mailer: Apple Mail (2.733) X-Spam-Score: 2.9 (++) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: "Soliman, Hesham" , nemo@ietf.org, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Alex On 2005/08/10, at 23:04, Alexandru Petrescu wrote: > Ryuji Wakikawa wrote: > >>> All in all, IMHO, mip6trans should not waste effort on giving v4 >>> access to nodes in the moving network; if it does (because >>> consensus) then >>> >> >> We should work on v4 reachability, because MIP6 WG already has the >> problem statement draft (draft-ietf-dsmip), And It makes sense to >> have a similar/common solution, because both goals are to establish >> tunnel between HA-MN after all. >> > > I am confused. dsmip problem statement is not mip6trans > problem-statement/reqs/scenarios. > > The mip6trans and dsmip problem statements are different at least > in size. > In my understanding, I was thinking that the problem mip6trans is > trying > to solve was to give IPv6 access to a MH connecting to a v4 network. > Or, this requirement is not even listed now in the mp6trans > requirements. it is included. > dsmip problem statement looks more wider reach, doing all v4/v6 > mobility > by extending only the Mobile IPv6 protocol. > >> The question may be whether we should split document or not?! >> > > If "split" means separate the dsmip documents and the mip6trans > documents, goals, requirements, scenarios, I'd vote for it. > > If "split" means separate draft-soliman from draft-shima with > respect to > v4 access, I'd vote against. Better have a unique document that does > Mobile IPv6-based dsmip-v4-access than two. But not for mip6trans. I just tried to get back to the original question of keiichi:-) If we have a unique solution for MIP6 and NEMO v4 access, I am fine either way. >>> shouldn't do it with NAT. >>> >> >> >> Do you mean doing NAT in mobile networks? >> > > Yes, that's what I meant. In detail, if v4 access to nodes in the > mobile network is to be developped anywhere, then don't do it in > mip6trans and don't do it with NAT in the mobile network. If MR can get v4 HoA through Hesham idea, MR can do NAT without any modifications. I don't know whether we need additional modification after v4 HoA assignment. NAT is NAT:-) ryuji From nemo-bounces@ietf.org Wed Aug 10 10:24:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2rUw-0006ep-KQ; Wed, 10 Aug 2005 10:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2rUu-0006du-Hw; Wed, 10 Aug 2005 10:24:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01892; Wed, 10 Aug 2005 10:23:58 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2s2z-0008My-8i; Wed, 10 Aug 2005 10:59:16 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j7AEXYHd025612; Wed, 10 Aug 2005 07:33:38 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id j7AETAum009052; Wed, 10 Aug 2005 09:29:15 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id C5D3D8637E6; Wed, 10 Aug 2005 16:23:34 +0200 (CEST) Message-ID: <42FA0DE6.2040104@motorola.com> Date: Wed, 10 Aug 2005 16:23:34 +0200 From: Alexandru Petrescu Organization: Motorola Labs, Paris, France User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Keiichi SHIMA Subject: Re: [nemo] carrying IPv4 traffic using MIP6/NEMO References: <20050808.150050.259287104.keiichi@iijlab.net> In-Reply-To: <20050808.150050.259287104.keiichi@iijlab.net> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Keiichi, Ryuji (thanks for clarifying), Keiichi SHIMA wrote: > At the IETF MIP6 WG session, the design team talked about the > mechanism to bind an IPv4 home address to an IPv6 care-of address as > a transission mechanism. I think giving v6 access to a Mobile IPv6 MH connecting to a v4 access network should be the main requirement for the mip6trans DT. How this is achieved is another matter. The above paragraph proposes to bind an IPv4 Home Address to an IPv6 CoA. I would not propose to do so. The reason is that if MH is behind NAT (most likely v4 access networks that I think of are NAT'ed) so it makes no sense to bind a 192.168 CoA for a Global IPv6 Home Address. On the contrary, I'd propose use UDP NAT traversal from Mobile IPv4 and keep an IPv6 CoA on the tunnel. > I have submitted very similar mechanism for IPv4 networks as > draft-shima-nemo-v4prefix-00.txt, which binds IPv4 prefixes to an > IPv6 care-of address of a mobile router and provides IPv4 mobile > network functionarity on top of NEMO. > > I wonder if we should consider to integrate these two mechanism to > provide a single way to provide the mechanism to carry IPv4 traffic > for both a mobile host and a mobile router. Generally, adding a prefixlen field too is preferable. If WG and mip6trans decide to go with v4 CoA then try to look at prefixes too, so "integrate" yes. But, big but, I am against the mip6trans requiremnent that offers v4 access to MH; mip6trans just solve the case v6 access for Mobile IPv6 MH connecting to v4 network. Alex From nemo-bounces@ietf.org Wed Aug 10 10:28:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2rZQ-0007DK-GX; Wed, 10 Aug 2005 10:28:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2rZO-0007Cj-Iu; Wed, 10 Aug 2005 10:28:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02210; Wed, 10 Aug 2005 10:28:36 -0400 (EDT) From: Basavaraj.Patil@nokia.com Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2s7S-0008VM-TA; Wed, 10 Aug 2005 11:03:54 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j7AESRAF021893; Wed, 10 Aug 2005 17:28:30 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Aug 2005 17:28:30 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Aug 2005 09:28:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Re: [nemo] carrying IPv4 traffic using MIP6/NEMO Date: Wed, 10 Aug 2005 09:28:29 -0500 Message-ID: <456943D540CFC14A8D7138E64843F853016B9066@daebe101.NOE.Nokia.com> Thread-Topic: [Mip6] Re: [nemo] carrying IPv4 traffic using MIP6/NEMO Thread-Index: AcWdr4BRgmCbt8DgSgu7LP8eRi72xQAB7p/Q To: , X-OriginalArrivalTime: 10 Aug 2005 14:28:28.0890 (UTC) FILETIME=[C6BEDBA0:01C59DB7] X-Spam-Score: 0.3 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Cc: H.Soliman@flarion.com, nemo@ietf.org, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Alex, > >I agree using NAT in the mobile network is possible. I also agree that >if NAT is used in the mobile network then there can be no mip6trans >requirement for reachability at a permanent v4 address (behind NAT the >v4 nodes are not reachable, somebody can't connect() to them). Well reachability using an IP(v4) address is difficult in the case the MN has a NATed address. However for various types of applications and scenarios the v4 address is useful to have for the MN (even if it is not a globally routable address). > >All in all, IMHO, mip6trans should not waste effort on giving v4 access >to nodes in the moving network; if it does (because consensus) then >shouldn't do it with NAT. Enabling a MIP6 node to send/receive v4 packets is useful and worth doing in the current scope. -Raj > >My oppinion, > >Alex > > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www1.ietf.org/mailman/listinfo/mip6 > From nemo-bounces@ietf.org Wed Aug 10 10:54:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2ry0-0007Nl-Tc; Wed, 10 Aug 2005 10:54:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2rxx-0007Lb-D1; Wed, 10 Aug 2005 10:54:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03963; Wed, 10 Aug 2005 10:53:59 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2sW4-0000so-3R; Wed, 10 Aug 2005 11:29:17 -0400 Received: from az33exr02.mot.com ([10.64.251.232]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j7AF3q93002709; Wed, 10 Aug 2005 08:03:52 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id j7AEwrnt005420; Wed, 10 Aug 2005 09:58:54 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 2FD45865980; Wed, 10 Aug 2005 16:53:55 +0200 (CEST) Message-ID: <42FA1503.9080903@motorola.com> Date: Wed, 10 Aug 2005 16:53:55 +0200 From: Alexandru Petrescu Organization: Motorola Labs, Paris, France User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com Subject: Re: [Mip6] Re: [nemo] carrying IPv4 traffic using MIP6/NEMO References: <456943D540CFC14A8D7138E64843F853016B9066@daebe101.NOE.Nokia.com> In-Reply-To: <456943D540CFC14A8D7138E64843F853016B9066@daebe101.NOE.Nokia.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, mip6@ietf.org, Alexandru Petrescu , H.Soliman@flarion.com, ryuji@sfc.wide.ad.jp X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Raj, Basavaraj.Patil@nokia.com wrote: >> I agree using NAT in the mobile network is possible. I also agree >> that if NAT is used in the mobile network then there can be no >> mip6trans requirement for reachability at a permanent v4 address >> (behind NAT the v4 nodes are not reachable, somebody can't >> connect() to them). > > > Well reachability using an IP(v4) address is difficult in the case > the MN has a NATed address. However for various types of applications > and scenarios the v4 address is useful to have for the MN (even if it > is not a globally routable address). I agree. >> All in all, IMHO, mip6trans should not waste effort on giving v4 >> access to nodes in the moving network; if it does (because >> consensus) then shouldn't do it with NAT. > > > Enabling a MIP6 node to send/receive v4 packets is useful and worth > doing in the current scope. Raj, I do not oppose an IPv6 MH connecting to the v4 access network to also have v4 access (just as it did until now). That access can be withou reachability, without session continuity, as it is today. It's just that I don't feel there should be a requirement on mip6trans to "support" or "enable" this in any way. It just is there and mip6trans protocol shouldn't block it. Making a mip6trans requirement for v4 access on MH leads to v4 access to nodes in moving network too, etc. This is clearly out of scope for mip6trans, IMHO. Alex From nemo-bounces@ietf.org Wed Aug 10 11:09:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2sCa-0004Qn-5P; Wed, 10 Aug 2005 11:09:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2sCY-0004QA-5o; Wed, 10 Aug 2005 11:09:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04911; Wed, 10 Aug 2005 11:09:01 -0400 (EDT) Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2skc-0001Li-4b; Wed, 10 Aug 2005 11:44:19 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id j7AFFet4006981; Wed, 10 Aug 2005 08:15:40 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id j7AFDaKA009615; Wed, 10 Aug 2005 10:13:37 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 3DCBF865980; Wed, 10 Aug 2005 17:08:53 +0200 (CEST) Message-ID: <42FA1885.2090800@motorola.com> Date: Wed, 10 Aug 2005 17:08:53 +0200 From: Alexandru Petrescu Organization: Motorola Labs, Paris, France User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Ryuji Wakikawa Subject: Re: [Mip6] Re: [nemo] carrying IPv4 traffic using MIP6/NEMO References: <42F877E9.8010304@motorola.com> <6ED12209-2B69-4F0D-84FA-489A5AC05E49@sfc.wide.ad.jp> <42F9FE4D.6030406@motorola.com> <4CC22A36-030D-4816-B86F-9E3D0BB3B345@sfc.wide.ad.jp> <42FA097B.1070904@motorola.com> In-Reply-To: X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: "Soliman, Hesham" , nemo@ietf.org, Alexandru Petrescu , mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Ryuji Wakikawa wrote: > Alex > > On 2005/08/10, at 23:04, Alexandru Petrescu wrote: > >> Ryuji Wakikawa wrote: >> >>>> All in all, IMHO, mip6trans should not waste effort on giving v4 >>>> access to nodes in the moving network; if it does (because >>>> consensus) then >>>> >>> >>> We should work on v4 reachability, because MIP6 WG already has the >>> problem statement draft (draft-ietf-dsmip), And It makes sense to >>> have a similar/common solution, because both goals are to establish >>> tunnel between HA-MN after all. >>> >> >> I am confused. dsmip problem statement is not mip6trans >> problem-statement/reqs/scenarios. >> >> The mip6trans and dsmip problem statements are different at least in >> size. >> In my understanding, I was thinking that the problem mip6trans is trying >> to solve was to give IPv6 access to a MH connecting to a v4 network. >> Or, this requirement is not even listed now in the mp6trans >> requirements. > > > it is included. Sorry, mistake, I think I've missed it when copy/paste. I've looked again and it's there. Alex From nemo-bounces@ietf.org Mon Aug 15 10:18:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4fna-0006mH-9G; Mon, 15 Aug 2005 10:18:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4fnY-0006lj-AP; Mon, 15 Aug 2005 10:18:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05410; Mon, 15 Aug 2005 10:18:39 -0400 (EDT) Received: from bay106-f35.bay106.hotmail.com ([65.54.161.45] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4gMc-0008Fj-Dz; Mon, 15 Aug 2005 10:55:00 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 15 Aug 2005 07:18:29 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Mon, 15 Aug 2005 14:18:29 GMT X-Originating-IP: [65.54.161.200] X-Originating-Email: [amin_abdul@hotmail.com] X-Sender: amin_abdul@hotmail.com From: "Amin Abdul" To: mip4@ietf.org Date: Mon, 15 Aug 2005 14:18:29 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 15 Aug 2005 14:18:29.0734 (UTC) FILETIME=[35AFA860:01C5A1A4] X-Spam-Score: 0.8 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: nemo@ietf.org Subject: [nemo] IPv4: Mobile IP Lite (Host/Network Mobility) X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Any comments/questions are welcome: Objectives: 1. Re-thinking IPv4 Mobility design. 2. Take advantage of last ~10 years of IPv4 evolution 3. simplified design by removing redundant\unused\unusable objects 4. Design reused Issues: 1. IPv4 Mobility model pre-dates some recents developments in IPv4 2. IPv4 Mobility model develop in parallel with widely deployed changes in IPv4 without taking into account those changes 3. In recent years, it seems that IPv4 mobility model is bit ignore because of the push for IPv6. Mobile IP Lite: Frameworks: A. Host Mobility framework: ------------------------------------------ | Mobile Node | | Objects: | - Registration | - Co-located Care-OF-Addr | - DHCP Client | - UDP/IP Tunnel | - DNA (Detecting Network Attachment) | - Cookies (depends) (such as AAA Cookies) | - Optional tunnel Feature Profile |------------------------------------------- | | | -------------------------------------------- | Access Network | | Objects: | - Access Point | - DHCP Relay/Server | - AAA Client/Proxy (depends) | - Cookies (depends) (such as AAA Cookies) | - NAT (depends) |-------------------------------------------- | | | ------------------------------------- | Home Agent | | Objects: | - Registration | - Binding Information | - UDP/IP Tunnel | - Optional tunnel Feature Profile | - Header Compression | - Data Compression | - Content Adaptation | - Packet Buffering | - Encryption | - Proxying/Caching | - Congestion Control | - QoS | - etc... |------------------------------------- | | ------------------------ | Corresponding Node |----------------------- Please note that: 1. No Foreign Agent (FA) 2. Mobile Node Don't care about the nature of co-located care-of-addr, is it public or private 3. Simply Tunnel options - UDP/IP only 4. Usage of cookies for stateful information (such as AAA). Scope could be intra/inter domains 5. Customized tunnel features according to user(s) needs 6. AAA can be reuse for IP information as well (such as IP address, IP netmask ...) B. Network Mobility framework: ------------------------ ----------------------- | IP Enabled Device 1 | | IP Enabled Device 2 | ------------------------ ----------------------- | | | | ------------------------------------------ | Mobile Router | | Objects: | - Registration | - Co-located Care-OF-Addr | - DHCP Client | - UDP/IP Tunnel | - DNA (Detecting Network Attachment) | - Cookies (depends) (such as AAA Cookies) | - Optional tunnel Feature Profile | - IP forwarding | - NAT |------------------------------------------- | | | -------------------------------------------- | Access Network | | Objects: | - Access Point | - DHCP Relay/Server | - AAA Client/Proxy (depends) | - Cookies (depends) (such as AAA Cookies) | - NAT (depends) |-------------------------------------------- | | | ------------------------------------- | Home Agent | | Objects: | - Registration | - Binding Information | - UDP/IP Tunnel | - Optional tunnel Feature Profile | - Header Compression | - Data Compression | - Content Adaptation | - Packet Buffering | - Encryption | - Proxying/Caching | - Congestion Control | - QoS | - etc... |------------------------------------- | | ------------------------ | Corresponding Node |----------------------- Please note that only changes are: 1. Mobile Router supports IP forwarding 2. Mobile Router supports NAT Any comments/questions are welcome. /Amin 1 (519) 721 3301 From nemo-bounces@ietf.org Tue Aug 16 04:51:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4xA2-0006vg-5q; Tue, 16 Aug 2005 04:51:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4x9z-0006v9-Di; Tue, 16 Aug 2005 04:51:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28211; Tue, 16 Aug 2005 04:51:01 -0400 (EDT) Received: from omgo.iij.ad.jp ([202.232.30.157]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4xjH-0002g1-8c; Tue, 16 Aug 2005 05:27:32 -0400 Received: OTM-MO id j7G8olKV023752; Tue, 16 Aug 2005 17:50:47 +0900 (JST) Received: OTM-MIX0 id j7G8okBn011151; Tue, 16 Aug 2005 17:50:46 +0900 (JST) Received: from localhost (keiichi00.osaka.iij.ad.jp [192.168.64.45]) by jc-smtp.iij.ad.jp (JC-SMTP/jc-smtp) id j7G8okEN003538; Tue, 16 Aug 2005 17:50:46 +0900 (JST) Date: Tue, 16 Aug 2005 17:52:02 +0900 (JST) Message-Id: <20050816.175202.22797246.keiichi@iijlab.net> To: ryuji@sfc.wide.ad.jp Subject: Re: [nemo] Re: mip6trans requirements From: Keiichi SHIMA In-Reply-To: References: <7F1AD8E3-716A-45C3-9F03-179CA14E38B5@sfc.wide.ad.jp> <42FA0709.1060208@motorola.com> X-Mailer: Mew version 4.1.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: H.Soliman@flarion.com, nemo@ietf.org, alexandru.petrescu@motorola.com, mip6@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org From: Ryuji Wakikawa Date: Wed, 10 Aug 2005 23:07:34 +0900 > > Let me try to understand. Do you mean splitting DT documents? > > Initially the DT was supposed to produce 1 scenario/reqs draft and 1 > > solution draft. Do you mean that instead of the one solution draft > > there'd be two complimentary solution drafts? > > Sorry, it was not so clear. I refer the comment of Keiichi. > What i thought was that DT produce a base spec for v4 traversal > (maybe tunnel establishment) and > define additional document how to bind v4 HoA/MNP to the tunnel (MIP > tunnel/v4 traversal tunnel, whatever). > This is just personal idea and hopefully catch the intention of keiichi. Yes, the above comment catches my intention. I think providing an IPv4 HoA and (multiple) IPv4 home networks to a mobile router is an important feature. The question is whether the specification must be discussed with traversal mechanisms or not. I personally think these ideas (the mechanism for v4traversal and the mechanism to provide v4 access) can be documented separately. The v4 traversal document specifies the mechanism to provide an IPv4 address as a CoA. The v4 access document will provide the mechanism to put additional identifiers (a v4 HoA and v4 MNPs). I don't think these two mechanisms depend each other tightly. (or, does it?) Both specifications may be produced inside the DT or may not. It depends on the decision of the DT members. (BTW, I personally think v4 access mechanisms are out of scope of the DT for v4traversal, though) But, at least splitting orthogonal (it looks so to me) ideas are a good way to keep specs simple.. Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project From nemo-bounces@ietf.org Wed Aug 17 07:46:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5MMz-0007Ej-AF; Wed, 17 Aug 2005 07:46:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5MMw-0007Bm-IS for nemo@megatron.ietf.org; Wed, 17 Aug 2005 07:46:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23147 for ; Wed, 17 Aug 2005 07:46:05 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5MwR-0004ed-DH for nemo@ietf.org; Wed, 17 Aug 2005 08:22:50 -0400 Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0ILD00J8C7CDR6@mailout2.samsung.com> for nemo@ietf.org; Wed, 17 Aug 2005 20:45:49 +0900 (KST) Received: from sameerk ([107.108.71.68]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPSA id <0ILD007167BTV8@mmp2.samsung.com> for nemo@ietf.org; Wed, 17 Aug 2005 20:45:49 +0900 (KST) Date: Wed, 17 Aug 2005 17:10:44 +0530 From: Sameer Kumar To: nemo@ietf.org Message-id: <000001c5a320$962b0590$44476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: multipart/alternative; boundary="Boundary_(ID_a+l+jMQo/APW7kfQOUrNdA)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 Subject: [nemo] Split Networks:Query X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_a+l+jMQo/APW7kfQOUrNdA) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi all, I have a doubt regarding the concept of "Split Networks" in NEMO. Split Networks comprise the case (n,1,1): Multiple MRs, Single HA, Single MNP. Figure 1. below depicts the Split Network scenario. No "split" has occured. MR1 and MR2 are together. MR1 | _ | |-|_|-| _____ | p<- |-| | _ | _ _ | | | |-|_|--|-|_|HA MNN|_|-| | | | AR | | _ |-|_____| |-|_|-| INTERNET |p<- | MR2 Figure 1: (n,1,1): Multiple MRs, 1 HA, 1 MNP In this case, HA can send packets destined to MNN via MR1, or MR2 (Load Balancing). The same situation in a wireless deployment is shown in Figure 2. Here also, we consider the case when no "split" has occurred i.e. MR1 and MR2 are together. AP1 MR1 _ _ _ | / |_|---|_|-| _____ _ / p<- |-| | _ | _ MNN|_| | | |-|_|--|-|_|HA | | | AR | _ _ |-|_____| |_|---|_|-| INTERNET p<- | AP2 MR2 Figure 2: (n,1,1) : Multiple MRs, 1 HA, 1 MNP in a Wireless Scenario In Figure 2. MNN is currently attached to the Access Point (AP1) of MR1. I have the following questions: a)If HA tries to send packets to MNN via MR2, how will these packets reach MNN? Basically how is "Load Balancing" possible for a case (n,1,1) in a practical wireless deployment? b)Is it that the AP1 and AP2 are "physically connected"? If so, then does the term "split" means a "physical split"? Thanks and Regards, Sameer Kumar. --Boundary_(ID_a+l+jMQo/APW7kfQOUrNdA) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

Hi all,

      I have a doubt regarding the concept of "Split Networks" in NEMO. Split Networks comprise the case (n,1,1): Multiple MRs, Single HA, Single MNP.

   Figure 1. below depicts the Split Network scenario. No "split" has occured. MR1 and MR2 are together.

 

                        MR1

                      |  _  |

                      |-|_|-|  _____ 

                      | p<- |-|     |  _   |  _

                   _  |     | |     |-|_|--|-|_|HA

               MNN|_|-|     | |     |  AR  |

                      |  _  |-|_____|

                      |-|_|-| INTERNET 

                      |p<-  |

                        MR2

 

              Figure 1: (n,1,1): Multiple MRs, 1 HA, 1 MNP

 

In this case, HA can send packets destined to MNN via MR1, or MR2 (Load Balancing). The same situation in a wireless deployment is shown in Figure 2. Here also, we consider the case when no "split" has occurred i.e. MR1 and MR2 are together.

 

 

                               AP1   MR1

                              _ _     _  |

                             / |_|---|_|-|  _____ 

                          _ /  p<-       |-|     |  _   |  _

                      MNN|_|             | |     |-|_|--|-|_|HA

                                         | |     |  AR  |

                                _     _  |-|_____|

                               |_|---|_|-| INTERNET 

                              p<-        |

                               AP2   MR2

 

                     Figure 2: (n,1,1) : Multiple MRs, 1 HA, 1 MNP in a Wireless Scenario

 

In Figure 2. MNN is currently attached to the Access Point (AP1) of MR1. I have the following questions:

 

a)If HA tries to send packets to MNN via MR2, how will these packets reach MNN? Basically how is "Load Balancing"

  possible for a case (n,1,1) in a practical wireless deployment?

b)Is it that the AP1 and AP2 are "physically connected"? If so, then does the term "split" means a "physical split"?

 

Thanks and Regards,

Sameer Kumar.

 

 

                 

 

 

 

--Boundary_(ID_a+l+jMQo/APW7kfQOUrNdA)-- From nemo-bounces@ietf.org Wed Aug 17 08:10:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Mkn-0004fS-VF; Wed, 17 Aug 2005 08:10:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Mkl-0004e8-Se for nemo@megatron.ietf.org; Wed, 17 Aug 2005 08:10:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24672 for ; Wed, 17 Aug 2005 08:10:42 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5NKI-0005P8-NE for nemo@ietf.org; Wed, 17 Aug 2005 08:47:27 -0400 Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0ILD00JS18HGR6@mailout2.samsung.com> for nemo@ietf.org; Wed, 17 Aug 2005 21:10:28 +0900 (KST) Received: from sameerk ([107.108.71.68]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPSA id <0ILD004YD8GUJO@mmp2.samsung.com> for nemo@ietf.org; Wed, 17 Aug 2005 21:10:28 +0900 (KST) Date: Wed, 17 Aug 2005 17:35:44 +0530 From: Sameer Kumar To: nemo@ietf.org Message-id: <000c01c5a324$08b05090$44476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: multipart/alternative; boundary="Boundary_(ID_ooPiaEpXP20BhQE4vs2Cxw)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: 4d9ae72af46718088458d214998cc683 Subject: [nemo] Split Networks:Query X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_ooPiaEpXP20BhQE4vs2Cxw) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi all, I have a doubt regarding the concept of "Split Networks" in NEMO. Split Networks comprise the case (n,1,1): Multiple MRs, Single HA, Single MNP. Figure 1. below depicts the Split Network scenario. No "split" has occured. MR1 and MR2 are together. MR1 | _ | |-|_|-| _____ | p<- |-| | _ | _ _ | | | |-|_|--|-|_|HA MNN|_|-| | | | AR | | _ |-|_____| |-|_|-| INTERNET |p<- | MR2 Figure 1: (n,1,1): Multiple MRs, 1 HA, 1 MNP In this case, HA can send packets destined to MNN via MR1, or MR2 (Load Balancing). The same situation in a wireless deployment is shown in Figure 2. Here also, we consider the case when no "split" has occurred i.e. MR1 and MR2 are together. AP1 MR1 _ _ _ | / |_|---|_|-| _____ _ / p<- |-| | _ | _ MNN|_| | | |-|_|--|-|_|HA | | | AR | _ _ |-|_____| |_|---|_|-| INTERNET p<- | AP2 MR2 Figure 2: (n,1,1) : Multiple MRs, 1 HA, 1 MNP in a Wireless Scenario In Figure 2. MNN is currently attached to the Access Point (AP1) of MR1. I have the following questions: a)If HA tries to send packets to MNN via MR2, how will these packets reach MNN? Basically how is "Load Balancing" possible for a case (n,1,1) in a practical wireless deployment? b)Is it that the AP1 and AP2 are "physically connected"? If so, then does the term "split" means a "physical split"? Thanks and Regards, Sameer Kumar. --Boundary_(ID_ooPiaEpXP20BhQE4vs2Cxw) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

 

Hi all,

      I have a doubt regarding the concept of "Split Networks" in NEMO. Split Networks comprise the case (n,1,1): Multiple MRs, Single HA, Single MNP.

   Figure 1. below depicts the Split Network scenario. No "split" has occured. MR1 and MR2 are together.

 

                        MR1

                      |  _  |

                      |-|_|-|  _____ 

                      | p<- |-|     |  _   |  _

                   _  |     | |     |-|_|--|-|_|HA

               MNN|_|-|     | |     |  AR  |

                      |  _  |-|_____|

                      |-|_|-| INTERNET 

                      |p<-  |

                        MR2

 

              Figure 1: (n,1,1): Multiple MRs, 1 HA, 1 MNP

 

In this case, HA can send packets destined to MNN via MR1, or MR2 (Load Balancing). The same situation in a wireless deployment is shown in Figure 2. Here also, we consider the case when no "split" has occurred i.e. MR1 and MR2 are together.

 

 

                               AP1   MR1

                              _ _     _  |

                             / |_|---|_|-|  _____ 

                          _ /  p<-       |-|     |  _   |  _

                      MNN|_|             | |     |-|_|--|-|_|HA

                                         | |     |  AR  |

                                _     _  |-|_____|

                               |_|---|_|-| INTERNET 

                              p<-        |

                               AP2   MR2

 

                     Figure 2: (n,1,1) : Multiple MRs, 1 HA, 1 MNP in a Wireless Scenario

 

In Figure 2. MNN is currently attached to the Access Point (AP1) of MR1. I have the following questions:

 

a)If HA tries to send packets to MNN via MR2, how will these packets reach MNN? Basically how is "Load Balancing"

  possible for a case (n,1,1) in a practical wireless deployment?

b)Is it that the AP1 and AP2 are "physically connected"? If so, then does the term "split" means a "physical split"?

 

Thanks and Regards,

Sameer Kumar.

 

 

                 

 

 

 

--Boundary_(ID_ooPiaEpXP20BhQE4vs2Cxw)-- From nemo-bounces@ietf.org Wed Aug 17 09:21:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Nqz-0004FD-3Q; Wed, 17 Aug 2005 09:21:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Nqw-0004Ez-Ow for nemo@megatron.ietf.org; Wed, 17 Aug 2005 09:21:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29644 for ; Wed, 17 Aug 2005 09:21:07 -0400 (EDT) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5OQN-0007h0-Bj for nemo@ietf.org; Wed, 17 Aug 2005 09:57:53 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 2BB28711F6; Wed, 17 Aug 2005 15:20:48 +0200 (CEST) Received: from [163.117.203.145] (unknown [163.117.203.145]) by smtp01.uc3m.es (Postfix) with ESMTP id A3A3871147; Wed, 17 Aug 2005 15:20:45 +0200 (CEST) In-Reply-To: <000001c5a320$962b0590$44476c6b@sisodomain.com> References: <000001c5a320$962b0590$44476c6b@sisodomain.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] Split Networks:Query Date: Wed, 17 Aug 2005 15:21:33 +0200 To: Sameer Kumar X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Sameer, El 17/08/2005, a las 13:40, Sameer Kumar escribi=F3: > Hi all, > =A0=A0=A0=A0=A0 I have a doubt regarding the concept of "Split = Networks" in=20 > NEMO. Split Networks comprise the case (n,1,1): Multiple MRs, Single=20= > HA, Single MNP. > =A0=A0 Figure 1. below depicts the Split Network scenario. No "split" = has=20 > occured. MR1 and MR2 are together. > =A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = MR1 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 = _=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |-|_|-|=A0 _____=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | p<- = |-|=A0=A0=A0=A0 |=A0 _=A0=A0 |=A0 _ > =A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0_=A0 |=A0=A0=A0=A0= | |=A0=A0=A0=A0 |-|_|--|-|_|HA > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 MNN|_|-|=A0=A0=A0=A0 | = |=A0=A0=A0=A0 |=A0 AR=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 = _=A0 |-|_____| > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |-|_|-| INTERNET=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0 |p<-=A0 = | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = MR2 > =A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Figure 1: (n,1,1): Multiple = MRs, 1 HA, 1 MNP > =A0 > In this case, HA can send packets destined to MNN via MR1, or MR2=20 > (Load Balancing). so far so good > The same situation in a wireless deployment is shown in Figure 2.=20 > Here also, we consider the case when no "split" has occurred i.e. MR1=20= > and MR2 are together. > =A0 > =A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 AP1=A0=A0 MR1 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 _ _=A0=A0=A0=A0 _=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 / |_|---|_|-|=A0 _____=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 _ /=A0 p<-=A0=A0=A0=A0=A0=A0 |-|=A0=A0=A0=A0 |=A0 _=A0=A0 |=A0 _ > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = MNN|_|=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0| |=A0=A0=A0=A0 = |-|_|--|-|_|HA > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | |=A0=A0=A0=A0 |=A0 = AR=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 _=A0=A0=A0=A0 _=A0 |-|_____| > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 |_|---|_|-| INTERNET=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 p<-=A0=A0=A0=A0=A0=A0=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 AP2=A0=A0 MR2 > =A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Figure 2: = (n,1,1) : Multiple MRs, 1 HA, 1 MNP in=20 > a Wireless Scenario > =A0 I am not sure i understand this scenario... I mean as i see this case 2, the network has already split and in order=20= to deal with this situation, you would need additional mechanisms,=20 since MR1 and MR2 only connect themselves through the internet (i.e.=20 the nemo is split) In this case the difficulty is to detect that the nemo has split and to=20= be able to determine which MNN are in which part of the nemo,=20 especially when you have a single MNP. For this you would need=20 additional mechanisms and/or to impose certain contraints, like=20 requiring that each MR has its own prefix assoicated, so that when they=20= split, the MR can take its MNP with it. /this configuration is not=20 without problems of its own, like ingress filtering compatibility and=20 so on) so... > In Figure 2. MNN is currently attached to the Access Point (AP1) of=20 > MR1. I have the following questions: > =A0 > a)If HA tries to send packets to MNN via MR2, how will these packets=20= > reach MNN? they can't without additional mechanisms imho > Basically how is "Load Balancing" > =A0 possible for a case (n,1,1) in a practical wireless deployment? not sure what you mean > b)Is it that the AP1 and AP2 are "physically connected"? If so, then=20= > does the term "split" means a "physical split"? > =A0 AP1 and AP2 are connected through the internet and not thorugh the nemo=20= as i see it, so they don't belong to the same nemo, that is why they=20 are split regards, marcelo > Thanks and Regards, > Sameer Kumar. > =A0 > =A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0 > =A0 > =A0 From nemo-bounces@ietf.org Wed Aug 17 10:02:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5OV8-0006zp-Fd; Wed, 17 Aug 2005 10:02:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5OV4-0006zf-6I for nemo@megatron.ietf.org; Wed, 17 Aug 2005 10:02:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01858 for ; Wed, 17 Aug 2005 10:02:35 -0400 (EDT) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5P4a-0000QO-Gi for nemo@ietf.org; Wed, 17 Aug 2005 10:39:22 -0400 Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0ILD008J7DNWCF@mailout1.samsung.com> for nemo@ietf.org; Wed, 17 Aug 2005 23:02:20 +0900 (KST) Received: from sameerk ([107.108.71.68]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPSA id <0ILD007Y3DNDV8@mmp2.samsung.com> for nemo@ietf.org; Wed, 17 Aug 2005 23:02:20 +0900 (KST) Date: Wed, 17 Aug 2005 19:27:27 +0530 From: Sameer Kumar Subject: RE: [nemo] Split Networks:Query In-reply-to: To: "'marcelo bagnulo braun'" Message-id: <001301c5a333$a3bb5530$44476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Marcelo, Thanks for the prompt reply. I think I couldn't convey my question clearly in my last mail. Let me put it this way: - In case of a wireless network ( case (n,1,1)) with MR1 advertising = through AP1, and MR2 advertising through AP2, and "NO SPLIT" has occurred, how = is it possible for an MNN to receive packets from both MR1 and MR2? I just want to clarify how an (n,1,1) network is deployed in a wireless scenario such that MNN can receive packets from all the MRs. Thanks and Regards, Sameer Kumar. -----Original Message----- From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 Sent: Wednesday, August 17, 2005 6:52 PM To: Sameer Kumar Cc: nemo@ietf.org Subject: Re: [nemo] Split Networks:Query Hi Sameer, El 17/08/2005, a las 13:40, Sameer Kumar escribi=F3: > Hi all, > =A0=A0=A0=A0=A0 I have a doubt regarding the concept of "Split = Networks" in=20 > NEMO. Split Networks comprise the case (n,1,1): Multiple MRs, Single=20 > HA, Single MNP. > =A0=A0 Figure 1. below depicts the Split Network scenario. No "split" = has=20 > occured. MR1 and MR2 are together. > =A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = MR1 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 = _=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |-|_|-|=A0 _____=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | p<- = |-|=A0=A0=A0=A0 |=A0 _=A0=A0 |=A0 _ > =A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0_=A0 = |=A0=A0=A0=A0 | |=A0=A0=A0=A0 |-|_|--|-|_|HA > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 MNN|_|-|=A0=A0=A0=A0 | = |=A0=A0=A0=A0 |=A0 AR=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 = _=A0 |-|_____| > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |-|_|-| INTERNET=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0 |p<-=A0 = | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = MR2 > =A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Figure 1: (n,1,1): Multiple = MRs, 1 HA, 1 MNP > =A0 > In this case, HA can send packets destined to MNN via MR1, or MR2=20 > (Load Balancing). so far so good > The same situation in a wireless deployment is shown in Figure 2.=20 > Here also, we consider the case when no "split" has occurred i.e. MR1=20 > and MR2 are together. > =A0 > =A0 > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 AP1=A0=A0 MR1 > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 _ _=A0=A0=A0=A0 _=A0 | > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 / |_|---|_|-|=A0 _____=A0 > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= _ /=A0 p<-=A0=A0=A0=A0=A0=A0 |-|=A0=A0=A0=A0 |=A0 _=A0=A0 |=A0 _ > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = MNN|_|=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0| |=A0=A0=A0=A0 = |-|_|--|-|_|HA > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | |=A0=A0=A0=A0 |=A0 AR=A0 = | > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 _=A0=A0=A0=A0 _=A0 |-|_____| > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 |_|---|_|-| INTERNET=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 p<-=A0=A0=A0=A0=A0=A0=A0 | > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 AP2=A0=A0 MR2 > =A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Figure 2: = (n,1,1) : Multiple MRs, 1 HA, 1 MNP in=20 > a Wireless Scenario > =A0 I am not sure i understand this scenario... I mean as i see this case 2, the network has already split and in order=20 to deal with this situation, you would need additional mechanisms,=20 since MR1 and MR2 only connect themselves through the internet (i.e.=20 the nemo is split) In this case the difficulty is to detect that the nemo has split and to=20 be able to determine which MNN are in which part of the nemo,=20 especially when you have a single MNP. For this you would need=20 additional mechanisms and/or to impose certain contraints, like=20 requiring that each MR has its own prefix assoicated, so that when they=20 split, the MR can take its MNP with it. /this configuration is not=20 without problems of its own, like ingress filtering compatibility and=20 so on) so... > In Figure 2. MNN is currently attached to the Access Point (AP1) of=20 > MR1. I have the following questions: > =A0 > a)If HA tries to send packets to MNN via MR2, how will these packets=20 > reach MNN? they can't without additional mechanisms imho > Basically how is "Load Balancing" > =A0 possible for a case (n,1,1) in a practical wireless deployment? not sure what you mean > b)Is it that the AP1 and AP2 are "physically connected"? If so, then=20 > does the term "split" means a "physical split"? > =A0 AP1 and AP2 are connected through the internet and not thorugh the nemo=20 as i see it, so they don't belong to the same nemo, that is why they=20 are split regards, marcelo > Thanks and Regards, > Sameer Kumar. > =A0 > =A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0 > =A0 > =A0 From nemo-bounces@ietf.org Wed Aug 17 10:45:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5PAh-0000mm-8C; Wed, 17 Aug 2005 10:45:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5PAf-0000me-87 for nemo@megatron.ietf.org; Wed, 17 Aug 2005 10:45:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05114 for ; Wed, 17 Aug 2005 10:45:33 -0400 (EDT) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5PkB-0001Zb-S7 for nemo@ietf.org; Wed, 17 Aug 2005 11:22:20 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 48EE1702EF; Wed, 17 Aug 2005 16:45:25 +0200 (CEST) Received: from [163.117.203.145] (unknown [163.117.203.145]) by smtp01.uc3m.es (Postfix) with ESMTP id 486326FF1E; Wed, 17 Aug 2005 16:45:22 +0200 (CEST) In-Reply-To: <001301c5a333$a3bb5530$44476c6b@sisodomain.com> References: <001301c5a333$a3bb5530$44476c6b@sisodomain.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] Split Networks:Query Date: Wed, 17 Aug 2005 16:45:28 +0200 To: Sameer Kumar X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org El 17/08/2005, a las 15:57, Sameer Kumar escribi=F3: > Hi Marcelo, > Thanks for the prompt reply. I think I couldn't convey my > question clearly in my last mail. Let me put it this way: > - In case of a wireless network ( case (n,1,1)) with MR1 advertising=20= > through > AP1, and MR2 advertising through AP2, I guess i am failing to understand the scenario... let me ask: are MR1=20= and MR2 connected through the nemo or are only connected through the=20 Internet? Regards, marcelo > and "NO SPLIT" has occurred, how is it > possible for an MNN to receive packets from both MR1 and MR2? > > I just want to clarify how an (n,1,1) network is deployed in a = wireless > scenario such that MNN can receive packets from all the MRs. > > Thanks and Regards, > Sameer Kumar. > > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > Sent: Wednesday, August 17, 2005 6:52 PM > To: Sameer Kumar > Cc: nemo@ietf.org > Subject: Re: [nemo] Split Networks:Query > > Hi Sameer, > > El 17/08/2005, a las 13:40, Sameer Kumar escribi=F3: > >> Hi all, >> =A0=A0=A0=A0=A0 I have a doubt regarding the concept of "Split = Networks" in >> NEMO. Split Networks comprise the case (n,1,1): Multiple MRs, Single >> HA, Single MNP. >> =A0=A0 Figure 1. below depicts the Split Network scenario. No "split" = has >> occured. MR1 and MR2 are together. >> =A0 >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = MR1 >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 = _=A0 | >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |-|_|-|=A0 _____=A0 >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | p<- = |-|=A0=A0=A0=A0 |=A0 _=A0=A0 |=A0 _ >> =A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0_=A0 |=A0=A0=A0=A0= | |=A0=A0=A0=A0 |-|_|--|-|_|HA >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 MNN|_|-|=A0=A0=A0=A0 | = |=A0=A0=A0=A0 |=A0 AR=A0 | >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 = _=A0 |-|_____| >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |-|_|-| INTERNET=A0 >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0 |p<-=A0 = | >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = MR2 >> =A0 >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Figure 1: (n,1,1): Multiple = MRs, 1 HA, 1 MNP >> =A0 >> In this case, HA can send packets destined to MNN via MR1, or MR2 >> (Load Balancing). > > so far so good > >> The same situation in a wireless deployment is shown in Figure 2. >> Here also, we consider the case when no "split" has occurred i.e. MR1 >> and MR2 are together. >> =A0 >> =A0 >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 AP1=A0=A0 MR1 >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 _ _=A0=A0=A0=A0 _=A0 | >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 / |_|---|_|-|=A0 _____=A0 >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 _ /=A0 p<-=A0=A0=A0=A0=A0=A0 |-|=A0=A0=A0=A0 |=A0 _=A0=A0 |=A0 _ >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = MNN|_|=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0| |=A0=A0=A0=A0 = |-|_|--|-|_|HA >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | |=A0=A0=A0=A0 |=A0 = AR=A0 | >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 _=A0=A0=A0=A0 _=A0 |-|_____| >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 |_|---|_|-| INTERNET=A0 >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 p<-=A0=A0=A0=A0=A0=A0=A0 | >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 AP2=A0=A0 MR2 >> =A0 >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Figure = 2: (n,1,1) : Multiple MRs, 1 HA, 1 MNP in >> a Wireless Scenario >> =A0 > > I am not sure i understand this scenario... > I mean as i see this case 2, the network has already split and in = order > to deal with this situation, you would need additional mechanisms, > since MR1 and MR2 only connect themselves through the internet (i.e. > the nemo is split) > > In this case the difficulty is to detect that the nemo has split and = to > be able to determine which MNN are in which part of the nemo, > especially when you have a single MNP. For this you would need > additional mechanisms and/or to impose certain contraints, like > requiring that each MR has its own prefix assoicated, so that when = they > split, the MR can take its MNP with it. /this configuration is not > without problems of its own, like ingress filtering compatibility and > so on) > > so... > >> In Figure 2. MNN is currently attached to the Access Point (AP1) of >> MR1. I have the following questions: >> =A0 >> a)If HA tries to send packets to MNN via MR2, how will these packets >> reach MNN? > > they can't without additional mechanisms imho > >> Basically how is "Load Balancing" >> =A0 possible for a case (n,1,1) in a practical wireless deployment? > > not sure what you mean > >> b)Is it that the AP1 and AP2 are "physically connected"? If so, then >> does the term "split" means a "physical split"? >> =A0 > > AP1 and AP2 are connected through the internet and not thorugh the = nemo > as i see it, so they don't belong to the same nemo, that is why they > are split > > regards, marcelo > > >> Thanks and Regards, >> Sameer Kumar. >> =A0 >> =A0 >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >> =A0 >> =A0 >> =A0 > > > From nemo-bounces@ietf.org Wed Aug 17 22:29:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5a9r-00033y-Aw; Wed, 17 Aug 2005 22:29:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5a9p-00033o-EP for nemo@megatron.ietf.org; Wed, 17 Aug 2005 22:29:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20245 for ; Wed, 17 Aug 2005 22:29:26 -0400 (EDT) Received: from smtp1.mei.co.jp ([133.183.129.26] helo=smtp2.mei.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5ajS-00078c-AU for nemo@ietf.org; Wed, 17 Aug 2005 23:06:20 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id j7I2TElH025081; Thu, 18 Aug 2005 11:29:14 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id j7I2TFs22337; Thu, 18 Aug 2005 11:29:15 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/expos) with ESMTP id j7I2TEN19813; Thu, 18 Aug 2005 11:29:14 +0900 (JST) Received: from mozart.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Aug 2005 10:27:22 +0800 Received: by mozart.psl.com.sg (Postfix, from userid 1000) id 8CBFB20C1A0; Thu, 18 Aug 2005 10:45:50 +0800 (SGT) Subject: RE: [nemo] Split Networks:Query From: Chan-Wah Ng To: Sameer Kumar In-Reply-To: <001301c5a333$a3bb5530$44476c6b@sisodomain.com> References: <001301c5a333$a3bb5530$44476c6b@sisodomain.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Aug 2005 10:45:50 +0800 Message-Id: <1124333150.9242.62.camel@bach.psl.com.sg> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 X-OriginalArrivalTime: 18 Aug 2005 02:27:22.0181 (UTC) FILETIME=[5D14FF50:01C5A39C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Content-Transfer-Encoding: quoted-printable Cc: 'marcelo bagnulo braun' , IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello Sameer and Marcelo, On Wed, 2005-08-17 at 19:27 +0530, Sameer Kumar wrote: > Hi Marcelo, > Thanks for the prompt reply. I think I couldn't convey my > question clearly in my last mail. Let me put it this way: > - In case of a wireless network ( case (n,1,1)) with MR1 advertising thro= ugh > AP1, and MR2 advertising through AP2, and "NO SPLIT" has occurred, how is= it > possible for an MNN to receive packets from both MR1 and MR2? >=20 Nope, its already split. True, MR1 and MR2 are on the same access network link, but by splitting into AP1 and AP2, you created two different *Mobile Network Links*. So, it is actually something like that: Mobile Access Network Network Links Link +--------+ | | NEMO-1 +--- AP1 -- MR1 --+ +--------+ | + -- AR -- Internet -- HA +--------+ | | NEMO-2 +--- AP2 -- MR2 --+ +--------+ | /rgds /cwng > I just want to clarify how an (n,1,1) network is deployed in a wireless > scenario such that MNN can receive packets from all the MRs. >=20 > Thanks and Regards, > Sameer Kumar. >=20 > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 > Sent: Wednesday, August 17, 2005 6:52 PM > To: Sameer Kumar > Cc: nemo@ietf.org > Subject: Re: [nemo] Split Networks:Query >=20 > Hi Sameer, >=20 > El 17/08/2005, a las 13:40, Sameer Kumar escribi=F3: >=20 > > Hi all, > > I have a doubt regarding the concept of "Split Networks" in=20 > > NEMO. Split Networks comprise the case (n,1,1): Multiple MRs, Single=20 > > HA, Single MNP. > > Figure 1. below depicts the Split Network scenario. No "split" has=20 > > occured. MR1 and MR2 are together. > > =20 > > MR1 > > | _ | > > |-|_|-| _____=20 > > | p<- |-| | _ | _ > > _ | | | |-|_|--|-|_|HA > > MNN|_|-| | | | AR | > > | _ |-|_____| > > |-|_|-| INTERNET=20 > > |p<- | > > MR2 > > =20 > > Figure 1: (n,1,1): Multiple MRs, 1 HA, 1 MNP > > =20 > > In this case, HA can send packets destined to MNN via MR1, or MR2=20 > > (Load Balancing). >=20 > so far so good >=20 > > The same situation in a wireless deployment is shown in Figure 2.=20 > > Here also, we consider the case when no "split" has occurred i.e. MR1=20 > > and MR2 are together. > > =20 > > =20 > > AP1 MR1 > > _ _ _ | > > / |_|---|_|-| _____=20 > > _ / p<- |-| | _ | _ > > MNN|_| | | |-|_|--|-|_|HA > > | | | AR | > > _ _ |-|_____| > > |_|---|_|-| INTERNET=20 > > p<- | > > AP2 MR2 > > =20 > > Figure 2: (n,1,1) : Multiple MRs, 1 HA, 1 MNP in=20 > > a Wireless Scenario > > =20 >=20 > I am not sure i understand this scenario... > I mean as i see this case 2, the network has already split and in order=20 > to deal with this situation, you would need additional mechanisms,=20 > since MR1 and MR2 only connect themselves through the internet (i.e.=20 > the nemo is split) >=20 > In this case the difficulty is to detect that the nemo has split and to=20 > be able to determine which MNN are in which part of the nemo,=20 > especially when you have a single MNP. For this you would need=20 > additional mechanisms and/or to impose certain contraints, like=20 > requiring that each MR has its own prefix assoicated, so that when they=20 > split, the MR can take its MNP with it. /this configuration is not=20 > without problems of its own, like ingress filtering compatibility and=20 > so on) >=20 > so... >=20 > > In Figure 2. MNN is currently attached to the Access Point (AP1) of=20 > > MR1. I have the following questions: > > =20 > > a)If HA tries to send packets to MNN via MR2, how will these packets=20 > > reach MNN? >=20 > they can't without additional mechanisms imho >=20 > > Basically how is "Load Balancing" > > possible for a case (n,1,1) in a practical wireless deployment? >=20 > not sure what you mean >=20 > > b)Is it that the AP1 and AP2 are "physically connected"? If so, then=20 > > does the term "split" means a "physical split"? > > =20 >=20 > AP1 and AP2 are connected through the internet and not thorugh the nemo=20 > as i see it, so they don't belong to the same nemo, that is why they=20 > are split >=20 > regards, marcelo >=20 >=20 > > Thanks and Regards, > > Sameer Kumar. > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 >=20 >=20 >=20 >=20 From nemo-bounces@ietf.org Wed Aug 17 22:47:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5aRP-0006cY-DC; Wed, 17 Aug 2005 22:47:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5aRM-0006cK-SJ for nemo@megatron.ietf.org; Wed, 17 Aug 2005 22:47:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21007 for ; Wed, 17 Aug 2005 22:47:34 -0400 (EDT) Received: from smtp1.mei.co.jp ([133.183.129.26] helo=smtp2.mei.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5b11-0007Zs-Oz for nemo@ietf.org; Wed, 17 Aug 2005 23:24:28 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id j7I2lPlH011359 for ; Thu, 18 Aug 2005 11:47:25 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id j7I2lRs00502 for ; Thu, 18 Aug 2005 11:47:27 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/expos) with ESMTP id j7I2lQN00507 for ; Thu, 18 Aug 2005 11:47:26 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.11.6p2/3.7W/soml23) id j7I2lPL12911 for nemo@ietf.org; Thu, 18 Aug 2005 11:47:25 +0900 (JST) Received: from nancy by soml23.jp.panasonic.com (8.11.6p2/3.7W) with ESMTP id j7I2lPh12891 for ; Thu, 18 Aug 2005 11:47:25 +0900 (JST) Message-Id: <200508180247.j7I2lPh12891@soml23.jp.panasonic.com> Date: Thu, 18 Aug 2005 11:52:38 +0900 From: Masayuki Kumazawa Subject: Re: [nemo] Split Networks:Query To: nemo@ietf.org X-Mailer: Datula version 1.51.09 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello Sammer, <000001c5a320$962b0590$44476c6b@sisodomain.com> From Sameer Kumar-san >Hi all, > > I have a doubt regarding the concept of "Split Networks" in NEMO. >Split Networks comprise the case (n,1,1): Multiple MRs, Single HA, Single >MNP. > > Figure 1. below depicts the Split Network scenario. No "split" has >occured. MR1 and MR2 are together. > > MR1 > | _ | > |-|_|-| _____ > | p<- |-| | _ | _ > _ | | | |-|_|--|-|_|HA > MNN|_|-| | | | AR | > | _ |-|_____| > |-|_|-| INTERNET > |p<- | > MR2 > Figure 1: (n,1,1): Multiple MRs, 1 HA, 1 MNP In this case, split may occur in two ways. One case is that MR2, which is a portable device like a cellular phone, moves away from the network. The other case is that both of them are installed in different places but they are configured with the same MNP. In the second case without additional mechanism, prefix table must be configured more carefully, maybe manually. >In this case, HA can send packets destined to MNN via MR1, or MR2 (Load >Balancing). The same situation in a wireless deployment is shown in Figure >2. Here also, we consider the case when no "split" has occurred i.e. MR1 and >MR2 are together. > > AP1 MR1 > _ _ _ | > / |_|---|_|-| _____ > _ / p<- |-| | _ | _ > MNN|_| | | |-|_|--|-|_|HA > | | | AR | > _ _ |-|_____| > |_|---|_|-| INTERNET > p<- | > AP2 MR2 > > Figure 2: (n,1,1) : Multiple MRs, 1 HA, 1 MNP in a Wireless Scenario >In Figure 2. MNN is currently attached to the Access Point (AP1) of MR1. I >have the following questions: >a)If HA tries to send packets to MNN via MR2, how will these packets reach >MNN? Basically how is "Load Balancing" > possible for a case (n,1,1) in a practical wireless deployment? >b)Is it that the AP1 and AP2 are "physically connected"? If so, then does >the term "split" means a "physical split"? In the architecture of current major wireless technologies, there is one AP in a BSS. So, as you pointed out, even if MR1 and MR2 are together, AP1 and AP2 can't be connected phisically as Access Point. However, if AP2 behaves as a STA, MR1 and MR2 can be connected phisically. In this configuration, all packets are forwarded via AP1, but load balancing between MR1 and MR2 seems possible. I'm not sure whether I understand your question, but I hope they will be answer of your question. Best regards, Masayuki ----------- M.Kumazawa From nemo-bounces@ietf.org Wed Aug 17 23:25:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5b1i-0005qe-Qu; Wed, 17 Aug 2005 23:25:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5b1f-0005nl-Fc for nemo@megatron.ietf.org; Wed, 17 Aug 2005 23:25:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22912 for ; Wed, 17 Aug 2005 23:25:04 -0400 (EDT) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5bbK-0000Ph-FI for nemo@ietf.org; Thu, 18 Aug 2005 00:01:59 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id E72C46F5A0; Thu, 18 Aug 2005 05:24:56 +0200 (CEST) Received: from [201.217.142.193] (unknown [163.117.203.145]) by smtp01.uc3m.es (Postfix) with SMTP id C94A06D11E; Thu, 18 Aug 2005 05:24:53 +0200 (CEST) In-Reply-To: <1124333150.9242.62.camel@bach.psl.com.sg> References: <001301c5a333$a3bb5530$44476c6b@sisodomain.com> <1124333150.9242.62.camel@bach.psl.com.sg> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <2fd72c9e1f208010a4aba64a5fa55f87@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] Split Networks:Query Date: Thu, 18 Aug 2005 04:43:04 +0200 To: Chan-Wah Ng X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is my understanding too El 18/08/2005, a las 4:45, Chan-Wah Ng escribi=F3: > Hello Sameer and Marcelo, > > On Wed, 2005-08-17 at 19:27 +0530, Sameer Kumar wrote: >> Hi Marcelo, >> Thanks for the prompt reply. I think I couldn't convey my >> question clearly in my last mail. Let me put it this way: >> - In case of a wireless network ( case (n,1,1)) with MR1 advertising=20= >> through >> AP1, and MR2 advertising through AP2, and "NO SPLIT" has occurred,=20 >> how is it >> possible for an MNN to receive packets from both MR1 and MR2? >> > > Nope, its already split. True, MR1 and MR2 are on the same access > network link, but by splitting into AP1 and AP2, you created two > different *Mobile Network Links*. So, it is actually something like > that: > > Mobile Access > Network Network > Links Link > +--------+ | > | NEMO-1 +--- AP1 -- MR1 --+ > +--------+ | > + -- AR -- Internet -- HA > +--------+ | > | NEMO-2 +--- AP2 -- MR2 --+ > +--------+ | > > /rgds > /cwng > >> I just want to clarify how an (n,1,1) network is deployed in a=20 >> wireless >> scenario such that MNN can receive packets from all the MRs. >> >> Thanks and Regards, >> Sameer Kumar. >> >> -----Original Message----- >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >> Sent: Wednesday, August 17, 2005 6:52 PM >> To: Sameer Kumar >> Cc: nemo@ietf.org >> Subject: Re: [nemo] Split Networks:Query >> >> Hi Sameer, >> >> El 17/08/2005, a las 13:40, Sameer Kumar escribi=F3: >> >>> Hi all, >>> I have a doubt regarding the concept of "Split Networks" in >>> NEMO. Split Networks comprise the case (n,1,1): Multiple MRs, Single >>> HA, Single MNP. >>> Figure 1. below depicts the Split Network scenario. No "split" = has >>> occured. MR1 and MR2 are together. >>> >>> MR1 >>> | _ | >>> |-|_|-| _____ >>> | p<- |-| | _ | _ >>> _ | | | |-|_|--|-|_|HA >>> MNN|_|-| | | | AR | >>> | _ |-|_____| >>> |-|_|-| INTERNET >>> |p<- | >>> MR2 >>> >>> Figure 1: (n,1,1): Multiple MRs, 1 HA, 1 MNP >>> >>> In this case, HA can send packets destined to MNN via MR1, or MR2 >>> (Load Balancing). >> >> so far so good >> >>> The same situation in a wireless deployment is shown in Figure 2. >>> Here also, we consider the case when no "split" has occurred i.e. = MR1 >>> and MR2 are together. >>> >>> >>> AP1 MR1 >>> _ _ _ | >>> / |_|---|_|-| _____ >>> _ / p<- |-| | _ | _ >>> MNN|_| | | |-|_|--|-|_|HA >>> | | | AR | >>> _ _ |-|_____| >>> |_|---|_|-| INTERNET >>> p<- | >>> AP2 MR2 >>> >>> Figure 2: (n,1,1) : Multiple MRs, 1 HA, 1 MNP = in >>> a Wireless Scenario >>> >> >> I am not sure i understand this scenario... >> I mean as i see this case 2, the network has already split and in=20 >> order >> to deal with this situation, you would need additional mechanisms, >> since MR1 and MR2 only connect themselves through the internet (i.e. >> the nemo is split) >> >> In this case the difficulty is to detect that the nemo has split and=20= >> to >> be able to determine which MNN are in which part of the nemo, >> especially when you have a single MNP. For this you would need >> additional mechanisms and/or to impose certain contraints, like >> requiring that each MR has its own prefix assoicated, so that when=20 >> they >> split, the MR can take its MNP with it. /this configuration is not >> without problems of its own, like ingress filtering compatibility and >> so on) >> >> so... >> >>> In Figure 2. MNN is currently attached to the Access Point (AP1) of >>> MR1. I have the following questions: >>> >>> a)If HA tries to send packets to MNN via MR2, how will these packets >>> reach MNN? >> >> they can't without additional mechanisms imho >> >>> Basically how is "Load Balancing" >>> possible for a case (n,1,1) in a practical wireless deployment? >> >> not sure what you mean >> >>> b)Is it that the AP1 and AP2 are "physically connected"? If so, then >>> does the term "split" means a "physical split"? >>> >> >> AP1 and AP2 are connected through the internet and not thorugh the=20 >> nemo >> as i see it, so they don't belong to the same nemo, that is why they >> are split >> >> regards, marcelo >> >> >>> Thanks and Regards, >>> Sameer Kumar. >>> >>> >>> >>> >>> >>> >> >> >> >> > From nemo-bounces@ietf.org Thu Aug 18 08:36:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5jd5-0005wg-1P; Thu, 18 Aug 2005 08:36:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5jd3-0005uu-Un for nemo@megatron.ietf.org; Thu, 18 Aug 2005 08:36:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01364 for ; Thu, 18 Aug 2005 08:36:16 -0400 (EDT) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5kCl-0007S1-EC for nemo@ietf.org; Thu, 18 Aug 2005 09:13:14 -0400 Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0ILF003P74C4EX@mailout1.samsung.com> for nemo@ietf.org; Thu, 18 Aug 2005 21:36:04 +0900 (KST) Received: from sameerk ([107.108.71.68]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPSA id <0ILF0020A4C0YP@mmp1.samsung.com> for nemo@ietf.org; Thu, 18 Aug 2005 21:36:03 +0900 (KST) Date: Thu, 18 Aug 2005 18:01:17 +0530 From: Sameer Kumar Subject: RE: [nemo] Split Networks:Query In-reply-to: <200508180247.j7I2lPh12891@soml23.jp.panasonic.com> To: "'Masayuki Kumazawa'" , nemo@ietf.org Message-id: <000001c5a3f0$c2b24a30$44476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: 7BIT Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi all, Thanks for the replies. I still have some concerns regarding (n,1,1) configuration in a wireless network..I mean, how does it look like. > AP1 MR1 > _ _ _ | > / |_|---|_|-| _____ > _ / p<- |-| | _ | _ > MNN|_| | | |-|_|--|-|_|HA > | | | AR | > _ _ |-|_____| > |_|---|_|-| INTERNET > p<- | > AP2 MR2 > Figure 2. I agree that the above network( Figure 2) is actually split. Consider the figure below: > MR1 > | _ | > |-|_|-| _____ > | p<- |-| | _ | _ > _ | | | |-|_|--|-|_|HA > MNN|_|-| | | | AR | > | _ |-|_____| > |-|_|-| INTERNET > |p<- | > MR2 > Figure 1: (n,1,1): Multiple MRs, 1 HA, 1 MNP The Figure 1. is easily possible in a wired scenario. It is a (n,1,1) "no split" scenario. I just want to know how a similar configuration, as Figure 1, will look like in a wireless scenario..with MR1, MR2, and one or more Access Points in the diagram. And then how will split occur in a wireless scenario. Thanks and Regards, Sameer Kumar. -----Original Message----- From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of Masayuki Kumazawa Sent: Thursday, August 18, 2005 8:23 AM To: nemo@ietf.org Subject: Re: [nemo] Split Networks:Query Hello Sammer, <000001c5a320$962b0590$44476c6b@sisodomain.com> From Sameer Kumar-san >Hi all, > > I have a doubt regarding the concept of "Split Networks" in NEMO. >Split Networks comprise the case (n,1,1): Multiple MRs, Single HA, Single >MNP. > > Figure 1. below depicts the Split Network scenario. No "split" has >occured. MR1 and MR2 are together. > > MR1 > | _ | > |-|_|-| _____ > | p<- |-| | _ | _ > _ | | | |-|_|--|-|_|HA > MNN|_|-| | | | AR | > | _ |-|_____| > |-|_|-| INTERNET > |p<- | > MR2 > Figure 1: (n,1,1): Multiple MRs, 1 HA, 1 MNP In this case, split may occur in two ways. One case is that MR2, which is a portable device like a cellular phone, moves away from the network. The other case is that both of them are installed in different places but they are configured with the same MNP. In the second case without additional mechanism, prefix table must be configured more carefully, maybe manually. >In this case, HA can send packets destined to MNN via MR1, or MR2 (Load >Balancing). The same situation in a wireless deployment is shown in Figure >2. Here also, we consider the case when no "split" has occurred i.e. MR1 and >MR2 are together. > > AP1 MR1 > _ _ _ | > / |_|---|_|-| _____ > _ / p<- |-| | _ | _ > MNN|_| | | |-|_|--|-|_|HA > | | | AR | > _ _ |-|_____| > |_|---|_|-| INTERNET > p<- | > AP2 MR2 > > Figure 2: (n,1,1) : Multiple MRs, 1 HA, 1 MNP in a Wireless Scenario >In Figure 2. MNN is currently attached to the Access Point (AP1) of MR1. I >have the following questions: >a)If HA tries to send packets to MNN via MR2, how will these packets reach >MNN? Basically how is "Load Balancing" > possible for a case (n,1,1) in a practical wireless deployment? >b)Is it that the AP1 and AP2 are "physically connected"? If so, then does >the term "split" means a "physical split"? In the architecture of current major wireless technologies, there is one AP in a BSS. So, as you pointed out, even if MR1 and MR2 are together, AP1 and AP2 can't be connected phisically as Access Point. However, if AP2 behaves as a STA, MR1 and MR2 can be connected phisically. In this configuration, all packets are forwarded via AP1, but load balancing between MR1 and MR2 seems possible. I'm not sure whether I understand your question, but I hope they will be answer of your question. Best regards, Masayuki ----------- M.Kumazawa From nemo-bounces@ietf.org Thu Aug 18 09:04:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5k4E-0003y3-J7; Thu, 18 Aug 2005 09:04:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5k4A-0003xt-DY for nemo@megatron.ietf.org; Thu, 18 Aug 2005 09:04:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02833 for ; Thu, 18 Aug 2005 09:04:16 -0400 (EDT) Received: from smtp1.mei.co.jp ([133.183.129.26] helo=smtp2.mei.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5kdu-0008Eb-Ks for nemo@ietf.org; Thu, 18 Aug 2005 09:41:15 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/jazz) with ESMTP id j7ID3j1o028232; Thu, 18 Aug 2005 22:03:45 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id j7ID3kc05801; Thu, 18 Aug 2005 22:03:46 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with SMTP id j7ID3lM16201; Thu, 18 Aug 2005 22:03:48 +0900 (JST) Received: from mozart.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Aug 2005 21:01:45 +0800 Received: by mozart.psl.com.sg (Postfix, from userid 1000) id B546720C1A0; Thu, 18 Aug 2005 21:20:17 +0800 (SGT) Subject: RE: [nemo] Split Networks:Query From: Chan-Wah Ng To: Sameer Kumar In-Reply-To: <000001c5a3f0$c2b24a30$44476c6b@sisodomain.com> References: <000001c5a3f0$c2b24a30$44476c6b@sisodomain.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 18 Aug 2005 21:20:17 +0800 Message-Id: <1124371217.9242.95.camel@bach.psl.com.sg> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 X-OriginalArrivalTime: 18 Aug 2005 13:01:45.0857 (UTC) FILETIME=[FCCD0710:01C5A3F4] X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , 'Masayuki Kumazawa' X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org On Thu, 2005-08-18 at 18:01 +0530, Sameer Kumar wrote: > Hi all, > Thanks for the replies. I still have some concerns regarding > (n,1,1) configuration in a wireless network..I mean, how does it look like. > > > AP1 MR1 > > _ _ _ | > > / |_|---|_|-| _____ > > _ / p<- |-| | _ | _ > > MNN|_| | | |-|_|--|-|_|HA > > | | | AR | > > _ _ |-|_____| > > |_|---|_|-| INTERNET > > p<- | > > AP2 MR2 > > > Figure 2. > > I agree that the above network( Figure 2) is actually split. Consider the > figure below: > > MR1 > > | _ | > > |-|_|-| _____ > > | p<- |-| | _ | _ > > _ | | | |-|_|--|-|_|HA > > MNN|_|-| | | | AR | > > | _ |-|_____| > > |-|_|-| INTERNET > > |p<- | > > MR2 > > Figure 1: (n,1,1): Multiple MRs, 1 HA, 1 MNP > > The Figure 1. is easily possible in a wired scenario. It is a (n,1,1) "no > split" scenario. I just want to know how a similar configuration, as Figure > 1, will look like in a wireless scenario..with MR1, MR2, and one or more > Access Points in the diagram. With access point? I don't know if its possible. Perhaps this: MR1 and MR2 connected to AP via Ethernet/Bluetooth, AP is a WLAN-Ethernet or WLAN-Bluetooth bridge. But I don't imagine why it will split. MR1 | _ | AP |-|_|-| _____ _ _ | |-| | _ | _ MNN|_|-|_|--| | | |-|_|--|-|_|HA | | | | AR | | _ |-|_____| |-|_|-| INTERNET Ethernet->| | MR2 Alternatively, a more common scenario is the ad-hoc mode, then there is no concept of AP, and it may split. Here, MR1 has two interface. the inner interface is in ad-hoc mode with MNN and MR2. MR1 _ _ _ | / |_|_|-| _____ _ / p<- |-| | _ | _ MNN|_| | | |-|_|--|-|_|HA \ | | | AR | \_ _ _ |-|_____| |_|_|-| INTERNET p<- | MR2 /rgds /cwng > And then how will split occur in a wireless > scenario. > > Thanks and Regards, > Sameer Kumar. > > > -----Original Message----- > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of > Masayuki Kumazawa > Sent: Thursday, August 18, 2005 8:23 AM > To: nemo@ietf.org > Subject: Re: [nemo] Split Networks:Query > > Hello Sammer, > > <000001c5a320$962b0590$44476c6b@sisodomain.com> From Sameer Kumar-san > >Hi all, > > > > I have a doubt regarding the concept of "Split Networks" in NEMO. > >Split Networks comprise the case (n,1,1): Multiple MRs, Single HA, Single > >MNP. > > > > Figure 1. below depicts the Split Network scenario. No "split" has > >occured. MR1 and MR2 are together. > > > > MR1 > > | _ | > > |-|_|-| _____ > > | p<- |-| | _ | _ > > _ | | | |-|_|--|-|_|HA > > MNN|_|-| | | | AR | > > | _ |-|_____| > > |-|_|-| INTERNET > > |p<- | > > MR2 > > Figure 1: (n,1,1): Multiple MRs, 1 HA, 1 MNP > > In this case, split may occur in two ways. > One case is that MR2, which is a portable device like a cellular phone, > moves away from the network. > > The other case is that both of them are installed in different places but > they are configured with the same MNP. > > In the second case without additional mechanism, prefix table must be > configured more carefully, maybe manually. > > >In this case, HA can send packets destined to MNN via MR1, or MR2 (Load > >Balancing). The same situation in a wireless deployment is shown in Figure > >2. Here also, we consider the case when no "split" has occurred i.e. MR1 > and > >MR2 are together. > > > > AP1 MR1 > > _ _ _ | > > / |_|---|_|-| _____ > > _ / p<- |-| | _ | _ > > MNN|_| | | |-|_|--|-|_|HA > > | | | AR | > > _ _ |-|_____| > > |_|---|_|-| INTERNET > > p<- | > > AP2 MR2 > > > > Figure 2: (n,1,1) : Multiple MRs, 1 HA, 1 MNP in a Wireless Scenario > > >In Figure 2. MNN is currently attached to the Access Point (AP1) of MR1. I > >have the following questions: > >a)If HA tries to send packets to MNN via MR2, how will these packets reach > >MNN? Basically how is "Load Balancing" > > possible for a case (n,1,1) in a practical wireless deployment? > > >b)Is it that the AP1 and AP2 are "physically connected"? If so, then does > >the term "split" means a "physical split"? > > In the architecture of current major wireless technologies, > there is one AP in a BSS. > > So, as you pointed out, even if MR1 and MR2 are together, > AP1 and AP2 can't be connected phisically as Access Point. > > However, if AP2 behaves as a STA, MR1 and MR2 can be connected phisically. > In this configuration, all packets are forwarded via AP1, but load balancing > > between MR1 and MR2 seems possible. > > I'm not sure whether I understand your question, but I hope they will be > answer of your question. > > Best regards, > Masayuki > ----------- > M.Kumazawa > > > > From nemo-bounces@ietf.org Thu Aug 18 09:13:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5kCz-0005Nb-FF; Thu, 18 Aug 2005 09:13:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5kCx-0005NT-RA for nemo@megatron.ietf.org; Thu, 18 Aug 2005 09:13:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03160 for ; Thu, 18 Aug 2005 09:13:22 -0400 (EDT) Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5kmg-0008SA-7x for nemo@ietf.org; Thu, 18 Aug 2005 09:50:20 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 308BE57273; Thu, 18 Aug 2005 15:13:11 +0200 (CEST) Received: from [163.117.203.145] (unknown [163.117.203.145]) by smtp02.uc3m.es (Postfix) with ESMTP id AF16055E05; Thu, 18 Aug 2005 15:13:08 +0200 (CEST) In-Reply-To: <000001c5a3f0$c2b24a30$44476c6b@sisodomain.com> References: <000001c5a3f0$c2b24a30$44476c6b@sisodomain.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] Split Networks:Query Date: Thu, 18 Aug 2005 15:13:58 +0200 To: Sameer Kumar X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org El 18/08/2005, a las 14:31, Sameer Kumar escribi=F3: >> MR1 >> | _ | >> |-|_|-| _____ >> | p<- |-| | _ | _ >> _ | | | |-|_|--|-|_|HA >> MNN|_|-| | | | AR | >> | _ |-|_____| >> |-|_|-| INTERNET >> |p<- | >> MR2 >> Figure 1: (n,1,1): Multiple MRs, 1 HA, 1 MNP > > The Figure 1. is easily possible in a wired scenario. It is a (n,1,1)=20= > "no > split" scenario. I just want to know how a similar configuration, as=20= > Figure > 1, will look like in a wireless scenario..with MR1, MR2, and one or=20 > more > Access Points in the diagram. And then how will split occur in a=20 > wireless > scenario. I am not sure why you think that a wired and a wireless scenario are so=20= different... i mean, in the figure above the link between MR1, MR2 and=20= MNN could perfectly be wireless or wired. I guess that from an IP layer=20= perspective (that's where we are sitting on) there is no difference=20 imho So if you assume that all the links above are wireless, then you have a=20= wireless scenario, right? Then this scenario could simply split by breaking the link between MR1,=20= MR2 and MNN i.e. for instance MR1 leaves and MR2 and MNN continues in=20 the same link Regards, marcelo > > Thanks and Regards, > Sameer Kumar. > > > -----Original Message----- > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf = Of > Masayuki Kumazawa > Sent: Thursday, August 18, 2005 8:23 AM > To: nemo@ietf.org > Subject: Re: [nemo] Split Networks:Query > > Hello Sammer, > > <000001c5a320$962b0590$44476c6b@sisodomain.com> =46rom Sameer = Kumar-san >> Hi all, >> >> I have a doubt regarding the concept of "Split Networks" in = NEMO. >> Split Networks comprise the case (n,1,1): Multiple MRs, Single HA,=20 >> Single >> MNP. >> >> Figure 1. below depicts the Split Network scenario. No "split" has >> occured. MR1 and MR2 are together. >> >> MR1 >> | _ | >> |-|_|-| _____ >> | p<- |-| | _ | _ >> _ | | | |-|_|--|-|_|HA >> MNN|_|-| | | | AR | >> | _ |-|_____| >> |-|_|-| INTERNET >> |p<- | >> MR2 >> Figure 1: (n,1,1): Multiple MRs, 1 HA, 1 MNP > > In this case, split may occur in two ways. > One case is that MR2, which is a portable device like a cellular = phone, > moves away from the network. > > The other case is that both of them are installed in different places=20= > but > they are configured with the same MNP. > > In the second case without additional mechanism, prefix table must be > configured more carefully, maybe manually. > >> In this case, HA can send packets destined to MNN via MR1, or MR2=20 >> (Load >> Balancing). The same situation in a wireless deployment is shown in=20= >> Figure >> 2. Here also, we consider the case when no "split" has occurred i.e.=20= >> MR1 > and >> MR2 are together. >> >> AP1 MR1 >> _ _ _ | >> / |_|---|_|-| _____ >> _ / p<- |-| | _ | _ >> MNN|_| | | |-|_|--|-|_|HA >> | | | AR | >> _ _ |-|_____| >> |_|---|_|-| INTERNET >> p<- | >> AP2 MR2 >> >> Figure 2: (n,1,1) : Multiple MRs, 1 HA, 1 MNP in a Wireless=20 >> Scenario > >> In Figure 2. MNN is currently attached to the Access Point (AP1) of=20= >> MR1. I >> have the following questions: >> a)If HA tries to send packets to MNN via MR2, how will these packets=20= >> reach >> MNN? Basically how is "Load Balancing" >> possible for a case (n,1,1) in a practical wireless deployment? > >> b)Is it that the AP1 and AP2 are "physically connected"? If so, then=20= >> does >> the term "split" means a "physical split"? > > In the architecture of current major wireless technologies, > there is one AP in a BSS. > > So, as you pointed out, even if MR1 and MR2 are together, > AP1 and AP2 can't be connected phisically as Access Point. > > However, if AP2 behaves as a STA, MR1 and MR2 can be connected=20 > phisically. > In this configuration, all packets are forwarded via AP1, but load=20 > balancing > > between MR1 and MR2 seems possible. > > I'm not sure whether I understand your question, but I hope they will=20= > be > answer of your question. > > Best regards, > Masayuki > ----------- > M.Kumazawa > > > > From nemo-bounces@ietf.org Mon Aug 22 02:43:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E761m-0001eH-VL; Mon, 22 Aug 2005 02:43:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E761l-0001eC-Bf for nemo@megatron.ietf.org; Mon, 22 Aug 2005 02:43:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25736 for ; Mon, 22 Aug 2005 02:43:23 -0400 (EDT) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E76cG-0005Y0-Ff for nemo@ietf.org; Mon, 22 Aug 2005 03:21:09 -0400 Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0ILM00LS52O18W@mailout3.samsung.com> for nemo@ietf.org; Mon, 22 Aug 2005 15:43:13 +0900 (KST) Received: from wable ([107.108.71.65]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0ILM000SE2NZ3P@mmp1.samsung.com> for nemo@ietf.org; Mon, 22 Aug 2005 15:43:13 +0900 (KST) Date: Mon, 22 Aug 2005 11:54:25 +0530 From: Ranjitsinh Wable Subject: Re: [nemo] Split Networks:Query To: Sameer Kumar Message-id: <000201c5a6e4$1c3e33c0$41476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; reply-type=response; charset=iso-8859-1; format=flowed Content-transfer-encoding: QUOTED-PRINTABLE X-Priority: 3 X-MSMail-priority: Normal References: <000001c5a3f0$c2b24a30$44476c6b@sisodomain.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Marcelo, See the inlined comments. ----- Original Message -----=20 =46rom: "marcelo bagnulo braun" To: "Sameer Kumar" Cc: "IETF NEMO WG" Sent: Thursday, August 18, 2005 6:43 PM Subject: Re: [nemo] Split Networks:Query El 18/08/2005, a las 14:31, Sameer Kumar escribi=F3: >> MR1 >> | _ | >> |-|_|-| _____ >> | p<- |-| | _ | _ >> _ | | | |-|_|--|-|_|HA >> MNN|_|-| | | | AR | >> | _ |-|_____| >> |-|_|-| INTERNET >> |p<- | >> MR2 >> Figure 1: (n,1,1): Multiple MRs, 1 HA, 1 MNP > > The Figure 1. is easily possible in a wired scenario. It is a (n,1,= 1) "no > split" scenario. I just want to know how a similar configuration, a= s=20 > Figure > 1, will look like in a wireless scenario..with MR1, MR2, and one or= more > Access Points in the diagram. And then how will split occur in a wi= reless > scenario. I am not sure why you think that a wired and a wireless scenario are = so different... i mean, in the figure above the link between MR1, MR2 an= d MNN could perfectly be wireless or wired. I guess that from an IP lay= er perspective (that's where we are sitting on) there is no difference imho So if you assume that all the links above are wireless, then you have= a wireless scenario, right? Then this scenario could simply split by breaking the link between MR= 1, MR2 and MNN i.e. for instance MR1 leaves and MR2 and MNN continues in the same link Regards, marcelo =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> I would like to know how the MR1, MR2 and MNN can be on same link in wireless scenario? 1) whether you say that they all connected to the AR's wireless Link? 2) If not, then whether the MNN have two interfaces to get in touch with both the MRs? I will try to put this problem in slightly different scenario: As per NEMO concept we can have two wireless networks 1) Between the AR and the MR's 2) Between MR and MNN. Now suppose the MNN's are going to use the same prefix then there is no problem for the first network. As both the MRs are on same link of AR. Its normal AR-MR communication. Lets think about the second wireless scenario i.e. Between MR-MNN. Lets says there are two MR's on Link of AR MR1, MR2. Now one MNN can connect to either of the MR. Say it connected to MR1. Lets say packet is comming for MNN to MR2 as per load balancing at HA of MRs. Now the question arieses is that how the packet will reach to MNN via MR2? There can be some possiblities like 1) MNN have two links and get connected to both MRs. (Sorry I know its not possible(feasible) but putting it to just give = all=20 options) 2) MRs who share prefixes always send the packes on other link. (But its burden on the Wireless link (between AR and MRs)) 3) MRs keep update of the nodes under it and if packet is not destinied then only it forwards on other link. (Improved case 2 with intelligence at MR. ) 4) We can have Adhoc mode as explained by chan-Wah ng but (I don't think that the NEMO talks about adhoc mode) If the Option 2 & 3 are the answer then, NEMO does not talk about thi= s. So its hard to get the scenarion for anybody. Let me know your views on this. Thanks and Regards, Wable R. U. > > Thanks and Regards, > Sameer Kumar. > > > -----Original Message----- > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behal= f Of > Masayuki Kumazawa > Sent: Thursday, August 18, 2005 8:23 AM > To: nemo@ietf.org > Subject: Re: [nemo] Split Networks:Query > > Hello Sammer, > > <000001c5a320$962b0590$44476c6b@sisodomain.com> From Sameer Kumar-s= an >> Hi all, >> >> I have a doubt regarding the concept of "Split Networks" in N= EMO. >> Split Networks comprise the case (n,1,1): Multiple MRs, Single HA,= Single >> MNP. >> >> Figure 1. below depicts the Split Network scenario. No "split" h= as >> occured. MR1 and MR2 are together. >> >> MR1 >> | _ | >> |-|_|-| _____ >> | p<- |-| | _ | _ >> _ | | | |-|_|--|-|_|HA >> MNN|_|-| | | | AR | >> | _ |-|_____| >> |-|_|-| INTERNET >> |p<- | >> MR2 >> Figure 1: (n,1,1): Multiple MRs, 1 HA, 1 MNP > > In this case, split may occur in two ways. > One case is that MR2, which is a portable device like a cellular ph= one, > moves away from the network. > > The other case is that both of them are installed in different plac= es but > they are configured with the same MNP. > > In the second case without additional mechanism, prefix table must = be > configured more carefully, maybe manually. > >> In this case, HA can send packets destined to MNN via MR1, or MR2 = (Load >> Balancing). The same situation in a wireless deployment is shown i= n=20 >> Figure >> 2. Here also, we consider the case when no "split" has occurred i.= e. MR1 > and >> MR2 are together. >> >> AP1 MR1 >> _ _ _ | >> / |_|---|_|-| _____ >> _ / p<- |-| | _ | _ >> MNN|_| | | |-|_|--|-|_|HA >> | | | AR | >> _ _ |-|_____| >> |_|---|_|-| INTERNET >> p<- | >> AP2 MR2 >> >> Figure 2: (n,1,1) : Multiple MRs, 1 HA, 1 MNP in a Wireless Sce= nario > >> In Figure 2. MNN is currently attached to the Access Point (AP1) o= f MR1.=20 >> I >> have the following questions: >> a)If HA tries to send packets to MNN via MR2, how will these packe= ts=20 >> reach >> MNN? Basically how is "Load Balancing" >> possible for a case (n,1,1) in a practical wireless deployment? > >> b)Is it that the AP1 and AP2 are "physically connected"? If so, th= en does >> the term "split" means a "physical split"? > > In the architecture of current major wireless technologies, > there is one AP in a BSS. > > So, as you pointed out, even if MR1 and MR2 are together, > AP1 and AP2 can't be connected phisically as Access Point. > > However, if AP2 behaves as a STA, MR1 and MR2 can be connected phis= ically. > In this configuration, all packets are forwarded via AP1, but load= =20 > balancing > > between MR1 and MR2 seems possible. > > I'm not sure whether I understand your question, but I hope they wi= ll be > answer of your question. > > Best regards, > Masayuki > ----------- > M.Kumazawa > > > > From nemo-bounces@ietf.org Mon Aug 22 02:53:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E76B9-0003gk-FU; Mon, 22 Aug 2005 02:53:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E76B5-0003gb-Om for nemo@megatron.ietf.org; Mon, 22 Aug 2005 02:53:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26447 for ; Mon, 22 Aug 2005 02:53:01 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E76la-0005uX-T6 for nemo@ietf.org; Mon, 22 Aug 2005 03:30:47 -0400 Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0ILM00F6733ZYG@mailout2.samsung.com> for nemo@ietf.org; Mon, 22 Aug 2005 15:52:47 +0900 (KST) Received: from wable ([107.108.71.65]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0ILM0004333XO3@mmp2.samsung.com> for nemo@ietf.org; Mon, 22 Aug 2005 15:52:47 +0900 (KST) Date: Mon, 22 Aug 2005 12:18:04 +0530 From: Ranjitsinh Wable Subject: Fw: [nemo] Split Networks:Query To: marcelo bagnulo braun , Sameer Kumar Message-id: <001b01c5a6e5$739edd80$41476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; reply-type=response; charset=iso-8859-1; format=flowed Content-transfer-encoding: QUOTED-PRINTABLE X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Marcelo, Please see the inlined comments. > ----- Original Message -----=20 > From: "marcelo bagnulo braun" > To: "Sameer Kumar" > Cc: "IETF NEMO WG" > Sent: Thursday, August 18, 2005 6:43 PM > Subject: Re: [nemo] Split Networks:Query > > > > El 18/08/2005, a las 14:31, Sameer Kumar escribi=F3: >>> MR1 >>> | _ | >>> |-|_|-| _____ >>> | p<- |-| | _ | _ >>> _ | | | |-|_|--|-|_|HA >>> MNN|_|-| | | | AR | >>> | _ |-|_____| >>> |-|_|-| INTERNET >>> |p<- | >>> MR2 >>> Figure 1: (n,1,1): Multiple MRs, 1 HA, 1 MNP >> >> The Figure 1. is easily possible in a wired scenario. It is a (n,1= ,1) "no >> split" scenario. I just want to know how a similar configuration, = as=20 >> Figure >> 1, will look like in a wireless scenario..with MR1, MR2, and one o= r more >> Access Points in the diagram. And then how will split occur in a w= ireless >> scenario. > > I am not sure why you think that a wired and a wireless scenario ar= e so > different... i mean, in the figure above the link between MR1, MR2 = and > MNN could perfectly be wireless or wired. I guess that from an IP l= ayer > perspective (that's where we are sitting on) there is no difference > imho > So if you assume that all the links above are wireless, then you ha= ve a > wireless scenario, right? > Then this scenario could simply split by breaking the link between = MR1, > MR2 and MNN i.e. for instance MR1 leaves and MR2 and MNN continues = in > the same link > > Regards, marcelo =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> I would like to know how the MR1, MR2 and MNN can be on same link in wireless scenario? 1) whether you want say that they all connected to the AR's wireless= Link? Again there may be a case that the MRs are connected to different ARs= but still advertise the same prefix without spilt. 2) If not, then whether the MNN have two interfaces to get in touch with both the MRs? I will try to put this problem in slightly different scenario: As per NEMO concept we can have two wireless networks 1) Between the AR and the MR's 2) Between MR and MNN. Now suppose the MNN's are going to use the same prefix then there is no problem for the first network. As both the MRs are on same link of AR. Its normal AR-MR communication. Lets think about the second wireless scenario i.e. Between MR-MNN. Lets says there are two MR's on Link of AR MR1, MR2. Now one MNN can connect to either of the MR. Say it connected to MR1. Lets say packet is comming for MNN to MR2 as per load balancing at HA of MRs. Now the question arieses is that how the packet will reach to MNN via MR2? There can be some possiblities like 1) MNN have two links and get connected to both MRs. (Sorry I know its not possible(feasible) but putting it to just give= all options) 2) MRs who share prefixes always send the packes on other link. (But its burden on the Wireless link (between AR and MRs)) 3) MRs keep update of the nodes under it and if packet is not destinied then only it forwards on other link. (Improved case 2 with intelligence at MR. ) 4) We can have Adhoc mode as explained by chan-Wah ng (I don't think that the NEMO talks about adhoc mode) If the Option 2 & 3 are the answer then, NEMO does not talk about th= is. So its hard to get the scenarion for anybody. Let me know your views on this. Regards, Wable R. U. >> >> Thanks and Regards, >> Sameer Kumar. >> >> >> -----Original Message----- >> From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Beha= lf Of >> Masayuki Kumazawa >> Sent: Thursday, August 18, 2005 8:23 AM >> To: nemo@ietf.org >> Subject: Re: [nemo] Split Networks:Query >> >> Hello Sammer, >> >> <000001c5a320$962b0590$44476c6b@sisodomain.com> From Sameer Kumar-= san >>> Hi all, >>> >>> I have a doubt regarding the concept of "Split Networks" in = NEMO. >>> Split Networks comprise the case (n,1,1): Multiple MRs, Single HA= ,=20 >>> Single >>> MNP. >>> >>> Figure 1. below depicts the Split Network scenario. No "split" = has >>> occured. MR1 and MR2 are together. >>> >>> MR1 >>> | _ | >>> |-|_|-| _____ >>> | p<- |-| | _ | _ >>> _ | | | |-|_|--|-|_|HA >>> MNN|_|-| | | | AR | >>> | _ |-|_____| >>> |-|_|-| INTERNET >>> |p<- | >>> MR2 >>> Figure 1: (n,1,1): Multiple MRs, 1 HA, 1 MNP >> >> In this case, split may occur in two ways. >> One case is that MR2, which is a portable device like a cellular p= hone, >> moves away from the network. >> >> The other case is that both of them are installed in different pla= ces but >> they are configured with the same MNP. >> >> In the second case without additional mechanism, prefix table must= be >> configured more carefully, maybe manually. >> >>> In this case, HA can send packets destined to MNN via MR1, or MR2= (Load >>> Balancing). The same situation in a wireless deployment is shown = in=20 >>> Figure >>> 2. Here also, we consider the case when no "split" has occurred i= .e. MR1 >> and >>> MR2 are together. >>> >>> AP1 MR1 >>> _ _ _ | >>> / |_|---|_|-| _____ >>> _ / p<- |-| | _ | _ >>> MNN|_| | | |-|_|--|-|_|HA >>> | | | AR | >>> _ _ |-|_____| >>> |_|---|_|-| INTERNET >>> p<- | >>> AP2 MR2 >>> >>> Figure 2: (n,1,1) : Multiple MRs, 1 HA, 1 MNP in a Wireless Sc= enario >> >>> In Figure 2. MNN is currently attached to the Access Point (AP1) = of MR1.=20 >>> I >>> have the following questions: >>> a)If HA tries to send packets to MNN via MR2, how will these pack= ets=20 >>> reach >>> MNN? Basically how is "Load Balancing" >>> possible for a case (n,1,1) in a practical wireless deployment? >> >>> b)Is it that the AP1 and AP2 are "physically connected"? If so, t= hen=20 >>> does >>> the term "split" means a "physical split"? >> >> In the architecture of current major wireless technologies, >> there is one AP in a BSS. >> >> So, as you pointed out, even if MR1 and MR2 are together, >> AP1 and AP2 can't be connected phisically as Access Point. >> >> However, if AP2 behaves as a STA, MR1 and MR2 can be connected= =20 >> phisically. >> In this configuration, all packets are forwarded via AP1, but load= =20 >> balancing >> >> between MR1 and MR2 seems possible. >> >> I'm not sure whether I understand your question, but I hope they w= ill be >> answer of your question. >> >> Best regards, >> Masayuki >> ----------- >> M.Kumazawa >> >> >> >> > > > >=20 From nemo-bounces@ietf.org Mon Aug 22 05:40:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E78mp-0003qi-9D; Mon, 22 Aug 2005 05:40:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E78mn-0003qd-UO for nemo@megatron.ietf.org; Mon, 22 Aug 2005 05:40:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03172 for ; Mon, 22 Aug 2005 05:40:07 -0400 (EDT) Received: from smtp1.mei.co.jp ([133.183.129.26] helo=smtp2.mei.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E79NL-0002IV-4F for nemo@ietf.org; Mon, 22 Aug 2005 06:17:55 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/jazz) with ESMTP id j7M9dbDp013431; Mon, 22 Aug 2005 18:39:37 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id j7M9dbp06348; Mon, 22 Aug 2005 18:39:37 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/whitesox) with ESMTP id j7M9dac13961; Mon, 22 Aug 2005 18:39:37 +0900 (JST) Received: from mozart.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Aug 2005 17:37:38 +0800 Received: by mozart.psl.com.sg (Postfix, from userid 1000) id 1D5C220C1A0; Mon, 22 Aug 2005 17:56:41 +0800 (SGT) Subject: Re: [nemo] Split Networks:Query From: Chan-Wah Ng To: Ranjitsinh Wable In-Reply-To: <000201c5a6e4$1c3e33c0$41476c6b@sisodomain.com> References: <000001c5a3f0$c2b24a30$44476c6b@sisodomain.com> <000201c5a6e4$1c3e33c0$41476c6b@sisodomain.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 22 Aug 2005 17:56:40 +0800 Message-Id: <1124704600.483.49.camel@bach.psl.com.sg> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 X-OriginalArrivalTime: 22 Aug 2005 09:37:38.0776 (UTC) FILETIME=[229FC580:01C5A6FD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello all, > I would like to know how the MR1, MR2 and MNN can be on same link > in wireless scenario? > > 1) whether you say that they all connected to the AR's wireless Link? > 2) If not, then whether the MNN have two interfaces to get in touch > with both the MRs? > > I will try to put this problem in slightly different scenario: > > As per NEMO concept we can have two wireless networks > > 1) Between the AR and the MR's > 2) Between MR and MNN. > > Now suppose the MNN's are going to use the same prefix then > there is no problem for the first network. As both the MRs are > on same link of AR. Its normal AR-MR communication. > > Lets think about the second wireless scenario i.e. Between > MR-MNN. Lets says there are two MR's on Link of AR > MR1, MR2. > > Now one MNN can connect to either of the MR. Say > it connected to MR1. Lets say packet is comming for MNN > to MR2 as per load balancing at HA of MRs. > > Now the question arieses is that how the packet will reach to MNN > via MR2? > > There can be some possiblities like > > 1) MNN have two links and get connected to both MRs. > (Sorry I know its not possible(feasible) but putting it to just give all > options) this is possible, but this is two different NEMOs as we have already explained in previous mails. > > 2) MRs who share prefixes always send the packes on other link. > (But its burden on the Wireless link (between AR and MRs)) Possible, but who would do that and why? > > 3) MRs keep update of the nodes under it and if > packet is not destinied then only it forwards on other link. > (Improved case 2 with intelligence at MR. ) okay, the MR is also a bridge now. Possible, but again highly unlikely. A more possible alternative to your Option 2&3 is the single AP bridge, connected to two MR scenario. > > 4) We can have Adhoc mode as explained by chan-Wah ng but > (I don't think that the NEMO talks about adhoc mode) I must stress that this has nothing to do with MANET. The ad-hoc mode I am saying is a 802.11 mode, which get rids of the concept of AP. So don't understand what do you mean by "don't think ... NEMO talks about adhoc mode". The reason why there is an apparent difficulty in visualizing a scenario where a mobile network with multiple MRs is because of the assumed 802.11 wireless LAN infrastructure-mode scenario. First 3 of your above 4 options all assumed that. If you throw away the concept of AP, you can have a lot more options, eg Bluetooth WPAN network, etc. > If the Option 2 & 3 are the answer then, NEMO does not talk about this. > So its hard to get the scenarion for anybody. I don't understand what you mean by the above statement "NEMO does not talk about this". In fact, NMEO shouldn't talk about any of this, because NEMO as a layer-3 protocol, is supposed to be agnostic to whatever access technology deployed for layer-2. /rgds /cwng > > Let me know your views on this. > > Thanks and Regards, > > Wable R. U. > > > > > Thanks and Regards, > > Sameer Kumar. > > > > > > -----Original Message----- > > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of > > Masayuki Kumazawa > > Sent: Thursday, August 18, 2005 8:23 AM > > To: nemo@ietf.org > > Subject: Re: [nemo] Split Networks:Query > > > > Hello Sammer, > > > > <000001c5a320$962b0590$44476c6b@sisodomain.com> From Sameer Kumar-san > >> Hi all, > >> > >> I have a doubt regarding the concept of "Split Networks" in NEMO. > >> Split Networks comprise the case (n,1,1): Multiple MRs, Single HA, Single > >> MNP. > >> > >> Figure 1. below depicts the Split Network scenario. No "split" has > >> occured. MR1 and MR2 are together. > >> > >> MR1 > >> | _ | > >> |-|_|-| _____ > >> | p<- |-| | _ | _ > >> _ | | | |-|_|--|-|_|HA > >> MNN|_|-| | | | AR | > >> | _ |-|_____| > >> |-|_|-| INTERNET > >> |p<- | > >> MR2 > >> Figure 1: (n,1,1): Multiple MRs, 1 HA, 1 MNP > > > > In this case, split may occur in two ways. > > One case is that MR2, which is a portable device like a cellular phone, > > moves away from the network. > > > > The other case is that both of them are installed in different places but > > they are configured with the same MNP. > > > > In the second case without additional mechanism, prefix table must be > > configured more carefully, maybe manually. > > > >> In this case, HA can send packets destined to MNN via MR1, or MR2 (Load > >> Balancing). The same situation in a wireless deployment is shown in > >> Figure > >> 2. Here also, we consider the case when no "split" has occurred i.e. MR1 > > and > >> MR2 are together. > >> > >> AP1 MR1 > >> _ _ _ | > >> / |_|---|_|-| _____ > >> _ / p<- |-| | _ | _ > >> MNN|_| | | |-|_|--|-|_|HA > >> | | | AR | > >> _ _ |-|_____| > >> |_|---|_|-| INTERNET > >> p<- | > >> AP2 MR2 > >> > >> Figure 2: (n,1,1) : Multiple MRs, 1 HA, 1 MNP in a Wireless Scenario > > > >> In Figure 2. MNN is currently attached to the Access Point (AP1) of MR1. > >> I > >> have the following questions: > >> a)If HA tries to send packets to MNN via MR2, how will these packets > >> reach > >> MNN? Basically how is "Load Balancing" > >> possible for a case (n,1,1) in a practical wireless deployment? > > > >> b)Is it that the AP1 and AP2 are "physically connected"? If so, then does > >> the term "split" means a "physical split"? > > > > In the architecture of current major wireless technologies, > > there is one AP in a BSS. > > > > So, as you pointed out, even if MR1 and MR2 are together, > > AP1 and AP2 can't be connected phisically as Access Point. > > > > However, if AP2 behaves as a STA, MR1 and MR2 can be connected phisically. > > In this configuration, all packets are forwarded via AP1, but load > > balancing > > > > between MR1 and MR2 seems possible. > > > > I'm not sure whether I understand your question, but I hope they will be > > answer of your question. > > > > Best regards, > > Masayuki > > ----------- > > M.Kumazawa > > > > > > > > > > > > > > From nemo-bounces@ietf.org Mon Aug 22 10:11:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7D1l-0000Kt-HR; Mon, 22 Aug 2005 10:11:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7D1i-0000Kh-KJ for nemo@megatron.ietf.org; Mon, 22 Aug 2005 10:11:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17677 for ; Mon, 22 Aug 2005 10:11:48 -0400 (EDT) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7DcH-00022L-L6 for nemo@ietf.org; Mon, 22 Aug 2005 10:49:38 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 7DAE985B9F; Mon, 22 Aug 2005 16:11:34 +0200 (CEST) Received: from [163.117.203.145] (unknown [163.117.203.145]) by smtp01.uc3m.es (Postfix) with ESMTP id 9F4A285BB3; Mon, 22 Aug 2005 16:11:30 +0200 (CEST) In-Reply-To: <001b01c5a6e5$739edd80$41476c6b@sisodomain.com> References: <001b01c5a6e5$739edd80$41476c6b@sisodomain.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] Split Networks:Query Date: Mon, 22 Aug 2005 16:12:27 +0200 To: Ranjitsinh Wable X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Wable, El 22/08/2005, a las 8:48, Ranjitsinh Wable escribi=F3: > Hi Marcelo, > > Please see the inlined comments. > >> ----- Original Message ----- From: "marcelo bagnulo braun"=20 >> >> To: "Sameer Kumar" >> Cc: "IETF NEMO WG" >> Sent: Thursday, August 18, 2005 6:43 PM >> Subject: Re: [nemo] Split Networks:Query >> >> >> >> El 18/08/2005, a las 14:31, Sameer Kumar escribi=F3: >>>> MR1 >>>> | _ | >>>> |-|_|-| _____ >>>> | p<- |-| | _ | _ >>>> _ | | | |-|_|--|-|_|HA >>>> MNN|_|-| | | | AR | >>>> | _ |-|_____| >>>> |-|_|-| INTERNET >>>> |p<- | >>>> MR2 >>>> Figure 1: (n,1,1): Multiple MRs, 1 HA, 1 MNP >>> keeping the figure for reference... First of all, i am really failing to understand what is so=20 wireless-specific in any of those scenarios... i mean nemo is basically=20= an IP layer protocol right? so why is it relevant that this is a=20 wireless case? i mean, i think that exactly the same cases could be=20 considered in a wired scenario... am i missing something? (i agree that=20= splitting networks in a wired scenario is much less likely than in a=20 wwireless scenario, but this would not change the solution behaviour=20 imho) Second, i am not sure i understand the actual cases we are=20 discussing... i mean the draft tries to provide a description of the=20 problem of split networks, and does not provides an actual solution to=20= the problem. It is accepted that in some scenarios, where the nemo=20 splits, there are problems yet unsolved. As i see it we are in the point of understanding that there is a=20 problem and we could consider solutions (i guess there are a few drafts=20= proposing solutions) So, in brief at this point the situation w.r.t. problem is that: - splitting a nemo may result in communication disruption of some of=20 the MNN with current nemo support - additional tools/considerations/constraints are needed to support=20 this scenario Do we agree so far? I mean, if you are arguing that splitting a nemo may cause problems, i=20= agree But before moving on to discussing solutions i would like to make sure=20= that we have a common understanding about what the problem is (i.e. if=20= you agree with the problem description included in the draft). In=20 particular, i would like to understand if you consider that there are=20 some wireless specific considerations in this problem (i guess so=20 because of your mail) and which are those. > I will try to put this problem in slightly different scenario: > > As per NEMO concept we can have two wireless networks > > 1) Between the AR and the MR's > 2) Between MR and MNN. > right > Now suppose the MNN's are going to use the same prefix then > there is no problem for the first network. As both the MRs are > on same link of AR. Its normal AR-MR communication. > > Lets think about the second wireless scenario i.e. Between > MR-MNN. Lets says there are two MR's on Link of AR > MR1, MR2. > i don't understand what you mean here in this second scenario, the link between MR1, MR2 and MNNs is=20 wireless... not sure how does the AR fits in here. As i see it, the=20 (wireless) link between MR1, MR2 and MNNs is a different wireless link=20= that the one between the MRs and the ARs > Now one MNN can connect to either of the MR. Are you considering that the network is split? If yes, then as i mentioned before we do may have problems. If no, the MNNs are connected to the wireless link where both MR1 and=20 MR2 are, what is the problem with this? The options below are when the nemo is split of before splitting? Again the same, if no split then no problem If split we do may have issues that need additional tools Regards, marcelo > Say > it connected to MR1. Lets say packet is comming for MNN > to MR2 as per load balancing at HA of MRs. > > Now the question arieses is that how the packet will reach to MNN > via MR2? > > There can be some possiblities like > > 1) MNN have two links and get connected to both MRs. > (Sorry I know its not possible(feasible) but putting it to just give=20= > all > options) > > 2) MRs who share prefixes always send the packes on other link. > (But its burden on the Wireless link (between AR and MRs)) > > 3) MRs keep update of the nodes under it and if > packet is not destinied then only it forwards on other link. > (Improved case 2 with intelligence at MR. ) > > 4) We can have Adhoc mode as explained by chan-Wah ng > (I don't think that the NEMO talks about adhoc mode) > > If the Option 2 & 3 are the answer then, NEMO does not talk about = this. > So its hard to get the scenarion for anybody. > > Let me know your views on this. > > Regards, > > Wable R. U. > >>> >>> Thanks and Regards, >>> Sameer Kumar. >>> >>> >>> -----Original Message----- >>> From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf=20= >>> Of >>> Masayuki Kumazawa >>> Sent: Thursday, August 18, 2005 8:23 AM >>> To: nemo@ietf.org >>> Subject: Re: [nemo] Split Networks:Query >>> >>> Hello Sammer, >>> >>> <000001c5a320$962b0590$44476c6b@sisodomain.com> =46rom Sameer = Kumar-san >>>> Hi all, >>>> >>>> I have a doubt regarding the concept of "Split Networks" in=20 >>>> NEMO. >>>> Split Networks comprise the case (n,1,1): Multiple MRs, Single HA,=20= >>>> Single >>>> MNP. >>>> >>>> Figure 1. below depicts the Split Network scenario. No "split" = has >>>> occured. MR1 and MR2 are together. >>>> >>>> MR1 >>>> | _ | >>>> |-|_|-| _____ >>>> | p<- |-| | _ | _ >>>> _ | | | |-|_|--|-|_|HA >>>> MNN|_|-| | | | AR | >>>> | _ |-|_____| >>>> |-|_|-| INTERNET >>>> |p<- | >>>> MR2 >>>> Figure 1: (n,1,1): Multiple MRs, 1 HA, 1 MNP >>> >>> In this case, split may occur in two ways. >>> One case is that MR2, which is a portable device like a cellular=20 >>> phone, >>> moves away from the network. >>> >>> The other case is that both of them are installed in different=20 >>> places but >>> they are configured with the same MNP. >>> >>> In the second case without additional mechanism, prefix table must = be >>> configured more carefully, maybe manually. >>> >>>> In this case, HA can send packets destined to MNN via MR1, or MR2=20= >>>> (Load >>>> Balancing). The same situation in a wireless deployment is shown in=20= >>>> Figure >>>> 2. Here also, we consider the case when no "split" has occurred=20 >>>> i.e. MR1 >>> and >>>> MR2 are together. >>>> >>>> AP1 MR1 >>>> _ _ _ | >>>> / |_|---|_|-| _____ >>>> _ / p<- |-| | _ | _ >>>> MNN|_| | | |-|_|--|-|_|HA >>>> | | | AR | >>>> _ _ |-|_____| >>>> |_|---|_|-| INTERNET >>>> p<- | >>>> AP2 MR2 >>>> >>>> Figure 2: (n,1,1) : Multiple MRs, 1 HA, 1 MNP in a Wireless=20 >>>> Scenario >>> >>>> In Figure 2. MNN is currently attached to the Access Point (AP1) of=20= >>>> MR1. I >>>> have the following questions: >>>> a)If HA tries to send packets to MNN via MR2, how will these=20 >>>> packets reach >>>> MNN? Basically how is "Load Balancing" >>>> possible for a case (n,1,1) in a practical wireless deployment? >>> >>>> b)Is it that the AP1 and AP2 are "physically connected"? If so,=20 >>>> then does >>>> the term "split" means a "physical split"? >>> >>> In the architecture of current major wireless technologies, >>> there is one AP in a BSS. >>> >>> So, as you pointed out, even if MR1 and MR2 are together, >>> AP1 and AP2 can't be connected phisically as Access Point. >>> >>> However, if AP2 behaves as a STA, MR1 and MR2 can be connected=20 >>> phisically. >>> In this configuration, all packets are forwarded via AP1, but load=20= >>> balancing >>> >>> between MR1 and MR2 seems possible. >>> >>> I'm not sure whether I understand your question, but I hope they=20 >>> will be >>> answer of your question. >>> >>> Best regards, >>> Masayuki >>> ----------- >>> M.Kumazawa >>> >>> >>> >>> >> >> >> > From nemo-bounces@ietf.org Mon Aug 22 15:00:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7HXF-0007NI-W4; Mon, 22 Aug 2005 15:00:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7HXC-0007My-92 for nemo@megatron.ietf.org; Mon, 22 Aug 2005 15:00:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04239 for ; Mon, 22 Aug 2005 15:00:36 -0400 (EDT) Received: from web33506.mail.mud.yahoo.com ([68.142.206.155]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E7I7h-0002Ti-E9 for nemo@ietf.org; Mon, 22 Aug 2005 15:38:29 -0400 Received: (qmail 42229 invoked by uid 60001); 22 Aug 2005 19:00:21 -0000 Message-ID: <20050822190021.42227.qmail@web33506.mail.mud.yahoo.com> Received: from [141.225.9.54] by web33506.mail.mud.yahoo.com via HTTP; Mon, 22 Aug 2005 12:00:20 PDT X-RocketYMMF: yangxiao_acm Date: Mon, 22 Aug 2005 12:00:20 -0700 (PDT) From: Yang Xiao To: multicomm@comsoc.org, tccc@cs.columbia.edu, comm-theory@ieee.org, manet@ietf.org, nemo@ietf.org, TCPC.Mail@sce.carleton.ca MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA04239 Cc: Subject: [nemo] CFP: The First IEEE International Workshop on Security and Pervasive Multimedia Environments X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yangxiao@ieee.org List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org The First IEEE International Workshop on Security and Pervasive Multimedia Environments Call for Papers Pervasive multimedia environments provide users to access multimedia services anytime and anywhere. The resources limitations of pervasive devices and huge data amount make security a challenge. On the other hand, pervasive multimedia services enhance the mission of security and protection. For example, the collection of video surveillance data and/or sensor video data is useful for monitoring.=20 This workshop provides an international forum for academic, industry and government professionals to discuss recent progress in the above emerging research areas. Topics of interest include, but are not limited to: Privacy and anonymity=20 Trust management=20 Video surveillance=20 Quality of protection and QoS=20 Secure multimedia information sharing=20 Access control=20 Cryptographic algorithms=20 Information hiding and multimedia watermarking=20 Key management and authentication=20 Network security issues and protocols=20 Case studies=20 Risk and vulnerability assessment=20 Commercial and industrial experiences=20 Testbed and evaluation=20 Biometrics=20 Forensics=20 Submissions The written and spoken language of MultiSec2005 is English. All submissions will be electronic, and and the web site is here. Full papers must not exceed 12 pages printed using at least 11-point type and double spacing. All papers should be in Adobe portable document format (PDF) or PostScript format. The paper should have a cover page, which includes a 200-word abstract, a list of keywords, and author's phone number and e- mail address. The accepted papers will be published along with Conference Proceedings by the IEEE Computer Society Press. A printable version of the call for paper can be downloaded here: =20 Important Dates =B7 August 30, 2005 Submission of papers due =B7 September 14, 2005 Notification of acceptance of papers =B7 October 2, 2005 Camera-Ready copy of accepted papers due=20 Organization Steering Chair: =20 Laurence T. Yang, St. Francis Xavier University, Canada General Chairs: Shu-Ching Chen, Florida International University, USA Yang Xiao, University of Memphis, USA Program Chairs: Alex Zhaoyu Liu, University of North Carolina at Charlotte, USA Kouichi Sakurai, Kyushu University, Japan Program Committee Members:=20 Jiannong Cao, Hong Kong Polytechnic Univ., Hong Kong Chih-Yung Chang, Tamkang University, Taiwan Weide (Willie) Chang, Sacramento State University, USA Han-Chieh Chao, National Dong Hwa University, Taiwan Ing-Ray Chen, Virginia Polytechnic Institute and State University, USA Shigang Chen, University of Florida, USA Tanmoy Kanti Das, I2R, Singapore Mieso Denko, University of Guelph, Canada Jing Deng, University of New Orleans, USA Christos Douligeris, University of Piraeus, Greece=20 Tomoya Enokido, Rissho University, Japan Zongming Fei, University of Kentucky, USA Dieter Gollmann, TU Hamburg-Harburg, Germany Ekram Hossain, University of Manitoba, Canada Dong Hoon Lee, Korea Univ., Korea Hong-Va Leong, HongKong Polytechnic Univ., HK Raymond Li, Cisco Systems Inc., USA Xiang-Yang Li, Illinois Institute of Technology, USA=20 Jonathan Chien-Liang Liu, University of Florida, USA Javier Lopez, University of Malaga, Spain Weijia Jia, City University of Hong Kong, Hong Kong Geyong Min, University of Bradford, UK Jelena Misic, University of Manitoba, Canada Vojislav B Misic, University of Manitoba, Canada Chris Mitchell, University of London, UK Yi Mu, University of Wollongong, Australia David Naccache, Gempuls, France Qiang Ni, Hamilton Institute,National University of Ireland, Ireland Thomas Noel, University Louis Pasteur, France and Keio Univ., Japan R. Phan, Swinburne University of Technology, Malaysia Yi Qian, University of Puerto Rico at Mayag=FCez, USA Masakazu Soshi, JAIST, Japan Bo Sun, Lamar University, USA Tsuyoshi Takagi, FUN, Japan Ilenia Tinnirello, University of Palermo, Italy=20 Dimitrios D. Vergados, University of the Aegean, Greece Li-Chun Wang, National Chiao-Tung University, Taiwan Xudong Wang, Kiyon Inc., USA Duncan S. Wong, City University of Hong Kong, Hong Kong Hongyi Wu, University of Louisiana at Lafayette, USA Kui Wu, University of Victoria, Canada Bin Xiao, Hong Kong Polytechnic Univ., Hong Kong Lu Yan, Turku Centre for Computer Science, Finland Hao Zhu, Florida International University, USA =3D=3D http://coitweb.uncc.edu/~zhliu/MultiSec05/ From nemo-bounces@ietf.org Mon Aug 22 15:50:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7IJN-0000Fx-Fx; Mon, 22 Aug 2005 15:50:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7IJ4-00009k-4u; Mon, 22 Aug 2005 15:50:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08464; Mon, 22 Aug 2005 15:50:03 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7Itf-0004Eu-EY; Mon, 22 Aug 2005 16:27:56 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E7IIz-0000ud-Kk; Mon, 22 Aug 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 22 Aug 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-prefix-delegation-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Mobility Working Group of the IETF. Title : Mobile Network Prefix Delegation Author(s) : T. Kniveton, P. Thubert Filename : draft-ietf-nemo-prefix-delegation-00.txt Pages : 27 Date : 2005-8-22 This paper extends the Nemo Basic Support [10] for a Mobile Router to synchronize its Mobile Network Prefixes with its Home Agents and obtain new ones dynamically. The proposed prefix delegation mechanism is agnostic to the way the prefixes are managed and provisioned at the Home Agent; it might be used for bootstrapping, resynchronization at binding creation or after a loss of states (eg MR reboot), MNP Renumbering, and configuration checking for loop avoidance. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-prefix-delegation-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-prefix-delegation-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-prefix-delegation-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-8-22130911.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-prefix-delegation-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-prefix-delegation-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-22130911.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-bounces@ietf.org Mon Aug 22 22:09:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7OE4-0004nN-Dj; Mon, 22 Aug 2005 22:09:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7OE1-0004lL-PH for nemo@megatron.ietf.org; Mon, 22 Aug 2005 22:09:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14235 for ; Mon, 22 Aug 2005 22:09:15 -0400 (EDT) Received: from smtp1.mei.co.jp ([133.183.129.26] helo=smtp2.mei.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7ODp-0002oD-PH for nemo@ietf.org; Mon, 22 Aug 2005 22:09:07 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id j7N28mBG007974; Tue, 23 Aug 2005 11:08:48 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id j7N28o529529; Tue, 23 Aug 2005 11:08:50 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/whitesox) with ESMTP id j7N28nc12278; Tue, 23 Aug 2005 11:08:49 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.11.6p2/3.7W/soml22) id j7N28nl16438; Tue, 23 Aug 2005 11:08:49 +0900 (JST) Received: from nancy by soml22.jp.panasonic.com (8.11.6p2/3.7W) with ESMTP id j7N28m916405; Tue, 23 Aug 2005 11:08:48 +0900 (JST) Message-Id: <200508230208.j7N28m916405@soml22.jp.panasonic.com> Date: Tue, 23 Aug 2005 11:08:49 +0900 From: Masayuki Kumazawa Subject: Re: [nemo] Split Networks:Query To: In-Reply-To: References: <001b01c5a6e5$739edd80$41476c6b@sisodomain.com> X-Mailer: Datula version 1.51.09 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Marcelo and all, Please see the inlined comments. From marcelo bagnulo braun-san >Hi Wable, > >El 22/08/2005, a las 8:48, Ranjitsinh Wable escribi$B!&(B > >> Hi Marcelo, >> >> Please see the inlined comments. >>> >>> El 18/08/2005, a las 14:31, Sameer Kumar escribi$B!&(B >>>>> MR1 >>>>> | _ | >>>>> |-|_|-| _____ >>>>> | p<- |-| | _ | _ >>>>> _ | | | |-|_|--|-|_|HA >>>>> MNN|_|-| | | | AR | >>>>> | _ |-|_____| >>>>> |-|_|-| INTERNET >>>>> |p<- | >>>>> MR2 >>>>> Figure 1: (n,1,1): Multiple MRs, 1 HA, 1 MNP >>>> > >keeping the figure for reference... > >First of all, i am really failing to understand what is so >wireless-specific in any of those scenarios... i mean nemo is basically >an IP layer protocol right? so why is it relevant that this is a >wireless case? i mean, i think that exactly the same cases could be >considered in a wired scenario... am i missing something? (i agree that >splitting networks in a wired scenario is much less likely than in a >wwireless scenario, but this would not change the solution behaviour >imho) > >Second, i am not sure i understand the actual cases we are >discussing... i mean the draft tries to provide a description of the >problem of split networks, and does not provides an actual solution to >the problem. It is accepted that in some scenarios, where the nemo >splits, there are problems yet unsolved. I assume that you mean the draft is draft-kumazawa-nemo-tbdnd-02.txt here. If so, it does not provide an actual solution as you mentioned. It provides only the way HA confirms whether split occurs or not. And it does not provide any solution solving problems which will happen after split occurs. This is because I guessed there were several different policies about addressing the problem. To keep communications in both of mobile networks after split occurs, renumbering of MRs may be needed. Otherwise HA have only to reject a Binding Update to prohibit MRs' splitting. However, I agree with you on the point that actual cases and problems need to be clarified more before discussing solutions. Best regards, Masayuki >As i see it we are in the point of understanding that there is a >problem and we could consider solutions (i guess there are a few drafts >proposing solutions) > >So, in brief at this point the situation w.r.t. problem is that: >- splitting a nemo may result in communication disruption of some of >the MNN with current nemo support >- additional tools/considerations/constraints are needed to support >this scenario > >Do we agree so far? > >I mean, if you are arguing that splitting a nemo may cause problems, i >agree > >But before moving on to discussing solutions i would like to make sure >that we have a common understanding about what the problem is (i.e. if >you agree with the problem description included in the draft). In >particular, i would like to understand if you consider that there are >some wireless specific considerations in this problem (i guess so >because of your mail) and which are those. ----------- M.Kumazawa From nemo-bounces@ietf.org Tue Aug 23 02:14:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7S36-0003Ib-Sm; Tue, 23 Aug 2005 02:14:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7S34-0003Gt-8j for nemo@megatron.ietf.org; Tue, 23 Aug 2005 02:14:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15071 for ; Tue, 23 Aug 2005 02:14:12 -0400 (EDT) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7S34-0000fI-Tg for nemo@ietf.org; Tue, 23 Aug 2005 02:14:17 -0400 Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0ILN00AGHVZ95T@mailout1.samsung.com> for nemo@ietf.org; Tue, 23 Aug 2005 15:13:57 +0900 (KST) Received: from wable ([107.108.71.65]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0ILN00GJ1VZ3IZ@mmp1.samsung.com> for nemo@ietf.org; Tue, 23 Aug 2005 15:13:57 +0900 (KST) Date: Tue, 23 Aug 2005 11:19:03 +0530 From: Ranjitsinh Wable Subject: Re: [nemo] Split Networks:Query To: marcelo bagnulo braun Message-id: <000601c5a7a9$2f457580$41476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; reply-type=response; charset=iso-8859-1; format=flowed Content-transfer-encoding: QUOTED-PRINTABLE X-Priority: 3 X-MSMail-priority: Normal References: <001b01c5a6e5$739edd80$41476c6b@sisodomain.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3b3709b7fb3320c78bd7b1555081f0fc Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Marcelo, Kindly see the comments inlined ----- Original Message -----=20 =46rom: "marcelo bagnulo braun" To: "Ranjitsinh Wable" Cc: "IETF NEMO WG" ; "Sameer Kumar" Sent: Monday, August 22, 2005 7:42 PM Subject: Re: [nemo] Split Networks:Query Hi Wable, El 22/08/2005, a las 8:48, Ranjitsinh Wable escribi=F3: > Hi Marcelo, > > Please see the inlined comments. > >> ----- Original Message ----- From: "marcelo bagnulo braun"=20 >> >> To: "Sameer Kumar" >> Cc: "IETF NEMO WG" >> Sent: Thursday, August 18, 2005 6:43 PM >> Subject: Re: [nemo] Split Networks:Query >> >> >> >> El 18/08/2005, a las 14:31, Sameer Kumar escribi=F3: >>>> MR1 >>>> | _ | >>>> |-|_|-| _____ >>>> | p<- |-| | _ | _ >>>> _ | | | |-|_|--|-|_|HA >>>> MNN|_|-| | | | AR | >>>> | _ |-|_____| >>>> |-|_|-| INTERNET >>>> |p<- | >>>> MR2 >>>> Figure 1: (n,1,1): Multiple MRs, 1 HA, 1 MNP >>> keeping the figure for reference... First of all, i am really failing to understand what is so wireless-specific in any of those scenarios... i mean nemo is basical= ly an IP layer protocol right? so why is it relevant that this is a wireless case? i mean, i think that exactly the same cases could be considered in a wired scenario... am i missing something? (i agree th= at splitting networks in a wired scenario is much less likely than in a wwireless scenario, but this would not change the solution behaviour imho) =3D=3D=3D=3D> This question about wireless scenarion arised bcoz we want to know in wireless scenario how the sharing of the prefix works?(Problem bef= ore=20 split). May be its more related to Laye2 which L3 solution will not bother but still we would like to know the practical implementation feasibil= ity, in current avialable wireless systems. Second, i am not sure i understand the actual cases we are discussing... i mean the draft tries to provide a description of the problem of split networks, and does not provides an actual solution t= o the problem. It is accepted that in some scenarios, where the nemo splits, there are problems yet unsolved. As i see it we are in the point of understanding that there is a problem and we could consider solutions (i guess there are a few draf= ts proposing solutions) So, in brief at this point the situation w.r.t. problem is that: - splitting a nemo may result in communication disruption of some of the MNN with current nemo support - additional tools/considerations/constraints are needed to support this scenario =3D=3D=3D=3D> This is not regarding the solution on split network but its regarding= the basic understading of existing cases. Sorry if we asking very basic= =20 questions. But we are not clear about it. Do we agree so far? =3D=3D=3D> Yes I agree on your point. I mean, if you are arguing that splitting a nemo may cause problems, = i agree But before moving on to discussing solutions i would like to make sur= e that we have a common understanding about what the problem is (i.e. i= f you agree with the problem description included in the draft). In particular, i would like to understand if you consider that there are some wireless specific considerations in this problem (i guess so because of your mail) and which are those. > I will try to put this problem in slightly different scenario: > > As per NEMO concept we can have two wireless networks > > 1) Between the AR and the MR's > 2) Between MR and MNN. > right > Now suppose the MNN's are going to use the same prefix then > there is no problem for the first network. As both the MRs are > on same link of AR. Its normal AR-MR communication. > > Lets think about the second wireless scenario i.e. Between > MR-MNN. Lets says there are two MR's on Link of AR > MR1, MR2. > i don't understand what you mean here in this second scenario, the link between MR1, MR2 and MNNs is wireless... not sure how does the AR fits in here. As i see it, the (wireless) link between MR1, MR2 and MNNs is a different wireless lin= k that the one between the MRs and the ARs =3D=3D=3D=3D>> I agree the link between AR and MR is different than the Link between MNN and MRs (same I stated above point 1) and 2)). Basic question here is that how MR1, MR2 and MNN share one link. (May be L2 related question but its basic requirement to share the pe= rfixes) Does MNN communicates with both MR1 and MR2? May be different answers for Bluetooth and WLAN. We tried to put the WLAN scenario with AP but as Chan-Wah said and we also understand it is not possible. As suggested by Chan-Wah WLAN adhoc mode can help in this regard. But we are not sure how the link concept will be provided by the adhoc WLAN. We may look into that option. About bluetooth option provides mechanism to comminicate with more than one router at a time (MR1, MR2 in above example) but again it does not ptovide link concept as wired scenario. > Now one MNN can connect to either of the MR. Are you considering that the network is split? If yes, then as i mentioned before we do may have problems. If no, the MNNs are connected to the wireless link where both MR1 and MR2 are, what is the problem with this? The options below are when the nemo is split of before splitting? Again the same, if no split then no problem If split we do may have issues that need additional tools. =3D=3D=3D=3D> We agree there are some issues in the split network which need to be= =20 addressed. But this mail was for basic clarification of the actual implementatio= n of=20 sharing of prefix on network. Regards, Wable R. U. Regards, marcelo > Say > it connected to MR1. Lets say packet is comming for MNN > to MR2 as per load balancing at HA of MRs. > > Now the question arieses is that how the packet will reach to MNN > via MR2? > > There can be some possiblities like > > 1) MNN have two links and get connected to both MRs. > (Sorry I know its not possible(feasible) but putting it to just giv= e all > options) > > 2) MRs who share prefixes always send the packes on other link. > (But its burden on the Wireless link (between AR and MRs)) > > 3) MRs keep update of the nodes under it and if > packet is not destinied then only it forwards on other link. > (Improved case 2 with intelligence at MR. ) > > 4) We can have Adhoc mode as explained by chan-Wah ng > (I don't think that the NEMO talks about adhoc mode) > > If the Option 2 & 3 are the answer then, NEMO does not talk about t= his. > So its hard to get the scenarion for anybody. > > Let me know your views on this. > > Regards, > > Wable R. U. > >>> >>> Thanks and Regards, >>> Sameer Kumar. >>> >>> >>> -----Original Message----- >>> From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Beh= alf Of >>> Masayuki Kumazawa >>> Sent: Thursday, August 18, 2005 8:23 AM >>> To: nemo@ietf.org >>> Subject: Re: [nemo] Split Networks:Query >>> >>> Hello Sammer, >>> >>> <000001c5a320$962b0590$44476c6b@sisodomain.com> From Sameer Kumar= -san >>>> Hi all, >>>> >>>> I have a doubt regarding the concept of "Split Networks" in= NEMO. >>>> Split Networks comprise the case (n,1,1): Multiple MRs, Single H= A,=20 >>>> Single >>>> MNP. >>>> >>>> Figure 1. below depicts the Split Network scenario. No "split"= has >>>> occured. MR1 and MR2 are together. >>>> >>>> MR1 >>>> | _ | >>>> |-|_|-| _____ >>>> | p<- |-| | _ | _ >>>> _ | | | |-|_|--|-|_|HA >>>> MNN|_|-| | | | AR | >>>> | _ |-|_____| >>>> |-|_|-| INTERNET >>>> |p<- | >>>> MR2 >>>> Figure 1: (n,1,1): Multiple MRs, 1 HA, 1 MNP >>> >>> In this case, split may occur in two ways. >>> One case is that MR2, which is a portable device like a cellular = phone, >>> moves away from the network. >>> >>> The other case is that both of them are installed in different pl= aces=20 >>> but >>> they are configured with the same MNP. >>> >>> In the second case without additional mechanism, prefix table mus= t be >>> configured more carefully, maybe manually. >>> >>>> In this case, HA can send packets destined to MNN via MR1, or MR= 2 (Load >>>> Balancing). The same situation in a wireless deployment is shown= in=20 >>>> Figure >>>> 2. Here also, we consider the case when no "split" has occurred = i.e.=20 >>>> MR1 >>> and >>>> MR2 are together. >>>> >>>> AP1 MR1 >>>> _ _ _ | >>>> / |_|---|_|-| _____ >>>> _ / p<- |-| | _ | _ >>>> MNN|_| | | |-|_|--|-|_|HA >>>> | | | AR | >>>> _ _ |-|_____| >>>> |_|---|_|-| INTERNET >>>> p<- | >>>> AP2 MR2 >>>> >>>> Figure 2: (n,1,1) : Multiple MRs, 1 HA, 1 MNP in a Wireless S= cenario >>> >>>> In Figure 2. MNN is currently attached to the Access Point (AP1)= of=20 >>>> MR1. I >>>> have the following questions: >>>> a)If HA tries to send packets to MNN via MR2, how will these pac= kets=20 >>>> reach >>>> MNN? Basically how is "Load Balancing" >>>> possible for a case (n,1,1) in a practical wireless deployment? >>> >>>> b)Is it that the AP1 and AP2 are "physically connected"? If so, = then=20 >>>> does >>>> the term "split" means a "physical split"? >>> >>> In the architecture of current major wireless technologies, >>> there is one AP in a BSS. >>> >>> So, as you pointed out, even if MR1 and MR2 are together, >>> AP1 and AP2 can't be connected phisically as Access Point. >>> >>> However, if AP2 behaves as a STA, MR1 and MR2 can be connected= =20 >>> phisically. >>> In this configuration, all packets are forwarded via AP1, but loa= d=20 >>> balancing >>> >>> between MR1 and MR2 seems possible. >>> >>> I'm not sure whether I understand your question, but I hope they = will be >>> answer of your question. >>> >>> Best regards, >>> Masayuki >>> ----------- >>> M.Kumazawa >>> >>> >>> >>> >> >> >> > From nemo-bounces@ietf.org Tue Aug 23 07:45:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7XDI-0008Mi-3S; Tue, 23 Aug 2005 07:45:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7XDF-0008MW-Hc for nemo@megatron.ietf.org; Tue, 23 Aug 2005 07:45:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28690 for ; Tue, 23 Aug 2005 07:45:04 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7XDK-0001Vp-Pw for nemo@ietf.org; Tue, 23 Aug 2005 07:45:12 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id DA02189852 for ; Tue, 23 Aug 2005 14:44:54 +0300 (EEST) Message-ID: <430B0C42.4050709@piuha.net> Date: Tue, 23 Aug 2005 14:45:06 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit Subject: [nemo] review of draft-ietf-nemo-ro-problem-statement-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi all, I read this draft and found it generally OK. Some comments: I was convinced that route optimization is useful even prior to reading this document, and would probably have been convinced of it even by a shorter document. I understand that some solutions in this space are being considered by the WG, and I look forward to seeing how they solve issues that come up. One aspect of the justification for work in this space was not covered in the draft, however. We do understand well the technical implications, but it would be interesting to hear about vendors and service providers wishing to deploy nemo technology, and their specific expectations. There are a number of reasons why route optimization can be useful, but some of those reasons are very different from each other. For instance, if we need a solution for loop avoidance that may be very different from issues relating to pure optimization of RTTs and header sizes. Different types of networks have also different requirements regarding letting visiting nodes route traffic through home networks. And disadvantages of extreme nesting may or may not be a real issue, depending on the type of networks being planned. Before we start new work it would probably make sense to understand what the use cases and the demand is. (Of course, you probably have discussed all this already -- I have not followed the list closely.) > NEMO Basic Support presents a number of additional issues, making the > problem more complex, so it was decided to address Route Optimization > separately. In that case, the expected benefits are more dramatic, > and a Route Optimization mechanism could enable connectivity that > would be broken otherwise. In that sense, Route Optimization is even > more important to NEMO Basic Support than it is to Mobile IPv6. > > This worries me a bit. Route optimization in Mobile IPv6 was never designed as a mechanism that guarantees optimal routing: correspondent nodes can refuse to honor requests based on resource constraints, there may situations where some traffic needs to be routed through tunnels anyway, etc. Of course, what ever solutions we come by in this space need to deal with these issues. I'm just making an observation that this may imply a solution that is quite different, or even completely distinct, from the current Mobile IPv6 mechanisms. > When Mobile > Routers have no prior knowledge of their peers (no Security > association, AAA, PKI etc...) it can still be mutually beneficial to > apply a form of reciprocal altruism based on anonymity and > innocuousness. In particular, it is possible to adopt a tit for tat > (T4T) strategy and forward traffic unless the other party proves to > be uncooperative when it is solicited. > This is interesting, but might also be its own problem area all by itself. > Then again, a Route Optimization mechanism that bypasses the nested > tunnel might enable the parent traffic to reach the Internet and let > it bind. At that point, the child Mobile Router would be able to > reach its parent and bind in turn. Additional nested Route > Optimization solutions might also enable the child to locate its Home > Agent in the nested structure and bind regardless of whether the > reach to the Internet is available at all. > > It isn't clear to me that this can be done. Most route optimization schemes appear to need some roundtrips through the "home", so lack of internet connectivity would probably be a problem, at least if its prolonged. There are also schemes that do not need "home" participation, but it remains to be seen if we could make them compatible with Mobile IPv6-based schemes. Anyway, I'm looking forward to the solutions proposals... >5. Security Considerations > > This is an informational document that describes some limitations > with NEMO Basic Support and does not introduce any additional > security concerns. Please see RFC3963 [1] for security > considerations pertaining to the NEMO Basic Support protocol. > Avoidance of home network policy controls or the t4t mode would probably imply some new security issues to think about. Might be worthwhile to mention them here. Editorial comments: > Agent on the Internet, the increase in delay is tremendous. > s/tremendous/larger/ (I prefer to use milder words, at least for me it makes the case better than strong argumentation.) --Jari From nemo-bounces@ietf.org Tue Aug 23 07:55:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7XN5-00028l-3W; Tue, 23 Aug 2005 07:55:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7XMv-000263-NG for nemo@megatron.ietf.org; Tue, 23 Aug 2005 07:55:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29092 for ; Tue, 23 Aug 2005 07:55:04 -0400 (EDT) Received: from web33509.mail.mud.yahoo.com ([68.142.206.158]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E7XN0-0001lu-7v for nemo@ietf.org; Tue, 23 Aug 2005 07:55:12 -0400 Received: (qmail 89514 invoked by uid 60001); 23 Aug 2005 11:54:53 -0000 Message-ID: <20050823115453.89512.qmail@web33509.mail.mud.yahoo.com> Received: from [70.156.50.105] by web33509.mail.mud.yahoo.com via HTTP; Tue, 23 Aug 2005 04:54:53 PDT X-RocketYMMF: yangxiao_acm Date: Tue, 23 Aug 2005 04:54:53 -0700 (PDT) From: Yang Xiao To: multicomm@comsoc.org, tccc@cs.columbia.edu, comm-theory@ieee.org, manet@ietf.org, nemo@ietf.org, TCPC.Mail@sce.carleton.ca MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA29092 Cc: Subject: [nemo] (correction) CFP: The First IEEE International Workshop on Security and Pervasive Multimedia Environment X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yangxiao@ieee.org List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org (We apologize for your receiving multiple copies) (In last CFP, we forget including the place and time of the conference. Here is an corrected one) CFP: The First IEEE International Workshop on Security and Pervasive Multimedia Environment=20 http://coitweb.uncc.edu/~zhliu/MultiSec05/ to be held in conjunction with=20 IEEE International Symposium on Multimedia (ISM2005) December 12-14, 2005, Irvine, California, USA http://ism2005.eecs.uci.edu/ Call for Papers Pervasive multimedia environments provide users to access multimedia services anytime and anywhere. The resources limitations of pervasive devices and huge data amount make security a challenge. On the other hand, pervasive multimedia services enhance the mission of security and protection. For example, the collection of video surveillance data and/or sensor video data is useful for monitoring.=20 This workshop provides an international forum for academic, industry and government professionals to discuss recent progress in the above emerging research areas. Topics of interest include, but are not limited to: Privacy and anonymity=20 Trust management=20 Video surveillance=20 Quality of protection and QoS=20 Secure multimedia information sharing=20 Access control=20 Cryptographic algorithms=20 Information hiding and multimedia watermarking=20 Key management and authentication=20 Network security issues and protocols=20 Case studies=20 Risk and vulnerability assessment=20 Commercial and industrial experiences=20 Testbed and evaluation=20 Biometrics=20 Forensics=20 Submissions The written and spoken language of MultiSec2005 is English. All submissions will be electronic, and and the web site is here. Full papers must not exceed 12 pages printed using at least 11-point type and double spacing. All papers should be in Adobe portable document format (PDF) or PostScript format. The paper should have a cover page, which includes a 200-word abstract, a list of keywords, and author's phone number and e- mail address. The accepted papers will be published along with Conference Proceedings by the IEEE Computer Society Press. A printable version of the call for paper can be downloaded here: =20 Important Dates =B7 August 30, 2005 Submission of papers due =B7 September 14, 2005 Notification of acceptance of papers =B7 October 2, 2005 Camera-Ready copy of accepted papers due=20 Organization Steering Chair: =20 Laurence T. Yang, St. Francis Xavier University, Canada General Chairs: Shu-Ching Chen, Florida International University, USA Yang Xiao, University of Memphis, USA Program Chairs: Alex Zhaoyu Liu, University of North Carolina at Charlotte, USA Kouichi Sakurai, Kyushu University, Japan Program Committee Members:=20 Jiannong Cao, Hong Kong Polytechnic Univ., Hong Kong Chih-Yung Chang, Tamkang University, Taiwan Weide (Willie) Chang, Sacramento State University, USA Han-Chieh Chao, National Dong Hwa University, Taiwan Ing-Ray Chen, Virginia Polytechnic Institute and State University, USA Shigang Chen, University of Florida, USA Tanmoy Kanti Das, I2R, Singapore Mieso Denko, University of Guelph, Canada Jing Deng, University of New Orleans, USA Christos Douligeris, University of Piraeus, Greece=20 Tomoya Enokido, Rissho University, Japan Zongming Fei, University of Kentucky, USA Dieter Gollmann, TU Hamburg-Harburg, Germany Ekram Hossain, University of Manitoba, Canada Dong Hoon Lee, Korea Univ., Korea Hong-Va Leong, HongKong Polytechnic Univ., HK Raymond Li, Cisco Systems Inc., USA Xiang-Yang Li, Illinois Institute of Technology, USA=20 Jonathan Chien-Liang Liu, University of Florida, USA Javier Lopez, University of Malaga, Spain Weijia Jia, City University of Hong Kong, Hong Kong Geyong Min, University of Bradford, UK Jelena Misic, University of Manitoba, Canada Vojislav B Misic, University of Manitoba, Canada Chris Mitchell, University of London, UK Yi Mu, University of Wollongong, Australia David Naccache, Gempuls, France Qiang Ni, Hamilton Institute,National University of Ireland, Ireland Thomas Noel, University Louis Pasteur, France and Keio Univ., Japan R. Phan, Swinburne University of Technology, Malaysia Yi Qian, University of Puerto Rico at Mayag=FCez, USA Masakazu Soshi, JAIST, Japan Bo Sun, Lamar University, USA Tsuyoshi Takagi, FUN, Japan Ilenia Tinnirello, University of Palermo, Italy=20 Dimitrios D. Vergados, University of the Aegean, Greece Li-Chun Wang, National Chiao-Tung University, Taiwan Xudong Wang, Kiyon Inc., USA Duncan S. Wong, City University of Hong Kong, Hong Kong Hongyi Wu, University of Louisiana at Lafayette, USA Kui Wu, University of Victoria, Canada Bin Xiao, Hong Kong Polytechnic Univ., Hong Kong Lu Yan, Turku Centre for Computer Science, Finland Hao Zhu, Florida International University, USA From nemo-bounces@ietf.org Tue Aug 23 09:51:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ZBo-0002Pm-4U; Tue, 23 Aug 2005 09:51:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ZBm-0002N5-1q for nemo@megatron.ietf.org; Tue, 23 Aug 2005 09:51:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05008 for ; Tue, 23 Aug 2005 09:51:39 -0400 (EDT) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7ZBr-0005FT-0Q for nemo@ietf.org; Tue, 23 Aug 2005 09:51:49 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 0FA3385F4D; Tue, 23 Aug 2005 15:51:25 +0200 (CEST) Received: from [163.117.203.145] (unknown [163.117.203.145]) by smtp01.uc3m.es (Postfix) with ESMTP id E3BCC85F4B; Tue, 23 Aug 2005 15:51:21 +0200 (CEST) In-Reply-To: <200508230208.j7N28m916405@soml22.jp.panasonic.com> References: <001b01c5a6e5$739edd80$41476c6b@sisodomain.com> <200508230208.j7N28m916405@soml22.jp.panasonic.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=HZ-GB-2312; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: marcelo bagnulo braun Subject: Re: [nemo] Split Networks:Query Date: Tue, 23 Aug 2005 15:52:22 +0200 To: Masayuki Kumazawa X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org El 23/08/2005, a las 4:08, Masayuki Kumazawa escribi~{(.~}: > Hi Marcelo and all, > > Please see the inlined comments. > > From marcelo bagnulo > braun-san >> Hi Wable, >> >> El 22/08/2005, a las 8:48, Ranjitsinh Wable escribi~{!$~} >> >>> Hi Marcelo, >>> >>> Please see the inlined comments. >>>> >>>> El 18/08/2005, a las 14:31, Sameer Kumar escribi~{!$~} >>>>>> MR1 >>>>>> | _ | >>>>>> |-|_|-| _____ >>>>>> | p<- |-| | _ | _ >>>>>> _ | | | |-|_|--|-|_|HA >>>>>> MNN|_|-| | | | AR | >>>>>> | _ |-|_____| >>>>>> |-|_|-| INTERNET >>>>>> |p<- | >>>>>> MR2 >>>>>> Figure 1: (n,1,1): Multiple MRs, 1 HA, 1 MNP >>>>> >> >> keeping the figure for reference... >> >> First of all, i am really failing to understand what is so >> wireless-specific in any of those scenarios... i mean nemo is >> basically >> an IP layer protocol right? so why is it relevant that this is a >> wireless case? i mean, i think that exactly the same cases could be >> considered in a wired scenario... am i missing something? (i agree >> that >> splitting networks in a wired scenario is much less likely than in a >> wwireless scenario, but this would not change the solution behaviour >> imho) >> >> Second, i am not sure i understand the actual cases we are >> discussing... i mean the draft tries to provide a description of the >> problem of split networks, and does not provides an actual solution to >> the problem. It is accepted that in some scenarios, where the nemo >> splits, there are problems yet unsolved. > > I assume that you mean the draft is draft-kumazawa-nemo-tbdnd-02.txt > here. > Well actually i was considering draft-ietf-nemo-multihoming-issues-03 sorry for the confusion, regards, marcelo > If so, it does not provide an actual solution as you mentioned. > > It provides only the way HA confirms whether split occurs or not. > And it does not provide any solution solving problems which > will happen after split occurs. > > This is because I guessed there were several different policies about > addressing the problem. > > To keep communications in both of mobile networks after split occurs, > renumbering of MRs may be needed. > Otherwise HA have only to reject a Binding Update to prohibit MRs' > splitting. > > However, I agree with you on the point that actual cases and problems > need to be clarified more before discussing solutions. > > Best regards, > Masayuki > >> As i see it we are in the point of understanding that there is a >> problem and we could consider solutions (i guess there are a few >> drafts >> proposing solutions) >> >> So, in brief at this point the situation w.r.t. problem is that: >> - splitting a nemo may result in communication disruption of some of >> the MNN with current nemo support >> - additional tools/considerations/constraints are needed to support >> this scenario >> >> Do we agree so far? >> >> I mean, if you are arguing that splitting a nemo may cause problems, i >> agree >> >> But before moving on to discussing solutions i would like to make sure >> that we have a common understanding about what the problem is (i.e. if >> you agree with the problem description included in the draft). In >> particular, i would like to understand if you consider that there are >> some wireless specific considerations in this problem (i guess so >> because of your mail) and which are those. > ----------- > M.Kumazawa > From nemo-bounces@ietf.org Tue Aug 23 13:15:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7cMl-0006o7-N7; Tue, 23 Aug 2005 13:15:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7cMi-0006o0-VB for nemo@megatron.ietf.org; Tue, 23 Aug 2005 13:15:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16339 for ; Tue, 23 Aug 2005 13:15:09 -0400 (EDT) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7cMp-00032u-Fn for nemo@ietf.org; Tue, 23 Aug 2005 13:15:22 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 0C0CB85EC2; Tue, 23 Aug 2005 19:15:00 +0200 (CEST) Received: from [163.117.203.145] (unknown [163.117.203.145]) by smtp01.uc3m.es (Postfix) with ESMTP id 91BBF85EAE; Tue, 23 Aug 2005 19:14:54 +0200 (CEST) In-Reply-To: <000601c5a7a9$2f457580$41476c6b@sisodomain.com> References: <001b01c5a6e5$739edd80$41476c6b@sisodomain.com> <000601c5a7a9$2f457580$41476c6b@sisodomain.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <234c199d4c88c3021988c2035853cb39@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] Split Networks:Query Date: Tue, 23 Aug 2005 19:15:53 +0200 To: Ranjitsinh Wable X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: c119f9923e40f08a1d7f390ce651ea92 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org El 23/08/2005, a las 7:49, Ranjitsinh Wable escribi=F3: > keeping the figure for reference... > > First of all, i am really failing to understand what is so > wireless-specific in any of those scenarios... i mean nemo is = basically > an IP layer protocol right? so why is it relevant that this is a > wireless case? i mean, i think that exactly the same cases could be > considered in a wired scenario... am i missing something? (i agree = that > splitting networks in a wired scenario is much less likely than in a > wwireless scenario, but this would not change the solution behaviour > imho) > > =3D=3D=3D=3D> > This question about wireless scenarion arised bcoz we want to know > in wireless scenario how the sharing of the prefix works?(Problem=20 > before split). I am far from being a wireless expert, but it is my understanding that=20= you can have multiple routers in the same WLAN. The next question then=20= is whether those routers also behave as AP or as stations. At this point, we would need to explore how would the different=20 combinations of roles MR/AP/stations would work. One case would be that all MRs are APs. In this case each station in=20 the WLAN would connect to one of the MR/AP =46rom what i understand this configuration would work, since the APs=20= would forward packets addresses to stations connected to other AP to=20 that AP The other case would be that some MR are just stations. In that case,=20 the network before split would work, but if the MR/station leaves, it=20 wouldn't be able to take any other node with it, since there wouldn't=20 be an AP in the part of the network So, as i see it, there may be some considerations that need to be=20 explored given a particular wireless technology, but my feeling is that=20= the described scenario would be possible in some technologies, in=20 particular in WLAN > May be its more related to Laye2 which L3 solution will not bother > but still we would like to know the practical implementation=20 > feasibility, > in current avialable wireless systems. > > Second, i am not sure i understand the actual cases we are > discussing... i mean the draft tries to provide a description of the > problem of split networks, and does not provides an actual solution to > the problem. It is accepted that in some scenarios, where the nemo > splits, there are problems yet unsolved. > > As i see it we are in the point of understanding that there is a > problem and we could consider solutions (i guess there are a few = drafts > proposing solutions) > > So, in brief at this point the situation w.r.t. problem is that: > - splitting a nemo may result in communication disruption of some of > the MNN with current nemo support > - additional tools/considerations/constraints are needed to support > this scenario > > =3D=3D=3D=3D> > This is not regarding the solution on split network but its regarding=20= > the > basic understading of existing cases. Sorry if we asking very basic=20 > questions. > But we are not clear about it. we are still not clear about it? what is missing? > > Do we agree so far? > =3D=3D=3D> > Yes I agree on your point. > > I mean, if you are arguing that splitting a nemo may cause problems, i > agree > > But before moving on to discussing solutions i would like to make sure > that we have a common understanding about what the problem is (i.e. if > you agree with the problem description included in the draft). In > particular, i would like to understand if you consider that there are > some wireless specific considerations in this problem (i guess so > because of your mail) and which are those. > >> I will try to put this problem in slightly different scenario: >> >> As per NEMO concept we can have two wireless networks >> >> 1) Between the AR and the MR's >> 2) Between MR and MNN. >> > > right > >> Now suppose the MNN's are going to use the same prefix then >> there is no problem for the first network. As both the MRs are >> on same link of AR. Its normal AR-MR communication. >> >> Lets think about the second wireless scenario i.e. Between >> MR-MNN. Lets says there are two MR's on Link of AR >> MR1, MR2. >> > > i don't understand what you mean here > > in this second scenario, the link between MR1, MR2 and MNNs is > wireless... not sure how does the AR fits in here. As i see it, the > (wireless) link between MR1, MR2 and MNNs is a different wireless link > that the one between the MRs and the ARs > > =3D=3D=3D=3D>> > I agree the link between AR and MR is different than the Link between > MNN and MRs (same I stated above point 1) and 2)). > > Basic question here is that how MR1, MR2 and MNN share one link. I am not sure what is the problem with this... i think it is possible=20 to have wireless lan networks with many many hosts and multiple routers=20= and multiple ARs, isn't it? > (May be L2 related question but its basic requirement to share the=20 > perfixes) > > Does MNN communicates with both MR1 and MR2? > May be different answers for Bluetooth and WLAN. > agree, but for instance with WLAN, i think this would be possible,=20 right? > We tried to put the WLAN scenario with AP but as Chan-Wah said > and we also understand it is not possible. not sure what you mean by not possible here regards, marcelo > As suggested by Chan-Wah > WLAN adhoc mode can help in this regard. But we are not sure how > the link concept will be provided by the adhoc WLAN. We may look > into that option. > > About bluetooth option provides mechanism to comminicate with more > than one router at a time (MR1, MR2 in above example) but again it > does not ptovide link concept as wired scenario. > >> Now one MNN can connect to either of the MR. > > Are you considering that the network is split? > If yes, then as i mentioned before we do may have problems. > If no, the MNNs are connected to the wireless link where both MR1 and > MR2 are, what is the problem with this? > > The options below are when the nemo is split of before splitting? > > Again the same, if no split then no problem > If split we do may have issues that need additional tools. > > =3D=3D=3D=3D> > We agree there are some issues in the split network which need to be=20= > addressed. > But this mail was for basic clarification of the actual implementation=20= > of sharing of > prefix on network. > > Regards, > > Wable R. U. > > Regards, marcelo > > >> Say >> it connected to MR1. Lets say packet is comming for MNN >> to MR2 as per load balancing at HA of MRs. >> >> Now the question arieses is that how the packet will reach to MNN >> via MR2? >> >> There can be some possiblities like >> >> 1) MNN have two links and get connected to both MRs. >> (Sorry I know its not possible(feasible) but putting it to just give=20= >> all >> options) >> >> 2) MRs who share prefixes always send the packes on other link. >> (But its burden on the Wireless link (between AR and MRs)) >> >> 3) MRs keep update of the nodes under it and if >> packet is not destinied then only it forwards on other link. >> (Improved case 2 with intelligence at MR. ) >> >> 4) We can have Adhoc mode as explained by chan-Wah ng >> (I don't think that the NEMO talks about adhoc mode) >> >> If the Option 2 & 3 are the answer then, NEMO does not talk about=20 >> this. >> So its hard to get the scenarion for anybody. >> >> Let me know your views on this. >> >> Regards, >> >> Wable R. U. >> >>>> >>>> Thanks and Regards, >>>> Sameer Kumar. >>>> >>>> >>>> -----Original Message----- >>>> From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On=20 >>>> Behalf Of >>>> Masayuki Kumazawa >>>> Sent: Thursday, August 18, 2005 8:23 AM >>>> To: nemo@ietf.org >>>> Subject: Re: [nemo] Split Networks:Query >>>> >>>> Hello Sammer, >>>> >>>> <000001c5a320$962b0590$44476c6b@sisodomain.com> =46rom Sameer=20 >>>> Kumar-san >>>>> Hi all, >>>>> >>>>> I have a doubt regarding the concept of "Split Networks" in=20= >>>>> NEMO. >>>>> Split Networks comprise the case (n,1,1): Multiple MRs, Single HA,=20= >>>>> Single >>>>> MNP. >>>>> >>>>> Figure 1. below depicts the Split Network scenario. No "split"=20= >>>>> has >>>>> occured. MR1 and MR2 are together. >>>>> >>>>> MR1 >>>>> | _ | >>>>> |-|_|-| _____ >>>>> | p<- |-| | _ | _ >>>>> _ | | | |-|_|--|-|_|HA >>>>> MNN|_|-| | | | AR | >>>>> | _ |-|_____| >>>>> |-|_|-| INTERNET >>>>> |p<- | >>>>> MR2 >>>>> Figure 1: (n,1,1): Multiple MRs, 1 HA, 1 MNP >>>> >>>> In this case, split may occur in two ways. >>>> One case is that MR2, which is a portable device like a cellular=20 >>>> phone, >>>> moves away from the network. >>>> >>>> The other case is that both of them are installed in different=20 >>>> places but >>>> they are configured with the same MNP. >>>> >>>> In the second case without additional mechanism, prefix table must=20= >>>> be >>>> configured more carefully, maybe manually. >>>> >>>>> In this case, HA can send packets destined to MNN via MR1, or MR2=20= >>>>> (Load >>>>> Balancing). The same situation in a wireless deployment is shown=20= >>>>> in Figure >>>>> 2. Here also, we consider the case when no "split" has occurred=20 >>>>> i.e. MR1 >>>> and >>>>> MR2 are together. >>>>> >>>>> AP1 MR1 >>>>> _ _ _ | >>>>> / |_|---|_|-| _____ >>>>> _ / p<- |-| | _ | _ >>>>> MNN|_| | | |-|_|--|-|_|HA >>>>> | | | AR | >>>>> _ _ |-|_____| >>>>> |_|---|_|-| INTERNET >>>>> p<- | >>>>> AP2 MR2 >>>>> >>>>> Figure 2: (n,1,1) : Multiple MRs, 1 HA, 1 MNP in a Wireless=20 >>>>> Scenario >>>> >>>>> In Figure 2. MNN is currently attached to the Access Point (AP1)=20= >>>>> of MR1. I >>>>> have the following questions: >>>>> a)If HA tries to send packets to MNN via MR2, how will these=20 >>>>> packets reach >>>>> MNN? Basically how is "Load Balancing" >>>>> possible for a case (n,1,1) in a practical wireless deployment? >>>> >>>>> b)Is it that the AP1 and AP2 are "physically connected"? If so,=20 >>>>> then does >>>>> the term "split" means a "physical split"? >>>> >>>> In the architecture of current major wireless technologies, >>>> there is one AP in a BSS. >>>> >>>> So, as you pointed out, even if MR1 and MR2 are together, >>>> AP1 and AP2 can't be connected phisically as Access Point. >>>> >>>> However, if AP2 behaves as a STA, MR1 and MR2 can be connected=20 >>>> phisically. >>>> In this configuration, all packets are forwarded via AP1, but load=20= >>>> balancing >>>> >>>> between MR1 and MR2 seems possible. >>>> >>>> I'm not sure whether I understand your question, but I hope they=20 >>>> will be >>>> answer of your question. >>>> >>>> Best regards, >>>> Masayuki >>>> ----------- >>>> M.Kumazawa >>>> >>>> >>>> >>>> >>> >>> >>> >> > > > From nemo-bounces@ietf.org Tue Aug 23 23:43:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7mAY-00083t-AD; Tue, 23 Aug 2005 23:43:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7mAW-00082n-Gq for nemo@megatron.ietf.org; Tue, 23 Aug 2005 23:43:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27888 for ; Tue, 23 Aug 2005 23:43:14 -0400 (EDT) Received: from smtp1.mei.co.jp ([133.183.129.26] helo=smtp2.mei.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7mAl-0007mP-5Z for nemo@ietf.org; Tue, 23 Aug 2005 23:43:31 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id j7O3gjdr004678; Wed, 24 Aug 2005 12:42:45 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id j7O3gl922370; Wed, 24 Aug 2005 12:42:47 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/astros) with ESMTP id j7O3ghv12811; Wed, 24 Aug 2005 12:42:43 +0900 (JST) Received: from mozart.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Aug 2005 11:40:47 +0800 Received: by mozart.psl.com.sg (Postfix, from userid 1000) id 79D262B5C9A; Wed, 24 Aug 2005 12:00:02 +0800 (SGT) Subject: Re: [nemo] review of draft-ietf-nemo-ro-problem-statement-00.txt From: Chan-Wah Ng To: Jari Arkko In-Reply-To: <430B0C42.4050709@piuha.net> References: <430B0C42.4050709@piuha.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 24 Aug 2005 12:00:01 +0800 Message-Id: <1124856001.19649.82.camel@bach.psl.com.sg> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 X-OriginalArrivalTime: 24 Aug 2005 03:40:47.0692 (UTC) FILETIME=[9D7320C0:01C5A85D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello Jari, Thanks for your comments. See response in-line. On Tue, 2005-08-23 at 14:45 +0300, Jari Arkko wrote: > Hi all, > > I read this draft and found it generally OK. > > Some comments: > > I was convinced that route optimization is useful even > prior to reading this document, and would probably have > been convinced of it even by a shorter document. > I understand that some solutions in this space are > being considered by the WG, and I look forward > to seeing how they solve issues that come up. > > One aspect of the justification for work in this > space was not covered in the draft, however. > We do understand well the technical implications, > but it would be interesting to hear about vendors > and service providers wishing to deploy nemo > technology, and their specific expectations. There > are a number of reasons why route optimization can > be useful, but some of those reasons are very > different from each other. For instance, if we > need a solution for loop avoidance that may be > very different from issues relating to pure > optimization of RTTs and header sizes. Different > types of networks have also different requirements > regarding letting visiting nodes route traffic through > home networks. And disadvantages of extreme > nesting may or may not be a real issue, depending > on the type of networks being planned. Yes, unfortunately that is one of the common problems. Operators and service providers tends not to be very vocal in mailing lists. I would like to take this opportunity to urge them to provide their inputs regarding route optimization. Also, in response to some of the observations you made below, I would like to point out that there is going to be a separate WG draft (that should be published by early September) that analyzes the NEMO RO solution space. It might address some of your concerns. > > Before we start new work it would probably make > sense to understand what the use cases and the > demand is. (Of course, you probably have discussed > all this already -- I have not followed the list closely.) > > > NEMO Basic Support presents a number of additional issues, making the > > problem more complex, so it was decided to address Route Optimization > > separately. In that case, the expected benefits are more dramatic, > > and a Route Optimization mechanism could enable connectivity that > > would be broken otherwise. In that sense, Route Optimization is even > > more important to NEMO Basic Support than it is to Mobile IPv6. > > > > > This worries me a bit. Route optimization in Mobile IPv6 was > never designed as a mechanism that guarantees optimal > routing: correspondent nodes can refuse to honor requests > based on resource constraints, there may situations where > some traffic needs to be routed through tunnels anyway, etc. > Of course, what ever solutions we come by in this space > need to deal with these issues. I'm just making an observation > that this may imply a solution that is quite different, or > even completely distinct, from the current Mobile IPv6 > mechanisms. > > > When Mobile > > Routers have no prior knowledge of their peers (no Security > > association, AAA, PKI etc...) it can still be mutually beneficial to > > apply a form of reciprocal altruism based on anonymity and > > innocuousness. In particular, it is possible to adopt a tit for tat > > (T4T) strategy and forward traffic unless the other party proves to > > be uncooperative when it is solicited. > > > This is interesting, but might also be its own problem > area all by itself. > > > Then again, a Route Optimization mechanism that bypasses the nested > > tunnel might enable the parent traffic to reach the Internet and let > > it bind. At that point, the child Mobile Router would be able to > > reach its parent and bind in turn. Additional nested Route > > Optimization solutions might also enable the child to locate its Home > > Agent in the nested structure and bind regardless of whether the > > reach to the Internet is available at all. > > > > > It isn't clear to me that this can be done. Most route > optimization schemes appear to need some roundtrips > through the "home", so lack of internet connectivity > would probably be a problem, at least if its prolonged. > There are also schemes that do not need "home" > participation, but it remains to be seen if we could > make them compatible with Mobile IPv6-based schemes. > > Anyway, I'm looking forward to the solutions proposals... > > >5. Security Considerations > > > > This is an informational document that describes some limitations > > with NEMO Basic Support and does not introduce any additional > > security concerns. Please see RFC3963 [1] for security > > considerations pertaining to the NEMO Basic Support protocol. > > > Avoidance of home network policy controls or > the t4t mode would probably imply some new > security issues to think about. Might be worthwhile > to mention them here. > Right. Will do. > Editorial comments: > > > Agent on the Internet, the increase in delay is tremendous. > > > s/tremendous/larger/ (I prefer to use milder words, > at least for me it makes the case better than strong > argumentation.) > Fine ;). /rgds /cwng From nemo-bounces@ietf.org Fri Aug 26 16:53:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8lCh-0007xz-Fd; Fri, 26 Aug 2005 16:53:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8lCb-0007rx-SO for nemo@megatron.ietf.org; Fri, 26 Aug 2005 16:53:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22083 for ; Fri, 26 Aug 2005 16:53:27 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8lDO-00077Q-8s for nemo@ietf.org; Fri, 26 Aug 2005 16:54:19 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j7QKL0d22467; Fri, 26 Aug 2005 13:21:00 -0700 X-mProtect: <200508262021> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14192.americas.nokia.com (172.18.141.92, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdpIGoBj; Fri, 26 Aug 2005 13:20:59 PDT Message-ID: <430F8132.70909@iprg.nokia.com> Date: Fri, 26 Aug 2005 13:53:06 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: rdroms@cisco.com, pthubert@cisco.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org Subject: [nemo] comments on draft-ietf-nemo-dhcpv6-pd-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org hi, I quickly glanced through the draft. looks good. I have one concern. section 3.2 does not belong in this draft. in RFC 3963, the assumption is that the prefixes assigned to the mobile network always comes from the home link. never from the access link. I dont think there was any discussion on the mailing list on this to include it in a WG document. did I miss the discussion? > A Mobile Router may also obtain a temporary delegated prefix from its > Access Router (acting as a DHCPv6PD DR) while the MR is roaming > within the AR space. what is "roaming within the AR space"? the access router is the first hop router to which the mobile router is attached to. Vijay Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Network Mobility Working Group of the IETF. > > Title : DHCPv6 Prefix Delegation for NEMO > Author(s) : R. Droms, P. Thubert > Filename : draft-ietf-nemo-dhcpv6-pd-00.txt > Pages : 8 > Date : 2005-8-8 > > One aspect of network mobility support is the assignment of a prefix > or prefixes to a mobile router (MR) for use on the links in the > mobile network. DHCPv6 prefix delegation can be used for this > configuration task. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nemo-dhcpv6-pd-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-nemo-dhcpv6-pd-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-nemo-dhcpv6-pd-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From nemo-bounces@ietf.org Fri Aug 26 19:11:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8nMP-0006UF-9V; Fri, 26 Aug 2005 19:11:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8nMN-0006U9-Kk for nemo@megatron.ietf.org; Fri, 26 Aug 2005 19:11:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00353 for ; Fri, 26 Aug 2005 19:11:40 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8nNC-0003Ct-7W for nemo@ietf.org; Fri, 26 Aug 2005 19:12:34 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j7QMcvL03607; Fri, 26 Aug 2005 15:38:57 -0700 X-mProtect: <200508262238> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14192.americas.nokia.com (172.18.141.92, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpduzimVF; Fri, 26 Aug 2005 15:38:55 PDT Message-ID: <430FA186.3050001@iprg.nokia.com> Date: Fri, 26 Aug 2005 16:11:02 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tj@kniveton.com, pthubert@cisco.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org Subject: [nemo] comments on draft-ietf-nemo-prefix-delegation-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org I quickly glanced through this draft and have one concern. > Prefix Status (S) The Prefix Status (S) bit is set by a MR to request > the full list of all prefixes that are already assigned to it I dont like the new 'S' bit in the Binding Update and Binding Acknowledgement. bits are scarce, especially in the Binding Ack. instead why dont we introduce a bit in the Mobile Network Prefix Request option (section 6.4), which when set means the MR wants to know all the prefixes assigned to it and when not set, means the MR wishes to a get a new prefix assigned to it as a MNP? I am assuming the MR includes the Mobile Network Prefix Request option in both cases (getting the list of MNPs or a new MNP). and for the response the HA could set a bit in the prefix option (that carries the prefixes) to indicate the response contains the complete list of prefixes. section 3.3 does not seem to justify the new bit in the BU. maybe I am missing something? > It is important that the HA set that bit in its full list of prefixes > in order to differentiate between an empty list (there is no prefix > for that MR) and no list (HA is not providing a list in that BA). what is the difference between an empty list and a no list? a minor comment > The reader of that document is expected to be familiar with both the > Mobile IPv6 [8] and NEMO Basic Support [10] documents. As such, it > is well understood that neither protocol provides the means for > provisioning the Mobile Nodes and Routers with essential parameters > such as Home Address and Home Network. we do have a bootstrapping solution for MIP6 now. :) draft-ietf-mip6-bootstrapping-split-00.txt. Vijay Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Network Mobility Working Group of the IETF. > > Title : Mobile Network Prefix Delegation > Author(s) : T. Kniveton, P. Thubert > Filename : draft-ietf-nemo-prefix-delegation-00.txt > Pages : 27 > Date : 2005-8-22 > > This paper extends the Nemo Basic Support [10] for a Mobile Router to > synchronize its Mobile Network Prefixes with its Home Agents and > obtain new ones dynamically. The proposed prefix delegation > mechanism is agnostic to the way the prefixes are managed and > provisioned at the Home Agent; it might be used for bootstrapping, > resynchronization at binding creation or after a loss of states (eg > MR reboot), MNP Renumbering, and configuration checking for loop > avoidance. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nemo-prefix-delegation-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-nemo-prefix-delegation-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-nemo-prefix-delegation-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce From nemo-bounces@ietf.org Mon Aug 29 03:42:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9eID-0002iK-At; Mon, 29 Aug 2005 03:42:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9eIB-0002iC-32 for nemo@megatron.ietf.org; Mon, 29 Aug 2005 03:42:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22533 for ; Mon, 29 Aug 2005 03:42:53 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9eJR-0006Fj-9H for nemo@ietf.org; Mon, 29 Aug 2005 03:44:16 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 29 Aug 2005 09:42:11 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7T7g3VT021265; Mon, 29 Aug 2005 09:42:08 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 29 Aug 2005 09:42:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Aug 2005 09:42:07 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC01356157@xmb-ams-337.emea.cisco.com> Thread-Topic: comments on draft-ietf-nemo-prefix-delegation-00.txt Thread-Index: AcWqk4iFkUHsQVVjRvqYyawy733U+AB1aEsg From: "Pascal Thubert \(pthubert\)" To: "Vijay Devarapalli" , X-OriginalArrivalTime: 29 Aug 2005 07:42:07.0855 (UTC) FILETIME=[285D67F0:01C5AC6D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org Subject: [nemo] RE: comments on draft-ietf-nemo-prefix-delegation-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Thanks for this, Vijay :) Comments inline: >-----Original Message----- >From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] >Sent: Saturday, August 27, 2005 1:11 AM >To: tj@kniveton.com; Pascal Thubert (pthubert) >Cc: nemo@ietf.org >Subject: comments on draft-ietf-nemo-prefix-delegation-00.txt > >I quickly glanced through this draft and have one concern. > >> Prefix Status (S) The Prefix Status (S) bit is set by a MR to = request >> the full list of all prefixes that are already assigned to it > >I dont like the new 'S' bit in the Binding Update and Binding >Acknowledgement. bits are scarce, especially in the Binding >Ack. instead why dont we introduce a bit in the Mobile Network >Prefix Request option (section 6.4), which when set means the >MR wants to know all the prefixes assigned to it and when not >set, means the MR wishes to a get a new prefix assigned to it >as a MNP? I am assuming the MR includes the Mobile Network >Prefix Request option in both cases (getting the list of >MNPs or a new MNP). and for the response the HA could set a >bit in the prefix option (that carries the prefixes) to >indicate the response contains the complete list of prefixes. [] Hum... The MNPR and the full status requests have different = semantics. I believe mixing would be confusing. We had the same concerns = as you have here, but the alternate we considered to the bit was a = specific option, which seemed less overloading and confusing. There was = not much to say in the option so we went for a bit, thinking that the = list would decide.=20 >section 3.3 does not seem to justify the new bit in the BU. >maybe I am missing something? > >> It is important that the HA set that bit in its full list of = prefixes >> in order to differentiate between an empty list (there is no = prefix >> for that MR) and no list (HA is not providing a list in that BA). > >what is the difference between an empty list and a no list? > [] What is the difference between an empty glass of c=F4te du Rhone = and no glass at all? Maybe a good memory, or great hopes? I guess you're right, we need to make it a bit clearer. If the HA does not send a list, the MR does not know what the HA thinks = the MR owns (no list) If the HA sends an empty list, it means that the MR owns nothing, as far = as the HA knows (empty list). So there's a huge semantics difference and = we need to be very clear on that. >a minor comment > >> The reader of that document is expected to be familiar with both = the >> Mobile IPv6 [8] and NEMO Basic Support [10] documents. As such, = it >> is well understood that neither protocol provides the means for >> provisioning the Mobile Nodes and Routers with essential = parameters >> such as Home Address and Home Network. > >we do have a bootstrapping solution for MIP6 now. :) >draft-ietf-mip6-bootstrapping-split-00.txt. > >Vijay > > >Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Network Mobility Working Group of = the IETF. >> >> Title : Mobile Network Prefix Delegation >> Author(s) : T. Kniveton, P. Thubert >> Filename : draft-ietf-nemo-prefix-delegation-00.txt >> Pages : 27 >> Date : 2005-8-22 >> >> This paper extends the Nemo Basic Support [10] for a Mobile Router = to >> synchronize its Mobile Network Prefixes with its Home Agents and >> obtain new ones dynamically. The proposed prefix delegation >> mechanism is agnostic to the way the prefixes are managed and >> provisioned at the Home Agent; it might be used for bootstrapping, >> resynchronization at binding creation or after a loss of states = (eg >> MR reboot), MNP Renumbering, and configuration checking for loop >> avoidance. >> >> A URL for this Internet-Draft is: >> = http://www.ietf.org/internet-drafts/draft-ietf-nemo-prefix-delegation-00.= txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the body = of the message. >> You can also visit = https://www1.ietf.org/mailman/listinfo/I-D-announce >> to change your subscription settings. >> >> >> Internet-Drafts are also available by anonymous FTP. Login with the = username >> "anonymous" and a password of your e-mail address. After logging in, >> type "cd internet-drafts" and then >> "get draft-ietf-nemo-prefix-delegation-00.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-ietf-nemo-prefix-delegation-00.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> = ------------------------------------------------------------------------ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www1.ietf.org/mailman/listinfo/i-d-announce From nemo-bounces@ietf.org Mon Aug 29 03:42:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9eIE-0002io-So; Mon, 29 Aug 2005 03:42:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9eID-0002ij-Ny for nemo@megatron.ietf.org; Mon, 29 Aug 2005 03:42:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22536 for ; Mon, 29 Aug 2005 03:42:56 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9eJT-0006Fk-8J for nemo@ietf.org; Mon, 29 Aug 2005 03:44:18 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 29 Aug 2005 09:42:13 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7T7g3VV021265; Mon, 29 Aug 2005 09:42:10 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 29 Aug 2005 09:42:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Aug 2005 09:42:08 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC01356158@xmb-ams-337.emea.cisco.com> Thread-Topic: comments on draft-ietf-nemo-dhcpv6-pd-00.txt Thread-Index: AcWqgDfbK0jy8KZYREyHCoSWVDAbTwB6heFQ From: "Pascal Thubert \(pthubert\)" To: "Vijay Devarapalli" , "Ralph Droms \(rdroms\)" X-OriginalArrivalTime: 29 Aug 2005 07:42:08.0949 (UTC) FILETIME=[29045650:01C5AC6D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org Subject: [nemo] RE: comments on draft-ietf-nemo-dhcpv6-pd-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Thanks for this, Vijay :) Comments inline: >-----Original Message----- >From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] >Sent: Friday, August 26, 2005 10:53 PM >To: Ralph Droms (rdroms); Pascal Thubert (pthubert) >Cc: nemo@ietf.org >Subject: comments on draft-ietf-nemo-dhcpv6-pd-00.txt > >hi, > >I quickly glanced through the draft. looks good. > >I have one concern. section 3.2 does not belong in this >draft. in RFC 3963, the assumption is that the prefixes >assigned to the mobile network always comes from the >home link. never from the access link. > >I dont think there was any discussion on the mailing >list on this to include it in a WG document. did I miss >the discussion? > >> A Mobile Router may also obtain a temporary delegated prefix from its >> Access Router (acting as a DHCPv6PD DR) while the MR is roaming >> within the AR space. > >what is "roaming within the AR space"? the access router >is the first hop router to which the mobile router is >attached to. > [] This is an opening to DHCPv6PD based Local Mobility Management. This is a leftover from the text we removed from the draft (the LMM part). We do not specify it any more here, but we do not prevent it either. The sentence says it's possible, which is true. But the sentence can be removed without hurting the rest of the spec. Votes? And I agree the AR term is ill chosen. The AR space is some kind of domain within which it makes sense to use the delegated prefix for LMM. >Vijay > >Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Network Mobility Working Group of the IETF. >> >> Title : DHCPv6 Prefix Delegation for NEMO >> Author(s) : R. Droms, P. Thubert >> Filename : draft-ietf-nemo-dhcpv6-pd-00.txt >> Pages : 8 >> Date : 2005-8-8 >> >> One aspect of network mobility support is the assignment of a prefix >> or prefixes to a mobile router (MR) for use on the links in the >> mobile network. DHCPv6 prefix delegation can be used for this >> configuration task. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-nemo-dhcpv6-pd-00.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >> to change your subscription settings. >> >> >> Internet-Drafts are also available by anonymous FTP. Login with the username >> "anonymous" and a password of your e-mail address. After logging in, >> type "cd internet-drafts" and then >> "get draft-ietf-nemo-dhcpv6-pd-00.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-ietf-nemo-dhcpv6-pd-00.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. From nemo-bounces@ietf.org Mon Aug 29 11:01:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9l8O-0003c4-2Q; Mon, 29 Aug 2005 11:01:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9l8M-0003bu-6z for nemo@megatron.ietf.org; Mon, 29 Aug 2005 11:01:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15232 for ; Mon, 29 Aug 2005 11:01:12 -0400 (EDT) Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9l9g-0002Ye-JR for nemo@ietf.org; Mon, 29 Aug 2005 11:02:38 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate.mot.com (Motorola/Motgate) with ESMTP id j7TF0uLZ022820; Mon, 29 Aug 2005 08:01:00 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id j7TF6SbG025243; Mon, 29 Aug 2005 10:06:29 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 07693865980; Mon, 29 Aug 2005 17:00:52 +0200 (CEST) Message-ID: <43132324.8000004@motorola.com> Date: Mon, 29 Aug 2005 17:00:52 +0200 From: Alexandru Petrescu Organization: Motorola Labs, Paris, France User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Jari Arkko Subject: Re: [nemo] review of draft-ietf-nemo-ro-problem-statement-00.txt References: <430B0C42.4050709@piuha.net> In-Reply-To: <430B0C42.4050709@piuha.net> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Jari Arkko wrote: > > Hi all, > > I read this draft and found it generally OK. > > Some comments: > > I was convinced that route optimization is useful even prior to > reading this document, and would probably have been convinced of it > even by a shorter document. I understand that some solutions in this > space are being considered by the WG, and I look forward to seeing > how they solve issues that come up. > > One aspect of the justification for work in this space was not > covered in the draft, however. We do understand well the technical > implications, but it would be interesting to hear about vendors and > service providers wishing to deploy nemo technology, and their > specific expectations. I agree completely that it would be interesting to hear about vendors and service providers wishing to deploy nemo tech and their expectations, before looking at developping RO solutions for nemo. That will probably be precluded by a need for more implementation and test work, of Basic non-RO support, by independent actors. This is why it is significant to have implementation&deployment aspects of Basic Support in the Charter about to be re-written. > There are a number of reasons why route optimization can be useful, > but some of those reasons are very different from each other. For > instance, if we need a solution for loop avoidance that may be very > different from issues relating to pure optimization of RTTs and > header sizes. Different types of networks have also different > requirements regarding letting visiting nodes route traffic through > home networks. And disadvantages of extreme nesting may or may not be > a real issue, depending on the type of networks being planned. I agree. > Before we start new work it would probably make sense to understand > what the use cases and the demand is. I agree. I feel a little bit that need for deploying NEMO RO may arrive much later than the desire to specify it, which may lead to over-specifying something that nobody needs. Just a gut feeling. > [...] >> Then again, a Route Optimization mechanism that bypasses the nested >> tunnel might enable the parent traffic to reach the Internet and >> let it bind. At that point, the child Mobile Router would be able >> to reach its parent and bind in turn. Additional nested Route >> Optimization solutions might also enable the child to locate its >> Home Agent in the nested structure and bind regardless of whether >> the reach to the Internet is available at all. >> >> > It isn't clear to me that this can be done. Most route optimization > schemes appear to need some roundtrips through the "home", so lack of > internet connectivity would probably be a problem, at least if its > prolonged. There are also schemes that do not need "home" > participation, but it remains to be seen if we could make them > compatible with Mobile IPv6-based schemes. I agree that common RO schemes need to go through home and anything different may distance itself too much from what the MIP6 RO scheme is. I just wanted to mention that it is important to see the need-for-RO topics listed by the draft (sub-sections 2.x) as separated in two: those that relate to performance and those that related to work-or-dont-work. For example, topics 2.1-2.4 are obviously performance related while 2.6 and 2.7 can be seen as issues with the NEMO Base Support protocol itself. These latter suggest that in certain mobility scenarios the protocol can't work. And that if an RO mechanism existed then moving networks as described could work. Which brings me back to the vendor/deployment needs. I could say that if vendor/deployment needs are only about one moving network (and not about nestedness) then the protocol will work fine without RO, albeit with applications noticing performance decrease because of long paths. But it would work. Alex From nemo-bounces@ietf.org Mon Aug 29 11:25:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9lVf-00088K-ED; Mon, 29 Aug 2005 11:25:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9lVe-00088F-6S for nemo@megatron.ietf.org; Mon, 29 Aug 2005 11:25:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16440 for ; Mon, 29 Aug 2005 11:25:16 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9lWy-0003KW-SJ for nemo@ietf.org; Mon, 29 Aug 2005 11:26:43 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j7TFZbek026591 for ; Mon, 29 Aug 2005 08:35:37 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (8.13.1/8.13.0) with ESMTP id j7TFWv4v003374 for ; Mon, 29 Aug 2005 10:32:57 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 6EDB9865980 for ; Mon, 29 Aug 2005 17:25:12 +0200 (CEST) Message-ID: <431328D8.9080002@motorola.com> Date: Mon, 29 Aug 2005 17:25:12 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: IETF NEMO WG X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Subject: [nemo] More comments on the RO problem statement draft X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org I've just went through the draft, thanks for putting it up in a concise form. First, I'll repeat along the lines of the recent Jari posting about vendors/deployment necessity. Having an RO problem statement is good, at least to acknowledge the protocol issues with moving networks. To that end I see necessity of the Problem Statement draft. However, developping an RO scheme for NEMO should be subject to deployment needs and user experience first. Section 2.5 "Security Policy Prohibiting Traffic From Visiting Nodes" poses problems for my understanding. The title is expressive, however the description is difficult to grasp, IMHO. > it can be expected that in many deployments, policies will be put in > place to prevent untrusted visitors from attaching to the Mobile > Router. [...] A Route Optimization mechanism that would prevent the > multiple re- encapsulation of the packets by nested Mobile Routers > might as a side effect alleviate this limitation In my understanding "policy" is like packet filters on MR, that would simply block anybody else than the known LFNs to connect to that moving network. No RO mechanism could do anything against those policies. If they're in place then nothing could be done about them. Maybe the moving networks problem was this: any moving network can attach to another moving network and there may be DoS attacks when entities administrated by different separate administrative domains take networking ressources from each other without a formal agreement. In that case a formal agreement may solve the problem, but not an RO solution which is mainly designed to shorten paths. No? Section 2.7 "Deadlock with a Home Agent Nested in a Mobile Network" has a textual illustration (ASCII art) of a mobility configuration experimented in lab and where MRs can't update their HAs because the tunnels would "cross-over" each other if they were set, instead of "encapsulating" each other (see section B.6 in an expired draft at http://tinyurl.com/4z4kc). Section 5 "Security Considerations" - ok this document does not introduce any security issues, but what about the potential extensions of the (security) RR mechanisms that can't be logically extended to return routability tests for entire prefixes (the MNP instead of HoA)? This was one of the important issues of not looking at RO mechanisms for NEMO, because it was said that extending RR to support prefixes is very unclear. Alex From nemo-bounces@ietf.org Tue Aug 30 14:42:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAB4T-00018Z-1H; Tue, 30 Aug 2005 14:42:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAB4R-00016F-N3 for nemo@megatron.ietf.org; Tue, 30 Aug 2005 14:42:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29912 for ; Tue, 30 Aug 2005 14:42:53 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAB62-0001Rq-FP for nemo@ietf.org; Tue, 30 Aug 2005 14:44:34 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j7UIAEo06355; Tue, 30 Aug 2005 11:10:14 -0700 X-mProtect: <200508301810> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdsbkAu2; Tue, 30 Aug 2005 11:10:12 PDT Message-ID: <4314A895.9020208@iprg.nokia.com> Date: Tue, 30 Aug 2005 11:42:29 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.6-1.4.1 (X11/20050719) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC01356157@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC01356157@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 8bit Cc: nemo@ietf.org, tj@kniveton.com Subject: [nemo] Re: comments on draft-ietf-nemo-prefix-delegation-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Pascal Thubert (pthubert) wrote: > Thanks for this, Vijay :) > > Comments inline: > > >>-----Original Message----- >>From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] >>Sent: Saturday, August 27, 2005 1:11 AM >>To: tj@kniveton.com; Pascal Thubert (pthubert) >>Cc: nemo@ietf.org >>Subject: comments on draft-ietf-nemo-prefix-delegation-00.txt >> >>I quickly glanced through this draft and have one concern. >> >> >>> Prefix Status (S) The Prefix Status (S) bit is set by a MR to request >>> the full list of all prefixes that are already assigned to it >> >>I dont like the new 'S' bit in the Binding Update and Binding >>Acknowledgement. bits are scarce, especially in the Binding >>Ack. instead why dont we introduce a bit in the Mobile Network >>Prefix Request option (section 6.4), which when set means the >>MR wants to know all the prefixes assigned to it and when not >>set, means the MR wishes to a get a new prefix assigned to it >>as a MNP? I am assuming the MR includes the Mobile Network >>Prefix Request option in both cases (getting the list of >>MNPs or a new MNP). and for the response the HA could set a >>bit in the prefix option (that carries the prefixes) to >>indicate the response contains the complete list of prefixes. > > > [] Hum... The MNPR and the full status requests have different semantics. I believe mixing would be confusing. We had the same concerns as you have here, but the alternate we considered to the bit was a specific option, which seemed less overloading and confusing. There was not much to say in the option so we went for a bit, thinking that the list would decide. I would prefer a new option instead of the bit, if the mobile network prefix request option can't be used. another question, why does the MR care if the list contains the complete set of MNPs or not? can't we have something like, if the MR requests for information about the current set of prefixes assigned to it, the HA responds with the complete set of prefixes assigned to the MR. when would returning a partial list be useful? if you think a partial list is useful, how does the HA decide which set of MNPs to return? if the MR wants a new MNP assigned to it, it includes the Mobile Network Prefix Request option in the Binding Update and gets a new prefix assigned. >>> It is important that the HA set that bit in its full list of prefixes >>> in order to differentiate between an empty list (there is no prefix >>> for that MR) and no list (HA is not providing a list in that BA). >> >>what is the difference between an empty list and a no list? >> > > [] What is the difference between an empty glass of ctte du Rhone and no glass at all? Maybe a good memory, or great hopes? > > I guess you're right, we need to make it a bit clearer. > > If the HA does not send a list, the MR does not know what the HA thinks the MR owns (no list) > If the HA sends an empty list, it means that the MR owns nothing, as far as the HA knows (empty list). So there's a huge semantics difference and we need to be very clear on that. isn't the MR response same in both cases? if the MR does not get a list or gets an empty list, it has to request for a new MNP to be assigned. so why bother? Vijay From nemo-bounces@ietf.org Tue Aug 30 14:46:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAB7a-0002iv-2G; Tue, 30 Aug 2005 14:46:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAB7X-0002in-Qe for nemo@megatron.ietf.org; Tue, 30 Aug 2005 14:46:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00007 for ; Tue, 30 Aug 2005 14:46:06 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAB98-0001W9-MU for nemo@ietf.org; Tue, 30 Aug 2005 14:47:47 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j7UIDPm09003; Tue, 30 Aug 2005 11:13:25 -0700 X-mProtect: <200508301813> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdz8QPzc; Tue, 30 Aug 2005 11:13:24 PDT Message-ID: <4314A955.5050906@iprg.nokia.com> Date: Tue, 30 Aug 2005 11:45:41 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.6-1.4.1 (X11/20050719) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC01356158@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC01356158@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, "Ralph Droms \(rdroms\)" Subject: [nemo] Re: comments on draft-ietf-nemo-dhcpv6-pd-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Pascal Thubert (pthubert) wrote: >> >>I quickly glanced through the draft. looks good. >> >>I have one concern. section 3.2 does not belong in this >>draft. in RFC 3963, the assumption is that the prefixes >>assigned to the mobile network always comes from the >>home link. never from the access link. >> >>I dont think there was any discussion on the mailing >>list on this to include it in a WG document. did I miss >>the discussion? >> >> >>> A Mobile Router may also obtain a temporary delegated prefix from > > its > >>> Access Router (acting as a DHCPv6PD DR) while the MR is roaming >>> within the AR space. >> >>what is "roaming within the AR space"? the access router >>is the first hop router to which the mobile router is >>attached to. >> > > [] This is an opening to DHCPv6PD based Local Mobility Management. > This is a leftover from the text we removed from the draft (the LMM > part). We do not specify it any more here, but we do not prevent it > either. The sentence says it's possible, which is true. But the sentence > can be removed without hurting the rest of the spec. Votes? > > And I agree the AR term is ill chosen. The AR space is some kind of > domain within which it makes sense to use the delegated prefix for LMM. this is bad. there was never any consensus to include something like this in DHCPv6 based prefix delegation. I dont think NEMO is supposed to work on Local Mobility Management. IMO, section 3.2 needs to be removed. I think the document would advance quickly without this section. Vijay From nemo-bounces@ietf.org Tue Aug 30 23:52:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAJeR-0004a9-Qv; Tue, 30 Aug 2005 23:52:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAJeP-0004Yk-Qf for nemo@megatron.ietf.org; Tue, 30 Aug 2005 23:52:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28541 for ; Tue, 30 Aug 2005 23:52:34 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAJg4-0007Xr-Ie for nemo@ietf.org; Tue, 30 Aug 2005 23:54:21 -0400 Received: from [10.0.1.196] (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id C65794C514 for ; Wed, 31 Aug 2005 12:52:03 +0900 (JST) Message-ID: <43152992.1010309@sfc.wide.ad.jp> Date: Wed, 31 Aug 2005 12:52:50 +0900 From: Romain KUNTZ Organization: Keio University User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo Subject: Re: [nemo] Questions about draft-kniveton-nemo-prefix-delegation-01 References: <42E4C5C5.3000501@sfc.wide.ad.jp> <9d173ec44e3a58dc22c1563a6803b155@kniveton.com> <42E6D592.90600@sfc.wide.ad.jp> <39AD4325-268A-4EC0-98F7-0AFB4879AB79@kniveton.com> In-Reply-To: <39AD4325-268A-4EC0-98F7-0AFB4879AB79@kniveton.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi TJ, Sorry, I just found this unreplied mail in my mailbox. T.J. Kniveton wrote: >>>> - Also, I don't understand well the utility of the I flag in the >>>> Mobile >>>> Network Prefix Option: >>>> Implicit (I): The (I) bit is set if the prefix is assigned to >>>> and >>>> routed via the MR even if the prefix is not listed in explicit >>>> mode BU. >>>> >>>> No MNP options are used when the MR uses Implicit mode. So this bit is >>>> never used. Or does the HA has to use the MNP option and set this bit >>>> when listing all the prefixes owned by the MR ? >>>> >>> That's correct. The idea is to be able to explicitly list *all* >>> prefixes assigned, including ones that are bound using implicit BUs. >>> >> >> Ok, but if the HA uses MNPO to list all the prefixes, see my comment >> above. > > > How does it relate to implicit prefixes? No relation, actually My concern is just that listing all prefixes with MNPOs may be redundant sometimes with the MNPCO options (I mean, the same prefix may appear twice in a MNPCO and in a MNPO). Maybe we should use MNCO option when sending a BAck with the S bit, and add a bit in the MNPCO saying, if set, that this MNPCO option is just for listing, not for delegation (and if not set, the prefix is for listing AND delegation). Just an idea, I am not sure it is efficient. Romain From nemo-bounces@ietf.org Wed Aug 31 00:35:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAKKD-0007mC-CZ; Wed, 31 Aug 2005 00:35:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAKKA-0007jM-SH for nemo@megatron.ietf.org; Wed, 31 Aug 2005 00:35:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01020 for ; Wed, 31 Aug 2005 00:35:43 -0400 (EDT) Received: from mandala.kddilabs.jp ([192.26.91.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAKLq-0000Hg-Ks for nemo@ietf.org; Wed, 31 Aug 2005 00:37:31 -0400 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 95902EC8E5; Wed, 31 Aug 2005 13:35:16 +0900 (JST) Received: from neutrino.hsc.kddilabs.jp (unknown [2001:200:601:200:20e:cff:fe08:e137]) by mandala.kddilabs.jp (Postfix) with ESMTP id 00044EC8E2; Wed, 31 Aug 2005 13:35:15 +0900 (JST) Received: from [IPv6?2001?200?601?200?9140?1a56?f46f?38d0] (unknown [IPv6:2001:200:601:200:9140:1a56:f46f:38d0]) by neutrino.hsc.kddilabs.jp (Postfix) with ESMTP id DF08B340078; Wed, 31 Aug 2005 13:35:15 +0900 (JST) Message-ID: <43153404.8090204@kddilabs.jp> Date: Wed, 31 Aug 2005 13:37:24 +0900 From: Masafumi Watari Organization: KDDI R&D Laboratories Inc. User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [nemo] More comments on the RO problem statement draft References: <431328D8.9080002@motorola.com> In-Reply-To: <431328D8.9080002@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi, On 2005/08/30 0:25, Alexandru Petrescu wrote: > I've just went through the draft, thanks for putting it up in a concise > form. > > First, I'll repeat along the lines of the recent Jari posting about > vendors/deployment necessity. Having an RO problem statement is good, > at least to acknowledge the protocol issues with moving networks. To > that end I see necessity of the Problem Statement draft. However, > developping an RO scheme for NEMO should be subject to deployment needs > and user experience first. > > Section 2.5 "Security Policy Prohibiting Traffic From Visiting Nodes" > poses problems for my understanding. The title is expressive, however > the description is difficult to grasp, IMHO. > >>it can be expected that in many deployments, policies will be put in >>place to prevent untrusted visitors from attaching to the Mobile >>Router. [...] A Route Optimization mechanism that would prevent the >>multiple re- encapsulation of the packets by nested Mobile Routers >>might as a side effect alleviate this limitation > > In my understanding "policy" is like packet filters on MR, that would > simply block anybody else than the known LFNs to connect to that moving > network. No RO mechanism could do anything against those policies. If > they're in place then nothing could be done about them. > > Maybe the moving networks problem was this: any moving network can > attach to another moving network and there may be DoS attacks when > entities administrated by different separate administrative domains take > networking ressources from each other without a formal agreement. In > that case a formal agreement may solve the problem, but not an RO > solution which is mainly designed to shorten paths. No? RO solution is designed to shorten paths, which means that it's providing an alternative paths for the MNNs. Since the alternative path is different from the default MRHA tunnel, the MRs may decide to forward packets for the vistor through the alternative path since the path will not threaten its home network. We didn't define what the "policy" might be, but if the policy prohibits a vistor to connect to its mobile network, as you mentioned, then I a RO solution is not designed to solve that problem. > Section 2.7 "Deadlock with a Home Agent Nested in a Mobile Network" has > a textual illustration (ASCII art) of a mobility configuration > experimented in lab and where MRs can't update their HAs because the > tunnels would "cross-over" each other if they were set, instead of > "encapsulating" each other (see section B.6 in an expired draft at > http://tinyurl.com/4z4kc). > > Section 5 "Security Considerations" - ok this document does not > introduce any security issues, but what about the potential extensions > of the (security) RR mechanisms that can't be logically extended to > return routability tests for entire prefixes (the MNP instead of HoA)? > This was one of the important issues of not looking at RO mechanisms for > NEMO, because it was said that extending RR to support prefixes is very > unclear. The document is not intend to discuss any potential solutions, but perhaps in the Solution Space Analysis draft which is to be published soon. watari From nemo-bounces@ietf.org Wed Aug 31 06:03:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAPRP-0001Kl-Ry; Wed, 31 Aug 2005 06:03:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAPRO-0001JW-4w for nemo@megatron.ietf.org; Wed, 31 Aug 2005 06:03:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11239 for ; Wed, 31 Aug 2005 06:03:31 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAPT7-0000HE-0e for nemo@ietf.org; Wed, 31 Aug 2005 06:05:21 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 31 Aug 2005 12:03:24 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7VA2ZW1012955; Wed, 31 Aug 2005 12:03:22 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 31 Aug 2005 12:03:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 31 Aug 2005 12:03:08 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC01397D25@xmb-ams-337.emea.cisco.com> Thread-Topic: comments on draft-ietf-nemo-prefix-delegation-00.txt Thread-Index: AcWtkrPuP2wxbRrGT26TNafX+RFKygAahjkg From: "Pascal Thubert \(pthubert\)" To: "Vijay Devarapalli" X-OriginalArrivalTime: 31 Aug 2005 10:03:08.0861 (UTC) FILETIME=[3057F6D0:01C5AE13] X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, tj@kniveton.com Subject: [nemo] RE: comments on draft-ietf-nemo-prefix-delegation-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org >-----Original Message----- >From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] >Sent: Tuesday, August 30, 2005 8:42 PM >To: Pascal Thubert (pthubert) >Cc: tj@kniveton.com; nemo@ietf.org >Subject: Re: comments on draft-ietf-nemo-prefix-delegation-00.txt > >Pascal Thubert (pthubert) wrote: >> Thanks for this, Vijay :) >> >> Comments inline: >> >> >>>-----Original Message----- >>>From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] >>>Sent: Saturday, August 27, 2005 1:11 AM >>>To: tj@kniveton.com; Pascal Thubert (pthubert) >>>Cc: nemo@ietf.org >>>Subject: comments on draft-ietf-nemo-prefix-delegation-00.txt >>> >>>I quickly glanced through this draft and have one concern. >>> >>> >>>> Prefix Status (S) The Prefix Status (S) bit is set by a MR to request >>>> the full list of all prefixes that are already assigned to it >>> >>>I dont like the new 'S' bit in the Binding Update and Binding >>>Acknowledgement. bits are scarce, especially in the Binding >>>Ack. instead why dont we introduce a bit in the Mobile Network >>>Prefix Request option (section 6.4), which when set means the >>>MR wants to know all the prefixes assigned to it and when not >>>set, means the MR wishes to a get a new prefix assigned to it >>>as a MNP? I am assuming the MR includes the Mobile Network >>>Prefix Request option in both cases (getting the list of >>>MNPs or a new MNP). and for the response the HA could set a >>>bit in the prefix option (that carries the prefixes) to >>>indicate the response contains the complete list of prefixes. >> >> >> [] Hum... The MNPR and the full status requests have different semantics. I believe mixing >would be confusing. We had the same concerns as you have here, but the alternate we considered to the >bit was a specific option, which seemed less overloading and confusing. There was not much to say in >the option so we went for a bit, thinking that the list would decide. > >I would prefer a new option instead of the bit, if the mobile >network prefix request option can't be used. another question, >why does the MR care if the list contains the complete set of >MNPs or not? can't we have something like, if the MR requests >for information about the current set of prefixes assigned to >it, the HA responds with the complete set of prefixes assigned >to the MR. when would returning a partial list be useful? if >you think a partial list is useful, how does the HA decide >which set of MNPs to return? > [] Well, it would be either asking for a new prefix or for the complete list of all prefixes. There's no concept of partial list in the draft.=20 >if the MR wants a new MNP assigned to it, it includes the >Mobile Network Prefix Request option in the Binding Update and >gets a new prefix assigned. > [] Yes, that's how it's proposed... >>>> It is important that the HA set that bit in its full list of prefixes >>>> in order to differentiate between an empty list (there is no prefix >>>> for that MR) and no list (HA is not providing a list in that BA). >>> >>>what is the difference between an empty list and a no list? >>> >> >> [] What is the difference between an empty glass of ctte du Rhone and no glass at all? Maybe a >good memory, or great hopes? >> >> I guess you're right, we need to make it a bit clearer. >> >> If the HA does not send a list, the MR does not know what the HA thinks the MR owns (no list) >> If the HA sends an empty list, it means that the MR owns nothing, as far as the HA knows (empty >list). So there's a huge semantics difference and we need to be very clear on that. > >isn't the MR response same in both cases? if the MR does not >get a list or gets an empty list, it has to request for a new >MNP to be assigned. so why bother? [] When the MR asks for the list (the bit is set) and the HA responds with the bit set but nothing listed, the MR knows it needs to obtain new prefixes. OTOH, if the HA does not set the bit (no list) then the MR does not know what the HA has for it, which is the current NEMO support. The MR can try both implicit or explicit modes, but does not necessarily need a new prefix delegated. You might see that as backward compatibility. Pascal From nemo-bounces@ietf.org Wed Aug 31 08:04:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EARKs-0003rz-VR; Wed, 31 Aug 2005 08:04:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EARKq-0003rK-De for nemo@megatron.ietf.org; Wed, 31 Aug 2005 08:04:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16548 for ; Wed, 31 Aug 2005 08:04:54 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EARMY-0003ic-Eq for nemo@ietf.org; Wed, 31 Aug 2005 08:06:44 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j7VCF25P004373; Wed, 31 Aug 2005 05:15:07 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id j7VCAoJg002773; Wed, 31 Aug 2005 07:10:50 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 010F8865980; Wed, 31 Aug 2005 14:04:34 +0200 (CEST) Message-ID: <43159CD1.3060609@motorola.com> Date: Wed, 31 Aug 2005 14:04:33 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Masafumi Watari Subject: Re: [nemo] More comments on the RO problem statement draft References: <431328D8.9080002@motorola.com> <43153404.8090204@kddilabs.jp> In-Reply-To: <43153404.8090204@kddilabs.jp> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , Alexandru Petrescu X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Watari, Masafumi Watari wrote: > Hi, > > On 2005/08/30 0:25, Alexandru Petrescu wrote: > >> I've just went through the draft, thanks for putting it up in a >> concise form. >> >> First, I'll repeat along the lines of the recent Jari posting about >> vendors/deployment necessity. Having an RO problem statement is >> good, at least to acknowledge the protocol issues with moving >> networks. To that end I see necessity of the Problem Statement >> draft. However, developping an RO scheme for NEMO should be >> subject to deployment needs and user experience first. >> >> Section 2.5 "Security Policy Prohibiting Traffic From Visiting >> Nodes" poses problems for my understanding. The title is >> expressive, however the description is difficult to grasp, IMHO. >> >>> it can be expected that in many deployments, policies will be put >>> in place to prevent untrusted visitors from attaching to the >>> Mobile Router. [...] A Route Optimization mechanism that would >>> prevent the multiple re- encapsulation of the packets by nested >>> Mobile Routers might as a side effect alleviate this limitation >> >> >> In my understanding "policy" is like packet filters on MR, that >> would simply block anybody else than the known LFNs to connect to >> that moving network. No RO mechanism could do anything against >> those policies. If they're in place then nothing could be done >> about them. > >> > >> Maybe the moving networks problem was this: any moving network can >> attach to another moving network and there may be DoS attacks when >> entities administrated by different separate administrative domains >> take networking ressources from each other without a formal >> agreement. In that case a formal agreement may solve the problem, >> but not an RO solution which is mainly designed to shorten paths. >> No? > > > RO solution is designed to shorten paths, which means that it's > providing an alternative paths for the MNNs. Since the alternative > path is different from the default MRHA tunnel, the MRs may decide to > forward packets for the vistor through the alternative path since the > path will not threaten its home network. > > We didn't define what the "policy" might be, but if the policy > prohibits a vistor to connect to its mobile network, as you > mentioned, then I a RO solution is not designed to solve that > problem. Thanks. I've re-read the section. It says that with typical networks, maybe T4T is used and nodes do connect to each other without worry. And it says that with NEMO if VMNs are allowed to connect to moving networks then the T4T "policy" may no longer apply because traffic goes through HA, which is another network. And which may make administrators to no longer apply T4T. But if NEMO used RO then the administrators would continue to indulge VMNs, because traffic would no longer go through HA. The reasoning sounds complicated to me, it makes assumptions on too many unknown things (T4T, policies, etc). Maybe it would be easier to say something along the lines of this: if NEMO uses RO then there is more probability that moving networks will be allowed (policy-wise) to connect to each other. Does this follow? >> Section 2.7 "Deadlock with a Home Agent Nested in a Mobile Network" >> has a textual illustration (ASCII art) of a mobility configuration >> experimented in lab and where MRs can't update their HAs because >> the tunnels would "cross-over" each other if they were set, instead >> of "encapsulating" each other (see section B.6 in an expired draft >> at http://tinyurl.com/4z4kc). >> >> Section 5 "Security Considerations" - ok this document does not >> introduce any security issues, but what about the potential >> extensions of the (security) RR mechanisms that can't be logically >> extended to return routability tests for entire prefixes (the MNP >> instead of HoA)? This was one of the important issues of not >> looking at RO mechanisms for NEMO, because it was said that >> extending RR to support prefixes is very unclear. > > > The document is not intend to discuss any potential solutions, but > perhaps in the Solution Space Analysis draft which is to be published > soon. I agree this document should not have discussion of potential solutions. I just wanted to mention that there is a "prefix ownership problem" just like there is an "address ownership problem" (which was addressed with CGA). It is little feasible to use CGA to address the "prefix ownership problem". It is little feasible to do return routability testing for all addresses comprised by a prefix. Without addressing the "prefix ownership problem" it little feasible IMHO to have RR/RO like MIP6 is. Maybe it's not correctly formulated... Maybe something should be said like this: assume RO is needed for NEMO. It is then needed to use mechanism similar to MIP6 RR. But MIP6 RR is used to ensure that a certain address is owned by a MN. It can't be extended to ensure that an entire prefix is owned by an MR. "Prefix Ownership": when MR tries to instruct a CN that its MNP is at a new CoA it should have a means to convince CN that that particular MNP is actually the MNP that the MR is administratively assigned, in order to avoid security attacks. Maybe still not correctly formulated, but you may get the idea... Alex From nemo-bounces@ietf.org Wed Aug 31 09:03:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EASFz-0004Z7-R4; Wed, 31 Aug 2005 09:03:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EASFy-0004XQ-I5 for nemo@megatron.ietf.org; Wed, 31 Aug 2005 09:03:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19295 for ; Wed, 31 Aug 2005 09:03:56 -0400 (EDT) Received: from email10.etsi.org ([212.234.161.112] helo=Xms1.etsihq.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EASHh-0005Gx-Q4 for nemo@ietf.org; Wed, 31 Aug 2005 09:05:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 31 Aug 2005 15:03:46 +0200 Message-ID: <43CEA2D153F88E47B0E3CFE0656B89CE0EC882@Xms1.etsihq.org> Thread-Topic: 6th IPv6 17-21 October 2005 Thread-Index: AcWuLGvNYai/RnfNQNe6r1hw3j4u7g== From: "Maya Ayache" To: X-Spam-Score: 1.2 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Subject: [nemo] 6th IPv6 17-21 October 2005 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear Madame, Dear Sir, We are organizing the 6th IPv6 interoperability event from 17 to 21 October 2005 http://www.etsi.org/plugtests/IPv6.htm.=20 We have notably received requests to include NEMO into the test programme. Therefore, to help us optimize the event preparation we would like to know if you would be interested by such tests.=20 Please reply to plugtests@etsi.org at the latest by Monday 12 September 2005. Thank you in advance, Best regards, Maya Ayache PLUGTESTS - Events & Marketing Coordinator From nemo-bounces@ietf.org Wed Aug 31 13:49:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAWhp-0004nw-Ad; Wed, 31 Aug 2005 13:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAWhn-0004nl-48 for nemo@megatron.ietf.org; Wed, 31 Aug 2005 13:48:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02793 for ; Wed, 31 Aug 2005 13:48:57 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAWja-0004NS-4P for nemo@ietf.org; Wed, 31 Aug 2005 13:50:50 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j7VHFcC22613; Wed, 31 Aug 2005 10:15:38 -0700 X-mProtect: <200508311715> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14192.americas.nokia.com (172.18.141.92, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdOBSHFh; Wed, 31 Aug 2005 10:15:37 PDT Message-ID: <4315ED4B.2090701@iprg.nokia.com> Date: Wed, 31 Aug 2005 10:47:55 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] RE: comments on draft-ietf-nemo-prefix-delegation-00.txt References: <7892795E1A87F04CADFCCF41FADD00FC01397D25@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC01397D25@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, tj@kniveton.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Pascal Thubert (pthubert) wrote: >>>>I quickly glanced through this draft and have one concern. >>>> >>>> >>>> >>>>> Prefix Status (S) The Prefix Status (S) bit is set by a MR to > > request > >>>>> the full list of all prefixes that are already assigned to it >>>> >>>>I dont like the new 'S' bit in the Binding Update and Binding >>>>Acknowledgement. bits are scarce, especially in the Binding >>>>Ack. instead why dont we introduce a bit in the Mobile Network >>>>Prefix Request option (section 6.4), which when set means the >>>>MR wants to know all the prefixes assigned to it and when not >>>>set, means the MR wishes to a get a new prefix assigned to it >>>>as a MNP? I am assuming the MR includes the Mobile Network >>>>Prefix Request option in both cases (getting the list of >>>>MNPs or a new MNP). and for the response the HA could set a >>>>bit in the prefix option (that carries the prefixes) to >>>>indicate the response contains the complete list of prefixes. >>> >>> >>>[] Hum... The MNPR and the full status requests have different > > semantics. I believe mixing > >>would be confusing. We had the same concerns as you have here, but the > > alternate we considered to the > >>bit was a specific option, which seemed less overloading and confusing. > > There was not much to say in > >>the option so we went for a bit, thinking that the list would decide. >> >>I would prefer a new option instead of the bit, if the mobile >>network prefix request option can't be used. another question, >>why does the MR care if the list contains the complete set of >>MNPs or not? can't we have something like, if the MR requests >>for information about the current set of prefixes assigned to >>it, the HA responds with the complete set of prefixes assigned >>to the MR. when would returning a partial list be useful? if >>you think a partial list is useful, how does the HA decide >>which set of MNPs to return? >> > > [] Well, it would be either asking for a new prefix or for the > complete list of all prefixes. There's no concept of partial list in the > draft. I am more confused now. so why do we then need a bit to indicate "complete set of prefixes", if the complete list of prefixes is always returned? the request for a new prefix is explicit through the inclusion of the Mobile Network Prefix Request option. >>isn't the MR response same in both cases? if the MR does not >>get a list or gets an empty list, it has to request for a new >>MNP to be assigned. so why bother? > > [] When the MR asks for the list (the bit is set) and the HA > responds with the bit set but nothing listed, the MR knows it needs to > obtain new prefixes. OTOH, if the HA does not set the bit (no list) then > the MR does not know what the HA has for it, which is the current NEMO > support. The MR can try both implicit or explicit modes, but does not > necessarily need a new prefix delegated. You might see that as backward > compatibility. forget the bit for now. I would really like to see the bit in the BU removed. here is one proposal. we define a new option, "MNP Information", that can be carried in a BU and BAck. - the MR wants to know what MNPs are assigned to it the MR just sends a BU with the MNP Information option, with a bit set to indicate that it is a request, to the HA. if the HA implements draft-ietf-nemo-prefix-delegation draft it responds with a list of prefixes using the MNP Information option, but with a bit set to indicate that it is a response. if there are no prefixes assigned to the MR, the HA returns an empty MNP Information option. if the HA happens to be a RFC 3963 HA that does not implement draft-ietf-nemo-prefix-delegation, it just ignores the MNP Information option and includes nothing in the Binding Ack. here I have avoided using the Mobile Network Prefix option defined in RFC 3963. Mobile Network Prefix option was designed to carry just one prefix. it can't carry mutliple prefixes. to carry multiple prefixes, RFC 3963 says, multiple MNP options have to be included in the BU. - the MR wants to get a new prefix assigned the MR includes the Mobile Network Prefix Request option (defined in draft-ietf-nemo-prefix-delegation) in the BU and gets the prefix from the HA. if the HA does not implement draft-ietf-nemo-prefix-delegation, then the option is ignored. let me know what you think about this proposal. Vijay From nemo-bounces@ietf.org Wed Aug 31 18:33:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAb8g-0001C3-TA; Wed, 31 Aug 2005 18:33:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAb8d-0001Bv-KC for nemo@megatron.ietf.org; Wed, 31 Aug 2005 18:33:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22092 for ; Wed, 31 Aug 2005 18:32:56 -0400 (EDT) Received: from vici.ucdavis.edu ([169.237.105.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAbAS-0004vJ-7s for nemo@ietf.org; Wed, 31 Aug 2005 18:34:53 -0400 Received: from localhost (localhost [127.0.0.1]) by vici.ucdavis.edu (8.13.3/8.13.1/it-std-5.2.0) with ESMTP id j7VMWqSw025193; Wed, 31 Aug 2005 15:32:52 -0700 (PDT) Date: Wed, 31 Aug 2005 15:32:52 -0700 (PDT) From: Fan Zhao X-X-Sender: fanzhao@vici.ucdavis.edu To: Alexandru Petrescu Subject: Prefix ownership Re: [nemo] More comments on the RO problem statement draft In-Reply-To: <43159CD1.3060609@motorola.com> Message-ID: References: <431328D8.9080002@motorola.com> <43153404.8090204@kddilabs.jp> <43159CD1.3060609@motorola.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear Alex, Prefix ownership is addressed in the solution space analysis draft. And I have a draft, draft-zhao-mip6-rr-ext-01, which provides an alternative way to guarantee the validity of prefix without generating many test messages. Sincerely, fan On Wed, 31 Aug 2005, Alexandru Petrescu wrote: > Hi Watari, > > Masafumi Watari wrote: > > > Hi, > > > > On 2005/08/30 0:25, Alexandru Petrescu wrote: > > > >> I've just went through the draft, thanks for putting it up in a > >> concise form. > >> > >> First, I'll repeat along the lines of the recent Jari posting about > >> vendors/deployment necessity. Having an RO problem statement is > >> good, at least to acknowledge the protocol issues with moving > >> networks. To that end I see necessity of the Problem Statement > >> draft. However, developping an RO scheme for NEMO should be > >> subject to deployment needs and user experience first. > >> > >> Section 2.5 "Security Policy Prohibiting Traffic From Visiting > >> Nodes" poses problems for my understanding. The title is > >> expressive, however the description is difficult to grasp, IMHO. > >> > >>> it can be expected that in many deployments, policies will be put > >>> in place to prevent untrusted visitors from attaching to the > >>> Mobile Router. [...] A Route Optimization mechanism that would > >>> prevent the multiple re- encapsulation of the packets by nested > >>> Mobile Routers might as a side effect alleviate this limitation > >> > >> > >> In my understanding "policy" is like packet filters on MR, that > >> would simply block anybody else than the known LFNs to connect to > >> that moving network. No RO mechanism could do anything against > >> those policies. If they're in place then nothing could be done > >> about them. > > > >> > > > >> Maybe the moving networks problem was this: any moving network can > >> attach to another moving network and there may be DoS attacks when > >> entities administrated by different separate administrative domains > >> take networking ressources from each other without a formal > >> agreement. In that case a formal agreement may solve the problem, > >> but not an RO solution which is mainly designed to shorten paths. > >> No? > > > > > > RO solution is designed to shorten paths, which means that it's > > providing an alternative paths for the MNNs. Since the alternative > > path is different from the default MRHA tunnel, the MRs may decide to > > forward packets for the vistor through the alternative path since the > > path will not threaten its home network. > > > > We didn't define what the "policy" might be, but if the policy > > prohibits a vistor to connect to its mobile network, as you > > mentioned, then I a RO solution is not designed to solve that > > problem. > > Thanks. I've re-read the section. It says that with typical networks, > maybe T4T is used and nodes do connect to each other without worry. And > it says that with NEMO if VMNs are allowed to connect to moving networks > then the T4T "policy" may no longer apply because traffic goes through > HA, which is another network. And which may make administrators to no > longer apply T4T. But if NEMO used RO then the administrators would > continue to indulge VMNs, because traffic would no longer go through HA. > > The reasoning sounds complicated to me, it makes assumptions on too many > unknown things (T4T, policies, etc). > > Maybe it would be easier to say something along the lines of this: if > NEMO uses RO then there is more probability that moving networks will be > allowed (policy-wise) to connect to each other. Does this follow? > > >> Section 2.7 "Deadlock with a Home Agent Nested in a Mobile Network" > >> has a textual illustration (ASCII art) of a mobility configuration > >> experimented in lab and where MRs can't update their HAs because > >> the tunnels would "cross-over" each other if they were set, instead > >> of "encapsulating" each other (see section B.6 in an expired draft > >> at http://tinyurl.com/4z4kc). > >> > >> Section 5 "Security Considerations" - ok this document does not > >> introduce any security issues, but what about the potential > >> extensions of the (security) RR mechanisms that can't be logically > >> extended to return routability tests for entire prefixes (the MNP > >> instead of HoA)? This was one of the important issues of not > >> looking at RO mechanisms for NEMO, because it was said that > >> extending RR to support prefixes is very unclear. > > > > > > The document is not intend to discuss any potential solutions, but > > perhaps in the Solution Space Analysis draft which is to be published > > soon. > > I agree this document should not have discussion of potential solutions. > I just wanted to mention that there is a "prefix ownership problem" > just like there is an "address ownership problem" (which was addressed > with CGA). It is little feasible to use CGA to address the "prefix > ownership problem". It is little feasible to do return routability > testing for all addresses comprised by a prefix. Without addressing the > "prefix ownership problem" it little feasible IMHO to have RR/RO like > MIP6 is. > > Maybe it's not correctly formulated... > > Maybe something should be said like this: assume RO is needed for NEMO. > It is then needed to use mechanism similar to MIP6 RR. But MIP6 RR is > used to ensure that a certain address is owned by a MN. It can't be > extended to ensure that an entire prefix is owned by an MR. > > "Prefix Ownership": when MR tries to instruct a CN that its MNP is at a > new CoA it should have a means to convince CN that that particular MNP > is actually the MNP that the MR is administratively assigned, in order > to avoid security attacks. > > Maybe still not correctly formulated, but you may get the idea... > > Alex > >