From TommyBoswell@thewarned.com Fri Feb 1 00:19:13 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A76A13A683D for ; Fri, 1 Feb 2008 00:19:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 89.938 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=89.938 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DATE_IN_FUTURE_03_06=0.274, FH_RELAY_NODNS=1.451, FORGED_MUA_OUTLOOK=3.116, INVALID_MSGID=1.9, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_ENLRGYOUR=1.02, STOX_REPLY_TYPE=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 0.0 STOX_REPLY_TYPE STOX_REPLY_TYPE * 0.3 DATE_IN_FUTURE_03_06 Date: is 3 to 6 hours after Received: date * 1.0 SARE_ENLRGYOUR BODY: Talks about "enlarging" something * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: hisamesses.com] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: hisamesses.com] * 10 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist * [URIs: hisamesses.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: hisamesses.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: hisamesses.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: hisamesses.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: hisamesses.com] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * [88.247.193.212 listed in zen.spamhaus.org] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS * 1.9 INVALID_MSGID Message-Id is not valid, according to RFC 2822 * 3.1 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhHwqittwJIn for ; Fri, 1 Feb 2008 00:19:12 -0800 (PST) Received: from rsm07.yemmakas.local (unknown [88.247.193.212]) by core3.amsl.com (Postfix) with SMTP id 1DD973A689E for ; Fri, 1 Feb 2008 00:19:10 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by host85180492.thewarned.com (8.13.1/8.13.1) with SMTP id 5H30VUES35.220044.O5N.bnR.3075958351477 for ; Fri, 1 Feb 2008 10:17:00 -0200 Message-ID: 5be601c864aa$e221c120$1701a8c0@RSM07 From: "Doctor Tommy Boswell" To: Subject: ***SPAM*** 89.938 (5) Enormous jang is the fact that all wife love. Date: Fri, 1 Feb 2008 10:17:00 -0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Your wife lived you alone by reason of she had sex with your friend. By reason of she has always dreamed about huge male aggregate. Don't worry guy. At present you have wonderful possibility to Enlarge your male aggregate length. Increase your male aggregate size and you will forget about troubles for sure. http://www.hisamesses.com From RandallCarlton@refdesk.com Fri Feb 1 00:19:14 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE9D43A6872; Fri, 1 Feb 2008 00:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 91.168 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=91.168 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DATE_IN_FUTURE_03_06=0.274, FH_RELAY_NODNS=1.451, FORGED_MUA_OUTLOOK=3.116, INVALID_MSGID=1.9, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_ADLTSUB2=1.23, SARE_ENLRGYOUR=1.02, STOX_REPLY_TYPE=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 1.2 SARE_ADLTSUB2 Contains possible adult words * 0.0 STOX_REPLY_TYPE STOX_REPLY_TYPE * 0.3 DATE_IN_FUTURE_03_06 Date: is 3 to 6 hours after Received: date * 1.0 SARE_ENLRGYOUR BODY: Talks about "enlarging" something * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: tunborr.com] * 10 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist * [URIs: tunborr.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: tunborr.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: tunborr.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: tunborr.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: tunborr.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: tunborr.com] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * [88.247.193.212 listed in zen.spamhaus.org] * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS * 1.9 INVALID_MSGID Message-Id is not valid, according to RFC 2822 * 3.1 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3AhsRqL7zPH; Fri, 1 Feb 2008 00:19:14 -0800 (PST) Received: from rsm07.yemmakas.local (unknown [88.247.193.212]) by core3.amsl.com (Postfix) with SMTP id DCAAE3A6896; Fri, 1 Feb 2008 00:19:09 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by host81708333.refdesk.com (8.13.1/8.13.1) with SMTP id icmGuNNp69.023559.oOm.mzQ.7901060292469 for ; Fri, 1 Feb 2008 10:17:00 -0200 Message-ID: 5b4c01c864aa$e09de040$1701a8c0@RSM07 From: "Doctor Randall Carlton" To: , " X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7650D3A6900; Fri, 1 Feb 2008 01:22:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 108.255 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=108.255 tagged_above=-999 required=5 tests=[BAYES_99=3.5, BODY_ENHANCEMENT=0.309, BODY_ENHANCEMENT2=0.001, DATE_IN_FUTURE_06_12=1.897, FH_RELAY_NODNS=1.451, FRT_PENIS1=3.592, HELO_EQ_BR=0.955, HELO_MISMATCH_BR=2.4, J_CHICKENPOX_23=0.6, MANGLED_PENIS=2.3, MONEY_BACK=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DSBL=0.961, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_SORBS_MISC=0.353, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_ADULT2=1.42, SARE_ENLRGYOUR=1.02, SARE_OBFU_PENIS_SUB=3.333, SARE_SUB_CASH_CHAR=0.747, SUBJECT_FUZZY_PENIS=3.096, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 1.0 HELO_EQ_BR HELO_EQ_BR * 0.7 SARE_SUB_CASH_CHAR Subject has letter then $ then letter * 3.1 SUBJECT_FUZZY_PENIS Attempt to obfuscate words in Subject: * 3.3 SARE_OBFU_PENIS_SUB subject has obfuscated spammer topic * 1.9 DATE_IN_FUTURE_06_12 Date: is 6 to 12 hours after Received: date * 0.6 J_CHICKENPOX_23 BODY: 2alpha-pock-3alpha * 2.3 MANGLED_PENIS BODY: mangled - Penis * 0.0 MONEY_BACK BODY: Money back guarantee * 0.3 BODY_ENHANCEMENT BODY: Information on growing body parts * 1.0 SARE_ENLRGYOUR BODY: Talks about "enlarging" something * 1.4 SARE_ADULT2 BODY: Contains adult material * 3.6 FRT_PENIS1 BODY: ReplaceTags: Penis * 0.0 BODY_ENHANCEMENT2 BODY: Information on getting larger body parts * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: dovosgehr.com] * 10 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist * [URIs: dovosgehr.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: dovosgehr.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: dovosgehr.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: dovosgehr.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: dovosgehr.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: dovosgehr.com] * 1.6 RCVD_IN_NJABL_PROXY RBL: NJABL: sender is an open proxy * [211.136.107.180 listed in combined.njabl.org] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * [211.136.107.180 listed in zen.spamhaus.org] * 0.4 RCVD_IN_SORBS_MISC RBL: SORBS: sender is open proxy server * [211.136.107.180 listed in dnsbl.sorbs.net] * 1.0 RCVD_IN_DSBL RBL: Received via a relay in list.dsbl.org * [] * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS * 2.4 HELO_MISMATCH_BR HELO_MISMATCH_BR Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4q0FEnnsAhC; Fri, 1 Feb 2008 01:22:37 -0800 (PST) Received: from zaz.com.br (unknown [211.136.107.180]) by core3.amsl.com (Postfix) with ESMTP id 586D63A68FA; Fri, 1 Feb 2008 01:22:37 -0800 (PST) MIME-Version: 1.0 Date: Fri, 01 Feb 2008 16:29:26 +0000 To: nemo@ietf.org, nemo-archive@ietf.org, nsis@ietf.org, nsis-admin@ietf.org From: "Cole Montes" Subject: ***SPAM*** 108.255 (5) Hey. Is big pe$nis better ? ovx5q4 Message-ID: <1201883366.5057@gmx.net> Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit Dear nemo@ietf.org http://dovosgehr.com Do you want Enlarge your Penis? » Gain 3+ Inches In Length. 100% Money Back Guarantee. » *3 FREE Bottles Of ManSter !! http://dovosgehr.com Thanks Rebeca Moore nemo@ietf.org wrote: > Do you want enlarge your penis? e7dvzemt9m- out me now http://dovosgehr.com/w.php From wyndham-erohim@EXCELLENT-LIVIN.NL Fri Feb 1 01:54:12 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9272A3A686F for ; Fri, 1 Feb 2008 01:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 96.897 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=96.897 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FB_PENIS=1.66, FH_RELAY_NODNS=1.451, FRT_PENIS1=3.592, HELO_EQ_IP_ADDR=1.119, HTML_MESSAGE=1, J_CHICKENPOX_13=0.6, MANGLED_PENIS=2.3, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.1 HELO_EQ_IP_ADDR HELO using IP Address (not private) * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 2.3 MANGLED_PENIS BODY: mangled - Penis * 3.6 FRT_PENIS1 BODY: ReplaceTags: Penis * 1.7 FB_PENIS BODY: FB_PENIS * 0.6 J_CHICKENPOX_13 BODY: 1alpha-pock-3alpha * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: keelnena.com] * 10 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist * [URIs: keelnena.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: keelnena.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: keelnena.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: keelnena.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: keelnena.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: keelnena.com] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [151.56.67.40 listed in dnsbl.sorbs.net] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [151.56.67.40 listed in zen.spamhaus.org] * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muaIV7kDXaCk for ; Fri, 1 Feb 2008 01:54:11 -0800 (PST) Received: from [151.56.67.40] (unknown [151.56.67.40]) by core3.amsl.com (Postfix) with ESMTP id C93803A68FB for ; Fri, 1 Feb 2008 01:53:53 -0800 (PST) Message-ID: <000c01c864b8$95c27b90$28433897@windowsfff2962> From: "wyndham Kalbfleisch" To: nemo-archive@lists.ietf.org Subject: ***SPAM*** 96.897 (5) Real Men have Real Big Dcks, are you a Real Man? Date: Fri, 1 Feb 2008 10:55:32 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0008_01C864C0.F786E390" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_0008_01C864C0.F786E390 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Make her tremble with desire with your new huge p3nis ----------=_NextPart_000_0008_01C864C0.F786E390 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Make her tremble with desire with = your new=20 huge p3nis ----------=_NextPart_000_0008_01C864C0.F786E390-- From mext-bounces@ietf.org Fri Feb 1 02:32:01 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5034D3A68FF; Fri, 1 Feb 2008 02:32:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lL2+QRBht6Ap; Fri, 1 Feb 2008 02:32:00 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21E7F3A68B3; Fri, 1 Feb 2008 02:32:00 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 930873A68B3 for ; Fri, 1 Feb 2008 02:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdQP2gEtN3jz for ; Fri, 1 Feb 2008 02:31:58 -0800 (PST) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.232]) by core3.amsl.com (Postfix) with ESMTP id 6F4133A6869 for ; Fri, 1 Feb 2008 02:31:58 -0800 (PST) Received: by wx-out-0506.google.com with SMTP id s8so1156238wxc.31 for ; Fri, 01 Feb 2008 02:33:32 -0800 (PST) Received: by 10.142.226.2 with SMTP id y2mr1995682wfg.46.1201862010936; Fri, 01 Feb 2008 02:33:30 -0800 (PST) Received: from ?203.178.143.210? ( [203.178.143.210]) by mx.google.com with ESMTPS id h38sm108366wxd.15.2008.02.01.02.33.23 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Feb 2008 02:33:28 -0800 (PST) From: RYUJI WAKIKAWA To: George Tsirtsis In-Reply-To: References: <7892795E1A87F04CADFCCF41FADD00FC051C02A0@xmb-ams-337.emea.cisco.com> <4C47BAA9-BA58-45F7-BDCF-2C050118BACE@it.uc3m.es> <6D19CA8D71C89C43A057926FE0D4ADAA232B6D@ecamlmw720.eamcs.ericsson.se> Message-Id: <855CE3D2-FD2E-498F-BABB-1970645CBC77@gmail.com> Mime-Version: 1.0 (Apple Message framework v915) Date: Fri, 1 Feb 2008 19:33:19 +0900 X-Mailer: Apple Mail (2.915) Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] re-direction attack on MCoA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi All, Thanks for all your comments. I agree with George and see the progress. I treated this action as a consensus. We will not include the Ben's solution in the MCoA and leave it to = other work. thanks, ryuji On 2008/01/31, at 20:08, George Tsirtsis wrote: > I am of course also interested in this work. I guess we already have > enough people to get the ball rolling on this. > > Thanks > George > > On Jan 31, 2008 10:59 AM, Suresh Krishnan > wrote: >> Hi Marcelo, >> I am willing to work on a generic MIPv6 threats document along = >> with the other interested people. >> >> Cheers >> Suresh >> >> -----Original Message----- >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >> Sent: January 31, 2008 11:13 AM >> To: Wassim Haddad >> Cc: Julien Laganier; mext@ietf.org >> >> Subject: Re: [MEXT] re-direction attack on MCoA >> >> >> El 30/01/2008, a las 19:16, Wassim Haddad escribi=F3: >>> >>> =3D> As there is a clear interest in the redirection attack on the HA >>> side, I volunteer to do some work on this one. >>> >> >> I think the work should be general to all residual threats on MIP as >> George mentioned, i think this would be more interesting since it >> would allow us to put the different threats in perspective and figure >> out which ones we should address. >> >> >> >>> >>> Regards, >>> >>> Wassim H. >>> >>> >>>> El 30/01/2008, a las 18:19, Wassim Haddad escribi=F3: >>>> >>>>> Hi Marcelo, >>>>> IMHO, this topic has to be included as a new item in the new >>>>> charter and >>>>> should not be limited to MCoA. >>>>> Regards, >>>>> Wassim H. >>>>> On Wed, 30 Jan 2008, marcelo bagnulo braun wrote: >>>>>> Pascal, >>>>>> The question at this point is the following one: do you think >>>>>> that this threat should be addressed in the MCoA draft itself? >>>>>> comments? >>>>>> Regards, marcelo >>>>>> El 30/01/2008, a las 10:09, Pascal Thubert (pthubert) escribi=F3: >>>>>>> I agree with Wassim on both mails. >>>>>>> There's also the situation where the MN/MR might be fooled by = >>>>>>> the >>>>>>> visited network into believing that the CoA (or its prefix if a >>>>>>> network >>>>>>> is attacked as opposed to a host) is on the visited link. DSMIP >>>>>>> is also >>>>>>> exposed, in particular with IPv4 CoAs. >>>>>>> There are many scenarios that do not involve high mobility were >>>>>>> a 3-way >>>>>>> or a 4-way handshake could be used to verify the CoA. We have >>>>>>> proposed >>>>>>> such a test in section 6 of the RRH draft that uses a triggered >>>>>>> 2nd BU >>>>>>> flow to verify the CoA in the first one: >>>>>>> http://tools.ietf.org/html/draft-thubert-nemo-reverse-routing-heade= r-07# >>>>>>> section-6 >>>>>>> Pascal >>>>>>>> -----Original Message----- >>>>>>>> From: Wassim Haddad [mailto:whaddad@tcs.hut.fi] >>>>>>>> Sent: mercredi 30 janvier 2008 09:32 >>>>>>>> To: Benjamin Lim >>>>>>>> Cc: 'Julien Laganier'; mext@ietf.org >>>>>>>> Subject: RE: [MEXT] re-direction attack on MCoA >>>>>>>> On Wed, 30 Jan 2008, Benjamin Lim wrote: >>>>>>>>> All in all, what I am trying to say is that tracing only >>>>>>>>> limits the >>>>>>>>> effect of the attack from escalating further and not >>>>>>>>> preventing it. >>>>>>>> =3D> which (again) also perfectly applies to a single CoA. >>>>>>>> Regards, >>>>>>>> Wassim H. >>>>>>>> _______________________________________________ >>>>>>>> MEXT mailing list >>>>>>>> MEXT@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/mext >>>>>>> _______________________________________________ >>>>>>> MEXT mailing list >>>>>>> MEXT@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/mext >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/mext >>>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mext >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www1.ietf.org/mailman/listinfo/mext >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www1.ietf.org/mailman/listinfo/mext >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Feb 1 02:34:19 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0E5F3A6913; Fri, 1 Feb 2008 02:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1pTobeUTc0C; Fri, 1 Feb 2008 02:34:18 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 589253A689E; Fri, 1 Feb 2008 02:34:18 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 447343A6880 for ; Fri, 1 Feb 2008 02:34:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUsh-4+IThjw for ; Fri, 1 Feb 2008 02:34:15 -0800 (PST) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by core3.amsl.com (Postfix) with ESMTP id 83DFF3A689E for ; Fri, 1 Feb 2008 02:34:15 -0800 (PST) Received: by py-out-1112.google.com with SMTP id x19so1135977pyg.24 for ; Fri, 01 Feb 2008 02:35:49 -0800 (PST) Received: by 10.110.2.2 with SMTP id 2mr1807454tib.14.1201862147473; Fri, 01 Feb 2008 02:35:47 -0800 (PST) Received: from ?203.178.143.210? ( [203.178.143.210]) by mx.google.com with ESMTPS id h38sm115638wxd.15.2008.02.01.02.35.39 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Feb 2008 02:35:42 -0800 (PST) From: RYUJI WAKIKAWA To: George Tsirtsis In-Reply-To: References: <479E56F1.5080906@azairenet.com> Message-Id: <947C06A5-BC84-46C6-87D0-C8F34D2A2C4E@gmail.com> Mime-Version: 1.0 (Apple Message framework v915) Date: Fri, 1 Feb 2008 19:35:35 +0900 X-Mailer: Apple Mail (2.915) Cc: mext@ietf.org Subject: Re: [MEXT] re-direction attack on MCoA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org George, Thanks for summary. I agree this issue is not specific to MCoA. > In fact I think the following should > be removed form the MCoA draft.....possibly moved to the flow > filtering draft.: > " This valid care-of address could then be used by the malicious > mobile > node to set up flow filtering rules at its home agent, thereby > controlling and/or launching new re-direction attacks." OK regards, ryuji On 2008/01/29, at 19:58, George Tsirtsis wrote: > Hi Ben, et.al., > > While the issue you point out is real (everyone seems to agree with > that) it falls under the category of traceable attacks, as others have > already pointed out. In MIPv6 we never really considered the issue of > a "fake" CoAs as a very important one (Only MIPv4 FA Mode deals with > that). Indeed, several attacks, like the redirection attack you point > out are possible, even without MCoA support. But other attacks are > also possible without MCoA support e.g., an MN associates with two > different HAs and registers the HoA from the first as the CoA for the > second and vice versa, creating a routing loop. > > So, I share the sentiment of the group that mitigation techniques > should be defined outside the MCoA spec, and I would suggest we > actually expand the scope of these techniques to cover also other > cases involving CoA based attacks. > > In any case the attack you describe for the MCoA case does not become > really interesting unless it is combined with flow filtering which is > out of scope of the MCoA draft. In fact I think the following should > be removed form the MCoA draft.....possibly moved to the flow > filtering draft.: > " This valid care-of address could then be used by the malicious > mobile > node to set up flow filtering rules at its home agent, thereby > controlling and/or launching new re-direction attacks." > > Regards > George > > On Jan 29, 2008 3:03 AM, Benjamin Lim > wrote: >> Hi Vijay, >> >> =8==8<=8== >>> FWIW, for the current draft, I think it is sufficient to >>> point out the threats in the security considerations section. >>> The home agent knows which mobile node launched the attch, so >>> that should be a deterrent. We should not require the CoA to >>> be a CGA, require CBA or mandate a return routability test >>> for the CoA for the multiple CoA extension. >> [Ben] I am not mandating a solution for CoA testing yet. My >> intention in my >> draft was to analyze and discuss the best way to solve the problem. >> Till >> then, I feel it might be better to list the current possible >> approaches to >> the problem in the MCoA draft. These approaches serves as some >> options that >> implementers can take to help advert such problem. >> >>> >>> I also think we should add an informative reference pointing >>> to draft-lim-mext-multiple-coa-verify-00 for preventing the attack. >> [Ben] A standard track document pointing to a draft that may expire >> for >> solutions. I am not sure if this is the correct way to go. >> >> Regards, >> Benjamin Lim >> >> >>> >>> Vijay >>> >>> Benjamin Lim wrote: >>>> Hi, >>>> >>>> Some points inline to start of discussion. >>>> >>>>> -----Original Message----- >>>>> From: RYUJI WAKIKAWA [mailto:ryuji.wakikawa@gmail.com] >>>>> Sent: Monday, January 28, 2008 11:27 AM >>>>> To: mext@ietf.org >>>>> Subject: [MEXT] re-direction attack on MCoA >>>>> >>>>> Hi, >>>>> >>>>> At the last IETF meeting, Benjamin presented the security >>>>> vulnerability of MCoA, re-direction attack. >>>>> Benjamin's text is merged into the security consideration >>> section. >>>>> Thanks Benjamin. >>>>> >>>>> However, we didn't merge the solution part in the MCoA. >>>>> The proposed solution is more like an extension and should >>> be written >>>>> in the separate document. >>>>> We believe the issue of re-direction attack should not be often >>>>> happened because a malicious mobile node is always traceable by an >>>>> operator (i.e. HA). >>>>> A mobile node must take certain risk to do re-direction attack. >>>> [Ben] Such risk taken by the mobile node does factor into >>> the account >>>> on wether the attack will occur. However, I find it hard to justify >>>> that such risk will prevent such attack from happening >>> often. If more >>>> and more attackers are willingly to take such risk (e.g. >>> strong sense >>>> of purpose or even 'big ego') or there exisit better mechnisam that >>>> helps mask the attacker identity in the future, can we say >>> that such >>>> attacks will not happen often? >>>> >>>>> For the MCoA document it should be sufficient to just >>> point out this >>>>> threats. >>>> [Ben] This is my point of view. As this is a standard >>> tracks document >>>> for a protocol, stating a possible miuse of the protocol (aka loop >>>> hole) without providing some soultions or guideline to it >>> seems funny. >>>> Its like saying "hey you can exploit this protocol this way. How to >>>> slove/prevent it, crack your own brains" Hence, my intention of the >>>> below proposed text is to serve as a guide that such exploit can be >>>> reduce/prevent with some methods. This I feel helps >>> implementers as we >>>> provide some basic steps to help advert such misuse. >>>> >>>> Would appericate any comments to help in this discussion. Thanks! >>>> >>>> Regards, >>>> Benjamin Lim >>>>> If you have any comments, let us know. >>>>> I attach the Benjamin's proposed text. >>>>> >>>>> thanks >>>>> ryuji >>>>> >>>>> >>>>> >>>>> To mitigate such risk described in Section 9, one approach >>> is for the >>>>> care-of address to be secured cryptographically (CGA) [RFC-3972], >>>>> thus permitting the home agent to know if the mobile node actually >>>>> owns that particular care-of address listed in the binding update >>>>> message. >>>>> However, >>>>> introducing cryptographically generated care-of addresses might >>>>> increase the complexity of the mechanism to achieve >>> multiple bindings >>>>> such as how a message can contain multiple CGA signatures >>> for each of >>>>> the care-of addresses, integration between the CGA module and >>>>> Mobility Support module in a network stack implementation >>> and further >>>>> increasing the size of the binding update message. >>> Furthermore, using >>>>> CGA does not prevent a malicious mobile node to launch a flooding >>>>> attack against a subnet by generating multiple >>> non-existent care-of >>>>> addresses in that subnet using the mobile node's own public keys. >>>>> >>>>> Another approach to mitigate the risk is to employ some means at a >>>>> home agent to limit the amount of information that a home >>> agent can >>>>> send to a care-of address that has not be tested for its >>>>> reachability. This reduces the chances of the home agent from >>>>> flooding packets to a particular untested care-of address. >>> A possible >>>>> technique to achieve this is to use credit- based >>> authorization (CBA) >>>>> [RFC-4866]. In this technique, for the home agent to fully use the >>>>> care-of address for packet routing, the home agent would need to >>>>> receive a packet from the mobile node from the untested care-of >>>>> address. >>>>> However, the packets that the home agent receives from >>> these untested >>>>> care-of addresses might not be sent by the mobile node. >>> Hence, this >>>>> technique and the following few proposed techniques will >>> henceforth >>>>> assumes that ingress filtering within the network is done. For >>>>> example, a mobile node can use the Internet Control >>> Message Protocol >>>>> (ICMP) described in [RFC-792] to send a request message >>> via its home >>>>> address to a untested victim care-of address, thereby triggering a >>>>> response from this care-of address. Also, in situations where an >>>>> interface of the mobile node has asymmetrical link characteristics >>>>> (e.g. General Packet Radio System), that particular >>> interface might >>>>> have resource constraint on its upload path making it costly for a >>>>> mobile node to send a packet to its home agent using that >>> particular >>>>> interface. >>>>> >>>>> In yet another approach, instead of the home agent waiting for a >>>>> packet to fully utilize a care-of address for routing, it might be >>>>> possible for the home agent to send a packet to a untested care-of >>>>> address to trigger a response from the mobile node from >>> that care-of >>>>> address. One technique described in [ID-RRCOOKIE] uses a cookie to >>>>> prove to the home agent that the mobile node is reachable at a >>>>> specified care-of address. Another technique could employ >>> the use of >>>>> the Binding Refresh Request message to trigger the mobile node to >>>>> send a binding update message from that care-of address to >>> the mobile >>>>> node. However, this technique of testing reduces the optimization >>>>> benefit of sending bulk registration as it would require >>> the mobile >>>>> node to respond via all these care-of addresses. In this case, the >>>>> mobile node might as well send the binding update message >>>>> individually for each care-of address. >>>>> >>>>> To optimize the previous approach in order to keep the benefits of >>>>> bulk registration, the home agent could test the care-of >>> address by >>>>> asking a mobile node to reply from a different care-of address as >>>>> oppose to the care-of address that was used by the home >>> agent to send >>>>> the trigger message. >>>>> This utilizes the concept of multiple care-of addresses >>> whereby the >>>>> mobile node need not respond back using the same path as the >>>>> reception of the request. Such a concept is particularly useful in >>>>> the event that the mobile node has several unverified care-of >>>>> addresses that needs to be tested. >>>>> By >>>>> asking the mobile node to respond via another care-of >>> address, in one >>>>> round trip time, the home agent would be able to verify >>> two care-of >>>>> addresses. >>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/mext >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mext >>> >>> >> >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www1.ietf.org/mailman/listinfo/mext >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From violetta@glankler.com Fri Feb 1 02:55:47 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96F213A680F for ; Fri, 1 Feb 2008 02:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 54.965 X-Spam-Level: ****************************************************** X-Spam-Status: Yes, score=54.965 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_DHCP=1.398, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HELO_EQ_DSL_3=1.022, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 0.9995] * 1.0 SARE_HELO_EQ_DSL_3 SARE_HELO_EQ_DSL_3 * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 1.4 HELO_DYNAMIC_DHCP Relay HELO'd using suspicious hostname (DHCP) * 0.0 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: 76.31.103.49] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: 76.31.103.49] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: 76.31.103.49] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * [61.246.140.50 listed in zen.spamhaus.org] * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJtxygDMaKWM for ; Fri, 1 Feb 2008 02:55:47 -0800 (PST) Received: from dsl-MP-static-050.140.246.61.airtelbroadband.in (unknown [61.246.140.50]) by core3.amsl.com (Postfix) with SMTP id 00CAA3A6880 for ; Fri, 1 Feb 2008 02:55:43 -0800 (PST) Received: (qmail 28653 invoked from network); Fri, 1 Feb 2008 16:27:42 +0530 Received: from unknown (HELO unoif) (180.226.166.134) by dsl-MP-static-050.140.246.61.airtelbroadband.in with SMTP; Fri, 1 Feb 2008 16:27:42 +0530 Message-ID: <47A2FB26.3020600@glankler.com> Date: Fri, 1 Feb 2008 16:27:42 +0530 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: ***SPAM*** 54.965 (5) Size truly does matter! Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Our experts advise http://76.31.103.49/vs/ From tommyfrom253@airportcoordination.dk Fri Feb 1 03:42:03 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 280593A691D for ; Fri, 1 Feb 2008 03:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 66.657 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=66.657 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d * 3.5 HELO_DYNAMIC_SPLIT_IP Relay HELO'd using suspicious hostname (Split * IP) * 1.1 HELO_EQ_IP_ADDR HELO using IP Address (not private) * 0.9 FH_HOST_EQ_D_D_D_DB Host is d-d-d-d * 4.4 HELO_DYNAMIC_IPADDR2 Relay HELO'd using suspicious hostname (IP addr * 2) * 1.9 TVD_RCVD_IP TVD_RCVD_IP * 2.1 RCVD_NUMERIC_HELO Received: contains an IP address used for HELO * 0.0 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: 89.252.21.37] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [70.44.177.96 listed in zen.spamhaus.org] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: 89.252.21.37] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: 89.252.21.37] * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9hjOVIvrxLi for ; Fri, 1 Feb 2008 03:42:02 -0800 (PST) Received: from 70.44.177.96.res-cmts.tnk.ptd.net (70.44.177.96.res-cmts.tnk.ptd.net [70.44.177.96]) by core3.amsl.com (Postfix) with SMTP id A84CE3A68B5 for ; Fri, 1 Feb 2008 03:42:00 -0800 (PST) Received: from [179.98.140.158] (helo=qof) by 70.44.177.96.res-cmts.tnk.ptd.net with smtp (Exim 4.62 (FreeBSD)) id 1JLT2-0004Uj-B9; Fri, 1 Feb 2008 06:44:28 -0500 Message-ID: <47A305E2.7030003@airportcoordination.dk> Date: Fri, 1 Feb 2008 06:43:30 -0500 From: User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: nemo-archive@ietf.org Subject: ***SPAM*** 66.657 (5) Your Love Has Opened Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Words in my Heart http://89.252.21.37/ From namsdool1979@ABCIN.COM Fri Feb 1 03:53:27 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3632928C202 for ; Fri, 1 Feb 2008 03:53:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 68.34 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=68.34 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_SEX_HOSTDDDD=10.357, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HTML_MESSAGE=1, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, SARE_SXLIFE=1.07, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d * 3.5 HELO_DYNAMIC_SPLIT_IP Relay HELO'd using suspicious hostname (Split * IP) * 1.1 HELO_EQ_IP_ADDR HELO using IP Address (not private) * 0.9 FH_HOST_EQ_D_D_D_DB Host is d-d-d-d * 4.4 HELO_DYNAMIC_IPADDR2 Relay HELO'd using suspicious hostname (IP addr * 2) * 1.9 TVD_RCVD_IP TVD_RCVD_IP * 2.1 RCVD_NUMERIC_HELO Received: contains an IP address used for HELO * 1.1 SARE_SXLIFE BODY: Talks about your sex life * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: bjoogehhy.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: bjoogehhy.com] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [77.54.24.201 listed in zen.spamhaus.org] * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS * 10 FM_SEX_HOSTDDDD Sex words + host = dddd * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4lo1vFu3Psx for ; Fri, 1 Feb 2008 03:53:26 -0800 (PST) Received: from 122.160.54.77.rev.vodafone.pt (201.24.54.77.rev.vodafone.pt [77.54.24.201]) by core3.amsl.com (Postfix) with ESMTP id 4922A3A6813 for ; Fri, 1 Feb 2008 03:53:23 -0800 (PST) Message-ID: <000701c864c9$47d75e80$7aa0364d@paulo771b52c78> From: "Bayani Poyphom" To: nemo-archive@lists.ietf.org Subject: ***SPAM*** 68.34 (5) Chicks will be AMAZED by your legendary PROWESS. Date: Fri, 1 Feb 2008 11:55:03 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0003_01C864C9.47D75E80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_0003_01C864C9.47D75E80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A huge manhood is your ticket to a great sex life, everyday. ----------=_NextPart_000_0003_01C864C9.47D75E80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A huge manhood is your ticket to a = great sex=20 life, everyday. ----------=_NextPart_000_0003_01C864C9.47D75E80-- From mailman-bounces@core3.amsl.com Fri Feb 1 06:03:59 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02D0E28C70C for ; Fri, 1 Feb 2008 05:59:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T73pXn-PTOhi for ; Fri, 1 Feb 2008 05:59:51 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33B42296761 for ; Fri, 1 Feb 2008 05:35:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: nemo-archive@megatron.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:05:14 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! From mailman-bounces@core3.amsl.com Fri Feb 1 06:04:21 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A81CF295227 for ; Fri, 1 Feb 2008 06:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+FG8XKqlWVa for ; Fri, 1 Feb 2008 06:00:06 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A4B3293D66 for ; Fri, 1 Feb 2008 05:35:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: nemo-archive@megatron.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:05:15 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! From vivian06@faxsav.com Fri Feb 1 07:22:48 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDB0D3A6B59 for ; Fri, 1 Feb 2008 07:22:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 59.477 X-Spam-Level: *********************************************************** X-Spam-Status: Yes, score=59.477 tagged_above=-999 required=5 tests=[BAYES_99=3.5, BODY_ENHANCEMENT=0.309, BODY_ENHANCEMENT2=0.001, DOS_OE_TO_MX=2.75, DRUGS_ERECTILE=1, DRUGS_ERECTILE_OBFU=1.5, FB_CIALIS_LEO3=3.899, FH_RELAY_NODNS=1.451, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IT=0.635, HTML_MESSAGE=1, J_CHICKENPOX_12=0.6, MANGLED_CIALIS=2.5, MANGLED_DOSE=2.3, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, SARE_ADULT2=1.42, SUBJECT_DRUG_GAP_C=0.003, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.1 HELO_EQ_DYNAMIC HELO_EQ_DYNAMIC * 0.6 HELO_EQ_IT HELO_EQ_IT * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 0.0 SUBJECT_DRUG_GAP_C Subject contains a gappy version of 'cialis' * 2.3 MANGLED_DOSE BODY: mangled dose * 2.5 MANGLED_CIALIS BODY: mangled Cialis * 3.9 FB_CIALIS_LEO3 BODY: Uses a mis-spelled version of cialis. * 0.3 BODY_ENHANCEMENT BODY: Information on growing body parts * 0.6 J_CHICKENPOX_12 BODY: 1alpha-pock-2alpha * 1.4 SARE_ADULT2 BODY: Contains adult material * 0.0 BODY_ENHANCEMENT2 BODY: Information on getting larger body parts * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: knowfull.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: knowfull.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: knowfull.com] * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [79.22.252.10 listed in dnsbl.sorbs.net] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [79.22.252.10 listed in zen.spamhaus.org] * 1.5 DRUGS_ERECTILE_OBFU Obfuscated reference to an erectile drug * 1.0 DRUGS_ERECTILE Refers to an erectile drug * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9W3rdPWFT+7P for ; Fri, 1 Feb 2008 07:22:46 -0800 (PST) Received: from host10-252-dynamic.22-79-r.retail.telecomitalia.it (unknown [79.22.252.10]) by core3.amsl.com (Postfix) with ESMTP id 2249E28C5CC for ; Fri, 1 Feb 2008 07:11:25 -0800 (PST) Message-ID: <000701c864e4$03d3e840$235f43a8@scgrraii> From: "kalman collins" To: Subject: ***SPAM*** 59.477 (5) Worldwide ciallis delivery. Date: Fri, 01 Feb 2008 13:25:30 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C864E4.03D12218" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C864E4.03D12218 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What is tadalafil? Tadalafil relaxes muscles within the penis. This = allows increased blood flow into the penis, necessary to achieve and = maintain an erection. Ciallis at $2.8 per d0se Cheap ------=_NextPart_000_0004_01C864E4.03D12218 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

What is tadalafil? Tadalafil relaxes muscles within the penis. This = allows increased blood flow into the penis, necessary to achieve and = maintain an erection.

Ciallis at $2.8 per = d0se Cheap

------=_NextPart_000_0004_01C864E4.03D12218-- From lknox_sb@usa.net Fri Feb 1 07:39:08 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A1673A6A25; Fri, 1 Feb 2008 07:39:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 105.388 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=105.388 tagged_above=-999 required=5 tests=[BAYES_99=3.5, BODY_ENHANCEMENT=0.309, BODY_ENHANCEMENT2=0.001, FH_RELAY_NODNS=1.451, FRT_PENIS1=3.592, HELO_EQ_GEOCITIES=3.531, HELO_MISMATCH_COM=0.553, MANGLED_PENIS=2.3, MONEY_BACK=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DSBL=0.961, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_SORBS_HTTP=0.001, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_ADULT2=1.42, SARE_ENLRGYOUR=1.02, SARE_OBFU_PENIS_SUB=3.333, SUBJECT_FUZZY_PENIS=3.096, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 3.5 HELO_EQ_GEOCITIES HELO_EQ_GEOCITIES * 3.1 SUBJECT_FUZZY_PENIS Attempt to obfuscate words in Subject: * 3.3 SARE_OBFU_PENIS_SUB subject has obfuscated spammer topic * 2.3 MANGLED_PENIS BODY: mangled - Penis * 0.0 MONEY_BACK BODY: Money back guarantee * 0.3 BODY_ENHANCEMENT BODY: Information on growing body parts * 1.0 SARE_ENLRGYOUR BODY: Talks about "enlarging" something * 1.4 SARE_ADULT2 BODY: Contains adult material * 3.6 FRT_PENIS1 BODY: ReplaceTags: Penis * 0.0 BODY_ENHANCEMENT2 BODY: Information on getting larger body parts * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: dovosgehr.com] * 10 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist * [URIs: dovosgehr.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: dovosgehr.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: dovosgehr.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: dovosgehr.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: dovosgehr.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: dovosgehr.com] * 1.6 RCVD_IN_NJABL_PROXY RBL: NJABL: sender is an open proxy * [60.217.228.199 listed in combined.njabl.org] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * [60.217.228.199 listed in zen.spamhaus.org] * 0.0 RCVD_IN_SORBS_HTTP RBL: SORBS: sender is open HTTP proxy server * [60.217.228.199 listed in dnsbl.sorbs.net] * 1.0 RCVD_IN_DSBL RBL: Received via a relay in list.dsbl.org * [] * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS * 0.6 HELO_MISMATCH_COM HELO_MISMATCH_COM Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKXH0tfRR0WO; Fri, 1 Feb 2008 07:39:07 -0800 (PST) Received: from geocities.com (unknown [60.217.228.199]) by core3.amsl.com (Postfix) with ESMTP id 5A08C28C349; Fri, 1 Feb 2008 07:37:27 -0800 (PST) MIME-Version: 1.0 From: "Luella S. Knox" To: msec@ietf.org, nemo@ietf.org, nemo-archive@ietf.org Message-ID: <1201879182.8870@usa.net> Subject: ***SPAM*** 105.388 (5) Add up to 4 inches to yours peni@s kjggn Date: Fri, 01 Feb 2008 15:19:42 +0000 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit Dear msec@ietf.org http://dovosgehr.com Do you want Enlarge your Penis? » Gain 3+ Inches In Length. 100% Money Back Guarantee. » *3 FREE Bottles Of ManSter !! http://dovosgehr.com Thanks Cathy Anniston msec@ietf.org wrote: > Are you ready for BIG PENlS ? mnome7atxd- out me now http://dovosgehr.com/w.php From MarypurgeDurham@gotickets.com Fri Feb 1 07:50:39 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 679073A6975; Fri, 1 Feb 2008 07:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 16.308 X-Spam-Level: **************** X-Spam-Status: Yes, score=16.308 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DATE_IN_PAST_06_12=1.069, DOS_OE_TO_MX=2.75, FH_RELAY_NODNS=1.451, HTML_MESSAGE=1, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 1.1 DATE_IN_PAST_06_12 Date: is 6 to 12 hours before Received: date * 1.0 HTML_MESSAGE BODY: HTML included in message * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [200.44.231.109 listed in zen.spamhaus.org] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZEfrqWuX-x6; Fri, 1 Feb 2008 07:50:38 -0800 (PST) Received: from anaventas.infilca (unknown [200.44.231.109]) by core3.amsl.com (Postfix) with SMTP id A4EAB3A6905; Fri, 1 Feb 2008 07:50:37 -0800 (PST) Message-ID: From: "Denny Bauer" To: Cc: , " =20
We told you to keep = watching, G &=20 S Minerals... Symol : GSML

Gold is reaching = record of $1000/=20 oz ... GSML is the undiscovered gem you should be invested=20 in.

Up 4 straight days with = record=20 volume

If you missed the move = from .13 to .17=20 dont dispair they have not even scratched the surfact.

This company is going to=20 $3.00

So grab yourself = some GSML and=20 earn easy 10 bagger

------=_NextPart_000_B1BE_01C864E6.113F5CC0-- From mext-bounces@ietf.org Fri Feb 1 09:32:00 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8559028C3BE; Fri, 1 Feb 2008 09:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.762 X-Spam-Level: X-Spam-Status: No, score=-3.762 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mos-owb0lD7f; Fri, 1 Feb 2008 09:32:00 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41A8428C387; Fri, 1 Feb 2008 09:31:51 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9F8A28C387 for ; Fri, 1 Feb 2008 09:31:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v481-uoPjXcY for ; Fri, 1 Feb 2008 09:31:49 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id E7ACD3A68A6 for ; Fri, 1 Feb 2008 09:31:44 -0800 (PST) Received: from chelo-it-uc3m-es.it.uc3m.es (chelo-it-uc3m-es.it.uc3m.es [163.117.139.76])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp03.uc3m.es (Postfix) with ESMTP id 172372C68F9;Fri, 1 Feb 2008 18:33:18 +0100 (CET) Message-Id: From: marcelo bagnulo braun To: RYUJI WAKIKAWA In-Reply-To: <855CE3D2-FD2E-498F-BABB-1970645CBC77@gmail.com> Mime-Version: 1.0 (Apple Message framework v915) Date: Fri, 1 Feb 2008 18:33:16 +0100 References: <7892795E1A87F04CADFCCF41FADD00FC051C02A0@xmb-ams-337.emea.cisco .com><4C47BAA9-BA58-45F7-BDCF-2C050118BACE@it.uc3m.es><6D19CA8D71C89C43A057926FE0D4ADAA232B6D@ecamlm w720.eamcs.ericsson.se> <855CE3D2-FD2E-498F-BABB-1970645CBC77@gmail.com> X-Mailer: Apple Mail (2.915) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-30.4878 TC:1F TRN:51 TV:5.0.1023(15704.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] re-direction attack on MCoA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org right El 01/02/2008, a las 11:33, RYUJI WAKIKAWA escribi=F3: > Hi All, > > Thanks for all your comments. I agree with George and see the = > progress. > > I treated this action as a consensus. > We will not include the Ben's solution in the MCoA and leave it to > other work. > > thanks, > ryuji > > > > On 2008/01/31, at 20:08, George Tsirtsis wrote: > >> I am of course also interested in this work. I guess we already have >> enough people to get the ball rolling on this. >> >> Thanks >> George >> >> On Jan 31, 2008 10:59 AM, Suresh Krishnan >> wrote: >>> Hi Marcelo, >>> I am willing to work on a generic MIPv6 threats document along >>> with the other interested people. >>> >>> Cheers >>> Suresh >>> >>> -----Original Message----- >>> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >>> Sent: January 31, 2008 11:13 AM >>> To: Wassim Haddad >>> Cc: Julien Laganier; mext@ietf.org >>> >>> Subject: Re: [MEXT] re-direction attack on MCoA >>> >>> >>> El 30/01/2008, a las 19:16, Wassim Haddad escribi=F3: >>>> >>>> =3D> As there is a clear interest in the redirection attack on the HA >>>> side, I volunteer to do some work on this one. >>>> >>> >>> I think the work should be general to all residual threats on MIP as >>> George mentioned, i think this would be more interesting since it >>> would allow us to put the different threats in perspective and = >>> figure >>> out which ones we should address. >>> >>> >>> >>>> >>>> Regards, >>>> >>>> Wassim H. >>>> >>>> >>>>> El 30/01/2008, a las 18:19, Wassim Haddad escribi=F3: >>>>> >>>>>> Hi Marcelo, >>>>>> IMHO, this topic has to be included as a new item in the new >>>>>> charter and >>>>>> should not be limited to MCoA. >>>>>> Regards, >>>>>> Wassim H. >>>>>> On Wed, 30 Jan 2008, marcelo bagnulo braun wrote: >>>>>>> Pascal, >>>>>>> The question at this point is the following one: do you think >>>>>>> that this threat should be addressed in the MCoA draft itself? >>>>>>> comments? >>>>>>> Regards, marcelo >>>>>>> El 30/01/2008, a las 10:09, Pascal Thubert (pthubert) escribi=F3: >>>>>>>> I agree with Wassim on both mails. >>>>>>>> There's also the situation where the MN/MR might be fooled by >>>>>>>> the >>>>>>>> visited network into believing that the CoA (or its prefix if a >>>>>>>> network >>>>>>>> is attacked as opposed to a host) is on the visited link. DSMIP >>>>>>>> is also >>>>>>>> exposed, in particular with IPv4 CoAs. >>>>>>>> There are many scenarios that do not involve high mobility were >>>>>>>> a 3-way >>>>>>>> or a 4-way handshake could be used to verify the CoA. We have >>>>>>>> proposed >>>>>>>> such a test in section 6 of the RRH draft that uses a triggered >>>>>>>> 2nd BU >>>>>>>> flow to verify the CoA in the first one: >>>>>>>> http://tools.ietf.org/html/draft-thubert-nemo-reverse-routing-head= er-07# >>>>>>>> section-6 >>>>>>>> Pascal >>>>>>>>> -----Original Message----- >>>>>>>>> From: Wassim Haddad [mailto:whaddad@tcs.hut.fi] >>>>>>>>> Sent: mercredi 30 janvier 2008 09:32 >>>>>>>>> To: Benjamin Lim >>>>>>>>> Cc: 'Julien Laganier'; mext@ietf.org >>>>>>>>> Subject: RE: [MEXT] re-direction attack on MCoA >>>>>>>>> On Wed, 30 Jan 2008, Benjamin Lim wrote: >>>>>>>>>> All in all, what I am trying to say is that tracing only >>>>>>>>>> limits the >>>>>>>>>> effect of the attack from escalating further and not >>>>>>>>>> preventing it. >>>>>>>>> =3D> which (again) also perfectly applies to a single CoA. >>>>>>>>> Regards, >>>>>>>>> Wassim H. >>>>>>>>> _______________________________________________ >>>>>>>>> MEXT mailing list >>>>>>>>> MEXT@ietf.org >>>>>>>>> https://www1.ietf.org/mailman/listinfo/mext >>>>>>>> _______________________________________________ >>>>>>>> MEXT mailing list >>>>>>>> MEXT@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/mext >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/mext >>>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mext >>> >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mext >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mext >>> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www1.ietf.org/mailman/listinfo/mext > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From jenn8simply@escortcorp.com Fri Feb 1 09:41:59 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE6953A6932 for ; Fri, 1 Feb 2008 09:41:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 121.54 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=121.54 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_RFC_DSN=1.495, DOS_OE_TO_MX=2.75, GB_ROLEX=5, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DSBL=0.961, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_ROLEX=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 0.7 HOST_EQ_AT HOST_EQ_AT * 1.4 HELO_DYNAMIC_DHCP Relay HELO'd using suspicious hostname (DHCP) * 0.4 HELO_EQ_AT HELO_EQ_AT * 5.0 GB_ROLEX BODY: I don't need a new watch! * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: tankseat.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: tankseat.com] * 10 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist * [URIs: tankseat.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: tankseat.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: tankseat.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: tankseat.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: tankseat.com] * 1.5 DNS_FROM_RFC_DSN RBL: Envelope sender in dsn.rfc-ignorant.org * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [81.10.174.4 listed in dnsbl.sorbs.net] * 1.6 RCVD_IN_NJABL_PROXY RBL: NJABL: sender is an open proxy * [81.10.174.4 listed in combined.njabl.org] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [81.10.174.4 listed in zen.spamhaus.org] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * 1.0 RCVD_IN_DSBL RBL: Received via a relay in list.dsbl.org * [] * 20 URIBL_SBL Contains an URL listed in the SBL blocklist * [URIs: tankseat.com] * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS * 1.7 SARE_SPEC_ROLEX Rolex watch spam * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vg7a2ihMISj7 for ; Fri, 1 Feb 2008 09:41:58 -0800 (PST) Received: from cm174-4.liwest.at (cm174-4.liwest.at [81.10.174.4]) by core3.amsl.com (Postfix) with ESMTP id A86E53A69F1 for ; Fri, 1 Feb 2008 09:41:01 -0800 (PST) Message-ID: <000701c864f9$071d456f$0a43d381@ajtyh> From: "jerold kinson" To: "Terry Otto" Subject: ***SPAM*** 121.54 (5) exclusive watches, lowest prices possible rolex Date: Fri, 01 Feb 2008 15:55:13 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 The finest of luxury timepieces at the LOWEST prices!! http://tankseat.com/ From mext-bounces@ietf.org Fri Feb 1 10:15:15 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9599928C169; Fri, 1 Feb 2008 10:15:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.762 X-Spam-Level: X-Spam-Status: No, score=-3.762 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDZooEDgnCjM; Fri, 1 Feb 2008 10:15:14 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 705103A693A; Fri, 1 Feb 2008 10:15:14 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30F0B3A69B2 for ; Fri, 1 Feb 2008 10:15:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LatYHeQOFF10 for ; Fri, 1 Feb 2008 10:15:12 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 4A8D93A6930 for ; Fri, 1 Feb 2008 10:13:49 -0800 (PST) Received: from chelo-it-uc3m-es.it.uc3m.es (chelo-it-uc3m-es.it.uc3m.es [163.117.139.76])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp02.uc3m.es (Postfix) with ESMTP id A2B822EBD92;Fri, 1 Feb 2008 19:15:23 +0100 (CET) Message-Id: From: marcelo bagnulo braun To: mext@ietf.org Mime-Version: 1.0 (Apple Message framework v915) Date: Fri, 1 Feb 2008 19:15:22 +0100 X-Mailer: Apple Mail (2.915) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-6.9168 TC:1F TRN:10 TV:5.0.1023(15704.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: Julien Laganier Subject: [MEXT] MEXT review of Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, i would like to request feedback from the MEXT community on the following draft Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction draft-ietf-dime-mip6-integrated-07.txt http://tools.ietf.org/html/draft-ietf-dime-mip6-integrated-07 Even though this is not a MEXT document, it is clearly MIP6 related, so it would be important that MEXT WG feel comfortable with it. Thanks, marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From Duston-1odriah@alexdesign.ru Fri Feb 1 10:35:04 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5AB83A699E for ; Fri, 1 Feb 2008 10:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 87.918 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=87.918 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HTML_MESSAGE=1, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d * 0.9 FH_HOST_EQ_D_D_D_DB Host is d-d-d-d * 4.4 HELO_DYNAMIC_IPADDR2 Relay HELO'd using suspicious hostname (IP addr * 2) * 1.6 FH_HELO_EQ_D_D_D_D Helo is d-d-d-d * 1.9 TVD_RCVD_IP TVD_RCVD_IP * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: ghecterosi.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: ghecterosi.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: ghecterosi.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: ghecterosi.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: ghecterosi.com] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * [81.7.86.59 listed in zen.spamhaus.org] * 2.0 FM_DDDD_TIMES_2 Dual helo + host eq d_d_d_d * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BCX-K1ixrMr for ; Fri, 1 Feb 2008 10:35:02 -0800 (PST) Received: from 81-7-86-59.ip.zebra.lt (81-7-86-59.ip.zebra.lt [81.7.86.59]) by core3.amsl.com (Postfix) with ESMTP id 8784E3A69CE for ; Fri, 1 Feb 2008 10:34:19 -0800 (PST) Message-ID: <000901c86501$3e784060$3b560751@SERVERIS> From: "Duston Guzinski" To: nemo-archive@lists.ietf.org Subject: ***SPAM*** 87.918 (5) Your hot dates are set to get HOTTER. Date: Fri, 1 Feb 2008 20:35:39 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0005_01C86512.02011060" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_0005_01C86512.02011060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Amaze your chick with your new legendary manhood. ----------=_NextPart_000_0005_01C86512.02011060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Amaze your chick with your new = legendary=20 manhood. ----------=_NextPart_000_0005_01C86512.02011060-- From SherylburnoutQuick@crengland.com Fri Feb 1 13:05:17 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F5C928C3BE; Fri, 1 Feb 2008 13:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 25.807 X-Spam-Level: ************************* X-Spam-Status: Yes, score=25.807 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_RELAY_NODNS=1.451, FORGED_MUA_OUTLOOK=3.116, HELO_LH_HOME=3.714, INVALID_MSGID=1.9, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 3.7 HELO_LH_HOME HELO_LH_HOME * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 0.0 STOX_REPLY_TYPE STOX_REPLY_TYPE * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [190.24.62.12 listed in dnsbl.sorbs.net] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [190.24.62.12 listed in zen.spamhaus.org] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS * 1.9 INVALID_MSGID Message-Id is not valid, according to RFC 2822 * 3.1 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyIZkxZTpDCV; Fri, 1 Feb 2008 13:05:16 -0800 (PST) Received: from oliver.myhome.westell.com (pool-72-79-201-130.spfdma.east.verizon.net [72.79.201.130]) by core3.amsl.com (Postfix) with SMTP id E33323A68D6; Fri, 1 Feb 2008 13:04:17 -0800 (PST) Message-ID: 24fbe01c86516$399c9c70$2f01a8c0@oliver From: "Natasha Billings" To: Cc: , " X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78B5C28C70C; Sat, 2 Feb 2008 06:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyHfXrr38iJV; Sat, 2 Feb 2008 06:35:21 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C0A928C6EE; Sat, 2 Feb 2008 06:35:21 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BE0128C6F6 for ; Sat, 2 Feb 2008 06:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsKYuZDbAQJW for ; Sat, 2 Feb 2008 06:35:19 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by core3.amsl.com (Postfix) with ESMTP id 55F6E28C6F0 for ; Sat, 2 Feb 2008 06:35:19 -0800 (PST) Received: by an-out-0708.google.com with SMTP id d11so411163and.122 for ; Sat, 02 Feb 2008 06:36:55 -0800 (PST) Received: by 10.100.252.16 with SMTP id z16mr10084336anh.93.1201963015230; Sat, 02 Feb 2008 06:36:55 -0800 (PST) Received: from ?172.16.0.38? ( [200.36.98.226]) by mx.google.com with ESMTPS id c20sm9886556ana.13.2008.02.02.06.36.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 02 Feb 2008 06:36:53 -0800 (PST) Message-ID: <47A48009.4070708@laposte.net> Date: Sat, 02 Feb 2008 15:36:57 +0100 From: Julien Laganier User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: mext@ietf.org, draft-ietf-mext-nemo-v4traversal@tools.ietf.org Cc: Pasi.Eronen@nokia.com Subject: Re: [MEXT] [WGLC] draft-ietf-mext-nemo-v4traversal-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Folks, The WGLC for draft-ietf-mext-nemo-v4traversal-00 has concluded, We received a certain number of comments (Thanks!), most of which are easily fixable it seems. Authors, please address these comments in further revisions of the draft before we sent it to IESG. More substantial are Pasi's concerns on the use of IPsec as specified: 1- lack of detailed descriptions in Section "5.1 Handover interactions for IPsec and IKE" possibly making it difficult for the average implementor to understand what needs to be done. 2- concern about whether the specification is using IPsec or is actually a change to the IPsec architecture. I think Pasi's concerns should be at least discussed before we sent the draft to IESG, so that we can figure out if/how we address them. Thanks. --julien, MEXT co-chair Julien Laganier wrote: > Folks, > > Hereby we're issuing a WGLC for draft-ietf-mext-nemo-v4traversal-00.txt. > > It is a short, one-week WGLC as the document has been previously WGLC'd, > it will last until January 31st. We kindly ask the WG to review the > last changes that were made and provide comments if needed. > > If you have no comments and think the document is ready to be submitted > to IESG, please do send a note stating that to the WG ML. > > Additional information about the document is below: > > Title : Mobile IPv6 support for dual stack Hosts and > Routers (DSMIPv6) > Author(s) : H. Soliman > Filename : draft-ietf-mext-nemo-v4traversal-00.txt > Pages : 29 > Date : 2008-1-23 > > The current Mobile IPv6 and NEMO specifications support IPv6 only. > This specification extends those standards to allow the registration > of IPv4 addresses and prefixes, respectively, and the transport of > both IPv4 and IPv6 packets over the tunnel to the HA. This > specification also allows the Mobile Node to roam over both IPv6 and > IPv4, including the case where Network Address Translation is present > on the path between the mobile node and its home agent. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-v4traversal-00.txt > > Thank you for your support. > > --julien and marcelo, MEXT chairs _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Feb 3 06:59:45 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69CF63A6C7A; Sun, 3 Feb 2008 06:59:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DL6TTi9gnJnO; Sun, 3 Feb 2008 06:59:44 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60BAC3A6C43; Sun, 3 Feb 2008 06:59:44 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E22313A6BD2 for ; Sun, 3 Feb 2008 06:59:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNIjGiX85zrm for ; Sun, 3 Feb 2008 06:59:42 -0800 (PST) Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.90.157]) by core3.amsl.com (Postfix) with SMTP id 99C2C3A6C68 for ; Sun, 3 Feb 2008 06:59:41 -0800 (PST) Received: (qmail 32155 invoked for bounce); 3 Feb 2008 15:01:15 -0000 Received: from unknown (HELO ?192.168.0.2?) (kuntz@unknown) by unknown with RC4-SHA encrypted SMTP; 3 Feb 2008 15:01:15 -0000 Message-Id: <4BA04C8D-C8A6-4DD3-8C87-A263AC23FC3D@clarinet.u-strasbg.fr> From: Romain KUNTZ To: mext@ietf.org In-Reply-To: <47A48009.4070708@laposte.net> Mime-Version: 1.0 (Apple Message framework v915) Date: Sun, 3 Feb 2008 16:01:14 +0100 References: <47A48009.4070708@laposte.net> X-Mailer: Apple Mail (2.915) Subject: Re: [MEXT] [WGLC] draft-ietf-mext-nemo-v4traversal-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, I hope it's not too late for one more comments. I think the document is not very clear about the usage of the v4 prefix allocation to the Mobile Node. Description of the P flag in section 3.1.1 indicates that the MN can request a Mobile Network Prefix. Description of the IPv4 Home Address field states that this prefix can be used to form an IPv4 HoA. So what is the real purpose of this prefix allocation mechanism? Can such prefix be advertised by a mobile router in its mobile network, thus allowing nodes in the mobile network to use IPv4? Regards, -- Romain KUNTZ kuntz@lsiit.u-strasbg.fr Louis Pasteur University - Networks and Protocols Team On 2008/02/02, at 15:36, Julien Laganier wrote: > Folks, > > The WGLC for draft-ietf-mext-nemo-v4traversal-00 has concluded, We > received a certain number of comments (Thanks!), most of which are > easily fixable it seems. Authors, please address these comments in > further revisions of the draft before we sent it to IESG. > > More substantial are Pasi's concerns on the use of IPsec as specified: > > 1- lack of detailed descriptions in Section "5.1 Handover > interactions > for IPsec and IKE" possibly making it difficult for the average > implementor to understand what needs to be done. > > 2- concern about whether the specification is using IPsec or is > actually a change to the IPsec architecture. > > I think Pasi's concerns should be at least discussed before we sent > the > draft to IESG, so that we can figure out if/how we address them. > > Thanks. > > --julien, MEXT co-chair > > Julien Laganier wrote: >> Folks, >> >> Hereby we're issuing a WGLC for draft-ietf-mext-nemo- >> v4traversal-00.txt. >> >> It is a short, one-week WGLC as the document has been previously >> WGLC'd, >> it will last until January 31st. We kindly ask the WG to review the >> last changes that were made and provide comments if needed. >> >> If you have no comments and think the document is ready to be >> submitted >> to IESG, please do send a note stating that to the WG ML. >> >> Additional information about the document is below: >> >> Title : Mobile IPv6 support for dual stack Hosts and >> Routers (DSMIPv6) >> Author(s) : H. Soliman >> Filename : draft-ietf-mext-nemo-v4traversal-00.txt >> Pages : 29 >> Date : 2008-1-23 >> >> The current Mobile IPv6 and NEMO specifications support IPv6 only. >> This specification extends those standards to allow the >> registration >> of IPv4 addresses and prefixes, respectively, and the transport of >> both IPv4 and IPv6 packets over the tunnel to the HA. This >> specification also allows the Mobile Node to roam over both IPv6 >> and >> IPv4, including the case where Network Address Translation is >> present >> on the path between the mobile node and its home agent. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-v4traversal-00.txt >> >> Thank you for your support. >> >> --julien and marcelo, MEXT chairs > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Feb 3 07:09:43 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E23483A6B24; Sun, 3 Feb 2008 07:09:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.846 X-Spam-Level: X-Spam-Status: No, score=-5.846 tagged_above=-999 required=5 tests=[AWL=0.709, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PoumoWJWYRNk; Sun, 3 Feb 2008 07:09:43 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19BE83A6BD2; Sun, 3 Feb 2008 07:09:43 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD2E03A6C3F for ; Sun, 3 Feb 2008 07:09:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2dVJKdwZno6 for ; Sun, 3 Feb 2008 07:09:41 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 81B0B3A6B24 for ; Sun, 3 Feb 2008 07:09:40 -0800 (PST) Received: from [163.117.203.45] (unknown [163.117.203.45])by smtp01.uc3m.es (Postfix) with ESMTP id 9D00636E1F5; Sun, 3 Feb 2008 16:10:57 +0100 (CET) Message-Id: From: marcelo bagnulo braun To: mext@ietf.org Mime-Version: 1.0 (Apple Message framework v915) Date: Sun, 3 Feb 2008 11:31:55 +0100 X-Mailer: Apple Mail (2.915) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-11.5597 TC:1F TRN:21 TV:5.0.1023(15706.001) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: Julien Laganier , Ryuji Wakikawa Subject: [MEXT] WGLC for draft-ietf-monami6-multiplecoa-05.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, With this email we issue the WGLC for draft-ietf-monami6- multiplecoa-05.txt The WGLC will be open till the 11 of february. We kindly ask the WG to review the document and provide comments. Please note that a valid comment at this stage is positive feedback about the document being ready to be shipped. So, please if you think the doc is ready, do express this to the ml (or to the chairs) For you convenience, additional information about the document: Title : Multiple Care-of Addresses Registration Author(s) : R. Wakikawa, et al. Filename : draft-ietf-monami6-multiplecoa-05.txt Pages : 44 Date : 2008-01-27 http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-05.txt Thanks, Julien and marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Feb 4 01:33:05 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B5053A6E59; Mon, 4 Feb 2008 01:33:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Cd6RYWGrGa7; Mon, 4 Feb 2008 01:33:04 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43E9B3A6E33; Mon, 4 Feb 2008 01:33:04 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECA093A6E25 for ; Mon, 4 Feb 2008 01:33:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHAS0bar6InC for ; Mon, 4 Feb 2008 01:33:03 -0800 (PST) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.225]) by core3.amsl.com (Postfix) with ESMTP id B91603A6E2B for ; Mon, 4 Feb 2008 01:33:02 -0800 (PST) Received: by wx-out-0506.google.com with SMTP id s8so1974713wxc.31 for ; Mon, 04 Feb 2008 01:34:36 -0800 (PST) Received: by 10.142.88.20 with SMTP id l20mr3235536wfb.72.1202117675618; Mon, 04 Feb 2008 01:34:35 -0800 (PST) Received: by 10.142.11.11 with HTTP; Mon, 4 Feb 2008 01:34:35 -0800 (PST) Message-ID: Date: Mon, 4 Feb 2008 09:34:35 +0000 From: "George Tsirtsis" To: "Romain KUNTZ" In-Reply-To: <4BA04C8D-C8A6-4DD3-8C87-A263AC23FC3D@clarinet.u-strasbg.fr> MIME-Version: 1.0 Content-Disposition: inline References: <47A48009.4070708@laposte.net> <4BA04C8D-C8A6-4DD3-8C87-A263AC23FC3D@clarinet.u-strasbg.fr> Cc: mext@ietf.org Subject: Re: [MEXT] [WGLC] draft-ietf-mext-nemo-v4traversal-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org The Ipv4 addresses and prefixes in DSMIPv6 are in addition to at least an IPv6 HoA. Because of this, the MN does not have to have an IPv4 HoA. Instead it can have one or more prefixes which it can either consume itself or it can use to allocate to other attached nodes in a NEMO configuration (e.g., via DHCP) or other configurations. In any case, as long as the behavior of the HA and the MN is clear over the DSMIPv6 protocol, we should not be too prescriptive on what these addresses are to be used for. So, the text in the draft, while correct, it could be improved a bit for the non-expert reader, as follows. Modified text marked by "|" on its left side: IPv4 home address The mobile node's IPv4 home address that should be defended by the home agent. This field could contain any unicast IPv4 address (public or private) that was assigned to the mobile node. The value 0.0.0.0 is used to request an IPv4 home address from the home agent. A mobile node may choose to use this option to request a prefix by setting the address to the All Zeroes and setting the P flag. The mobile node could then form an IPv4 home address based on the | allocated prefix or it can use it to address other nodes | attached to it. Alternatively, the mobile node | may use a combination of options, for | requesting static and/or dynamic address(es) and prefix(es) | as required. George On Feb 3, 2008 3:01 PM, Romain KUNTZ wrote: > Hi, > > I hope it's not too late for one more comments. > > I think the document is not very clear about the usage of the v4 > prefix allocation to the Mobile Node. Description of the P flag in > section 3.1.1 indicates that the MN can request a Mobile Network > Prefix. Description of the IPv4 Home Address field states that this > prefix can be used to form an IPv4 HoA. So what is the real purpose of > this prefix allocation mechanism? Can such prefix be advertised by a > mobile router in its mobile network, thus allowing nodes in the mobile > network to use IPv4? > > Regards, > -- > Romain KUNTZ > kuntz@lsiit.u-strasbg.fr > Louis Pasteur University - Networks and Protocols Team > > > > > On 2008/02/02, at 15:36, Julien Laganier wrote: > > > Folks, > > > > The WGLC for draft-ietf-mext-nemo-v4traversal-00 has concluded, We > > received a certain number of comments (Thanks!), most of which are > > easily fixable it seems. Authors, please address these comments in > > further revisions of the draft before we sent it to IESG. > > > > More substantial are Pasi's concerns on the use of IPsec as specified: > > > > 1- lack of detailed descriptions in Section "5.1 Handover > > interactions > > for IPsec and IKE" possibly making it difficult for the average > > implementor to understand what needs to be done. > > > > 2- concern about whether the specification is using IPsec or is > > actually a change to the IPsec architecture. > > > > I think Pasi's concerns should be at least discussed before we sent > > the > > draft to IESG, so that we can figure out if/how we address them. > > > > Thanks. > > > > --julien, MEXT co-chair > > > > Julien Laganier wrote: > >> Folks, > >> > >> Hereby we're issuing a WGLC for draft-ietf-mext-nemo- > >> v4traversal-00.txt. > >> > >> It is a short, one-week WGLC as the document has been previously > >> WGLC'd, > >> it will last until January 31st. We kindly ask the WG to review the > >> last changes that were made and provide comments if needed. > >> > >> If you have no comments and think the document is ready to be > >> submitted > >> to IESG, please do send a note stating that to the WG ML. > >> > >> Additional information about the document is below: > >> > >> Title : Mobile IPv6 support for dual stack Hosts and > >> Routers (DSMIPv6) > >> Author(s) : H. Soliman > >> Filename : draft-ietf-mext-nemo-v4traversal-00.txt > >> Pages : 29 > >> Date : 2008-1-23 > >> > >> The current Mobile IPv6 and NEMO specifications support IPv6 only. > >> This specification extends those standards to allow the > >> registration > >> of IPv4 addresses and prefixes, respectively, and the transport of > >> both IPv4 and IPv6 packets over the tunnel to the HA. This > >> specification also allows the Mobile Node to roam over both IPv6 > >> and > >> IPv4, including the case where Network Address Translation is > >> present > >> on the path between the mobile node and its home agent. > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-v4traversal-00.txt > >> > >> Thank you for your support. > >> > >> --julien and marcelo, MEXT chairs > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > http://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From message@eBay.com Tue Feb 5 10:34:00 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id F0CF63A7484; Tue, 5 Feb 2008 10:52:55 -0800 (PST) Received: from pr-server.pr-domain.local (mail.professionalrepro.com [74.0.248.195]) by mail.ietf.org (Postfix) with ESMTP id 355833A7E0F; Mon, 4 Feb 2008 18:48:43 -0800 (PST) Received: from User ([62.38.143.62]) by pr-server.pr-domain.local with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Feb 2008 21:56:53 -0500 From: "eBay" Subject: Message from ebay memeber Date: Tue, 5 Feb 2008 04:50:14 +0200 MIME-Version: 1.0 Content-Type: text/html; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 05 Feb 2008 02:56:54.0187 (UTC) FILETIME=[C37867B0:01C867A2] To: undisclosed-recipients:;

Unpaid Item Message from OpreansiRobotu-: #311117921711 -- response required


Dear member,

ebay co. member nascar-stuff- has left you a message regarding item #311117921711

View the dispute thread to respond..

Regards,

eBay

From jr@proactivenet.com Tue Feb 5 10:36:58 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id A7B7B3A8353; Tue, 5 Feb 2008 10:52:58 -0800 (PST) Received: from anent.com (unknown [203.90.41.109]) by mail.ietf.org (Postfix) with SMTP id 80E803A950A for ; Tue, 5 Feb 2008 02:25:44 -0800 (PST) Received: from 209.10.202.218 (HELO warpdrive.proactivenet.com) by ietf.org with esmtp (KGLZTTNIR JALNB) id NP6cQD-7qVMqr-GP for nemo-archive@ietf.org; Tue, 05 Feb 2008 19:27:23 +0900 Message-ID: <7a9e01c867e1$b262a190$cb5a296d@Madeline> From: "Madeline Frey" To: "Sheri Kaiser" Subject: Pleasure all women with the size of your instrument. Date: Tue, 05 Feb 2008 19:27:23 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_31388_7B06_01C8682D.224A4990" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 This is a multi-part message in MIME format. ------=_NextPart_31388_7B06_01C8682D.224A4990 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable In just a few short weeks, you`ll watch with amazement=20 as your phallus grows into the thickest, biggest, hardest, and most power= ful tool=20 you`ve ever imagined - the one you`ve always dreamed about=20 having! No pen!s en`l@rgement system is faster, easier to use, or=20 more effective than VPXL+ - FOREVER}! VPXL+ IS GUARANTEED TO EN`L@RGE & STRENGTHEN YOUR=20 PHALLUS OR YOUR MONEY BACK - PERIOD! SO WHY WAIT? GET=20 VPXL+ AND LIVE LARGE TODAY! CHECK THIS OFFER TO SUBSTANTIALLY IMPROVE YOUR MALE PACKAGE IN THIS YEAR!= http://nbnibsee=2Ecom/ hostageemail communications; if we lived in a country thatinformation to = add to this news event, click the "edit their nerve to scrape home by one wicket=2EThe bus has been surrounded by= armed Filipino police, ------=_NextPart_31388_7B06_01C8682D.224A4990 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
#1 DOCTOR RECOMMENDED PEN|S= EN'L@RGEMENT PREPARATION!

In just= a few short weeks,=20 you`ll watch with amazement as your phallus
grows into the thickest, = biggest, hardest, and most powerful tool
you`ve ever imagined - the one you`ve always dreamed about
having! No= pen!s en`l@rgement=20 system is faster, easier to use, or
more effective than VPXL+= - FOREVER!

VPXL+ IS=20 GUARANTEED TO EN`L@RGE & STRENGTHEN YOUR
PH= ALLUS OR=20 YOUR MONEY BACK - PERIOD! SO WHY WAIT? GET
VPXL+ AND LIVE LARG= E TODAY!

CHECK THIS OFFER TO SUBSTANTIALLY= IMPROVE YOUR MALE PACKAGE IN THIS YEAR!



soldiers were in Iranian waters at the time of theirUEFA Euro 200= 8: March 28th qualification game roundup
day included Italy taking on Scotland, and Swedenhostage
email communi= cations; if we lived in a country thatinformation to add to this news eve= nt, click the "edit
their nerve to scrape home by one wicket=2EThe bus= has been surrounded by armed Filipino police, ------=_NextPart_31388_7B06_01C8682D.224A4990-- From email.eii@hinet.net Tue Feb 5 10:37:55 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 1A4743A7FB1; Tue, 5 Feb 2008 10:53:00 -0800 (PST) Received: from hinet.net (122-123-150-225.dynamic.hinet.net [122.123.150.225]) by mail.ietf.org (Postfix) with SMTP id A34723A92BA; Tue, 5 Feb 2008 01:51:08 -0800 (PST) Received: from qrx.quickslick.com [202.235.62.228] by group21.345mail.com with ASMTP; Tue, 05 Feb 2008 02:36:38 -0800 Received: from [62.4.47.79] by external.newsubdomain.com with QMQP; Tue, 05 Feb 2008 02:34:59 -0800 Received: from mx.reskind.net ([Tue, 05 Feb 2008 02:27:52 -0800]) by smtp.mixedthings.net with NNFMP; Tue, 05 Feb 2008 02:27:52 -0800 Received: from [178.51.154.68] by mxs.perenter.com with ESMTP; Tue, 05 Feb 2008 02:19:04 -0800 Received: from mxs.perenter.com ([4.161.36.101]) by smtp.doneohx.com with SMTP; Tue, 05 Feb 2008 02:13:02 -0800 Message-ID: Date: Tue, 05 Feb 2008 02:12:50 -0800 Reply-To: "Klaus" From: "Klaus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us MIME-Version: 1.0 To: "Henrik" Subject: Eine Empfehlung von Klaus Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hallo Henrik! Ich habe eine super Seite entdeckt, wo man ganz einfach einen Seitensprung Partner finden kann. Ich habe mir gerade mein Passwort angefordert und kann die Seite nur weiterempfehlen. Echt eine super Sache! Schau einfach auch mal vorbei: http://www.onlineseitensprung2.tk/ Viele Grüße Klaus ------------------------------------------------------------------------ Diese ePost wurde versendet von: Klaus (email.eii@hinet.net) From RickeyemulsionTate@greatdreams.com Tue Feb 5 10:38:13 2008 Return-Path: X-Original-To: nemo-archive@lists.ietf.org Delivered-To: ietfarch-nemo-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 359333A983A; Tue, 5 Feb 2008 10:52:48 -0800 (PST) Received: from mardekor6c5be5.netvisao.pt (unknown [217.129.140.222]) by mail.ietf.org (Postfix) with SMTP id B97293A7782; Mon, 4 Feb 2008 16:21:10 -0800 (PST) Received: from barton by greatdreams.com with SMTP id ATt4eaZIdb for ; Tue, 5 Feb 2008 00:19:57 +0000 From: "Preston Santos" To: Cc: , Date: Mon, 4 Feb 2008 16:21:10 -0800 (PST) Travel no further than your screen and get your free $2400 Get $2400 you download our casino. Get to know your new casino home! Play your favorite games and get $2400 welcome bonus. http://bearte.net.cn/ From jqsvd@hofstra.edu Tue Feb 5 10:39:34 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 5E75C3A8366; Tue, 5 Feb 2008 10:52:50 -0800 (PST) Received: from co.durham.nc.us (unknown [124.157.227.116]) by mail.ietf.org (Postfix) with SMTP id 693DE3A8BBB for ; Mon, 4 Feb 2008 23:18:40 -0800 (PST) Received: from 147.4.4.101 (HELO prfpnt1.hofstra.edu) by ietf.org with esmtp (IAEYTSOECP UUAML) id 25sf2L-V7nFPa-w6 for nemo-archive@ietf.org; Sun, 03 Feb 2008 14:24:07 +0700 Message-ID: <000301c86635$c30e8e30$c0a801cb@Jenifer> From: "Jenifer X. Devine" To: "Leola B. Kyle" Subject: Nice gifts for your dearest people on holidays! Date: Sun, 03 Feb 2008 14:24:07 +0700 MIME-Version: 1.0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable


-------------------------------------------
EMAIL ID: PeS0q From gudrun-r`enivar@220vat.ru Tue Feb 5 10:43:23 2008 Return-Path: X-Original-To: nemo-archive@lists.ietf.org Delivered-To: ietfarch-nemo-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 903F03A6820; Tue, 5 Feb 2008 10:52:58 -0800 (PST) Received: from [80.54.4.107] (unknown [80.54.4.107]) by mail.ietf.org (Postfix) with ESMTP id 828D928C9B8 for ; Tue, 5 Feb 2008 06:04:32 -0800 (PST) Message-ID: <001201c86800$39dfb4f0$6b043650@aaac982ab72368> From: "gudrun rabena" To: nemo-archive@lists.ietf.org Subject: Don't disappoint your Valentine's Day date Get your enlargement pills today Date: Tue, 5 Feb 2008 15:05:56 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000E_01C86808.9BA41CF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_000E_01C86808.9BA41CF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Take this c0ck enlargement pill only if you want to attract the best = women ----------=_NextPart_000_000E_01C86808.9BA41CF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Take this c0ck enlargement pill = only if you=20 want to attract the best women ----------=_NextPart_000_000E_01C86808.9BA41CF0-- From lucindaserranoqq@mb.infoweb.ne.jp Tue Feb 5 10:44:22 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id D4A8F3A7D28; Tue, 5 Feb 2008 10:52:54 -0800 (PST) Received: from tin.it (unknown [211.147.247.199]) by mail.ietf.org (Postfix) with ESMTP id 1C0F928D5FB; Tue, 5 Feb 2008 08:48:57 -0800 (PST) Subject: Do you want enlarge your penis? t75rrw To: nemo@ietf.org, nemo-archive@ietf.org, nsis@ietf.org, nsis-bounces@ietf.org, nsis-request@ietf.org, pana-bounces@ietf.org, pana-request@ietf.org, pce@ietf.org MIME-Version: 1.0 Message-ID: <1202230350.8886@mb.infoweb.ne.jp> Date: Tue, 05 Feb 2008 16:52:30 +0000 From: "Lucinda Serrano" Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit Dear nemo@ietf.org http://cvoaccess.com A breakthrough in herbal Science has created a pill that has been designed specifically for penis enlargement. The tests that took place over a 6 month period showed that out of the 5,000 Males from around the world who participated, the average gain after 5 months of taking ManSter pills was 3.02 Inches! Amazing, PERMANENT RESULTS that will last. » Gain 3+ Inches In Length. » Increase Your Penis Width (Girth) By upto 20%. http://cvoaccess.com Thanks Ann Cassidy nemo@ietf.org wrote: > Add up to 4 inches to yours penis gxmo8ls3y8- out me now http://cvoaccess.com/w.php From _dioraps@BeautyBound.com Tue Feb 5 10:46:22 2008 Return-Path: <_dioraps@BeautyBound.com> X-Original-To: nemo-archive@lists.ietf.org Delivered-To: ietfarch-nemo-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 5F3853A7415; Tue, 5 Feb 2008 10:37:49 -0800 (PST) Received: from host166-108-static.29-87-b.business.telecomitalia.it (host166-108-static.29-87-b.business.telecomitalia.it [87.29.108.166]) by mail.ietf.org (Postfix) with ESMTP id 1BA403A8291 for ; Mon, 4 Feb 2008 20:08:49 -0800 (PST) Message-ID: <001001c867ad$05108130$a66c1d57@luca> From: "fahri Korolov" <_dioraps@BeautyBound.com> To: nemo-archive@lists.ietf.org Subject: Life will never be the same again once you click here. Date: Tue, 5 Feb 2008 05:10:19 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000C_01C867B5.66D4E930" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_000C_01C867B5.66D4E930 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Never hear a single complaint about your small weener ever again. ----------=_NextPart_000_000C_01C867B5.66D4E930 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Never hear a single complaint about = your=20 small weener ever again. ----------=_NextPart_000_000C_01C867B5.66D4E930-- From NedsecreteHardin@gotgtek.com Tue Feb 5 10:46:48 2008 Return-Path: X-Original-To: nemo-archive@lists.ietf.org Delivered-To: ietfarch-nemo-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 5AA2A3A70E6; Tue, 5 Feb 2008 10:37:57 -0800 (PST) Received: from pc1b1ea4322b3b.hsd1.in.comcast.net (c-67-174-90-111.hsd1.in.comcast.net [67.174.90.111]) by mail.ietf.org (Postfix) with SMTP id A603D3A7DA3; Mon, 4 Feb 2008 18:42:31 -0800 (PST) Received: from slang by gotgtek.com with SMTP id jyGi0MLmJ8 for ; Mon, 4 Feb 2008 21:42:39 +0500 From: "Reggie Montoya" To: , Date: Mon, 4 Feb 2008 18:42:31 -0800 (PST) Our casino is for you and everyone else who likes to win! We pay you to play. USA players too! Download and GO! Come find out. http://beartf.com.cn/ From jr@proactivenet.com Tue Feb 5 10:47:15 2008 Return-Path: X-Original-To: nemo-archive@lists.ietf.org Delivered-To: ietfarch-nemo-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 63E6B3A761C; Tue, 5 Feb 2008 10:37:54 -0800 (PST) Received: from anent.com (unknown [80.85.177.140]) by mail.ietf.org (Postfix) with SMTP id EF5DC3A8FF6 for ; Tue, 5 Feb 2008 00:50:35 -0800 (PST) Received: from 209.10.202.218 (HELO warpdrive.proactivenet.com) by lists.ietf.org with esmtp (DSAUGJQGAV TBBXIV) id 0BCIE5-pYIXLd-xB for nemo-archive@lists.ietf.org; Tue, 05 Feb 2008 12:52:13 +0400 Message-ID: <000301c867d4$66fc2f30$c0a8040c@Austin> From: "Austin V. Pearson" To: "Jean A. Holland" Subject: Stylish presents for your loved ones! Date: Tue, 05 Feb 2008 12:52:13 +0400 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


__________________________________
EMAIL ID: wsL2x From philippe.caboche@cwslaw.com Tue Feb 5 10:47:25 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id E204E3A6E3D; Tue, 5 Feb 2008 10:52:48 -0800 (PST) Received: from oh-74-5-159-170.dhcp.embarqhsd.net (oh-74-5-159-170.dhcp.embarqhsd.net [74.5.159.170]) by mail.ietf.org (Postfix) with SMTP id B5D423A8432 for ; Mon, 4 Feb 2008 20:48:18 -0800 (PST) Received: from hkcy ([94.127.31.35]) by oh-74-5-159-170.dhcp.embarqhsd.net (8.13.5/8.13.5) with SMTP id m154sjEd057997; Mon, 4 Feb 2008 23:54:45 -0500 Message-ID: <002201c867b2$8a80de00$231f7f5e@hkcy> From: To: Subject: A brand new large baby-maker! Date: Mon, 4 Feb 2008 23:49:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Best prices for blue-pill! http://oxr.speakpound.com From maadler@bordersgroupinc.com Tue Feb 5 10:53:21 2008 Return-Path: X-Original-To: nemo-archive@lists.ietf.org Delivered-To: ietfarch-nemo-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 698D53A75F6; Tue, 5 Feb 2008 10:37:53 -0800 (PST) Received: from c3-host107.eso-es.net (c3-host107.eso-es.net [88.255.61.107]) by mail.ietf.org (Postfix) with SMTP id 33DFC28D716 for ; Tue, 5 Feb 2008 09:09:12 -0800 (PST) Received: from dudck ([150.180.135.126]) by c3-host107.eso-es.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Feb 2008 19:10:41 +0200 Message-ID: <47A89891.7020803@bordersgroupinc.com> Date: Tue, 5 Feb 2008 19:10:41 +0200 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: Our Journey Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit A Token of My Love http://208.106.64.165/ From jrader@faculty.ed.umuc.edu Tue Feb 5 10:56:20 2008 Return-Path: X-Original-To: nemo-archive@lists.ietf.org Delivered-To: ietfarch-nemo-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id D75883A7B94; Tue, 5 Feb 2008 10:52:56 -0800 (PST) Received: from h-192-55.A148.cust.bahnhof.se (h-192-55.A148.cust.bahnhof.se [81.170.192.55]) by mail.ietf.org (Postfix) with SMTP id 3419D3A91E4 for ; Tue, 5 Feb 2008 01:32:50 -0800 (PST) Received: from 195.127.52.27 (HELO thor.ed.umuc.edu) by lists.ietf.org with esmtp (SOFYOCIACQH JPJBEM) id V3IF5o-wiWTvU-r for nemo-archive@lists.ietf.org; Tue, 05 Feb 2008 10:34:39 +0100 Message-ID: <000301c867da$54217770$37c0aa51@Joan> From: "Joan D. Shirley" To: "Carmen C. Kendall" Subject: Nice gifts for your dearest people on holidays! Date: Tue, 05 Feb 2008 10:34:39 +0100 MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable


------------------------------------------------------------
EMAIL ID: 0LzXx From noorazlina_ashaari@ruh-bath.swest.nhs.uk Tue Feb 5 10:59:29 2008 Return-Path: X-Original-To: nemo-archive@ietf.org Delivered-To: ietfarch-nemo-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 629223A6C8F; Tue, 5 Feb 2008 10:52:49 -0800 (PST) Received: from 216-206-31-2.dia.static.qwest.net (216-206-31-2.dia.static.qwest.net [216.206.31.2]) by mail.ietf.org (Postfix) with SMTP id B7A083A99C2 for ; Tue, 5 Feb 2008 03:16:24 -0800 (PST) Received: (qmail 12186 invoked from network); Tue, 5 Feb 2008 05:13:11 -0600 Received: from unknown (HELO yish) (127.217.220.105) by 216-206-31-2.dia.static.qwest.net with SMTP; Tue, 5 Feb 2008 05:13:11 -0600 Message-ID: <47A844C7.7060303@ruh-bath.swest.nhs.uk> Date: Tue, 5 Feb 2008 05:13:11 -0600 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: nemo-archive@ietf.org Subject: Sending You All My Love Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The Mood for Love http://99.129.205.112/ From RyanbootlegMurphy@hotelgeorge.com Tue Feb 5 11:01:58 2008 Return-Path: X-Original-To: nemo-archive@lists.ietf.org Delivered-To: ietfarch-nemo-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 0E8E33A816E; Tue, 5 Feb 2008 10:52:52 -0800 (PST) Received: from abdi.domain.actdsltmp (207-109-2-80.mpls.qwest.net [207.109.2.80]) by mail.ietf.org (Postfix) with SMTP id 6A64428CC49; Tue, 5 Feb 2008 06:34:52 -0800 (PST) Message-ID: <09c901c86804$787c5070$0200a8c0@abdi> From: "Samuel Reed" To: , =20
If you have your own = business and=20 require IMMEDIATE ready money to spend ANY way you like or wish Extra = money to=20 give your business a boost or require A low interest loan - NO = STRINGS=20 ATTACHED!
=20
Do not worry about = approval... your=20 credit score will not disqualify you!
=20
http://beartd.com.cn/
------=_NextPart_000_09C5_01C86804.787C5070-- From NicolesalonChildress@twit.tv Tue Feb 5 11:04:04 2008 Return-Path: X-Original-To: nemo-archive@lists.ietf.org Delivered-To: ietfarch-nemo-archive@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id EEBB83A67B3; Tue, 5 Feb 2008 10:38:05 -0800 (PST) Received: from d2g93s61.stjoseph.mo.npgco.com (cm-24-121-69-237.stjoseph.mo.npgco.com [24.121.69.237]) by mail.ietf.org (Postfix) with SMTP id 0BCA03A8805; Mon, 4 Feb 2008 22:19:37 -0800 (PST) Message-ID: <807eb01c867bf$4aca5e50$ed457918@D2G93S61> From: "Judith Walden" To: Subject: Business Financing Date: Tue, 5 Feb 2008 00:17:52 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_807E7_01C867BF.4ACA5E50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_807E7_01C867BF.4ACA5E50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you have your own business and wish IMMEDIATE ready money to spend = ANY way you like or require Extra money to give your business a boost or = want A low interest loan - NO STRINGS ATTACHED! Do not worry about approval... your credit will not disqualify you! http://beartc.cn/ ------=_NextPart_000_807E7_01C867BF.4ACA5E50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20
If you have your own = business and=20 wish IMMEDIATE ready money to spend ANY way you like or want Extra money = to=20 give the business a boost or wish A low interest loan - NO STRINGS=20 ATTACHED!
=20
Do not worry about = approval... your=20 credit score will not disqualify you!
=20
http://beartc.cn/
------=_NextPart_000_807E7_01C867BF.4ACA5E50-- From mext-bounces@ietf.org Tue Feb 5 14:38:24 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 428493A7BC8; Tue, 5 Feb 2008 14:38:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrGMvbiz5ila; Tue, 5 Feb 2008 14:38:23 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E77943A7F1F; Tue, 5 Feb 2008 14:20:51 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BFE53A7969 for ; Tue, 5 Feb 2008 14:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+OheDXYNVp0 for ; Tue, 5 Feb 2008 14:20:49 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id AF0153A86E0 for ; Tue, 5 Feb 2008 13:56:04 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id C58452C000357; Tue, 5 Feb 2008 22:57:36 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gxPu9gbofzW; Tue, 5 Feb 2008 22:57:36 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id A82B12C000355; Tue, 5 Feb 2008 22:57:26 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Feb 2008 22:55:35 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF4D0644@mx1.office> In-Reply-To: <99FE0422-FDAD-4721-941B-2C50905E8162@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: few questions about draft-baldessari-c2ccc-nemo-req-01 Thread-Index: AchoK+cv4PtUV6RXRqqtvQr09UfZXQAAl2Mg From: "Roberto Baldessari" To: "marcelo bagnulo braun" Cc: mext@ietf.org Subject: Re: [MEXT] few questions about draft-baldessari-c2ccc-nemo-req-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Marcelo, thanks for the comments, please see inline > > Hi, > > i have been reading this document and the first question that > i have is that if i understood correctly, the main scope of > the usage of nemo in this scenario is for non safety > communications with any arbitrary node in the Internet, right? > Not only. NEMO in C2C is meant to be used to talk either to an arbitrary node in the Internet or to a newly deployed node for automotive applications. > If that is the case, i think it is kind of strange that the > use case considered in section 5 which mainly focused in the > conept of CR: > > The requirements defined in this document refer to RO between MR and > CR (Correspondent Router). According to C2C-CC use > cases, the CR can > be: > > o a NEMO MR. For example the MR running on another vehicle or > another mobile device connected to the Internet; > > o a RO-enabled router, i.e. a router static or mobile > that does not > act as NEMO MR but is capable of establishing RO sessions with > NEMO MRs. For example the access router serving a CN in the > infrastructure that offers services to vehicles, or the access > router serving RSUs installed along the road; > > I think this kind of assumes a solution, i.e. the existance > of a CR, which does not exists today. I guess that if the > goal of the usage of nemo is mainly communications with node > in the internet, the makor usage case would be to talk with > any CN, rather than to a CR. > Right, this usage of the term CR is not clear and probably breaks RFC 4885. This was already pointed out at IETF-69 (no new version has been submitted since then). I proposed to change CR into CE. And CE can be one of these: 1) a NEMO MR 2) a router (not a MR) implementing NEMO RO 3) a CN, i.e. IPv6 host 4) a MIPv6 CN What do you think? BTW Regarding solution space, we did not want to restrict it but on the contrary make it wider (in the bullet you omitted from the above text, we wrote that a CR can be "a RO-enabled router collapsed into the CN") > Next, in section > > 6.3. Req 3 - RO Security > > > A RO technique MUST prevent malicious nodes to claim false MNP > ownership. In order to achieve this, a RO technique MAY > make use of > security features provided by the sub-IPv6 C2C-CC Network > layer (e.g. > cryptographic protection), but it MUST NOT introduce new security > leaks for the C2C-CC applications or render their > security measures > ineffective. > > I fail to understand this one. > first, as i understand it, the goal is to run ro between > nodes in the nemo and any node in the internet. In this case, > it seems hardly useful to use the C2C network interface, > since i doesn't seems that any node in the internet will use > the C2C network layer. A similar comment was made during IETF-69. We will remove in the next version references to C2C-CC security features wrt to this requirement. So we will keep only the first sentence of the req. The background of this text was that C2C is going anyway to implement security features probably based on certificates issued by a CA. We thought that RO security might take advantage of this in the case of MR-MR via 802.11p (excluding the MR-CN and the WLAN cases). But it doesn't seem possible as it is a too particular case. > Moreover, if i udnerstood correctly, > the IPv6 layer can use directly the WLAN interface in the > vehicle so, we cannot rely on the C2C network layer since it > may not be ther. > See previous comment. > With respect to: > > 6.5. Req 5 - Multihoming > > Do you need to support multiple MRs in the same nemo? it > seems you don't because you seem to assume a single OBU, right? > Right. 1 OBU per vehicle is the C2C-CC approach. > I guess that the OBU may have multiple technologies, but it > deosn't seem to me that the nemo RO for non safety > application will be able to use them, so it seems that the > OBU for non safety usage will only be able to use the WLAN, > so, how come that multihoming is needed? I mean, you have a > single MR and you have a single technology, i guess that the > possibility is that you will be attached to different WLAN > simoultaneously? is that the scenario that you have in nmind? No. In the protocol stack depicted in the draft (Figure 2), IPv6 is used over C2C-CC NET/11p and over WLAN. So, a node has 2 IPv6 interfaces (one virtual, one real). This is already a possibly multihomed MR (i.e. if the MR is attached to a 802.11p RSU and a public WLAN hotspot). Additional technologies that are not in the current focus of C2C-CC might come later (e.g. 3G). This is why RO must be compatible with multihoming. > Moreover, are you considering the case with multiple HAs? > Multiple HAs is not currently a priority for C2C. Reallocating HAs has benefits but having a standard RO solution that works even with 1 HA should come first. Best regards, Roberto _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Feb 6 01:55:03 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E34A73A6C24; Wed, 6 Feb 2008 01:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.415 X-Spam-Level: X-Spam-Status: No, score=0.415 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_40=-0.185, J_CHICKENPOX_13=0.6] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3wfxIqfoI0x; Wed, 6 Feb 2008 01:55:02 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 217B83A6C30; Wed, 6 Feb 2008 01:55:02 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30FF43A6C0D for ; Wed, 6 Feb 2008 01:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTeA3oM3l7rL for ; Wed, 6 Feb 2008 01:54:59 -0800 (PST) Received: from omta01sl.mx.bigpond.com (omta01sl.mx.bigpond.com [144.140.92.153]) by core3.amsl.com (Postfix) with ESMTP id 456BA3A6A1E for ; Wed, 6 Feb 2008 01:54:58 -0800 (PST) Received: from oaamta04sl.mx.bigpond.com ([124.190.105.201]) by omta01sl.mx.bigpond.com with ESMTP id <20080206095628.YFFU6603.omta01sl.mx.bigpond.com@oaamta04sl.mx.bigpond.com> for ; Wed, 6 Feb 2008 09:56:28 +0000 Received: from PC20005 ([124.190.105.201]) by oaamta04sl.mx.bigpond.com with ESMTP id <20080206095626.ZWPC17660.oaamta04sl.mx.bigpond.com@PC20005>; Wed, 6 Feb 2008 09:56:26 +0000 From: "Hesham Soliman" To: , Date: Wed, 6 Feb 2008 20:56:02 +1000 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AchjOp+tBBZPPj39Q6+7x6ZGZVfkIgFco+Gw In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A010202.47A9844C.0096,ss=1,fgs=0 Subject: Re: [MEXT] IPsec use in draft-ietf-mext-nemo-v4traversal-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Pasi, Thanks for the comments. The comments in the other email will be handled in the next rev. Regarding these comments please see my response below. > I do not think the spec is ready to be submitted to IESG without > non-trivial work on the IPsec aspects. > > My main concerns are the following: > > First, while the basic idea behind the DSMIPv6-IPsec interaction > seems doable, I am not convinced that an average implementor (i.e., > someone who hasn't participated in writing this specification and > doesn't have a PhD) could actually figure out how it works based on > the current text. I would strongly suggest expanding the > description in Section 5.1, and including e.g. message diagrams > showing in what order the various local state updates and messages > have to happen. In the off-list discussions thinking how to > use IPsec, both Karen and I wrote such descriptions; merging > them (and updating the details to match the latest discussions) > could be a good starting point. I'm including my notes (which > may not be fully up-to-date) at the end of this message; feel > free to use them and/or Karen's text as starting points. => This is what I tried to do already. I haven't received comments from Karen or Christian indicating dissatisfaction (not yet anyway). The issue here is how much implementation detail should we include without crossing the barrier from specification to implementation. As I mentioned in the private discussions I'd like the reader to know *what* needs to be done, but not necessarily *how* to do it. So, if you think the order of events is not clear, please give me some specific changes to make it clearer. The issue of message diagrams is not really the key point IMO, as I think any implementer knows the messages exchanged. I believe what we want to show is what happens when. > > Second, in places, the spec is close to the line drawn in water > between using IPsec and actually changing the IPsec architecture. > In particular, there are architectural details related to NATs that > AFAIK are not present in any other use of IPsec (including plain > Mobile IPv6). For example, > > - On MN side, it's assumed that after IPsec processing, some > packets (in particular, BUs) are *not* processed as usual via IP > forwarding, but are rather handed back to "DSMIPv6" code for > special encapsulation. In other words, the treatment in IP > forwarding ("Forwarding" box in RFC 4301, Section 5.1) depends on > something else than the destination address, and more importantly, > on something that isn't visible in the packet itself (after it has > been encrypted) but is expected to survive IPsec processing. => MIPv6 does similar things architecturally anyway, like swapping the home address with the content of the HAO. So, the idea of the packet returning to the "calling function" to do things to it before sending is not new. > > - On HA side, it's assumed that IPsec processing doesn't just > decrypt the packet (and hand it over to IP forwarding), but also > somehow preserves DSMIPv6-specific information (in particular, > the IP address/port in the outermost IPv4 header) across the > IPsec processing and eventually to the module processing BUs. => Correct. We could have avoided this using other alternatives but there was no concensus. This is one of those issues that are implementation dependent. Again the "calling function" could preserve this information without relying on IPsec to do so. Hence, there is no need to change IPsec architecture or implementation. When I worked on MIPv6 implementations it was not difficult to pass additional information around with the packet. May be things changed now :) > > While these can certainly be implemented, they are architecturally > ugly, and may prevent using existing IPsec implementations as-is. > I'm not sure if we can avoid this (many other solutions for > IPsec/DSMIPv6 integration were proposed and discussed, and none of > them was IMHO significantly better), but I believe the specification > should explicitly discuss these complications and their implications. => We can discuss the last complication above if you think it adds value to the spec. As you said, this particular complication could have been avoided with other alternatives but at a different cost/ugliness. > > > More detailed comments (which should be easier to fix than > the concerns above) follow: > > 1) Section 5.1, "After the mobile node detects movement it > configures a new care-of address. In addition, the mobile node > updates its local Security Association information to include its > IPv4 address and the home agent's IPv4 address." > > The security associations used for protecting BUs/BAcks are between > MN's IPv6 Home Address and HA's IPv6 address -- and those are > not updated. It may have to update the remote tunnel header > address for tunnel mode IPsec SAs, but according to the current > text, that should happen only after BAck has been received. > > 2) Section 5.1, "The home agent may also need to change NAT > traversal fields in the IKE_SA." You can't figure out what this > means unless you participated in the related email discussions. > For HA, it probably means enabling "dynamic" update of address > and port (in IKE_SA and tunnel mode IPsec SAs) based on incoming > authenticated packets (even if they're not BUs), as described in > RFC 4306 Section 2.23. => ok. > > Text later actually requires the home agent to support this > feature; however, there should be some discussion about its > implications, as there are now *two* different ways how tunnel mode > SAs can get updated (this "dynamic update" and ordinary BUs). => What implications do you see? Apart from supporting two different methods? > > 3) The spec has to say something about using port 500 vs. port 4500 > for IPsec traffic, since the text in RFC 4306 Section 2.23 won't > work as is (MOBIKE had to deal with this issue as well, see RFC > 4555 Section 3.3). > > 4) Text has to mention that MN needs to enable/disable sending > IPsec keep-alives (for port 4500) depending on whether it's behind > a NAT or not. => ok. Hesham > > Best regards, > Pasi > > ---------------------- > > What follows are my random notes about how this might work > (not necessarily fully up-to-date vs. rest of the spec): > > NOTE: This description assumies two (conceptual) DSMIPv6 > tunnels. One is used for sending BUs/BAcks (and always uses UDP > encapsulation); the other one is used for all other traffic. > During handovers these two tunnels are not updated at the same > time, and thus may temporarily use different IP addresses. > They can also use different type of encapsulation. > > 1. if in IPv4 network: update the "BU-DSMIPv6 tunnel" tunnel: > local address = V4CoA:DSMIPv6-port > remote address = V4HA:DSMIPv6-port > > 2. if in IPv4 network: the MN deletes all route optimization > entries from its binding cache. > > 3. The MN sends a Binding Update, which looks like this: > > if in IPv6 network: > > IPv6 header (src=V6CoA, dst=V6HA) > Destination Options header > Home Address option (V6HoA) > ESP header (transport mode) > Mobility header > Binding Update > Alternate Care-of Address option (V6CoA) > [IPv4 Home Address option (V4HoA)] > > if in IPv4 network: > > the code sending the BU has to indicate that after IPsec > processing, the packets has to be sent via "BU-DSMIPv6 tunnel" > (and this indication has to survive IPsec processing). > > IPv4 header (src=V4CoA, dst=V4HA) > UDP header (src=DSMIPv6-PORT, dst=DSMIPv6-PORT) > IPv6 header (src=V6HoA, dst=V6HA) > ESP header (transport mode) > Mobility header > Binding Update > IPv4 Care-of Address option (V4CoA) > [IPv4 Home Address option (V4HoA)] > > 4. The HA receives a Binding Update > > In IPv4 case, its header may have been changed by NAT to: > > IPv4 header (src=NATTED_V4CoA, dst=V4HA) > UDP header (src=NATTED_DSMIPv6-PORT, dst=DSMIPv6-PORT) > IPv6 header (src=V6HoA, dst=V6HA) > [...] > > 5. After DSMIPv6 decapsulation (in case of IPv4) and IPsec > processing, the packet will look like this: > > if in IPv6 network: > > IPv6 header (src=V6CoA, dst=V6HA) > Destination Options header > Home Address option (V6HoA) > Mobility header > Binding Update > Alternate Care-of Address option (V6CoA) > [IPv4 Home Address option (V4HoA)] > > if in IPv4 network: > > IPv6 header (src=V6HoA, dst=V6HA) > Mobility header > Binding Update > IPv4 Care-of Address option (V4CoA) > [IPv4 Home Address option (V4HoA)] > > the DSMIPv6 decapsulation has to store NATTED_V4CoA and > NATTED_DSMIPv6-PORT and somehow pass it on (surviving > IPsec processing). > > 6. If IPv4: The HA determines whether UDP encapsulation is > used (if the MN requested it, or local policy requires it, > or NATTED_V4CoA and V4CoA do not match). > > 7. The HA updates its local forwarding state: > > if IPv4: > update bindings/something so that traffic to V4HoA/V6HoA gets > sent via "Normal-DSMIPv6 tunnel" > update both the "Normal-DSMIPv6" and "BU-DSMIPv6" tunnels as > follows: > local address = V4HA:DSMIPv6-PORT > remote address = NATTED_V4CoA:NATTED-DSMIPv6-PORT > update the "Normal-DSMIPv6" tunnel as follows: > encapsulation = "IPvX-in-IPv4" / "UDP" / "TLV" > else > update bindings/something so that traffic to V4HoA/V6HoA gets > tunneled as IPvX-in-IPv6 to V6CoA. > > 8. If the "HA" will set the "K" bit, it updates the IKE_SA > as follows: > local address = V4HA/V6HA:4500 > remote address = NATTED_V4CoA/V6CoA:4500 > NAT traversal (dynamic updates) = yes/no > (NOTE: remote port number is wrong if doing NAT-T; this > will be updated below) > > 9. The HA updates its *tunnel* mode IPsec SAD entries with MN: > local tunnel header address = V4HA/V6HA:4500 > remote tunnel header address = NATTED_V4CoA/V6CoA:4500 > UDP encapsulation = yes/no > (NOTE: remote port number is wrong if doing NAT-T; this > will be updated below) > > 10. The HA may also need to update information in its SPD, so > that any new SAs get created with these tunnel header addresses. > (This depends a bit on how IKE determines the correct peer > when SA creation is needed.) > > 11. HA generates a Binding Acknowledgement. > > if in IPv6 network: > > IPv6 header (src=V6HA, dst=V6CoA) > Routing header (type 2): V6HoA > Mobility header > Binding Acknowledgement > [IPv4 Home Address option] > [IPv4 Acknowledgement option] > > if in IPv4 network: > > the code sending the BAck has to indicate that after IPsec > processing, the packets has to be sent via "BU-DSMIPv6 tunnel" > (and this indication has to survive IPsec processing). > > IPv6 header (src=V6HA, dst=V6HoA) > Mobility header > Binding Acknowledgement > [IPv4 Home Address option] > [IPv4 Acknowledgement option] > [NAT detection option] > > 12. After IPsec processing and DSMIPv6 encapsulation, it will > look as follows: > > if in IPv6 network: > > IPv6 header (src=V6HA, dst=V6CoA) > Routing header (type 2): V6HoA > ESP header (transport mode) > Mobility header > Binding Acknowledgement > [IPv4 Home Address option] > [IPv4 Acknowledgement option] > > if in IPv4 network: > > IPv4 header (src=V4HA, dst=NATTED_V4CoA) > UDP header (src=DSMIPv6-PORT, dst=NATTED_DSMIPv6-PORT) > IPv6 header (src=V6HA, dst=V6HoA) > ESP header (transport mode) > Mobility header > Binding Acknowledgement > [IPv4 Home Address option] > [IPv4 Acknowledgement option] > [NAT detection option] > > 13. After receiving the BAck, the MN updates its "Normal-DSMIPv6" > tunnel as follows: > > if in IPv4 network: > update bindings/something so that traffic from V4HoA/V6HoA gets > sent via "Normal-DSMIPv6 tunnel" > update the "Normal-DSMIPv6 tunnel as follows: > local address = V4CoA:DSMIPv6-port > remote address = V4HA:DSMIPv6-port > encapsulation = "IPvX-in-IPv4" / "UDP" / "TLV" > else > update bindings/something so that traffic from V4HoA/V6HoA > gets sent as usual IPvX-in-IPv6 to home agent. > > 14. The MN updates IKE/IPsec state as follows: > > if "K" bit not set: > negotiate a new IKE_SA and new IPsec SAs replace all the > existing IPsec SAs (both transport and tunnel mode), > and close the old IKE_SA. > else if "K" bit set, and no MOBIKE: > update the IKE_SA as follows: > local address = V4CoA/V6CoA:4500 > remote address = V4HA/V6HA:4500 > NAT traversal (keepalives) = yes/no (depending on > NAT.D. option) > update *tunnel* mode IPsec SAD entries with HA as follows: > local tunnel header address = V4CoA/V6CoA > remote tunnel header address = V4HA/V6HA > UDP encapsulation = yes/no (depending on NAT Detection option) > send an empty informational message (note that this step must > not be done before receiving the BAck) > > the MN may also need to update information in its SPD, so that > any new SAs get created with these tunnel header addresses. > (This depends a bit on how IKE determines the correct peer > when SA creation is needed.) > else (MOBIKE): > update IKE_SA and tunnel mode SAs with MOBIKE > > 15. If the MN sent an empty Informational request, the HA will > update its IKE_SA as follows: > remote_address = NATTED_V4CoA:NATTED_PORT_4500 > > and tunnel mode IPsec SAD entries as follows: > remote_address = NATTED_V4CoA:NATTED_PORT_4500 > > 16. Finally, the MN can start doing something about route > optimization: > if in IPv4 network: > MN sends Binding Updates to delete bindings with all > Correspondent Nodes that were using route optimization. > else: > MN could send Binding Updates to update bindings with > Corrrespondent Nodes for route optimization. > > 17. End? > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Feb 6 05:26:50 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EBAD3A6E41; Wed, 6 Feb 2008 05:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GL-iZMKY-WHw; Wed, 6 Feb 2008 05:26:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50D0B3A6D6B; Wed, 6 Feb 2008 05:26:46 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD81C3A683D for ; Wed, 6 Feb 2008 05:26:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMDONuL2YWvf for ; Wed, 6 Feb 2008 05:26:43 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 8B10A3A6CA0 for ; Wed, 6 Feb 2008 05:26:43 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,312,1199660400"; d="scan'208";a="4903827" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 06 Feb 2008 14:28:14 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m16DSDjP006032; Wed, 6 Feb 2008 14:28:13 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m16DSCKx003139; Wed, 6 Feb 2008 13:28:12 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Feb 2008 14:28:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Feb 2008 14:28:06 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0526C76F@xmb-ams-337.emea.cisco.com> In-Reply-To: <4C47BAA9-BA58-45F7-BDCF-2C050118BACE@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] re-direction attack on MCoA thread-index: AchjX6xAfnRfYwSzTNeIL8EZ9vivcQFWJZFA From: "Pascal Thubert (pthubert)" To: "marcelo bagnulo braun" X-OriginalArrivalTime: 06 Feb 2008 13:28:06.0865 (UTC) FILETIME=[1BC23410:01C868C4] Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] re-direction attack on MCoA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Marcelo: I think there should be a separate draft for the RR check to the CoA. The p= roblem is everywhere and not specific to MCoA, just like it's not specific = to DSMIP. = The trouble is that the draft in question is never started. I'll be happy t= o give away the text from RRH for that noble purpose ;) Pascal = >-----Original Message----- >From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] = >Sent: mercredi 30 janvier 2008 17:46 >To: Pascal Thubert (pthubert) >Cc: Wassim Haddad; Benjamin Lim; Julien Laganier; mext@ietf.org >Subject: Re: [MEXT] re-direction attack on MCoA > >Pascal, > >The question at this point is the following one: do you think = >that this threat should be addressed in the MCoA draft itself? > >comments? > >Regards, marcelo > > >El 30/01/2008, a las 10:09, Pascal Thubert (pthubert) escribi=F3: > >> I agree with Wassim on both mails. >> >> There's also the situation where the MN/MR might be fooled by the = >> visited network into believing that the CoA (or its prefix if a = >> network is attacked as opposed to a host) is on the visited link. = >> DSMIP is also exposed, in particular with IPv4 CoAs. >> >> There are many scenarios that do not involve high mobility were a 3- = >> way or a 4-way handshake could be used to verify the CoA. We have = >> proposed such a test in section 6 of the RRH draft that uses a = >> triggered 2nd BU flow to verify the CoA in the first one: >> = >http://tools.ietf.org/html/draft-thubert-nemo-reverse-routing-header-0 >> 7# >> section-6 >> >> >> Pascal >> >> >>> -----Original Message----- >>> From: Wassim Haddad [mailto:whaddad@tcs.hut.fi] >>> Sent: mercredi 30 janvier 2008 09:32 >>> To: Benjamin Lim >>> Cc: 'Julien Laganier'; mext@ietf.org >>> Subject: RE: [MEXT] re-direction attack on MCoA >>> >>> On Wed, 30 Jan 2008, Benjamin Lim wrote: >>> >>>> All in all, what I am trying to say is that tracing only = >limits the = >>>> effect of the attack from escalating further and not preventing it. >>> >>> =3D> which (again) also perfectly applies to a single CoA. >>> >>> >>> Regards, >>> >>> Wassim H. >>> >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mext >>> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www1.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Feb 6 07:04:36 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AD933A6E75; Wed, 6 Feb 2008 07:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.948 X-Spam-Level: X-Spam-Status: No, score=-3.948 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ru6O1FU08Wp5; Wed, 6 Feb 2008 07:04:35 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A4D93A6E6C; Wed, 6 Feb 2008 07:04:35 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31B8E3A6E6A for ; Wed, 6 Feb 2008 07:04:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTeeMBJSqyOH for ; Wed, 6 Feb 2008 07:04:33 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id E3F9E3A6E17 for ; Wed, 6 Feb 2008 07:04:32 -0800 (PST) Received: from chelo-it-uc3m-es.it.uc3m.es (chelo-it-uc3m-es.it.uc3m.es [163.117.139.71])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp03.uc3m.es (Postfix) with ESMTP id 05B522DAC28;Wed, 6 Feb 2008 16:04:04 +0100 (CET) Message-Id: <24B2D6E8-015E-484F-B97B-ACD6649621AF@it.uc3m.es> From: marcelo bagnulo braun To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0526C76F@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v915) Date: Wed, 6 Feb 2008 16:04:03 +0100 References: <7892795E1A87F04CADFCCF41FADD00FC0526C76F@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.915) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-21.6138 TC:02 TRN:40 TV:5.0.1023(15714.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] re-direction attack on MCoA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org The idea at this point afaiu is to work on a draft trying to identify = residual threats in mip6 and then figure out if we should do something = about some of them You are kindly invited to join that effort, that i understand GEorge, = Wassim and Ben are starting Regards, marcelo El 06/02/2008, a las 14:28, Pascal Thubert (pthubert) escribi=F3: > Hi Marcelo: > > I think there should be a separate draft for the RR check to the = > CoA. The problem is everywhere and not specific to MCoA, just like = > it's not specific to DSMIP. > > The trouble is that the draft in question is never started. I'll be = > happy to give away the text from RRH for that noble purpose ;) > > Pascal > > >> -----Original Message----- >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >> Sent: mercredi 30 janvier 2008 17:46 >> To: Pascal Thubert (pthubert) >> Cc: Wassim Haddad; Benjamin Lim; Julien Laganier; mext@ietf.org >> Subject: Re: [MEXT] re-direction attack on MCoA >> >> Pascal, >> >> The question at this point is the following one: do you think >> that this threat should be addressed in the MCoA draft itself? >> >> comments? >> >> Regards, marcelo >> >> >> El 30/01/2008, a las 10:09, Pascal Thubert (pthubert) escribi=F3: >> >>> I agree with Wassim on both mails. >>> >>> There's also the situation where the MN/MR might be fooled by the >>> visited network into believing that the CoA (or its prefix if a >>> network is attacked as opposed to a host) is on the visited link. >>> DSMIP is also exposed, in particular with IPv4 CoAs. >>> >>> There are many scenarios that do not involve high mobility were a 3- >>> way or a 4-way handshake could be used to verify the CoA. We have >>> proposed such a test in section 6 of the RRH draft that uses a >>> triggered 2nd BU flow to verify the CoA in the first one: >>> >> http://tools.ietf.org/html/draft-thubert-nemo-reverse-routing- = >> header-0 >>> 7# >>> section-6 >>> >>> >>> Pascal >>> >>> >>>> -----Original Message----- >>>> From: Wassim Haddad [mailto:whaddad@tcs.hut.fi] >>>> Sent: mercredi 30 janvier 2008 09:32 >>>> To: Benjamin Lim >>>> Cc: 'Julien Laganier'; mext@ietf.org >>>> Subject: RE: [MEXT] re-direction attack on MCoA >>>> >>>> On Wed, 30 Jan 2008, Benjamin Lim wrote: >>>> >>>>> All in all, what I am trying to say is that tracing only >> limits the >>>>> effect of the attack from escalating further and not preventing = >>>>> it. >>>> >>>> =3D> which (again) also perfectly applies to a single CoA. >>>> >>>> >>>> Regards, >>>> >>>> Wassim H. >>>> >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mext >>>> >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mext >> >> > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Feb 6 07:12:09 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6751F3A6EBD; Wed, 6 Feb 2008 07:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.594 X-Spam-Level: X-Spam-Status: No, score=-3.594 tagged_above=-999 required=5 tests=[AWL=-0.432, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5OiqCC5l7PV; Wed, 6 Feb 2008 07:12:08 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEAE93A6EB5; Wed, 6 Feb 2008 07:12:06 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB5F33A6E17 for ; Wed, 6 Feb 2008 07:12:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1DdDBCGCIhK for ; Wed, 6 Feb 2008 07:12:04 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 346E93A6E7A for ; Wed, 6 Feb 2008 07:12:02 -0800 (PST) Received: from chelo-it-uc3m-es.it.uc3m.es (chelo-it-uc3m-es.it.uc3m.es [163.117.139.71])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp01.uc3m.es (Postfix) with ESMTP id 51D61383B19;Wed, 6 Feb 2008 16:13:33 +0100 (CET) Message-Id: From: marcelo bagnulo braun To: Roberto Baldessari In-Reply-To: <5F6519BF2DE0404D99B7C75607FF76FF4D0644@mx1.office> Mime-Version: 1.0 (Apple Message framework v915) Date: Wed, 6 Feb 2008 16:13:33 +0100 References: <5F6519BF2DE0404D99B7C75607FF76FF4D0644@mx1.office> X-Mailer: Apple Mail (2.915) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-28.5726 TC:1F TRN:87 TV:5.0.1023(15714.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: mext@ietf.org Subject: Re: [MEXT] few questions about draft-baldessari-c2ccc-nemo-req-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org below... El 05/02/2008, a las 22:55, Roberto Baldessari escribi=F3: > Hi Marcelo, > > thanks for the comments, please see inline > >> >> Hi, >> >> i have been reading this document and the first question that >> i have is that if i understood correctly, the main scope of >> the usage of nemo in this scenario is for non safety >> communications with any arbitrary node in the Internet, right? >> > > Not only. > NEMO in C2C is meant to be used to talk either to an arbitrary node = > in the Internet or to a newly deployed node for automotive = > applications. > but non safety critical applications from what i understood in draft... My point is that i see these are two very different scenarios (and i = think the c2c also shares this) On one hand you have the safety critical coomunications, which have = important reliability, security fault toelrance requirements, since = safety is involved. However, i think they have a completelly different = trust model. I mean, it seems to me that cars only need to have safety = communications with a reduced set of CNs, which normally are operated = by a very reduced set of entities, police, fire men and so on. OTOH, entertainment communications are very different. They don't have = si much requirements in terms of security, reliabilty as the previous = ones, but the trust model is compeltelly different. You need to be = able to talk with anyone in the Internet. So, it would importnat imho to understand what we are targetting the = solution for. So far, i have unserstood that safety comunications will use the c2c = network layer, so the nemo will be restricted to the entertainment. This is very vaguely defined in the draft. I think the draft should = clearly state what scenario you have in mind (safety or non safety = communications) > >> If that is the case, i think it is kind of strange that the >> use case considered in section 5 which mainly focused in the >> conept of CR: >> >> The requirements defined in this document refer to RO between MR and >> CR (Correspondent Router). According to C2C-CC use >> cases, the CR can >> be: >> >> o a NEMO MR. For example the MR running on another vehicle or >> another mobile device connected to the Internet; >> >> o a RO-enabled router, i.e. a router static or mobile >> that does not >> act as NEMO MR but is capable of establishing RO sessions with >> NEMO MRs. For example the access router serving a CN in the >> infrastructure that offers services to vehicles, or the access >> router serving RSUs installed along the road; >> >> I think this kind of assumes a solution, i.e. the existance >> of a CR, which does not exists today. I guess that if the >> goal of the usage of nemo is mainly communications with node >> in the internet, the makor usage case would be to talk with >> any CN, rather than to a CR. >> > > Right, this usage of the term CR is not clear and probably breaks = > RFC 4885. > This was already pointed out at IETF-69 (no new version has been = > submitted since then). > I proposed to change CR into CE. And CE can be one of these: > > 1) a NEMO MR > 2) a router (not a MR) implementing NEMO RO > 3) a CN, i.e. IPv6 host > 4) a MIPv6 CN > > What do you think? > makes sense to me > BTW Regarding solution space, we did not want to restrict it but on = > the contrary make it wider (in the bullet you omitted from the above = > text, we wrote that a CR can be "a RO-enabled router collapsed into = > the CN") > > > >> Next, in section >> >> 6.3. Req 3 - RO Security >> >> >> A RO technique MUST prevent malicious nodes to claim false MNP >> ownership. In order to achieve this, a RO technique MAY >> make use of >> security features provided by the sub-IPv6 C2C-CC Network >> layer (e.g. >> cryptographic protection), but it MUST NOT introduce new security >> leaks for the C2C-CC applications or render their >> security measures >> ineffective. >> >> I fail to understand this one. >> first, as i understand it, the goal is to run ro between >> nodes in the nemo and any node in the internet. In this case, >> it seems hardly useful to use the C2C network interface, >> since i doesn't seems that any node in the internet will use >> the C2C network layer. > > A similar comment was made during IETF-69. We will remove in the = > next version references to C2C-CC security features wrt to this = > requirement. So we will keep only the first sentence of the req. > > The background of this text was that C2C is going anyway to = > implement security features probably based on certificates issued by = > a CA. We thought that RO security might take advantage of this in = > the case of MR-MR via 802.11p (excluding the MR-CN and the WLAN = > cases). But it doesn't seem possible as it is a too particular case. > right >> Moreover, if i udnerstood correctly, >> the IPv6 layer can use directly the WLAN interface in the >> vehicle so, we cannot rely on the C2C network layer since it >> may not be ther. >> > > See previous comment. > >> With respect to: >> >> 6.5. Req 5 - Multihoming >> >> Do you need to support multiple MRs in the same nemo? it >> seems you don't because you seem to assume a single OBU, right? >> > Right. 1 OBU per vehicle is the C2C-CC approach. > >> I guess that the OBU may have multiple technologies, but it >> deosn't seem to me that the nemo RO for non safety >> application will be able to use them, so it seems that the >> OBU for non safety usage will only be able to use the WLAN, >> so, how come that multihoming is needed? I mean, you have a >> single MR and you have a single technology, i guess that the >> possibility is that you will be attached to different WLAN >> simoultaneously? is that the scenario that you have in nmind? > > No. In the protocol stack depicted in the draft (Figure 2), IPv6 is = > used over C2C-CC NET/11p and over WLAN. No. in the picture include in the draft it seems to me that IPv6 is only = used in WLAN, while C2C network is used both in 802.11p and WLAN. if this is not the case, you may wnat to clarify it > So, a node has 2 IPv6 interfaces (one virtual, one real). you mean one directly to the WLAN and the other one through the C2C = network layer? > This is already a possibly multihomed MR (i.e. if the MR is attached = > to a 802.11p RSU and a public WLAN hotspot). Additional technologies = > that are not in the current focus of C2C-CC might come later (e.g. = > 3G). This is why RO must be compatible with multihoming. > right. My point is that if we are using nemo only for non safety = communications and these communications only go through WLAN, then = even though the MR has multiple technologies, from the perspective of = the usage of nemo,the MR only have one technology, which is WLAN, if = you see what i mean >> Moreover, are you considering the case with multiple HAs? >> > > Multiple HAs is not currently a priority for C2C. Reallocating HAs = > has benefits but having a standard RO solution that works even with = > 1 HA should come first. > good Regards, marcelo > Best regards, > > Roberto > > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Feb 6 08:34:05 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B1743A7029; Wed, 6 Feb 2008 08:34:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qKymYT4Rmjz; Wed, 6 Feb 2008 08:34:02 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CC193A6F6B; Wed, 6 Feb 2008 08:34:01 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 194DC3A6C6B for ; Wed, 6 Feb 2008 08:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xslgOIczB3Qo for ; Wed, 6 Feb 2008 08:33:58 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id ADA113A700C for ; Wed, 6 Feb 2008 08:32:30 -0800 (PST) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m15Ir8CT021644; Tue, 5 Feb 2008 12:53:09 -0600 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Feb 2008 12:53:08 -0600 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Feb 2008 12:53:08 -0600 Message-ID: <47A8B10E.1000801@ericsson.com> Date: Tue, 05 Feb 2008 13:55:10 -0500 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: marcelo bagnulo braun References: In-Reply-To: X-OriginalArrivalTime: 05 Feb 2008 18:53:08.0355 (UTC) FILETIME=[5923AD30:01C86828] Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Firewall work X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Marcelo, I have read the documents and I think they are ready to be adopted as wg items. Thanks Suresh (Full Disclosure: I am one of the authors) marcelo bagnulo braun wrote: > Hi Folks, > > during last IETF meeting, the DT presented their work and we agreed that > people will read the drafts and comment to see if we adopt them as the > WG items for this work. > > I remind you the documents are: > > - Guidelines for firewall administrators regarding MIPv6 traffic > draft-krishnan-mip6-firewall-admin-02 > - Guidelines for firewall vendors regarding MIPv6 traffic > draft-krishnan-mip6-firewall-vendor-02 > > Please read and comment so we can figure out if we adopt these docs or > what to do. > > Regards, marcelo > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Feb 6 10:38:00 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D78253A7046; Wed, 6 Feb 2008 10:38:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPCzj8KKJlLj; Wed, 6 Feb 2008 10:37:59 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B7273A6FF2; Wed, 6 Feb 2008 10:37:59 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 903C63A6DE6 for ; Wed, 6 Feb 2008 10:37:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiTOMXXpENDp for ; Wed, 6 Feb 2008 10:37:56 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 561623A7000 for ; Wed, 6 Feb 2008 10:36:13 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id B0A432C002B4A; Wed, 6 Feb 2008 19:37:44 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-0L+W5Tbj3C; Wed, 6 Feb 2008 19:37:44 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id 904DD2C002B48; Wed, 6 Feb 2008 19:37:34 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Feb 2008 19:37:32 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF4D0757@mx1.office> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: few questions about draft-baldessari-c2ccc-nemo-req-01 Thread-Index: Acho0txkps4hPOWbQ7GTFNt2sxY6aAAGxDjQ From: "Roberto Baldessari" To: "marcelo bagnulo braun" Cc: mext@ietf.org Subject: Re: [MEXT] few questions about draft-baldessari-c2ccc-nemo-req-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Marcelo, See below [removed some text] > > Not only. > > NEMO in C2C is meant to be used to talk either to an > arbitrary node in > > the Internet or to a newly deployed node for automotive > applications. > > > > but non safety critical applications from what i understood > in draft... > > My point is that i see these are two very different scenarios > (and i think the c2c also shares this) > > On one hand you have the safety critical coomunications, > which have important reliability, security fault toelrance > requirements, since safety is involved. However, i think they > have a completelly different trust model. I mean, it seems to > me that cars only need to have safety communications with a > reduced set of CNs, which normally are operated by a very > reduced set of entities, police, fire men and so on. > > OTOH, entertainment communications are very different. They > don't have si much requirements in terms of security, > reliabilty as the previous ones, but the trust model is > compeltelly different. You need to be able to talk with > anyone in the Internet. > > So, it would importnat imho to understand what we are > targetting the solution for. > > So far, i have unserstood that safety comunications will use > the c2c network layer, so the nemo will be restricted to the > entertainment. > > This is very vaguely defined in the draft. I think the draft > should clearly state what scenario you have in mind (safety > or non safety > communications) > We wrote an entire sub-section to state that NEMO in C2C is limited to non-safety. I'm refering to Section 4.1 "Scope of NEMO". It says: "...This implies that the usage of NEMO in vehicular communications does not target safety-of-life applications but rather less restrictive, non-safety applications." I think this is clear enough and you just missed it. > >> > >> 6.5. Req 5 - Multihoming > >> > >> Do you need to support multiple MRs in the same nemo? it > >> seems you don't because you seem to assume a single OBU, right? > >> > > Right. 1 OBU per vehicle is the C2C-CC approach. > > > >> I guess that the OBU may have multiple technologies, but it > >> deosn't seem to me that the nemo RO for non safety > >> application will be able to use them, so it seems that the > >> OBU for non safety usage will only be able to use the WLAN, > >> so, how come that multihoming is needed? I mean, you have a > >> single MR and you have a single technology, i guess that the > >> possibility is that you will be attached to different WLAN > >> simoultaneously? is that the scenario that you have in nmind? > > > > No. In the protocol stack depicted in the draft (Figure 2), > IPv6 is > > used over C2C-CC NET/11p and over WLAN. > > No. > > in the picture include in the draft it seems to me that IPv6 is only > used in WLAN, while C2C network is used both in 802.11p and WLAN. > > if this is not the case, you may wnat to clarify it > > > So, a node has 2 IPv6 interfaces (one virtual, one real). > > you mean one directly to the WLAN and the other one through the C2C > network layer? > > > This is already a possibly multihomed MR (i.e. if the MR is > attached > > to a 802.11p RSU and a public WLAN hotspot). Additional > technologies > > that are not in the current focus of C2C-CC might come later (e.g. > > 3G). This is why RO must be compatible with multihoming. > > > > right. My point is that if we are using nemo only for non safety > communications and these communications only go through WLAN, then > even though the MR has multiple technologies, from the > perspective of > the usage of nemo,the MR only have one technology, which is WLAN, if > you see what i mean > > Here is probably the misunderstanding. C2C NET layer can be used for both safety and non-safety. NEMO will not be used for safety. IPV6 can be used over C2C NET to enjoy multi-hop access and over WLAN to enjoy (single-hop) public hotspot access. I will try to make this clearer in the draft. Regards, Roberto _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Feb 6 13:47:37 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDECB3A733E; Wed, 6 Feb 2008 13:47:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yClpqDF6+KW; Wed, 6 Feb 2008 13:47:37 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 397813A726F; Wed, 6 Feb 2008 13:47:30 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A22963A6D92 for ; Wed, 6 Feb 2008 13:47:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIY7KfWq00Av for ; Wed, 6 Feb 2008 13:47:26 -0800 (PST) Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.90.157]) by core3.amsl.com (Postfix) with SMTP id 57D403A718E for ; Wed, 6 Feb 2008 13:47:09 -0800 (PST) Received: (qmail 17282 invoked for bounce); 6 Feb 2008 21:48:38 -0000 Received: from unknown (HELO ?192.168.0.20?) (kuntz@unknown) by unknown with RC4-SHA encrypted SMTP; 6 Feb 2008 21:48:38 -0000 Message-Id: <067A6921-E9AF-4FD9-843B-8355F6B5E9CB@clarinet.u-strasbg.fr> From: Romain KUNTZ To: mext@ietf.org In-Reply-To: Mime-Version: 1.0 (Apple Message framework v915) Date: Wed, 6 Feb 2008 22:48:38 +0100 References: X-Mailer: Apple Mail (2.915) Cc: Ryuji Wakikawa Subject: Re: [MEXT] WGLC for draft-ietf-monami6-multiplecoa-05.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ryuji, I have a couple more comments on some part of the draft: - Section 4.2.1: Why is the O flag stored in the Binding ID option, and not the BU? This would be more consistent in the case of the Bulk registration, as this flag is supposed to be shared among all the Binding ID options. - Section 5.6.3 "If the home agent receives the [MCOA RETURNHOME WO/NDP]," Replace "home agent" with "mobile node" - Section 5.10 "For Correspondent nodes, the mobile node cannot use the O flag because of no bulk registration support. Thus, if necessary, it MUST sends a regular binding first to overwrite the remaining bindings at the correspondent node. Then, it can re-register the set of bindings by using Multiple Care-of Address Registration. What is the problem to use the O flag with a single Binding ID option? This is not considered as bulk registration, so why the MN can't use O flag with CN? - Section 6.3 "* If the receiver has a regular binding which does not have BID for the mobile node, it de-registers the regular binding and registers a new binding including BID according to the Binding Update. In this case, the receiver MUST return [MCOA BID CONFLICT]." This IMHO contradicts what section 5.7 says: "o If [MCOA BID CONFLICT] is specified, the binding entry specified by the Binding Identifier mobility option is already registered as a regular binding. In such case, the mobile node SHOULD stop sending Binding Updates with BID, or SHOULD use O flag for the peer to reset all the registered bindings." because on the HA side, the new binding (with BID) is registered, but on the MN side it is advised to stop sending BU with BID option. Note also that MCOA_BID_CONFLICT is considered as a status for an unsuccessful refistration (>128), so it also conflicts with the fact that the HA accepts the new binding. - Section 6.3 "If all the above operations are successfully finished, the Binding Acknowledgment containing the Binding Identifier mobility options MUST be replied to the mobile node if A flag is set in the Binding Acknowledgment." The last "Binding Acknowledgment" should be instead "Binding Update" "Whenever a Binding Acknowledgment is returned, all the Binding Identifier mobility options stored in the Binding Update MUST be copied to the Binding Acknowledgment." All the field must be copied EXCEPT the status field that must be set to the previously decided value. Cheers, -- Romain KUNTZ kuntz@lsiit.u-strasbg.fr Louis Pasteur University - Networks and Protocols Team On 2008/02/03, at 11:31, marcelo bagnulo braun wrote: > Hi, > > With this email we issue the WGLC for draft-ietf-monami6- > multiplecoa-05.txt > The WGLC will be open till the 11 of february. > We kindly ask the WG to review the document and provide comments. > > Please note that a valid comment at this stage is positive feedback > about the document being ready to be shipped. > So, please if you think the doc is ready, do express this to the ml > (or to the chairs) > > For you convenience, additional information about the document: > > Title : Multiple Care-of Addresses Registration > Author(s) : R. Wakikawa, et al. > Filename : draft-ietf-monami6-multiplecoa-05.txt > Pages : 44 > Date : 2008-01-27 > > http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-05.txt > > Thanks, Julien and marcelo > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Feb 7 01:29:49 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 498D93A7686; Thu, 7 Feb 2008 01:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7TU-M97FxVUd; Thu, 7 Feb 2008 01:29:47 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8820D3A766B; Thu, 7 Feb 2008 01:29:47 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 068DD3A765B for ; Thu, 7 Feb 2008 01:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJ20uTItdMGu for ; Thu, 7 Feb 2008 01:29:44 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id F03363A765D for ; Thu, 7 Feb 2008 01:29:43 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 4C6EC198D08; Thu, 7 Feb 2008 11:31:14 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id B44CD198AC0; Thu, 7 Feb 2008 11:31:13 +0200 (EET) Message-ID: <47AACFDD.8030406@piuha.net> Date: Thu, 07 Feb 2008 10:31:09 +0100 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: mext@ietf.org, draft-ietf-mext-aero-reqs@tools.ietf.org X-Virus-Scanned: ClamAV using ClamSMTP Subject: [MEXT] review of draft-ietf-mext-aero-reqs X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I have reviewed this document. My detailed comments are further down. Overall, the document is well written and a good start for specifying what the aeronautics community needs. However, there are a number of issues that still need work: 1) To me, the main issue with airline network access is the extra continent roundtrip that is introduced if your tunnel has to be used and has to stay at the same server endpoint all the time. This issue needs emphasis among the various IMHO less important requirements. 2) The security requirements need significant work to specify what problems the RO solution must guard against. 3) Transport implications, separability, support VMNs, and some of the other specific requirements require further clarification. > Longer routes leading to increased delay and additional > infrastructure load - In aeronautical networks (e.g. using Plain > Old Aircraft Communication Addressing and Reporting System (ACARS) > or ACARS over VHF Data Link (VDL) mode 2 ) the queueing delays are > often long due to ARQ mechanisms and underprovisioned radio links. > > Furthermore, for aeronautical communications systems that pass > through geosynchronous satellites, and for space exploration, the > propagation delays are also long. These delays combined with the > additional need to cross continents in order to transport packets > between ground stations and CNs means that delays are already > quite high in aeronautical and space networks without the addition > of an MRHA tunnel. The increased delays caused by MRHA tunnels > may be unacceptable in meeting Required Communication Performance > [8 ]. Overall, I felt that the document talks about a large number of requirements, but fails to highlight the key problem which is talked about at the end of the above passage: as planes travel from one continent to another, having a stationary tunnel endpoint will eventually cause an additional continent roundtrip. > Increased packet overhead - Given the constrained link bandwidths > available in even future communications systems for aeronautics > and space exploration, planners are extremely adverse to header > overhead. Since any amount of available link capacity can be > utilized for extra situational awareness, science data, etc., > every byte of header/tunnel overhead displaces a byte of useful > data. Secondary issues like this are not very convincing (what about header compression, for instance?) and confuse the key problem. > Since for ATS, the MRs and MNNs are under regulatory control and are > actively tested and maintained, it is not unreasonable to assume that > special patches or software be running on these devices to enable > NEMO RO. In fact, since these devices are accessed by skilled > technicians and professionals, it may be acceptable even if complex > configuration is required for NEMO RO. Of course simplicity in setup > and configuration is desirable, however. What about CNs, is it reasonable to expect changes to them? > The set of CNs may be assumed to > all share the same network prefix. This seems unexpected. Why would we assume this? > 2.1.2. Airline Operational Services Domain This section talks about the airline's operational processes. What about the manufacturers, maintenance contract holders, etc -- I would expect that there will be some communication with them as well. > in the future, it is expected that the In-Flight > Entertainment (IFE) systems may receive movie refreshes of data > running into the gigabyte range. > This seems low. A single high-definition movie involves tens of gigabytes. If you are really talking about movies, I suspect these could be scheduled to be changed while in the airport. If you talk about current TV programs (news etc), it may be a different matter. Even then, I suspect one gigabyte is a small amount of data. > For the small number of messaging flows, > however, the CNs are geographically (but not necessarily > topologically) very close to the aircraft. It is not clear that this would be the case. We need to separate what happens at different layers. Recipients may indeed be close to you, but applications (chat, e-mail) typically go through central servers at the home site. > Due to the great size of the data stored on > these LFNs compared to the anemic bandwidth available air-to-ground, > these LFNs will probably not attempt to communicate off-board at all > during the course of a flight, but will wait to update their content > via either high-speed links are available on the ground, or via > removable media inserted by the flight crew. Hmm. It seems to me that there would be demand for downloading new data (e.g., current TV programming) if it were possible. I would not necessarily rule this out... > The RO solution should be optimized for > ATS and AOS needs, and consider PIES as a secondary concern. > > With this in consideration, the PIES domain is also the most likely > to utilize NEMO for communications in the near-term since > relatatively little regulations and beaurocracy are involved in > deploying new technology in this domain Are there legal interception requirements that would affect the passenger domain? Will these requirements affect what we need to do for RO? > It can be assumed that for manned spaceflight, at least, multiple MRs > will be present and on-line simultaneously for fast failover. These > will usually be multihomed over space links in diverse frequency > bands, and so multiple-prefixes can be expected, especially since > some links will be direct to ground stations while others may be > bent-pipe repeated through satellite relays like TDRSS. First, multiple prefixes on the access network that the MRs connect to, or multiple home prefixes that are presented to the mobile network nodes? These are very different... And if it is the latter, I'm not sure I fully understand why multiple prefixes are needed. > 3.1.1. Rationale for Aeronautics - Separability It is not clear to me why separability is needed as a requirement. Or at least it is unclear to me whether this refers to a functionality within NEMO or something relating to the ability to employ NEMO on a case-by-case basis. Presumably, you should be able to run NEMO, NEMO RO, and various different techniques on the different domains independently already today. Simply have some devices in the plane be under an MR that uses RO, some under an MR that does not, others that don't use NEMO at all, etc. I think it would be potentially harmful to try to integrate the different traffic domains under the same MR and NEMO connection. Particularly given the safety issues. > 3. Required Characteristics Should this document talk about the requirements related to transport effects from the use of RO? Or lack thereof... > If duplicating a small number of packets sent over > both the MRHA tunnel and the optimized path is possible until the > optimized path can be verified to function for a particular data > flow, then this could be sufficient to meet this requirement (it is > safe to assume that the applications are robust to this duplication). I am not sure I understand the transport implications of such duplication. I could imagine under some conditions it could introduce reordering or something that causes harm for TCP. > When an MR is completely disconnected from the > majority of the network it is intended to communicate, including its > HA, there is no requirement for it to be able to retain any > communications involving parties outside the mobile networks managed > by itself. Its great to have such non-requirements here as well. > 3.6. Req6 - Scalability > > > Req6 - An RO scheme MUST be simultaneously usable by ten thousand > nodes without overloading the ground network or routing system. This should be formulated more firmly. For instance, I would like to see an additional requirement that the solution MUST NOT inject updates to the global BGP routing table when planes move around. > 3.8. Req8 - Security > > > Req8 - IPsec MUST be usable over the RO scheme, and the data used to > make RO decisions MUST be authenticable, perhaps using some form of > IPsec. This requirement should be split up. The part about payload traffic being able to use IPsec should be generalized to any security mechanism. It might make sense to combine this with Req9. The part about securing the RO itself should be held separate. In addition, the requirement as it stands not sufficiently detailed to be useful. Start with the requirement that route optimization decisions must be taken by such and such nodes involved in the protocol, and that strong authentication is required for the signaling. Specify who is authorized make particular decisions. Specify what security infrastructure you are prepared to accept to allow all this to happen. Even so, there are other requirements that you may want to consider, such as what to do with securing path tests (but these may not be something that we completely secure). > Likewise, since the IPsec standards > seem to be the only widely-agreed upon framework for implementing > packet authentication and other security services, the use of IPsec > to authenticate or otherwise secure RO signaling and other data used > in the RO process is also desirable, but other reasonable > authentication mechanisms may be acceptable for RO signalling. As above. IPsec may be the right solution, but the text sounds like spreading security pixie dust to a hard problem. Specify the security requirements for your problem, not the solution. > This requirement was extrapolated from ICAO's TC-8 - "The approach > should be secure." Against what attacks? Making RO decisions by someone in the Internet? By someone on the path? By a legitimate participant but who does not "own" this particular prefix? By a compromised node? > For oceanic flight, ATS and AOS may > also benefit from the capability of nesting MRs between multiple > planes to provide a "reachback" to terrestrial groundstations rather > than relying solely on lower rate HF or satellite systems. In either > case, this mode of operation is beyond current strict requirements > and is merely desirable. This requirement makes sense to me, but it is also something that focuses on building ad hoc routing style networks. I would suggest that we have to keep this part of the problem space out of our effort if we are going to complete something. Lets look at the ad hoc routing aspect separately. I also do not necessarily believe that nested NEMOs are the right approach to doin such multi-hop manet routing. It seems preferrable that the MR deals with this by also acting as a, say, MANET router. > 4.4. Des4 - VMN Support > > At least LFNs and LMNs MUST be supported by a viable RO solution for > aeronautics, as these local nodes are within the ATS and AOS domains. > VMNs within the PIES domain are expected to be numerous, and it is > strongly desirable for them to be supported by the RO technique, but > not strictly required. What does "support" mean here -- presumably if Req9 is followed, it would be hard for any new technology to break nodes that employ VPNs, Mobile IPv6, HIP, or something like that. Or does "support" mean some additional feature that will be beneficial to the nodes? If so, please specify. Editorial: > (e.g. using Plain > Old Aircraft Communication Addressing and Reporting System (ACARS) > or ACARS over VHF Data Link (VDL) mode 2 ) Style: use "the old" instead of "plain old". Or some other choice of words... > Entertainment (IFE) systems may receive movie refreshes of data s/movie/television program/ ? I would expect that current news would be something of value to passengers. > When an MR is completely disconnected from the > majority of the network it is intended to communicate, including its > HA, there is no requirement for it to be able to retain any > communications involving parties outside the mobile networks managed > by itself. s/HA,/HA(s),/ > [1] Ernst, T. and H. Lach, "Network Mobility Support Terminology", > draft-ietf-nemo-terminology-06 (work in progress), > November 2006. > > [2] Ernst, T., "Network Mobility Support Goals and Requirements", > draft-ietf-nemo-requirements-06 (work in progress), > November 2006. > [7] Ng, C., "Network Mobility Route Optimization Problem > Statement", draft-ietf-nemo-ro-problem-statement-03 (work in > progress), September 2006. These are RFCs now. > [17] Bradner, S., "Key words for use in RFCs to Indicate Requirement > Levels", BCP 14, RFC 2119, March 1997. Make this a normative reference. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Feb 7 02:08:01 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE0593A7700; Thu, 7 Feb 2008 02:08:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojEF3HLeZQhQ; Thu, 7 Feb 2008 02:07:56 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EA213A76B1; Thu, 7 Feb 2008 02:07:56 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B1983A76AB for ; Thu, 7 Feb 2008 02:07:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3V2eNMMip98 for ; Thu, 7 Feb 2008 02:07:54 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by core3.amsl.com (Postfix) with ESMTP id A94403A76C3 for ; Thu, 7 Feb 2008 02:07:53 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id d21so854254nfb.39 for ; Thu, 07 Feb 2008 02:09:23 -0800 (PST) Received: by 10.78.204.20 with SMTP id b20mr19746039hug.33.1202378962889; Thu, 07 Feb 2008 02:09:22 -0800 (PST) Received: from ?192.168.1.101? ( [163.117.139.42]) by mx.google.com with ESMTPS id u26sm11314827mug.17.2008.02.07.02.09.19 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Feb 2008 02:09:20 -0800 (PST) From: RYUJI WAKIKAWA To: Romain KUNTZ In-Reply-To: <067A6921-E9AF-4FD9-843B-8355F6B5E9CB@clarinet.u-strasbg.fr> References: <067A6921-E9AF-4FD9-843B-8355F6B5E9CB@clarinet.u-strasbg.fr> Message-Id: <5247F524-F366-45B3-B2B0-731C4E35BB6C@gmail.com> Mime-Version: 1.0 (Apple Message framework v915) Date: Thu, 7 Feb 2008 19:09:17 +0900 X-Mailer: Apple Mail (2.915) Cc: mext@ietf.org Subject: Re: [MEXT] WGLC for draft-ietf-monami6-multiplecoa-05.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Romain, Thanks for comments. Please my reply inline. On 2008/02/07, at 6:48, Romain KUNTZ wrote: > Hi Ryuji, > > I have a couple more comments on some part of the draft: > > - Section 4.2.1: > Why is the O flag stored in the Binding ID option, and not the BU? > This would be more consistent in the case of the Bulk registration, > as this flag is supposed to be shared among all the Binding ID > options. Try not to consume the reserved field in BU. > - Section 5.6.3 > "If the home agent receives the [MCOA RETURNHOME WO/NDP]," > > Replace "home agent" with "mobile node" right. > > - Section 5.10 > "For Correspondent nodes, the mobile node cannot use the O flag > because of no bulk registration support. Thus, if necessary, it > MUST > sends a regular binding first to overwrite the remaining bindings at > the correspondent node. Then, it can re-register the set of > bindings > by using Multiple Care-of Address Registration. > > What is the problem to use the O flag with a single Binding ID > option? This is not considered as bulk registration, so why the MN > can't use O flag with CN? Correct. MN can send single binding with O flag set so that it can refresh the bindings on CN. > > - Section 6.3 > "* If the receiver has a regular binding which does not have BID > for the mobile node, it de-registers the regular binding and > registers a new binding including BID according to the Binding > Update. In this case, the receiver MUST return [MCOA BID > CONFLICT]." > > This IMHO contradicts what section 5.7 says: > > "o If [MCOA BID CONFLICT] is specified, the binding entry specified > by the Binding Identifier mobility option is already registered > as > a regular binding. In such case, the mobile node SHOULD stop > sending Binding Updates with BID, or SHOULD use O flag for the > peer to reset all the registered bindings." > > because on the HA side, the new binding (with BID) is registered, > but on the MN side it is advised to stop sending BU with BID option. > > Note also that MCOA_BID_CONFLICT is considered as a status for an > unsuccessful refistration (>128), so it also conflicts with the fact > that the HA accepts the new binding. right.. The home agent operation is wrong. The HA should not accept the bindings and reply the error code [BID- CONFLICT]. > - Section 6.3 > > "If all the above operations are successfully finished, the Binding > Acknowledgment containing the Binding Identifier mobility options > MUST be replied to the mobile node if A flag is set in the Binding > Acknowledgment." > > The last "Binding Acknowledgment" should be instead "Binding Update" > > "Whenever a Binding Acknowledgment is returned, all > the Binding Identifier mobility options stored in the Binding Update > MUST be copied to the Binding Acknowledgment." > > All the field must be copied EXCEPT the status field that must be > set to the previously decided value. right. we will correct this. Thanks for your comments again, ryuji > > > > > Cheers, > -- > Romain KUNTZ > kuntz@lsiit.u-strasbg.fr > Louis Pasteur University - Networks and Protocols Team > > > On 2008/02/03, at 11:31, marcelo bagnulo braun wrote: > >> Hi, >> >> With this email we issue the WGLC for draft-ietf-monami6- >> multiplecoa-05.txt >> The WGLC will be open till the 11 of february. >> We kindly ask the WG to review the document and provide comments. >> >> Please note that a valid comment at this stage is positive feedback >> about the document being ready to be shipped. >> So, please if you think the doc is ready, do express this to the ml >> (or to the chairs) >> >> For you convenience, additional information about the document: >> >> Title : Multiple Care-of Addresses Registration >> Author(s) : R. Wakikawa, et al. >> Filename : draft-ietf-monami6-multiplecoa-05.txt >> Pages : 44 >> Date : 2008-01-27 >> >> http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-05.txt >> >> Thanks, Julien and marcelo >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> http://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Feb 7 02:12:46 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FF7E3A76CE; Thu, 7 Feb 2008 02:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rfYMbN82dKC; Thu, 7 Feb 2008 02:12:45 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74C503A76D4; Thu, 7 Feb 2008 02:12:41 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E7D93A76D3 for ; Thu, 7 Feb 2008 02:12:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcL8XLSP-xRj for ; Thu, 7 Feb 2008 02:12:38 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 7A9F43A7626 for ; Thu, 7 Feb 2008 02:11:18 -0800 (PST) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m17AC0nl029047; Thu, 7 Feb 2008 12:12:18 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Feb 2008 12:11:58 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Feb 2008 12:11:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Feb 2008 12:11:56 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] IPsec use in draft-ietf-mext-nemo-v4traversal-00 Thread-Index: AchjOp+tBBZPPj39Q6+7x6ZGZVfkIgFco+GwADCPvvA= References: From: To: , X-OriginalArrivalTime: 07 Feb 2008 10:11:57.0336 (UTC) FILETIME=[DEFC5980:01C86971] X-Nokia-AV: Clean Subject: Re: [MEXT] IPsec use in draft-ietf-mext-nemo-v4traversal-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hesham Soliman wrote: > Hi Pasi, > > Thanks for the comments. The comments in the other email will be > handled in the next rev. Regarding these comments please see my > response below. > > > I do not think the spec is ready to be submitted to IESG > > without non-trivial work on the IPsec aspects. > > > > My main concerns are the following: > > > > First, while the basic idea behind the DSMIPv6-IPsec > > interaction seems doable, I am not convinced that an average > > implementor (i.e., someone who hasn't participated in writing > > this specification and doesn't have a PhD) could actually > > figure out how it works based on the current text. I would > > strongly suggest expanding the description in Section 5.1, and > > including e.g. message diagrams showing in what order the > > various local state updates and messages have to happen. In the > > off-list discussions thinking how to use IPsec, both Karen and > > I wrote such descriptions; merging them (and updating the > > details to match the latest discussions) could be a good > > starting point. I'm including my notes (which may not be fully > > up-to-date) at the end of this message; feel free to use them > > and/or Karen's text as starting points. > > => This is what I tried to do already. I haven't received comments > from Karen or Christian indicating dissatisfaction (not yet > anyway). The issue here is how much implementation detail should > we include without crossing the barrier from specification to > implementation. As I mentioned in the private discussions I'd like > the reader to know *what* needs to be done, but not necessarily > *how* to do it. So, if you think the order of events is not clear, > please give me some specific changes to make it clearer. The issue > of message diagrams is not really the key point IMO, as I think > any implementer knows the messages exchanged. I believe what we > want to show is what happens when. The messages exchanged over the wire are obvious; the local state updates needed when sending and receiving those messages are not. (I think this was pretty much proved in the email discussions earlier, when non-obvious bugs where found the descriptions even after several iterations.) The specific change I am proposing is text describing both the exchanged messages *and* the local state updates in the *order* they are required to happen. This would not constrain implementation, as any implementation with the same externally visible effects would be OK. > > Second, in places, the spec is close to the line drawn in water > > between using IPsec and actually changing the IPsec > > architecture. In particular, there are architectural details > > related to NATs that AFAIK are not present in any other use of > > IPsec (including plain Mobile IPv6). For example, > > > > - On MN side, it's assumed that after IPsec processing, some > > packets (in particular, BUs) are *not* processed as usual via > > IP forwarding, but are rather handed back to "DSMIPv6" code for > > special encapsulation. In other words, the treatment in IP > > forwarding ("Forwarding" box in RFC 4301, Section 5.1) depends > > on something else than the destination address, and more > > importantly, on something that isn't visible in the packet > > itself (after it has been encrypted) but is expected to survive > > IPsec processing. > > => MIPv6 does similar things architecturally anyway, like swapping > the home address with the content of the HAO. So, the idea of the > packet returning to the "calling function" to do things to it > before sending is not new. I don't find this similar at all. In MIPv6, packets that have been through IPsec processing are forwarded just like other packets, based on information in the packet headers. > > - On HA side, it's assumed that IPsec processing doesn't just > > decrypt the packet (and hand it over to IP forwarding), but also > > somehow preserves DSMIPv6-specific information (in particular, > > the IP address/port in the outermost IPv4 header) across the > > IPsec processing and eventually to the module processing BUs. > > => Correct. We could have avoided this using other alternatives > but there was no concensus. This is one of those issues that are > implementation dependent. Again the "calling function" could > preserve this information without relying on IPsec to do > so. Hence, there is no need to change IPsec architecture or > implementation. When I worked on MIPv6 implementations it was not > difficult to pass additional information around with the > packet. May be things changed now :) I was not arguing that this is untolerably bad, or that this cannot be implemented. I was arguing that this is an architecturally important topic which needs to be discussed in the document itself, not just emails on the list. > > 2) Section 5.1, "The home agent may also need to change NAT > > traversal fields in the IKE_SA." You can't figure out what this > > means unless you participated in the related email discussions. > > For HA, it probably means enabling "dynamic" update of address > > and port (in IKE_SA and tunnel mode IPsec SAs) based on incoming > > authenticated packets (even if they're not BUs), as described in > > RFC 4306 Section 2.23. > > => ok. > > > > > Text later actually requires the home agent to support this > > feature; however, there should be some discussion about its > > implications, as there are now *two* different ways how tunnel mode > > SAs can get updated (this "dynamic update" and ordinary BUs). > > => What implications do you see? Apart from supporting two different > methods? It basically means that the DS-MIPv6 module may not actually know where MN's packets get sent (i.e. what is effectively the MN's care-of-address). I find this pretty important thing to mention, as the reader might otherwise assume that (effectively) changing the CoA requires BU messages. Best reards, Pasi _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Feb 7 02:54:50 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50FC93A7717; Thu, 7 Feb 2008 02:54:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMw478KcVy0l; Thu, 7 Feb 2008 02:54:49 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27FBA3A76BE; Thu, 7 Feb 2008 02:54:49 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9159C3A7578 for ; Thu, 7 Feb 2008 02:54:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fapT0vzj-blm for ; Thu, 7 Feb 2008 02:54:47 -0800 (PST) Received: from omta02sl.mx.bigpond.com (omta02sl.mx.bigpond.com [144.140.93.154]) by core3.amsl.com (Postfix) with ESMTP id 0F0923A76BE for ; Thu, 7 Feb 2008 02:54:46 -0800 (PST) Received: from oaamta04sl.mx.bigpond.com ([124.190.105.201]) by omta02sl.mx.bigpond.com with ESMTP id <20080207105615.KOOB26674.omta02sl.mx.bigpond.com@oaamta04sl.mx.bigpond.com> for ; Thu, 7 Feb 2008 10:56:15 +0000 Received: from PC20005 ([124.190.105.201]) by oaamta04sl.mx.bigpond.com with ESMTP id <20080207105614.OZIU17660.oaamta04sl.mx.bigpond.com@PC20005>; Thu, 7 Feb 2008 10:56:14 +0000 From: "Hesham Soliman" To: , Date: Thu, 7 Feb 2008 21:55:50 +1000 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AchjOp+tBBZPPj39Q6+7x6ZGZVfkIgFco+GwADCPvvAAA6+ssA== In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A010206.47AAE3CF.006A,ss=1,fgs=0 Subject: Re: [MEXT] IPsec use in draft-ietf-mext-nemo-v4traversal-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I think I'm getting closer to understanding what you want changed. Some comments below. > > => This is what I tried to do already. I haven't received comments > > from Karen or Christian indicating dissatisfaction (not yet > > anyway). The issue here is how much implementation detail should > > we include without crossing the barrier from specification to > > implementation. As I mentioned in the private discussions I'd like > > the reader to know *what* needs to be done, but not necessarily > > *how* to do it. So, if you think the order of events is not clear, > > please give me some specific changes to make it clearer. The issue > > of message diagrams is not really the key point IMO, as I think > > any implementer knows the messages exchanged. I believe what we > > want to show is what happens when. > > The messages exchanged over the wire are obvious; the local state > updates needed when sending and receiving those messages are not. > (I think this was pretty much proved in the email discussions > earlier, when non-obvious bugs where found the descriptions even > after several iterations.) => Sure. > > The specific change I am proposing is text describing both the > exchanged messages *and* the local state updates in the *order* they > are required to happen. This would not constrain implementation, as > any implementation with the same externally visible effects would > be OK. => To avoid multiple iterations of the text again, let me reword the above to: The text needs to discuss the events resulting from the message exchanges in the order that they take place. Is this what you want? If so, I can re-arrange the text to make it more orderly and I would appreciate it if after that you can point out *exactly* the missing details. > > => MIPv6 does similar things architecturally anyway, like swapping > > the home address with the content of the HAO. So, the idea of the > > packet returning to the "calling function" to do things to it > > before sending is not new. > > I don't find this similar at all. In MIPv6, packets that have been > through IPsec processing are forwarded just like other packets, > based on information in the packet headers. => If we talk about forwarding then I don't think there is a change. I think what you mean is that some packets will have an IPv4 source address that does not match an existing tunnel. Correct me if I misunderstood you, but this is addressed in the following part of the text: Following this, the mobile node sends the binding update message to the home agent. In order to be able to send the binding update, the mobile node needs to use the new care-of address, which is different from the care-of address used in the existing tunnel. This should be done without permanently updating the tunnel with the home address to allow the mobile node to receive packets on the old care-of address until the binding acknowledgement is received. The method used to achieve this effect is implementation dependent and is outside the scope of this specification. Assuming that we agree that there is nothing technically wrong with the text, do you see the need for adding more detail to this? I want to know exactly what you're asking so I can update this once and for all. > > > - On HA side, it's assumed that IPsec processing doesn't just > > > decrypt the packet (and hand it over to IP forwarding), but also > > > somehow preserves DSMIPv6-specific information (in particular, > > > the IP address/port in the outermost IPv4 header) across the > > > IPsec processing and eventually to the module processing BUs. > > > > => Correct. We could have avoided this using other alternatives > > but there was no concensus. This is one of those issues that are > > implementation dependent. Again the "calling function" could > > preserve this information without relying on IPsec to do > > so. Hence, there is no need to change IPsec architecture or > > implementation. When I worked on MIPv6 implementations it was not > > difficult to pass additional information around with the > > packet. May be things changed now :) > > I was not arguing that this is untolerably bad, or that this cannot > be implemented. I was arguing that this is an architecturally > important topic which needs to be discussed in the document itself, > not just emails on the list. => Ok, I just want to make sure that we agree that there are no changes to IPsec implementations or architecture, I thought you were saying that. > > > Text later actually requires the home agent to support this > > > feature; however, there should be some discussion about its > > > implications, as there are now *two* different ways how > tunnel mode > > > SAs can get updated (this "dynamic update" and ordinary BUs). > > > > => What implications do you see? Apart from supporting two > different > > methods? > > It basically means that the DS-MIPv6 module may not actually know > where MN's packets get sent (i.e. what is effectively the MN's > care-of-address). I find this pretty important thing to mention, as > the reader might otherwise assume that (effectively) changing the > CoA requires BU messages. => I'm not sure I follow, you're talking about the DSMIPv6 module in the HA right? In the case of NAT, then changing the CoA requires a BU and an IKE dynamic update for the HA as a whole (DSMIP + IKE)to be informed of the MN's address . If no NAT, then a BU with the K flag would suffice. Since the DSMIPv6 module in the HA always knows whether a NAT is present or not, why is it confused? Thanks, Hesham > > Best reards, > Pasi > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Feb 7 07:22:03 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 273A73A79D1; Thu, 7 Feb 2008 07:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8Q33XQclNxr; Thu, 7 Feb 2008 07:22:02 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2969E3A79CB; Thu, 7 Feb 2008 07:22:01 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 322583A797D for ; Thu, 7 Feb 2008 07:22:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBjEHufrxvNo for ; Thu, 7 Feb 2008 07:21:59 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.191]) by core3.amsl.com (Postfix) with ESMTP id 87E173A78B3 for ; Thu, 7 Feb 2008 07:21:58 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id i7so798884tid.25 for ; Thu, 07 Feb 2008 07:23:28 -0800 (PST) Received: by 10.150.202.17 with SMTP id z17mr4711121ybf.139.1202397806330; Thu, 07 Feb 2008 07:23:26 -0800 (PST) Received: from klee.local ( [163.117.139.42]) by mx.google.com with ESMTPS id j9sm5184494mue.6.2008.02.07.07.23.23 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Feb 2008 07:23:25 -0800 (PST) From: Julien Laganier To: mext@ietf.org Date: Thu, 7 Feb 2008 16:23:17 +0100 User-Agent: KMail/1.9.6 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200802071623.17774.julien.IETF@laposte.net> Cc: Pasi.Eronen@nokia.com, Hesham Soliman Subject: Re: [MEXT] IPsec use in draft-ietf-mext-nemo-v4traversal-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Hesham, On Thursday 07 February 2008, Hesham Soliman wrote: > > [...] > > > The specific change I am proposing is text describing both the > > exchanged messages *and* the local state updates in the *order* > > they are required to happen. This would not constrain > > implementation, as any implementation with the same externally > > visible effects would be OK. > > => To avoid multiple iterations of the text again, let me reword the > above to: > The text needs to discuss the events resulting from the message > exchanges in the order that they take place. Is this what you want? > If so, I can re-arrange the text to make it more orderly and I would > appreciate it if after that you can point out *exactly* the missing > details. I fail to see the difference between what you and Pasi are saying and thus I am fine with both :) Could you re-arrange the text as you proposed and send it to the list, then Pasi (and others too!) can comment? > > > => MIPv6 does similar things architecturally anyway, like > > > swapping the home address with the content of the HAO. So, the > > > idea of the packet returning to the "calling function" to do > > > things to it before sending is not new. > > > > I don't find this similar at all. In MIPv6, packets that have been > > through IPsec processing are forwarded just like other packets, > > based on information in the packet headers. > > => If we talk about forwarding then I don't think there is a change. > I think what you mean is that some packets will have an IPv4 source > address that does not match an existing tunnel. Correct me if I > misunderstood you, but this is addressed in the following part of the > text: > > Following this, the mobile node sends the > binding update message to the home agent. In order to be able to > send the binding update, the mobile node needs to use the new care-of > address, which is different from the care-of address used in the > existing tunnel. This should be done without permanently updating the > tunnel with the home address to allow the mobile node to receive > packets on the old care-of address until the binding acknowledgement > is received. The method used to achieve this effect is implementation > dependent and is outside the scope of this specification. > > Assuming that we agree that there is nothing technically wrong with > the text, do you see the need for adding more detail to this? I want > to know exactly what you're asking so I can update this once and for > all. AFAIU, Pasi wants the text to be explicit about the fact that the new care-of-address needs to be attached as ancillary data to the BU before it is passed to IPsec, and that this information has to survive IPsec processing, i.e. it is still present after IPsec processing happened and the packet is passed back to DSMIP code, thus DSMIP has access to the new care-of address and can fill in the source address of the BU. This has implication on the use of IPsec since the IPsec architecture does not specify how such ancillary data can be passed along with a packet through an IPsec stack. Thus this is not implementation dependent, since any implementation would need IPsec to handle passing such ancillary data. In other words, I agree with Pasi's request. Pasi, am I reading you correctly? Feel free to correct me in case I'm not. > > > > - On HA side, it's assumed that IPsec processing doesn't just > > > > decrypt the packet (and hand it over to IP forwarding), but > > > > also somehow preserves DSMIPv6-specific information (in > > > > particular, the IP address/port in the outermost IPv4 header) > > > > across the IPsec processing and eventually to the module > > > > processing BUs. > > > > > > => Correct. We could have avoided this using other alternatives > > > but there was no concensus. This is one of those issues that are > > > implementation dependent. Again the "calling function" could > > > preserve this information without relying on IPsec to do > > > so. Hence, there is no need to change IPsec architecture or > > > implementation. When I worked on MIPv6 implementations it was > > > not difficult to pass additional information around with the > > > packet. May be things changed now :) > > > > I was not arguing that this is untolerably bad, or that this > > cannot be implemented. I was arguing that this is an > > architecturally important topic which needs to be discussed in the > > document itself, not just emails on the list. > > => Ok, I just want to make sure that we agree that there are no > changes to IPsec implementations or architecture, I thought you were > saying that. I think Pasi is actually arguing that this passing of meta-data attached to a packet thru an IPsec stack is actually not present in the IPsec architecture. As such, it is indeed an extension to the IPsec architecture as we know it, and would thus require changes to implementations of RFC4301. I think it's pretty clear it's not possible to buy an RFC4301 IPsec stack from vendor X and have it work "AS IS" together with a DSMIP implementation from vendor Y. > > > > Text later actually requires the home agent to support this > > > > feature; however, there should be some discussion about its > > > > implications, as there are now *two* different ways how > > > > tunnel mode > > > > > > SAs can get updated (this "dynamic update" and ordinary BUs). > > > > > > => What implications do you see? Apart from supporting two > > > > different > > > > > methods? > > > > It basically means that the DS-MIPv6 module may not actually know > > where MN's packets get sent (i.e. what is effectively the MN's > > care-of-address). I find this pretty important thing to mention, > > as the reader might otherwise assume that (effectively) changing > > the CoA requires BU messages. > > => I'm not sure I follow, you're talking about the DSMIPv6 module in > the HA right? In the case of NAT, then changing the CoA requires a BU > and an IKE dynamic update for the HA as a whole (DSMIP + IKE)to be > informed of the MN's address . If no NAT, then a BU with the K flag > would suffice. Since the DSMIPv6 module in the HA always knows > whether a NAT is present or not, why is it confused? Here I'm not sure what the issue is but it seems there's one. Let's try to sort that out. Best, --julien _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Feb 7 07:50:05 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38DE43A7A8F; Thu, 7 Feb 2008 07:50:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atPsyGd5RG6D; Thu, 7 Feb 2008 07:50:04 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DC303A7A6F; Thu, 7 Feb 2008 07:48:56 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5E883A7A68 for ; Thu, 7 Feb 2008 07:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZbVWvSjyBN5 for ; Thu, 7 Feb 2008 07:48:54 -0800 (PST) Received: from omta04sl.mx.bigpond.com (omta04sl.mx.bigpond.com [144.140.93.156]) by core3.amsl.com (Postfix) with ESMTP id 6DE1A3A7A74 for ; Thu, 7 Feb 2008 07:46:16 -0800 (PST) Received: from oaamta03sl.mx.bigpond.com ([124.190.105.201]) by omta04sl.mx.bigpond.com with ESMTP id <20080207154746.XBPY7960.omta04sl.mx.bigpond.com@oaamta03sl.mx.bigpond.com> for ; Thu, 7 Feb 2008 15:47:46 +0000 Received: from PC20005 ([124.190.105.201]) by oaamta03sl.mx.bigpond.com with ESMTP id <20080207154745.QKPQ28642.oaamta03sl.mx.bigpond.com@PC20005>; Thu, 7 Feb 2008 15:47:45 +0000 From: "Hesham Soliman" To: "'Julien Laganier'" , Date: Fri, 8 Feb 2008 02:47:21 +1000 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AchpnWZ4wg5A0O6vSN+lHAbCEny6PgACoROA In-Reply-To: <200802071623.17774.julien.IETF@laposte.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A010206.47AB2821.0060,ss=1,fgs=0 Cc: Pasi.Eronen@nokia.com Subject: Re: [MEXT] IPsec use in draft-ietf-mext-nemo-v4traversal-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > > => To avoid multiple iterations of the text again, let me > reword the > > above to: > > The text needs to discuss the events resulting from the message > > exchanges in the order that they take place. Is this what you want? > > If so, I can re-arrange the text to make it more orderly > and I would > > appreciate it if after that you can point out *exactly* the missing > > details. > > I fail to see the difference between what you and Pasi are > saying and > thus I am fine with both :) => That's my intention :) I wanted to be absolutely clear that we're on the same page. I know this might sound like an overkill but given the history of this work you can never be too sure and we need to get this out very soon. > > Could you re-arrange the text as you proposed and send it to > the list, > then Pasi (and others too!) can comment? => Yes. > > Following this, the mobile node sends the > > binding update message to the home agent. In order to be able to > > send the binding update, the mobile node needs to use the > new care-of > > address, which is different from the care-of address used in the > > existing tunnel. This should be done without permanently > updating the > > tunnel with the home address to allow the mobile node to receive > > packets on the old care-of address until the binding > acknowledgement > > is received. The method used to achieve this effect is > implementation > > dependent and is outside the scope of this specification. > > > > Assuming that we agree that there is nothing technically wrong with > > the text, do you see the need for adding more detail to > this? I want > > to know exactly what you're asking so I can update this > once and for > > all. > > AFAIU, Pasi wants the text to be explicit about the fact > that the new > care-of-address needs to be attached as ancillary data to > the BU before > it is passed to IPsec, and that this information has to > survive IPsec > processing, i.e. it is still present after IPsec processing happened > and the packet is passed back to DSMIP code, thus DSMIP has > access to > the new care-of address and can fill in the source address of the BU. => That's not how I read the comment on this part of the text, I think Pasi made that comment for the receiving end. But my response was that there is no need to pass ancillary information to IPsec because this information can be kept by the function that calls IPsec and when the packet returns, the information can be "appended" for the next function. This makes it implementation dependent and does not change IPsec interfaces. > > This has implication on the use of IPsec since the IPsec > architecture > does not specify how such ancillary data can be passed along with a > packet through an IPsec stack. Thus this is not implementation > dependent, since any implementation would need IPsec to > handle passing > such ancillary data. > > In other words, I agree with Pasi's request. > > Pasi, am I reading you correctly? Feel free to correct me in > case I'm > not. > > > => Ok, I just want to make sure that we agree that there are no > > changes to IPsec implementations or architecture, I > thought you were > > saying that. > > I think Pasi is actually arguing that this passing of > meta-data attached > to a packet thru an IPsec stack is actually not present in the IPsec > architecture. => But that's exactly the opposite of what I'm suggesting above . I actually thought Pasi and I were on the same page on this but now I'm confused, Pasi? Hesham As such, it is indeed an extension to the IPsec > architecture as we know it, and would thus require changes to > implementations of RFC4301. I think it's pretty clear it's > not possible > to buy an RFC4301 IPsec stack from vendor X and have it work "AS IS" > together with a DSMIP implementation from vendor Y. > > > > > > Text later actually requires the home agent to support this > > > > > feature; however, there should be some discussion about its > > > > > implications, as there are now *two* different ways how > > > > > > tunnel mode > > > > > > > > SAs can get updated (this "dynamic update" and > ordinary BUs). > > > > > > > > => What implications do you see? Apart from supporting two > > > > > > different > > > > > > > methods? > > > > > > It basically means that the DS-MIPv6 module may not > actually know > > > where MN's packets get sent (i.e. what is effectively the MN's > > > care-of-address). I find this pretty important thing to mention, > > > as the reader might otherwise assume that (effectively) changing > > > the CoA requires BU messages. > > > > => I'm not sure I follow, you're talking about the DSMIPv6 > module in > > the HA right? In the case of NAT, then changing the CoA > requires a BU > > and an IKE dynamic update for the HA as a whole (DSMIP + IKE)to be > > informed of the MN's address . If no NAT, then a BU with the K flag > > would suffice. Since the DSMIPv6 module in the HA always knows > > whether a NAT is present or not, why is it confused? > > Here I'm not sure what the issue is but it seems there's > one. Let's try > to sort that out. > > Best, > > --julien > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Feb 7 08:22:51 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F23503A79DD; Thu, 7 Feb 2008 08:22:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNsttOjUeYfy; Thu, 7 Feb 2008 08:22:49 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B547F3A79AD; Thu, 7 Feb 2008 08:22:49 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AB3E3A76B7 for ; Thu, 7 Feb 2008 08:22:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrhV4sqQq6BQ for ; Thu, 7 Feb 2008 08:22:47 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.185]) by core3.amsl.com (Postfix) with ESMTP id 0637D3A771C for ; Thu, 7 Feb 2008 08:22:45 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id i7so827058tid.25 for ; Thu, 07 Feb 2008 08:24:15 -0800 (PST) Received: by 10.150.143.14 with SMTP id q14mr4742574ybd.44.1202401454116; Thu, 07 Feb 2008 08:24:14 -0800 (PST) Received: from klee.local ( [163.117.139.42]) by mx.google.com with ESMTPS id j2sm16163520mue.3.2008.02.07.08.24.11 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Feb 2008 08:24:13 -0800 (PST) From: Julien Laganier To: "Hesham Soliman" Date: Thu, 7 Feb 2008 17:24:07 +0100 User-Agent: KMail/1.9.6 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200802071724.07386.julien.IETF@laposte.net> Cc: Pasi.Eronen@nokia.com, mext@ietf.org Subject: Re: [MEXT] IPsec use in draft-ietf-mext-nemo-v4traversal-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Thursday 07 February 2008, Hesham Soliman wrote: > =A0> > =3D> To avoid multiple iterations of the text again, let me > =A0> reword the > =A0> > above to: > =A0> > The text needs to discuss the events resulting from the message > =A0> > exchanges in the order that they take place. Is this what you > =A0> > want? If so, I can re-arrange the text to make it more orderly > =A0> > and I would appreciate it if after that you can point out > =A0> > *exactly* the missing details. > =A0> > =A0> I fail to see the difference between what you and Pasi are > =A0> saying and > =A0> thus I am fine with both :) > > =3D> That's my intention :) I wanted to be absolutely clear that we're > on the same page. > I know this might sound like an overkill but given the history of > this work you can never be too sure and we need to get this out very > soon. > > =A0> Could you re-arrange the text as you proposed and send it to > =A0> the list, > =A0> then Pasi (and others too!) can comment? > > =3D> Yes. Great! > =A0> > Following this, the mobile node sends the > =A0> > binding update message to the home agent. In order to be able > > > send the binding update, the mobile node needs to use the new > > > care-of address, which is different from the care-of address used > > > in the existing tunnel. This should be done without permanently > =A0> > updating the > =A0> > tunnel with the home address to allow the mobile node to receive > =A0> > packets on the old care-of address until the binding > =A0> > acknowledgement > =A0> > is received. The method used to achieve this effect is > =A0> > implementation > =A0> > dependent and is outside the scope of this specification. > =A0> > > =A0> > Assuming that we agree that there is nothing technically wrong > > > with the text, do you see the need for adding more detail to > > > this? I want to know exactly what you're asking so I can update > > > this once and for all. > =A0> > =A0> AFAIU, Pasi wants the text to be explicit about the fact > =A0> that the new > =A0> care-of-address needs to be attached as ancillary data to > =A0> the BU before > =A0> it is passed to IPsec, and that this information has to > =A0> survive IPsec > =A0> processing, i.e. it is still present after IPsec processing = > =A0> happened and the packet is passed back to DSMIP code, thus DSMIP = > > has access to the new care-of address and can fill in the source > > address of the BU. > > =3D> That's not how I read the comment on this part of the text, I > think Pasi made that comment for the receiving end. But my response > was that there is no need to pass ancillary information to IPsec > because this information can be kept by the function that calls IPsec > and when the packet returns, the information can be "appended" for > the next function. This makes it implementation dependent and does > not change IPsec interfaces. Ok, maybe I got confused between receive and transmit sides. = But anyway, the point is that you can't assume there's a function call. = That's most likely true only in the case of a native IPsec = implementation. But IPsec stacks are implemented in so many different = ways, what if it's a BITS? = Thus that is not implementation dependent since in every case, if = someone want to use a given IPsec stack with DSMIP, that stack needs to = handle survival of that ancillary data attached to a packet. It is implementation dependent whether or not IPsec processing occurs as = part of a function call that return a processed packet. If you're using = a STREAMS based IPsec stack, the function call you'd call for IPsec = processing will pass the packet to the IPsec STREAMS module and won't = return the processed packet. = Thus I think the requirement placed on the IPsec stack that it is able = to handle meta-data with BUs is not limited to implementation but is an = architectural extension. IMHO That should be written down. --julien _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Feb 7 10:30:20 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 603D13A799B; Thu, 7 Feb 2008 10:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTC1OWiSOOTg; Thu, 7 Feb 2008 10:30:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEE763A79A5; Thu, 7 Feb 2008 10:30:16 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD9CB3A79A5 for ; Thu, 7 Feb 2008 10:30:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOy82yESzXte for ; Thu, 7 Feb 2008 10:30:10 -0800 (PST) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id CD4B93A762B for ; Thu, 7 Feb 2008 10:30:09 -0800 (PST) Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Feb 2008 10:31:39 -0800 Message-ID: <47AB4E8A.4050100@azairenet.com> Date: Thu, 07 Feb 2008 10:31:38 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: George Tsirtsis References: In-Reply-To: X-OriginalArrivalTime: 07 Feb 2008 18:31:39.0634 (UTC) FILETIME=[ADD3F520:01C869B7] Cc: Julien Laganier , Ryuji Wakikawa , mext@ietf.org Subject: Re: [MEXT] WGLC for draft-ietf-monami6-multiplecoa-05.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi George, Thanks for the extensive review. It was very useful. I am adopting most of the editorial changes you suggested. Only responding to those that might need more discussion below. George Tsirtsis wrote: > A mobile node MAY change the value of a BID at any time > according to its administrative policy, for instance to protect > its privacy. > = > GT> I do not understand this. If BID changes then it has to be updated > at the HA side, so it has some impact in HA scalability. = Yes, it would need to be updated on the home agent. > It is also > not clear what the privacy concern is here. The above is removed. Perhaps a constant BID is one of those things you could use to track a mobile node's communication. But I also think it should be removed. Its not really a big concern unless you are changing the home address also at the same time. > A new identification number (BID) is introduced to distinguish > multiple bindings pertaining to the same Home Address. Once a mobile > node gets several IPv6 global addresses on one or more of its > interfaces, it can register these addresses with its home agent. If > the mobile node wants to register multiple bindings, it MUST generate > a BID for each care-of address and record the BID into the binding > update list. A mobile node can manipulate each binding independently > by using a BID. The mobile node then registers its care-of addresses > by sending a Binding Update with a Binding Identifier mobility > option. The BID MUST be included in the Binding Identifier mobility > option. After receiving such Binding Update and Binding Identifier > mobility option, the home agent MUST copy the BID from the Binding > Identifier mobility option to the corresponding field in the binding > cache entry. Even if there is already an entry for the mobile node's > home address, the home agent MUST register a new binding entry for > the BID stored in the Binding Identifier mobility option. > = > GT> Not clear Re-wrote the paragraph. A new extension called the Binding identification number (BID) is introduced to distinguish multiple bindings pertaining to the same Home Address. If a mobile node configures several IPv6 global addresses on one or more of its interfaces, it can register these addresses with its home agent as care-of addresses. If the mobile node wants to register multiple bindings, it MUST generate a BID for each care-of address and store the BID in the binding update list. A mobile node can manipulate each binding independently by using the BIDs. The mobile node then registers its care-of addresses by sending a Binding Update with a Binding Identifier mobility option. The BID is included in the Binding Identifier mobility option. After receiving the Binding Update with a Binding Identifier mobility option, the home agent MUST copy the BID from the Binding Identifier mobility option to the corresponding field in the binding cache entry. If there is an existing binding cache entry for the mobile node, and the if the BID in the Binding Update does not match the one with the existing entry, the home agent MUST create a new binding cache entry for the new care-of address and BID. The mobile node can register multiple care-of addresses either independently in individual Binding Updates or multiple at once in a single Binding Update. > The mobile > node registers multiple care-of addresses either independently in > individual Binding Updates or multiple at once in a single Binding > Update. > = > If the mobile host wishes to register its binding with a > correspondent node, it must perform return routability operations. > The mobile host MUST manage a Care-of Keygen Token per care-of > address. The mobile host exchanges CoTI and CoT for the > corresponding care-of addresses if necessary. When the mobile host > registers several care-of addresses to a correspondent node, it uses > the same BID as the one generated for the home registration's > bindings. > = > GT> Why does the same BID have to be used in the HA and the CNs? It > may make sense to implement it this way but why is this required? Not sure why. I modified the text to say it is recommended. See below for the entire paragraph. > The binding registration step is the same as for the home > registration except for calculating authenticator. > = > GT> What is different in the calculation of the authenticator? I think the intention was to say that this BU is protected by the Binding Authorization Data option. I think this sentence should be removed. The protection for a BU sent to a CN is different from the BU sent to a home agent. That is already known to the mobile node. The new paragraph reads If the mobile host wishes to register its binding with a correspondent node, it must perform return routability operations. This includes managing a Care-of Keygen token per care-of address and exchanging CoTi and CoT message with the correspondent node for each care-of address. It is RECOMMENDED that the mobile node uses the same BID that it used with the home agent for a particular care-of address. For protocol simplicity, bulk registration to correspondent nodes is not supported in this document. This is because the Return Routability mechanism introduced in [RFC-3775] cannot be easily extended to verify multiple care-of addresses stored in a single Binding Update. > When a home agent and a correspondent node check the binding cache > database for the mobile node, they search a corresponding binding > entry with the pair of Home Address and BID of the desired binding. > If necessary, a mobile node can use policy and filter information to > look up the best binding per sessions, flow, packets, but this is out > of scope in this document. If there is no desired binding, it > searches the binding cache database with the Home Address as > specified in Mobile IPv6. The first matched binding entry may be > found, although this is implementation dependent. > = > = > GT> IMHO this whole paragraph should be removed. It is cinfusing and > does not say anything useful. I believe this is the paragraph that provides a description of how binding cache lookup is done using the BID. So here is a re-write Binding cache lookup is done based on the Home Address and BID information. This is different from RFC 3775, where only the home address is used for binding cache lookup. The binding cache lookup may also involve policy or flow filters in cases where some policy or flow filters are used to direct certain packets or flows to a particular care-of address. The binding cache lookup using policy or flow filters is out of scope for this document. In case the binding cache lookup, using the combination of home address and BID, does not return a valid binding cache entry, the home agent MAY perform another lookup based on only the home address. This is implementation dependent and configurable on the home agent. > Care-of address (C) flag > = > When this flag is set, a mobile node can store a Care-of Address > corresponding to the BID in the Binding Identifier mobility > option. > = > GT> The above sentence make no sense to me. Assuming I understand what > you mean. maybe you can use the following: "When this flag is set, BID > Mobility Option includes a care-off address field." See below for the re-written paragraph. > = > This flag MUST be used whenever a mobile node sends > multiple care-of addresses in a single Binding Update, i.e. bulk > registration. It MUST be also used for the independent binding > registration as a substitute for an alternate care-of address > option. This flag is valid only for binding update sent to the > home agent. > = > GT> Several things are not clear. The C-flag must be set for > individual as well as bulk binding registrations correct? = It is a MUST for bulk registrations. Not for individual registrations. I think the intention was to say that if the mobile node is going to use the alt CoA option in a BU with the BID option, it can just include the CoA in the BID option. Does not have to include the alt CoA option. If yes > rephrase to make this clearer. Why is C-flag a substitute to the > alt-CoA?? Is there a case where this option is included in a BU and > C-flag is NOT set? Needs to be re-written. Care-of address (C) flag When this flag is set, it indicates that a valid care-of address is present in the care-of address field in the BID mobility option. This flag MUST be set whenever the mobile node sends multiple care-of addresses in a single Binding Update, i.e., bulk registration. It MAY also used as a substitute for alternate care-of address option even for binding updates that are sent only for one care-of address. This flag is valid only for binding update sent to the home agent. > 5. Mobile Node Operation > = > 5.1. Management of Care-of Addresses and Binding Identifier > = > There are two cases when a mobile node has several Care-of Addresses. > Note that a mixture of the two cases are possible. > = > = > 1. A mobile node uses several physical network interfaces and > acquires a care-of address on each of its interfaces. > = > 2. A mobile node uses a single physical network interface, but > multiple prefixes are announced on the link the interface is > attached to. Several global addresses are configured on this > interface for each of the announced prefixes. > = > The difference between the above two cases is only a number of > physical network interfaces and therefore does not matter in this > document. > = > = > The Identification number is used to identify a binding. > To implement this, a mobile node MAY assign an identification number > for each care-of addresses. How to assign an identification number > is implementation specific, but the following rules MUST be followed. > = > GT> IMHO the above 3 sentences are not useful and should be removed. > If you want to keep them change "Identification" with "BID", otherwise > they are confusing. Removed. > 5.4. Binding Bulk Registration > = > The bulk registration is an optimization for registering multiple > care-of addresses only to a home agent by using a single Binding > Update. > = > GT> More accurate: "The bulk registration is an optimization for > binding multiple care-of addresses to a single home address by using a > single Binding > Update." Re-written as The bulk registration is an optimization for binding multiple care-of addresses to a home address by using a single Binding Update. If a mobile node, for instance, does not want to send a lot of signaling messages through an interface where the bandwidth is scarce, it can use this bulk registration mechanism. > A mobile node sets the C flag in a Binding Identifier mobility option > and includes the particular care-of address in the Binding Identifier > mobility option. The mobile node stores multiple sets of a Binding > Identifier mobility option in a Binding Update as shown in Figure 3. > = > GT> I am re-writing the above paragraph for clarity: > " To use bulk registration the mobile node includes a Binding > Identifier Mobility option for each BID and Care-of address pair it > wants to register in the same Binding Update message. > = > In the bulk registration, all the other binding information such as > Lifetime, Sequence Number, binding Flags are shared among the bulked > Care-of Addresses. > = > GT> It is not clear what you mean here. Is this "other binding > information" in the regular BU fields? or you mean something else? > Please clarify. re-wrote it To use bulk registration, the mobile node includes a Binding Identifier Mobility option for each BID and Care-of address pair it wants to register in the same binding update message. This is shown in Figure 3. The rest of the fiels and options in the binding update such as Lifetime, Sequence Number, the flags in the Binding Update are common across all care-of addresses. The alternate care-of address option MUST NOT be used. > The receiver will remove only the care-of > address(es) that matches to the specified BID. For the bulk de- > registration, the care-of addresses field of each mobility option > SHOULD be omitted, because the receiver will remove all the care-of > addresses matching the specified BID. > = > GT> Is the care-of address field required in the individual > de-registrations? The BIDs should be sufficient to identify the > bindings that need to be removed. If you agree please clarify. I don't think the care-of address is needed. The BID should be sufficient. Ryuji? > 5.6. Returning Home > = > The mobile node may return to the home link, by attaching to the home > link through one of the interfaces on the mobile node. > = > When the > mobile node wants to return home, it should be configured with what > interface it needs to use. > = > GT> Remove the above sentence. What 'home link' means and how it is > defined is already described in RFC3775. Not clear. There are two sentences aboves. One of them says that the mobile node can return home by attaching to the home link through *one* of the interfaces. The second one says, the mobile node should be configure with the information on which interface it should use to attach to the home link. Aren't both required? > These bindings at > correspondent node MUST be created before a mobile node returns home. > = > GT> Why? CN bindings do not affect and are not affected by the > bindings at the HA. I would just remove this sentence. Agreed. Nothing stops the mobile node from doing a care-of address text or home address test. > = > 5.6.2. Using only Interface attached to the Visited Link > = > The mobile node returns home and shutdown the interface attached to > the home link as shown in Figure 10. The binding of the home > attached interface MUST be deleted by sending a de-registration > binding update from one of active interface attached to the foreign > links. This scenario is not the most efficient because all the > traffic from and to the mobile node is going through the bi- > directional tunnel, whereas the mobile node is now accessible at one > hop from its home agent. > = > = > GT> This is badly written. This section describes procedures for > returning home, in which case it makes no sense to de-register a > binding to the home interface=85which can not possibly exist. This > scenario instead is one where when the MN detects that an interface is > connected to the home link e.g., receives an RA including its HNP, it > shuts down that interface. In other words, the MN chooses never to > connect to its home link. hmmm.. The above paragraph assumes that there was a care-of address associated with that interface and there was corresponding binding for that care-of address (and BID) on the home agent. That binding would need to be deleted. Here is the re-written paragraph. The mobile node returns home and shuts down the interface attached to the home link as shown in Figure 10. Before shutting down the interface, any binding for the care-of address previously associated with the interface should be deleted. To delete the binding cache entry, the mobile node MUST send a de-registration binding update with the lifetime set to zero and include the corresponding BID information. This scenario is not the most efficient because all the traffic from and to the mobile node is going through the bi- directional tunnel, whereas the mobile node is now accessible at one hop from its home agent. > In this specification, the home agent MUST intercept all the packets > meant for the mobile node and decide whether to send the traffic > directly to the home address on the link or tunnel to the care-of > address. The home agent would make this decision based on the type > of packets and flows. How to make this decision is out of scope in > this document. The delicate part would be to create a neighbor cache > entry for the mobile node so that the home agent can deliver the > packets on-link. > = > The home agent would need to know the Layer-2 > address of the interface with which the mobile node is attached to > the home link. > = > GT> Why is the L2 address necessary? This could be based on Interface > ID or other information. I would remove the last sentence. For constructing the ether header for example. Since the home agent is still defending the home address, it cannot send a neighbor solicitation and get a neighbor advertisement from the mobile node to create a neighbor cache entry. > When the home agent sends the Binding Acknowledgment, it MUST store > one of two status values such as [Binding Update Accepted (0)] [MCOA > RETURNHOME WO/NDP (TBD)] in the BID mobility option depending on home > agent configuration at the home link. The new values are: > = > o Binding Update Accepted (0): NDP is permitted for the home address > at the home link. This is regular returning home operation of > [RFC3775] > = > o MCOA RETURNHOME WO/NDP (TBD): NDP is prohibited for the home > address at the home link > = > When the home agent is the only router at the home link, it can > intercept all the packets by IP routing without proxy NDP. It stops > proxy ND for the requested home address and replies the [Binding > Update Accepted] value to the mobile node. The neighbor cache entry > for the mobile node is created by the regular NDP operation (i.e. > NS/NA exchange). On the other hand, if the home agent is not the > only router, it MUST continue defending the home address by proxy NDP > to capture all the mobile node's traffic. The home agent, then, > returns [MCOA RETURNHOME WO/NDP] value in the Status field of the BID > mobility option. The home agent also learns the mobile node's > layer-2 address (i.e. MAC address) during this binding de- > registration. It keeps the learned layer-2 address as the neighbor > cache entry for the mobile node so that it can construct the layer-2 > header for the packets meant for the mobile node and forwards them > directly to the mobile node's interface attached to the home link. > = > According to [RFC3775], the mobile node MUST NOT assign the home > address to the interface attached to the home link and MUST NOT > attempt NDP operations for the home address before the completion of > binding de-registration. It MUST NOT send and reply to Neighbor > Solicitation for the home address. The home address MUST be > tentative address at this moment until it receives Binding > Acknowledgment with success status value. > = > When the mobile node receives the binding acknowledgment and BID > mobility option, it assigns home address at the interface attached to > the home link according to the status field of the BID. If the value > is [Binding Update Accepted], the mobile node can start defending the > home address using NDP. The home agent can create neighbor cache > entry for the mobile node by NS and NA exchange as normal IPv6 > operation. > = > If the home agent receives the [MCOA RETURNHOME WO/NDP], it MUST NOT > defends its home address at the home link by NDP. When the mobile > node sends packets from the interface attached to the home link, it > MUST learn the layer2 address (i.e. MAC address) of the next hop > (i.e. default router, it can be home agent) during the binding de- > registration and construct the packet including layer 2 header with > the learned home agent's layer-2 address. > = > GT> This whole section is very badly written. Will try to improve it in the next revision. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Feb 7 14:27:29 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B9FC3A7C25; Thu, 7 Feb 2008 14:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClE5UkHYmxjb; Thu, 7 Feb 2008 14:27:27 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF88A3A7C2A; Thu, 7 Feb 2008 14:27:17 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AABFB3A7C29 for ; Thu, 7 Feb 2008 14:27:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26MV3nbDsIyz for ; Thu, 7 Feb 2008 14:27:15 -0800 (PST) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by core3.amsl.com (Postfix) with ESMTP id CA2EB3A7AD7 for ; Thu, 7 Feb 2008 14:26:02 -0800 (PST) Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m17MRL0R016223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 7 Feb 2008 14:27:21 -0800 Received: from [129.46.78.229] (dhcp-bldg-l7-78-7.qualcomm.com [129.46.78.229]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m17MRJoH015099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Feb 2008 14:27:20 -0800 (PST) Message-ID: <47AB85C3.7060408@qualcomm.com> Date: Thu, 07 Feb 2008 14:27:15 -0800 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: George Tsirtsis References: <7892795E1A87F04CADFCCF41FADD00FC051C02A0@xmb-ams-337.emea.cisco.com> <4C47BAA9-BA58-45F7-BDCF-2C050118BACE@it.uc3m.es> <6D19CA8D71C89C43A057926FE0D4ADAA232B6D@ecamlmw720.eamcs.ericsson.se> In-Reply-To: Cc: Charles Clancy , Christian Vogt , Julien Laganier , mext@ietf.org Subject: [MEXT] MIP threats (Re: re-direction attack on MCoA) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Suresh, George, all, Please see draft-vidya-ip-mobility-threats-01 draft-vidya-ip-mobility-sec-reqs-01 Christian, Charles, Vidya and I have been working on the same topic and = wrote those documents (we hope to prepare an update before the next = meeting). Perhaps these could be a starting point? regards, Lakshminath On 1/31/2008 3:08 AM, George Tsirtsis wrote: > I am of course also interested in this work. I guess we already have > enough people to get the ball rolling on this. > = > Thanks > George > = > On Jan 31, 2008 10:59 AM, Suresh Krishnan = wrote: >> Hi Marcelo, >> I am willing to work on a generic MIPv6 threats document along with th= e other interested people. >> >> Cheers >> Suresh >> >> -----Original Message----- >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >> Sent: January 31, 2008 11:13 AM >> To: Wassim Haddad >> Cc: Julien Laganier; mext@ietf.org >> >> Subject: Re: [MEXT] re-direction attack on MCoA >> >> >> El 30/01/2008, a las 19:16, Wassim Haddad escribi=F3: >>> =3D> As there is a clear interest in the redirection attack on the HA >>> side, I volunteer to do some work on this one. >>> >> I think the work should be general to all residual threats on MIP as >> George mentioned, i think this would be more interesting since it >> would allow us to put the different threats in perspective and figure >> out which ones we should address. >> >> >> >>> Regards, >>> >>> Wassim H. >>> >>> >>>> El 30/01/2008, a las 18:19, Wassim Haddad escribi=F3: >>>> >>>>> Hi Marcelo, >>>>> IMHO, this topic has to be included as a new item in the new >>>>> charter and >>>>> should not be limited to MCoA. >>>>> Regards, >>>>> Wassim H. >>>>> On Wed, 30 Jan 2008, marcelo bagnulo braun wrote: >>>>>> Pascal, >>>>>> The question at this point is the following one: do you think >>>>>> that this threat should be addressed in the MCoA draft itself? >>>>>> comments? >>>>>> Regards, marcelo >>>>>> El 30/01/2008, a las 10:09, Pascal Thubert (pthubert) escribi=F3: >>>>>>> I agree with Wassim on both mails. >>>>>>> There's also the situation where the MN/MR might be fooled by the >>>>>>> visited network into believing that the CoA (or its prefix if a >>>>>>> network >>>>>>> is attacked as opposed to a host) is on the visited link. DSMIP >>>>>>> is also >>>>>>> exposed, in particular with IPv4 CoAs. >>>>>>> There are many scenarios that do not involve high mobility were >>>>>>> a 3-way >>>>>>> or a 4-way handshake could be used to verify the CoA. We have >>>>>>> proposed >>>>>>> such a test in section 6 of the RRH draft that uses a triggered >>>>>>> 2nd BU >>>>>>> flow to verify the CoA in the first one: >>>>>>> http://tools.ietf.org/html/draft-thubert-nemo-reverse-routing-heade= r-07# >>>>>>> section-6 >>>>>>> Pascal >>>>>>>> -----Original Message----- >>>>>>>> From: Wassim Haddad [mailto:whaddad@tcs.hut.fi] >>>>>>>> Sent: mercredi 30 janvier 2008 09:32 >>>>>>>> To: Benjamin Lim >>>>>>>> Cc: 'Julien Laganier'; mext@ietf.org >>>>>>>> Subject: RE: [MEXT] re-direction attack on MCoA >>>>>>>> On Wed, 30 Jan 2008, Benjamin Lim wrote: >>>>>>>>> All in all, what I am trying to say is that tracing only >>>>>>>>> limits the >>>>>>>>> effect of the attack from escalating further and not >>>>>>>>> preventing it. >>>>>>>> =3D> which (again) also perfectly applies to a single CoA. >>>>>>>> Regards, >>>>>>>> Wassim H. >>>>>>>> _______________________________________________ >>>>>>>> MEXT mailing list >>>>>>>> MEXT@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/mext >>>>>>> _______________________________________________ >>>>>>> MEXT mailing list >>>>>>> MEXT@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/mext >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/mext >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mext >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www1.ietf.org/mailman/listinfo/mext >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www1.ietf.org/mailman/listinfo/mext >> > = > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext > = _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Feb 7 15:08:03 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98C763A790A; Thu, 7 Feb 2008 15:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EIvN9glx8zl; Thu, 7 Feb 2008 15:08:02 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C2E03A79CB; Thu, 7 Feb 2008 15:08:02 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F13193A79CB for ; Thu, 7 Feb 2008 15:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMc0Ysujqz+0 for ; Thu, 7 Feb 2008 15:08:00 -0800 (PST) Received: from omta02sl.mx.bigpond.com (omta02sl.mx.bigpond.com [144.140.93.154]) by core3.amsl.com (Postfix) with ESMTP id E2F063A78C3 for ; Thu, 7 Feb 2008 15:07:59 -0800 (PST) Received: from oaamta01sl.mx.bigpond.com ([124.190.105.201]) by omta02sl.mx.bigpond.com with ESMTP id <20080207230928.TWDA26674.omta02sl.mx.bigpond.com@oaamta01sl.mx.bigpond.com> for ; Thu, 7 Feb 2008 23:09:28 +0000 Received: from PC20005 ([124.190.105.201]) by oaamta01sl.mx.bigpond.com with ESMTP id <20080207230927.SEOY2036.oaamta01sl.mx.bigpond.com@PC20005>; Thu, 7 Feb 2008 23:09:27 +0000 From: "Hesham Soliman" To: "'Julien Laganier'" Date: Fri, 8 Feb 2008 10:08:53 +1000 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Achppe0xowK66MkmRW+RykSq7g4fFQAQGOFw In-Reply-To: <200802071724.07386.julien.IETF@laposte.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A010205.47AB8FA7.0023,ss=1,fgs=0 Cc: Pasi.Eronen@nokia.com, mext@ietf.org Subject: Re: [MEXT] IPsec use in draft-ietf-mext-nemo-v4traversal-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > > Ok, maybe I got confused between receive and transmit sides. > > But anyway, the point is that you can't assume there's a > function call. > That's most likely true only in the case of a native IPsec > implementation. But IPsec stacks are implemented in so many > different > ways, what if it's a BITS? > > Thus that is not implementation dependent since in every case, if > someone want to use a given IPsec stack with DSMIP, that > stack needs to > handle survival of that ancillary data attached to a packet. > > It is implementation dependent whether or not IPsec > processing occurs as > part of a function call that return a processed packet. If > you're using > a STREAMS based IPsec stack, the function call you'd call for IPsec > processing will pass the packet to the IPsec STREAMS module > and won't > return the processed packet. => Good points. I think that clarifies what I was missing about the architectural issue. although any interaction within a node is by definition an "implementation issue" :) this is a serious point that should be highlighted given the pseudo standard APIs that exist. > > Thus I think the requirement placed on the IPsec stack that > it is able > to handle meta-data with BUs is not limited to > implementation but is an > architectural extension. IMHO That should be written down. => Sure. Hesham > > --julien > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Feb 8 01:45:08 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34BA328C1D2; Fri, 8 Feb 2008 01:45:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rwq6bI-CWiil; Fri, 8 Feb 2008 01:45:07 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17E2728C1AD; Fri, 8 Feb 2008 01:45:07 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D5C528C1AD for ; Fri, 8 Feb 2008 01:45:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOpKsDOsCPVt for ; Fri, 8 Feb 2008 01:45:05 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by core3.amsl.com (Postfix) with ESMTP id EA4AA28C150 for ; Fri, 8 Feb 2008 01:45:04 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id 16so3020111fgg.41 for ; Fri, 08 Feb 2008 01:46:33 -0800 (PST) Received: by 10.86.59.2 with SMTP id h2mr11479341fga.78.1202463993286; Fri, 08 Feb 2008 01:46:33 -0800 (PST) Received: from ?192.168.1.106? ( [163.117.139.42]) by mx.google.com with ESMTPS id 4sm24597447fgg.4.2008.02.08.01.46.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 08 Feb 2008 01:46:31 -0800 (PST) Message-ID: <47AC24F6.4020502@laposte.net> Date: Fri, 08 Feb 2008 10:46:30 +0100 From: Julien Laganier User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: Cc: Pasi.Eronen@nokia.com, mext@ietf.org Subject: Re: [MEXT] IPsec use in draft-ietf-mext-nemo-v4traversal-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Hesham, All right, looks good -- we seem to be on the same page now. I'm looking forward to your updated text and progressing the document towards IESG. Best, --julien Hesham Soliman wrote: > > > > Ok, maybe I got confused between receive and transmit sides. > > > > But anyway, the point is that you can't assume there's a > > function call. > > That's most likely true only in the case of a native IPsec > > implementation. But IPsec stacks are implemented in so many > > different > > ways, what if it's a BITS? > > > > Thus that is not implementation dependent since in every case, if > > someone want to use a given IPsec stack with DSMIP, that > > stack needs to > > handle survival of that ancillary data attached to a packet. > > > > It is implementation dependent whether or not IPsec > > processing occurs as > > part of a function call that return a processed packet. If > > you're using > > a STREAMS based IPsec stack, the function call you'd call for IPsec > > processing will pass the packet to the IPsec STREAMS module > > and won't > > return the processed packet. > > => Good points. I think that clarifies what I was missing about the > architectural issue. although any interaction within a node is by definition > an "implementation issue" :) this is a serious point that should be > highlighted given the pseudo standard APIs that exist. > > > > > Thus I think the requirement placed on the IPsec stack that > > it is able > > to handle meta-data with BUs is not limited to > > implementation but is an > > architectural extension. IMHO That should be written down. > > => Sure. > > Hesham > > > > > --julien _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Feb 8 02:52:26 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C46228C20E; Fri, 8 Feb 2008 02:52:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FVBaabDJahq; Fri, 8 Feb 2008 02:52:25 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75C3F28C218; Fri, 8 Feb 2008 02:52:24 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6913228C218 for ; Fri, 8 Feb 2008 02:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPLSD-4+fuEI for ; Fri, 8 Feb 2008 02:52:19 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id C08BF28C212 for ; Fri, 8 Feb 2008 02:51:25 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m18AqSQM005793; Fri, 8 Feb 2008 12:52:44 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Feb 2008 12:52:36 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Feb 2008 12:52:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 8 Feb 2008 12:52:34 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] IPsec use in draft-ietf-mext-nemo-v4traversal-00 Thread-Index: AchjOp+tBBZPPj39Q6+7x6ZGZVfkIgFco+GwADCPvvAAA6+ssAAwf7hg References: From: To: , X-OriginalArrivalTime: 08 Feb 2008 10:52:36.0642 (UTC) FILETIME=[B756A820:01C86A40] X-Nokia-AV: Clean Subject: Re: [MEXT] IPsec use in draft-ietf-mext-nemo-v4traversal-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hesham Soliman wrote: > > The specific change I am proposing is text describing both the > > exchanged messages *and* the local state updates in the *order* > > they are required to happen. This would not constrain > > implementation, as any implementation with the same externally > > visible effects would be OK. > > => To avoid multiple iterations of the text again, let me reword the > above to: The text needs to discuss the events resulting from the > message exchanges in the order that they take place. Is this what > you want? If so, I can re-arrange the text to make it more orderly > and I would appreciate it if after that you can point out *exactly* > the missing details. I think we're on the same page here, but given the complexity of the topic, getting it nailed down in one iteration may be difficult. There are two events particularly worth discussing: - Movement: here the tricky parts (as we discovered in earlier email discussions) are the specific order of state changes, especially IPsec-related state. - Initial connection in IPv4 (when the MN is powered on and contacts HA for the first time): here the non-obvious details are related to transport and tunnel mode SAs working in totally different way with DSMIPv6, and to different tunneling formats. (About the latter point, Section 4.1 has some incorrect text about there being three possible formats for tunneling packets between MN and HA -- I'm counting five in the current spec: vanilla IP-in-UDP, IP-in-TLV-in-UDP, IP-in-IP, IP-in-ESP, and IP-in-ESP-in-UDP. The latter two require quite different treatment at certain points.) > > > => MIPv6 does similar things architecturally anyway, like > > > swapping the home address with the content of the HAO. So, the > > > idea of the packet returning to the "calling function" to do > > > things to it before sending is not new. > > > > I don't find this similar at all. In MIPv6, packets that have > > been through IPsec processing are forwarded just like other > > packets, based on information in the packet headers. > > => If we talk about forwarding then I don't think there is a > change. I guess we disagree about this, then; I think that forwarding packets based on some information which isn't in the packet header would be a change compared to plain MIPv6. (Also, IPsec architecture in RFC4301 is not really described in terms of functional calls, but rather packets flowing through different components.) > I think what you mean is that some packets will have an IPv4 source > address that does not match an existing tunnel. Correct me if I > misunderstood you, but this is addressed in the following part of > the text: > > Following this, the mobile node sends the binding update message > to the home agent. In order to be able to send the binding > update, the mobile node needs to use the new care-of address, > which is different from the care-of address used in the existing > tunnel. This should be done without permanently updating the > tunnel with the home address to allow the mobile node to receive > packets on the old care-of address until the binding > acknowledgement is received. The method used to achieve this > effect is implementation dependent and is outside the scope of > this specification. > > Assuming that we agree that there is nothing technically wrong with > the text, do you see the need for adding more detail to this? I want > to know exactly what you're asking so I can update this once and for > all. The detail I'm concerned is interaction with the IPsec architecture as specified in RFC 4301 (in terms of packets flowing through components, not as function calls). DSMIPv6 requires some additions to that which, as far as I know, are not present in *any* other use of IPsec. > > I was not arguing that this is untolerably bad, or that this cannot > > be implemented. I was arguing that this is an architecturally > > important topic which needs to be discussed in the document itself, > > not just emails on the list. > > => Ok, I just want to make sure that we agree that there are > no changes to IPsec implementations or architecture, I thought you > were saying that. No, I guess we don't agree on that: I think this is a (small) change to IPsec architecture, and will require changes in many IPsec implementations. (Certainly it can be implemented, and it's not untolerably bad either.) > > It basically means that the DS-MIPv6 module may not actually know > > where MN's packets get sent (i.e. what is effectively the MN's > > care-of-address). I find this pretty important thing to mention, as > > the reader might otherwise assume that (effectively) changing the > > CoA requires BU messages. > > => I'm not sure I follow, you're talking about the DSMIPv6 module in > the HA right? In the case of NAT, then changing the CoA requires a > BU and an IKE dynamic update for the HA as a whole (DSMIP + IKE)to > be informed of the MN's address . If no NAT, then a BU with the K > flag would suffice. Since the DSMIPv6 module in the HA always knows > whether a NAT is present or not, why is it confused? Yes, I'm talking about the DSMIPv6 module in the HA. My point is that the "HA as a whole" may not have consistent view of the CoA: if IPsec tunnel mode SAs are updated via the IPsec dynamic updates, then the "effective CoA" (the address where HA actually sends the packets) can be different than what the DSMIPv6 module thinks it is. This is a somewhat unobvious property that normal MIPv6 doesn't have, and IMHO needs explicit discussion in the document. Best regards, Pasi _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Feb 8 02:57:17 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1099528C223; Fri, 8 Feb 2008 02:57:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4SXV3Wdc-cs; Fri, 8 Feb 2008 02:57:16 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10CD528C20D; Fri, 8 Feb 2008 02:57:16 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7DCC28C20C for ; Fri, 8 Feb 2008 02:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ct9AiYpwtqW for ; Fri, 8 Feb 2008 02:57:14 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id B4D6828C20E for ; Fri, 8 Feb 2008 02:56:47 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m18Ax6XQ032165; Fri, 8 Feb 2008 04:59:33 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Feb 2008 12:58:12 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Feb 2008 12:58:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 8 Feb 2008 12:58:11 +0200 Message-ID: In-Reply-To: <200802071623.17774.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] IPsec use in draft-ietf-mext-nemo-v4traversal-00 Thread-Index: AchpnWk1KZx8pTGFSISsqNjQG36tBgAo2jrw References: <200802071623.17774.julien.IETF@laposte.net> From: To: , X-OriginalArrivalTime: 08 Feb 2008 10:58:12.0494 (UTC) FILETIME=[7F859AE0:01C86A41] X-Nokia-AV: Clean Subject: Re: [MEXT] IPsec use in draft-ietf-mext-nemo-v4traversal-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Julien Laganier wrote: > AFAIU, Pasi wants the text to be explicit about the fact that the > new care-of-address needs to be attached as ancillary data to the BU > before it is passed to IPsec, and that this information has to > survive IPsec processing, i.e. it is still present after IPsec > processing happened and the packet is passed back to DSMIP code, > thus DSMIP has access to the new care-of address and can fill in the > source address of the BU. > > This has implication on the use of IPsec since the IPsec > architecture does not specify how such ancillary data can be passed > along with a packet through an IPsec stack. Thus this is not > implementation dependent, since any implementation would need IPsec > to handle passing such ancillary data. > > In other words, I agree with Pasi's request. > > Pasi, am I reading you correctly? Feel free to correct me in case > I'm not. This is a reasonably accurate summary of my concern here. Note that such ancillary data may be needed in both directions. On HA, the new CoA from outermost IP header needs to survive IPsec decryption; on MN, the information needed to correctly forward the packet needs to survive IPsec encryption -- and the MN's packet forwarding code needs extensions so that it actually looks at this data (i.e. current code for stuffing packets to IP-in-IP tunnels may not be able to check that ancilliary data to see that actually some packets need to be tunneled differently.) Best regards, Pasi _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Feb 8 08:34:24 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1A963A8179; Fri, 8 Feb 2008 08:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHPm97VMdqnu; Fri, 8 Feb 2008 08:34:23 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 988ED3A78B3; Fri, 8 Feb 2008 08:34:23 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D9DA3A78B3 for ; Fri, 8 Feb 2008 08:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMaNYmpBZhty for ; Fri, 8 Feb 2008 08:34:21 -0800 (PST) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id 10D653A6B82 for ; Fri, 8 Feb 2008 08:34:21 -0800 (PST) Received: from [127.0.0.1] ([98.207.82.216]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Feb 2008 08:35:50 -0800 Message-ID: <47AC84E3.2030605@azairenet.com> Date: Fri, 08 Feb 2008 08:35:47 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: mext@ietf.org References: In-Reply-To: X-OriginalArrivalTime: 08 Feb 2008 16:35:50.0731 (UTC) FILETIME=[AA5F41B0:01C86A70] Cc: Julien Laganier , Ryuji Wakikawa Subject: Re: [MEXT] WGLC for draft-ietf-monami6-multiplecoa-05.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello, There is a pre-06 version of this draft available at http://dvijay.com/ietf/internet-drafts/mext/mcoa.txt The draft has been cleaned up a bit. In case, you haven't reviewed the document yet, please review the pre-06 version. In case you have already reviewed version 05, please send your comments based on version 05. The diff between 05 and pre-06 can be found at http://dvijay.com/ietf/internet-drafts/mext/diff-05-06.html Vijay marcelo bagnulo braun wrote: > Hi, > > With this email we issue the WGLC for draft-ietf-monami6- > multiplecoa-05.txt > The WGLC will be open till the 11 of february. > We kindly ask the WG to review the document and provide comments. > > Please note that a valid comment at this stage is positive feedback > about the document being ready to be shipped. > So, please if you think the doc is ready, do express this to the ml > (or to the chairs) > > For you convenience, additional information about the document: > > Title : Multiple Care-of Addresses Registration > Author(s) : R. Wakikawa, et al. > Filename : draft-ietf-monami6-multiplecoa-05.txt > Pages : 44 > Date : 2008-01-27 > > http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-05.txt > > Thanks, Julien and marcelo > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Feb 8 12:10:39 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91D1928C500; Fri, 8 Feb 2008 12:10:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XiuJ92jxn3Fh; Fri, 8 Feb 2008 12:10:39 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5110628C54D; Fri, 8 Feb 2008 12:09:49 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53B5D28C51B for ; Fri, 8 Feb 2008 12:09:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MeO3DXk2tMAg for ; Fri, 8 Feb 2008 12:09:47 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 529CF28C570 for ; Fri, 8 Feb 2008 12:09:38 -0800 (PST) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m18KARQZ019190; Fri, 8 Feb 2008 14:12:21 -0600 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Feb 2008 22:10:45 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Feb 2008 14:10:43 -0600 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 8 Feb 2008 14:09:24 -0600 Message-ID: In-Reply-To: <47A8B10E.1000801@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Firewall work Thread-Index: Acho3mTtwNwb1IMwS3+9Osk0t1QHhQBrpYpw References: <47A8B10E.1000801@ericsson.com> From: To: , X-OriginalArrivalTime: 08 Feb 2008 20:10:43.0281 (UTC) FILETIME=[AEEE4410:01C86A8E] X-Nokia-AV: Clean Cc: mext@ietf.org, julien.ietf@laposte.net Subject: Re: [MEXT] Firewall work X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I also think that the documents are ready for adoption. - Gabor -----Original Message----- From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of ext Suresh Krishnan Sent: Tuesday, February 05, 2008 10:55 AM To: marcelo bagnulo braun Cc: Julien Laganier; mext@ietf.org Subject: Re: [MEXT] Firewall work Hi Marcelo, I have read the documents and I think they are ready to be adopted as wg items. Thanks Suresh (Full Disclosure: I am one of the authors) marcelo bagnulo braun wrote: > Hi Folks, > > during last IETF meeting, the DT presented their work and we agreed > that people will read the drafts and comment to see if we adopt them > as the WG items for this work. > > I remind you the documents are: > > - Guidelines for firewall administrators regarding MIPv6 traffic > draft-krishnan-mip6-firewall-admin-02 > - Guidelines for firewall vendors regarding MIPv6 traffic > draft-krishnan-mip6-firewall-vendor-02 > > Please read and comment so we can figure out if we adopt these docs or > what to do. > > Regards, marcelo > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Feb 10 09:08:40 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A7803A687D; Sun, 10 Feb 2008 09:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.555 X-Spam-Level: X-Spam-Status: No, score=-5.555 tagged_above=-999 required=5 tests=[AWL=1.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQQSJzm4N2vf; Sun, 10 Feb 2008 09:08:39 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E3233A6868; Sun, 10 Feb 2008 09:08:39 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F09A03A6850 for ; Sun, 10 Feb 2008 09:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jb-N+uEqVB6w for ; Sun, 10 Feb 2008 09:08:38 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 05B953A67B4 for ; Sun, 10 Feb 2008 09:08:38 -0800 (PST) Received: from [163.117.203.28] (unknown [163.117.203.28])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp01.uc3m.es (Postfix) with ESMTP id 2F5FA39BEBFfor ; Sun, 10 Feb 2008 17:17:10 +0100 (CET) Message-Id: <7E0F1525-DC6F-427D-B885-DFB493AE98D1@it.uc3m.es> From: marcelo bagnulo braun To: mext@ietf.org Mime-Version: 1.0 (Apple Message framework v915) Date: Sun, 10 Feb 2008 17:17:11 +0100 References: <20080209084809.577663A8176@core3.amsl.com> X-Mailer: Apple Mail (2.915) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-8.9970 TC:1F TRN:16 TV:5.0.1023(15722.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Subject: [MEXT] Fwd: MEXT - Requested sessions have been scheduled for IETF 71 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org FYI Inicio del mensaje reenviado: > De: IETF Secretariat > Fecha: 9 de febrero de 2008 09:48:09 GMT+01:00 > Para: marcelo@it.uc3m.es > Cc: julien.ietf@laposte.net, jari.arkko@piuha.net, > townsley@cisco.com, session-request@ietf.org > Asunto: MEXT - Requested sessions have been scheduled for IETF 71 > > Dear Marcelo Bagnulo, > > The sessions that you have requested have been scheduled. > Below is the scheduled session information followed by > the information of sessions that you have requested. > > MEXT Session 1 (2.5 hours) > Tuesday, Morning Session I 0900-1130 > Room Name: Breakout Room > ---------------------------------------------- > MEXT Session 2 (2.5 hours) > Thursday, Morning Session I 0900-1130 > Room Name: Breakout Room > ---------------------------------------------- _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Feb 11 01:53:33 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABBCA3A6B00; Mon, 11 Feb 2008 01:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=-2.033, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhDP5-LnW9A5; Mon, 11 Feb 2008 01:53:32 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67F8B3A68E7; Mon, 11 Feb 2008 01:53:32 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69B213A68E7 for ; Mon, 11 Feb 2008 01:53:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrHrTG+Ywnqs for ; Mon, 11 Feb 2008 01:53:27 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id F19C83A6895 for ; Mon, 11 Feb 2008 01:53:26 -0800 (PST) Received: from chelo-it-uc3m-es.it.uc3m.es (unknown [163.117.139.71])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp01.uc3m.es (Postfix) with ESMTP id 4CFE939F61E; Mon, 11 Feb 2008 10:54:51 +0100 (CET) Message-Id: <00115188-2AC9-460B-A325-437BD77F7D3E@it.uc3m.es> From: marcelo bagnulo braun To: Lakshminath Dondeti In-Reply-To: <47AB85C3.7060408@qualcomm.com> Mime-Version: 1.0 (Apple Message framework v915) Date: Mon, 11 Feb 2008 10:54:53 +0100 References: <7892795E1A87F04CADFCCF41FADD00FC051C02A0@xmb-ams-337.emea.cisco .com> <4C47BAA9-BA58-45F7-BDCF-2C050118BACE@it.uc3m.es> <6D19CA8D71C89C43A057926FE0D4ADAA232B6D@ ecamlmw720.eamcs.ericsson.se> <47AB85C3.7060408@qualcomm.com> X-Mailer: Apple Mail (2.915) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-39.5431 TC:1F TRN:64 TV:5.0.1023(15722.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: Julien Laganier , mext@ietf.org, Christian Vogt , Charles Clancy Subject: Re: [MEXT] MIP threats (Re: re-direction attack on MCoA) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Lakshminath, I haven't review the document, but the document that i understand = George, Wassim and Ben are thinking about is an analysis of residual = threats in rfc3775 (or more in general in MIPv6). I mean, assuming all = the security measures currently available, what threats are still = there and whether we need to address them. One clear case if the case = of flooding attack towards a given using the HA, as Ben and other = folks have noticed Regards, marcelo El 07/02/2008, a las 23:27, Lakshminath Dondeti escribi=F3: > Hi Suresh, George, all, > > Please see > draft-vidya-ip-mobility-threats-01 > draft-vidya-ip-mobility-sec-reqs-01 > > Christian, Charles, Vidya and I have been working on the same topic = > and > wrote those documents (we hope to prepare an update before the next > meeting). Perhaps these could be a starting point? > > regards, > Lakshminath > > On 1/31/2008 3:08 AM, George Tsirtsis wrote: >> I am of course also interested in this work. I guess we already have >> enough people to get the ball rolling on this. >> >> Thanks >> George >> >> On Jan 31, 2008 10:59 AM, Suresh Krishnan > > wrote: >>> Hi Marcelo, >>> I am willing to work on a generic MIPv6 threats document along = >>> with the other interested people. >>> >>> Cheers >>> Suresh >>> >>> -----Original Message----- >>> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >>> Sent: January 31, 2008 11:13 AM >>> To: Wassim Haddad >>> Cc: Julien Laganier; mext@ietf.org >>> >>> Subject: Re: [MEXT] re-direction attack on MCoA >>> >>> >>> El 30/01/2008, a las 19:16, Wassim Haddad escribi=F3: >>>> =3D> As there is a clear interest in the redirection attack on the HA >>>> side, I volunteer to do some work on this one. >>>> >>> I think the work should be general to all residual threats on MIP as >>> George mentioned, i think this would be more interesting since it >>> would allow us to put the different threats in perspective and = >>> figure >>> out which ones we should address. >>> >>> >>> >>>> Regards, >>>> >>>> Wassim H. >>>> >>>> >>>>> El 30/01/2008, a las 18:19, Wassim Haddad escribi=F3: >>>>> >>>>>> Hi Marcelo, >>>>>> IMHO, this topic has to be included as a new item in the new >>>>>> charter and >>>>>> should not be limited to MCoA. >>>>>> Regards, >>>>>> Wassim H. >>>>>> On Wed, 30 Jan 2008, marcelo bagnulo braun wrote: >>>>>>> Pascal, >>>>>>> The question at this point is the following one: do you think >>>>>>> that this threat should be addressed in the MCoA draft itself? >>>>>>> comments? >>>>>>> Regards, marcelo >>>>>>> El 30/01/2008, a las 10:09, Pascal Thubert (pthubert) escribi=F3: >>>>>>>> I agree with Wassim on both mails. >>>>>>>> There's also the situation where the MN/MR might be fooled by = >>>>>>>> the >>>>>>>> visited network into believing that the CoA (or its prefix if a >>>>>>>> network >>>>>>>> is attacked as opposed to a host) is on the visited link. DSMIP >>>>>>>> is also >>>>>>>> exposed, in particular with IPv4 CoAs. >>>>>>>> There are many scenarios that do not involve high mobility were >>>>>>>> a 3-way >>>>>>>> or a 4-way handshake could be used to verify the CoA. We have >>>>>>>> proposed >>>>>>>> such a test in section 6 of the RRH draft that uses a triggered >>>>>>>> 2nd BU >>>>>>>> flow to verify the CoA in the first one: >>>>>>>> http://tools.ietf.org/html/draft-thubert-nemo-reverse-routing-head= er-07# >>>>>>>> section-6 >>>>>>>> Pascal >>>>>>>>> -----Original Message----- >>>>>>>>> From: Wassim Haddad [mailto:whaddad@tcs.hut.fi] >>>>>>>>> Sent: mercredi 30 janvier 2008 09:32 >>>>>>>>> To: Benjamin Lim >>>>>>>>> Cc: 'Julien Laganier'; mext@ietf.org >>>>>>>>> Subject: RE: [MEXT] re-direction attack on MCoA >>>>>>>>> On Wed, 30 Jan 2008, Benjamin Lim wrote: >>>>>>>>>> All in all, what I am trying to say is that tracing only >>>>>>>>>> limits the >>>>>>>>>> effect of the attack from escalating further and not >>>>>>>>>> preventing it. >>>>>>>>> =3D> which (again) also perfectly applies to a single CoA. >>>>>>>>> Regards, >>>>>>>>> Wassim H. >>>>>>>>> _______________________________________________ >>>>>>>>> MEXT mailing list >>>>>>>>> MEXT@ietf.org >>>>>>>>> https://www1.ietf.org/mailman/listinfo/mext >>>>>>>> _______________________________________________ >>>>>>>> MEXT mailing list >>>>>>>> MEXT@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/mext >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/mext >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mext >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mext >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mext >>> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www1.ietf.org/mailman/listinfo/mext >> > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Feb 11 02:51:29 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E5F53A6B0A; Mon, 11 Feb 2008 02:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.795 X-Spam-Level: X-Spam-Status: No, score=-0.795 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpGxv0r8QNvW; Mon, 11 Feb 2008 02:51:27 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D597B3A6AD5; Mon, 11 Feb 2008 02:51:27 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD8E73A6AF2 for ; Mon, 11 Feb 2008 02:51:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rt-qINUG+Isu for ; Mon, 11 Feb 2008 02:51:24 -0800 (PST) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.234]) by core3.amsl.com (Postfix) with ESMTP id 6B50F3A6AD5 for ; Mon, 11 Feb 2008 02:51:24 -0800 (PST) Received: by wx-out-0506.google.com with SMTP id s8so5261097wxc.31 for ; Mon, 11 Feb 2008 02:52:49 -0800 (PST) Received: by 10.142.83.4 with SMTP id g4mr8377949wfb.28.1202727168933; Mon, 11 Feb 2008 02:52:48 -0800 (PST) Received: by 10.142.11.11 with HTTP; Mon, 11 Feb 2008 02:52:48 -0800 (PST) Message-ID: Date: Mon, 11 Feb 2008 10:52:48 +0000 From: "George Tsirtsis" To: "marcelo bagnulo braun" In-Reply-To: <00115188-2AC9-460B-A325-437BD77F7D3E@it.uc3m.es> MIME-Version: 1.0 Content-Disposition: inline References: <4C47BAA9-BA58-45F7-BDCF-2C050118BACE@it.uc3m.es> <47AB85C3.7060408@qualcomm.com> <00115188-2AC9-460B-A325-437BD77F7D3E@it.uc3m.es> Cc: Julien Laganier , Charles Clancy , Christian Vogt , mext@ietf.org Subject: Re: [MEXT] MIP threats (Re: re-direction attack on MCoA) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Yes, it is in my todo list to read those as I create a presentation for this for the IETF meeting. George On Feb 11, 2008 9:54 AM, marcelo bagnulo braun wrote: > Hi Lakshminath, > > I haven't review the document, but the document that i understand > George, Wassim and Ben are thinking about is an analysis of residual > threats in rfc3775 (or more in general in MIPv6). I mean, assuming all > the security measures currently available, what threats are still > there and whether we need to address them. One clear case if the case > of flooding attack towards a given using the HA, as Ben and other > folks have noticed > > Regards, marcelo > > > El 07/02/2008, a las 23:27, Lakshminath Dondeti escribi=F3: > > > Hi Suresh, George, all, > > > > Please see > > draft-vidya-ip-mobility-threats-01 > > draft-vidya-ip-mobility-sec-reqs-01 > > > > Christian, Charles, Vidya and I have been working on the same topic > > and > > wrote those documents (we hope to prepare an update before the next > > meeting). Perhaps these could be a starting point? > > > > regards, > > Lakshminath > > > > On 1/31/2008 3:08 AM, George Tsirtsis wrote: > >> I am of course also interested in this work. I guess we already have > >> enough people to get the ball rolling on this. > >> > >> Thanks > >> George > >> > >> On Jan 31, 2008 10:59 AM, Suresh Krishnan >> > wrote: > >>> Hi Marcelo, > >>> I am willing to work on a generic MIPv6 threats document along > >>> with the other interested people. > >>> > >>> Cheers > >>> Suresh > >>> > >>> -----Original Message----- > >>> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > >>> Sent: January 31, 2008 11:13 AM > >>> To: Wassim Haddad > >>> Cc: Julien Laganier; mext@ietf.org > >>> > >>> Subject: Re: [MEXT] re-direction attack on MCoA > >>> > >>> > >>> El 30/01/2008, a las 19:16, Wassim Haddad escribi=F3: > >>>> =3D> As there is a clear interest in the redirection attack on the HA > >>>> side, I volunteer to do some work on this one. > >>>> > >>> I think the work should be general to all residual threats on MIP as > >>> George mentioned, i think this would be more interesting since it > >>> would allow us to put the different threats in perspective and > >>> figure > >>> out which ones we should address. > >>> > >>> > >>> > >>>> Regards, > >>>> > >>>> Wassim H. > >>>> > >>>> > >>>>> El 30/01/2008, a las 18:19, Wassim Haddad escribi=F3: > >>>>> > >>>>>> Hi Marcelo, > >>>>>> IMHO, this topic has to be included as a new item in the new > >>>>>> charter and > >>>>>> should not be limited to MCoA. > >>>>>> Regards, > >>>>>> Wassim H. > >>>>>> On Wed, 30 Jan 2008, marcelo bagnulo braun wrote: > >>>>>>> Pascal, > >>>>>>> The question at this point is the following one: do you think > >>>>>>> that this threat should be addressed in the MCoA draft itself? > >>>>>>> comments? > >>>>>>> Regards, marcelo > >>>>>>> El 30/01/2008, a las 10:09, Pascal Thubert (pthubert) escribi=F3: > >>>>>>>> I agree with Wassim on both mails. > >>>>>>>> There's also the situation where the MN/MR might be fooled by > >>>>>>>> the > >>>>>>>> visited network into believing that the CoA (or its prefix if a > >>>>>>>> network > >>>>>>>> is attacked as opposed to a host) is on the visited link. DSMIP > >>>>>>>> is also > >>>>>>>> exposed, in particular with IPv4 CoAs. > >>>>>>>> There are many scenarios that do not involve high mobility were > >>>>>>>> a 3-way > >>>>>>>> or a 4-way handshake could be used to verify the CoA. We have > >>>>>>>> proposed > >>>>>>>> such a test in section 6 of the RRH draft that uses a triggered > >>>>>>>> 2nd BU > >>>>>>>> flow to verify the CoA in the first one: > >>>>>>>> http://tools.ietf.org/html/draft-thubert-nemo-reverse-routing-he= ader-07# > >>>>>>>> section-6 > >>>>>>>> Pascal > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Wassim Haddad [mailto:whaddad@tcs.hut.fi] > >>>>>>>>> Sent: mercredi 30 janvier 2008 09:32 > >>>>>>>>> To: Benjamin Lim > >>>>>>>>> Cc: 'Julien Laganier'; mext@ietf.org > >>>>>>>>> Subject: RE: [MEXT] re-direction attack on MCoA > >>>>>>>>> On Wed, 30 Jan 2008, Benjamin Lim wrote: > >>>>>>>>>> All in all, what I am trying to say is that tracing only > >>>>>>>>>> limits the > >>>>>>>>>> effect of the attack from escalating further and not > >>>>>>>>>> preventing it. > >>>>>>>>> =3D> which (again) also perfectly applies to a single CoA. > >>>>>>>>> Regards, > >>>>>>>>> Wassim H. > >>>>>>>>> _______________________________________________ > >>>>>>>>> MEXT mailing list > >>>>>>>>> MEXT@ietf.org > >>>>>>>>> https://www1.ietf.org/mailman/listinfo/mext > >>>>>>>> _______________________________________________ > >>>>>>>> MEXT mailing list > >>>>>>>> MEXT@ietf.org > >>>>>>>> https://www1.ietf.org/mailman/listinfo/mext > >>>>>> _______________________________________________ > >>>>>> MEXT mailing list > >>>>>> MEXT@ietf.org > >>>>>> https://www1.ietf.org/mailman/listinfo/mext > >>>> _______________________________________________ > >>>> MEXT mailing list > >>>> MEXT@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/mext > >>> > >>> _______________________________________________ > >>> MEXT mailing list > >>> MEXT@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/mext > >>> > >>> _______________________________________________ > >>> MEXT mailing list > >>> MEXT@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/mext > >>> > >> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mext > >> > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > http://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Feb 11 07:06:58 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49F613A6C74; Mon, 11 Feb 2008 07:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.383 X-Spam-Level: ** X-Spam-Status: No, score=2.383 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dYd1zCs98+G; Mon, 11 Feb 2008 07:06:48 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17B8D3A6C22; Mon, 11 Feb 2008 07:06:48 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7D753A6C45 for ; Mon, 11 Feb 2008 07:06:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0JAoGa6mltw for ; Mon, 11 Feb 2008 07:06:38 -0800 (PST) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.178]) by core3.amsl.com (Postfix) with ESMTP id 2A7503A6C5C for ; Mon, 11 Feb 2008 07:06:31 -0800 (PST) Received: by el-out-1112.google.com with SMTP id j27so2206227elf.25 for ; Mon, 11 Feb 2008 07:07:57 -0800 (PST) Received: by 10.142.98.18 with SMTP id v18mr72560wfb.61.1202742475894; Mon, 11 Feb 2008 07:07:55 -0800 (PST) Received: by 10.142.11.11 with HTTP; Mon, 11 Feb 2008 07:07:55 -0800 (PST) Message-ID: Date: Mon, 11 Feb 2008 15:07:55 +0000 From: "George Tsirtsis" To: "Vijay Devarapalli" In-Reply-To: <47AC84E3.2030605@azairenet.com> MIME-Version: 1.0 Content-Disposition: inline References: <47AC84E3.2030605@azairenet.com> Cc: Julien Laganier , Ryuji Wakikawa , mext@ietf.org Subject: Re: [MEXT] WGLC for draft-ietf-monami6-multiplecoa-05.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Vijay/Ryuji et.al., This version (pre-6) is much improved so well done. There are still several minor technical issues, unlear text, and nits, which I indicate below, but I want to highlight a few more important technical issues upfront: 1) Lifetime of BIDs: I think the relation between BIDs and BU Lifetime field is not clear. I think the assumption has been that the Lifetime is common across all BIDs. IMO there needs to be more explicit language in the spec to make this clear.. - a BU with one or more BIDs, O=3D0, and Lifetime !=3D 0, updates the lifetime of all the BIDs in the binding cache. i.e., to maintain all the BIDs you just need to send a Binding refresh including at least BID.(right?) - a BU with O=3D1 replaces all BIDs and associates them with lifetime in th= e BU - a BU with one or more BIDs, O=3D0, and Lifetime =3D 0, removes only the listed BIDs and does not affect the lifetime of other BIDs in the binding cache - a BU with lifetime=3D0 and H=3D1 indicates the MN is at home link, but the lifetime of other BIDs is not affected. How is the home link state maintained though? This looks like hard state at the moment and I do not like it. Any ideas? 2) Changing BIDs. the draft indicates that BIDs can be changed for privacy reasons. While I still do not understand what these reasons are, I also do not see anywhere how BIDs can be changed. Is is done by sending a BU with a new BID mapped to a CoA that is already in the binding cache (but mapped to another BID)? I indicate that this could be added somewhere inline, but some additional care also needs to be taken e.g., can you reuse the BID you are replacing in the same BU? 3) Section 5.6.2 (using only IF attached to visitied) is very confusing: I copy here the comment I also placed inline below: My understanding is that in this scenario the MN simply DOES NOT connect to the home link. If the MN connected to a link which is identified or detected to be its home link, it simply disconnects without sending a BU to the HA. So, as far as the HA is concerned the MN is NOT connected at its home link and operations continue as normal. The text in this section, however, says something different which does not match my understanding at all. Am I confused? Thanks again for all the effort and see the rest of the detailed review bel= ow. George ---------------------------------------------------------------------------= ---------------------------------------------------- 1. Introduction ... But assigning a single home address to a node is more advantageous than assigning multiple home addresses because applications do not need to be aware of the multiplicity of home addresses. GT> I am not sure I agree with this statement. I think effective use of multiple home addresses by applications is a better and more robust technique but it does require applications to be written in a certain way. Multiple CoAs allow multihoming awareness to be outsourced to a different part of the IP stack but, especially when combined with per flow bindings, it results in routing that is not purely destination address based. This is not necessarily a good thing for Internet routing as a whole and only acceptable because it is only confined in HAs. I think we can have a bit better applicability statement that is more objective and looks at the big picture. i.e., at the architectural limitations of this approach. ... 3. Protocol Overview A new extension called the Binding identification number (BID) is GT> I think the name of the extension is "Binding Identifier Mobility Optio= n"? introduced to distinguish between multiple bindings pertaining to the same home address. If a mobile node configures several IPv6 global addresses on one or more of its interfaces, it can register these addresses with its home agent as care-of addresses. If the mobile node wants to register multiple bindings, it MUST generate a BID for each care-of address and store the BID in the binding update list. A mobile node can manipulate each binding independently by using the BIDs. The mobile node then registers its care-of addresses by sending a Binding Update with a Binding Identifier mobility option. The BID is included in the Binding Identifier mobility option. After receiving the Binding Update with a Binding Identifier mobility option, the home agent MUST copy the BID from the Binding Identifier mobility option to the corresponding field in the binding cache entry. If there is an existing binding cache entry for the mobile node, and the if the BID in the Binding Update does not match the one GT> // and the if/ and if with the existing entry, the home agent MUST create a new binding cache entry for the new care-of address and BID. The mobile node can register multiple care-of addresses either independently in individual Binding Updates or multiple at once in a single Binding Update. If the mobile host wishes to register its binding with a correspondent node, it must perform return routability operations. This includes managing a Care-of Keygen token per care-of address and exchanging CoTi and CoT message with the correspondent node for each care-of address. It is RECOMMENDED that the mobile node uses the same BID that it used with the home agent for a particular care-of address. GT> I do not see why this is RECOMMENDED either :-). At most this is a MAY, since I can not think of any reason why this not totally an implementation decision. For protocol simplicity, bulk registration to correspondent nodes is not supported in this document. This is because the Return Routability mechanism introduced in [RFC-3775] cannot be easily extended to verify multiple care-of addresses stored in a single Binding Update. If the mobile node decides to act as a regular mobile node compliant with [RFC-3775], it sends a Binding Update without any Binding Identifier mobility options. The receiver of the Binding Update deletes all the bindings registering with a BID and registers only a single binding for the mobile node. Note that the mobile node can continue using BID even if only has a single binding is active. GT> //BID even if only has a/BIDs even if it has only a/ Binding cache lookup is done based on the home address and BID information. This is different from RFC 3775, where only the home address is used for binding cache lookup. The binding cache lookup may also involve policy or flow filters in cases where some policy or flow filters are used to direct certain packets or flows to a particular care-of address. The binding cache lookup using policy or flow filters is out of scope for this document. In case the binding cache lookup, using the combination of home address and BID, does not return a valid binding cache entry, the home agent MAY perform another lookup based on only the home address. This is implementation dependent and configurable on the home agent. The mobile node may return to the home link through one of its interfaces. There are three options possible for the mobile node when its returns home. 1. The mobile node uses only the interface with which it attaches to the home link. It de-registers all bindings related to all care-of addresses. The interfaces still attached to the visited link are no longer going to be receiving any encapsulated traffic GT> //link/link(s) from the home agent. 2. The mobile node uses only the interfaces still attached to the visited link. GT> //link/link(s) The interface with which the mobile node attaches to the home link is not used. 3. The mobile node may simultaneously use both the interface attached to the home link and the interfaces still attached to the visited links. GT> //links/link(s) ... Wakikawa (Ed.), et al. Expires August 11, 2008 [Page 8] Internet-Draft MCoA February 2008 Status When the Binding Identifier mobility option is included in a Binding Acknowledgement, this field overwrites the status field correspondent to each binding in the Binding Acknowledgement. If this field is zero, the receiver MUST use the registration status stored in the Binding Acknowledgement message. This Status field can be used to carry error information for a Care-of Test message. The status is 8-bit unsigned integer. The possible status codes are the same as the status codes of Binding Acknowledgement. GT> This is not true, right? New values are defined in section 4.5. Care-of address (C) flag When this flag is set, it indicates that a valid care-of address is present in the care-of address field in the BID mobility option. This flag MUST be set whenever the mobile node sends multiple care-of addresses in a single Binding Update, i.e., bulk registration. It MAY also used as a substitute for alternate care-of address option even for Binding Updates that are sent only for one care-of address. This flag is valid only for Binding Update sent to the home agent. Overwrite (O) flag When this flag is set, a mobile node requests the recipient to replace all the bindings to binding entries stored in a Binding Update. Simultaneous Home and Foreign Binding (H) flag This flag indicates that the mobile node registers multiple bindings to the home agent while is attached to the home link. This flag is valid only for a Binding Update sent to the home agent. DSMIPv6 (D) flag This flag indicates that the care-of address is an IPv4 address. When this flag is set, the care-of address field MUST contain an IPv4 address. Reserved 5 bits Reserved field. The reserved field MUST be zero. Wakikawa (Ed.), et al. Expires August 11, 2008 [Page 9] Internet-Draft MCoA February 2008 Care-of Address This field has the variable length depending on the specified flags. When the 'C' flag is set and the 'D' flag is not, an IPv6 care-of address for the corresponding BID is stored in this field. If both 'C' and 'D' flags are set, an IPv4 Care-of Address is carried in this field. This field MUST NOT be used if a Binding Identifier mobility option is included in any other message other than a Binding Update. GT> For completeness you may want to add: "...or if the 'C' flag is not set= ." ... 5. Mobile Node Operation 5.1. Management of Care-of Addresses and Binding Identifier // Addresses and Binding Identifier/ Address(es) and Binding Identifier(s) There are two cases when a mobile node might acquire several care-of addresses. Note that a mixture of the two cases are also possible. GT> //are/is 1. A mobile node may be using several physical network interfaces and acquires a care-of address on each of its interfaces. 2. A mobile node uses a single physical network interface, but receives advertisements for multiple prefixes on the link the interface is attached to. This will result in the mobile node configuring several global addresses on the interface from each of the announced prefixes. The difference between the above two cases is only in the number of physical network interfaces and therefore irrelevant in this document. What is of significance is the fact that the mobile node has several addresses it can use as care-of addresses. A mobile node assigns a BID to each care-of address when it wants to register them simultaneously with its home address. The BID MUST be unique for a given home address and care-of address pair. The value should be an integer between 1 and 65535. Zero and negative values MUST NOT be used as a BID. If a mobile node has only one care-of GT> //as a BID/as BIDs address, the assignment of a BID is not needed until it has multiple care-of addresses to register with, at which time all of the care-of addresses MUST be mapped to BIDs. 5.2. Return Routability: Sending CoTI and Receiving CoT When a mobile node wants to register multiple care-of address with a correspondent node, it MUST have the valid Care-of Keygen token per care-of address. For the Home Keygen, the mobile node needs only for the home address. GT> Rephrase the above: "The mobile node needs only one Home Keygen for its home address." The mobile node MUST include a Binding Identifier mobility option in the Care-of Test Init message. It MUST NOT set any flags in the mobility option. The receiver (i.e. correspondent node) will calculate a care-of Keygen token as specified in [RFC-3775] and reply with a Care-of Test message, with the Binding Identifier mobility option as described in Section 6.2. When the mobile node receives the Care-of Test message, the message is verified as in [RFC-3775]. If a Binding Identifier mobility option is not present in the CoT message in reply to the CoTI message that included a Binding Identifier mobility option, the mobile node must assume that the correspondent node does not support Multiple Care-of Address Wakikawa (Ed.), et al. Expires August 11, 2008 [Page 12] Internet-Draft MCoA February 2008 registration. Thus, the mobile node MUST NOT use a Binding Identifier mobility option in any future Binding Updates to that correspondent node. The mobile node MAY skip re-sending regular CoTI message and keep the received care-of Keygen token for the regular Binding Update. GT> Should we also say anything about Enhanced RO based on RFC4866? 5.3. Binding Registration For the multiple Care-of Addresses registration, the mobile node MUST include a Binding Identifier mobility option(s) in the Binding Update as shown in Figure 2. The BID is copied from a corresponding Binding Update List entry to the BID field of the Binding Identifier mobility option. When IPsec ESP is used for protecting the Binding Update, the care-of address cam be carried in the Care-of Address field of GT> //cam/can the Binding Identifier mobility option. If this is done, the alternate care-of address option MUST NOT be included in the Binding Update. For binding registration to a correspondent node, the mobile node MUST have both active Home and Care-of Keygen tokens for Kbm (see Section 5.2.5 of [RFC-3775]) before sending the Binding Update. The care-of Keygen tokens MUST be maintained for each care-of address that the mobile node wants to register to the correspondent node. The Binding Update to the correspondent node is protected by the Binding Authorization Data mobility option that is placed after the Binding Identifier mobility option. IPv6 header (src=3DCoA, dst=3DHA) IPv6 Home Address Option ESP Header (for home registration) Mobility header -BU Mobility Options - Binding Identifier mobility option - Binding Authorization mobility option (for Route Optimization) Figure 2: Binding Update for Binding Registration 5.4. Bulk Registration Bulk registration is an optimization for binding multiple care-of addresses to a home address using a single Binding Update. This is very useful if the mobile node, for instance, does not want to send a lot of signaling messages through an interface where the bandwidth is scarce. To use bulk registration, the mobile node includes a Binding Identifier Mobility option for each BID and Care-of address pair it wants to register in the same Binding Update message. This is shown Wakikawa (Ed.), et al. Expires August 11, 2008 [Page 13] Internet-Draft MCoA February 2008 in Figure 3. The rest of the fields and options in the Binding Update such as Lifetime, Sequence Number, the flags in the Binding Update are common across all care-of addresses. The alternate care-of address option MUST NOT be used. In the bulk registration, the Sequence Number field of a Binding Update SHOULD be carefully configured. This is because all the bulk- registered bindings uses the same Sequence Number specified in the GT>//uses/use Binding Update. If each binding uses different sequence number, a mobile node MUST use the largest sequence number from the Binding Update list entries used for the bulk registration. If the mobile node cannot select a sequence number for all the bindings due to sequence number out of window, it MUST NOT use the bulk registration for the binding whose sequence number is out of window. A separate Binding Update should be sent for the binding. IPv6 header (src=3DCoA, dst=3DHA) IPv6 Home Address Option ESP Header Mobility header -BU Mobility Options - Binding Identifier mobility options (C flag is set, O flag is optional, BID and CoA are stored) Figure 3: Binding Update for Bulk Registration If the mobile node wants to replace existing registered bindings on the home agent with the bindings in the sent Binding Update, it sets the 'O' flag. Section 6.3 describes this registration procedure in detail. 5.5. Binding De-Registration When a mobile node decides to delete all the bindings for its home address, it sends a regular de-registration Binding Update with lifetime set to zero as defined in [RFC-3775]. The Binding Identifier mobility option is not required. If a mobile node wants to delete a particular binding(s) from its home agent and correspondent nodes (e.g. from foreign link), the GT> Remove "(e.g. from foreign link)" it is not clear what it means. mobile node sends a Binding Update with lifetime set to zero and includes a Binding Identifier mobility option(s) with the BID(s) it wants to de-register. The receiver will remove only the care-of address(es) that match(es) the specified BID(s). The care-of addresses field of each mobility option SHOULD be omitted, because the receiver will remove the binding matching the specified BID. GT> // SHOULD be omitted/ SHOULD be omitted by the sender and MUST be ignored by the receiver/ Wakikawa (Ed.), et al. Expires August 11, 2008 [Page 14] Internet-Draft MCoA February 2008 5.6. Returning Home The mobile node may return to the home link, by attaching to the home link through one of its interfaces. When the mobile node wants to return home, it should be configured with information on what interface it needs to use. The mobile node may use only the interface with which it is attached to the home link, only the interfaces still attached to the visited link or use both interfaces attached to the home link and visited link simultaneously. The following describes each option in more detail. 5.6.1. Using only Interface attached to the Home Link The mobile node returns home and de-registers all the bindings as shown in Figure 9. GT> add: "...and as defined in [RFC3775]. De-registering all the bindings is the same as binding de-registration from foreign link described in Section 5.5. After the de-registration step, all the packets routed by the home agent are only forwarded to the interface attached to the home link, even if there are other active interfaces attached to the visited link. While the mobile node de-registers all the bindings from the home agent, it may continue registering bindings for interface attached to visited link to the correspondent node as shown in Figure 9. 5.6.2. Using only Interface attached to the Visited Link The mobile node returns home and shuts down the interface attached to the home link as shown in Figure 10. Before shutting down the interface, any binding for the care-of address previously associated with the interface should be deleted. To delete the binding cache entry, the mobile node MUST send a de-registration Binding Update with the lifetime set to zero and include the corresponding BID information. This scenario is not the most efficient because all the traffic to and from the mobile node is going through the bi- directional tunnel, whereas the mobile node is now accessible at one hop on the home link from its home agent. GT> This scenario is still confusing to me. My understanding is that in this scenario the MN simply DOES NOT connect to the home link. If the MN connected to a link that is identified or detected to be its home link, it simply disconnects without sending a BU to the HA. So, as far as the HA is concerned the MN is NOT connected at its home link and operations continue as normal. The paragraph above, however, says something different which does not match my understanding at all. Am I confused? 5.6.3. Simultaneous Home and Visited Link Operation In this case, the mobile node returns home and continues using all the interfaces attached to both foreign and home links as shown in Figure 11. The mobile node indicates this by setting the 'H' flag in the BID mobility option. GT> Add: " ...as defined below." There are additional requirements on the Returning Home procedures for possible ND conflicts at the home link described below. In [RFC-3775], the home agent intercepts packets meant for the mobile node using proxy Neighbor Discovery while the mobile node is away Wakikawa (Ed.), et al. Expires August 11, 2008 [Page 15] Internet-Draft MCoA February 2008 from the home link. When the mobile node returns home, the home agent deletes the binding cache and stops proxying for the home address so that a mobile node can configure its home address on the interface attached to the home link. In this specification, a mobile node may return home, configure the home address on the interface attached to the home link, but still use the interfaces attached to the foreign links. In this case, a possible conflict arises when the both the home agent and the mobile node try to defend the home address. If the home agent stops proxying for the home address, the packets are always routed to the interface attached to the home link and are never routed to the interfaces attached to the visited links. It is required to avoid the conflict between the home agent and the mobile node, while still allowing the simultaneous use of home and foreign links. The following describes the mechanism for achieving this. In this specification, the home agent MUST intercept all the packets meant for the mobile node and decide whether to send the traffic directly to the home address on the link or tunnel to the care-of address. The home agent intercepts all the packets even when the mobile node is attached to the home link through one of its interfaces. The home agent would make this decision based on the type of packets and flows. How to make this decision is out of scope in this document. The critical part would be to create a neighbor cache entry for the mobile node so that the home agent can deliver the packets on-link. The home agent would need to know the Layer-2 address of the interface with which the mobile node is attached to the home link. In order to create the neighbor cache entry for the mobile node, following operations are required. The mobile node sends a de-registration Binding Update to the home agent from the interface attached to the home link. In the Binding Update, the BID mobility option must include the BID the mobile node had previously associated with the interface attached to the home link. GT> When was this association done? What does "previously" refer to? The 'H' flag MUST be set in the BID mobility option. The 'C' flag MUST NOT be set and the care-of address field MUST NOT be included. When the 'H' flag is set, the home agent recognizes that the mobile node wants to continue using interfaces attached to both home and visited links. If the 'H' flag is unset, the home agent deletes either all the bindings or the binding corresponding to the BID included in the Binding Identifier mobility option. When the home agent sends the Binding Acknowledgement, it MUST set the status value to either 0 [Binding Update Accepted] or to [MCOA RETURNHOME WO/NDP (TBD)] in the BID mobility option depending on home agent configuration at the home link. The new values are: Wakikawa (Ed.), et al. Expires August 11, 2008 [Page 16] Internet-Draft MCoA February 2008 o Binding Update Accepted (0): NDP is permitted for the home address at the home link. This is regular returning home operation of [RFC-3775] o MCOA RETURNHOME WO/NDP (TBD): NDP is prohibited for the home address at the home link When the home agent is the only router at the home link, it can intercept all the packets by normal IP routing without using proxying for the home address. It stops proxy ND for the requested home address and responds with the [Binding Update Accepted] status value to the mobile node. The neighbor cache entry for the mobile node is created by the regular exchange of Neighbor Solicitation and Neighbor Advertisement. If the home agent is not the only router on the home link, it MUST continue defending the home address by proxy neighbor discovery in order to intercept the mobile node's traffic. The home agent, then, returns [MCOA RETURNHOME WO/NDP] value in the Status field of the BID mobility option. The home agent also learns the mobile node's layer-2 address (i.e., MAC address) during this binding de-registration. It stores the learnt layer-2 address in a neighbor cache entry for the mobile node so that it can construct the layer-2 header for the packets meant for the mobile node and forwards them directly to the mobile node's interface attached to the home link. According to [RFC-3775], the mobile node MUST NOT assign the home address to the interface attached to the home link and MUST NOT attempt NDP operations for the home address before the completion of binding de-registration. It MUST NOT send and reply to Neighbor Solicitation for the home address. The home address MUST be tentative address at this moment until it receives Binding Acknowledgement with success status value. When the mobile node receives the Binding Acknowledgement and BID mobility option, it assigns home address to the interface attached to the home link according to the status field of the BID. If the value is [Binding Update Accepted], the mobile node can start defending the home address using regular Neighbor Discovery. If the mobile node receives the [MCOA RETURNHOME WO/NDP], it MUST NOT defend its home address on the home link. When the mobile node sends packets from the interface attached to the home link, it MUST learn the layer 2 address (i.e., MAC address) of the next hop (i.e. default router, it can be home agent) during the binding de- registration and construct the packet including layer 2 header with the learnt layer-2 address of the default router or the home agent. GT> Something needs to be said about the lifetime of the BU with 'H' flag set. If the MN has to send a de-reg to the HA with Lifetime=3D0 and 'H' set, for how ling is this state valid? What happens to the lifetime of the other bindings?? Wakikawa (Ed.), et al. Expires August 11, 2008 [Page 17] Internet-Draft MCoA February 2008 5.7. Receiving Binding Acknowledgement The verification of a Binding Acknowledgement is the same as Mobile IPv6 (section 11.7.3 of [RFC-3775]). The operation for sending a Binding Acknowledgement is described in Section 6.3. If a mobile node includes a Binding Identifier mobility option in a Binding Update with the 'A' flag set, a Binding Acknowledgement MUST carry a Binding Identifier mobility option. If no such mobility option is included in the Binding Acknowledgement in response to a Binding Update for multiple care-of address registration, this indicates that the originating node of the Binding Acknowledgement does not support processing the Binding Identifier mobility option. The mobile node MUST then stop multiple care-of address registration with that node. If a Binding Identifier mobility option is present in the received Binding Acknowledgement, the mobile node checks the status field in the option. If the status value in the Binding Identifier mobility option is zero, the mobile node uses the value in the Status field of the Binding Acknowledgement. Otherwise, it uses the value in the Status field of the Binding Identifier mobility option. If the status code is greater than or equal to 128, the mobile node starts relevant operations according to the error code. Otherwise, the mobile node assumes that the originator (home agent or correspondent node) successfully registered the binding information and BID for the mobile node. o If the Status value is [MCOA PROHIBITED], the mobile node MUST stop registering multiple bindings to the node that sent the Binding Acknowledgement. o If the Status value is [MCOA BULK REGISTRATION NOT SUPPORT], the mobile node SHOULD stop using bulk registrations with the node that sent the Binding Acknowledgement. o If [MCOA MALFORMED] is specified, it indicates that the binding identifier mobility option is formatted wrongly. For example, if the 'C' flag is set, all mobility options MUST have 'C' flag. It is same for 'O' flag. GT> What do you mean here with the 'C' and 'O' flags? It is not clear. Also it is not nice to find MUSTs with respect on how to use the flags when talking about the error codes. These MUSTs, if needed, should be moved elsewhere. o If [MCOA BID CONFLICT] is specified, the binding entry specified by the Binding Identifier mobility option is already registered as a regular binding. In such case, the mobile node SHOULD stop sending Binding Updates with BID, or SHOULD use the 'O' flag to reset all the registered bindings. Wakikawa (Ed.), et al. Expires August 11, 2008 [Page 18] Internet-Draft MCoA February 2008 5.8. Receiving Binding Refresh Request The verification of a Binding Refresh Request is the same as in Mobile IPv6 (section 11.7.4 of [RFC-3775]). The operation of sending a Binding Refresh Request is described in section Section 6.4. If a mobile node receives a Binding Refresh Request with a Binding Identifier mobility option, it indicates that the node sending the Binding Refresh Request message is requesting the mobile node to send a new Binding Update for the BID. The mobile node SHOULD then send a Binding Update only for the respective binding. The mobile node MUST include a Binding Identifier mobility option in the Binding Update. If no Binding Identifier mobility option is present in a Binding Refresh Request, the mobile node sends a Binding Update according to its Binding Update List. On the other hand, if the mobile node does not have any Binding Update List entry for the requesting node, the mobile node needs to register either a single binding or multiple bindings depending on its binding management policy. 5.9. Sending Packets to Home Agent When a multihomed mobile node sends packets to its home agent, there are conceptually two ways to construct packets. 1. Using Home Address Option. (required additional 24 bytes) 2. Using IPv6-IPv6 tunnel. (required additional 40 bytes) GT> Remove the period or remove the ( ) and capitalize the R. Beside the difference in the size of packets, there is no difference between the two. The routing path does not get affected. With extensions specified in this document, the mobile node is capable of using multiple care-of addresses for outgoing packets. This is a problem on the home agent side because it must verify the Care-of address for all the packets received from the mobile node (i.e. ingress filtering). When the mobile node uses the Home Address option, the home agent MAY check the care-of address in the packet with the registered binding entries. This causes additional overhead to the home agent. Therefore, the mobile node SHOULD use the bi- directional tunnel even if it registers a binding(s) to the home agent. GT> This confuses me a bit. Is there anything different from RFC3775? Why is this section needed? 5.10. Bootstrapping When a mobile node bootstraps and registers multiple bindings for the first time, it SHOULD set the 'O' flag in the Binding Identifier mobility option. GT> Should this be a MUST? Otherwise what is the behavior of the HA? If old bindings still exists at the home agent, the mobile node has no knowledge of which bindings still exist at the Wakikawa (Ed.), et al. Expires August 11, 2008 [Page 19] Internet-Draft MCoA February 2008 home agent. This scenario happens when a mobile node reboots and looses state regarding the registrations. If the 'O' flag is set, all the bindings are replaced by the new binding(s). If the mobile node receives the Binding Acknowledgement with the status code set to 135 [Sequence number out of window], it MUST retry sending a Binding Update with the last accepted sequence number indicated in the Binding Acknowledgement. The 'O' flag can also be used in individual Binding Updates sent to the correspondent nodes to override any existing binding cache entries at the correspondent node. GT> Again the 'O' flag MUST be set the first time MCoA is used with a CN I think. Wakikawa (Ed.), et al. Expires August 11, 2008 [Page 20] Internet-Draft MCoA February 2008 6. Home Agent and Correspondent Node Operation 6.1. Searching Binding Cache with Binding Identifier If either a correspondent node or a home agent has multiple bindings for a mobile node in their binding cache database, it can use any of the bindings to communicate with the mobile node. How to select the most suitable binding from the binding cache database is out of scope in this document. Whenever a correspondent node searches a binding cache for a home address, it SHOULD uses both the home address and the BID as the search key if it knows the corresponding BID. GT> This is a bid strange. Why would the HA or CN use a BID as a key? The HoA is used as a key because the HA/CN want to send a packet with the HoA as destination address, which causes Mobile IP to use the HoA as a key to find an appropriate CoA. I do not think that the BIDs are needed for this. With MCoA, the only difference is that a lookup of the HoA will return multiple CoAs; and which one is used is out of scope for this document. GT> So, the BIDs are only used as key when the receiver processes a BU message including a BID Mobility option. Is this what this is about? In the example below, if a correspondent node searches the binding with the home address and BID2, it gets binding2 for this mobile node. binding1 [a:b:c:d::EUI, care-of address1, BID1] binding2 [a:b:c:d::EUI, care-of address2, BID2] binding3 [a:b:c:d::EUI, care-of address3, BID3] Figure 4: Searching the Binding Cache A correspondent node earns the BID when it receives a Binding GT> //earns/learns Identifier mobility option. At the time, the correspondent node MUST GT>//At the time/At that time look up its binding cache database with the home address and the BID retrieved from the Binding Update. If the correspondent node does not know the BID, it searches for a binding with only the home address. In such a case, the first matched binding is found. If the correspondent node does not desire to use multiple bindings for a mobile node, it can simply ignore the BID. GT> This whole section needs to be cleaned based on the comment above. 6.2. Receiving CoTI and Sending CoT When a correspondent node receives a CoTI message which contains a Binding Identifier mobility option, it processes it as follows. First, the CoTI message is verified as specified in [RFC-3775]. The Binding Identifier mobility option is processed as follows: o If a correspondent node does not understand a Binding Identifier mobility option, it just ignores and skips processing the option. The calculation of a care-of Keygen token will thus be done without a BID value. The correspondent node returns a CoT message without a Binding Identifier mobility option. The mobile node knows whether the correspondent supports processing the Binding Identifier mobility option, by checking if the option is present in the CoT message. Wakikawa (Ed.), et al. Expires August 11, 2008 [Page 21] Internet-Draft MCoA February 2008 o If either the 'C' or the 'O' flag is set in the Binding Identifier mobility option, the correspondent Node SHOULD NOT calculate a care-of Keygen token, but MUST include a Binding Identifier mobility option with status value set to [MCOA MALFORMED] in the Care-of Test message. o Otherwise, the correspondent node MUST include a Binding Identifier mobility option with status value set to zero (success) in the Care-of Test message. o The Care-of address field of each Binding Identifier mobility option, can be omitted, because the mobile node can identify the corresponding Binding Update list entry using the BID. 6.3. Processing Binding Update If a Binding Update does not contain a Binding Identifier mobility option, its processing is same as in [RFC-3775]. If the receiver already has multiple bindings for the home address, it MUST replace all the existing bindings by the received binding. As a result, the receiver node MUST have only one binding cache entry for the mobile node. If the Binding Update is for de-registration, the receiver MUST delete all existing bindings from its Binding Cache. If the Binding Update contains a Binding Identifier mobility option(s), it is validated according to section 9.5.1 of [RFC-3775] and the following steps. o If the home registration flag is set in the Binding Update, the home agent MUST carefully operate Duplicate Address Detection (DAD) for the received home address. If the home agent has already had a binding(s) for the mobile node, it MUST avoid running DAD for the home address on the home link when it receives the Binding Update. GT> Why is this here? This is normal RFC3775 operation and should not be affected by MCoA, no? The receiver MUST process the Binding Identifier mobility option(s) in the following steps. When a correspondent node sends a Binding Acknowledgement, the status value MUST be always stored in the Status field of the Binding Acknowledgement and the Status field of Binding Identifier mobility option set to zero. GT> The last sentence does not make sense. Please rephrase. For the home agent, the status value can be stored in the Status field of either a Binding Acknowledgement or a Binding Identifier mobility option. If the status value is specific to one of bindings in the bulk registration, the status value MUST be stored in the Status field in the corresponding Binding Identifier mobility option. In this case, [MCOA NOTCOMPLETE] MUST be set to the Status field of the Binding Acknowledgement so that the receiver can examine the Wakikawa (Ed.), et al. Expires August 11, 2008 [Page 22] Internet-Draft MCoA February 2008 Status field of each Binding Identifier mobility option for further operations. o The length value is examined. The length value MUST be either 4, 8, or 20 depending on the 'C' and 'D' flags. If the length is incorrect, the receiver MUST reject the Binding Update and returns the status value set to [MCOA MALFORMED]. o When the 'C' flag is set, the care-of address MUST be present in the Binding Identifier mobility option. Otherwise, the receiver GT> It is not clear what "Otherwise" refers to. Replace with: "If the care-of address is not present..." MUST reject the Binding Identifier mobility option and returns the status value set to [MCOA MALFORMED]. The operation of 'D' flag is described in Section 8 o When multiple Binding Identifier mobility options are present in the Binding Update, it is treated as bulk registration. If the receiving node is a correspondent node, it MUST reject the Binding Update and returns the status value in the binding acknowledgement set to [MCOA BULK REGISTRATION NOT SUPPORT] o If the Lifetime field in the Binding Update is set to zero, the receiving node deletes the binding entry that corresponds to the BID in the Binding Identifier mobility option. If the receiving node does not have an appropriate binding for the BID, it MUST reject the Binding Update and send a Binding Acknowledgement with status set to 133 [not home agent for this mobile node]. GT>This does not make sense. If the BID does not exist then the binding never existed or has already been deleted so I would send a BA and BID Mobility option with status 0. Status 133 means that the HoA is not valid...which is a different issue already covered in RFC3775. Also please move this bullet one place down to be next to Lifetime !=3D zero case. o If the 'O' flag is set in the de-registering Binding Update, the receiver can ignore this flag for de-registration. GT> This sentence is strange please rephrase. If the 'H' flag is set, the home agent stores a home address in the Care-of Address field of the binding cache entry. The home agent also stops performing proxy ND for the mobile node's home address. o If the Lifetime field is not set to zero, the receiving node registers a binding with the specified BID as a mobile node's binding. The Care-of address is obtained from the Binding Update packet as follows: * If the 'C' flag is set in the Binding Identifier mobility option, the care-of address is copied from the care-of address field in the Binding Identifier mobility option. * If the 'C' flag is not set in the Binding Identifier mobility option, the care-of address is copied from the source address field of the IPv6 header. * If the 'C' flag is not set and an alternate care-of address is present, the care-of address is copied from the Alternate Wakikawa (Ed.), et al. Expires August 11, 2008 [Page 23] Internet-Draft MCoA February 2008 Care-of address mobility option. o Once the care-of address(es) has been retrieved from the Binding GT>//has/have Update, the receiving nodes creates new binding(s). * If only the 'O' flag is set in the Binding Identifier mobility option, the home agent removes all the existing bindings and registers the received bindings. * If the receiver has a regular binding which does not have BID for the mobile node, it must not process the binding update. The receiver should sent a binding acknowledgement with status set to [MCOA BID CONFLICT]. GT> This makes no sense. What do you mean? * If the receiver already has a binding with the same BID, it GT>// same BID, it/ same BID and different care-of address, it MUST update the binding and responds with a Binding GT>//responds/respond Acknowledgement with status set to 0 [Binding Update accepted]. * If the receiver does not have a binding entry for the BID, it registers a new binding for the BID and responds with a Binding Acknowledgement with status set to 0 [Binding Update accepted]. GT> What happens if one receives a new BID mapped to a CoA already in the binding cache (but mapped to different BID?) Is this allowed? Is this how one can change the BIDs it is using? If all the above operations are successfully completed, a Binding Acknowledgement containing the Binding Identifier mobility options MUST be sent to the mobile node. Whenever a Binding Acknowledgement is sent, all the Binding Identifier mobility options stored in the Binding Update MUST be copied to the Binding Acknowledgement except the status field. The Care-of address field in each Binding Identifier mobility option, however, can be omitted, because the mobile node can match a corresponding binding update list entry using the BID. GT> Something needs to be said about the lifetime of the bindings. I assume that the Lifetime field of the BU updates the lifetime of all the bindings, whether a regular or bulk MCoA registration is performed. 6.4. Sending Binding Refresh Request When a node (home agent or correspondent node) sends a Binding Refresh Request for a particular binding created with the BID, the node SHOULD include the Binding Identifier mobility option in the Binding Refresh Request. GT> This needs a bit more...which BID mobility option is included? Just one? All of them? Again we need to be clear what the lifetime does and how it relates to each of the CoAs. 6.5. Receiving Packets from Mobile Node When a node receives packets with a Home Address destination option from a mobile node, it MUST check that the care-of address that appears in the source address field of the IPv6 header MUST be equal to one of the care-of addresses in the binding cache entry. If no binding is found, the packets MUST be silently discarded. GT> Why don't we just point to RFC3775 and say that the exact same processing is used here? The node MUST also send a Binding Error message as specified in [RFC-3775]. This verification MUST NOT be done for a Binding Update. Wakikawa (Ed.), et al. Expires August 11, 2008 [Page 24] Internet-Draft MCoA February 2008 7. Network Mobility Applicability The binding management mechanisms are the same for a mobile host that uses Mobile IPv6 and for a mobile router that is using the NEMO Basic Support protocol [RFC-3963]. Therefore the extensions described in this document can also be used to support a mobile router with multiple care-of addresses. Figure 5 shows an example format of a Binding Update sent by a mobile router. IPv6 header (src=3DCoA, dst=3DHA) IPv6 Home Address Option ESP Header Mobility header -BU Mobility Options - Binding Identifier - Mobile Network Prefix Figure 5: NEMO Binding Update GT> Why is this example here? I would remove it together with the last sent= ence. Wakikawa (Ed.), et al. Expires August 11, 2008 [Page 25] Internet-Draft MCoA February 2008 8. DSMIPv6 Applicability Dual Stack Mobile IPv6 (DSMIPv6) [ID-DSMIPv6] extends Mobile IPv6 to register an IPv4 care-of address instead of the IPv6 care-of address when the mobile node is attached to an IPv4-only access network. It also allows the mobile node to acquire an IPv4 home address in addition to an IPv6 home address for use with IPv4-only correspondent nodes. This section describes how multiple care-of address registration works with IPv4 care-of and home addresses. 8.1. IPv4 Care-of Address Registration The mobile node can use the extensions described in the document to register multiple care-of addresses, even if some of the care-of addresses are IPv4 address. Bulk registration MUST NOT be used for the initial binding from an IPv4 care-of address. This is because, the Binding Update and binding acknowledgement exchange is used to detect NAT on the path between the mobile node and the home agent. So the mobile node needs to check for a NAT between each IPv4 care-of address and the home agent. The Binding Update MUST be sent to the IPv4 home agent address by using UDP and IPv4 headers as shown in Figure 6. It is similar to [ID-DSMIPv6] except that the IPv4 care-of address option MUST NOT be used when the BID mobility option is used. IPv4 header (src=3DV4ADDR, dst=3DHA_V4ADDR) UDP Header IPv6 header (src=3DV6HoA, dst=3DHAADDR) ESP Header Mobility header -BU Mobility Options - Binding Identifier (IPv4 CoA) Figure 6: Initial Binding Update for IPv4 Care-of Address Whenever a NAT is detected, mobile node MUST NOT use bulk registration for the IPv4 care-of address. GT> This was repeated above. Delete. If a NAT is not detected, the mobile node can update the IPv4 care-of address by using BULK GT>//BULK/bulk registration. The mobile node can register the IPv4 care-of address along with other care-of addresses. Figure 7 shows the Binding GT>// other care-of addresses/ other IPv4 and IPv6 care-of addresses Update format when the mobile node sends a Binding Update from one of its IPv6 care-of addresses. If the mobile node sends a BU from IPv4 care-of address, it MUST follow the format described in Figure 6. Note that the IPv4 Care-of Address must be registered by non bulk Wakikawa (Ed.), et al. Expires August 11, 2008 [Page 26] Internet-Draft MCoA February 2008 Binding registration, whenever it is changed. NAT detection MUST be carried out for every new IPv4 addresses. GT> Again, this was repeated above. Delete. IPv6 header (src=3DV6CoA, dst=3DHAADDR) IPv6 Home Address Option ESP Header Mobility header -BU Mobility Options - Binding Identifier (IPv6/v4 CoA) - Binding Identifier (IPv6/v4 CoA) - ... Figure 7: Binding Bulk Registration for IPv4 care-of address If the home agent rejects the IPv4 care-of address, it MUST store the error code value in the Status field of the BID mobility option. The home agent MUST send the Binding Acknowledgement and all the received BID mobility options to the mobile node. GT> This has already been explained in other sections. It is not good to repeat MUST statements about the same thing. Delete the whole paragraph=85.or just point to HA processing section. 8.2. IPv4 HoA Management When the mobile node wants to configure an IPv4 home address in addition to the IPv6 home address, it can request for one using the IPv4 Home Address option in the Binding Update. If the home agent accepts the Binding Update, the mobile node can now register multiple care-of addresses for the IPv4 home address in addition to the IPv6 home address. The same set of care-of addresses will be registered for both IPv6 and IPv4 home addresses. The mobile node cannot bind different set of care-of addresses to each home address. The home agent includes the IPv4 address acknowledgement option in the Binding Acknowledgement only if the mobile node had requested for the IPv4 home address. GT> Rephrase: "According to [DSMIPv6], the home agent includes the IPv4 address acknowledgement option in the Binding Acknowledgement only if the mobile node requests an IPv4 home address in the corresponding Binding Update. " The IPv4 address acknowledgement option MUST be present before any BID option. The status field of the IPv4 address acknowledgement option contains only the error code regarding IPv4 home address management. GT>// the error code regarding IPv4 home address management/ the error code corresponding to the IPv4 home address. The error values related to the IPv4 care-of address registration MUST be stored in the BID mobility option. Wakikawa (Ed.), et al. Expires August 11, 2008 [Page 27] Internet-Draft MCoA February 2008 9. IPsec and IKEv2 interaction Mobile IPv6 [RFC-3775] and the NEMO protocol [RFC-3963] require the use of IPsec to protect signaling messages like Binding Updates, Binding Acknowledgements and return routability messages. IPsec may also be used protect all reverse tunneled data traffic. The Mobile GT> //used protect all reverse tunneled data / used to protect all tunneled data/ IPv6-IKEv2 specification [RFC-4877] specifies how IKEv2 can be used to setup the required IPsec security associations. The following assumptions were made in [RFC-3775], [RFC-3963] and the MIP6-IKEv2 specification with respect to the use of IKEv2 and IPsec. GT> Why is MIP6-IKEv2 not properly referenced? o There is only one primary care-of address per mobile node. o The primary care-of address is stored in the IPsec database for tunnel encapsulation and decapsulation. o When the home agent receives a packet from the mobile node, the source address is verified against the care-of address in the corresponding binding cache entry. If the packet is a reverse tunneled packet from the mobile node, the care-of address check is done against the source address on the outer IPv6 header. The reverse tunnel packet could either be a tunneled HoTi message or tunneled data traffic to the correspondent node. o The mobile node runs IKEv2 (or IKEv1) with the home agent using the care-of address. The IKE SA is based on the care-of address of the mobile node. The above assumptions may not be valid when multiple care-of addresses are used by the mobile node. In the following sections, the main issues with the use of multiple care-of address with IPsec are addressed. 9.1. Use of Care-of Address in the IKEv2 exchange For each home address the mobile node sets up security associations with the home agent, the mobile node must pick one care-of address and use that as the source address for all IKEv2 messages exchanged to create and maintain the IPsec security associations associated with the home address. The resultant IKEv2 security association is created based on this care-of address. GT> Add "according to MIP6-IKEv2 ..." until you have something new. If the mobile node needs to change the care-of address, it just sends a Binding Update with the care-of address it wants to use, with the corresponding Binding Identifier mobility option, and with the 'K' bit set. This will force the home agent to update the IKEv2 security association to use the new care-of address. If the 'K' bit is not supported on the mobile node or the home agent, the mobile node MUST Wakikawa (Ed.), et al. Expires August 11, 2008 [Page 28] Internet-Draft MCoA February 2008 re-establish the IKEv2 security association with the new care-of address. This will also result in new IPsec security associations being setup for the home address. On Feb 8, 2008 4:35 PM, Vijay Devarapalli wrote: > Hello, > > There is a pre-06 version of this draft available at > http://dvijay.com/ietf/internet-drafts/mext/mcoa.txt > > The draft has been cleaned up a bit. In case, you haven't reviewed > the document yet, please review the pre-06 version. In case you > have already reviewed version 05, please send your comments based > on version 05. > > The diff between 05 and pre-06 can be found at > http://dvijay.com/ietf/internet-drafts/mext/diff-05-06.html > > Vijay > > > marcelo bagnulo braun wrote: > > Hi, > > > > With this email we issue the WGLC for draft-ietf-monami6- > > multiplecoa-05.txt > > The WGLC will be open till the 11 of february. > > We kindly ask the WG to review the document and provide comments. > > > > Please note that a valid comment at this stage is positive feedback > > about the document being ready to be shipped. > > So, please if you think the doc is ready, do express this to the ml > > (or to the chairs) > > > > For you convenience, additional information about the document: > > > > Title : Multiple Care-of Addresses Registration > > Author(s) : R. Wakikawa, et al. > > Filename : draft-ietf-monami6-multiplecoa-05.txt > > Pages : 44 > > Date : 2008-01-27 > > > > http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-05.t= xt > > > > Thanks, Julien and marcelo > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > http://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Feb 11 16:06:47 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0975B3A6DF1; Mon, 11 Feb 2008 16:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.053 X-Spam-Level: X-Spam-Status: No, score=-0.053 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_24=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lw-F-a-LAfX8; Mon, 11 Feb 2008 16:06:42 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07F0B3A6D11; Mon, 11 Feb 2008 16:06:42 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72E4A3A6C7C for ; Mon, 11 Feb 2008 16:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w72Y5FnQ7rtr for ; Mon, 11 Feb 2008 16:06:36 -0800 (PST) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.234]) by core3.amsl.com (Postfix) with ESMTP id 9EB7E3A684B for ; Mon, 11 Feb 2008 16:06:35 -0800 (PST) Received: by wr-out-0506.google.com with SMTP id 50so5442897wri.25 for ; Mon, 11 Feb 2008 16:07:59 -0800 (PST) Received: by 10.142.77.11 with SMTP id z11mr545247wfa.98.1202774878521; Mon, 11 Feb 2008 16:07:58 -0800 (PST) Received: from dhcp-128-107-155-146.cisco.com ( [128.107.155.146]) by mx.google.com with ESMTPS id 30sm5349577wfg.5.2008.02.11.16.07.56 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Feb 2008 16:07:56 -0800 (PST) From: RYUJI WAKIKAWA To: George Tsirtsis In-Reply-To: References: <47AC84E3.2030605@azairenet.com> Message-Id: <55AB1BB1-1C3B-4C6E-8E04-5584C9669B17@gmail.com> Mime-Version: 1.0 (Apple Message framework v915) Date: Tue, 12 Feb 2008 09:07:55 +0900 X-Mailer: Apple Mail (2.915) Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] WGLC for draft-ietf-monami6-multiplecoa-05.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi George, Thanks a lot for comments, please find my reply inline. On 2008/02/12, at 0:07, George Tsirtsis wrote: > Hi Vijay/Ryuji et.al., > > This version (pre-6) is much improved so well done. There are still > several minor technical issues, unlear text, and nits, which I > indicate below, but I want to highlight a few more important technical > issues upfront: > > 1) Lifetime of BIDs: I think the relation between BIDs and BU Lifetime > field is not clear. I think the assumption has been that the Lifetime > is common across all BIDs. Yes. This is because BID option does not have lifetime field. > IMO there needs to be more explicit > language in the spec to make this clear.. OK > > - a BU with one or more BIDs, O=0, and Lifetime != 0, updates the > lifetime of all the BIDs in the binding cache. i.e., to maintain all > the BIDs you just need to send a Binding refresh including at least > BID.(right?) > - a BU with O=1 replaces all BIDs and associates them with lifetime > in the BU > - a BU with one or more BIDs, O=0, and Lifetime = 0, removes only the > listed BIDs and does not affect the lifetime of other BIDs in the > binding cache All you mentioned above are correct. > - a BU with lifetime=0 and H=1 indicates the MN is at home link, but > the lifetime of other BIDs is not affected. right. > How is the home link > state maintained though? This looks like hard state at the moment and > I do not like it. Any ideas? I might miss your question. HA should verify the reachability of the mobile node at the home link. If the reachability is missed, the HA should clean up the all the home link states. > 2) Changing BIDs. the draft indicates that BIDs can be changed for > privacy reasons. While I still do not understand what these reasons > are, The point is not privacy or security reason, but MN can always pick a new BID. > I also do not see anywhere how BIDs can be changed. Is is done by > sending a BU with a new BID mapped to a CoA that is already in the > binding cache (but mapped to another BID)? yes. > I indicate that this could > be added somewhere inline, but some additional care also needs to be > taken e.g., can you reuse the BID you are replacing in the same BU? This seems to be corner-case, but we will clarify it. > 3) Section 5.6.2 (using only IF attached to visitied) is very > confusing: I copy here the comment I also placed inline below: > My understanding is that in this scenario the MN simply DOES NOT > connect to the home link. If the MN connected to a link which is > identified or detected to be its home link, it simply disconnects > without sending a BU to the HA. So, as far as the HA is concerned the > MN is NOT connected at its home link and operations continue as > normal. The text in this section, however, says something different > which does not match my understanding at all. Am I confused? We need one more operation here. What about the binding cache for the CoA previously assigned to the interface(which is now disconnected)? The interface is now disconnected, but the old binding cache for the previous CoA assigned to that interface might be still active at the home agent. It should explicitly send de-registration BU for that binding cache, since MN has other active interfaces to send that BU. We will revise the texts of section 5.6.2. thanks ryuji > Thanks again for all the effort and see the rest of the detailed > review below. > > George > > > > ------------------------------------------------------------------------------------------------------------------------------- > 1. Introduction > > ... > > But assigning a single home address to a node is more > advantageous than assigning multiple home addresses because > applications do not need to be aware of the multiplicity of home > addresses. > > GT> I am not sure I agree with this statement. I think effective use > of multiple home addresses by applications is a better and more robust > technique but it does require applications to be written in a certain > way. Multiple CoAs allow multihoming awareness to be outsourced to a > different part of the IP stack but, especially when combined with per > flow bindings, it results in routing that is not purely destination > address based. This is not necessarily a good thing for Internet > routing as a whole and only acceptable because it is only confined in > HAs. I think we can have a bit better applicability statement that is > more objective and looks at the big picture. i.e., at the > architectural limitations of this approach. > > ... > 3. Protocol Overview > > A new extension called the Binding identification number (BID) is > > GT> I think the name of the extension is "Binding Identifier > Mobility Option"? > > introduced to distinguish between multiple bindings pertaining to > the > same home address. If a mobile node configures several IPv6 global > addresses on one or more of its interfaces, it can register these > addresses with its home agent as care-of addresses. If the mobile > node wants to register multiple bindings, it MUST generate a BID for > each care-of address and store the BID in the binding update > list. A > mobile node can manipulate each binding independently by using the > BIDs. The mobile node then registers its care-of addresses by > sending a Binding Update with a Binding Identifier mobility option. > The BID is included in the Binding Identifier mobility option. > After > receiving the Binding Update with a Binding Identifier mobility > option, the home agent MUST copy the BID from the Binding Identifier > mobility option to the corresponding field in the binding cache > entry. If there is an existing binding cache entry for the mobile > node, and the if the BID in the Binding Update does not match the > one > > GT> // and the if/ and if > > with the existing entry, the home agent MUST create a new binding > cache entry for the new care-of address and BID. The mobile node > can > register multiple care-of addresses either independently in > individual Binding Updates or multiple at once in a single Binding > Update. > > If the mobile host wishes to register its binding with a > correspondent node, it must perform return routability operations. > This includes managing a Care-of Keygen token per care-of address > and > exchanging CoTi and CoT message with the correspondent node for each > care-of address. It is RECOMMENDED that the mobile node uses the > same BID that it used with the home agent for a particular care-of > address. > > GT> I do not see why this is RECOMMENDED either :-). At most this is > a MAY, since I can not think of any reason why this not totally an > implementation decision. > > For protocol simplicity, bulk registration to correspondent > nodes is not supported in this document. This is because the Return > Routability mechanism introduced in [RFC-3775] cannot be easily > extended to verify multiple care-of addresses stored in a single > Binding Update. > > If the mobile node decides to act as a regular mobile node compliant > with [RFC-3775], it sends a Binding Update without any Binding > Identifier mobility options. The receiver of the Binding Update > deletes all the bindings registering with a BID and registers only a > single binding for the mobile node. Note that the mobile node can > continue using BID even if only has a single binding is active. > > GT> //BID even if only has a/BIDs even if it has only a/ > > > Binding cache lookup is done based on the home address and BID > information. This is different from RFC 3775, where only the home > address is used for binding cache lookup. The binding cache lookup > may also involve policy or flow filters in cases where some policy > or > flow filters are used to direct certain packets or flows to a > particular care-of address. The binding cache lookup using policy > or > flow filters is out of scope for this document. In case the binding > cache lookup, using the combination of home address and BID, does > not > return a valid binding cache entry, the home agent MAY perform > another lookup based on only the home address. This is > implementation dependent and configurable on the home agent. > > The mobile node may return to the home link through one of its > interfaces. There are three options possible for the mobile node > when its returns home. > > 1. The mobile node uses only the interface with which it attaches > to > the home link. It de-registers all bindings related to all > care-of addresses. The interfaces still attached to the visited > link are no longer going to be receiving any encapsulated > traffic > > GT> //link/link(s) > > from the home agent. > > 2. The mobile node uses only the interfaces still attached to the > visited link. > > GT> //link/link(s) > > The interface with which the mobile node attaches > to the home link is not used. > > 3. The mobile node may simultaneously use both the interface > attached to the home link and the interfaces still attached to > the visited links. > > GT> //links/link(s) > > ... > > > Wakikawa (Ed.), et al. Expires August 11, 2008 > [Page 8] > > Internet-Draft MCoA February > 2008 > > > Status > > When the Binding Identifier mobility option is included in a > Binding Acknowledgement, this field overwrites the status field > correspondent to each binding in the Binding Acknowledgement. If > this field is zero, the receiver MUST use the registration status > stored in the Binding Acknowledgement message. This Status field > can be used to carry error information for a Care-of Test > message. > The status is 8-bit unsigned integer. > > The possible status codes > are the same as the status codes of Binding Acknowledgement. > > GT> This is not true, right? New values are defined in section 4.5. > Care-of address (C) flag > > When this flag is set, it indicates that a valid care-of address > is present in the care-of address field in the BID mobility > option. This flag MUST be set whenever the mobile node sends > multiple care-of addresses in a single Binding Update, i.e., bulk > registration. It MAY also used as a substitute for alternate > care-of address option even for Binding Updates that are sent > only > for one care-of address. This flag is valid only for Binding > Update sent to the home agent. > > Overwrite (O) flag > > When this flag is set, a mobile node requests the recipient to > replace all the bindings to binding entries stored in a Binding > Update. > > Simultaneous Home and Foreign Binding (H) flag > > This flag indicates that the mobile node registers multiple > bindings to the home agent while is attached to the home link. > This flag is valid only for a Binding Update sent to the home > agent. > > DSMIPv6 (D) flag > > This flag indicates that the care-of address is an IPv4 address. > When this flag is set, the care-of address field MUST contain an > IPv4 address. > > Reserved > > 5 bits Reserved field. The reserved field MUST be zero. > > > > > > > > Wakikawa (Ed.), et al. Expires August 11, 2008 > [Page 9] > > Internet-Draft MCoA February > 2008 > > > Care-of Address > > This field has the variable length depending on the specified > flags. When the 'C' flag is set and the 'D' flag is not, an IPv6 > care-of address for the corresponding BID is stored in this > field. > If both 'C' and 'D' flags are set, an IPv4 Care-of Address is > carried in this field. This field MUST NOT be used if a Binding > Identifier mobility option is included in any other message other > than a Binding Update. > > GT> For completeness you may want to add: "...or if the 'C' flag is > not set." > ... > 5. Mobile Node Operation > > 5.1. Management of Care-of Addresses and Binding Identifier > > // Addresses and Binding Identifier/ Address(es) and Binding > Identifier(s) > > There are two cases when a mobile node might acquire several care-of > addresses. Note that a mixture of the two cases are also possible. > > GT> //are/is > > 1. A mobile node may be using several physical network interfaces > and acquires a care-of address on each of its interfaces. > > 2. A mobile node uses a single physical network interface, but > receives advertisements for multiple prefixes on the link the > interface is attached to. This will result in the mobile node > configuring several global addresses on the interface from each > of the announced prefixes. > > The difference between the above two cases is only in the number of > physical network interfaces and therefore irrelevant in this > document. What is of significance is the fact that the mobile node > has several addresses it can use as care-of addresses. > > A mobile node assigns a BID to each care-of address when it wants to > register them simultaneously with its home address. The BID MUST be > unique for a given home address and care-of address pair. The value > should be an integer between 1 and 65535. Zero and negative values > MUST NOT be used as a BID. If a mobile node has only one care-of > > GT> //as a BID/as BIDs > > address, the assignment of a BID is not needed until it has multiple > care-of addresses to register with, at which time all of the care-of > addresses MUST be mapped to BIDs. > > 5.2. Return Routability: Sending CoTI and Receiving CoT > > When a mobile node wants to register multiple care-of address with a > correspondent node, it MUST have the valid Care-of Keygen token per > care-of address. > > For the Home Keygen, the mobile node needs only for > the home address. > > GT> Rephrase the above: "The mobile node needs only one Home Keygen > for its home address." > > > The mobile node MUST include a Binding Identifier mobility option in > the Care-of Test Init message. It MUST NOT set any flags in the > mobility option. The receiver (i.e. correspondent node) will > calculate a care-of Keygen token as specified in [RFC-3775] and > reply > with a Care-of Test message, with the Binding Identifier mobility > option as described in Section 6.2. When the mobile node receives > the Care-of Test message, the message is verified as in [RFC-3775]. > If a Binding Identifier mobility option is not present in the CoT > message in reply to the CoTI message that included a Binding > Identifier mobility option, the mobile node must assume that the > correspondent node does not support Multiple Care-of Address > > > > Wakikawa (Ed.), et al. Expires August 11, 2008 [Page > 12] > > Internet-Draft MCoA February > 2008 > > > registration. Thus, the mobile node MUST NOT use a Binding > Identifier mobility option in any future Binding Updates to that > correspondent node. The mobile node MAY skip re-sending regular > CoTI > message and keep the received care-of Keygen token for the regular > Binding Update. > > > GT> Should we also say anything about Enhanced RO based on RFC4866? > > > 5.3. Binding Registration > > For the multiple Care-of Addresses registration, the mobile node > MUST > include a Binding Identifier mobility option(s) in the Binding > Update > as shown in Figure 2. The BID is copied from a corresponding > Binding > Update List entry to the BID field of the Binding Identifier > mobility > option. When IPsec ESP is used for protecting the Binding Update, > the care-of address cam be carried in the Care-of Address field of > > GT> //cam/can > > the Binding Identifier mobility option. If this is done, the > alternate care-of address option MUST NOT be included in the Binding > Update. > For binding registration to a correspondent node, the mobile > node MUST have both active Home and Care-of Keygen tokens for Kbm > (see Section 5.2.5 of [RFC-3775]) before sending the Binding Update. > The care-of Keygen tokens MUST be maintained for each care-of > address > that the mobile node wants to register to the correspondent node. > The Binding Update to the correspondent node is protected by the > Binding Authorization Data mobility option that is placed after the > Binding Identifier mobility option. > > IPv6 header (src=CoA, dst=HA) > IPv6 Home Address Option > ESP Header (for home registration) > Mobility header > -BU > Mobility Options > - Binding Identifier mobility option > - Binding Authorization mobility option > (for Route Optimization) > > Figure 2: Binding Update for Binding Registration > > 5.4. Bulk Registration > > Bulk registration is an optimization for binding multiple care-of > addresses to a home address using a single Binding Update. This is > very useful if the mobile node, for instance, does not want to > send a > lot of signaling messages through an interface where the bandwidth > is > scarce. > > To use bulk registration, the mobile node includes a Binding > Identifier Mobility option for each BID and Care-of address pair it > wants to register in the same Binding Update message. This is shown > > > > Wakikawa (Ed.), et al. Expires August 11, 2008 [Page > 13] > > Internet-Draft MCoA February > 2008 > > > in Figure 3. The rest of the fields and options in the Binding > Update such as Lifetime, Sequence Number, the flags in the Binding > Update are common across all care-of addresses. The alternate > care-of address option MUST NOT be used. > > In the bulk registration, the Sequence Number field of a Binding > Update SHOULD be carefully configured. This is because all the > bulk- > registered bindings uses the same Sequence Number specified in the > > GT>//uses/use > > Binding Update. If each binding uses different sequence number, a > mobile node MUST use the largest sequence number from the Binding > Update list entries used for the bulk registration. If the mobile > node cannot select a sequence number for all the bindings due to > sequence number out of window, it MUST NOT use the bulk registration > for the binding whose sequence number is out of window. A separate > Binding Update should be sent for the binding. > > IPv6 header (src=CoA, dst=HA) > IPv6 Home Address Option > ESP Header > Mobility header > -BU > Mobility Options > - Binding Identifier mobility options > (C flag is set, O flag is optional, > BID and CoA are stored) > > Figure 3: Binding Update for Bulk Registration > > If the mobile node wants to replace existing registered bindings on > the home agent with the bindings in the sent Binding Update, it sets > the 'O' flag. Section 6.3 describes this registration procedure in > detail. > > 5.5. Binding De-Registration > > When a mobile node decides to delete all the bindings for its home > address, it sends a regular de-registration Binding Update with > lifetime set to zero as defined in [RFC-3775]. The Binding > Identifier mobility option is not required. > > If a mobile node wants to delete a particular binding(s) from its > home agent and correspondent nodes (e.g. from foreign link), the > > GT> Remove "(e.g. from foreign link)" it is not clear what it means. > > mobile node sends a Binding Update with lifetime set to zero and > includes a Binding Identifier mobility option(s) with the BID(s) it > wants to de-register. The receiver will remove only the care-of > address(es) that match(es) the specified BID(s). The care-of > addresses field of each mobility option SHOULD be omitted, because > the receiver will remove the binding matching the specified BID. > > GT> // SHOULD be omitted/ SHOULD be omitted by the sender and MUST be > ignored by the receiver/ > > Wakikawa (Ed.), et al. Expires August 11, 2008 [Page > 14] > > Internet-Draft MCoA February > 2008 > > > 5.6. Returning Home > > The mobile node may return to the home link, by attaching to the > home > link through one of its interfaces. When the mobile node wants to > return home, it should be configured with information on what > interface it needs to use. The mobile node may use only the > interface with which it is attached to the home link, only the > interfaces still attached to the visited link or use both interfaces > attached to the home link and visited link simultaneously. The > following describes each option in more detail. > > 5.6.1. Using only Interface attached to the Home Link > > The mobile node returns home and de-registers all the bindings as > shown in Figure 9. > > GT> add: "...and as defined in [RFC3775]. > > De-registering all the bindings is the same as > binding de-registration from foreign link described in Section 5.5. > After the de-registration step, all the packets routed by the home > agent are only forwarded to the interface attached to the home link, > even if there are other active interfaces attached to the visited > link. While the mobile node de-registers all the bindings from the > home agent, it may continue registering bindings for interface > attached to visited link to the correspondent node as shown in > Figure 9. > > 5.6.2. Using only Interface attached to the Visited Link > > The mobile node returns home and shuts down the interface attached > to > the home link as shown in Figure 10. Before shutting down the > interface, any binding for the care-of address previously associated > with the interface should be deleted. To delete the binding cache > entry, the mobile node MUST send a de-registration Binding Update > with the lifetime set to zero and include the corresponding BID > information. This scenario is not the most efficient because all > the > traffic to and from the mobile node is going through the bi- > directional tunnel, whereas the mobile node is now accessible at one > hop on the home link from its home agent. > > GT> This scenario is still confusing to me. My understanding is that > in this scenario the MN simply DOES NOT connect to the home link. If > the MN connected to a link that is identified or detected to be its > home link, it simply disconnects without sending a BU to the HA. So, > as far as the HA is concerned the MN is NOT connected at its home link > and operations continue as normal. The paragraph above, however, says > something different which does not match my understanding at all. Am I > confused? > > > > 5.6.3. Simultaneous Home and Visited Link Operation > > In this case, the mobile node returns home and continues using all > the interfaces attached to both foreign and home links as shown in > Figure 11. The mobile node indicates this by setting the 'H' flag > in > the BID mobility option. > > GT> Add: " ...as defined below." > > There are additional requirements on the > Returning Home procedures for possible ND conflicts at the home link > described below. > > In [RFC-3775], the home agent intercepts packets meant for the > mobile > node using proxy Neighbor Discovery while the mobile node is away > > > > Wakikawa (Ed.), et al. Expires August 11, 2008 [Page > 15] > > Internet-Draft MCoA February > 2008 > > > from the home link. When the mobile node returns home, the home > agent deletes the binding cache and stops proxying for the home > address so that a mobile node can configure its home address on the > interface attached to the home link. In this specification, a > mobile > node may return home, configure the home address on the interface > attached to the home link, but still use the interfaces attached to > the foreign links. In this case, a possible conflict arises when > the > both the home agent and the mobile node try to defend the home > address. If the home agent stops proxying for the home address, the > packets are always routed to the interface attached to the home link > and are never routed to the interfaces attached to the visited > links. > It is required to avoid the conflict between the home agent and the > mobile node, while still allowing the simultaneous use of home and > foreign links. The following describes the mechanism for achieving > this. > > In this specification, the home agent MUST intercept all the packets > meant for the mobile node and decide whether to send the traffic > directly to the home address on the link or tunnel to the care-of > address. The home agent intercepts all the packets even when the > mobile node is attached to the home link through one of its > interfaces. The home agent would make this decision based on the > type of packets and flows. How to make this decision is out of > scope > in this document. The critical part would be to create a neighbor > cache entry for the mobile node so that the home agent can deliver > the packets on-link. The home agent would need to know the Layer-2 > address of the interface with which the mobile node is attached to > the home link. In order to create the neighbor cache entry for the > mobile node, following operations are required. > > The mobile node sends a de-registration Binding Update to the home > agent from the interface attached to the home link. In the Binding > Update, the BID mobility option must include the BID the mobile node > had previously associated with the interface attached to the home > link. > > GT> When was this association done? What does "previously" refer to? > > The 'H' flag MUST be set in the BID mobility option. The 'C' > flag MUST NOT be set and the care-of address field MUST NOT be > included. When the 'H' flag is set, the home agent recognizes that > the mobile node wants to continue using interfaces attached to both > home and visited links. If the 'H' flag is unset, the home agent > deletes either all the bindings or the binding corresponding to the > BID included in the Binding Identifier mobility option. > > When the home agent sends the Binding Acknowledgement, it MUST set > the status value to either 0 [Binding Update Accepted] or to [MCOA > RETURNHOME WO/NDP (TBD)] in the BID mobility option depending on > home > agent configuration at the home link. The new values are: > > > > > > Wakikawa (Ed.), et al. Expires August 11, 2008 [Page > 16] > > Internet-Draft MCoA February > 2008 > > > o Binding Update Accepted (0): NDP is permitted for the home > address > at the home link. This is regular returning home operation of > [RFC-3775] > > o MCOA RETURNHOME WO/NDP (TBD): NDP is prohibited for the home > address at the home link > > When the home agent is the only router at the home link, it can > intercept all the packets by normal IP routing without using > proxying > for the home address. It stops proxy ND for the requested home > address and responds with the [Binding Update Accepted] status value > to the mobile node. The neighbor cache entry for the mobile node is > created by the regular exchange of Neighbor Solicitation and > Neighbor > Advertisement. If the home agent is not the only router on the home > link, it MUST continue defending the home address by proxy neighbor > discovery in order to intercept the mobile node's traffic. The home > agent, then, returns [MCOA RETURNHOME WO/NDP] value in the Status > field of the BID mobility option. The home agent also learns the > mobile node's layer-2 address (i.e., MAC address) during this > binding > de-registration. It stores the learnt layer-2 address in a neighbor > cache entry for the mobile node so that it can construct the layer-2 > header for the packets meant for the mobile node and forwards them > directly to the mobile node's interface attached to the home link. > > According to [RFC-3775], the mobile node MUST NOT assign the home > address to the interface attached to the home link and MUST NOT > attempt NDP operations for the home address before the completion of > binding de-registration. It MUST NOT send and reply to Neighbor > Solicitation for the home address. The home address MUST be > tentative address at this moment until it receives Binding > Acknowledgement with success status value. > > When the mobile node receives the Binding Acknowledgement and BID > mobility option, it assigns home address to the interface attached > to > the home link according to the status field of the BID. If the > value > is [Binding Update Accepted], the mobile node can start defending > the > home address using regular Neighbor Discovery. > > If the mobile node receives the [MCOA RETURNHOME WO/NDP], it MUST > NOT > defend its home address on the home link. When the mobile node > sends > packets from the interface attached to the home link, it MUST learn > the layer 2 address (i.e., MAC address) of the next hop (i.e. > default > router, it can be home agent) during the binding de- registration > and > construct the packet including layer 2 header with the learnt > layer-2 > address of the default router or the home agent. > > > > GT> Something needs to be said about the lifetime of the BU with 'H' > flag set. If the MN has to send a de-reg to the HA with Lifetime=0 and > 'H' set, for how ling is this state valid? What happens to the > lifetime of the other bindings?? > > > Wakikawa (Ed.), et al. Expires August 11, 2008 [Page > 17] > > Internet-Draft MCoA February > 2008 > > > 5.7. Receiving Binding Acknowledgement > > The verification of a Binding Acknowledgement is the same as Mobile > IPv6 (section 11.7.3 of [RFC-3775]). The operation for sending a > Binding Acknowledgement is described in Section 6.3. > > If a mobile node includes a Binding Identifier mobility option in a > Binding Update with the 'A' flag set, a Binding Acknowledgement MUST > carry a Binding Identifier mobility option. If no such mobility > option is included in the Binding Acknowledgement in response to a > Binding Update for multiple care-of address registration, this > indicates that the originating node of the Binding Acknowledgement > does not support processing the Binding Identifier mobility option. > The mobile node MUST then stop multiple care-of address registration > with that node. > > If a Binding Identifier mobility option is present in the received > Binding Acknowledgement, the mobile node checks the status field in > the option. If the status value in the Binding Identifier mobility > option is zero, the mobile node uses the value in the Status field > of > the Binding Acknowledgement. Otherwise, it uses the value in the > Status field of the Binding Identifier mobility option. > > If the status code is greater than or equal to 128, the mobile node > starts relevant operations according to the error code. Otherwise, > the mobile node assumes that the originator (home agent or > correspondent node) successfully registered the binding information > and BID for the mobile node. > > o If the Status value is [MCOA PROHIBITED], the mobile node MUST > stop registering multiple bindings to the node that sent the > Binding Acknowledgement. > > o If the Status value is [MCOA BULK REGISTRATION NOT SUPPORT], the > mobile node SHOULD stop using bulk registrations with the node > that sent the Binding Acknowledgement. > > o If [MCOA MALFORMED] is specified, it indicates that the binding > identifier mobility option is formatted wrongly. For example, if > the 'C' flag is set, all mobility options MUST have 'C' flag. It > is same for 'O' flag. > > GT> What do you mean here with the 'C' and 'O' flags? It is not clear. > Also it is not nice to find MUSTs with respect on how to use the flags > when talking about the error codes. These MUSTs, if needed, should be > moved elsewhere. > > > o If [MCOA BID CONFLICT] is specified, the binding entry specified > by the Binding Identifier mobility option is already registered > as > a regular binding. In such case, the mobile node SHOULD stop > sending Binding Updates with BID, or SHOULD use the 'O' flag to > reset all the registered bindings. > > > > > Wakikawa (Ed.), et al. Expires August 11, 2008 [Page > 18] > > Internet-Draft MCoA February > 2008 > > > 5.8. Receiving Binding Refresh Request > > The verification of a Binding Refresh Request is the same as in > Mobile IPv6 (section 11.7.4 of [RFC-3775]). The operation of > sending > a Binding Refresh Request is described in section Section 6.4. > > If a mobile node receives a Binding Refresh Request with a Binding > Identifier mobility option, it indicates that the node sending the > Binding Refresh Request message is requesting the mobile node to > send > a new Binding Update for the BID. The mobile node SHOULD then > send a > Binding Update only for the respective binding. The mobile node > MUST > include a Binding Identifier mobility option in the Binding Update. > > If no Binding Identifier mobility option is present in a Binding > Refresh Request, the mobile node sends a Binding Update according to > its Binding Update List. On the other hand, if the mobile node does > not have any Binding Update List entry for the requesting node, the > mobile node needs to register either a single binding or multiple > bindings depending on its binding management policy. > > 5.9. Sending Packets to Home Agent > > When a multihomed mobile node sends packets to its home agent, there > are conceptually two ways to construct packets. > > 1. Using Home Address Option. (required additional 24 bytes) > > 2. Using IPv6-IPv6 tunnel. (required additional 40 bytes) > > GT> Remove the period or remove the ( ) and capitalize the R. > > Beside the difference in the size of packets, there is no difference > between the two. The routing path does not get affected. With > extensions specified in this document, the mobile node is capable of > using multiple care-of addresses for outgoing packets. This is a > problem on the home agent side because it must verify the Care-of > address for all the packets received from the mobile node (i.e. > ingress filtering). When the mobile node uses the Home Address > option, the home agent MAY check the care-of address in the packet > with the registered binding entries. This causes additional > overhead > to the home agent. Therefore, the mobile node SHOULD use the bi- > directional tunnel even if it registers a binding(s) to the home > agent. > > GT> This confuses me a bit. Is there anything different from RFC3775? > Why is this section needed? > > > 5.10. Bootstrapping > > When a mobile node bootstraps and registers multiple bindings for > the > first time, it SHOULD set the 'O' flag in the Binding Identifier > mobility option. > > GT> Should this be a MUST? Otherwise what is the behavior of the HA? > > If old bindings still exists at the home agent, the > mobile node has no knowledge of which bindings still exist at the > > > > Wakikawa (Ed.), et al. Expires August 11, 2008 [Page > 19] > > Internet-Draft MCoA February > 2008 > > > home agent. This scenario happens when a mobile node reboots and > looses state regarding the registrations. If the 'O' flag is set, > all the bindings are replaced by the new binding(s). If the mobile > node receives the Binding Acknowledgement with the status code set > to > 135 [Sequence number out of window], it MUST retry sending a Binding > Update with the last accepted sequence number indicated in the > Binding Acknowledgement. > > The 'O' flag can also be used in individual Binding Updates sent to > the correspondent nodes to override any existing binding cache > entries at the correspondent node. > > > GT> Again the 'O' flag MUST be set the first time MCoA is used with a > CN I think. > > > > > > > > > Wakikawa (Ed.), et al. Expires August 11, 2008 [Page > 20] > > Internet-Draft MCoA February > 2008 > > > 6. Home Agent and Correspondent Node Operation > > 6.1. Searching Binding Cache with Binding Identifier > > If either a correspondent node or a home agent has multiple bindings > for a mobile node in their binding cache database, it can use any of > the bindings to communicate with the mobile node. How to select the > most suitable binding from the binding cache database is out of > scope > in this document. > > Whenever a correspondent node searches a binding cache for a home > address, it SHOULD uses both the home address and the BID as the > search key if it knows the corresponding BID. > > GT> This is a bid strange. Why would the HA or CN use a BID as a key? > The HoA is used as a key because the HA/CN want to send a packet with > the HoA as destination address, which causes Mobile IP to use the HoA > as a key to find an appropriate CoA. I do not think that the BIDs are > needed for this. With MCoA, the only difference is that a lookup of > the HoA will return multiple CoAs; and which one is used is out of > scope for this document. > > GT> So, the BIDs are only used as key when the receiver processes a BU > message including a BID Mobility option. Is this what this is about? > > In the example below, > if a correspondent node searches the binding with the home address > and BID2, it gets binding2 for this mobile node. > > binding1 [a:b:c:d::EUI, care-of address1, BID1] > binding2 [a:b:c:d::EUI, care-of address2, BID2] > binding3 [a:b:c:d::EUI, care-of address3, BID3] > > Figure 4: Searching the Binding Cache > > A correspondent node earns the BID when it receives a Binding > > GT> //earns/learns > > Identifier mobility option. At the time, the correspondent node > MUST > > GT>//At the time/At that time > > look up its binding cache database with the home address and the BID > retrieved from the Binding Update. If the correspondent node does > not know the BID, it searches for a binding with only the home > address. In such a case, the first matched binding is found. If > the > correspondent node does not desire to use multiple bindings for a > mobile node, it can simply ignore the BID. > > GT> This whole section needs to be cleaned based on the comment above. > > > 6.2. Receiving CoTI and Sending CoT > > When a correspondent node receives a CoTI message which contains a > Binding Identifier mobility option, it processes it as follows. > > First, the CoTI message is verified as specified in [RFC-3775]. The > Binding Identifier mobility option is processed as follows: > > o If a correspondent node does not understand a Binding Identifier > mobility option, it just ignores and skips processing the option. > The calculation of a care-of Keygen token will thus be done > without a BID value. The correspondent node returns a CoT > message > without a Binding Identifier mobility option. The mobile node > knows whether the correspondent supports processing the Binding > Identifier mobility option, by checking if the option is present > in the CoT message. > > > > > Wakikawa (Ed.), et al. Expires August 11, 2008 [Page > 21] > > Internet-Draft MCoA February > 2008 > > > o If either the 'C' or the 'O' flag is set in the Binding > Identifier > mobility option, the correspondent Node SHOULD NOT calculate a > care-of Keygen token, but MUST include a Binding Identifier > mobility option with status value set to [MCOA MALFORMED] in the > Care-of Test message. > > o Otherwise, the correspondent node MUST include a Binding > Identifier mobility option with status value set to zero > (success) > in the Care-of Test message. > > o The Care-of address field of each Binding Identifier mobility > option, can be omitted, because the mobile node can identify the > corresponding Binding Update list entry using the BID. > > 6.3. Processing Binding Update > > If a Binding Update does not contain a Binding Identifier mobility > option, its processing is same as in [RFC-3775]. If the receiver > already has multiple bindings for the home address, it MUST replace > all the existing bindings by the received binding. As a result, the > receiver node MUST have only one binding cache entry for the mobile > node. If the Binding Update is for de-registration, the receiver > MUST delete all existing bindings from its Binding Cache. > > If the Binding Update contains a Binding Identifier mobility > option(s), it is validated according to section 9.5.1 of [RFC-3775] > and the following steps. > > o If the home registration flag is set in the Binding Update, the > home agent MUST carefully operate Duplicate Address Detection > (DAD) for the received home address. If the home agent has > already had a binding(s) for the mobile node, it MUST avoid > running DAD for the home address on the home link when it > receives > the Binding Update. > > > GT> Why is this here? This is normal RFC3775 operation and should not > be affected by MCoA, no? > > The receiver MUST process the Binding Identifier mobility option(s) > in the following steps. When a correspondent node sends a Binding > Acknowledgement, the status value MUST be always stored in the > Status > field of the Binding Acknowledgement and the Status field of Binding > Identifier mobility option set to zero. > > GT> The last sentence does not make sense. Please rephrase. > > For the home agent, the status value can be stored in the Status > field of either a Binding Acknowledgement or a Binding Identifier > mobility option. If the status value is specific to one of bindings > in the bulk registration, the status value MUST be stored in the > Status field in the corresponding Binding Identifier mobility > option. > In this case, [MCOA NOTCOMPLETE] MUST be set to the Status field of > the Binding Acknowledgement so that the receiver can examine the > > > > Wakikawa (Ed.), et al. Expires August 11, 2008 [Page > 22] > > Internet-Draft MCoA February > 2008 > > > Status field of each Binding Identifier mobility option for further > operations. > > o The length value is examined. The length value MUST be either 4, > 8, or 20 depending on the 'C' and 'D' flags. If the length is > incorrect, the receiver MUST reject the Binding Update and > returns > the status value set to [MCOA MALFORMED]. > > o When the 'C' flag is set, the care-of address MUST be present in > the Binding Identifier mobility option. Otherwise, the receiver > > GT> It is not clear what "Otherwise" refers to. Replace with: "If the > care-of address is not present..." > > MUST reject the Binding Identifier mobility option and returns > the > status value set to [MCOA MALFORMED]. The operation of 'D' flag > is described in Section 8 > > o When multiple Binding Identifier mobility options are present in > the Binding Update, it is treated as bulk registration. If the > receiving node is a correspondent node, it MUST reject the > Binding > Update and returns the status value in the binding > acknowledgement > set to [MCOA BULK REGISTRATION NOT SUPPORT] > > o If the Lifetime field in the Binding Update is set to zero, the > receiving node deletes the binding entry that corresponds to the > BID in the Binding Identifier mobility option. If the receiving > node does not have an appropriate binding for the BID, it MUST > reject the Binding Update and send a Binding Acknowledgement with > status set to 133 [not home agent for this mobile node]. > > GT>This does not make sense. If the BID does not exist then the > binding never existed or has already been deleted so I would send a BA > and BID Mobility option with status 0. Status 133 means that the HoA > is not valid...which is a different issue already covered in RFC3775. > Also please move this bullet one place down to be next to Lifetime != > zero case. > > > o If the 'O' flag is set in the de-registering Binding Update, the > receiver can ignore this flag for de-registration. > > GT> This sentence is strange please rephrase. > > If the 'H' > flag is set, the home agent stores a home address in the Care-of > Address field of the binding cache entry. The home agent also > stops performing proxy ND for the mobile node's home address. > > o If the Lifetime field is not set to zero, the receiving node > registers a binding with the specified BID as a mobile node's > binding. The Care-of address is obtained from the Binding Update > packet as follows: > > * If the 'C' flag is set in the Binding Identifier mobility > option, the care-of address is copied from the care-of address > field in the Binding Identifier mobility option. > > * If the 'C' flag is not set in the Binding Identifier mobility > option, the care-of address is copied from the source address > field of the IPv6 header. > > * If the 'C' flag is not set and an alternate care-of address is > present, the care-of address is copied from the Alternate > > > > Wakikawa (Ed.), et al. Expires August 11, 2008 [Page > 23] > > Internet-Draft MCoA February > 2008 > > > Care-of address mobility option. > > o Once the care-of address(es) has been retrieved from the Binding > > GT>//has/have > > Update, the receiving nodes creates new binding(s). > > * If only the 'O' flag is set in the Binding Identifier mobility > option, the home agent removes all the existing bindings and > registers the received bindings. > > * If the receiver has a regular binding which does not have BID > for the mobile node, it must not process the binding update. > The receiver should sent a binding acknowledgement with status > set to [MCOA BID CONFLICT]. > > GT> This makes no sense. What do you mean? > > > * If the receiver already has a binding with the same BID, it > > GT>// same BID, it/ same BID and different care-of address, it > > MUST update the binding and responds with a Binding > > GT>//responds/respond > > Acknowledgement with status set to 0 [Binding Update > accepted]. > > * If the receiver does not have a binding entry for the BID, it > registers a new binding for the BID and responds with a > Binding > Acknowledgement with status set to 0 [Binding Update > accepted]. > > GT> What happens if one receives a new BID mapped to a CoA already in > the binding cache (but mapped to different BID?) Is this allowed? Is > this how one can change the BIDs it is using? > > > If all the above operations are successfully completed, a Binding > Acknowledgement containing the Binding Identifier mobility options > MUST be sent to the mobile node. Whenever a Binding Acknowledgement > is sent, all the Binding Identifier mobility options stored in the > Binding Update MUST be copied to the Binding Acknowledgement except > the status field. The Care-of address field in each Binding > Identifier mobility option, however, can be omitted, because the > mobile node can match a corresponding binding update list entry > using > the BID. > > GT> Something needs to be said about the lifetime of the bindings. I > assume that the Lifetime field of the BU updates the lifetime of all > the bindings, whether a regular or bulk MCoA registration is > performed. > > > 6.4. Sending Binding Refresh Request > > When a node (home agent or correspondent node) sends a Binding > Refresh Request for a particular binding created with the BID, the > node SHOULD include the Binding Identifier mobility option in the > Binding Refresh Request. > > GT> This needs a bit more...which BID mobility option is included? > Just one? All of them? Again we need to be clear what the lifetime > does and how it relates to each of the CoAs. > > 6.5. Receiving Packets from Mobile Node > > When a node receives packets with a Home Address destination option > from a mobile node, it MUST check that the care-of address that > appears in the source address field of the IPv6 header MUST be equal > to one of the care-of addresses in the binding cache entry. If no > binding is found, the packets MUST be silently discarded. > > GT> Why don't we just point to RFC3775 and say that the exact same > processing is used here? > > The node > MUST also send a Binding Error message as specified in [RFC-3775]. > This verification MUST NOT be done for a Binding Update. > > > > Wakikawa (Ed.), et al. Expires August 11, 2008 [Page > 24] > > Internet-Draft MCoA February > 2008 > > > 7. Network Mobility Applicability > > The binding management mechanisms are the same for a mobile host > that > uses Mobile IPv6 and for a mobile router that is using the NEMO > Basic > Support protocol [RFC-3963]. Therefore the extensions described in > this document can also be used to support a mobile router with > multiple care-of addresses. Figure 5 shows an example format of a > Binding Update sent by a mobile router. > > IPv6 header (src=CoA, dst=HA) > IPv6 Home Address Option > ESP Header > Mobility header > -BU > Mobility Options > - Binding Identifier > - Mobile Network Prefix > > Figure 5: NEMO Binding Update > > > > > > GT> Why is this example here? I would remove it together with the > last sentence. > > > > > > > > > > > > > > > > > > > > > > > > > > > Wakikawa (Ed.), et al. Expires August 11, 2008 [Page > 25] > > Internet-Draft MCoA February > 2008 > > > 8. DSMIPv6 Applicability > > Dual Stack Mobile IPv6 (DSMIPv6) [ID-DSMIPv6] extends Mobile IPv6 to > register an IPv4 care-of address instead of the IPv6 care-of address > when the mobile node is attached to an IPv4-only access network. It > also allows the mobile node to acquire an IPv4 home address in > addition to an IPv6 home address for use with IPv4-only > correspondent > nodes. This section describes how multiple care-of address > registration works with IPv4 care-of and home addresses. > > 8.1. IPv4 Care-of Address Registration > > The mobile node can use the extensions described in the document to > register multiple care-of addresses, even if some of the care-of > addresses are IPv4 address. > > Bulk registration MUST NOT be used for the initial binding from an > IPv4 care-of address. This is because, the Binding Update and > binding acknowledgement exchange is used to detect NAT on the path > between the mobile node and the home agent. So the mobile node > needs > to check for a NAT between each IPv4 care-of address and the home > agent. > > The Binding Update MUST be sent to the IPv4 home agent address by > using UDP and IPv4 headers as shown in Figure 6. It is similar to > [ID-DSMIPv6] except that the IPv4 care-of address option MUST NOT be > used when the BID mobility option is used. > > IPv4 header (src=V4ADDR, dst=HA_V4ADDR) > UDP Header > IPv6 header (src=V6HoA, dst=HAADDR) > ESP Header > Mobility header > -BU > Mobility Options > - Binding Identifier (IPv4 CoA) > > Figure 6: Initial Binding Update for IPv4 Care-of Address > > Whenever a NAT is detected, mobile node MUST NOT use bulk > registration for the IPv4 care-of address. > > GT> This was repeated above. Delete. > > If a NAT is not detected, > the mobile node can update the IPv4 care-of address by using BULK > > GT>//BULK/bulk > > registration. The mobile node can register the IPv4 care-of address > along with other care-of addresses. Figure 7 shows the Binding > > GT>// other care-of addresses/ other IPv4 and IPv6 care-of addresses > > Update format when the mobile node sends a Binding Update from one > of > its IPv6 care-of addresses. If the mobile node sends a BU from IPv4 > care-of address, it MUST follow the format described in Figure 6. > Note that the IPv4 Care-of Address must be registered by non bulk > > > > Wakikawa (Ed.), et al. Expires August 11, 2008 [Page > 26] > > Internet-Draft MCoA February > 2008 > > > Binding registration, whenever it is changed. > > > NAT detection MUST be > carried out for every new IPv4 addresses. > > GT> Again, this was repeated above. Delete. > > IPv6 header (src=V6CoA, dst=HAADDR) > IPv6 Home Address Option > ESP Header > Mobility header > -BU > Mobility Options > - Binding Identifier (IPv6/v4 CoA) > - Binding Identifier (IPv6/v4 CoA) > - ... > > Figure 7: Binding Bulk Registration for IPv4 care-of address > > If the home agent rejects the IPv4 care-of address, it MUST store > the > error code value in the Status field of the BID mobility option. > The > home agent MUST send the Binding Acknowledgement and all the > received > BID mobility options to the mobile node. > > GT> This has already been explained in other sections. It is not good > to repeat MUST statements about the same thing. Delete the whole > paragraph$B!D(B.or just point to HA processing section. > > > > 8.2. IPv4 HoA Management > > When the mobile node wants to configure an IPv4 home address in > addition to the IPv6 home address, it can request for one using the > IPv4 Home Address option in the Binding Update. If the home agent > accepts the Binding Update, the mobile node can now register > multiple > care-of addresses for the IPv4 home address in addition to the IPv6 > home address. The same set of care-of addresses will be registered > for both IPv6 and IPv4 home addresses. The mobile node cannot bind > different set of care-of addresses to each home address. > > The home agent includes the IPv4 address acknowledgement option in > the Binding Acknowledgement only if the mobile node had requested > for > the IPv4 home address. > > GT> Rephrase: "According to [DSMIPv6], the home agent includes the > IPv4 address acknowledgement option in the Binding Acknowledgement > only if the mobile node requests an IPv4 home address in the > corresponding Binding Update. " > > > The IPv4 address acknowledgement option MUST > be present before any BID option. The status field of the IPv4 > address acknowledgement option contains only the error code > regarding > IPv4 home address management. > > GT>// the error code regarding IPv4 home address management/ the error > code corresponding to the IPv4 home address. > > The error values related to the IPv4 > care-of address registration MUST be stored in the BID mobility > option. > > > > > > > > > > > > > Wakikawa (Ed.), et al. Expires August 11, 2008 [Page > 27] > > Internet-Draft MCoA February > 2008 > > > 9. IPsec and IKEv2 interaction > > Mobile IPv6 [RFC-3775] and the NEMO protocol [RFC-3963] require the > use of IPsec to protect signaling messages like Binding Updates, > Binding Acknowledgements and return routability messages. IPsec may > also be used protect all reverse tunneled data traffic. The Mobile > > GT> //used protect all reverse tunneled data / used to protect all > tunneled data/ > > IPv6-IKEv2 specification [RFC-4877] specifies how IKEv2 can be used > to setup the required IPsec security associations. The following > assumptions were made in [RFC-3775], [RFC-3963] and the MIP6-IKEv2 > specification with respect to the use of IKEv2 and IPsec. > > GT> Why is MIP6-IKEv2 not properly referenced? > > o There is only one primary care-of address per mobile node. > > o The primary care-of address is stored in the IPsec database for > tunnel encapsulation and decapsulation. > > o When the home agent receives a packet from the mobile node, the > source address is verified against the care-of address in the > corresponding binding cache entry. If the packet is a reverse > tunneled packet from the mobile node, the care-of address check > is > done against the source address on the outer IPv6 header. The > reverse tunnel packet could either be a tunneled HoTi message or > tunneled data traffic to the correspondent node. > > o The mobile node runs IKEv2 (or IKEv1) with the home agent using > the care-of address. The IKE SA is based on the care-of address > of the mobile node. > > The above assumptions may not be valid when multiple care-of > addresses are used by the mobile node. In the following sections, > the main issues with the use of multiple care-of address with IPsec > are addressed. > > 9.1. Use of Care-of Address in the IKEv2 exchange > > For each home address the mobile node sets up security associations > with the home agent, the mobile node must pick one care-of address > and use that as the source address for all IKEv2 messages exchanged > to create and maintain the IPsec security associations associated > with the home address. The resultant IKEv2 security association is > created based on this care-of address. > > GT> Add "according to MIP6-IKEv2 ..." until you have something new. > > If the mobile node needs to change the care-of address, it just > sends > a Binding Update with the care-of address it wants to use, with the > corresponding Binding Identifier mobility option, and with the 'K' > bit set. This will force the home agent to update the IKEv2 > security > association to use the new care-of address. If the 'K' bit is not > supported on the mobile node or the home agent, the mobile node MUST > > > > Wakikawa (Ed.), et al. Expires August 11, 2008 [Page > 28] > > Internet-Draft MCoA February > 2008 > > > re-establish the IKEv2 security association with the new care-of > address. This will also result in new IPsec security associations > being setup for the home address. > > > > On Feb 8, 2008 4:35 PM, Vijay Devarapalli > wrote: >> Hello, >> >> There is a pre-06 version of this draft available at >> http://dvijay.com/ietf/internet-drafts/mext/mcoa.txt >> >> The draft has been cleaned up a bit. In case, you haven't reviewed >> the document yet, please review the pre-06 version. In case you >> have already reviewed version 05, please send your comments based >> on version 05. >> >> The diff between 05 and pre-06 can be found at >> http://dvijay.com/ietf/internet-drafts/mext/diff-05-06.html >> >> Vijay >> >> >> marcelo bagnulo braun wrote: >>> Hi, >>> >>> With this email we issue the WGLC for draft-ietf-monami6- >>> multiplecoa-05.txt >>> The WGLC will be open till the 11 of february. >>> We kindly ask the WG to review the document and provide comments. >>> >>> Please note that a valid comment at this stage is positive feedback >>> about the document being ready to be shipped. >>> So, please if you think the doc is ready, do express this to the ml >>> (or to the chairs) >>> >>> For you convenience, additional information about the document: >>> >>> Title : Multiple Care-of Addresses Registration >>> Author(s) : R. Wakikawa, et al. >>> Filename : draft-ietf-monami6-multiplecoa-05.txt >>> Pages : 44 >>> Date : 2008-01-27 >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-05.txt >>> >>> Thanks, Julien and marcelo >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> http://www.ietf.org/mailman/listinfo/mext >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> http://www.ietf.org/mailman/listinfo/mext >> > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Feb 12 05:21:35 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B99028C205; Tue, 12 Feb 2008 05:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.489 X-Spam-Level: * X-Spam-Status: No, score=1.489 tagged_above=-999 required=5 tests=[AWL=0.704, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_24=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+3CXaqPQIIb; Tue, 12 Feb 2008 05:21:30 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52B9328C206; Tue, 12 Feb 2008 05:21:30 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8C1628C206 for ; Tue, 12 Feb 2008 05:21:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRqiaEGpSfJB for ; Tue, 12 Feb 2008 05:21:24 -0800 (PST) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.176]) by core3.amsl.com (Postfix) with ESMTP id BF18A28C205 for ; Tue, 12 Feb 2008 05:21:23 -0800 (PST) Received: by el-out-1112.google.com with SMTP id j27so2542062elf.25 for ; Tue, 12 Feb 2008 05:22:47 -0800 (PST) Received: by 10.143.164.19 with SMTP id r19mr971629wfo.179.1202822566804; Tue, 12 Feb 2008 05:22:46 -0800 (PST) Received: by 10.142.11.11 with HTTP; Tue, 12 Feb 2008 05:22:46 -0800 (PST) Message-ID: Date: Tue, 12 Feb 2008 13:22:46 +0000 From: "George Tsirtsis" To: "RYUJI WAKIKAWA" In-Reply-To: <55AB1BB1-1C3B-4C6E-8E04-5584C9669B17@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <47AC84E3.2030605@azairenet.com> <55AB1BB1-1C3B-4C6E-8E04-5584C9669B17@gmail.com> Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] WGLC for draft-ietf-monami6-multiplecoa-05.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Ryuji, thanks for your responses. Some comments inline... On Feb 12, 2008 12:07 AM, RYUJI WAKIKAWA wrote: > Hi George, > > Thanks a lot for comments, please find my reply inline. > > On 2008/02/12, at 0:07, George Tsirtsis wrote: > > > Hi Vijay/Ryuji et.al., > > > > This version (pre-6) is much improved so well done. There are still > > several minor technical issues, unlear text, and nits, which I > > indicate below, but I want to highlight a few more important technical > > issues upfront: > > > > 1) Lifetime of BIDs: I think the relation between BIDs and BU Lifetime > > field is not clear. I think the assumption has been that the Lifetime > > is common across all BIDs. > > Yes. This is because BID option does not have lifetime field. > > > IMO there needs to be more explicit > > language in the spec to make this clear.. > > OK > > > > > - a BU with one or more BIDs, O=3D0, and Lifetime !=3D 0, updates the > > lifetime of all the BIDs in the binding cache. i.e., to maintain all > > the BIDs you just need to send a Binding refresh including at least > > BID.(right?) > > - a BU with O=3D1 replaces all BIDs and associates them with lifetime > > in the BU > > - a BU with one or more BIDs, O=3D0, and Lifetime =3D 0, removes only t= he > > listed BIDs and does not affect the lifetime of other BIDs in the > > binding cache > > All you mentioned above are correct. > > > - a BU with lifetime=3D0 and H=3D1 indicates the MN is at home link, but > > the lifetime of other BIDs is not affected. > > right. > > > How is the home link > > state maintained though? This looks like hard state at the moment and > > I do not like it. Any ideas? > > I might miss your question. > > HA should verify the reachability of the mobile node at the home link. > If the reachability is missed, the HA should clean up the all the home > link states. > GT> Yes, this is what I think is not ideal. Mobile IP, as most well designed IP protocols, is a soft state protocol, and all of its state is associated with lifetimes which are maintained by signaling. We are now seem to be saying that when you have a home link, and although the HA must maintain state for that fact, that state is "hard" and can only be cleared by mechanisms that are outside protocol itself e.g., L2 triggers indicating the link is down. GT> I think a possible alternative which is even implied (but not clearly stated) by the current draft, is to use the lifetime maintained by the visited links. In other words, in the H=3D1 scenario, the MN has at least one other binding corresponding to a visited link. That visited link CoA is associated in the HA with a Lifetime. This same Lifetime value should be what maintains the home link state. The difference is that the MN does not maintain the home link state directly (i.e., it only has to send a BU with H=3D1 once) and then the state is maintained by the Lifetime associated with visited link BIDs. The implication is that if the MN deregisters all of its visited link CoAs the home link state is automatically removed i.e., it is as if the MN sent a BU with Lifetime=3D0 and no BID extensions. Does this make sense? > > > 2) Changing BIDs. the draft indicates that BIDs can be changed for > > privacy reasons. While I still do not understand what these reasons > > are, > > The point is not privacy or security reason, but MN can always pick a > new BID. > GT> But for what reason? the draft somehow implies that this is a good practice....while I think it is rather dangerous practice since it would cause uneccessary and difficult to dimension for BU signaling traffic. > > I also do not see anywhere how BIDs can be changed. Is is done by > > sending a BU with a new BID mapped to a CoA that is already in the > > binding cache (but mapped to another BID)? > > yes. > > > I indicate that this could > > be added somewhere inline, but some additional care also needs to be > > taken e.g., can you reuse the BID you are replacing in the same BU? > > This seems to be corner-case, but we will clarify it. > GT> Yes, do. But also I would warn against doing this for no particular rea= son. > > 3) Section 5.6.2 (using only IF attached to visitied) is very > > confusing: I copy here the comment I also placed inline below: > > My understanding is that in this scenario the MN simply DOES NOT > > connect to the home link. If the MN connected to a link which is > > identified or detected to be its home link, it simply disconnects > > without sending a BU to the HA. So, as far as the HA is concerned the > > MN is NOT connected at its home link and operations continue as > > normal. The text in this section, however, says something different > > which does not match my understanding at all. Am I confused? > > We need one more operation here. > > What about the binding cache for the CoA previously assigned to the > interface(which is now disconnected)? > The interface is now disconnected, but the old binding cache for the > previous CoA assigned to that interface > might be still active at the home agent. > It should explicitly send de-registration BU for that binding cache, > since > MN has other active interfaces to send that BU. > GT> What CoA previously assigned are you talking about? At a home or a visited link? We do not use CoAs in home links (are we?), and CoAs on visited links are normal case in this scenario. I do not understand. \> We will revise the texts of section 5.6.2. > > thanks > ryuji > > > > Thanks again for all the effort and see the rest of the detailed > > review below. > > > > George > > > > > > > > -----------------------------------------------------------------------= -------------------------------------------------------- > > 1. Introduction > > > > ... > > > > But assigning a single home address to a node is more > > advantageous than assigning multiple home addresses because > > applications do not need to be aware of the multiplicity of home > > addresses. > > > > GT> I am not sure I agree with this statement. I think effective use > > of multiple home addresses by applications is a better and more robust > > technique but it does require applications to be written in a certain > > way. Multiple CoAs allow multihoming awareness to be outsourced to a > > different part of the IP stack but, especially when combined with per > > flow bindings, it results in routing that is not purely destination > > address based. This is not necessarily a good thing for Internet > > routing as a whole and only acceptable because it is only confined in > > HAs. I think we can have a bit better applicability statement that is > > more objective and looks at the big picture. i.e., at the > > architectural limitations of this approach. > > > > ... > > 3. Protocol Overview > > > > A new extension called the Binding identification number (BID) is > > > > GT> I think the name of the extension is "Binding Identifier > > Mobility Option"? > > > > introduced to distinguish between multiple bindings pertaining to > > the > > same home address. If a mobile node configures several IPv6 global > > addresses on one or more of its interfaces, it can register these > > addresses with its home agent as care-of addresses. If the mobile > > node wants to register multiple bindings, it MUST generate a BID for > > each care-of address and store the BID in the binding update > > list. A > > mobile node can manipulate each binding independently by using the > > BIDs. The mobile node then registers its care-of addresses by > > sending a Binding Update with a Binding Identifier mobility option. > > The BID is included in the Binding Identifier mobility option. > > After > > receiving the Binding Update with a Binding Identifier mobility > > option, the home agent MUST copy the BID from the Binding Identifier > > mobility option to the corresponding field in the binding cache > > entry. If there is an existing binding cache entry for the mobile > > node, and the if the BID in the Binding Update does not match the > > one > > > > GT> // and the if/ and if > > > > with the existing entry, the home agent MUST create a new binding > > cache entry for the new care-of address and BID. The mobile node > > can > > register multiple care-of addresses either independently in > > individual Binding Updates or multiple at once in a single Binding > > Update. > > > > If the mobile host wishes to register its binding with a > > correspondent node, it must perform return routability operations. > > This includes managing a Care-of Keygen token per care-of address > > and > > exchanging CoTi and CoT message with the correspondent node for each > > care-of address. It is RECOMMENDED that the mobile node uses the > > same BID that it used with the home agent for a particular care-of > > address. > > > > GT> I do not see why this is RECOMMENDED either :-). At most this is > > a MAY, since I can not think of any reason why this not totally an > > implementation decision. > > > > For protocol simplicity, bulk registration to correspondent > > nodes is not supported in this document. This is because the Return > > Routability mechanism introduced in [RFC-3775] cannot be easily > > extended to verify multiple care-of addresses stored in a single > > Binding Update. > > > > If the mobile node decides to act as a regular mobile node compliant > > with [RFC-3775], it sends a Binding Update without any Binding > > Identifier mobility options. The receiver of the Binding Update > > deletes all the bindings registering with a BID and registers only a > > single binding for the mobile node. Note that the mobile node can > > continue using BID even if only has a single binding is active. > > > > GT> //BID even if only has a/BIDs even if it has only a/ > > > > > > Binding cache lookup is done based on the home address and BID > > information. This is different from RFC 3775, where only the home > > address is used for binding cache lookup. The binding cache lookup > > may also involve policy or flow filters in cases where some policy > > or > > flow filters are used to direct certain packets or flows to a > > particular care-of address. The binding cache lookup using policy > > or > > flow filters is out of scope for this document. In case the binding > > cache lookup, using the combination of home address and BID, does > > not > > return a valid binding cache entry, the home agent MAY perform > > another lookup based on only the home address. This is > > implementation dependent and configurable on the home agent. > > > > The mobile node may return to the home link through one of its > > interfaces. There are three options possible for the mobile node > > when its returns home. > > > > 1. The mobile node uses only the interface with which it attaches > > to > > the home link. It de-registers all bindings related to all > > care-of addresses. The interfaces still attached to the visited > > link are no longer going to be receiving any encapsulated > > traffic > > > > GT> //link/link(s) > > > > from the home agent. > > > > 2. The mobile node uses only the interfaces still attached to the > > visited link. > > > > GT> //link/link(s) > > > > The interface with which the mobile node attaches > > to the home link is not used. > > > > 3. The mobile node may simultaneously use both the interface > > attached to the home link and the interfaces still attached to > > the visited links. > > > > GT> //links/link(s) > > > > ... > > > > > > Wakikawa (Ed.), et al. Expires August 11, 2008 > > [Page 8] > > > > Internet-Draft MCoA February > > 2008 > > > > > > Status > > > > When the Binding Identifier mobility option is included in a > > Binding Acknowledgement, this field overwrites the status field > > correspondent to each binding in the Binding Acknowledgement. If > > this field is zero, the receiver MUST use the registration status > > stored in the Binding Acknowledgement message. This Status field > > can be used to carry error information for a Care-of Test > > message. > > The status is 8-bit unsigned integer. > > > > The possible status codes > > are the same as the status codes of Binding Acknowledgement. > > > > GT> This is not true, right? New values are defined in section 4.5. > > Care-of address (C) flag > > > > When this flag is set, it indicates that a valid care-of address > > is present in the care-of address field in the BID mobility > > option. This flag MUST be set whenever the mobile node sends > > multiple care-of addresses in a single Binding Update, i.e., bulk > > registration. It MAY also used as a substitute for alternate > > care-of address option even for Binding Updates that are sent > > only > > for one care-of address. This flag is valid only for Binding > > Update sent to the home agent. > > > > Overwrite (O) flag > > > > When this flag is set, a mobile node requests the recipient to > > replace all the bindings to binding entries stored in a Binding > > Update. > > > > Simultaneous Home and Foreign Binding (H) flag > > > > This flag indicates that the mobile node registers multiple > > bindings to the home agent while is attached to the home link. > > This flag is valid only for a Binding Update sent to the home > > agent. > > > > DSMIPv6 (D) flag > > > > This flag indicates that the care-of address is an IPv4 address. > > When this flag is set, the care-of address field MUST contain an > > IPv4 address. > > > > Reserved > > > > 5 bits Reserved field. The reserved field MUST be zero. > > > > > > > > > > > > > > > > Wakikawa (Ed.), et al. Expires August 11, 2008 > > [Page 9] > > > > Internet-Draft MCoA February > > 2008 > > > > > > Care-of Address > > > > This field has the variable length depending on the specified > > flags. When the 'C' flag is set and the 'D' flag is not, an IPv6 > > care-of address for the corresponding BID is stored in this > > field. > > If both 'C' and 'D' flags are set, an IPv4 Care-of Address is > > carried in this field. This field MUST NOT be used if a Binding > > Identifier mobility option is included in any other message other > > than a Binding Update. > > > > GT> For completeness you may want to add: "...or if the 'C' flag is > > not set." > > ... > > 5. Mobile Node Operation > > > > 5.1. Management of Care-of Addresses and Binding Identifier > > > > // Addresses and Binding Identifier/ Address(es) and Binding > > Identifier(s) > > > > There are two cases when a mobile node might acquire several care-of > > addresses. Note that a mixture of the two cases are also possible. > > > > GT> //are/is > > > > 1. A mobile node may be using several physical network interfaces > > and acquires a care-of address on each of its interfaces. > > > > 2. A mobile node uses a single physical network interface, but > > receives advertisements for multiple prefixes on the link the > > interface is attached to. This will result in the mobile node > > configuring several global addresses on the interface from each > > of the announced prefixes. > > > > The difference between the above two cases is only in the number of > > physical network interfaces and therefore irrelevant in this > > document. What is of significance is the fact that the mobile node > > has several addresses it can use as care-of addresses. > > > > A mobile node assigns a BID to each care-of address when it wants to > > register them simultaneously with its home address. The BID MUST be > > unique for a given home address and care-of address pair. The value > > should be an integer between 1 and 65535. Zero and negative values > > MUST NOT be used as a BID. If a mobile node has only one care-of > > > > GT> //as a BID/as BIDs > > > > address, the assignment of a BID is not needed until it has multiple > > care-of addresses to register with, at which time all of the care-of > > addresses MUST be mapped to BIDs. > > > > 5.2. Return Routability: Sending CoTI and Receiving CoT > > > > When a mobile node wants to register multiple care-of address with a > > correspondent node, it MUST have the valid Care-of Keygen token per > > care-of address. > > > > For the Home Keygen, the mobile node needs only for > > the home address. > > > > GT> Rephrase the above: "The mobile node needs only one Home Keygen > > for its home address." > > > > > > The mobile node MUST include a Binding Identifier mobility option in > > the Care-of Test Init message. It MUST NOT set any flags in the > > mobility option. The receiver (i.e. correspondent node) will > > calculate a care-of Keygen token as specified in [RFC-3775] and > > reply > > with a Care-of Test message, with the Binding Identifier mobility > > option as described in Section 6.2. When the mobile node receives > > the Care-of Test message, the message is verified as in [RFC-3775]. > > If a Binding Identifier mobility option is not present in the CoT > > message in reply to the CoTI message that included a Binding > > Identifier mobility option, the mobile node must assume that the > > correspondent node does not support Multiple Care-of Address > > > > > > > > Wakikawa (Ed.), et al. Expires August 11, 2008 [Page > > 12] > > > > Internet-Draft MCoA February > > 2008 > > > > > > registration. Thus, the mobile node MUST NOT use a Binding > > Identifier mobility option in any future Binding Updates to that > > correspondent node. The mobile node MAY skip re-sending regular > > CoTI > > message and keep the received care-of Keygen token for the regular > > Binding Update. > > > > > > GT> Should we also say anything about Enhanced RO based on RFC4866? > > > > > > 5.3. Binding Registration > > > > For the multiple Care-of Addresses registration, the mobile node > > MUST > > include a Binding Identifier mobility option(s) in the Binding > > Update > > as shown in Figure 2. The BID is copied from a corresponding > > Binding > > Update List entry to the BID field of the Binding Identifier > > mobility > > option. When IPsec ESP is used for protecting the Binding Update, > > the care-of address cam be carried in the Care-of Address field of > > > > GT> //cam/can > > > > the Binding Identifier mobility option. If this is done, the > > alternate care-of address option MUST NOT be included in the Binding > > Update. > > For binding registration to a correspondent node, the mobile > > node MUST have both active Home and Care-of Keygen tokens for Kbm > > (see Section 5.2.5 of [RFC-3775]) before sending the Binding Update. > > The care-of Keygen tokens MUST be maintained for each care-of > > address > > that the mobile node wants to register to the correspondent node. > > The Binding Update to the correspondent node is protected by the > > Binding Authorization Data mobility option that is placed after the > > Binding Identifier mobility option. > > > > IPv6 header (src=3DCoA, dst=3DHA) > > IPv6 Home Address Option > > ESP Header (for home registration) > > Mobility header > > -BU > > Mobility Options > > - Binding Identifier mobility option > > - Binding Authorization mobility option > > (for Route Optimization) > > > > Figure 2: Binding Update for Binding Registration > > > > 5.4. Bulk Registration > > > > Bulk registration is an optimization for binding multiple care-of > > addresses to a home address using a single Binding Update. This is > > very useful if the mobile node, for instance, does not want to > > send a > > lot of signaling messages through an interface where the bandwidth > > is > > scarce. > > > > To use bulk registration, the mobile node includes a Binding > > Identifier Mobility option for each BID and Care-of address pair it > > wants to register in the same Binding Update message. This is shown > > > > > > > > Wakikawa (Ed.), et al. Expires August 11, 2008 [Page > > 13] > > > > Internet-Draft MCoA February > > 2008 > > > > > > in Figure 3. The rest of the fields and options in the Binding > > Update such as Lifetime, Sequence Number, the flags in the Binding > > Update are common across all care-of addresses. The alternate > > care-of address option MUST NOT be used. > > > > In the bulk registration, the Sequence Number field of a Binding > > Update SHOULD be carefully configured. This is because all the > > bulk- > > registered bindings uses the same Sequence Number specified in the > > > > GT>//uses/use > > > > Binding Update. If each binding uses different sequence number, a > > mobile node MUST use the largest sequence number from the Binding > > Update list entries used for the bulk registration. If the mobile > > node cannot select a sequence number for all the bindings due to > > sequence number out of window, it MUST NOT use the bulk registration > > for the binding whose sequence number is out of window. A separate > > Binding Update should be sent for the binding. > > > > IPv6 header (src=3DCoA, dst=3DHA) > > IPv6 Home Address Option > > ESP Header > > Mobility header > > -BU > > Mobility Options > > - Binding Identifier mobility options > > (C flag is set, O flag is optional, > > BID and CoA are stored) > > > > Figure 3: Binding Update for Bulk Registration > > > > If the mobile node wants to replace existing registered bindings on > > the home agent with the bindings in the sent Binding Update, it sets > > the 'O' flag. Section 6.3 describes this registration procedure in > > detail. > > > > 5.5. Binding De-Registration > > > > When a mobile node decides to delete all the bindings for its home > > address, it sends a regular de-registration Binding Update with > > lifetime set to zero as defined in [RFC-3775]. The Binding > > Identifier mobility option is not required. > > > > If a mobile node wants to delete a particular binding(s) from its > > home agent and correspondent nodes (e.g. from foreign link), the > > > > GT> Remove "(e.g. from foreign link)" it is not clear what it means. > > > > mobile node sends a Binding Update with lifetime set to zero and > > includes a Binding Identifier mobility option(s) with the BID(s) it > > wants to de-register. The receiver will remove only the care-of > > address(es) that match(es) the specified BID(s). The care-of > > addresses field of each mobility option SHOULD be omitted, because > > the receiver will remove the binding matching the specified BID. > > > > GT> // SHOULD be omitted/ SHOULD be omitted by the sender and MUST be > > ignored by the receiver/ > > > > Wakikawa (Ed.), et al. Expires August 11, 2008 [Page > > 14] > > > > Internet-Draft MCoA February > > 2008 > > > > > > 5.6. Returning Home > > > > The mobile node may return to the home link, by attaching to the > > home > > link through one of its interfaces. When the mobile node wants to > > return home, it should be configured with information on what > > interface it needs to use. The mobile node may use only the > > interface with which it is attached to the home link, only the > > interfaces still attached to the visited link or use both interfaces > > attached to the home link and visited link simultaneously. The > > following describes each option in more detail. > > > > 5.6.1. Using only Interface attached to the Home Link > > > > The mobile node returns home and de-registers all the bindings as > > shown in Figure 9. > > > > GT> add: "...and as defined in [RFC3775]. > > > > De-registering all the bindings is the same as > > binding de-registration from foreign link described in Section 5.5. > > After the de-registration step, all the packets routed by the home > > agent are only forwarded to the interface attached to the home link, > > even if there are other active interfaces attached to the visited > > link. While the mobile node de-registers all the bindings from the > > home agent, it may continue registering bindings for interface > > attached to visited link to the correspondent node as shown in > > Figure 9. > > > > 5.6.2. Using only Interface attached to the Visited Link > > > > The mobile node returns home and shuts down the interface attached > > to > > the home link as shown in Figure 10. Before shutting down the > > interface, any binding for the care-of address previously associated > > with the interface should be deleted. To delete the binding cache > > entry, the mobile node MUST send a de-registration Binding Update > > with the lifetime set to zero and include the corresponding BID > > information. This scenario is not the most efficient because all > > the > > traffic to and from the mobile node is going through the bi- > > directional tunnel, whereas the mobile node is now accessible at one > > hop on the home link from its home agent. > > > > GT> This scenario is still confusing to me. My understanding is that > > in this scenario the MN simply DOES NOT connect to the home link. If > > the MN connected to a link that is identified or detected to be its > > home link, it simply disconnects without sending a BU to the HA. So, > > as far as the HA is concerned the MN is NOT connected at its home link > > and operations continue as normal. The paragraph above, however, says > > something different which does not match my understanding at all. Am I > > confused? > > > > > > > > 5.6.3. Simultaneous Home and Visited Link Operation > > > > In this case, the mobile node returns home and continues using all > > the interfaces attached to both foreign and home links as shown in > > Figure 11. The mobile node indicates this by setting the 'H' flag > > in > > the BID mobility option. > > > > GT> Add: " ...as defined below." > > > > There are additional requirements on the > > Returning Home procedures for possible ND conflicts at the home link > > described below. > > > > In [RFC-3775], the home agent intercepts packets meant for the > > mobile > > node using proxy Neighbor Discovery while the mobile node is away > > > > > > > > Wakikawa (Ed.), et al. Expires August 11, 2008 [Page > > 15] > > > > Internet-Draft MCoA February > > 2008 > > > > > > from the home link. When the mobile node returns home, the home > > agent deletes the binding cache and stops proxying for the home > > address so that a mobile node can configure its home address on the > > interface attached to the home link. In this specification, a > > mobile > > node may return home, configure the home address on the interface > > attached to the home link, but still use the interfaces attached to > > the foreign links. In this case, a possible conflict arises when > > the > > both the home agent and the mobile node try to defend the home > > address. If the home agent stops proxying for the home address, the > > packets are always routed to the interface attached to the home link > > and are never routed to the interfaces attached to the visited > > links. > > It is required to avoid the conflict between the home agent and the > > mobile node, while still allowing the simultaneous use of home and > > foreign links. The following describes the mechanism for achieving > > this. > > > > In this specification, the home agent MUST intercept all the packets > > meant for the mobile node and decide whether to send the traffic > > directly to the home address on the link or tunnel to the care-of > > address. The home agent intercepts all the packets even when the > > mobile node is attached to the home link through one of its > > interfaces. The home agent would make this decision based on the > > type of packets and flows. How to make this decision is out of > > scope > > in this document. The critical part would be to create a neighbor > > cache entry for the mobile node so that the home agent can deliver > > the packets on-link. The home agent would need to know the Layer-2 > > address of the interface with which the mobile node is attached to > > the home link. In order to create the neighbor cache entry for the > > mobile node, following operations are required. > > > > The mobile node sends a de-registration Binding Update to the home > > agent from the interface attached to the home link. In the Binding > > Update, the BID mobility option must include the BID the mobile node > > had previously associated with the interface attached to the home > > link. > > > > GT> When was this association done? What does "previously" refer to? > > > > The 'H' flag MUST be set in the BID mobility option. The 'C' > > flag MUST NOT be set and the care-of address field MUST NOT be > > included. When the 'H' flag is set, the home agent recognizes that > > the mobile node wants to continue using interfaces attached to both > > home and visited links. If the 'H' flag is unset, the home agent > > deletes either all the bindings or the binding corresponding to the > > BID included in the Binding Identifier mobility option. > > > > When the home agent sends the Binding Acknowledgement, it MUST set > > the status value to either 0 [Binding Update Accepted] or to [MCOA > > RETURNHOME WO/NDP (TBD)] in the BID mobility option depending on > > home > > agent configuration at the home link. The new values are: > > > > > > > > > > > > Wakikawa (Ed.), et al. Expires August 11, 2008 [Page > > 16] > > > > Internet-Draft MCoA February > > 2008 > > > > > > o Binding Update Accepted (0): NDP is permitted for the home > > address > > at the home link. This is regular returning home operation of > > [RFC-3775] > > > > o MCOA RETURNHOME WO/NDP (TBD): NDP is prohibited for the home > > address at the home link > > > > When the home agent is the only router at the home link, it can > > intercept all the packets by normal IP routing without using > > proxying > > for the home address. It stops proxy ND for the requested home > > address and responds with the [Binding Update Accepted] status value > > to the mobile node. The neighbor cache entry for the mobile node is > > created by the regular exchange of Neighbor Solicitation and > > Neighbor > > Advertisement. If the home agent is not the only router on the home > > link, it MUST continue defending the home address by proxy neighbor > > discovery in order to intercept the mobile node's traffic. The home > > agent, then, returns [MCOA RETURNHOME WO/NDP] value in the Status > > field of the BID mobility option. The home agent also learns the > > mobile node's layer-2 address (i.e., MAC address) during this > > binding > > de-registration. It stores the learnt layer-2 address in a neighbor > > cache entry for the mobile node so that it can construct the layer-2 > > header for the packets meant for the mobile node and forwards them > > directly to the mobile node's interface attached to the home link. > > > > According to [RFC-3775], the mobile node MUST NOT assign the home > > address to the interface attached to the home link and MUST NOT > > attempt NDP operations for the home address before the completion of > > binding de-registration. It MUST NOT send and reply to Neighbor > > Solicitation for the home address. The home address MUST be > > tentative address at this moment until it receives Binding > > Acknowledgement with success status value. > > > > When the mobile node receives the Binding Acknowledgement and BID > > mobility option, it assigns home address to the interface attached > > to > > the home link according to the status field of the BID. If the > > value > > is [Binding Update Accepted], the mobile node can start defending > > the > > home address using regular Neighbor Discovery. > > > > If the mobile node receives the [MCOA RETURNHOME WO/NDP], it MUST > > NOT > > defend its home address on the home link. When the mobile node > > sends > > packets from the interface attached to the home link, it MUST learn > > the layer 2 address (i.e., MAC address) of the next hop (i.e. > > default > > router, it can be home agent) during the binding de- registration > > and > > construct the packet including layer 2 header with the learnt > > layer-2 > > address of the default router or the home agent. > > > > > > > > GT> Something needs to be said about the lifetime of the BU with 'H' > > flag set. If the MN has to send a de-reg to the HA with Lifetime=3D0 and > > 'H' set, for how ling is this state valid? What happens to the > > lifetime of the other bindings?? > > > > > > Wakikawa (Ed.), et al. Expires August 11, 2008 [Page > > 17] > > > > Internet-Draft MCoA February > > 2008 > > > > > > 5.7. Receiving Binding Acknowledgement > > > > The verification of a Binding Acknowledgement is the same as Mobile > > IPv6 (section 11.7.3 of [RFC-3775]). The operation for sending a > > Binding Acknowledgement is described in Section 6.3. > > > > If a mobile node includes a Binding Identifier mobility option in a > > Binding Update with the 'A' flag set, a Binding Acknowledgement MUST > > carry a Binding Identifier mobility option. If no such mobility > > option is included in the Binding Acknowledgement in response to a > > Binding Update for multiple care-of address registration, this > > indicates that the originating node of the Binding Acknowledgement > > does not support processing the Binding Identifier mobility option. > > The mobile node MUST then stop multiple care-of address registration > > with that node. > > > > If a Binding Identifier mobility option is present in the received > > Binding Acknowledgement, the mobile node checks the status field in > > the option. If the status value in the Binding Identifier mobility > > option is zero, the mobile node uses the value in the Status field > > of > > the Binding Acknowledgement. Otherwise, it uses the value in the > > Status field of the Binding Identifier mobility option. > > > > If the status code is greater than or equal to 128, the mobile node > > starts relevant operations according to the error code. Otherwise, > > the mobile node assumes that the originator (home agent or > > correspondent node) successfully registered the binding information > > and BID for the mobile node. > > > > o If the Status value is [MCOA PROHIBITED], the mobile node MUST > > stop registering multiple bindings to the node that sent the > > Binding Acknowledgement. > > > > o If the Status value is [MCOA BULK REGISTRATION NOT SUPPORT], the > > mobile node SHOULD stop using bulk registrations with the node > > that sent the Binding Acknowledgement. > > > > o If [MCOA MALFORMED] is specified, it indicates that the binding > > identifier mobility option is formatted wrongly. For example, if > > the 'C' flag is set, all mobility options MUST have 'C' flag. It > > is same for 'O' flag. > > > > GT> What do you mean here with the 'C' and 'O' flags? It is not clear. > > Also it is not nice to find MUSTs with respect on how to use the flags > > when talking about the error codes. These MUSTs, if needed, should be > > moved elsewhere. > > > > > > o If [MCOA BID CONFLICT] is specified, the binding entry specified > > by the Binding Identifier mobility option is already registered > > as > > a regular binding. In such case, the mobile node SHOULD stop > > sending Binding Updates with BID, or SHOULD use the 'O' flag to > > reset all the registered bindings. > > > > > > > > > > Wakikawa (Ed.), et al. Expires August 11, 2008 [Page > > 18] > > > > Internet-Draft MCoA February > > 2008 > > > > > > 5.8. Receiving Binding Refresh Request > > > > The verification of a Binding Refresh Request is the same as in > > Mobile IPv6 (section 11.7.4 of [RFC-3775]). The operation of > > sending > > a Binding Refresh Request is described in section Section 6.4. > > > > If a mobile node receives a Binding Refresh Request with a Binding > > Identifier mobility option, it indicates that the node sending the > > Binding Refresh Request message is requesting the mobile node to > > send > > a new Binding Update for the BID. The mobile node SHOULD then > > send a > > Binding Update only for the respective binding. The mobile node > > MUST > > include a Binding Identifier mobility option in the Binding Update. > > > > If no Binding Identifier mobility option is present in a Binding > > Refresh Request, the mobile node sends a Binding Update according to > > its Binding Update List. On the other hand, if the mobile node does > > not have any Binding Update List entry for the requesting node, the > > mobile node needs to register either a single binding or multiple > > bindings depending on its binding management policy. > > > > 5.9. Sending Packets to Home Agent > > > > When a multihomed mobile node sends packets to its home agent, there > > are conceptually two ways to construct packets. > > > > 1. Using Home Address Option. (required additional 24 bytes) > > > > 2. Using IPv6-IPv6 tunnel. (required additional 40 bytes) > > > > GT> Remove the period or remove the ( ) and capitalize the R. > > > > Beside the difference in the size of packets, there is no difference > > between the two. The routing path does not get affected. With > > extensions specified in this document, the mobile node is capable of > > using multiple care-of addresses for outgoing packets. This is a > > problem on the home agent side because it must verify the Care-of > > address for all the packets received from the mobile node (i.e. > > ingress filtering). When the mobile node uses the Home Address > > option, the home agent MAY check the care-of address in the packet > > with the registered binding entries. This causes additional > > overhead > > to the home agent. Therefore, the mobile node SHOULD use the bi- > > directional tunnel even if it registers a binding(s) to the home > > agent. > > > > GT> This confuses me a bit. Is there anything different from RFC3775? > > Why is this section needed? > > > > > > 5.10. Bootstrapping > > > > When a mobile node bootstraps and registers multiple bindings for > > the > > first time, it SHOULD set the 'O' flag in the Binding Identifier > > mobility option. > > > > GT> Should this be a MUST? Otherwise what is the behavior of the HA? > > > > If old bindings still exists at the home agent, the > > mobile node has no knowledge of which bindings still exist at the > > > > > > > > Wakikawa (Ed.), et al. Expires August 11, 2008 [Page > > 19] > > > > Internet-Draft MCoA February > > 2008 > > > > > > home agent. This scenario happens when a mobile node reboots and > > looses state regarding the registrations. If the 'O' flag is set, > > all the bindings are replaced by the new binding(s). If the mobile > > node receives the Binding Acknowledgement with the status code set > > to > > 135 [Sequence number out of window], it MUST retry sending a Binding > > Update with the last accepted sequence number indicated in the > > Binding Acknowledgement. > > > > The 'O' flag can also be used in individual Binding Updates sent to > > the correspondent nodes to override any existing binding cache > > entries at the correspondent node. > > > > > > GT> Again the 'O' flag MUST be set the first time MCoA is used with a > > CN I think. > > > > > > > > > > > > > > > > > > Wakikawa (Ed.), et al. Expires August 11, 2008 [Page > > 20] > > > > Internet-Draft MCoA February > > 2008 > > > > > > 6. Home Agent and Correspondent Node Operation > > > > 6.1. Searching Binding Cache with Binding Identifier > > > > If either a correspondent node or a home agent has multiple bindings > > for a mobile node in their binding cache database, it can use any of > > the bindings to communicate with the mobile node. How to select the > > most suitable binding from the binding cache database is out of > > scope > > in this document. > > > > Whenever a correspondent node searches a binding cache for a home > > address, it SHOULD uses both the home address and the BID as the > > search key if it knows the corresponding BID. > > > > GT> This is a bid strange. Why would the HA or CN use a BID as a key? > > The HoA is used as a key because the HA/CN want to send a packet with > > the HoA as destination address, which causes Mobile IP to use the HoA > > as a key to find an appropriate CoA. I do not think that the BIDs are > > needed for this. With MCoA, the only difference is that a lookup of > > the HoA will return multiple CoAs; and which one is used is out of > > scope for this document. > > > > GT> So, the BIDs are only used as key when the receiver processes a BU > > message including a BID Mobility option. Is this what this is about? > > > > In the example below, > > if a correspondent node searches the binding with the home address > > and BID2, it gets binding2 for this mobile node. > > > > binding1 [a:b:c:d::EUI, care-of address1, BID1] > > binding2 [a:b:c:d::EUI, care-of address2, BID2] > > binding3 [a:b:c:d::EUI, care-of address3, BID3] > > > > Figure 4: Searching the Binding Cache > > > > A correspondent node earns the BID when it receives a Binding > > > > GT> //earns/learns > > > > Identifier mobility option. At the time, the correspondent node > > MUST > > > > GT>//At the time/At that time > > > > look up its binding cache database with the home address and the BID > > retrieved from the Binding Update. If the correspondent node does > > not know the BID, it searches for a binding with only the home > > address. In such a case, the first matched binding is found. If > > the > > correspondent node does not desire to use multiple bindings for a > > mobile node, it can simply ignore the BID. > > > > GT> This whole section needs to be cleaned based on the comment above. > > > > > > 6.2. Receiving CoTI and Sending CoT > > > > When a correspondent node receives a CoTI message which contains a > > Binding Identifier mobility option, it processes it as follows. > > > > First, the CoTI message is verified as specified in [RFC-3775]. The > > Binding Identifier mobility option is processed as follows: > > > > o If a correspondent node does not understand a Binding Identifier > > mobility option, it just ignores and skips processing the option. > > The calculation of a care-of Keygen token will thus be done > > without a BID value. The correspondent node returns a CoT > > message > > without a Binding Identifier mobility option. The mobile node > > knows whether the correspondent supports processing the Binding > > Identifier mobility option, by checking if the option is present > > in the CoT message. > > > > > > > > > > Wakikawa (Ed.), et al. Expires August 11, 2008 [Page > > 21] > > > > Internet-Draft MCoA February > > 2008 > > > > > > o If either the 'C' or the 'O' flag is set in the Binding > > Identifier > > mobility option, the correspondent Node SHOULD NOT calculate a > > care-of Keygen token, but MUST include a Binding Identifier > > mobility option with status value set to [MCOA MALFORMED] in the > > Care-of Test message. > > > > o Otherwise, the correspondent node MUST include a Binding > > Identifier mobility option with status value set to zero > > (success) > > in the Care-of Test message. > > > > o The Care-of address field of each Binding Identifier mobility > > option, can be omitted, because the mobile node can identify the > > corresponding Binding Update list entry using the BID. > > > > 6.3. Processing Binding Update > > > > If a Binding Update does not contain a Binding Identifier mobility > > option, its processing is same as in [RFC-3775]. If the receiver > > already has multiple bindings for the home address, it MUST replace > > all the existing bindings by the received binding. As a result, the > > receiver node MUST have only one binding cache entry for the mobile > > node. If the Binding Update is for de-registration, the receiver > > MUST delete all existing bindings from its Binding Cache. > > > > If the Binding Update contains a Binding Identifier mobility > > option(s), it is validated according to section 9.5.1 of [RFC-3775] > > and the following steps. > > > > o If the home registration flag is set in the Binding Update, the > > home agent MUST carefully operate Duplicate Address Detection > > (DAD) for the received home address. If the home agent has > > already had a binding(s) for the mobile node, it MUST avoid > > running DAD for the home address on the home link when it > > receives > > the Binding Update. > > > > > > GT> Why is this here? This is normal RFC3775 operation and should not > > be affected by MCoA, no? > > > > The receiver MUST process the Binding Identifier mobility option(s) > > in the following steps. When a correspondent node sends a Binding > > Acknowledgement, the status value MUST be always stored in the > > Status > > field of the Binding Acknowledgement and the Status field of Binding > > Identifier mobility option set to zero. > > > > GT> The last sentence does not make sense. Please rephrase. > > > > For the home agent, the status value can be stored in the Status > > field of either a Binding Acknowledgement or a Binding Identifier > > mobility option. If the status value is specific to one of bindings > > in the bulk registration, the status value MUST be stored in the > > Status field in the corresponding Binding Identifier mobility > > option. > > In this case, [MCOA NOTCOMPLETE] MUST be set to the Status field of > > the Binding Acknowledgement so that the receiver can examine the > > > > > > > > Wakikawa (Ed.), et al. Expires August 11, 2008 [Page > > 22] > > > > Internet-Draft MCoA February > > 2008 > > > > > > Status field of each Binding Identifier mobility option for further > > operations. > > > > o The length value is examined. The length value MUST be either 4, > > 8, or 20 depending on the 'C' and 'D' flags. If the length is > > incorrect, the receiver MUST reject the Binding Update and > > returns > > the status value set to [MCOA MALFORMED]. > > > > o When the 'C' flag is set, the care-of address MUST be present in > > the Binding Identifier mobility option. Otherwise, the receiver > > > > GT> It is not clear what "Otherwise" refers to. Replace with: "If the > > care-of address is not present..." > > > > MUST reject the Binding Identifier mobility option and returns > > the > > status value set to [MCOA MALFORMED]. The operation of 'D' flag > > is described in Section 8 > > > > o When multiple Binding Identifier mobility options are present in > > the Binding Update, it is treated as bulk registration. If the > > receiving node is a correspondent node, it MUST reject the > > Binding > > Update and returns the status value in the binding > > acknowledgement > > set to [MCOA BULK REGISTRATION NOT SUPPORT] > > > > o If the Lifetime field in the Binding Update is set to zero, the > > receiving node deletes the binding entry that corresponds to the > > BID in the Binding Identifier mobility option. If the receiving > > node does not have an appropriate binding for the BID, it MUST > > reject the Binding Update and send a Binding Acknowledgement with > > status set to 133 [not home agent for this mobile node]. > > > > GT>This does not make sense. If the BID does not exist then the > > binding never existed or has already been deleted so I would send a BA > > and BID Mobility option with status 0. Status 133 means that the HoA > > is not valid...which is a different issue already covered in RFC3775. > > Also please move this bullet one place down to be next to Lifetime !=3D > > zero case. > > > > > > o If the 'O' flag is set in the de-registering Binding Update, the > > receiver can ignore this flag for de-registration. > > > > GT> This sentence is strange please rephrase. > > > > If the 'H' > > flag is set, the home agent stores a home address in the Care-of > > Address field of the binding cache entry. The home agent also > > stops performing proxy ND for the mobile node's home address. > > > > o If the Lifetime field is not set to zero, the receiving node > > registers a binding with the specified BID as a mobile node's > > binding. The Care-of address is obtained from the Binding Update > > packet as follows: > > > > * If the 'C' flag is set in the Binding Identifier mobility > > option, the care-of address is copied from the care-of address > > field in the Binding Identifier mobility option. > > > > * If the 'C' flag is not set in the Binding Identifier mobility > > option, the care-of address is copied from the source address > > field of the IPv6 header. > > > > * If the 'C' flag is not set and an alternate care-of address is > > present, the care-of address is copied from the Alternate > > > > > > > > Wakikawa (Ed.), et al. Expires August 11, 2008 [Page > > 23] > > > > Internet-Draft MCoA February > > 2008 > > > > > > Care-of address mobility option. > > > > o Once the care-of address(es) has been retrieved from the Binding > > > > GT>//has/have > > > > Update, the receiving nodes creates new binding(s). > > > > * If only the 'O' flag is set in the Binding Identifier mobility > > option, the home agent removes all the existing bindings and > > registers the received bindings. > > > > * If the receiver has a regular binding which does not have BID > > for the mobile node, it must not process the binding update. > > The receiver should sent a binding acknowledgement with status > > set to [MCOA BID CONFLICT]. > > > > GT> This makes no sense. What do you mean? > > > > > > * If the receiver already has a binding with the same BID, it > > > > GT>// same BID, it/ same BID and different care-of address, it > > > > MUST update the binding and responds with a Binding > > > > GT>//responds/respond > > > > Acknowledgement with status set to 0 [Binding Update > > accepted]. > > > > * If the receiver does not have a binding entry for the BID, it > > registers a new binding for the BID and responds with a > > Binding > > Acknowledgement with status set to 0 [Binding Update > > accepted]. > > > > GT> What happens if one receives a new BID mapped to a CoA already in > > the binding cache (but mapped to different BID?) Is this allowed? Is > > this how one can change the BIDs it is using? > > > > > > If all the above operations are successfully completed, a Binding > > Acknowledgement containing the Binding Identifier mobility options > > MUST be sent to the mobile node. Whenever a Binding Acknowledgement > > is sent, all the Binding Identifier mobility options stored in the > > Binding Update MUST be copied to the Binding Acknowledgement except > > the status field. The Care-of address field in each Binding > > Identifier mobility option, however, can be omitted, because the > > mobile node can match a corresponding binding update list entry > > using > > the BID. > > > > GT> Something needs to be said about the lifetime of the bindings. I > > assume that the Lifetime field of the BU updates the lifetime of all > > the bindings, whether a regular or bulk MCoA registration is > > performed. > > > > > > 6.4. Sending Binding Refresh Request > > > > When a node (home agent or correspondent node) sends a Binding > > Refresh Request for a particular binding created with the BID, the > > node SHOULD include the Binding Identifier mobility option in the > > Binding Refresh Request. > > > > GT> This needs a bit more...which BID mobility option is included? > > Just one? All of them? Again we need to be clear what the lifetime > > does and how it relates to each of the CoAs. > > > > 6.5. Receiving Packets from Mobile Node > > > > When a node receives packets with a Home Address destination option > > from a mobile node, it MUST check that the care-of address that > > appears in the source address field of the IPv6 header MUST be equal > > to one of the care-of addresses in the binding cache entry. If no > > binding is found, the packets MUST be silently discarded. > > > > GT> Why don't we just point to RFC3775 and say that the exact same > > processing is used here? > > > > The node > > MUST also send a Binding Error message as specified in [RFC-3775]. > > This verification MUST NOT be done for a Binding Update. > > > > > > > > Wakikawa (Ed.), et al. Expires August 11, 2008 [Page > > 24] > > > > Internet-Draft MCoA February > > 2008 > > > > > > 7. Network Mobility Applicability > > > > The binding management mechanisms are the same for a mobile host > > that > > uses Mobile IPv6 and for a mobile router that is using the NEMO > > Basic > > Support protocol [RFC-3963]. Therefore the extensions described in > > this document can also be used to support a mobile router with > > multiple care-of addresses. Figure 5 shows an example format of a > > Binding Update sent by a mobile router. > > > > IPv6 header (src=3DCoA, dst=3DHA) > > IPv6 Home Address Option > > ESP Header > > Mobility header > > -BU > > Mobility Options > > - Binding Identifier > > - Mobile Network Prefix > > > > Figure 5: NEMO Binding Update > > > > > > > > > > > > GT> Why is this example here? I would remove it together with the > > last sentence. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Wakikawa (Ed.), et al. Expires August 11, 2008 [Page > > 25] > > > > Internet-Draft MCoA February > > 2008 > > > > > > 8. DSMIPv6 Applicability > > > > Dual Stack Mobile IPv6 (DSMIPv6) [ID-DSMIPv6] extends Mobile IPv6 to > > register an IPv4 care-of address instead of the IPv6 care-of address > > when the mobile node is attached to an IPv4-only access network. It > > also allows the mobile node to acquire an IPv4 home address in > > addition to an IPv6 home address for use with IPv4-only > > correspondent > > nodes. This section describes how multiple care-of address > > registration works with IPv4 care-of and home addresses. > > > > 8.1. IPv4 Care-of Address Registration > > > > The mobile node can use the extensions described in the document to > > register multiple care-of addresses, even if some of the care-of > > addresses are IPv4 address. > > > > Bulk registration MUST NOT be used for the initial binding from an > > IPv4 care-of address. This is because, the Binding Update and > > binding acknowledgement exchange is used to detect NAT on the path > > between the mobile node and the home agent. So the mobile node > > needs > > to check for a NAT between each IPv4 care-of address and the home > > agent. > > > > The Binding Update MUST be sent to the IPv4 home agent address by > > using UDP and IPv4 headers as shown in Figure 6. It is similar to > > [ID-DSMIPv6] except that the IPv4 care-of address option MUST NOT be > > used when the BID mobility option is used. > > > > IPv4 header (src=3DV4ADDR, dst=3DHA_V4ADDR) > > UDP Header > > IPv6 header (src=3DV6HoA, dst=3DHAADDR) > > ESP Header > > Mobility header > > -BU > > Mobility Options > > - Binding Identifier (IPv4 CoA) > > > > Figure 6: Initial Binding Update for IPv4 Care-of Address > > > > Whenever a NAT is detected, mobile node MUST NOT use bulk > > registration for the IPv4 care-of address. > > > > GT> This was repeated above. Delete. > > > > If a NAT is not detected, > > the mobile node can update the IPv4 care-of address by using BULK > > > > GT>//BULK/bulk > > > > registration. The mobile node can register the IPv4 care-of address > > along with other care-of addresses. Figure 7 shows the Binding > > > > GT>// other care-of addresses/ other IPv4 and IPv6 care-of addresses > > > > Update format when the mobile node sends a Binding Update from one > > of > > its IPv6 care-of addresses. If the mobile node sends a BU from IPv4 > > care-of address, it MUST follow the format described in Figure 6. > > Note that the IPv4 Care-of Address must be registered by non bulk > > > > > > > > Wakikawa (Ed.), et al. Expires August 11, 2008 [Page > > 26] > > > > Internet-Draft MCoA February > > 2008 > > > > > > Binding registration, whenever it is changed. > > > > > > NAT detection MUST be > > carried out for every new IPv4 addresses. > > > > GT> Again, this was repeated above. Delete. > > > > IPv6 header (src=3DV6CoA, dst=3DHAADDR) > > IPv6 Home Address Option > > ESP Header > > Mobility header > > -BU > > Mobility Options > > - Binding Identifier (IPv6/v4 CoA) > > - Binding Identifier (IPv6/v4 CoA) > > - ... > > > > Figure 7: Binding Bulk Registration for IPv4 care-of address > > > > If the home agent rejects the IPv4 care-of address, it MUST store > > the > > error code value in the Status field of the BID mobility option. > > The > > home agent MUST send the Binding Acknowledgement and all the > > received > > BID mobility options to the mobile node. > > > > GT> This has already been explained in other sections. It is not good > > to repeat MUST statements about the same thing. Delete the whole > > paragraph=85.or just point to HA processing section. > > > > > > > > 8.2. IPv4 HoA Management > > > > When the mobile node wants to configure an IPv4 home address in > > addition to the IPv6 home address, it can request for one using the > > IPv4 Home Address option in the Binding Update. If the home agent > > accepts the Binding Update, the mobile node can now register > > multiple > > care-of addresses for the IPv4 home address in addition to the IPv6 > > home address. The same set of care-of addresses will be registered > > for both IPv6 and IPv4 home addresses. The mobile node cannot bind > > different set of care-of addresses to each home address. > > > > The home agent includes the IPv4 address acknowledgement option in > > the Binding Acknowledgement only if the mobile node had requested > > for > > the IPv4 home address. > > > > GT> Rephrase: "According to [DSMIPv6], the home agent includes the > > IPv4 address acknowledgement option in the Binding Acknowledgement > > only if the mobile node requests an IPv4 home address in the > > corresponding Binding Update. " > > > > > > The IPv4 address acknowledgement option MUST > > be present before any BID option. The status field of the IPv4 > > address acknowledgement option contains only the error code > > regarding > > IPv4 home address management. > > > > GT>// the error code regarding IPv4 home address management/ the error > > code corresponding to the IPv4 home address. > > > > The error values related to the IPv4 > > care-of address registration MUST be stored in the BID mobility > > option. > > > > > > > > > > > > > > > > > > > > > > > > > > Wakikawa (Ed.), et al. Expires August 11, 2008 [Page > > 27] > > > > Internet-Draft MCoA February > > 2008 > > > > > > 9. IPsec and IKEv2 interaction > > > > Mobile IPv6 [RFC-3775] and the NEMO protocol [RFC-3963] require the > > use of IPsec to protect signaling messages like Binding Updates, > > Binding Acknowledgements and return routability messages. IPsec may > > also be used protect all reverse tunneled data traffic. The Mobile > > > > GT> //used protect all reverse tunneled data / used to protect all > > tunneled data/ > > > > IPv6-IKEv2 specification [RFC-4877] specifies how IKEv2 can be used > > to setup the required IPsec security associations. The following > > assumptions were made in [RFC-3775], [RFC-3963] and the MIP6-IKEv2 > > specification with respect to the use of IKEv2 and IPsec. > > > > GT> Why is MIP6-IKEv2 not properly referenced? > > > > o There is only one primary care-of address per mobile node. > > > > o The primary care-of address is stored in the IPsec database for > > tunnel encapsulation and decapsulation. > > > > o When the home agent receives a packet from the mobile node, the > > source address is verified against the care-of address in the > > corresponding binding cache entry. If the packet is a reverse > > tunneled packet from the mobile node, the care-of address check > > is > > done against the source address on the outer IPv6 header. The > > reverse tunnel packet could either be a tunneled HoTi message or > > tunneled data traffic to the correspondent node. > > > > o The mobile node runs IKEv2 (or IKEv1) with the home agent using > > the care-of address. The IKE SA is based on the care-of address > > of the mobile node. > > > > The above assumptions may not be valid when multiple care-of > > addresses are used by the mobile node. In the following sections, > > the main issues with the use of multiple care-of address with IPsec > > are addressed. > > > > 9.1. Use of Care-of Address in the IKEv2 exchange > > > > For each home address the mobile node sets up security associations > > with the home agent, the mobile node must pick one care-of address > > and use that as the source address for all IKEv2 messages exchanged > > to create and maintain the IPsec security associations associated > > with the home address. The resultant IKEv2 security association is > > created based on this care-of address. > > > > GT> Add "according to MIP6-IKEv2 ..." until you have something new. > > > > If the mobile node needs to change the care-of address, it just > > sends > > a Binding Update with the care-of address it wants to use, with the > > corresponding Binding Identifier mobility option, and with the 'K' > > bit set. This will force the home agent to update the IKEv2 > > security > > association to use the new care-of address. If the 'K' bit is not > > supported on the mobile node or the home agent, the mobile node MUST > > > > > > > > Wakikawa (Ed.), et al. Expires August 11, 2008 [Page > > 28] > > > > Internet-Draft MCoA February > > 2008 > > > > > > re-establish the IKEv2 security association with the new care-of > > address. This will also result in new IPsec security associations > > being setup for the home address. > > > > > > > > On Feb 8, 2008 4:35 PM, Vijay Devarapalli > > wrote: > >> Hello, > >> > >> There is a pre-06 version of this draft available at > >> http://dvijay.com/ietf/internet-drafts/mext/mcoa.txt > >> > >> The draft has been cleaned up a bit. In case, you haven't reviewed > >> the document yet, please review the pre-06 version. In case you > >> have already reviewed version 05, please send your comments based > >> on version 05. > >> > >> The diff between 05 and pre-06 can be found at > >> http://dvijay.com/ietf/internet-drafts/mext/diff-05-06.html > >> > >> Vijay > >> > >> > >> marcelo bagnulo braun wrote: > >>> Hi, > >>> > >>> With this email we issue the WGLC for draft-ietf-monami6- > >>> multiplecoa-05.txt > >>> The WGLC will be open till the 11 of february. > >>> We kindly ask the WG to review the document and provide comments. > >>> > >>> Please note that a valid comment at this stage is positive feedback > >>> about the document being ready to be shipped. > >>> So, please if you think the doc is ready, do express this to the ml > >>> (or to the chairs) > >>> > >>> For you convenience, additional information about the document: > >>> > >>> Title : Multiple Care-of Addresses Registration > >>> Author(s) : R. Wakikawa, et al. > >>> Filename : draft-ietf-monami6-multiplecoa-05.txt > >>> Pages : 44 > >>> Date : 2008-01-27 > >>> > >>> http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-05= .txt > >>> > >>> Thanks, Julien and marcelo > >>> _______________________________________________ > >>> MEXT mailing list > >>> MEXT@ietf.org > >>> http://www.ietf.org/mailman/listinfo/mext > >> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> http://www.ietf.org/mailman/listinfo/mext > >> > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Feb 12 07:06:26 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E797928CC6C; Tue, 12 Feb 2008 07:06:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.545 X-Spam-Level: X-Spam-Status: No, score=-0.545 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhQJXkf1orYT; Tue, 12 Feb 2008 07:06:22 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC47C28CD94; Tue, 12 Feb 2008 07:03:20 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E82328CC3F for ; Tue, 12 Feb 2008 07:03:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t01k9Mq+ajNB for ; Tue, 12 Feb 2008 07:03:18 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 5BB7328C31F for ; Tue, 12 Feb 2008 07:02:11 -0800 (PST) Received: from IBM52A5038A94F (dsl88-233-53469.ttnet.net.tr [88.233.208.221]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1JOwfN3hew-0002YC; Tue, 12 Feb 2008 10:03:31 -0500 From: "Alper Yegin" To: "'George Tsirtsis'" , "'marcelo bagnulo braun'" Date: Tue, 12 Feb 2008 17:03:19 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchibyRN/OZ9m6L1RjSYJnbUIdho7gLGMcaw Message-Id: <0MKpCa-1JOwfN3hew-0002YC@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX188PVh99lRFbZ7Ga+Cm0PCmdlacNDUv9fhd0/Q OxfcrBW/OtywGBzErMlWT9S5KLbedZHVjw+BYXl9BK6P6q3Wbr UJKrb9LAAb/KDQXftJ2jg== Cc: mext@ietf.org Subject: Re: [MEXT] [Recharter] Mobile IPv6 Bootstrapping for theAuthentication Option Protocol X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org George, > I am repeating myself but given the fact that, as far as the IETF is > concerned, IPSEC should be used for securing MIPv6 and not RFC4285 > (see IESG Note inside it), " The IESG recommends against the usage of this specification outside of environments that meet the conditions of that applicability statement." is what the IESG note says. Your message above is much stronger than the IESG note and I think that's not accurate. I just wanted to note that, although this may not change your position or the faith of this work item. Alper > I think the WG should not spend any time on > this. > > If documenting this is needed by an external entity then it could be > handled as a personal contribution. > > This is going straight to the bottom of my ordered list (to be provided > soon). > > Regards > George > > On Jan 21, 2008 6:14 PM, marcelo bagnulo braun wrote: > > Existing bootstrapping mechanisms for Mobile IPv6 only address the use > > of IKEv2/IPsec for protecting Mobile IPv6 signaling messages. > > Bootstrapping a home address and security associationswhen RFC 4285 is > > used are not addressed. This draft describes bootstrapping mechanisms > > for using RFC 4285 with Mobile IPv6. > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Feb 12 07:25:59 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1740728C32C; Tue, 12 Feb 2008 07:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.408 X-Spam-Level: X-Spam-Status: No, score=-0.408 tagged_above=-999 required=5 tests=[AWL=-0.593, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcDZtMkYfvhd; Tue, 12 Feb 2008 07:25:58 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06A3B3A69DC; Tue, 12 Feb 2008 07:25:58 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1EED3A69DC for ; Tue, 12 Feb 2008 07:25:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0ZtC164K+lP for ; Tue, 12 Feb 2008 07:25:54 -0800 (PST) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.191]) by core3.amsl.com (Postfix) with ESMTP id A920E3A698D for ; Tue, 12 Feb 2008 07:25:54 -0800 (PST) Received: by rn-out-0910.google.com with SMTP id a46so2185534rne.10 for ; Tue, 12 Feb 2008 07:27:18 -0800 (PST) Received: by 10.142.188.4 with SMTP id l4mr1116708wff.92.1202830038006; Tue, 12 Feb 2008 07:27:18 -0800 (PST) Received: by 10.142.11.11 with HTTP; Tue, 12 Feb 2008 07:27:17 -0800 (PST) Message-ID: Date: Tue, 12 Feb 2008 15:27:17 +0000 From: "George Tsirtsis" To: "Alper Yegin" In-Reply-To: <0MKpCa-1JOwfN3hew-0002YC@mrelay.perfora.net> MIME-Version: 1.0 Content-Disposition: inline References: <0MKpCa-1JOwfN3hew-0002YC@mrelay.perfora.net> Cc: mext@ietf.org Subject: Re: [MEXT] [Recharter] Mobile IPv6 Bootstrapping for theAuthentication Option Protocol X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Clarification accepted....but as you predicted opinion not changed :-) Regards George On Feb 12, 2008 3:03 PM, Alper Yegin wrote: > George, > > > > I am repeating myself but given the fact that, as far as the IETF is > > concerned, IPSEC should be used for securing MIPv6 and not RFC4285 > > (see IESG Note inside it), > > " The IESG recommends against the usage of this specification outside of > environments that meet the conditions of that applicability statement." is > what the IESG note says. Your message above is much stronger than the IESG > note and I think that's not accurate. > > I just wanted to note that, although this may not change your position or > the faith of this work item. > > Alper > > > > > > > I think the WG should not spend any time on > > this. > > > > If documenting this is needed by an external entity then it could be > > handled as a personal contribution. > > > > This is going straight to the bottom of my ordered list (to be provided > > soon). > > > > Regards > > George > > > > On Jan 21, 2008 6:14 PM, marcelo bagnulo braun wrote: > > > Existing bootstrapping mechanisms for Mobile IPv6 only address the use > > > of IKEv2/IPsec for protecting Mobile IPv6 signaling messages. > > > Bootstrapping a home address and security associationswhen RFC 4285 is > > > used are not addressed. This draft describes bootstrapping mechanisms > > > for using RFC 4285 with Mobile IPv6. > > > > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mext > > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Feb 12 07:30:17 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A291F28CC4C; Tue, 12 Feb 2008 07:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.768 X-Spam-Level: X-Spam-Status: No, score=-2.768 tagged_above=-999 required=5 tests=[AWL=-0.331, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6Zv93oNJK0l; Tue, 12 Feb 2008 07:30:17 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8A5328CC56; Tue, 12 Feb 2008 07:30:14 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5E0528CC4B for ; Tue, 12 Feb 2008 07:30:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wb2jnHlp5FNG for ; Tue, 12 Feb 2008 07:30:12 -0800 (PST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by core3.amsl.com (Postfix) with ESMTP id 022B028CC56 for ; Tue, 12 Feb 2008 07:30:11 -0800 (PST) Received: by ug-out-1314.google.com with SMTP id u2so1434823uge.46 for ; Tue, 12 Feb 2008 07:31:35 -0800 (PST) Received: by 10.67.19.13 with SMTP id w13mr696631ugi.19.1202830295212; Tue, 12 Feb 2008 07:31:35 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id b35sm10209021ugd.33.2008.02.12.07.31.33 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Feb 2008 07:31:34 -0800 (PST) From: Julien Laganier To: mext@ietf.org User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200802111135.44252.julien.IETF@laposte.net> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Date: Tue, 12 Feb 2008 16:31:35 +0100 Message-Id: <200802121631.35572.julien.IETF@laposte.net> Subject: [MEXT] [Recharter.2] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Folks, This is the next step in the recharter process. We'd like to get input from WG participants on what should be the items included in rechartering, what are their priorities, and who is willing to sustain the effort. When that step is completed we will take the WG input and discuss with our AD to move forward with deciding what to include or not in the charter. Your input should be sent to the list during the following two weeks, by 2008-02-26. Please pick from the list of items below the items you think the WG should work on, and order them in decreasing priority (just to make sure, first priority items goes first in the list you're making :). List of items: Binding Revocation for IP Mobility MIPv6 home link operation in various SDOs IP Tunneling Optimization in a Mobile Environment Generic Notification Message for Mobile IPv6 GRE requirements for IPv6 mobility 4283bis to extend MN identifier to other identifiers Mobile IPv6 Bootstrapping for the Authentication Option Protocol Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions Virtual Home Link configuration for Mobile IPv6 Extend DSMIPv6 Home Network Support Also, please prefix each of the items in your list with the letters E, C and/or R if you're willing to: - [E]dit: Are you willing to edit the draft corresponding to the item. - [C]ontribute: Are you willing to propose text for the draft. - [R]eview: Are you willing to review new revisions of the draft when being asked by the chairs. As an example, that could be one input list: E MIPv6 home link operation in various SDOs CR Binding Revocation for IP Mobility R IP Tunneling Optimization in a Mobile Environment meaning that the MIPv6 home link is first priority and you volunteer to edit, Binding revocation is second priority and you're willing to contribute and review, while IP tunneling optimization is third priority and you're willing to review. Hope this is understandable :) Thanks. -- julien and marcello, MEXT chairs _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Feb 12 07:46:02 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6865C28C37B; Tue, 12 Feb 2008 07:46:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.342 X-Spam-Level: X-Spam-Status: No, score=-4.342 tagged_above=-999 required=5 tests=[AWL=-1.905, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiHsyqKfGlFh; Tue, 12 Feb 2008 07:46:01 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DE9D28C2D6; Tue, 12 Feb 2008 07:46:01 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B7B528C1E6 for ; Tue, 12 Feb 2008 07:46:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Glfv09eUvqg for ; Tue, 12 Feb 2008 07:45:59 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id CCAA83A69DC for ; Tue, 12 Feb 2008 07:45:58 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m1CFhGC27768; Tue, 12 Feb 2008 15:43:16 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 12 Feb 2008 09:47:08 -0600 Message-ID: In-Reply-To: <200802121631.35572.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [Recharter.2] Thread-Index: AchtjRgfOFJgN7wGRBGc/v3WRauLUwAAHvXA References: <200802111135.44252.julien.IETF@laposte.net> <200802121631.35572.julien.IETF@laposte.net> From: "Ahmad Muhanna" To: "Julien Laganier" , Subject: Re: [MEXT] [Recharter.2] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien/All, [E] Binding Revocation for IPv6 Mobility [CR] Generic Notification Message [R] MIPv6 home link operation in various SDOs && [CR] IP Tunneling Optimization in a Mobile Environment [CR] Extend DSMIPv6 Home Network Support I would give MIPv6 home link operation and IP Tunneling Optimization in Mobile Environment the same priority. Regards, Ahmad > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Julien Laganier > Sent: Tuesday, February 12, 2008 9:32 AM > To: mext@ietf.org > Subject: [MEXT] [Recharter.2] > > Folks, > > This is the next step in the recharter process. We'd like to > get input from WG participants on what should be the items > included in rechartering, what are their priorities, and who > is willing to sustain the effort. When that step is completed > we will take the WG input and discuss with our AD to move > forward with deciding what to include or not in the charter. > Your input should be sent to the list during the following > two weeks, by 2008-02-26. > > Please pick from the list of items below the items you think > the WG should work on, and order them in decreasing priority > (just to make sure, first priority items goes first in the > list you're making :). > > List of items: > > Binding Revocation for IP Mobility > MIPv6 home link operation in various SDOs IP Tunneling > Optimization in a Mobile Environment Generic Notification > Message for Mobile IPv6 GRE requirements for IPv6 mobility > 4283bis to extend MN identifier to other identifiers Mobile > IPv6 Bootstrapping for the Authentication Option Protocol > Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY > extensions Virtual Home Link configuration for Mobile IPv6 > Extend DSMIPv6 Home Network Support > > Also, please prefix each of the items in your list with the > letters E, C and/or R if you're willing to: > > - [E]dit: Are you willing to edit the draft corresponding to the > item. > > - [C]ontribute: Are you willing to propose text for the draft. > > - [R]eview: Are you willing to review new revisions of the draft when > being asked by the chairs. > > As an example, that could be one input list: > > E MIPv6 home link operation in various SDOs CR Binding > Revocation for IP Mobility R IP Tunneling Optimization in a > Mobile Environment > > meaning that the MIPv6 home link is first priority and you > volunteer to edit, Binding revocation is second priority and > you're willing to contribute and review, while IP tunneling > optimization is third priority and you're willing to review. > > Hope this is understandable :) > > Thanks. > > -- julien and marcello, MEXT chairs > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Feb 12 07:56:10 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7D0C28C37B; Tue, 12 Feb 2008 07:56:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74oXH+FfyTZF; Tue, 12 Feb 2008 07:56:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A608828C263; Tue, 12 Feb 2008 07:56:09 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A649428C310 for ; Tue, 12 Feb 2008 07:56:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmbqM4YnNcqF for ; Tue, 12 Feb 2008 07:56:07 -0800 (PST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by core3.amsl.com (Postfix) with ESMTP id C040928C1F4 for ; Tue, 12 Feb 2008 07:56:06 -0800 (PST) Received: by ug-out-1314.google.com with SMTP id u2so1465019uge.46 for ; Tue, 12 Feb 2008 07:57:30 -0800 (PST) Received: by 10.142.113.17 with SMTP id l17mr1128625wfc.188.1202831848877; Tue, 12 Feb 2008 07:57:28 -0800 (PST) Received: by 10.142.11.11 with HTTP; Tue, 12 Feb 2008 07:57:28 -0800 (PST) Message-ID: Date: Tue, 12 Feb 2008 15:57:28 +0000 From: "George Tsirtsis" To: "Julien Laganier" In-Reply-To: <200802121631.35572.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Disposition: inline References: <200802111135.44252.julien.IETF@laposte.net> <200802121631.35572.julien.IETF@laposte.net> Cc: mext@ietf.org Subject: Re: [MEXT] [Recharter.2] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien et.,al., My ordered list of new WG items is provided below together with some justification. Note that I include 5 items rather than the 4 requested by the chairs since item (3) in my list I think requires very few resources: 1) [R] Binding Revocation I think there is wide support for this work item both for MIPv6 and PMIPv6. Personally I would prefer the PMIPv6 specifics to be handled in NETLMM WG, while for the solution we should examine both draft-muhanna and reuse of RFC5142 Generic Notification Message for Mobile IPv6 and use of RFC5142 2) [CR] Virtual Home Link configuration for Mobile IPv6 This would be very useful as MIPv6 is getting deployed in various scenarios. I would be willing to spend some time to help Sri and others document this. 3) [R] 4283bis This is straightforward and should require minimal effort from the WG. 4) [R] MIPv6 Firewall As with (2) above, this is also useful work providing guidelines to corporate and other firewalled deployments of MIPv6. 5) [R] IP Tunneling Optimization in a Mobile Environment In some cases (e.g., low bandwidth wireless links) reducing the tunnel overhead would remove a barrier to MIPv6 adoption. Link specific mechanisms such as ROHC can have the same effect but a MIP layer solution would remove the dependency on such mechanisms (a good thing). This is worth pursuing. On Feb 12, 2008 3:31 PM, Julien Laganier wrote: > Folks, > > This is the next step in the recharter process. We'd like to get input > from WG participants on what should be the items included in > rechartering, what are their priorities, and who is willing to > sustain the effort. When that step is completed we will take the WG > input and discuss with our AD to move forward with deciding what to > include or not in the charter. Your input should be sent to the list > during the following two weeks, by 2008-02-26. > > Please pick from the list of items below the items you think the WG > should work on, and order them in decreasing priority (just to make > sure, first priority items goes first in the list you're making :). > > List of items: > > Binding Revocation for IP Mobility > MIPv6 home link operation in various SDOs > IP Tunneling Optimization in a Mobile Environment > Generic Notification Message for Mobile IPv6 > GRE requirements for IPv6 mobility > 4283bis to extend MN identifier to other identifiers > Mobile IPv6 Bootstrapping for the Authentication Option Protocol > Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions > Virtual Home Link configuration for Mobile IPv6 > Extend DSMIPv6 Home Network Support > > Also, please prefix each of the items in your list with the letters E, C > and/or R if you're willing to: > > - [E]dit: Are you willing to edit the draft corresponding to the > item. > > - [C]ontribute: Are you willing to propose text for the draft. > > - [R]eview: Are you willing to review new revisions of the draft when > being asked by the chairs. > > As an example, that could be one input list: > > E MIPv6 home link operation in various SDOs > CR Binding Revocation for IP Mobility > R IP Tunneling Optimization in a Mobile Environment > > meaning that the MIPv6 home link is first priority and you volunteer to > edit, Binding revocation is second priority and you're willing to > contribute and review, while IP tunneling optimization is third > priority and you're willing to review. > > Hope this is understandable :) > > Thanks. > > -- julien and marcello, MEXT chairs > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Feb 12 08:19:11 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7F3B28CC6F; Tue, 12 Feb 2008 08:19:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[AWL=-1.061, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hemvNdjmJLcC; Tue, 12 Feb 2008 08:19:10 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26BE128C376; Tue, 12 Feb 2008 08:19:10 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E291328C366 for ; Tue, 12 Feb 2008 08:19:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9P-JAJvD0QY for ; Tue, 12 Feb 2008 08:19:08 -0800 (PST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by core3.amsl.com (Postfix) with ESMTP id D3DD728CC55 for ; Tue, 12 Feb 2008 08:18:52 -0800 (PST) Received: by ug-out-1314.google.com with SMTP id u2so1494574uge.46 for ; Tue, 12 Feb 2008 08:20:16 -0800 (PST) Received: by 10.67.29.20 with SMTP id g20mr734328ugj.54.1202833216215; Tue, 12 Feb 2008 08:20:16 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id m1sm10288748uge.69.2008.02.12.08.20.13 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Feb 2008 08:20:15 -0800 (PST) From: Julien Laganier To: mext@ietf.org Date: Tue, 12 Feb 2008 17:20:12 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200802111135.44252.julien.IETF@laposte.net> <200802121631.35572.julien.IETF@laposte.net> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200802121720.13763.julien.IETF@laposte.net> Subject: [MEXT] ex-aequo priorities for recharter items X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Folks, Please consider avoiding giving the same priority to items you're proposing since it does not help us to determine what is most wanted. Also, note that when the same priority is given to the same items, all items below get their priorities decreased by one. See below for an example: On Tuesday 12 February 2008, Ahmad Muhanna wrote: > Hi Julien/All, > > [E] Binding Revocation for IPv6 Mobility > [CR] Generic Notification Message > [R] MIPv6 home link operation in various SDOs && [CR] IP Tunneling > Optimization in a Mobile Environment > [CR] Extend DSMIPv6 Home Network Support > > I would give MIPv6 home link operation and IP Tunneling Optimization > in Mobile Environment the same priority. This gives the following priorities: 1 Binding Revocation for IPv6 Mobility 2 Generic Notification Message 3-ex MIPv6 home link operation in various SDOs 3-ex IP Tunneling Optimization in a Mobile Environment 5 Extend DSMIPv6 Home Network Support --julien _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Feb 12 08:30:07 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2449E3A6D01; Tue, 12 Feb 2008 08:30:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.207 X-Spam-Level: X-Spam-Status: No, score=-3.207 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vscd9DUUH6hH; Tue, 12 Feb 2008 08:30:06 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FA703A6E6E; Tue, 12 Feb 2008 08:30:06 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8D753A6E4E for ; Tue, 12 Feb 2008 08:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsLl2Fuek7EU for ; Tue, 12 Feb 2008 08:30:03 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 9BF993A6D01 for ; Tue, 12 Feb 2008 08:30:03 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m1CGUij09096; Tue, 12 Feb 2008 16:30:44 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 12 Feb 2008 10:30:28 -0600 Message-ID: In-Reply-To: <200802121631.35572.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [Recharter.2] Thread-Index: AchtjOGRyGhrT4GhRPSqXUQr2gqIxgAB3dcw From: "Mohamed Khalil" To: "Julien Laganier" , Subject: Re: [MEXT] [Recharter.2] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien, [E] Binding Revocation for IPv6 Mobility [R] Generic Notification Message [R] 4283bis [R] Extend DSMIPv6 Home Network Support [R] IP Tunneling Optimization in a Mobile Environment -----Original Message----- From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Julien Laganier Sent: Tuesday, February 12, 2008 9:32 AM To: mext@ietf.org Subject: [MEXT] [Recharter.2] Folks, This is the next step in the recharter process. We'd like to get input from WG participants on what should be the items included in rechartering, what are their priorities, and who is willing to sustain the effort. When that step is completed we will take the WG input and discuss with our AD to move forward with deciding what to include or not in the charter. Your input should be sent to the list during the following two weeks, by 2008-02-26. Please pick from the list of items below the items you think the WG should work on, and order them in decreasing priority (just to make sure, first priority items goes first in the list you're making :). List of items: Binding Revocation for IP Mobility MIPv6 home link operation in various SDOs IP Tunneling Optimization in a Mobile Environment Generic Notification Message for Mobile IPv6 GRE requirements for IPv6 mobility 4283bis to extend MN identifier to other identifiers Mobile IPv6 Bootstrapping for the Authentication Option Protocol Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions Virtual Home Link configuration for Mobile IPv6 Extend DSMIPv6 Home Network Support Also, please prefix each of the items in your list with the letters E, C and/or R if you're willing to: - [E]dit: Are you willing to edit the draft corresponding to the item. - [C]ontribute: Are you willing to propose text for the draft. - [R]eview: Are you willing to review new revisions of the draft when being asked by the chairs. As an example, that could be one input list: E MIPv6 home link operation in various SDOs CR Binding Revocation for IP Mobility R IP Tunneling Optimization in a Mobile Environment meaning that the MIPv6 home link is first priority and you volunteer to edit, Binding revocation is second priority and you're willing to contribute and review, while IP tunneling optimization is third priority and you're willing to review. Hope this is understandable :) Thanks. -- julien and marcello, MEXT chairs _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Feb 12 08:45:57 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B426B28CCA4; Tue, 12 Feb 2008 08:45:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-2.162, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mh9yvxwLFTyj; Tue, 12 Feb 2008 08:45:56 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FBEB28C380; Tue, 12 Feb 2008 08:45:55 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7836E28C347 for ; Tue, 12 Feb 2008 08:45:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2H221GhOgXn for ; Tue, 12 Feb 2008 08:45:53 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id A46B728CCAA for ; Tue, 12 Feb 2008 08:45:27 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m1CGgdC06486; Tue, 12 Feb 2008 16:42:39 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 12 Feb 2008 10:46:39 -0600 Message-ID: In-Reply-To: <200802121720.13763.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ex-aequo priorities for recharter items Thread-Index: Achtk2YgbqBEjQAbTWq5OEvJ44x5egAAQkwg References: <200802111135.44252.julien.IETF@laposte.net> <200802121631.35572.julien.IETF@laposte.net> <200802121720.13763.julien.IETF@laposte.net> From: "Ahmad Muhanna" To: "Julien Laganier" , Subject: Re: [MEXT] ex-aequo priorities for recharter items X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Thanks Julien for the explanation but I also missed few items without voting and I would like to update my priority list accordingly. [E] Binding Revocation for IPv6 Mobility [CR] Generic Notification Message [CR] IP Tunneling Optimization in a Mobile Environment [R] Virtual Home Link configuration for Mobile IPv6 [R] MIPv6 home link operation in various SDOs [CR] GRE requirements for IPv6 mobility [CR] Extend DSMIPv6 Home Network Support Regards, Ahmad > -----Original Message----- > From: julien laganier [mailto:julien.laganier@gmail.com] On > Behalf Of Julien Laganier > Sent: Tuesday, February 12, 2008 10:20 AM > To: mext@ietf.org > Cc: Muhanna, Ahmad (RICH1:2H10) > Subject: ex-aequo priorities for recharter items > > Folks, > > Please consider avoiding giving the same priority to items > you're proposing since it does not help us to determine what > is most wanted. > Also, note that when the same priority is given to the same > items, all items below get their priorities decreased by one. > See below for an > example: > > On Tuesday 12 February 2008, Ahmad Muhanna wrote: > > Hi Julien/All, > > > > [E] Binding Revocation for IPv6 Mobility [CR] Generic Notification > > Message [R] MIPv6 home link operation in various SDOs && [CR] IP > > Tunneling Optimization in a Mobile Environment [CR] Extend DSMIPv6 > > Home Network Support > > > > I would give MIPv6 home link operation and IP Tunneling > Optimization > > in Mobile Environment the same priority. > > This gives the following priorities: > > 1 Binding Revocation for IPv6 Mobility > 2 Generic Notification Message > 3-ex MIPv6 home link operation in various SDOs > 3-ex IP Tunneling Optimization in a Mobile Environment > 5 Extend DSMIPv6 Home Network Support > > --julien > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Feb 12 10:22:13 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43FF628CCBF; Tue, 12 Feb 2008 10:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.877 X-Spam-Level: X-Spam-Status: No, score=-2.877 tagged_above=-999 required=5 tests=[AWL=-0.440, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdBT9blmCiNQ; Tue, 12 Feb 2008 10:22:12 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 263613A6BA5; Tue, 12 Feb 2008 10:22:12 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D802D28C386 for ; Tue, 12 Feb 2008 10:22:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUY6hKt+Vz20 for ; Tue, 12 Feb 2008 10:22:09 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id AAF533A6C66 for ; Tue, 12 Feb 2008 10:22:09 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m1CINSj27582; Tue, 12 Feb 2008 18:23:28 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 12 Feb 2008 12:23:17 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [Recharter.2] Thread-Index: AchtjOGRyGhrT4GhRPSqXUQr2gqIxgAB3dcwAAMDFsA= From: "Mohamed Khalil" To: "Mohamed Khalil" , "Julien Laganier" , Subject: Re: [MEXT] [Recharter.2] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org updated with 2 items [E] Binding Revocation for IPv6 Mobility [R] Generic Notification Message. [CR] GRE requirements for IPv6 mobility. [R] 4283bis. [R] Extend DSMIPv6 Home Network Support [CR] Virtual Home Link configuration for Mobile IPv6. [R] IP Tunneling Optimization in a Mobile Environment. -----Original Message----- From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Khalil, Mohamed (RICH2:2S20) Sent: Tuesday, February 12, 2008 10:30 AM To: Julien Laganier; mext@ietf.org Subject: Re: [MEXT] [Recharter.2] Hi Julien, [E] Binding Revocation for IPv6 Mobility [R] Generic Notification Message [R] 4283bis [R] Extend DSMIPv6 Home Network Support [R] IP Tunneling Optimization in a Mobile Environment -----Original Message----- From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Julien Laganier Sent: Tuesday, February 12, 2008 9:32 AM To: mext@ietf.org Subject: [MEXT] [Recharter.2] Folks, This is the next step in the recharter process. We'd like to get input from WG participants on what should be the items included in rechartering, what are their priorities, and who is willing to sustain the effort. When that step is completed we will take the WG input and discuss with our AD to move forward with deciding what to include or not in the charter. Your input should be sent to the list during the following two weeks, by 2008-02-26. Please pick from the list of items below the items you think the WG should work on, and order them in decreasing priority (just to make sure, first priority items goes first in the list you're making :). List of items: Binding Revocation for IP Mobility MIPv6 home link operation in various SDOs IP Tunneling Optimization in a Mobile Environment Generic Notification Message for Mobile IPv6 GRE requirements for IPv6 mobility 4283bis to extend MN identifier to other identifiers Mobile IPv6 Bootstrapping for the Authentication Option Protocol Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions Virtual Home Link configuration for Mobile IPv6 Extend DSMIPv6 Home Network Support Also, please prefix each of the items in your list with the letters E, C and/or R if you're willing to: - [E]dit: Are you willing to edit the draft corresponding to the item. - [C]ontribute: Are you willing to propose text for the draft. - [R]eview: Are you willing to review new revisions of the draft when being asked by the chairs. As an example, that could be one input list: E MIPv6 home link operation in various SDOs CR Binding Revocation for IP Mobility R IP Tunneling Optimization in a Mobile Environment meaning that the MIPv6 home link is first priority and you volunteer to edit, Binding revocation is second priority and you're willing to contribute and review, while IP tunneling optimization is third priority and you're willing to review. Hope this is understandable :) Thanks. -- julien and marcello, MEXT chairs _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Feb 12 10:31:46 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6925628C3CE; Tue, 12 Feb 2008 10:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+Qqac1kXA53; Tue, 12 Feb 2008 10:31:45 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DD9528C2E9; Tue, 12 Feb 2008 10:31:45 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC5B128C2E9 for ; Tue, 12 Feb 2008 10:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tuI1Ib9hqKQ for ; Tue, 12 Feb 2008 10:31:42 -0800 (PST) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id DBC743A6C66 for ; Tue, 12 Feb 2008 10:31:42 -0800 (PST) Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Feb 2008 10:33:07 -0800 Message-ID: <47B1E662.1000902@azairenet.com> Date: Tue, 12 Feb 2008 10:33:06 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Julien Laganier References: <200802111135.44252.julien.IETF@laposte.net> <200802121631.35572.julien.IETF@laposte.net> In-Reply-To: <200802121631.35572.julien.IETF@laposte.net> X-OriginalArrivalTime: 12 Feb 2008 18:33:07.0167 (UTC) FILETIME=[B6112EF0:01C86DA5] Cc: mext@ietf.org Subject: Re: [MEXT] [Recharter.2] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien, Here is my list. [R] Generic Notification Message for Mobile IPv6 [R] 4283bis to extend MN identifier to other identifiers [C] Binding Revocation for IP Mobility [E] MIPv6 home link operation in various SDOs [C] Virtual Home Link configuration for Mobile IPv6 [C] Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions [R] GRE requirements for IPv6 mobility Vijay ps: This is turning out to be a beauty contest. :) Julien Laganier wrote: > Folks, > > This is the next step in the recharter process. We'd like to get input > from WG participants on what should be the items included in > rechartering, what are their priorities, and who is willing to > sustain the effort. When that step is completed we will take the WG > input and discuss with our AD to move forward with deciding what to > include or not in the charter. Your input should be sent to the list > during the following two weeks, by 2008-02-26. > > Please pick from the list of items below the items you think the WG > should work on, and order them in decreasing priority (just to make > sure, first priority items goes first in the list you're making :). > > List of items: > > Binding Revocation for IP Mobility > MIPv6 home link operation in various SDOs > IP Tunneling Optimization in a Mobile Environment > Generic Notification Message for Mobile IPv6 > GRE requirements for IPv6 mobility > 4283bis to extend MN identifier to other identifiers > Mobile IPv6 Bootstrapping for the Authentication Option Protocol > Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions > Virtual Home Link configuration for Mobile IPv6 > Extend DSMIPv6 Home Network Support > > Also, please prefix each of the items in your list with the letters E, C > and/or R if you're willing to: > > - [E]dit: Are you willing to edit the draft corresponding to the > item. > > - [C]ontribute: Are you willing to propose text for the draft. > > - [R]eview: Are you willing to review new revisions of the draft when > being asked by the chairs. > > As an example, that could be one input list: > > E MIPv6 home link operation in various SDOs > CR Binding Revocation for IP Mobility > R IP Tunneling Optimization in a Mobile Environment > > meaning that the MIPv6 home link is first priority and you volunteer to > edit, Binding revocation is second priority and you're willing to > contribute and review, while IP tunneling optimization is third > priority and you're willing to review. > > Hope this is understandable :) > > Thanks. > > -- julien and marcello, MEXT chairs > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Feb 12 10:39:29 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D55A828C3EF; Tue, 12 Feb 2008 10:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.123 X-Spam-Level: X-Spam-Status: No, score=-4.123 tagged_above=-999 required=5 tests=[AWL=-1.686, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUJS-TFrNDXY; Tue, 12 Feb 2008 10:39:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C49A828C289; Tue, 12 Feb 2008 10:39:28 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C8AF28C289 for ; Tue, 12 Feb 2008 10:39:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6FgSc1SfAYFZ for ; Tue, 12 Feb 2008 10:39:21 -0800 (PST) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by core3.amsl.com (Postfix) with ESMTP id C121128C1E7 for ; Tue, 12 Feb 2008 10:39:21 -0800 (PST) Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m1CIeje4022549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Feb 2008 10:40:45 -0800 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m1CIeiwL005636; Tue, 12 Feb 2008 10:40:44 -0800 Received: from NAEX12.na.qualcomm.com ([129.46.51.246]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Feb 2008 10:40:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 12 Feb 2008 10:40:28 -0800 Message-ID: In-Reply-To: <200802121631.35572.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [Recharter.2] Thread-Index: AchtjO6BsClVztF0QNGQbWriNZVZXwAGbGXw From: "Giaretta, Gerardo" To: "Julien Laganier" , X-OriginalArrivalTime: 12 Feb 2008 18:40:44.0729 (UTC) FILETIME=[C6CB9A90:01C86DA6] Subject: Re: [MEXT] [Recharter.2] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien, Please find below my list: 1) Binding Revocation [CR] 2) 4283bis [R] 3) Virtual Home Link configuration for Mobile IPv6 [CR] 4) Generic Notification Message for Mobile IPv6 [R] 5) MIPv6 Firewall [R] Thanks Gerardo > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Julien Laganier > Sent: Tuesday, February 12, 2008 7:32 AM > To: mext@ietf.org > Subject: [MEXT] [Recharter.2] > > Folks, > > This is the next step in the recharter process. We'd like to get input > from WG participants on what should be the items included in > rechartering, what are their priorities, and who is willing to > sustain the effort. When that step is completed we will take the WG > input and discuss with our AD to move forward with deciding what to > include or not in the charter. Your input should be sent to the list > during the following two weeks, by 2008-02-26. > > Please pick from the list of items below the items you think the WG > should work on, and order them in decreasing priority (just to make > sure, first priority items goes first in the list you're making :). > > List of items: > > Binding Revocation for IP Mobility > MIPv6 home link operation in various SDOs > IP Tunneling Optimization in a Mobile Environment > Generic Notification Message for Mobile IPv6 > GRE requirements for IPv6 mobility > 4283bis to extend MN identifier to other identifiers > Mobile IPv6 Bootstrapping for the Authentication Option Protocol > Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions > Virtual Home Link configuration for Mobile IPv6 > Extend DSMIPv6 Home Network Support > > Also, please prefix each of the items in your list with the letters E, C > and/or R if you're willing to: > > - [E]dit: Are you willing to edit the draft corresponding to the > item. > > - [C]ontribute: Are you willing to propose text for the draft. > > - [R]eview: Are you willing to review new revisions of the draft when > being asked by the chairs. > > As an example, that could be one input list: > > E MIPv6 home link operation in various SDOs > CR Binding Revocation for IP Mobility > R IP Tunneling Optimization in a Mobile Environment > > meaning that the MIPv6 home link is first priority and you volunteer to > edit, Binding revocation is second priority and you're willing to > contribute and review, while IP tunneling optimization is third > priority and you're willing to review. > > Hope this is understandable :) > > Thanks. > > -- julien and marcello, MEXT chairs > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Feb 12 10:42:07 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09FCE28CC0D; Tue, 12 Feb 2008 10:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RC7cotpZz-6H; Tue, 12 Feb 2008 10:42:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E031328C3F6; Tue, 12 Feb 2008 10:42:05 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE17928C3F2 for ; Tue, 12 Feb 2008 10:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgG0LdKlPUoh for ; Tue, 12 Feb 2008 10:42:02 -0800 (PST) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id DB6DB28C3F0 for ; Tue, 12 Feb 2008 10:42:02 -0800 (PST) Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Feb 2008 10:43:20 -0800 Message-ID: <47B1E8C8.4030905@azairenet.com> Date: Tue, 12 Feb 2008 10:43:20 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Giaretta, Gerardo" References: In-Reply-To: X-OriginalArrivalTime: 12 Feb 2008 18:43:20.0746 (UTC) FILETIME=[23C9E8A0:01C86DA7] Cc: George Tsirtsis , mext@ietf.org, Julien Laganier Subject: [MEXT] Mobile IPv6 operation with Firewalls (was Re: [Recharter.2]) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Gerardo, George, Mobile IPv6 operation with firewalls is already there in the current mext charter. Vijay Giaretta, Gerardo wrote: > Hi Julien, > > Please find below my list: > > 1) Binding Revocation [CR] > 2) 4283bis [R] > 3) Virtual Home Link configuration for Mobile IPv6 [CR] > 4) Generic Notification Message for Mobile IPv6 [R] > 5) MIPv6 Firewall [R] > > Thanks > Gerardo > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf > Of >> Julien Laganier >> Sent: Tuesday, February 12, 2008 7:32 AM >> To: mext@ietf.org >> Subject: [MEXT] [Recharter.2] >> >> Folks, >> >> This is the next step in the recharter process. We'd like to get input >> from WG participants on what should be the items included in >> rechartering, what are their priorities, and who is willing to >> sustain the effort. When that step is completed we will take the WG >> input and discuss with our AD to move forward with deciding what to >> include or not in the charter. Your input should be sent to the list >> during the following two weeks, by 2008-02-26. >> >> Please pick from the list of items below the items you think the WG >> should work on, and order them in decreasing priority (just to make >> sure, first priority items goes first in the list you're making :). >> >> List of items: >> >> Binding Revocation for IP Mobility >> MIPv6 home link operation in various SDOs >> IP Tunneling Optimization in a Mobile Environment >> Generic Notification Message for Mobile IPv6 >> GRE requirements for IPv6 mobility >> 4283bis to extend MN identifier to other identifiers >> Mobile IPv6 Bootstrapping for the Authentication Option Protocol >> Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions >> Virtual Home Link configuration for Mobile IPv6 >> Extend DSMIPv6 Home Network Support >> >> Also, please prefix each of the items in your list with the letters E, > C >> and/or R if you're willing to: >> >> - [E]dit: Are you willing to edit the draft corresponding to the >> item. >> >> - [C]ontribute: Are you willing to propose text for the draft. >> >> - [R]eview: Are you willing to review new revisions of the draft when >> being asked by the chairs. >> >> As an example, that could be one input list: >> >> E MIPv6 home link operation in various SDOs >> CR Binding Revocation for IP Mobility >> R IP Tunneling Optimization in a Mobile Environment >> >> meaning that the MIPv6 home link is first priority and you volunteer > to >> edit, Binding revocation is second priority and you're willing to >> contribute and review, while IP tunneling optimization is third >> priority and you're willing to review. >> >> Hope this is understandable :) >> >> Thanks. >> >> -- julien and marcello, MEXT chairs >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> http://www.ietf.org/mailman/listinfo/mext > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Feb 12 17:25:02 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B21E628C58B; Tue, 12 Feb 2008 17:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.707 X-Spam-Level: X-Spam-Status: No, score=-2.707 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Ms-2VrLsAtr; Tue, 12 Feb 2008 17:25:01 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A861428C13A; Tue, 12 Feb 2008 17:25:01 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B3AA28C13A for ; Tue, 12 Feb 2008 17:24:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdLDkhjLx1p9 for ; Tue, 12 Feb 2008 17:24:58 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by core3.amsl.com (Postfix) with ESMTP id 7BCDC28C104 for ; Tue, 12 Feb 2008 17:24:58 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id k40so3770450wah.25 for ; Tue, 12 Feb 2008 17:26:21 -0800 (PST) Received: by 10.114.58.1 with SMTP id g1mr2268151waa.91.1202865981746; Tue, 12 Feb 2008 17:26:21 -0800 (PST) Received: by 10.114.178.12 with HTTP; Tue, 12 Feb 2008 17:26:21 -0800 (PST) Message-ID: Date: Tue, 12 Feb 2008 17:26:21 -0800 From: "Zhen Cao" To: "Julien Laganier" In-Reply-To: <200802121631.35572.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Disposition: inline References: <200802111135.44252.julien.IETF@laposte.net> <200802121631.35572.julien.IETF@laposte.net> Cc: mext@ietf.org Subject: Re: [MEXT] [Recharter.2] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi All, I would like to support: [CR] Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions Thanks, Zhen On Feb 12, 2008 7:31 AM, Julien Laganier wrote: > Folks, > > This is the next step in the recharter process. We'd like to get input > from WG participants on what should be the items included in > rechartering, what are their priorities, and who is willing to > sustain the effort. When that step is completed we will take the WG > input and discuss with our AD to move forward with deciding what to > include or not in the charter. Your input should be sent to the list > during the following two weeks, by 2008-02-26. > > Please pick from the list of items below the items you think the WG > should work on, and order them in decreasing priority (just to make > sure, first priority items goes first in the list you're making :). > > List of items: > > Binding Revocation for IP Mobility > MIPv6 home link operation in various SDOs > IP Tunneling Optimization in a Mobile Environment > Generic Notification Message for Mobile IPv6 > GRE requirements for IPv6 mobility > 4283bis to extend MN identifier to other identifiers > Mobile IPv6 Bootstrapping for the Authentication Option Protocol > Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions > Virtual Home Link configuration for Mobile IPv6 > Extend DSMIPv6 Home Network Support > > Also, please prefix each of the items in your list with the letters E, C > and/or R if you're willing to: > > - [E]dit: Are you willing to edit the draft corresponding to the > item. > > - [C]ontribute: Are you willing to propose text for the draft. > > - [R]eview: Are you willing to review new revisions of the draft when > being asked by the chairs. > > As an example, that could be one input list: > > E MIPv6 home link operation in various SDOs > CR Binding Revocation for IP Mobility > R IP Tunneling Optimization in a Mobile Environment > > meaning that the MIPv6 home link is first priority and you volunteer to > edit, Binding revocation is second priority and you're willing to > contribute and review, while IP tunneling optimization is third > priority and you're willing to review. > > Hope this is understandable :) > > Thanks. > > -- julien and marcello, MEXT chairs > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Feb 12 21:11:54 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CEE928C6F9; Tue, 12 Feb 2008 21:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.698 X-Spam-Level: X-Spam-Status: No, score=-3.698 tagged_above=-999 required=5 tests=[AWL=-1.261, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmKjukIByJYB; Tue, 12 Feb 2008 21:11:53 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BC8C28C6C4; Tue, 12 Feb 2008 21:11:53 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AD6D28C6C4 for ; Tue, 12 Feb 2008 21:11:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbkX-VJA365V for ; Tue, 12 Feb 2008 21:11:51 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A154328C65A for ; Tue, 12 Feb 2008 21:11:51 -0800 (PST) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 12 Feb 2008 21:13:15 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m1D5DFXM017507; Tue, 12 Feb 2008 21:13:15 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1D5D6JM018449; Wed, 13 Feb 2008 05:13:15 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Feb 2008 21:13:06 -0800 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Feb 2008 21:13:05 -0800 From: "Sri Gundavelli" To: "'Julien Laganier'" , References: <200802111135.44252.julien.IETF@laposte.net> <200802121631.35572.julien.IETF@laposte.net> Date: Tue, 12 Feb 2008 21:13:05 -0800 Message-ID: <000001c86dff$1d789930$d4f6200a@amer.cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AchtjOx1a28Z3esuT/Ssl9EXg+BHEQAcUPwg In-Reply-To: <200802121631.35572.julien.IETF@laposte.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 13 Feb 2008 05:13:05.0811 (UTC) FILETIME=[1D714630:01C86DFF] Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [MEXT] [Recharter.2] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien, My input on the proposals. [E] Virtual Home Link configuration for Mobile IPv6 [E] GRE requirements for IPv6 mobility [E] Generic Notification Message for Mobile IPv6 [E] Binding Revocation for IP Mobility [R] Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions [R] IP Tunneling Optimization in a Mobile Environment Regards Sri > MIPv6 home link operation in various SDOs > IP Tunneling Optimization in a Mobile Environment > Generic Notification Message for Mobile IPv6 > GRE requirements for IPv6 mobility > Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions > Virtual Home Link configuration for Mobile IPv6 > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Julien Laganier > Sent: Tuesday, February 12, 2008 7:32 AM > To: mext@ietf.org > Subject: [MEXT] [Recharter.2] > > Folks, > > This is the next step in the recharter process. We'd like to get input > from WG participants on what should be the items included in > rechartering, what are their priorities, and who is willing to > sustain the effort. When that step is completed we will take the WG > input and discuss with our AD to move forward with deciding what to > include or not in the charter. Your input should be sent to the list > during the following two weeks, by 2008-02-26. > > Please pick from the list of items below the items you think the WG > should work on, and order them in decreasing priority (just to make > sure, first priority items goes first in the list you're making :). > > List of items: > > Binding Revocation for IP Mobility > MIPv6 home link operation in various SDOs > IP Tunneling Optimization in a Mobile Environment > Generic Notification Message for Mobile IPv6 > GRE requirements for IPv6 mobility > 4283bis to extend MN identifier to other identifiers > Mobile IPv6 Bootstrapping for the Authentication Option Protocol > Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions > Virtual Home Link configuration for Mobile IPv6 > Extend DSMIPv6 Home Network Support > > Also, please prefix each of the items in your list with the > letters E, C > and/or R if you're willing to: > > - [E]dit: Are you willing to edit the draft corresponding to the > item. > > - [C]ontribute: Are you willing to propose text for the draft. > > - [R]eview: Are you willing to review new revisions of the draft when > being asked by the chairs. > > As an example, that could be one input list: > > E MIPv6 home link operation in various SDOs > CR Binding Revocation for IP Mobility > R IP Tunneling Optimization in a Mobile Environment > > meaning that the MIPv6 home link is first priority and you > volunteer to > edit, Binding revocation is second priority and you're willing to > contribute and review, while IP tunneling optimization is third > priority and you're willing to review. > > Hope this is understandable :) > > Thanks. > > -- julien and marcello, MEXT chairs > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Feb 12 22:16:11 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CB1C3A6EFE; Tue, 12 Feb 2008 22:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.751 X-Spam-Level: X-Spam-Status: No, score=-0.751 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFA99vkYn8Q7; Tue, 12 Feb 2008 22:16:10 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40AB13A6EDD; Tue, 12 Feb 2008 22:16:10 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0E363A6AE6 for ; Tue, 12 Feb 2008 22:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVI5eWI8HIDH for ; Tue, 12 Feb 2008 22:16:07 -0800 (PST) Received: from mail.critical.com (mail.critical.com [64.246.137.41]) by core3.amsl.com (Postfix) with ESMTP id 74ED43A6829 for ; Tue, 12 Feb 2008 22:16:07 -0800 (PST) Received: by mail.critical.com (Postfix, from userid 99) id EDB693A40C0; Wed, 13 Feb 2008 01:17:28 -0500 (EST) Received: from cardnote.critical.com (ip-72-10-210-250.nwptny.ntcnet.net [72.10.210.250]) by mail.critical.com (Postfix) with ESMTP id EEBA93A40C1; Wed, 13 Feb 2008 01:17:14 -0500 (EST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 13 Feb 2008 01:03:25 -0500 To: Jari Arkko , mext@ietf.org, draft-ietf-mext-aero-reqs@tools.ietf.org From: "Stuart W. Card" In-Reply-To: <47AACFDD.8030406@piuha.net> References: <47AACFDD.8030406@piuha.net> Mime-Version: 1.0 Message-Id: <20080213061714.EEBA93A40C1@mail.critical.com> Cc: patricia.baskinger@ngc.com, zabele@alphatech.com Subject: Re: [MEXT] review of draft-ietf-mext-aero-reqs X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org At 04:31 AM 2/7/2008, Jari Arkko wrote: >I have reviewed this document. My detailed comments are further down... Thanks for the comments. I have interspersed my own. Sorry it took me so long to send them. > > Increased packet overhead - Given the constrained link bandwidths > > available in even future communications systems for aeronautics > > and space exploration, planners are extremely adverse to header > > overhead. Since any amount of available link capacity can be > > utilized for extra situational awareness, science data, etc., > > every byte of header/tunnel overhead displaces a byte of useful > > data. >Secondary issues like this are not very convincing (what about header >compression, for instance?) and confuse the key problem. This is not a "secondary issue" in my world: link speeds of 128 kbps down all the way to 2400 bps half-duplex with long turn-around times; we are very concerned with protocol overhead. Admittedly ROHC etc. may reduce it. > > Since for ATS, the MRs and MNNs are under regulatory control and are > > actively tested and maintained, it is not unreasonable to assume that > > special patches or software be running on these devices to enable > > NEMO RO. In fact, since these devices are accessed by skilled > > technicians and professionals, it may be acceptable even if complex > > configuration is required for NEMO RO. Of course simplicity in setup > > and configuration is desirable, however. >What about CNs, is it reasonable to expect changes to them? No: in many cases, they may not even know that they are communicating with an aeronautical mobile. > > The set of CNs may be assumed to > > all share the same network prefix. >This seems unexpected. Why would we assume this? I agree with your comment. > > If duplicating a small number of packets sent over > > both the MRHA tunnel and the optimized path is possible until the > > optimized path can be verified to function for a particular data > > flow, then this could be sufficient to meet this requirement (it is > > safe to assume that the applications are robust to this duplication). > >I am not sure I understand the transport implications of such >duplication. I could imagine under some conditions it could introduce >reordering or something that causes harm for TCP. It is not the duplication that troubles TCP, but the possibility of sending _different_ packets over different paths: if packets N and N+2 both go over a fast path, and packet N+1 over a slow path, then the receiver is likely to erroneously declare that packet N+1 has been lost, and issue a DUP ACK of N. If this happens too often, TCP based applications will fail, due to exponential backoff, while the wireless links are filled with needless retransmissions. Fortunately there are TCP dialects that are immune to this, such as SCPS-TP, but they are far from universally used. > > For oceanic flight, ATS and AOS may > > also benefit from the capability of nesting MRs between multiple > > planes to provide a "reachback" to terrestrial groundstations rather > > than relying solely on lower rate HF or satellite systems. In either > > case, this mode of operation is beyond current strict requirements > > and is merely desirable. > >This requirement makes sense to me, but it is also something that >focuses on building ad hoc routing style networks. I would suggest that >we have to keep this part of the problem space out of our effort if we >are going to complete something. Lets look at the ad hoc routing aspect >separately. > >I also do not necessarily believe that nested NEMOs are the right >approach to doin such multi-hop manet routing. It seems preferrable that >the MR deals with this by also acting as a, say, MANET router. Whether this is handled as nested NEMO, MANET or MANEMO, for U.S. DoD airborne networks, the capability for one aircraft to relay on behalf of another is a hard requirement, not just a desirable feature. This is my most urgent comment. I have cc'ed a couple of members of our team who are not regular participants in MEXT, as they may be interested in this discussion in general, and that point in particular. Thanks to the authors for this fairly comprehensive draft! Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc. * Creativity * Diversity * Expertise * Flexibility * Integrity * Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501 315-793-0248 x141 FAX -9710 www.critical.com _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Feb 13 00:19:11 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E71A3A6F4B; Wed, 13 Feb 2008 00:19:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.406 X-Spam-Level: X-Spam-Status: No, score=-3.406 tagged_above=-999 required=5 tests=[AWL=-0.969, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THva2A3qoI5k; Wed, 13 Feb 2008 00:19:10 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 106003A6F40; Wed, 13 Feb 2008 00:19:10 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23E2928C630 for ; Wed, 13 Feb 2008 00:19:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hphcyG5jtnSz for ; Wed, 13 Feb 2008 00:19:08 -0800 (PST) Received: from sehan001bb.han.telia.se (sehan001bb.han.telia.se [131.115.18.152]) by core3.amsl.com (Postfix) with ESMTP id EBF163A6F0F for ; Wed, 13 Feb 2008 00:19:07 -0800 (PST) Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Feb 2008 09:20:29 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Feb 2008 09:20:28 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30288AD62@SEHAN021MB.tcad.telia.se> In-Reply-To: <200802121631.35572.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [Recharter.2] Thread-Index: AchtjN/OaRgxKKJZS028BA6VNDBxCwAe9jog References: <200802111135.44252.julien.IETF@laposte.net> <200802121631.35572.julien.IETF@laposte.net> From: To: , X-OriginalArrivalTime: 13 Feb 2008 08:20:29.0112 (UTC) FILETIME=[4AF8DB80:01C86E19] Subject: Re: [MEXT] [Recharter.2] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien, My list would be: [E] MIPv6 home link operation in various SDOs [E] Virtual Home Link configuration for Mobile IPv6 [E] 4283bis to extend MN identifier to other identifiers [CR] Binding Revocation for IP Mobility [R] GRE requirements for IPv6 mobility [CR] Extend DSMIPv6 Home Network Support [CR] IP Tunneling Optimization in a Mobile Environment Cheers, Jouni > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Julien Laganier > Sent: 12. helmikuuta 2008 17:32 > To: mext@ietf.org > Subject: [MEXT] [Recharter.2] > > > Folks, > > This is the next step in the recharter process. We'd like to get input > from WG participants on what should be the items included in > rechartering, what are their priorities, and who is willing to > sustain the effort. When that step is completed we will take the WG > input and discuss with our AD to move forward with deciding what to > include or not in the charter. Your input should be sent to the list > during the following two weeks, by 2008-02-26. > > Please pick from the list of items below the items you think the WG > should work on, and order them in decreasing priority (just to make > sure, first priority items goes first in the list you're making :). > > List of items: > > Binding Revocation for IP Mobility > MIPv6 home link operation in various SDOs > IP Tunneling Optimization in a Mobile Environment > Generic Notification Message for Mobile IPv6 > GRE requirements for IPv6 mobility > 4283bis to extend MN identifier to other identifiers > Mobile IPv6 Bootstrapping for the Authentication Option Protocol > Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions > Virtual Home Link configuration for Mobile IPv6 > Extend DSMIPv6 Home Network Support > > Also, please prefix each of the items in your list with the > letters E, C > and/or R if you're willing to: > > - [E]dit: Are you willing to edit the draft corresponding to the > item. > > - [C]ontribute: Are you willing to propose text for the draft. > > - [R]eview: Are you willing to review new revisions of the draft when > being asked by the chairs. > > As an example, that could be one input list: > > E MIPv6 home link operation in various SDOs > CR Binding Revocation for IP Mobility > R IP Tunneling Optimization in a Mobile Environment > > meaning that the MIPv6 home link is first priority and you > volunteer to > edit, Binding revocation is second priority and you're willing to > contribute and review, while IP tunneling optimization is third > priority and you're willing to review. > > Hope this is understandable :) > > Thanks. > > -- julien and marcello, MEXT chairs > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Feb 13 07:36:33 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A20B828C82A; Wed, 13 Feb 2008 07:36:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.837 X-Spam-Level: X-Spam-Status: No, score=-3.837 tagged_above=-999 required=5 tests=[AWL=-1.400, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NInXZV2SGUx0; Wed, 13 Feb 2008 07:36:32 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 843483A6F8C; Wed, 13 Feb 2008 07:36:32 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6085228C800 for ; Wed, 13 Feb 2008 07:36:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnx480+dZjYG for ; Wed, 13 Feb 2008 07:36:30 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 20BFA3A6F87 for ; Wed, 13 Feb 2008 07:36:30 -0800 (PST) Received: from chelo-it-uc3m-es.it.uc3m.es (chelo-it-uc3m-es.it.uc3m.es [163.117.139.32])by smtp02.uc3m.es (Postfix) with ESMTP id A15A12F8648; Wed, 13 Feb 2008 16:37:49 +0100 (CET) Message-Id: From: marcelo bagnulo braun To: Vijay Devarapalli In-Reply-To: <47B1E662.1000902@azairenet.com> Mime-Version: 1.0 (Apple Message framework v915) Date: Wed, 13 Feb 2008 16:37:48 +0100 References: <200802111135.44252.julien.IETF@laposte.net> <200802121631.35572.julien.IETF@laposte.net> <47B1E662.1000902@azairenet.com> X-Mailer: Apple Mail (2.915) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-24.9097 TC:1F TRN:45 TV:5.0.1023(15726.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] [Recharter.2] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org FWIW this expression of opinions is only part of the input that we = will be considering for this decision, as Julien has already = mentioned, since we also have other inputs to be added to this, like = previous discussion and expressions of interest, in order to fully = evaluate where the WG stands and in what items they would be willing = to investe their energy Regards, marcelo El 12/02/2008, a las 19:33, Vijay Devarapalli escribi=F3: > Hi Julien, > > Here is my list. > > [R] Generic Notification Message for Mobile IPv6 > [R] 4283bis to extend MN identifier to other identifiers > [C] Binding Revocation for IP Mobility > [E] MIPv6 home link operation in various SDOs > [C] Virtual Home Link configuration for Mobile IPv6 > [C] Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions > [R] GRE requirements for IPv6 mobility > > Vijay > > ps: This is turning out to be a beauty contest. :) > > Julien Laganier wrote: >> Folks, >> >> This is the next step in the recharter process. We'd like to get = >> input >> from WG participants on what should be the items included in >> rechartering, what are their priorities, and who is willing to >> sustain the effort. When that step is completed we will take the WG >> input and discuss with our AD to move forward with deciding what to >> include or not in the charter. Your input should be sent to the list >> during the following two weeks, by 2008-02-26. >> >> Please pick from the list of items below the items you think the WG >> should work on, and order them in decreasing priority (just to make >> sure, first priority items goes first in the list you're making :). >> >> List of items: >> >> Binding Revocation for IP Mobility >> MIPv6 home link operation in various SDOs >> IP Tunneling Optimization in a Mobile Environment >> Generic Notification Message for Mobile IPv6 >> GRE requirements for IPv6 mobility >> 4283bis to extend MN identifier to other identifiers >> Mobile IPv6 Bootstrapping for the Authentication Option Protocol >> Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions >> Virtual Home Link configuration for Mobile IPv6 >> Extend DSMIPv6 Home Network Support >> >> Also, please prefix each of the items in your list with the letters = >> E, C >> and/or R if you're willing to: >> >> - [E]dit: Are you willing to edit the draft corresponding to the >> item. >> >> - [C]ontribute: Are you willing to propose text for the draft. >> >> - [R]eview: Are you willing to review new revisions of the draft when >> being asked by the chairs. >> >> As an example, that could be one input list: >> >> E MIPv6 home link operation in various SDOs >> CR Binding Revocation for IP Mobility >> R IP Tunneling Optimization in a Mobile Environment >> >> meaning that the MIPv6 home link is first priority and you = >> volunteer to >> edit, Binding revocation is second priority and you're willing to >> contribute and review, while IP tunneling optimization is third >> priority and you're willing to review. >> >> Hope this is understandable :) >> >> Thanks. >> >> -- julien and marcello, MEXT chairs >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> http://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Feb 13 08:42:57 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEC3B28C8D9; Wed, 13 Feb 2008 08:42:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.518 X-Spam-Level: X-Spam-Status: No, score=-0.518 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxTSN-oX6vWJ; Wed, 13 Feb 2008 08:42:56 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C03A43A6F65; Wed, 13 Feb 2008 08:42:56 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3502E3A6A73 for ; Wed, 13 Feb 2008 08:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEwE0E3TMvUa for ; Wed, 13 Feb 2008 08:42:51 -0800 (PST) Received: from web84107.mail.mud.yahoo.com (web84107.mail.mud.yahoo.com [68.142.206.194]) by core3.amsl.com (Postfix) with SMTP id 4E2E03A6F86 for ; Wed, 13 Feb 2008 08:42:51 -0800 (PST) Received: (qmail 20791 invoked by uid 60001); 13 Feb 2008 16:44:14 -0000 X-YMail-OSG: CHa1ipIVM1lBST9yqOC0VqLrTcaCaeg7R7kenQQZv_kQ1xdnzX4mQgmsIu2Hq3q7Jr7ZLnqQfg-- Received: from [206.16.17.212] by web84107.mail.mud.yahoo.com via HTTP; Wed, 13 Feb 2008 08:44:13 PST X-Mailer: YahooMailRC/818.31 YahooMailWebService/0.7.162 Date: Wed, 13 Feb 2008 08:44:13 -0800 (PST) From: Behcet Sarikaya To: mext@ietf.org MIME-Version: 1.0 Message-ID: <121880.19681.qm@web84107.mail.mud.yahoo.com> Subject: [MEXT] Rechartering work items X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0778299725==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0778299725== Content-Type: multipart/alternative; boundary="0-1105360515-1202921053=:19681" --0-1105360515-1202921053=:19681 Content-Type: text/plain; charset=us-ascii Hi Julien, Here is my quite conservative list: [R] Virtual Home Link configuration for Mobile IPv6 [R] GRE requirements for IPv6 mobility [R] Extend DSMIPv6 Home Network Support [R] Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions Kind regards, Behcet --0-1105360515-1202921053=:19681 Content-Type: text/html; charset=us-ascii
Hi Julien,
  Here is my quite conservative list:

[R] Virtual Home Link configuration for Mobile IPv6
[R] GRE requirements for IPv6 mobility
[R] Extend DSMIPv6 Home Network Support
[R] Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions

Kind regards,


Behcet
--0-1105360515-1202921053=:19681-- --===============0778299725== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext --===============0778299725==-- From mext-bounces@ietf.org Wed Feb 13 10:38:07 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72B3B28CC87; Wed, 13 Feb 2008 10:38:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=-2.085, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOypG5mVVESt; Wed, 13 Feb 2008 10:38:07 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2685E28CA04; Wed, 13 Feb 2008 10:36:26 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B2CA28C9E9 for ; Wed, 13 Feb 2008 10:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12zx6HOmSEcF for ; Wed, 13 Feb 2008 10:36:23 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id C559C28C8C8 for ; Wed, 13 Feb 2008 10:34:12 -0800 (PST) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m1DIZT3O013136 for ; Wed, 13 Feb 2008 12:35:35 -0600 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Feb 2008 12:35:32 -0600 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Feb 2008 12:35:32 -0600 Message-ID: <47B338F4.60808@ericsson.com> Date: Wed, 13 Feb 2008 13:37:40 -0500 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: mext@ietf.org Content-Type: multipart/mixed; boundary="------------080703090509070108020408" X-OriginalArrivalTime: 13 Feb 2008 18:35:32.0062 (UTC) FILETIME=[36D827E0:01C86E6F] Subject: [MEXT] [Fwd: I-D Action:draft-krishnan-mext-ha-redirect-00.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --------------080703090509070108020408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Folks, We submitted a draft about redirecting MNs to other HAs for overload prevention, load balancing or other purposes. We would appreciate any comments and suggestions on this document. Thanks Authors -------- Original Message -------- Subject: I-D Action:draft-krishnan-mext-ha-redirect-00.txt Date: Wed, 13 Feb 2008 10:30:01 -0800 (PST) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Redirecting Binding Updates in MIPv6 Author(s) : S. Krishnan, et al. Filename : draft-krishnan-mext-ha-redirect-00.txt Pages : 9 Date : 2008-02-13 This document specifies a new Home Agent Redirect mechanism, where an initially contacted Home Agent can let the Mobile Node knows that it needs to connect to an alternate Home Agent to get mobility services for overload prevention and/or load balancing purposes. This document proposes a new error code for the binding acknowledgement message and a new mobility option to be carried on the binding acknowledgement message for this purpose. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-krishnan-mext-ha-redirect-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-krishnan-mext-ha-redirect-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-krishnan-mext-ha-redirect-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. --------------080703090509070108020408 Content-Type: Message/External-body; name="draft-krishnan-mext-ha-redirect-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-krishnan-mext-ha-redirect-00.txt" Content-Type: text/plain Content-ID: <2008-02-13101747.I-D\@ietf.org> --------------080703090509070108020408 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext --------------080703090509070108020408-- From mext-bounces@ietf.org Wed Feb 13 14:18:24 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0FBD28C500; Wed, 13 Feb 2008 14:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.366 X-Spam-Level: X-Spam-Status: No, score=-1.366 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GutBZ6VaAt3t; Wed, 13 Feb 2008 14:18:24 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CE9E28C0F3; Wed, 13 Feb 2008 14:18:24 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2F4328C1FC for ; Wed, 13 Feb 2008 14:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kXx1fbZZZBb for ; Wed, 13 Feb 2008 14:18:22 -0800 (PST) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id 125D128C0F3 for ; Wed, 13 Feb 2008 14:18:22 -0800 (PST) Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Feb 2008 14:19:45 -0800 Message-ID: <47B36D00.8020707@azairenet.com> Date: Wed, 13 Feb 2008 14:19:44 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: mext@ietf.org X-OriginalArrivalTime: 13 Feb 2008 22:19:45.0242 (UTC) FILETIME=[899083A0:01C86E8E] Subject: [MEXT] Home Link operation over p2p links X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello folks, Here is a draft that describes issues with the mobile node booting up on the home link over point-to-point links. It describes the issues and suggests a possible solution. http://www.ietf.org/internet-drafts/draft-devarapalli-mext-mipv6-home-link-00.txt Comments/reviews are welcome. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Feb 13 23:39:53 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 082A228CD0E; Wed, 13 Feb 2008 23:39:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.653 X-Spam-Level: X-Spam-Status: No, score=-0.653 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLyl-Vrr9F3J; Wed, 13 Feb 2008 23:39:52 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 187E528CCC4; Wed, 13 Feb 2008 23:39:52 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B176428CCEA for ; Wed, 13 Feb 2008 23:39:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqVNxcxeUr8n for ; Wed, 13 Feb 2008 23:39:50 -0800 (PST) Received: from mail.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by core3.amsl.com (Postfix) with ESMTP id 4240E28CCC6 for ; Wed, 13 Feb 2008 23:39:45 -0800 (PST) Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by mail.tcs.hut.fi (Postfix) with ESMTP id BA01C2C020D92; Thu, 14 Feb 2008 09:41:06 +0200 (EET) Date: Thu, 14 Feb 2008 09:41:06 +0200 (EET) From: Wassim Haddad To: mext@ietf.org Message-ID: MIME-Version: 1.0 Content-ID: Subject: [MEXT] I-D Action:draft-haddad-mext-enhanced-reachability-test-00.txt (fwd) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Dear all, I've submitted a new draft which deals with CoA rechability test on the HA side. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-haddad-mext-enhanced-reachability-test-00.txt Your comments are appreciated. Regards, Wassim H. _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Feb 14 00:25:58 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A28D3A706F; Thu, 14 Feb 2008 00:25:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.707 X-Spam-Level: X-Spam-Status: No, score=-2.707 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbKm7S-VkoMt; Thu, 14 Feb 2008 00:25:56 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE3AF3A7064; Thu, 14 Feb 2008 00:25:56 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 340D53A704A for ; Thu, 14 Feb 2008 00:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsEbddeCQkL5 for ; Thu, 14 Feb 2008 00:25:52 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.188]) by core3.amsl.com (Postfix) with ESMTP id 652383A7064 for ; Thu, 14 Feb 2008 00:24:58 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id i7so302795tid.25 for ; Thu, 14 Feb 2008 00:26:20 -0800 (PST) Received: by 10.150.157.11 with SMTP id f11mr369884ybe.108.1202977578309; Thu, 14 Feb 2008 00:26:18 -0800 (PST) Received: from ?172.16.1.105? ( [12.187.196.130]) by mx.google.com with ESMTPS id v26sm4339294ele.5.2008.02.14.00.26.15 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Feb 2008 00:26:17 -0800 (PST) From: RYUJI WAKIKAWA To: Julien Laganier In-Reply-To: <200802121631.35572.julien.IETF@laposte.net> References: <200802111135.44252.julien.IETF@laposte.net> <200802121631.35572.julien.IETF@laposte.net> Message-Id: <194C3FD3-7FEB-4126-8240-C1D7B6D9D0DB@gmail.com> Mime-Version: 1.0 (Apple Message framework v915) Date: Thu, 14 Feb 2008 17:26:13 +0900 X-Mailer: Apple Mail (2.915) Cc: mext@ietf.org Subject: Re: [MEXT] [Recharter.2] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien [E]Virtual Home Link configuration for Mobile IPv6 [C/E]Binding Revocation for IP Mobility [R]Generic Notification Message for Mobile IPv6 regards, ryuji On 2008/02/13, at 0:31, Julien Laganier wrote: > Folks, > > This is the next step in the recharter process. We'd like to get input > from WG participants on what should be the items included in > rechartering, what are their priorities, and who is willing to > sustain the effort. When that step is completed we will take the WG > input and discuss with our AD to move forward with deciding what to > include or not in the charter. Your input should be sent to the list > during the following two weeks, by 2008-02-26. > > Please pick from the list of items below the items you think the WG > should work on, and order them in decreasing priority (just to make > sure, first priority items goes first in the list you're making :). > > List of items: > > Binding Revocation for IP Mobility > MIPv6 home link operation in various SDOs > IP Tunneling Optimization in a Mobile Environment > Generic Notification Message for Mobile IPv6 > GRE requirements for IPv6 mobility > 4283bis to extend MN identifier to other identifiers > Mobile IPv6 Bootstrapping for the Authentication Option Protocol > Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions > Virtual Home Link configuration for Mobile IPv6 > Extend DSMIPv6 Home Network Support > > Also, please prefix each of the items in your list with the letters > E, C > and/or R if you're willing to: > > - [E]dit: Are you willing to edit the draft corresponding to the > item. > > - [C]ontribute: Are you willing to propose text for the draft. > > - [R]eview: Are you willing to review new revisions of the draft when > being asked by the chairs. > > As an example, that could be one input list: > > E MIPv6 home link operation in various SDOs > CR Binding Revocation for IP Mobility > R IP Tunneling Optimization in a Mobile Environment > > meaning that the MIPv6 home link is first priority and you volunteer > to > edit, Binding revocation is second priority and you're willing to > contribute and review, while IP tunneling optimization is third > priority and you're willing to review. > > Hope this is understandable :) > > Thanks. > > -- julien and marcello, MEXT chairs > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Feb 14 01:45:12 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ABCE28CE03; Thu, 14 Feb 2008 01:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.403 X-Spam-Level: ** X-Spam-Status: No, score=2.403 tagged_above=-999 required=5 tests=[AWL=-0.302, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_44=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8T6tK4DS08dZ; Thu, 14 Feb 2008 01:45:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8289228CDD2; Thu, 14 Feb 2008 01:45:09 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7C9228CDCB for ; Thu, 14 Feb 2008 01:45:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8kosQP0g5dy for ; Thu, 14 Feb 2008 01:45:05 -0800 (PST) Received: from szxga02-in.huawei.com (unknown [61.144.161.54]) by core3.amsl.com (Postfix) with ESMTP id 91AB028CDD2 for ; Thu, 14 Feb 2008 01:45:05 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JW8009AN354ZX@szxga02-in.huawei.com> for mext@ietf.org; Thu, 14 Feb 2008 17:46:16 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JW800L2O353DI@szxga02-in.huawei.com> for mext@ietf.org; Thu, 14 Feb 2008 17:46:16 +0800 (CST) Received: from z49950 ([10.121.33.161]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JW800EBK34ZD7@szxml04-in.huawei.com> for mext@ietf.org; Thu, 14 Feb 2008 17:46:15 +0800 (CST) Date: Thu, 14 Feb 2008 17:46:03 +0800 From: "John.zhao" In-reply-to: <200802121631.35572.julien.IETF@laposte.net> To: 'Julien Laganier' , mext@ietf.org Message-id: <008401c86eee$6e6d2e60$a864a8c0@china.huawei.com> Organization: Huawei Technologies Co., LTD. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Thread-index: AchtjNNs2xOI+DwpTlqnIQxMnecKpABXDkEQ Subject: Re: [MEXT] [Recharter.2] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: john.zhao@huawei.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org SGksSnVsaWVuIGFuZCBhbGwKCltFL0MvUl0gR1JFIHJlcXVpcmVtZW50cyBmb3IgSVB2NiBtb2Jp bGl0eQpbRS9DL1JdIEV4dGVuZCBEU01JUHY2IEhvbWUgTmV0d29yayBTdXBwb3J0CSAKW0UvQ10g QmluZGluZyBSZXZvY2F0aW9uIGZvciBJUCBNb2JpbGl0eSAKW0UvQ10gTW9iaWxlIElQdjYgQm9v dHN0cmFwcGluZyBmb3IgdGhlIEF1dGhlbnRpY2F0aW9uIE9wdGlvbiBQcm90b2NvbCAKW0MvUl0g VmlydHVhbCBIb21lIExpbmsgY29uZmlndXJhdGlvbiBmb3IgTW9iaWxlIElQdjYgCltSXSBHZW5l cmljIE5vdGlmaWNhdGlvbiBNZXNzYWdlIGZvciBNb2JpbGUgSVB2NgpbUl0gNDI4M2JpcyB0byBl eHRlbmQgTU4gaWRlbnRpZmllciB0byBvdGhlciBpZGVudGlmaWVycwoJQmVzdCBSZ2RzLApUaGFu a3MsCkpvaG4uemhhbwo+IC0tLS0t08q8/tStvP4tLS0tLQo+ILeivP7IyzogbWV4dC1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86bWV4dC1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEp1bGllbgo+IExh Z2FuaWVyCj4gt6LLzcqxvOQ6IDIwMDjE6jLUwjEyyNUgMjM6MzIKPiDK1bz+yMs6IG1leHRAaWV0 Zi5vcmcKPiDW98ziOiBbTUVYVF0gW1JlY2hhcnRlci4yXQo+IAo+IEZvbGtzLAo+IAo+IFRoaXMg aXMgdGhlIG5leHQgc3RlcCBpbiB0aGUgcmVjaGFydGVyIHByb2Nlc3MuIFdlJ2QgbGlrZSB0byBn ZXQgaW5wdXQKPiBmcm9tIFdHIHBhcnRpY2lwYW50cyBvbiB3aGF0IHNob3VsZCBiZSB0aGUgaXRl bXMgaW5jbHVkZWQgaW4KPiByZWNoYXJ0ZXJpbmcsIHdoYXQgYXJlIHRoZWlyIHByaW9yaXRpZXMs IGFuZCB3aG8gaXMgd2lsbGluZyB0bwo+IHN1c3RhaW4gdGhlIGVmZm9ydC4gV2hlbiB0aGF0IHN0 ZXAgaXMgY29tcGxldGVkIHdlIHdpbGwgdGFrZSB0aGUgV0cKPiBpbnB1dCBhbmQgZGlzY3VzcyB3 aXRoIG91ciBBRCB0byBtb3ZlIGZvcndhcmQgd2l0aCBkZWNpZGluZyB3aGF0IHRvCj4gaW5jbHVk ZSBvciBub3QgaW4gdGhlIGNoYXJ0ZXIuIFlvdXIgaW5wdXQgc2hvdWxkIGJlIHNlbnQgdG8gdGhl IGxpc3QKPiBkdXJpbmcgdGhlIGZvbGxvd2luZyB0d28gd2Vla3MsIGJ5IDIwMDgtMDItMjYuCj4g Cj4gUGxlYXNlIHBpY2sgZnJvbSB0aGUgbGlzdCBvZiBpdGVtcyBiZWxvdyB0aGUgaXRlbXMgeW91 IHRoaW5rIHRoZSBXRwo+IHNob3VsZCB3b3JrIG9uLCBhbmQgb3JkZXIgdGhlbSBpbiBkZWNyZWFz aW5nIHByaW9yaXR5IChqdXN0IHRvIG1ha2UKPiBzdXJlLCBmaXJzdCBwcmlvcml0eSBpdGVtcyBn b2VzIGZpcnN0IGluIHRoZSBsaXN0IHlvdSdyZSBtYWtpbmcgOikuCj4gCj4gTGlzdCBvZiBpdGVt czoKPiAKPiBCaW5kaW5nIFJldm9jYXRpb24gZm9yIElQIE1vYmlsaXR5Cj4gTUlQdjYgaG9tZSBs aW5rIG9wZXJhdGlvbiBpbiB2YXJpb3VzIFNET3MKPiBJUCBUdW5uZWxpbmcgT3B0aW1pemF0aW9u IGluIGEgTW9iaWxlIEVudmlyb25tZW50Cj4gR2VuZXJpYyBOb3RpZmljYXRpb24gTWVzc2FnZSBm b3IgTW9iaWxlIElQdjYKPiBHUkUgcmVxdWlyZW1lbnRzIGZvciBJUHY2IG1vYmlsaXR5Cj4gNDI4 M2JpcyB0byBleHRlbmQgTU4gaWRlbnRpZmllciB0byBvdGhlciBpZGVudGlmaWVycwo+IE1vYmls ZSBJUHY2IEJvb3RzdHJhcHBpbmcgZm9yIHRoZSBBdXRoZW50aWNhdGlvbiBPcHRpb24gUHJvdG9j b2wKPiBJbnRlcmFjdGlvbiBiZXR3ZWVuIE1vYmlsZSBJUHY2IGFuZCBJUHNlYy9JS0UgYnkgUEZf S0VZIGV4dGVuc2lvbnMKPiBWaXJ0dWFsIEhvbWUgTGluayBjb25maWd1cmF0aW9uIGZvciBNb2Jp bGUgSVB2Ngo+IEV4dGVuZCBEU01JUHY2IEhvbWUgTmV0d29yayBTdXBwb3J0Cj4gCj4gQWxzbywg cGxlYXNlIHByZWZpeCBlYWNoIG9mIHRoZSBpdGVtcyBpbiB5b3VyIGxpc3Qgd2l0aCB0aGUgbGV0 dGVycyBFLCBDCj4gYW5kL29yIFIgaWYgeW91J3JlIHdpbGxpbmcgdG86Cj4gCj4gLSBbRV1kaXQ6 IEFyZSB5b3Ugd2lsbGluZyB0byBlZGl0IHRoZSBkcmFmdCBjb3JyZXNwb25kaW5nIHRvIHRoZQo+ ICAgaXRlbS4KPiAKPiAtIFtDXW9udHJpYnV0ZTogQXJlIHlvdSB3aWxsaW5nIHRvIHByb3Bvc2Ug dGV4dCBmb3IgdGhlIGRyYWZ0Lgo+IAo+IC0gW1JdZXZpZXc6IEFyZSB5b3Ugd2lsbGluZyB0byBy ZXZpZXcgbmV3IHJldmlzaW9ucyBvZiB0aGUgZHJhZnQgd2hlbgo+ICAgYmVpbmcgYXNrZWQgYnkg dGhlIGNoYWlycy4KPiAKPiBBcyBhbiBleGFtcGxlLCB0aGF0IGNvdWxkIGJlIG9uZSBpbnB1dCBs aXN0Ogo+IAo+IEUgTUlQdjYgaG9tZSBsaW5rIG9wZXJhdGlvbiBpbiB2YXJpb3VzIFNET3MKPiBD UiBCaW5kaW5nIFJldm9jYXRpb24gZm9yIElQIE1vYmlsaXR5Cj4gUiBJUCBUdW5uZWxpbmcgT3B0 aW1pemF0aW9uIGluIGEgTW9iaWxlIEVudmlyb25tZW50Cj4gCj4gbWVhbmluZyB0aGF0IHRoZSBN SVB2NiBob21lIGxpbmsgaXMgZmlyc3QgcHJpb3JpdHkgYW5kIHlvdSB2b2x1bnRlZXIgdG8KPiBl ZGl0LCBCaW5kaW5nIHJldm9jYXRpb24gaXMgc2Vjb25kIHByaW9yaXR5IGFuZCB5b3UncmUgd2ls bGluZyB0bwo+IGNvbnRyaWJ1dGUgYW5kIHJldmlldywgd2hpbGUgSVAgdHVubmVsaW5nIG9wdGlt aXphdGlvbiBpcyB0aGlyZAo+IHByaW9yaXR5IGFuZCB5b3UncmUgd2lsbGluZyB0byByZXZpZXcu Cj4gCj4gSG9wZSB0aGlzIGlzIHVuZGVyc3RhbmRhYmxlIDopCj4gCj4gVGhhbmtzLgo+IAo+IC0t IGp1bGllbiBhbmQgbWFyY2VsbG8sIE1FWFQgY2hhaXJzCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KPiBNRVhUIG1haWxpbmcgbGlzdAo+IE1FWFRAaWV0 Zi5vcmcKPiBodHRwOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWV4dAoKCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCk1FWFQgbWFpbGluZyBs aXN0Ck1FWFRAaWV0Zi5vcmcKaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21l eHQK From mext-bounces@ietf.org Thu Feb 14 06:53:15 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1703028CF7B; Thu, 14 Feb 2008 06:53:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.316 X-Spam-Level: X-Spam-Status: No, score=-0.316 tagged_above=-999 required=5 tests=[AWL=-0.501, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4iiPUTbiFIc2; Thu, 14 Feb 2008 06:53:14 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B29E728CF57; Thu, 14 Feb 2008 06:53:11 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20C5A28CF42 for ; Thu, 14 Feb 2008 06:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3osFhTsSPyA for ; Thu, 14 Feb 2008 06:53:09 -0800 (PST) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.191]) by core3.amsl.com (Postfix) with ESMTP id 63CBB28CF57 for ; Thu, 14 Feb 2008 06:53:07 -0800 (PST) Received: by rn-out-0910.google.com with SMTP id a46so672848rne.10 for ; Thu, 14 Feb 2008 06:54:29 -0800 (PST) Received: by 10.143.1.2 with SMTP id d2mr1217321wfi.91.1203000868244; Thu, 14 Feb 2008 06:54:28 -0800 (PST) Received: by 10.142.177.9 with HTTP; Thu, 14 Feb 2008 06:54:28 -0800 (PST) Message-ID: Date: Thu, 14 Feb 2008 14:54:28 +0000 From: "George Tsirtsis" To: "Suresh Krishnan" In-Reply-To: <47B338F4.60808@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline References: <47B338F4.60808@ericsson.com> Cc: mext@ietf.org Subject: Re: [MEXT] [Fwd: I-D Action:draft-krishnan-mext-ha-redirect-00.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Suresh, Your proposal seems to be based on the fact that RFC5142 (HA-switch) is not sufficient since it only works for MNs already registered in the HA. You argue then that an HA should be able to redirect an MN during initial registration (to which I agree). So, while this sounds reasonable, when IPSEC is used to secure MIP6 signaling, would it not make more sense to get this information earlier? e.g., during the IKEv2 exchange? It is also worth noting that depending what kind of bootstrapping mechanism used the MN may already know a number of alternative HAs, in which case a BA with appropriate status (e.g., 130 Insufficient resources) would also work. Again, however, I am not saying that your suggestion is wrong, but that it is possibly applied to the wrong protocol. Thoughts? George On Wed, Feb 13, 2008 at 6:37 PM, Suresh Krishnan wrote: > Hi Folks, > We submitted a draft about redirecting MNs to other HAs for overload > prevention, load balancing or other purposes. We would appreciate any > comments and suggestions on this document. > > Thanks > Authors > > -------- Original Message -------- > Subject: I-D Action:draft-krishnan-mext-ha-redirect-00.txt > Date: Wed, 13 Feb 2008 10:30:01 -0800 (PST) > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Redirecting Binding Updates in MIPv6 > Author(s) : S. Krishnan, et al. > Filename : draft-krishnan-mext-ha-redirect-00.txt > Pages : 9 > Date : 2008-02-13 > > This document specifies a new Home Agent Redirect mechanism, where an > initially contacted Home Agent can let the Mobile Node knows that it > needs to connect to an alternate Home Agent to get mobility services > for overload prevention and/or load balancing purposes. This > document proposes a new error code for the binding acknowledgement > message and a new mobility option to be carried on the binding > acknowledgement message for this purpose. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-krishnan-mext-ha-redirect-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-krishnan-mext-ha-redirect-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-krishnan-mext-ha-redirect-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. > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Feb 14 08:23:42 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEB3928CFBB; Thu, 14 Feb 2008 08:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.173 X-Spam-Level: X-Spam-Status: No, score=-1.173 tagged_above=-999 required=5 tests=[AWL=-0.736, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTRA0i3kHvB4; Thu, 14 Feb 2008 08:23:41 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 432D33A6F47; Thu, 14 Feb 2008 08:23:41 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 741E63A6E5C for ; Thu, 14 Feb 2008 08:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neUsJZSKCo0X for ; Thu, 14 Feb 2008 08:23:38 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by core3.amsl.com (Postfix) with ESMTP id 7379C3A6F47 for ; Thu, 14 Feb 2008 08:23:37 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id d21so243335nfb.39 for ; Thu, 14 Feb 2008 08:24:58 -0800 (PST) Received: by 10.78.133.2 with SMTP id g2mr1284467hud.29.1203006297953; Thu, 14 Feb 2008 08:24:57 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id 35sm1036966nfu.12.2008.02.14.08.24.52 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Feb 2008 08:24:56 -0800 (PST) From: Julien Laganier To: mext@ietf.org Date: Thu, 14 Feb 2008 17:24:46 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <47B36D00.8020707@azairenet.com> In-Reply-To: <47B36D00.8020707@azairenet.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200802141724.48978.julien.IETF@laposte.net> Subject: Re: [MEXT] Home Link operation over p2p links X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Vijay, Thanks for submitting the draft in time! This is definitely helpful to assess the rechartering work item you proposed. I have couple of comments on your draft: > 3.1. Detecting Attachment to the Home Link > > In Mobile IPv6, a mobile node detects that it has attached to the > home link when it receives a router advertisement with the home > prefix. Some of the point-to-point links like IPsec tunnels and > PMIPv6 tunnels do not support running neighbor discovery in the > tunnels. When the home link is created by concatenating a GTP > tunnel with a PMIPv6 tunnel or an IPsec tunnel with PMIPv6 tunnels, > it becomes difficult for a router advertisement to be sent over the > concatenated tunnels. When "concatenating a GTP tunnel with a PMIPv6 tunnel", the RS can be sent through the GTP tunnel by the MN, up to the MAG. Then the MAG replies with an RA containing the Home Network Prefix, so there doesn't seem to be an issue. Am I missing something? When "concatenating an IPsec tunnel with a PMIPv6 tunnel", the MN cannot send the RS through the IPsec tunnel, and likewise, the MAG wouldn't be able to reply with an RA containing the Home Network Prefix. However, isn't the main issue at stake here the fact that IPsec "interfaces" are not fully fledged IPv6 interface, i.e. they do not support link-local addresses and multicast, etc. See Pasi's draft describing the issues and possible solution: draft-eronen-ipsec-ikev2-ipv6-config-02.txt It seems to me that if what Pasi proposes was implemented in the HA implementing IKEv2, then the issues your draft describe w.r.t. detecting home link attachment would vanish. If that is the case, wouldn't the right approach be to fix IPsec rather than extending MIPv6 because IPsec has a deficiency? > 3.2. Bootstrapping > > Mobile IPv6 bootstrapping [8] and [9] depends on the use of IKEv2 > between the mobile node and the home agent to bootstrap the MIPv6 > home address. According to RFC 3775, when the mobile node is > attached to the home link, it does not have to run IKEv1/IKEv2 > with the home agent to setup the necessary security associations. > Most often, the IKEv2 exchange is triggered by the need to send a > binding update. So if the mobile node boots up the home link, it may > not be able to use IKEv2 to bootstrap the MIPv6 home address. Purely based on RFC3775 the MN does not have to run IKE to setup SA's with HA when it is attached on its home link (But note that here we're talking about bootstrapping and that wasn't part of 3775 so we can't reason uniquely in terms of what 3775 says). However, the only ways for a MN to figure out that it is attached on its home link are either to compare its home address with the prefix advertized on-link in RA's. In the case of bootstrapping the MN does not know its home address before hand, thus it can't conclude that it is home before it acquire a home address via bootstrapping. By default it will thus assume it is not at home and initiate bootstrapping. Hence there is a need to send a BU to get the Home Address. As you note "the IKEv2 exchange is triggered by the need to send a binding update", thus I assume IKEv2 would be triggered to acquire an home address. Then the MN can conclude it is home (because HoA included in RA's PIO) and drop the IKE and IPsec association. It is true that it isn't written down but to me it looks logical that an implementor would follow these steps. Do you think such a procedure is inappropriate? > The IKEv2 exchange is only used to bootstrap the MIPv6 home > address. The DS-MIPv6 [11] IPv4 home address is obtained by the > mobile node using the exchange of Binding Update and Binding > Acknowledgement with the home agent. The Mobile Network Prefixes > required for mobile router operation, as described in [10], may also > obtained using the Binding Update and Binding Acknowledgement > exchange between the mobile router and the home agent. This is > specified in [12]. According to the current specifications, the > mobile node (or the mobile router) does not send a Binding Update to > the home agent when it is attached to the home link. Regarding IPv4 home address allocation, the same reasoning applies as with bootstrapping of the MIPv6 home address above: there would be a need to send a BU (to get the IPv4 HoA) thus IKE would be triggered, and dropped down once the v4 address is known. Regarding Mobile Network Prefix Assignment, there's no agreement yet whether this is done with extensions to BUs and BAs, or using DHCP. If it was done using DHCP it could work provided that DHCP requests can be sent thru the point-to-point link. Francis has proposed a method where a DHCP relay is collocated on the MR, and thus only unicast DHCP messages have to be sent and received. Therefore it would work well on a point-to-point link. > Since it is not typical for the mobile node to initiate an IKEv2 > exchange with its home agent and not possible to send a Binding > Update from the home link, there is a need for other bootstrapping > mechanisms that would work across all point-to-point home links. > However, this would result in the mobile node using different > bootstrapping mechanisms depending on the point-to-point that > appears as the home link. The mobile node would also end with using > different bootstrapping mechanisms when attached to the home link and > when attached to the visited link. To avoid this, it would be > desirable to use the same bootstrapping mechanisms irrespective of > the point-to-point link that appears as the home link and/or the > visited link. But it looks like the same IKEv2 based bootstrapping mechanism is used in everycase, it is just that once the MN figures out it is at home it can drop the IKE and IPsec SA's. > 3.4. Forwarding at the Home Agent > > According to RFC 3775, when the mobile node is attached to the > home link, it behaves as a regular IPv6 host and is able to > send/receive packets directly without going through the home agent. > In case the home agent needs to send any packet to the mobile node, > it has a valid neighbor cache entry for the mobile node which is then > used to forward packets to the mobile node. > > When point-to-point links are used a home links, then the packets > meant for the mobile node always reach the home agent first and > are then forwarded to the mobile node. However, the home agent > cannot construct a neighbor cache entry for the mobile node, since > most of the point-to-point links mentioned in Section 1 do not > support sending neighbor solicitation and receiving neighbor > advertisement messages. Again, if IPsec was fixed as in Pasi's proposal then it would work just fine. Other point-to-point links happily carry multicast traffic. > 3.5. Indicating Service Selection Option > > A new extension, the Service Selection for Mobile IPv6, has been > specified in [13] for the mobile node to indicate to the home > agent which service it wants to access. The Service Selection option > is sent in the Binding Update. When the mobile node boots up in the > home link, it won't be able to indicate the service it wants to > access to the home agent, since the Binding Update message is not > sent from the home link. > > It is possible to indicate the Service the mobile node wants to > access in the IKEv2 exchange with the home agent. The service > information is encoded in the IDr payload in the IKEv2 exchange. > However, this requires the mobile node to initiate an IKEv2 > exchange with the mobile node from the home link. According to RFC > 3775, the mobile node does not have to initiate an IKEv2 exchange > when it boots up in the home link. Same goes here than for bootstrapping. There's indeed a need to send a BU, so does the MN, then IKEv2 kicks in, BU is sent out, and no problem. In conclusion I am not sure there's a clear case to extend MIPv6. Maybe there's some room for a document clarifying how implementation should behave with bootstrapping while on the home link. What do you think? Best, --julien On Wednesday 13 February 2008, Vijay Devarapalli wrote: > Hello folks, > > Here is a draft that describes issues with the mobile node > booting up on the home link over point-to-point links. It > describes the issues and suggests a possible solution. > > http://www.ietf.org/internet-drafts/draft-devarapalli-mext-mipv6-home >-link-00.txt > > Comments/reviews are welcome. > > Vijay > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Feb 14 08:50:17 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDF913A70A3; Thu, 14 Feb 2008 08:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.964 X-Spam-Level: X-Spam-Status: No, score=-102.964 tagged_above=-999 required=5 tests=[AWL=-0.527, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bi+PqMJO3YQy; Thu, 14 Feb 2008 08:50:16 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 568933A702B; Thu, 14 Feb 2008 08:49:18 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEECC28CF44 for ; Thu, 14 Feb 2008 08:49:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXc+XyPBLhRw for ; Thu, 14 Feb 2008 08:49:15 -0800 (PST) Received: from g5t0009.atlanta.hp.com (g5t0009.atlanta.hp.com [15.192.0.46]) by core3.amsl.com (Postfix) with ESMTP id 2BAF33A6ACD for ; Thu, 14 Feb 2008 08:48:46 -0800 (PST) Received: from g5t0009.atlanta.hp.com (localhost.localdomain [127.0.0.1]) by receive-from-antispam-filter (Postfix) with SMTP id D4AD13064D; Thu, 14 Feb 2008 16:50:07 +0000 (UTC) Received: from smtp1.fc.hp.com (smtp.fc.hp.com [15.15.136.127]) by g5t0009.atlanta.hp.com (Postfix) with ESMTP id AA4FB30642; Thu, 14 Feb 2008 16:50:07 +0000 (UTC) Received: from [16.116.96.52] (wrx.zko.hp.com [16.116.96.52]) by smtp1.fc.hp.com (Postfix) with ESMTP id 308681E57AF; Thu, 14 Feb 2008 16:50:07 +0000 (UTC) Message-ID: <47B4713E.5060009@hp.com> Date: Thu, 14 Feb 2008 11:50:06 -0500 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: Julien Laganier References: <200802111135.44252.julien.IETF@laposte.net> <200802121631.35572.julien.IETF@laposte.net> In-Reply-To: <200802121631.35572.julien.IETF@laposte.net> Cc: mext@ietf.org Subject: Re: [MEXT] [Recharter.2] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien, My input. [E]Generic Notification Message for Mobile IPv6 [CR]Virtual Home Link configuration for Mobile IPv6 [CR]Binding Revocation for IP Mobility [R] Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions [R] IP Tunneling Optimization in a Mobile Environment -Brian Julien Laganier wrote: > Folks, > > This is the next step in the recharter process. We'd like to get input > from WG participants on what should be the items included in > rechartering, what are their priorities, and who is willing to > sustain the effort. When that step is completed we will take the WG > input and discuss with our AD to move forward with deciding what to > include or not in the charter. Your input should be sent to the list > during the following two weeks, by 2008-02-26. > > Please pick from the list of items below the items you think the WG > should work on, and order them in decreasing priority (just to make > sure, first priority items goes first in the list you're making :). > > List of items: > > Binding Revocation for IP Mobility > MIPv6 home link operation in various SDOs > IP Tunneling Optimization in a Mobile Environment > Generic Notification Message for Mobile IPv6 > GRE requirements for IPv6 mobility > 4283bis to extend MN identifier to other identifiers > Mobile IPv6 Bootstrapping for the Authentication Option Protocol > Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions > Virtual Home Link configuration for Mobile IPv6 > Extend DSMIPv6 Home Network Support > > Also, please prefix each of the items in your list with the letters E, C > and/or R if you're willing to: > > - [E]dit: Are you willing to edit the draft corresponding to the > item. > > - [C]ontribute: Are you willing to propose text for the draft. > > - [R]eview: Are you willing to review new revisions of the draft when > being asked by the chairs. > > As an example, that could be one input list: > > E MIPv6 home link operation in various SDOs > CR Binding Revocation for IP Mobility > R IP Tunneling Optimization in a Mobile Environment > > meaning that the MIPv6 home link is first priority and you volunteer to > edit, Binding revocation is second priority and you're willing to > contribute and review, while IP tunneling optimization is third > priority and you're willing to review. > > Hope this is understandable :) > > Thanks. > > -- julien and marcello, MEXT chairs > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Feb 14 08:56:54 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6019828CFF8; Thu, 14 Feb 2008 08:56:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[AWL=-0.961, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWdYFDtY5tbH; Thu, 14 Feb 2008 08:56:53 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1874B28CFB8; Thu, 14 Feb 2008 08:56:53 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5EAE28CFAF for ; Thu, 14 Feb 2008 08:56:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXDiG5ESkoYW for ; Thu, 14 Feb 2008 08:56:50 -0800 (PST) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id 7A88428CFAC for ; Thu, 14 Feb 2008 08:56:50 -0800 (PST) Received: from [127.0.0.1] ([98.207.82.216]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Feb 2008 08:58:10 -0800 Message-ID: <47B4731B.8000702@azairenet.com> Date: Thu, 14 Feb 2008 08:58:03 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: George Tsirtsis References: <47B338F4.60808@ericsson.com> In-Reply-To: X-OriginalArrivalTime: 14 Feb 2008 16:58:10.0218 (UTC) FILETIME=[C73F40A0:01C86F2A] Cc: mext@ietf.org Subject: Re: [MEXT] [Fwd: I-D Action:draft-krishnan-mext-ha-redirect-00.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org George Tsirtsis wrote: > Hi Suresh, > > Your proposal seems to be based on the fact that RFC5142 (HA-switch) > is not sufficient since it only works for MNs already registered in > the HA. You argue then that an HA should be able to redirect an MN > during initial registration (to which I agree). > So, while this sounds reasonable, when IPSEC is used to secure MIP6 > signaling, would it not make more sense to get this information > earlier? e.g., during the IKEv2 exchange? > > It is also worth noting that depending what kind of bootstrapping > mechanism used the MN may already know a number of alternative HAs, in > which case a BA with appropriate status (e.g., 130 Insufficient > resources) would also work. > > Again, however, I am not saying that your suggestion is wrong, but > that it is possibly applied to the wrong protocol. > > Thoughts? Agree. When RFC 5026 was being standardized, there was proposal to re-direct the mobile node during the IKEv2 exchange using IKEv2 anycast addresses. There were some issues found with the mechanism during the IESG review. It was about the destination address on the outgoing IKE_SA_INIT (anycast address) not matching the source address of the IKE_SA_INIT response (unicast address of the selected HA). Firewalls or NATs could drop these packets. So it was removed from the document during the IESG review. In some offline discussions, it was decided to move that mechanism to a separate draft and also introduce an explicit REDIRECT payload in the IKE_SA_INIT response from an anycast address. I was supposed to have submitted this document months ago, but due to various reasons, I haven't yet. I am planning to submit it by this Monday. Vijay > George > > On Wed, Feb 13, 2008 at 6:37 PM, Suresh Krishnan > wrote: >> Hi Folks, >> We submitted a draft about redirecting MNs to other HAs for overload >> prevention, load balancing or other purposes. We would appreciate any >> comments and suggestions on this document. >> >> Thanks >> Authors >> >> -------- Original Message -------- >> Subject: I-D Action:draft-krishnan-mext-ha-redirect-00.txt >> Date: Wed, 13 Feb 2008 10:30:01 -0800 (PST) >> From: Internet-Drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : Redirecting Binding Updates in MIPv6 >> Author(s) : S. Krishnan, et al. >> Filename : draft-krishnan-mext-ha-redirect-00.txt >> Pages : 9 >> Date : 2008-02-13 >> >> This document specifies a new Home Agent Redirect mechanism, where an >> initially contacted Home Agent can let the Mobile Node knows that it >> needs to connect to an alternate Home Agent to get mobility services >> for overload prevention and/or load balancing purposes. This >> document proposes a new error code for the binding acknowledgement >> message and a new mobility option to be carried on the binding >> acknowledgement message for this purpose. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-krishnan-mext-ha-redirect-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-krishnan-mext-ha-redirect-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-krishnan-mext-ha-redirect-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. >> >> >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> http://www.ietf.org/mailman/listinfo/mext >> >> > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Feb 14 09:26:36 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AC313A7096; Thu, 14 Feb 2008 09:26:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.186 X-Spam-Level: X-Spam-Status: No, score=-0.186 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tj7I7jTvkyvt; Thu, 14 Feb 2008 09:26:34 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E05803A6887; Thu, 14 Feb 2008 09:26:34 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92E163A68F3 for ; Thu, 14 Feb 2008 09:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pth1oLDS-oJr for ; Thu, 14 Feb 2008 09:26:32 -0800 (PST) Received: from mxs2.siemens.at (mxs2.siemens.at [194.138.12.133]) by core3.amsl.com (Postfix) with ESMTP id 771F23A702B for ; Thu, 14 Feb 2008 09:26:31 -0800 (PST) Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs2.siemens.at with ESMTP id m1EHRvvW028027; Thu, 14 Feb 2008 18:27:57 +0100 Received: from nets138a.ww300.siemens.net ([158.226.129.97]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id m1EHRliG027422; Thu, 14 Feb 2008 18:27:50 +0100 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Feb 2008 18:27:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 14 Feb 2008 18:27:34 +0100 Message-ID: <3C31CDD06342EA4A8137716247B1CD680368AD63@zagh223a.ww300.siemens.net> In-Reply-To: <200802141724.48978.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Home Link operation over p2p links Thread-Index: AchvJnzWdY3+FCK8TrSrWeGELxxR+QABe6jQ References: <47B36D00.8020707@azairenet.com> <200802141724.48978.julien.IETF@laposte.net> From: "Premec, Domagoj" To: "Julien Laganier" , X-OriginalArrivalTime: 14 Feb 2008 17:27:48.0523 (UTC) FILETIME=[EB330FB0:01C86F2E] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::080214182757-0AEA2BB0-166F3524/0-0/0-15 X-purgate-size: 11405/999999 Subject: Re: [MEXT] Home Link operation over p2p links X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien, Vijay, > In the case of bootstrapping the MN does not know its home > address before hand, thus it can't conclude that it is home > before it acquire a home address via bootstrapping. > > By default it will thus assume it is not at home and initiate > bootstrapping. Hence there is a need to send a BU to get the > Home Address. As you note "the IKEv2 exchange is triggered by > the need to send a binding update", thus I assume IKEv2 would > be triggered to acquire an home address. > > Then the MN can conclude it is home (because HoA included in > RA's PIO) and drop the IKE and IPsec association. Another way how a MN could detect it is on its home link is by using DHCP: if the Home network prefix in Home Network Information option matches the prefix in RA's PIO then the MN is at home link. This would avoid the overhead of setting up the IKE SA. > > The IKEv2 exchange is only used to bootstrap the MIPv6 home > > address. The DS-MIPv6 [11] IPv4 home address is obtained by > the mobile > > node using the exchange of Binding Update and Binding > Acknowledgement > > with the home agent. IPv4 HoA could be obtained via IKEv2 exchange in the same way as IPv6 HoA. domagoj > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Julien Laganier > Sent: 14. veljaca 2008 17:25 > To: mext@ietf.org > Subject: Re: [MEXT] Home Link operation over p2p links > > Hello Vijay, > > Thanks for submitting the draft in time! This is definitely > helpful to assess the rechartering work item you proposed. > > > > I have couple of comments on your draft: > > > 3.1. Detecting Attachment to the Home Link > > > > In Mobile IPv6, a mobile node detects that it has attached to the > > home link when it receives a router advertisement with the home > > prefix. Some of the point-to-point links like IPsec tunnels and > > PMIPv6 tunnels do not support running neighbor discovery in the > > tunnels. When the home link is created by concatenating a GTP > > tunnel with a PMIPv6 tunnel or an IPsec tunnel with PMIPv6 > tunnels, it > > becomes difficult for a router advertisement to be sent over the > > concatenated tunnels. > > When "concatenating a GTP tunnel with a PMIPv6 tunnel", the > RS can be sent through the GTP tunnel by the MN, up to the > MAG. Then the MAG replies with an RA containing the Home > Network Prefix, so there doesn't seem to be an issue. Am I > missing something? > > When "concatenating an IPsec tunnel with a PMIPv6 tunnel", > the MN cannot send the RS through the IPsec tunnel, and > likewise, the MAG wouldn't be able to reply with an RA > containing the Home Network Prefix. However, isn't the main > issue at stake here the fact that IPsec "interfaces" are not > fully fledged IPv6 interface, i.e. they do not support > link-local addresses and multicast, etc. See Pasi's draft > describing the issues and possible solution: > > draft-eronen-ipsec-ikev2-ipv6-config-02.txt > > It seems to me that if what Pasi proposes was implemented in > the HA implementing IKEv2, then the issues your draft describe w.r.t. > detecting home link attachment would vanish. If that is the > case, wouldn't the right approach be to fix IPsec rather than > extending MIPv6 because IPsec has a deficiency? > > > 3.2. Bootstrapping > > > > Mobile IPv6 bootstrapping [8] and [9] depends on the use of IKEv2 > > between the mobile node and the home agent to bootstrap the MIPv6 > > home address. According to RFC 3775, when the mobile node is > > attached to the home link, it does not have to run > IKEv1/IKEv2 with > > the home agent to setup the necessary security associations. > > Most often, the IKEv2 exchange is triggered by the need to send a > > binding update. So if the mobile node boots up the home > link, it may > > not be able to use IKEv2 to bootstrap the MIPv6 home address. > > Purely based on RFC3775 the MN does not have to run IKE to > setup SA's with HA when it is attached on its home link (But > note that here we're talking about bootstrapping and that > wasn't part of 3775 so we can't reason uniquely in terms of > what 3775 says). However, the only ways for a MN to figure > out that it is attached on its home link are either to > compare its home address with the prefix advertized on-link in RA's. > > In the case of bootstrapping the MN does not know its home > address before hand, thus it can't conclude that it is home > before it acquire a home address via bootstrapping. > > By default it will thus assume it is not at home and initiate > bootstrapping. Hence there is a need to send a BU to get the > Home Address. As you note "the IKEv2 exchange is triggered by > the need to send a binding update", thus I assume IKEv2 would > be triggered to acquire an home address. > > Then the MN can conclude it is home (because HoA included in > RA's PIO) and drop the IKE and IPsec association. > > It is true that it isn't written down but to me it looks > logical that an implementor would follow these steps. Do you > think such a procedure is inappropriate? > > > The IKEv2 exchange is only used to bootstrap the MIPv6 home > > address. The DS-MIPv6 [11] IPv4 home address is obtained by > the mobile > > node using the exchange of Binding Update and Binding > Acknowledgement > > with the home agent. The Mobile Network Prefixes required > for mobile > > router operation, as described in [10], may also obtained using the > > Binding Update and Binding Acknowledgement exchange between > the mobile > > router and the home agent. This is specified in [12]. According to > > the current specifications, the mobile node (or the mobile router) > > does not send a Binding Update to the home agent when it is > attached > > to the home link. > > Regarding IPv4 home address allocation, the same reasoning > applies as with bootstrapping of the MIPv6 home address > above: there would be a need to send a BU (to get the IPv4 > HoA) thus IKE would be triggered, and dropped down once the > v4 address is known. > > Regarding Mobile Network Prefix Assignment, there's no > agreement yet whether this is done with extensions to BUs and > BAs, or using DHCP. If it was done using DHCP it could work > provided that DHCP requests can be sent thru the > point-to-point link. Francis has proposed a method where a > DHCP relay is collocated on the MR, and thus only unicast > DHCP messages have to be sent and received. Therefore it > would work well on a point-to-point link. > > > Since it is not typical for the mobile node to initiate an IKEv2 > > exchange with its home agent and not possible to send a Binding > > Update from the home link, there is a need for other > bootstrapping > > mechanisms that would work across all point-to-point home links. > > However, this would result in the mobile node using different > > bootstrapping mechanisms depending on the point-to-point that > > appears as the home link. The mobile node would also end > with using > > different bootstrapping mechanisms when attached to the > home link and > > when attached to the visited link. To avoid this, it would be > > desirable to use the same bootstrapping mechanisms > irrespective of the > > point-to-point link that appears as the home link and/or > the visited > > link. > > But it looks like the same IKEv2 based bootstrapping > mechanism is used in everycase, it is just that once the MN > figures out it is at home it can drop the IKE and IPsec SA's. > > > 3.4. Forwarding at the Home Agent > > > > According to RFC 3775, when the mobile node is attached > to the home > > link, it behaves as a regular IPv6 host and is able to send/receive > > packets directly without going through the home agent. > > In case the home agent needs to send any packet to the > mobile node, it > > has a valid neighbor cache entry for the mobile node which is then > > used to forward packets to the mobile node. > > > > When point-to-point links are used a home links, then the packets > > meant for the mobile node always reach the home agent > first and are > > then forwarded to the mobile node. However, the home agent cannot > > construct a neighbor cache entry for the mobile node, since most of > > the point-to-point links mentioned in Section 1 do not > support sending > > neighbor solicitation and receiving neighbor advertisement messages. > > Again, if IPsec was fixed as in Pasi's proposal then it would > work just fine. Other point-to-point links happily carry > multicast traffic. > > > 3.5. Indicating Service Selection Option > > > > A new extension, the Service Selection for Mobile IPv6, has been > > specified in [13] for the mobile node to indicate to the > home agent > > which service it wants to access. The Service Selection option is > > sent in the Binding Update. When the mobile node boots up > in the home > > link, it won't be able to indicate the service it wants to > access to > > the home agent, since the Binding Update message is not > sent from the > > home link. > > > > It is possible to indicate the Service the mobile node wants to > > access in the IKEv2 exchange with the home agent. The service > > information is encoded in the IDr payload in the IKEv2 exchange. > > However, this requires the mobile node to initiate an IKEv2 > > exchange with the mobile node from the home link. According to RFC > > 3775, the mobile node does not have to initiate an IKEv2 > exchange when > > it boots up in the home link. > > Same goes here than for bootstrapping. There's indeed a need > to send a BU, so does the MN, then IKEv2 kicks in, BU is sent > out, and no problem. > > In conclusion I am not sure there's a clear case to extend > MIPv6. Maybe there's some room for a document clarifying how > implementation should behave with bootstrapping while on the > home link. > > What do you think? > > Best, > > --julien > > On Wednesday 13 February 2008, Vijay Devarapalli wrote: > > Hello folks, > > > > Here is a draft that describes issues with the mobile node > booting up > > on the home link over point-to-point links. It describes the issues > > and suggests a possible solution. > > > > > http://www.ietf.org/internet-drafts/draft-devarapalli-mext-mipv6-home > >-link-00.txt > > > > Comments/reviews are welcome. > > > > Vijay > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > http://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Feb 14 10:36:30 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 847063A680D; Thu, 14 Feb 2008 10:36:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.206 X-Spam-Level: X-Spam-Status: No, score=-1.206 tagged_above=-999 required=5 tests=[AWL=-0.769, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdO7eDaZZRRc; Thu, 14 Feb 2008 10:36:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEC913A6915; Thu, 14 Feb 2008 10:36:25 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FC893A6915 for ; Thu, 14 Feb 2008 10:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VFUHtH6w+TD for ; Thu, 14 Feb 2008 10:36:23 -0800 (PST) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id BEB3F3A6871 for ; Thu, 14 Feb 2008 10:36:22 -0800 (PST) Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Feb 2008 10:37:44 -0800 Message-ID: <47B48A76.3090007@azairenet.com> Date: Thu, 14 Feb 2008 10:37:42 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Julien Laganier References: <47B36D00.8020707@azairenet.com> <200802141724.48978.julien.IETF@laposte.net> In-Reply-To: <200802141724.48978.julien.IETF@laposte.net> X-OriginalArrivalTime: 14 Feb 2008 18:37:44.0655 (UTC) FILETIME=[B049FDF0:01C86F38] Cc: mext@ietf.org Subject: Re: [MEXT] Home Link operation over p2p links X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien, Thanks for reviewing the document. A few high level comments first. - When the home agent receives a Binding Update from a mobile node on the home link, it is treated as a de-registration BU. This is according to RFC 3775 and has not been updated by any spec. When the home agent receives this BU from the mobile node, if it does not have a valid binding cache entry, it responds with the status 133 (Not home agent for this mobile node) in the binding ack. When the mobile node boots up in the point-to-point home link, the home agent does not have a valid binding cache entry for the mobile node. The DS-MIPv6 IPv4 home address and Mobile Network prefixes will not be sent in the binding ack, since the Binding Update is seen as a failed one. This is one of the reasons why we introduced a new flag in the Binding Update. - I am aware of Pasi's draft on making IPsec tunnels look like regular IPv6 links. It might be a good idea, but the problem is that this draft has no "home" right now. Not sure if it will get standardized in the time frame we are looking at. Some of the architectures quoted in the draft are supposed to be finalized this year. - Regarding the mobile router using DHCPv6 prefix delegation to acquire the mobile network prefixes when at home, there are some issues. Since the mobile router is reachable only over the p2p link, the home agent becomes the default router where all the packets meant for the mobile router's mobile network prefixes arrive. The home agent according to RFC 3963 does not create forwarding entries for the mobile router prefixes until it receives a Binding Update from the mobile router with the prefixes in the message. The home agent does not advertise reachability for the mobile network prefixes either until there is a valid binding cache entry for the mobile router. - Regarding the solution proposed in the draft, if it turns out that we can resolve all the issues without having to introduce a new flag in the Binding Update, that is fine with me. I am not going to respond in detail to your comments below, yet. I want to check if you agree with the comments above first. Vijay Julien Laganier wrote: > Hello Vijay, > > Thanks for submitting the draft in time! This is definitely helpful to > assess the rechartering work item you proposed. > > > > I have couple of comments on your draft: > >> 3.1. Detecting Attachment to the Home Link >> >> In Mobile IPv6, a mobile node detects that it has attached to the >> home link when it receives a router advertisement with the home >> prefix. Some of the point-to-point links like IPsec tunnels and >> PMIPv6 tunnels do not support running neighbor discovery in the >> tunnels. When the home link is created by concatenating a GTP >> tunnel with a PMIPv6 tunnel or an IPsec tunnel with PMIPv6 tunnels, >> it becomes difficult for a router advertisement to be sent over the >> concatenated tunnels. > > When "concatenating a GTP tunnel with a PMIPv6 tunnel", the RS can be > sent through the GTP tunnel by the MN, up to the MAG. Then the MAG > replies with an RA containing the Home Network Prefix, so there doesn't > seem to be an issue. Am I missing something? > > When "concatenating an IPsec tunnel with a PMIPv6 tunnel", the MN cannot > send the RS through the IPsec tunnel, and likewise, the MAG wouldn't be > able to reply with an RA containing the Home Network Prefix. However, > isn't the main issue at stake here the fact that IPsec "interfaces" are > not fully fledged IPv6 interface, i.e. they do not support link-local > addresses and multicast, etc. See Pasi's draft describing the issues > and possible solution: > > draft-eronen-ipsec-ikev2-ipv6-config-02.txt > > It seems to me that if what Pasi proposes was implemented in the HA > implementing IKEv2, then the issues your draft describe w.r.t. > detecting home link attachment would vanish. If that is the case, > wouldn't the right approach be to fix IPsec rather than extending MIPv6 > because IPsec has a deficiency? > >> 3.2. Bootstrapping >> >> Mobile IPv6 bootstrapping [8] and [9] depends on the use of IKEv2 >> between the mobile node and the home agent to bootstrap the MIPv6 >> home address. According to RFC 3775, when the mobile node is >> attached to the home link, it does not have to run IKEv1/IKEv2 >> with the home agent to setup the necessary security associations. >> Most often, the IKEv2 exchange is triggered by the need to send a >> binding update. So if the mobile node boots up the home link, it may >> not be able to use IKEv2 to bootstrap the MIPv6 home address. > > Purely based on RFC3775 the MN does not have to run IKE to setup SA's > with HA when it is attached on its home link (But note that here we're > talking about bootstrapping and that wasn't part of 3775 so we can't > reason uniquely in terms of what 3775 says). However, the only ways for > a MN to figure out that it is attached on its home link are either to > compare its home address with the prefix advertized on-link in RA's. > > In the case of bootstrapping the MN does not know its home address > before hand, thus it can't conclude that it is home before it acquire a > home address via bootstrapping. > > By default it will thus assume it is not at home and initiate > bootstrapping. Hence there is a need to send a BU to get the Home > Address. As you note "the IKEv2 exchange is triggered by the need to > send a binding update", thus I assume IKEv2 would be triggered to > acquire an home address. > > Then the MN can conclude it is home (because HoA included in RA's PIO) > and drop the IKE and IPsec association. > > It is true that it isn't written down but to me it looks logical that an > implementor would follow these steps. Do you think such a procedure is > inappropriate? > >> The IKEv2 exchange is only used to bootstrap the MIPv6 home >> address. The DS-MIPv6 [11] IPv4 home address is obtained by the >> mobile node using the exchange of Binding Update and Binding >> Acknowledgement with the home agent. The Mobile Network Prefixes >> required for mobile router operation, as described in [10], may also >> obtained using the Binding Update and Binding Acknowledgement >> exchange between the mobile router and the home agent. This is >> specified in [12]. According to the current specifications, the >> mobile node (or the mobile router) does not send a Binding Update to >> the home agent when it is attached to the home link. > > Regarding IPv4 home address allocation, the same reasoning applies as > with bootstrapping of the MIPv6 home address above: there would be a > need to send a BU (to get the IPv4 HoA) thus IKE would be triggered, > and dropped down once the v4 address is known. > > Regarding Mobile Network Prefix Assignment, there's no agreement yet > whether this is done with extensions to BUs and BAs, or using DHCP. If > it was done using DHCP it could work provided that DHCP requests can be > sent thru the point-to-point link. Francis has proposed a method where > a DHCP relay is collocated on the MR, and thus only unicast DHCP > messages have to be sent and received. Therefore it would work well on > a point-to-point link. > >> Since it is not typical for the mobile node to initiate an IKEv2 >> exchange with its home agent and not possible to send a Binding >> Update from the home link, there is a need for other bootstrapping >> mechanisms that would work across all point-to-point home links. >> However, this would result in the mobile node using different >> bootstrapping mechanisms depending on the point-to-point that >> appears as the home link. The mobile node would also end with using >> different bootstrapping mechanisms when attached to the home link and >> when attached to the visited link. To avoid this, it would be >> desirable to use the same bootstrapping mechanisms irrespective of >> the point-to-point link that appears as the home link and/or the >> visited link. > > But it looks like the same IKEv2 based bootstrapping mechanism is used > in everycase, it is just that once the MN figures out it is at home it > can drop the IKE and IPsec SA's. > >> 3.4. Forwarding at the Home Agent >> >> According to RFC 3775, when the mobile node is attached to the >> home link, it behaves as a regular IPv6 host and is able to >> send/receive packets directly without going through the home agent. >> In case the home agent needs to send any packet to the mobile node, >> it has a valid neighbor cache entry for the mobile node which is then >> used to forward packets to the mobile node. >> >> When point-to-point links are used a home links, then the packets >> meant for the mobile node always reach the home agent first and >> are then forwarded to the mobile node. However, the home agent >> cannot construct a neighbor cache entry for the mobile node, since >> most of the point-to-point links mentioned in Section 1 do not >> support sending neighbor solicitation and receiving neighbor >> advertisement messages. > > Again, if IPsec was fixed as in Pasi's proposal then it would work just > fine. Other point-to-point links happily carry multicast traffic. > >> 3.5. Indicating Service Selection Option >> >> A new extension, the Service Selection for Mobile IPv6, has been >> specified in [13] for the mobile node to indicate to the home >> agent which service it wants to access. The Service Selection option >> is sent in the Binding Update. When the mobile node boots up in the >> home link, it won't be able to indicate the service it wants to >> access to the home agent, since the Binding Update message is not >> sent from the home link. >> >> It is possible to indicate the Service the mobile node wants to >> access in the IKEv2 exchange with the home agent. The service >> information is encoded in the IDr payload in the IKEv2 exchange. >> However, this requires the mobile node to initiate an IKEv2 >> exchange with the mobile node from the home link. According to RFC >> 3775, the mobile node does not have to initiate an IKEv2 exchange >> when it boots up in the home link. > > Same goes here than for bootstrapping. There's indeed a need to send a > BU, so does the MN, then IKEv2 kicks in, BU is sent out, and no > problem. > > In conclusion I am not sure there's a clear case to extend MIPv6. Maybe > there's some room for a document clarifying how implementation should > behave with bootstrapping while on the home link. > > What do you think? > > Best, > > --julien > > On Wednesday 13 February 2008, Vijay Devarapalli wrote: >> Hello folks, >> >> Here is a draft that describes issues with the mobile node >> booting up on the home link over point-to-point links. It >> describes the issues and suggests a possible solution. >> >> http://www.ietf.org/internet-drafts/draft-devarapalli-mext-mipv6-home >> -link-00.txt >> >> Comments/reviews are welcome. >> >> Vijay >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> http://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Feb 14 11:37:52 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5318E3A70FA; Thu, 14 Feb 2008 11:37:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.707 X-Spam-Level: X-Spam-Status: No, score=-0.707 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTOs+H2Q1ylB; Thu, 14 Feb 2008 11:37:45 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 367413A7086; Thu, 14 Feb 2008 11:37:45 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 108923A70C6 for ; Thu, 14 Feb 2008 11:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-fmx-+s0-5F for ; Thu, 14 Feb 2008 11:37:43 -0800 (PST) Received: from moog.chdir.org (unknown [IPv6:2002:58bf:2aa0:339b:f654:e10e:317f:e6fa]) by core3.amsl.com (Postfix) with ESMTP id 368AF3A70C0 for ; Thu, 14 Feb 2008 11:37:43 -0800 (PST) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1JPjv9-0000V5-2A; Thu, 14 Feb 2008 20:38:59 +0100 From: arno@natisbad.org (Arnaud Ebalard) To: Julien Laganier References: <200802111135.44252.julien.IETF@laposte.net> <200802121631.35572.julien.IETF@laposte.net> X-GnuPG-Key: 0x047A5026 X-Hashcash: 1:20:080214:julien.ietf@laposte.net::RF5Ds09lZUXReKhL:000000000000000000000000000000000000005a0W X-Hashcash: 1:20:080214:mext@ietf.org::NUlMCnc5TRCyKixE:000091E1 Date: Thu, 14 Feb 2008 20:38:54 +0100 In-Reply-To: <200802121631.35572.julien.IETF@laposte.net> (Julien Laganier's message of "Tue, 12 Feb 2008 16:31:35 +0100") Message-ID: <871w7fuy41.fsf@natisbad.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] [Recharter.2] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, RC Binding Revocation for IP Mobility R MIPv6 home link operation in various SDOs RC IP Tunneling Optimization in a Mobile Environment R Generic Notification Message for Mobile IPv6 GRE requirements for IPv6 mobility 4283bis to extend MN identifier to other identifiers Mobile IPv6 Bootstrapping for the Authentication Option Protocol E Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions R Virtual Home Link configuration for Mobile IPv6 Extend DSMIPv6 Home Network Support Cheers, a+ _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Feb 14 12:25:29 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 127DA28CE9A; Thu, 14 Feb 2008 12:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=-2.024, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eejdgNeYlZOY; Thu, 14 Feb 2008 12:25:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 822CE28CF7A; Thu, 14 Feb 2008 12:25:27 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAE413A70AE for ; Thu, 14 Feb 2008 12:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXyNqlKQ+yMH for ; Thu, 14 Feb 2008 12:25:24 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 5BE2628D097 for ; Thu, 14 Feb 2008 12:25:14 -0800 (PST) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m1EKQYSP017371; Thu, 14 Feb 2008 14:26:35 -0600 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Feb 2008 14:26:34 -0600 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Feb 2008 14:26:33 -0600 Message-ID: <47B4A47B.5020708@ericsson.com> Date: Thu, 14 Feb 2008 15:28:43 -0500 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Julien Laganier References: <200802111135.44252.julien.IETF@laposte.net> <200802121631.35572.julien.IETF@laposte.net> In-Reply-To: <200802121631.35572.julien.IETF@laposte.net> X-OriginalArrivalTime: 14 Feb 2008 20:26:33.0848 (UTC) FILETIME=[E3FDC780:01C86F47] Cc: mext@ietf.org Subject: Re: [MEXT] [Recharter.2] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien, Here is my ordered list R Binding Revocation for IP Mobility R GRE requirements for IPv6 mobility CR 4283bis to extend MN identifier to other identifiers CR IP Tunneling Optimization in a Mobile Environment R Virtual Home Link configuration for Mobile IPv6 R MIPv6 home link operation in various SDOs If the selected binding revocation mechanism will be based on generic notification messages. R Generic Notification Message for Mobile IPv6 Cheers Suresh _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Feb 14 19:07:59 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4B013A69DD; Thu, 14 Feb 2008 19:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.639 X-Spam-Level: ** X-Spam-Status: No, score=2.639 tagged_above=-999 required=5 tests=[AWL=-0.666, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_26=0.6, J_CHICKENPOX_44=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkB4iDZPHIbz; Thu, 14 Feb 2008 19:07:58 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF2013A69C4; Thu, 14 Feb 2008 19:07:58 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FF313A69CC for ; Thu, 14 Feb 2008 19:07:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZnm3x0mwsq9 for ; Thu, 14 Feb 2008 19:07:57 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [61.144.161.55]) by core3.amsl.com (Postfix) with ESMTP id 0C54B3A696B for ; Thu, 14 Feb 2008 19:07:57 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JW9009NFFFFAV@szxga03-in.huawei.com> for mext@ietf.org; Fri, 15 Feb 2008 11:09:15 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JW9007ZVFFEO0@szxga03-in.huawei.com> for mext@ietf.org; Fri, 15 Feb 2008 11:09:15 +0800 (CST) Received: from z49950 ([10.121.33.161]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JW9006HQFFARK@szxml03-in.huawei.com> for mext@ietf.org; Fri, 15 Feb 2008 11:09:14 +0800 (CST) Date: Fri, 15 Feb 2008 11:09:04 +0800 From: "John.zhao" In-reply-to: <008401c86eee$6e6d2e60$a864a8c0@china.huawei.com> To: 'Julien Laganier' , mext@ietf.org Message-id: <00fa01c86f80$22e52a00$a864a8c0@china.huawei.com> Organization: Huawei Technologies Co., LTD. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Thread-index: AchtjNNs2xOI+DwpTlqnIQxMnecKpABXDkEQACWohYA= Subject: Re: [MEXT] [Recharter.2] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: john.zhao@huawei.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org SGksSnVsaWVuIGFuZCBhbGwKCUFwcGVuZGVkIHdpdGggMSBpdGVtLgpbRS9DL1JdIEdSRSByZXF1 aXJlbWVudHMgZm9yIElQdjYgbW9iaWxpdHkKW0UvQy9SXSBFeHRlbmQgRFNNSVB2NiBIb21lIE5l dHdvcmsgU3VwcG9ydApbRS9DXSBCaW5kaW5nIFJldm9jYXRpb24gZm9yIElQIE1vYmlsaXR5CltF L0NdIE1vYmlsZSBJUHY2IEJvb3RzdHJhcHBpbmcgZm9yIHRoZSBBdXRoZW50aWNhdGlvbiBPcHRp b24gUHJvdG9jb2wKW0MvUl0gSW50ZXJhY3Rpb24gYmV0d2VlbiBNb2JpbGUgSVB2NiBhbmQgSVBz ZWMvSUtFIGJ5IFBGX0tFWSBleHRlbnNpb25zIApbQy9SXSBWaXJ0dWFsIEhvbWUgTGluayBjb25m aWd1cmF0aW9uIGZvciBNb2JpbGUgSVB2NgpbUl0gR2VuZXJpYyBOb3RpZmljYXRpb24gTWVzc2Fn ZSBmb3IgTW9iaWxlIElQdjYKW1JdIDQyODNiaXMgdG8gZXh0ZW5kIE1OIGlkZW50aWZpZXIgdG8g b3RoZXIgaWRlbnRpZmllcnMKCUJlc3QgUmdkcywKVGhhbmtzLApKb2huLnpoYW8KPiAtLS0tLdPK vP7Urbz+LS0tLS0KPiC3orz+yMs6IG1leHQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1leHQt Ym91bmNlc0BpZXRmLm9yZ10gtPqx7QpKb2huLnpoYW8KPiC3osvNyrG85DogMjAwOMTqMtTCMTTI 1SAxNzo0Ngo+IMrVvP7IyzogJ0p1bGllbiBMYWdhbmllcic7IG1leHRAaWV0Zi5vcmcKPiDW98zi OiBSZTogW01FWFRdIFtSZWNoYXJ0ZXIuMl0KPiAKPiBIaSxKdWxpZW4gYW5kIGFsbAo+IAo+IFtF L0MvUl0gR1JFIHJlcXVpcmVtZW50cyBmb3IgSVB2NiBtb2JpbGl0eQo+IFtFL0MvUl0gRXh0ZW5k IERTTUlQdjYgSG9tZSBOZXR3b3JrIFN1cHBvcnQKPiBbRS9DXSBCaW5kaW5nIFJldm9jYXRpb24g Zm9yIElQIE1vYmlsaXR5Cj4gW0UvQ10gTW9iaWxlIElQdjYgQm9vdHN0cmFwcGluZyBmb3IgdGhl IEF1dGhlbnRpY2F0aW9uIE9wdGlvbiBQcm90b2NvbAo+IFtDL1JdIFZpcnR1YWwgSG9tZSBMaW5r IGNvbmZpZ3VyYXRpb24gZm9yIE1vYmlsZSBJUHY2Cj4gW1JdIEdlbmVyaWMgTm90aWZpY2F0aW9u IE1lc3NhZ2UgZm9yIE1vYmlsZSBJUHY2Cj4gW1JdIDQyODNiaXMgdG8gZXh0ZW5kIE1OIGlkZW50 aWZpZXIgdG8gb3RoZXIgaWRlbnRpZmllcnMKPiAJQmVzdCBSZ2RzLAo+IFRoYW5rcywKPiBKb2hu LnpoYW8KPiA+IC0tLS0t08q8/tStvP4tLS0tLQo+ID4gt6K8/sjLOiBtZXh0LWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzptZXh0LWJvdW5jZXNAaWV0Zi5vcmddILT6se0gSnVsaWVuCj4gPiBMYWdh bmllcgo+ID4gt6LLzcqxvOQ6IDIwMDjE6jLUwjEyyNUgMjM6MzIKPiA+IMrVvP7IyzogbWV4dEBp ZXRmLm9yZwo+ID4g1vfM4jogW01FWFRdIFtSZWNoYXJ0ZXIuMl0KPiA+Cj4gPiBGb2xrcywKPiA+ Cj4gPiBUaGlzIGlzIHRoZSBuZXh0IHN0ZXAgaW4gdGhlIHJlY2hhcnRlciBwcm9jZXNzLiBXZSdk IGxpa2UgdG8gZ2V0IGlucHV0Cj4gPiBmcm9tIFdHIHBhcnRpY2lwYW50cyBvbiB3aGF0IHNob3Vs ZCBiZSB0aGUgaXRlbXMgaW5jbHVkZWQgaW4KPiA+IHJlY2hhcnRlcmluZywgd2hhdCBhcmUgdGhl aXIgcHJpb3JpdGllcywgYW5kIHdobyBpcyB3aWxsaW5nIHRvCj4gPiBzdXN0YWluIHRoZSBlZmZv cnQuIFdoZW4gdGhhdCBzdGVwIGlzIGNvbXBsZXRlZCB3ZSB3aWxsIHRha2UgdGhlIFdHCj4gPiBp bnB1dCBhbmQgZGlzY3VzcyB3aXRoIG91ciBBRCB0byBtb3ZlIGZvcndhcmQgd2l0aCBkZWNpZGlu ZyB3aGF0IHRvCj4gPiBpbmNsdWRlIG9yIG5vdCBpbiB0aGUgY2hhcnRlci4gWW91ciBpbnB1dCBz aG91bGQgYmUgc2VudCB0byB0aGUgbGlzdAo+ID4gZHVyaW5nIHRoZSBmb2xsb3dpbmcgdHdvIHdl ZWtzLCBieSAyMDA4LTAyLTI2Lgo+ID4KPiA+IFBsZWFzZSBwaWNrIGZyb20gdGhlIGxpc3Qgb2Yg aXRlbXMgYmVsb3cgdGhlIGl0ZW1zIHlvdSB0aGluayB0aGUgV0cKPiA+IHNob3VsZCB3b3JrIG9u LCBhbmQgb3JkZXIgdGhlbSBpbiBkZWNyZWFzaW5nIHByaW9yaXR5IChqdXN0IHRvIG1ha2UKPiA+ IHN1cmUsIGZpcnN0IHByaW9yaXR5IGl0ZW1zIGdvZXMgZmlyc3QgaW4gdGhlIGxpc3QgeW91J3Jl IG1ha2luZyA6KS4KPiA+Cj4gPiBMaXN0IG9mIGl0ZW1zOgo+ID4KPiA+IEJpbmRpbmcgUmV2b2Nh dGlvbiBmb3IgSVAgTW9iaWxpdHkKPiA+IE1JUHY2IGhvbWUgbGluayBvcGVyYXRpb24gaW4gdmFy aW91cyBTRE9zCj4gPiBJUCBUdW5uZWxpbmcgT3B0aW1pemF0aW9uIGluIGEgTW9iaWxlIEVudmly b25tZW50Cj4gPiBHZW5lcmljIE5vdGlmaWNhdGlvbiBNZXNzYWdlIGZvciBNb2JpbGUgSVB2Ngo+ ID4gR1JFIHJlcXVpcmVtZW50cyBmb3IgSVB2NiBtb2JpbGl0eQo+ID4gNDI4M2JpcyB0byBleHRl bmQgTU4gaWRlbnRpZmllciB0byBvdGhlciBpZGVudGlmaWVycwo+ID4gTW9iaWxlIElQdjYgQm9v dHN0cmFwcGluZyBmb3IgdGhlIEF1dGhlbnRpY2F0aW9uIE9wdGlvbiBQcm90b2NvbAo+ID4gSW50 ZXJhY3Rpb24gYmV0d2VlbiBNb2JpbGUgSVB2NiBhbmQgSVBzZWMvSUtFIGJ5IFBGX0tFWSBleHRl bnNpb25zCj4gPiBWaXJ0dWFsIEhvbWUgTGluayBjb25maWd1cmF0aW9uIGZvciBNb2JpbGUgSVB2 Ngo+ID4gRXh0ZW5kIERTTUlQdjYgSG9tZSBOZXR3b3JrIFN1cHBvcnQKPiA+Cj4gPiBBbHNvLCBw bGVhc2UgcHJlZml4IGVhY2ggb2YgdGhlIGl0ZW1zIGluIHlvdXIgbGlzdCB3aXRoIHRoZSBsZXR0 ZXJzIEUsIEMKPiA+IGFuZC9vciBSIGlmIHlvdSdyZSB3aWxsaW5nIHRvOgo+ID4KPiA+IC0gW0Vd ZGl0OiBBcmUgeW91IHdpbGxpbmcgdG8gZWRpdCB0aGUgZHJhZnQgY29ycmVzcG9uZGluZyB0byB0 aGUKPiA+ICAgaXRlbS4KPiA+Cj4gPiAtIFtDXW9udHJpYnV0ZTogQXJlIHlvdSB3aWxsaW5nIHRv IHByb3Bvc2UgdGV4dCBmb3IgdGhlIGRyYWZ0Lgo+ID4KPiA+IC0gW1JdZXZpZXc6IEFyZSB5b3Ug d2lsbGluZyB0byByZXZpZXcgbmV3IHJldmlzaW9ucyBvZiB0aGUgZHJhZnQgd2hlbgo+ID4gICBi ZWluZyBhc2tlZCBieSB0aGUgY2hhaXJzLgo+ID4KPiA+IEFzIGFuIGV4YW1wbGUsIHRoYXQgY291 bGQgYmUgb25lIGlucHV0IGxpc3Q6Cj4gPgo+ID4gRSBNSVB2NiBob21lIGxpbmsgb3BlcmF0aW9u IGluIHZhcmlvdXMgU0RPcwo+ID4gQ1IgQmluZGluZyBSZXZvY2F0aW9uIGZvciBJUCBNb2JpbGl0 eQo+ID4gUiBJUCBUdW5uZWxpbmcgT3B0aW1pemF0aW9uIGluIGEgTW9iaWxlIEVudmlyb25tZW50 Cj4gPgo+ID4gbWVhbmluZyB0aGF0IHRoZSBNSVB2NiBob21lIGxpbmsgaXMgZmlyc3QgcHJpb3Jp dHkgYW5kIHlvdSB2b2x1bnRlZXIgdG8KPiA+IGVkaXQsIEJpbmRpbmcgcmV2b2NhdGlvbiBpcyBz ZWNvbmQgcHJpb3JpdHkgYW5kIHlvdSdyZSB3aWxsaW5nIHRvCj4gPiBjb250cmlidXRlIGFuZCBy ZXZpZXcsIHdoaWxlIElQIHR1bm5lbGluZyBvcHRpbWl6YXRpb24gaXMgdGhpcmQKPiA+IHByaW9y aXR5IGFuZCB5b3UncmUgd2lsbGluZyB0byByZXZpZXcuCj4gPgo+ID4gSG9wZSB0aGlzIGlzIHVu ZGVyc3RhbmRhYmxlIDopCj4gPgo+ID4gVGhhbmtzLgo+ID4KPiA+IC0tIGp1bGllbiBhbmQgbWFy Y2VsbG8sIE1FWFQgY2hhaXJzCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwo+ID4gTUVYVCBtYWlsaW5nIGxpc3QKPiA+IE1FWFRAaWV0Zi5vcmcKPiA+ IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tZXh0Cj4gCj4gCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBNRVhUIG1haWxpbmcg bGlzdAo+IE1FWFRAaWV0Zi5vcmcKPiBodHRwOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbWV4dAoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Ck1FWFQgbWFpbGluZyBsaXN0Ck1FWFRAaWV0Zi5vcmcKaHR0cDovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21leHQK From mext-bounces@ietf.org Thu Feb 14 19:59:50 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEE0A3A695C; Thu, 14 Feb 2008 19:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsQyRd50c0KR; Thu, 14 Feb 2008 19:59:49 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCDE43A69C2; Thu, 14 Feb 2008 19:59:49 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34A383A695C for ; Thu, 14 Feb 2008 19:59:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLar1VurtIjc for ; Thu, 14 Feb 2008 19:59:48 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [61.144.161.7]) by core3.amsl.com (Postfix) with ESMTP id 9D4FC3A69C5 for ; Thu, 14 Feb 2008 19:58:54 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JW90091RHS2WO@szxga04-in.huawei.com> for mext@ietf.org; Fri, 15 Feb 2008 12:00:02 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JW900D8HHS1VM@szxga04-in.huawei.com> for mext@ietf.org; Fri, 15 Feb 2008 12:00:02 +0800 (CST) Received: from l50323 ([10.164.9.74]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JW9006HBHS1RK@szxml03-in.huawei.com> for mext@ietf.org; Fri, 15 Feb 2008 12:00:01 +0800 (CST) Date: Fri, 15 Feb 2008 12:00:00 +0800 From: li.chunqiang@huawei.com To: Julien Laganier , mext@ietf.org Message-id: <006501c86f87$3cf5f800$4a09a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <200802111135.44252.julien.IETF@laposte.net> <200802121631.35572.julien.IETF@laposte.net> Subject: Re: [MEXT] [Recharter.2] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, Julien and all Here is my list. [R] IP Tunneling Optimization in a Mobile Environment [R]Mobile IPv6 Bootstrapping for the Authentication Option Protocol [R]4283bis to extend MN identifier to other identifiers BRs Chunqiang Li ----- Original Message ----- From: "Julien Laganier" To: Sent: Tuesday, February 12, 2008 11:31 PM Subject: [MEXT] [Recharter.2] > Folks, > > This is the next step in the recharter process. We'd like to get input > from WG participants on what should be the items included in > rechartering, what are their priorities, and who is willing to > sustain the effort. When that step is completed we will take the WG > input and discuss with our AD to move forward with deciding what to > include or not in the charter. Your input should be sent to the list > during the following two weeks, by 2008-02-26. > > Please pick from the list of items below the items you think the WG > should work on, and order them in decreasing priority (just to make > sure, first priority items goes first in the list you're making :). > > List of items: > > Binding Revocation for IP Mobility > MIPv6 home link operation in various SDOs > IP Tunneling Optimization in a Mobile Environment > Generic Notification Message for Mobile IPv6 > GRE requirements for IPv6 mobility > 4283bis to extend MN identifier to other identifiers > Mobile IPv6 Bootstrapping for the Authentication Option Protocol > Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions > Virtual Home Link configuration for Mobile IPv6 > Extend DSMIPv6 Home Network Support > > Also, please prefix each of the items in your list with the letters E, C > and/or R if you're willing to: > > - [E]dit: Are you willing to edit the draft corresponding to the > item. > > - [C]ontribute: Are you willing to propose text for the draft. > > - [R]eview: Are you willing to review new revisions of the draft when > being asked by the chairs. > > As an example, that could be one input list: > > E MIPv6 home link operation in various SDOs > CR Binding Revocation for IP Mobility > R IP Tunneling Optimization in a Mobile Environment > > meaning that the MIPv6 home link is first priority and you volunteer to > edit, Binding revocation is second priority and you're willing to > contribute and review, while IP tunneling optimization is third > priority and you're willing to review. > > Hope this is understandable :) > > Thanks. > > -- julien and marcello, MEXT chairs > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Feb 15 08:23:30 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EA4E28D265; Fri, 15 Feb 2008 08:23:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.593 X-Spam-Level: X-Spam-Status: No, score=-1.593 tagged_above=-999 required=5 tests=[AWL=0.844, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVSQ0FPc0DC9; Fri, 15 Feb 2008 08:23:29 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46FB028D130; Fri, 15 Feb 2008 08:23:29 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43CA728CE14 for ; Fri, 15 Feb 2008 08:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6ozUyOE10vA for ; Fri, 15 Feb 2008 08:23:27 -0800 (PST) Received: from mxs1.siemens.at (mxs1.siemens.at [194.138.12.131]) by core3.amsl.com (Postfix) with ESMTP id F114E28D108 for ; Fri, 15 Feb 2008 08:23:26 -0800 (PST) Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs1.siemens.at with ESMTP id m1FGOjBx008638; Fri, 15 Feb 2008 17:24:45 +0100 Received: from nets139a.ww300.siemens.net ([158.226.129.98]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id m1FGOfmA021179; Fri, 15 Feb 2008 17:24:45 +0100 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Feb 2008 17:24:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Feb 2008 17:22:54 +0100 Message-ID: <3C31CDD06342EA4A8137716247B1CD680368B76D@zagh223a.ww300.siemens.net> In-Reply-To: <200802121631.35572.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [Recharter.2] Thread-Index: AchtjZ3CQuzT5Ll6Rl2xzSbDLvsxdgCXUMJw References: <200802111135.44252.julien.IETF@laposte.net> <200802121631.35572.julien.IETF@laposte.net> From: "Premec, Domagoj" To: "Julien Laganier" , X-OriginalArrivalTime: 15 Feb 2008 16:24:40.0537 (UTC) FILETIME=[43CC0490:01C86FEF] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::080215172445-0B21DBB0-2A22FE55/0-0/0-15 X-purgate-size: 3103/0 Subject: Re: [MEXT] [Recharter.2] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien, Here's my list: [R] Binding Revocation for IP Mobility [CR] GRE requirements for IPv6 mobility [CR] Extend DSMIPv6 Home Network Support [R] Generic Notification Message for Mobile IPv6 [CR] MIPv6 home link operation in various SDOs [CR] Virtual Home Link configuration for Mobile IPv6 IMO there is a partial overlap between the above two drafts, maybe it would be possible to describe home link variations in a single document? regards domagoj > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Julien Laganier > Sent: 12. veljaca 2008 16:32 > To: mext@ietf.org > Subject: [MEXT] [Recharter.2] > > Folks, > > This is the next step in the recharter process. We'd like to > get input from WG participants on what should be the items > included in rechartering, what are their priorities, and who > is willing to sustain the effort. When that step is completed > we will take the WG input and discuss with our AD to move > forward with deciding what to include or not in the charter. > Your input should be sent to the list during the following > two weeks, by 2008-02-26. > > Please pick from the list of items below the items you think > the WG should work on, and order them in decreasing priority > (just to make sure, first priority items goes first in the > list you're making :). > > List of items: > > Binding Revocation for IP Mobility > MIPv6 home link operation in various SDOs IP Tunneling > Optimization in a Mobile Environment Generic Notification > Message for Mobile IPv6 GRE requirements for IPv6 mobility > 4283bis to extend MN identifier to other identifiers Mobile > IPv6 Bootstrapping for the Authentication Option Protocol > Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY > extensions Virtual Home Link configuration for Mobile IPv6 > Extend DSMIPv6 Home Network Support > > Also, please prefix each of the items in your list with the > letters E, C and/or R if you're willing to: > > - [E]dit: Are you willing to edit the draft corresponding to the > item. > > - [C]ontribute: Are you willing to propose text for the draft. > > - [R]eview: Are you willing to review new revisions of the draft when > being asked by the chairs. > > As an example, that could be one input list: > > E MIPv6 home link operation in various SDOs CR Binding > Revocation for IP Mobility R IP Tunneling Optimization in a > Mobile Environment > > meaning that the MIPv6 home link is first priority and you > volunteer to edit, Binding revocation is second priority and > you're willing to contribute and review, while IP tunneling > optimization is third priority and you're willing to review. > > Hope this is understandable :) > > Thanks. > > -- julien and marcello, MEXT chairs > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Feb 15 10:35:51 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 649C63A695F; Fri, 15 Feb 2008 10:35:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.603 X-Spam-Level: X-Spam-Status: No, score=-3.603 tagged_above=-999 required=5 tests=[AWL=-1.165, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RANe2nInVBz4; Fri, 15 Feb 2008 10:35:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6338B3A6996; Fri, 15 Feb 2008 10:35:50 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C0D33A695F for ; Fri, 15 Feb 2008 10:35:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYGNl2CSbdcO for ; Fri, 15 Feb 2008 10:35:48 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 8BF2E3A6867 for ; Fri, 15 Feb 2008 10:35:48 -0800 (PST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 15 Feb 2008 10:37:09 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1FIb9ZC020394; Fri, 15 Feb 2008 10:37:09 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1FIabKG004906; Fri, 15 Feb 2008 18:37:09 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Feb 2008 10:36:55 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Feb 2008 10:37:50 -0800 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB053A15F5@xmb-sjc-236.amer.cisco.com> In-Reply-To: <200802121631.35572.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [Recharter.2] Thread-Index: AchtjOV0IfZeLg/9R3KoIsyh6tHF7ACdDlCA References: <200802111135.44252.julien.IETF@laposte.net> <200802121631.35572.julien.IETF@laposte.net> From: "Parviz Yegani (pyegani)" To: "Julien Laganier" , X-OriginalArrivalTime: 15 Feb 2008 18:36:55.0922 (UTC) FILETIME=[BDA7AD20:01C87001] Authentication-Results: sj-dkim-2; header.From=pyegani@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [MEXT] [Recharter.2] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien, The WG should work on the following items (in decreasing priority order): [E] Binding Revocation for IP Mobility [CR] GRE requirements for IPv6 mobility [CR] Virtual Home Link configuration for Mobile IPv6 Thanks, Parviz -----Original Message----- From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Julien Laganier Sent: Tuesday, February 12, 2008 7:32 AM To: mext@ietf.org Subject: [MEXT] [Recharter.2] Folks, This is the next step in the recharter process. We'd like to get input from WG participants on what should be the items included in rechartering, what are their priorities, and who is willing to sustain the effort. When that step is completed we will take the WG input and discuss with our AD to move forward with deciding what to include or not in the charter. Your input should be sent to the list during the following two weeks, by 2008-02-26. Please pick from the list of items below the items you think the WG should work on, and order them in decreasing priority (just to make sure, first priority items goes first in the list you're making :). List of items: Binding Revocation for IP Mobility MIPv6 home link operation in various SDOs IP Tunneling Optimization in a Mobile Environment Generic Notification Message for Mobile IPv6 GRE requirements for IPv6 mobility 4283bis to extend MN identifier to other identifiers Mobile IPv6 Bootstrapping for the Authentication Option Protocol Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions Virtual Home Link configuration for Mobile IPv6 Extend DSMIPv6 Home Network Support Also, please prefix each of the items in your list with the letters E, C and/or R if you're willing to: - [E]dit: Are you willing to edit the draft corresponding to the item. - [C]ontribute: Are you willing to propose text for the draft. - [R]eview: Are you willing to review new revisions of the draft when being asked by the chairs. As an example, that could be one input list: E MIPv6 home link operation in various SDOs CR Binding Revocation for IP Mobility R IP Tunneling Optimization in a Mobile Environment meaning that the MIPv6 home link is first priority and you volunteer to edit, Binding revocation is second priority and you're willing to contribute and review, while IP tunneling optimization is third priority and you're willing to review. Hope this is understandable :) Thanks. -- julien and marcello, MEXT chairs _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Feb 15 13:17:41 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D24593A685F; Fri, 15 Feb 2008 13:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.464 X-Spam-Level: X-Spam-Status: No, score=-1.464 tagged_above=-999 required=5 tests=[AWL=-1.027, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVHz5JKqcCxX; Fri, 15 Feb 2008 13:17:39 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 771603A6A96; Fri, 15 Feb 2008 13:17:39 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94E5B28C110 for ; Fri, 15 Feb 2008 13:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxtTc8jjHtWf for ; Fri, 15 Feb 2008 13:17:36 -0800 (PST) Received: from ndjsbar02.ndc.nasa.gov (ndjsbar02.ndc.nasa.gov [198.120.25.39]) by core3.amsl.com (Postfix) with ESMTP id 54F8C3A685F for ; Fri, 15 Feb 2008 13:17:35 -0800 (PST) Received: from ndjsxgw03.ndc.nasa.gov (ndjsxgw03.ndc.nasa.gov [129.166.32.111]) by ndjsbar02.ndc.nasa.gov (Spam Firewall) with ESMTP id EF2F9518C24 for ; Fri, 15 Feb 2008 15:18:55 -0600 (CST) Received: from ndjsxgw03.ndc.nasa.gov (ndjsxgw03.ndc.nasa.gov [129.166.32.111]) by ndjsbar02.ndc.nasa.gov with ESMTP id Df5tTGWMq2CvKRe7 for ; Fri, 15 Feb 2008 15:18:55 -0600 (CST) Received: from NDJSEVS23A.ndc.nasa.gov ([129.166.32.223]) by ndjsxgw03.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Feb 2008 15:18:55 -0600 MIME-Version: 1.0 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Date: Fri, 15 Feb 2008 15:18:50 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: firewall-vendor and firewall-admin review - editorial Thread-Index: AchwGFutbo4Ncb28QMCyEfpGGyhAuA== From: "Ivancic, William D. (GRC-RCN0)" To: X-OriginalArrivalTime: 15 Feb 2008 21:18:55.0813 (UTC) FILETIME=[5F295750:01C87018] Subject: [MEXT] firewall-vendor and firewall-admin review - editorial X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I was asked to review both Guidelines for firewall vendors regarding MIPv6 traffic draft-krishnan-mip6-firewall-vendor-02 and Guidelines for firewall administrators regarding MIPv6 traffic draft-krishnan-mip6-firewall-admin-02 I read the earlier versions and now the most recent versions. I read them over a few times and do not have much to add to those documents except for some minor editorial suggestions. I believe most details are covered regarding how to allow MIP to work relative to communicating through a firewalled network. I will submit a second email on operations. This only covers editorial comments except for recommendation 4. Recommendation #1 ================= In both document in the introduction, section 2 it states: "Since firewalls are not aware of MIPv6 protocol details, they will probably interfere with the smooth operation of the protocol." To me, there is no doubt or probability. Firewall WILL break MIPv6 (and MIPv4 and NEMO) unless steps are taken. Thus, I suggest changing the wording to: "Firewalls will interfere with the smooth operation of the MIPv6 protocol unless specific steps are taken to allow Mobile IPv6 signaling and data messages to pass through the firewall." Recommendation #2 =================== The people on the MEXT or MIP6 mail lists are probably familiar with the MIP abbreviations - although even I have to sometimes go back and look up what HoTI or CoT are. A firewall vendor or administrator is likely to have little familiarity with those terms. For example in the firewall-vendor draft section 4. "4. Allowing signaling response packets The MIPv6 signaling messages are usually performed as a request- response pair. ..... There are 3 message pairs that are of importance to MIPv6 signaling. They are the BU/BA, HoTI/HoT and CoTI/CoT pairs. ...." Thus, I recommend that an abbreviations list be provided as is done in section 3 of RFC4487 - see below. Also, if there is a MIPv6 or MIP document that defines mobile ip terms, it would be good to reference such a document. From RFC4487 section 3. 3. Abbreviations This document uses the following abbreviations: o CN: Correspondent Node o CoA: Care of Address o CoTI: Care of Test Init o HA: Home Agent o HoA: Home Address o HoTI: Home Test Init o HoT: Home Test o MN: Mobile Node o RO: Route Optimization o RRT: Return Routability Test Recommendation #3 ======================= A picture is worth a 1000s words. I probably would be useful to duplicate the graphics in RFC4887 - at least in the firewall-admin document. If one is not familiar with MIPv6 operations, those pictures may help quite a bit. From RFC4887 +----------------+ +----+ | | | HA | | | +----+ | | Home Agent | +---+ +----+ of A +---+ | | A | | FW | | B | | +---+ +----+ +---+ |Internal | External | MN | Node | | +----------------+ Network protected Figure 1: Issues between MIP6 and firewalls when MN is in a network protected by firewalls Recommendation/Question #4 =========================== Regarding the firewall-vendor document. In today's MIP deployments (v6, v4, NEMO), when MIP signaling is blocked by a firewall, does that firewall return any type of message to allow one to debug the system? Quite a few years ago when I did NEMO IPv4 with a T-Mobile network we were operating fine one day and the next day everything broke. It turned out T-Mobile started administratively filtering on what we considered an open network. At least we received "administratively filtered" messages and could track down the problem. http://roland.grc.nasa.gov/~ivancic/t-mobile/administrative_filtering.pd f My recommendation is that vendors should provide some type of uniform signaling to indicate that MIP signaling was administratively filtered. Perhaps some new ICMP message or at least a recommendation of which to send. /will _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Feb 15 13:33:20 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E21E28C36A; Fri, 15 Feb 2008 13:33:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=-1.976, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMgwgBKw4NZK; Fri, 15 Feb 2008 13:33:19 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21F5C28C2C7; Fri, 15 Feb 2008 13:33:19 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 142813A67E4 for ; Fri, 15 Feb 2008 13:33:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nSe+gOHvrzp for ; Fri, 15 Feb 2008 13:33:17 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 1EDEB28C1B6 for ; Fri, 15 Feb 2008 13:33:17 -0800 (PST) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m1FLYaxq022646; Fri, 15 Feb 2008 15:34:36 -0600 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Feb 2008 15:34:36 -0600 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Feb 2008 15:34:36 -0600 Message-ID: <47B605EE.1050707@ericsson.com> Date: Fri, 15 Feb 2008 16:36:46 -0500 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: "Ivancic, William D. (GRC-RCN0)" References: In-Reply-To: X-OriginalArrivalTime: 15 Feb 2008 21:34:36.0213 (UTC) FILETIME=[8FAEFE50:01C8701A] Cc: mext@ietf.org Subject: Re: [MEXT] firewall-vendor and firewall-admin review - editorial X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi William, Thanks for the comments. Please find my responses inline Ivancic, William D. (GRC-RCN0) wrote: > In both document in the introduction, section 2 it states: > > "Since firewalls are not aware of MIPv6 protocol details, they will > probably interfere with the smooth operation of the protocol." > > To me, there is no doubt or probability. Firewall WILL break MIPv6 (and > MIPv4 and NEMO) unless steps are taken. Thus, I suggest changing the > wording to: > > "Firewalls will interfere with the smooth operation of the MIPv6 > protocol unless specific steps are taken to allow Mobile IPv6 signaling > and data messages to pass through the firewall." OK. I will make this change. > > Recommendation #2 > =================== > The people on the MEXT or MIP6 mail lists are probably familiar with the > MIP abbreviations - although even I have to sometimes go back and look > up what HoTI or CoT are. A firewall vendor or administrator is likely > to have little familiarity with those terms. For example in the > firewall-vendor draft section 4. > > "4. Allowing signaling response packets > > The MIPv6 signaling messages are usually performed as a request- > response pair. ..... There are 3 message pairs that are > of importance to MIPv6 signaling. They are the BU/BA, HoTI/HoT and > CoTI/CoT pairs. ...." > > Thus, I recommend that an abbreviations list be provided as is done in > section 3 of RFC4487 - see below. Also, if there is a MIPv6 or MIP > document that defines mobile ip terms, it would be good to reference > such a document. OK. I will do this. It sounds like a good idea. > Recommendation #3 > ======================= > A picture is worth a 1000s words. I probably would be useful to > duplicate the graphics in RFC4887 - at least in the firewall-admin > document. If one is not familiar with MIPv6 operations, those pictures > may help quite a bit. > > > From RFC4887 > > +----------------+ +----+ > | | | HA | > | | +----+ > | | Home Agent > | +---+ +----+ of A +---+ > | | A | | FW | | B | > | +---+ +----+ +---+ > |Internal | External > | MN | Node > | | > +----------------+ > Network protected > > Figure 1: Issues between MIP6 and firewalls when MN is in a network > protected by firewalls > OK. I will add the figures. > Recommendation/Question #4 > =========================== > Regarding the firewall-vendor document. > > In today's MIP deployments (v6, v4, NEMO), when MIP signaling is blocked > by a firewall, does that firewall return any type of message to allow > one to debug the system? Quite a few years ago when I did NEMO IPv4 > with a T-Mobile network we were operating fine one day and the next day > everything broke. It turned out T-Mobile started administratively > filtering on what we considered an open network. At least we received > "administratively filtered" messages and could track down the problem. > http://roland.grc.nasa.gov/~ivancic/t-mobile/administrative_filtering.pd > f > > My recommendation is that vendors should provide some type of uniform > signaling to indicate that MIP signaling was administratively filtered. > Perhaps some new ICMP message or at least a recommendation of which to > send. ICMPv6 Type 1 (Destination unreachable) message with code 1 - communication with destination administratively prohibited seems like a good fit for this, but I am open to the idea of a new type/code Thanks Suresh _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Feb 15 13:59:21 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B2D728C351; Fri, 15 Feb 2008 13:59:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.728 X-Spam-Level: X-Spam-Status: No, score=-2.728 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrFgx-6Vsgqq; Fri, 15 Feb 2008 13:59:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 563893A6AD9; Fri, 15 Feb 2008 13:59:20 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2567628C0E7 for ; Fri, 15 Feb 2008 13:59:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EeTqNGFMOk0r for ; Fri, 15 Feb 2008 13:59:18 -0800 (PST) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id AF26728C1E2 for ; Fri, 15 Feb 2008 13:58:55 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 61B6D18804B for ; Fri, 15 Feb 2008 17:00:15 -0500 (EST) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11865-17 for ; Fri, 15 Feb 2008 17:00:13 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Fri, 15 Feb 2008 17:00:13 -0500 (EST) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Feb 2008 16:59:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Feb 2008 16:59:32 -0500 Message-ID: <4D35478224365146822AE9E3AD4A2666015125B7@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [Recharter.2] Thread-Index: AchtjOMQRbr+iYsST/+j1fmLp72M7wCjchXw From: "Chowdhury, Kuntal" To: "Julien Laganier" , X-OriginalArrivalTime: 15 Feb 2008 21:59:27.0335 (UTC) FILETIME=[08762770:01C8701E] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Subject: Re: [MEXT] [Recharter.2] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien, Here is my input: [E] Binding Revocation for IP Mobility [E] 4283bis to extend MN identifier to other identifiers [E] Mobile IPv6 Bootstrapping for the Authentication Option Protocol [C/R] MIPv6 home link operation in various SDOs [C/R] GRE requirements for IPv6 mobility [C/R] Virtual Home Link configuration for Mobile IPv6 [R] Generic Notification Message for Mobile IPv6 Regards, Kuntal > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Julien Laganier > Sent: Tuesday, February 12, 2008 9:32 AM > To: mext@ietf.org > Subject: [MEXT] [Recharter.2] > > Folks, > > This is the next step in the recharter process. We'd like to get input > from WG participants on what should be the items included in > rechartering, what are their priorities, and who is willing to > sustain the effort. When that step is completed we will take the WG > input and discuss with our AD to move forward with deciding what to > include or not in the charter. Your input should be sent to the list > during the following two weeks, by 2008-02-26. > > Please pick from the list of items below the items you think the WG > should work on, and order them in decreasing priority (just to make > sure, first priority items goes first in the list you're making :). > > List of items: > > Binding Revocation for IP Mobility > MIPv6 home link operation in various SDOs > IP Tunneling Optimization in a Mobile Environment > Generic Notification Message for Mobile IPv6 > GRE requirements for IPv6 mobility > 4283bis to extend MN identifier to other identifiers > Mobile IPv6 Bootstrapping for the Authentication Option Protocol > Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions > Virtual Home Link configuration for Mobile IPv6 > Extend DSMIPv6 Home Network Support > > Also, please prefix each of the items in your list with the letters E, C > and/or R if you're willing to: > > - [E]dit: Are you willing to edit the draft corresponding to the > item. > > - [C]ontribute: Are you willing to propose text for the draft. > > - [R]eview: Are you willing to review new revisions of the draft when > being asked by the chairs. > > As an example, that could be one input list: > > E MIPv6 home link operation in various SDOs > CR Binding Revocation for IP Mobility > R IP Tunneling Optimization in a Mobile Environment > > meaning that the MIPv6 home link is first priority and you volunteer to > edit, Binding revocation is second priority and you're willing to > contribute and review, while IP tunneling optimization is third > priority and you're willing to review. > > Hope this is understandable :) > > Thanks. > > -- julien and marcello, MEXT chairs > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Feb 15 14:10:19 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09E6A28C3B2; Fri, 15 Feb 2008 14:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.964 X-Spam-Level: X-Spam-Status: No, score=-2.964 tagged_above=-999 required=5 tests=[AWL=-0.527, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4nmtAsXJkFX; Fri, 15 Feb 2008 14:10:17 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0EA63A69B1; Fri, 15 Feb 2008 14:10:17 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 753803A68CB for ; Fri, 15 Feb 2008 14:10:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzSkEvJ6tzYW for ; Fri, 15 Feb 2008 14:10:15 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id E06E328C3B2 for ; Fri, 15 Feb 2008 14:10:03 -0800 (PST) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1FMB9kg027410; Sat, 16 Feb 2008 00:11:19 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Feb 2008 00:11:05 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Feb 2008 16:11:03 -0600 Received: from 10.138.85.190 ([10.138.85.190]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 15 Feb 2008 22:11:03 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Fri, 15 Feb 2008 16:11:55 -0600 From: Basavaraj Patil To: Julien Laganier , Message-ID: Thread-Topic: [MEXT] [Recharter.2] Thread-Index: AchwH8YaBH+L5twTEdylSAARJNUNiA== In-Reply-To: <200802121631.35572.julien.IETF@laposte.net> Mime-version: 1.0 X-OriginalArrivalTime: 15 Feb 2008 22:11:03.0037 (UTC) FILETIME=[A721DAD0:01C8701F] X-Nokia-AV: Clean Subject: Re: [MEXT] [Recharter.2] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien, In terms of priority, I hope the DS-MIP6 I-D is pretty high. The milestones indicate completion of this work by Dec 07. Hopefully we can get it out by IETF71 at least. I am willing to help on getting this thru. In terms of priorities for the list that you sent: [R] GRE requirements for IPv6 mobility [R] 4283bis to extend MN identifier to other identifiers [R] Extend DSMIPv6 Home Network Support [R] Binding Revocation for IP Mobility -Raj On 2/12/08 9:31 AM, "ext Julien Laganier" wrote: > Folks, > > This is the next step in the recharter process. We'd like to get input > from WG participants on what should be the items included in > rechartering, what are their priorities, and who is willing to > sustain the effort. When that step is completed we will take the WG > input and discuss with our AD to move forward with deciding what to > include or not in the charter. Your input should be sent to the list > during the following two weeks, by 2008-02-26. > > Please pick from the list of items below the items you think the WG > should work on, and order them in decreasing priority (just to make > sure, first priority items goes first in the list you're making :). > > List of items: > > Binding Revocation for IP Mobility > MIPv6 home link operation in various SDOs > IP Tunneling Optimization in a Mobile Environment > Generic Notification Message for Mobile IPv6 > GRE requirements for IPv6 mobility > 4283bis to extend MN identifier to other identifiers > Mobile IPv6 Bootstrapping for the Authentication Option Protocol > Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions > Virtual Home Link configuration for Mobile IPv6 > Extend DSMIPv6 Home Network Support > > Also, please prefix each of the items in your list with the letters E, C > and/or R if you're willing to: > > - [E]dit: Are you willing to edit the draft corresponding to the > item. > > - [C]ontribute: Are you willing to propose text for the draft. > > - [R]eview: Are you willing to review new revisions of the draft when > being asked by the chairs. > > As an example, that could be one input list: > > E MIPv6 home link operation in various SDOs > CR Binding Revocation for IP Mobility > R IP Tunneling Optimization in a Mobile Environment > > meaning that the MIPv6 home link is first priority and you volunteer to > edit, Binding revocation is second priority and you're willing to > contribute and review, while IP tunneling optimization is third > priority and you're willing to review. > > Hope this is understandable :) > > Thanks. > > -- julien and marcello, MEXT chairs > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Feb 15 14:14:50 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21EB13A6BAB; Fri, 15 Feb 2008 14:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, MISSING_HEADERS=1.292, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yi2tqpvde1DF; Fri, 15 Feb 2008 14:14:48 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28EAE3A6AA7; Fri, 15 Feb 2008 14:14:48 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 248623A6B5E for ; Fri, 15 Feb 2008 14:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAJnlviQN5Dv for ; Fri, 15 Feb 2008 14:14:46 -0800 (PST) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 248FD28C23A for ; Fri, 15 Feb 2008 14:13:47 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: Anand.Bedekar@Motorola.com X-Msg-Ref: server-2.tower-128.messagelabs.com!1203113706!2227391!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 23026 invoked from network); 15 Feb 2008 22:15:07 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-2.tower-128.messagelabs.com with SMTP; 15 Feb 2008 22:15:07 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id m1FMF2K4027362; Fri, 15 Feb 2008 15:15:06 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id m1FMF1t4009554; Fri, 15 Feb 2008 16:15:01 -0600 (CST) Received: from [10.18.232.244] (d1441-0a12e8f4.cig.mot.com [10.18.232.244]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id m1FMEx60009507; Fri, 15 Feb 2008 16:15:00 -0600 (CST) Message-ID: <47B60EE3.3070103@Motorola.com> Date: Fri, 15 Feb 2008 16:14:59 -0600 From: Bedekar Anand-ABEDEKA1 User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 References: <200802111135.44252.julien.IETF@laposte.net> <200802121631.35572.julien.IETF@laposte.net> <006501c86f87$3cf5f800$4a09a40a@china.huawei.com> In-Reply-To: <006501c86f87$3cf5f800$4a09a40a@china.huawei.com> X-CFilter-Loop: Reflected Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] [Recharter.2] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Julien, Here's my list: [C/R] GRE requirements for IPv6 mobility [C/R] Binding Revocation for IP Mobility [R] Virtual Home Link configuration for Mobile IPv6 [R] Generic Notification Message for Mobile IPv6 Thanks, Anand > ----- Original Message ----- > From: "Julien Laganier" > To: > Sent: Tuesday, February 12, 2008 11:31 PM > Subject: [MEXT] [Recharter.2] > > >> Folks, >> >> This is the next step in the recharter process. We'd like to get input >> from WG participants on what should be the items included in >> rechartering, what are their priorities, and who is willing to >> sustain the effort. When that step is completed we will take the WG >> input and discuss with our AD to move forward with deciding what to >> include or not in the charter. Your input should be sent to the list >> during the following two weeks, by 2008-02-26. >> >> Please pick from the list of items below the items you think the WG >> should work on, and order them in decreasing priority (just to make >> sure, first priority items goes first in the list you're making :). >> >> List of items: >> >> Binding Revocation for IP Mobility >> MIPv6 home link operation in various SDOs >> IP Tunneling Optimization in a Mobile Environment >> Generic Notification Message for Mobile IPv6 >> GRE requirements for IPv6 mobility >> 4283bis to extend MN identifier to other identifiers >> Mobile IPv6 Bootstrapping for the Authentication Option Protocol >> Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions >> Virtual Home Link configuration for Mobile IPv6 >> Extend DSMIPv6 Home Network Support >> >> Also, please prefix each of the items in your list with the letters E, C >> and/or R if you're willing to: >> >> - [E]dit: Are you willing to edit the draft corresponding to the >> item. >> >> - [C]ontribute: Are you willing to propose text for the draft. >> >> - [R]eview: Are you willing to review new revisions of the draft when >> being asked by the chairs. >> >> As an example, that could be one input list: >> >> E MIPv6 home link operation in various SDOs >> CR Binding Revocation for IP Mobility >> R IP Tunneling Optimization in a Mobile Environment >> >> meaning that the MIPv6 home link is first priority and you volunteer to >> edit, Binding revocation is second priority and you're willing to >> contribute and review, while IP tunneling optimization is third >> priority and you're willing to review. >> >> Hope this is understandable :) >> >> Thanks. >> >> -- julien and marcello, MEXT chairs >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> http://www.ietf.org/mailman/listinfo/mext > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Feb 15 14:14:52 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2BC428C4B4; Fri, 15 Feb 2008 14:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.122 X-Spam-Level: X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[AWL=-0.685, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXFDO1zHzJvc; Fri, 15 Feb 2008 14:14:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D76928C300; Fri, 15 Feb 2008 14:14:49 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32E723A6B7D for ; Fri, 15 Feb 2008 14:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tx-OdLA1VLsN for ; Fri, 15 Feb 2008 14:14:46 -0800 (PST) Received: from ndjsbar01.ndc.nasa.gov (ndjsbar01.ndc.nasa.gov [198.120.25.38]) by core3.amsl.com (Postfix) with ESMTP id 708703A68CB for ; Fri, 15 Feb 2008 14:13:46 -0800 (PST) Received: from ndjsxgw03.ndc.nasa.gov (ndjsxgw03.ndc.nasa.gov [129.166.32.111]) by ndjsbar01.ndc.nasa.gov (Spam Firewall) with ESMTP id 8CB615FCBB3; Fri, 15 Feb 2008 16:15:06 -0600 (CST) Received: from ndjsxgw03.ndc.nasa.gov (ndjsxgw03.ndc.nasa.gov [129.166.32.111]) by ndjsbar01.ndc.nasa.gov with ESMTP id FF4S7vBfrFzfyAHH; Fri, 15 Feb 2008 16:15:06 -0600 (CST) Received: from NDJSEVS23A.ndc.nasa.gov ([129.166.32.223]) by ndjsxgw03.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Feb 2008 16:15:06 -0600 MIME-Version: 1.0 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Date: Fri, 15 Feb 2008 16:14:59 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Regarding realistic deployment and operations of Mobile-IP. Thread-Index: AchwIDRYO9aVCJshRRyA7PNzRnbzDA== From: "Ivancic, William D. (GRC-RCN0)" To: , X-OriginalArrivalTime: 15 Feb 2008 22:15:06.0256 (UTC) FILETIME=[381A2100:01C87020] Subject: [MEXT] Regarding realistic deployment and operations of Mobile-IP. X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org (This message has been cross posted to Operational Security Capabilities for IP Network Infrastructure (opsec) in hopes of getting some response from firewall administrators) Regarding realistic deployment and operations of Mobile-IP. Two documents were review: Guidelines for firewall vendors regarding MIPv6 traffic draft-krishnan-mip6-firewall-vendor-02 and Guidelines for firewall administrators regarding MIPv6 traffic draft-krishnan-mip6-firewall-admin-02 These two documents provide a "technical" solution to enabling Mobile-IPv6 to operate through firewalls. In all cases, some security has to be relaxed to enable operation. In my experience there are three elements to all network design: the architecture, the protocol and the policy. These two documents assume a firewall is in place for security and how to generically configure that firewall. Item #1: ========== Perhaps a document is needed to address the policy and architecture portions of mobile-ip operations. For example: If my policy states no IPsec can pass the firewall, IKEv2 is dead and so is MIPv6 which uses IKEv2. Now, if I architect the network such that all mobile units allowed to operate through the firewall are on specific networks within my corporate network, I may be able to get the policy makers to modify policy as I have reduced the security risks relative to the overall corporate network. Question #1: Is it realistic to believe that security policy will be modified to enable capabilities such a mobile-ip in a corporate network? Item #2: =========== Regarding the admin-02 document: If the Home Agent or Mobile Nodes are behind my corporate firewall, I have knowledge of what network space is mobile-ip "allowed". As such, I may be able to convince the security policy makers to "allow" specific signaling to specific networks and be able to realistically manage this as filters would be via network address rather than host address. Also, most initial communication from the mobile nodes (MN) is outbound first. If the Corresponding Node (CN) is behind the firewall, and the mobile node initiates communication, I suspect that this is an administrative nightmare unless all CNs are place on mobile-ip "allowed" networks. Question #2; Is it reasonable to expect a firewall administrator to manually manage firewall rules on a per host basis - particularly with regard to CNs inside the firewall? Item #3 ============ Would a vendor consider implementing the firewall-vendor recommendations? If security policy would not permit such operations, the effort to implement the firewall-vendor recommendations provides zero return on investment. It appears to be a classic chicken/egg problem. Comment: =========== Until something like dynamic firewall technology comes about, practical management of firewalls needs to be considered and intelligent architecting of the network may help. The firewall-vendor document actually does specify some cleaver ways to partially dynamically configure a firewall. The owner of the Home Agent and Mobile Nodes has knowledge of those hosts and routers and therefore has a reasonable sense of what will be allowed through the firewall. The corporate network that is protecting a corresponding node has much less knowledge. Thus, communicating to CNs that are behind a firewall seems much more problematic without knowledge of the MN. /will _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Feb 15 15:38:27 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81D463A6BB8; Fri, 15 Feb 2008 15:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.663 X-Spam-Level: X-Spam-Status: No, score=-2.663 tagged_above=-999 required=5 tests=[AWL=-2.226, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88mYUVDzeLMh; Fri, 15 Feb 2008 15:38:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 805A63A68D1; Fri, 15 Feb 2008 15:38:26 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5194A3A68D1 for ; Fri, 15 Feb 2008 15:38:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RT4jo7lYZa12 for ; Fri, 15 Feb 2008 15:38:24 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 2A1D93A68CB for ; Fri, 15 Feb 2008 15:38:24 -0800 (PST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 15 Feb 2008 15:39:44 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1FNdiox027724; Fri, 15 Feb 2008 15:39:44 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1FNdLKG026766; Fri, 15 Feb 2008 23:39:41 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Feb 2008 15:39:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Feb 2008 15:39:40 -0800 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC52057B7F9A@xmb-sjc-235.amer.cisco.com> In-Reply-To: <200802121631.35572.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [Recharter.2] Thread-Index: AchtjOWPBGhV19OmSbGjI2XOVrHpKQCfhtrg From: "Kent Leung (kleung)" To: "Julien Laganier" , X-OriginalArrivalTime: 15 Feb 2008 23:39:40.0475 (UTC) FILETIME=[089280B0:01C8702C] Authentication-Results: sj-dkim-2; header.From=kleung@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [MEXT] [Recharter.2] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien. Here's my list. 1) [E] GRE requirements for IPv6 mobility 2) [E] Virtual Home Link configuration for Mobile IPv6 3) [R] Binding Revocation for IP Mobility 4) [C] 4283bis to extend MN identifier to other identifiers 5) [R] MIPv6 home link operation in various SDOs Kent -----Original Message----- From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Julien Laganier Sent: Tuesday, February 12, 2008 7:32 AM To: mext@ietf.org Subject: [MEXT] [Recharter.2] Folks, This is the next step in the recharter process. We'd like to get input from WG participants on what should be the items included in rechartering, what are their priorities, and who is willing to sustain the effort. When that step is completed we will take the WG input and discuss with our AD to move forward with deciding what to include or not in the charter. Your input should be sent to the list during the following two weeks, by 2008-02-26. Please pick from the list of items below the items you think the WG should work on, and order them in decreasing priority (just to make sure, first priority items goes first in the list you're making :). List of items: Binding Revocation for IP Mobility MIPv6 home link operation in various SDOs IP Tunneling Optimization in a Mobile Environment Generic Notification Message for Mobile IPv6 GRE requirements for IPv6 mobility 4283bis to extend MN identifier to other identifiers Mobile IPv6 Bootstrapping for the Authentication Option Protocol Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions Virtual Home Link configuration for Mobile IPv6 Extend DSMIPv6 Home Network Support A _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Feb 15 19:29:52 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3C533A6947; Fri, 15 Feb 2008 19:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+IxBZcF5XNS; Fri, 15 Feb 2008 19:29:51 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD7423A6BDB; Fri, 15 Feb 2008 19:29:51 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8DE73A695D for ; Fri, 15 Feb 2008 19:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xm6EFkoj1iwQ for ; Fri, 15 Feb 2008 19:29:49 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.184]) by core3.amsl.com (Postfix) with ESMTP id 7026A28C156 for ; Fri, 15 Feb 2008 19:29:49 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id i7so784646tid.25 for ; Fri, 15 Feb 2008 19:31:08 -0800 (PST) Received: by 10.110.60.2 with SMTP id i2mr2827857tia.11.1203132668365; Fri, 15 Feb 2008 19:31:08 -0800 (PST) Received: by 10.110.3.13 with HTTP; Fri, 15 Feb 2008 19:31:08 -0800 (PST) Message-ID: <1d38a3350802151931o32910313j254f10e1bfa9cd12@mail.gmail.com> Date: Sat, 16 Feb 2008 11:31:08 +0800 From: "Hui Deng" To: "Julien Laganier" In-Reply-To: <200802121631.35572.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Disposition: inline References: <200802111135.44252.julien.IETF@laposte.net> <200802121631.35572.julien.IETF@laposte.net> Cc: mext@ietf.org Subject: Re: [MEXT] [Recharter.2] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, Julien Here is my list: [E] Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions [CR] GRE requirements for IPv6 mobility [CR] MIPv6 home link operation in various SDOs [CR] Generic Notification Message for Mobile IPv6 [CR] IP Tunneling Optimization in a Mobile Environment. Thanks -Hui 2008/2/12, Julien Laganier : > Folks, > > This is the next step in the recharter process. We'd like to get input > from WG participants on what should be the items included in > rechartering, what are their priorities, and who is willing to > sustain the effort. When that step is completed we will take the WG > input and discuss with our AD to move forward with deciding what to > include or not in the charter. Your input should be sent to the list > during the following two weeks, by 2008-02-26. > > Please pick from the list of items below the items you think the WG > should work on, and order them in decreasing priority (just to make > sure, first priority items goes first in the list you're making :). > > List of items: > > Binding Revocation for IP Mobility > MIPv6 home link operation in various SDOs > IP Tunneling Optimization in a Mobile Environment > Generic Notification Message for Mobile IPv6 > GRE requirements for IPv6 mobility > 4283bis to extend MN identifier to other identifiers > Mobile IPv6 Bootstrapping for the Authentication Option Protocol > Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions > Virtual Home Link configuration for Mobile IPv6 > Extend DSMIPv6 Home Network Support > > Also, please prefix each of the items in your list with the letters E, C > and/or R if you're willing to: > > - [E]dit: Are you willing to edit the draft corresponding to the > item. > > - [C]ontribute: Are you willing to propose text for the draft. > > - [R]eview: Are you willing to review new revisions of the draft when > being asked by the chairs. > > As an example, that could be one input list: > > E MIPv6 home link operation in various SDOs > CR Binding Revocation for IP Mobility > R IP Tunneling Optimization in a Mobile Environment > > meaning that the MIPv6 home link is first priority and you volunteer to > edit, Binding revocation is second priority and you're willing to > contribute and review, while IP tunneling optimization is third > priority and you're willing to review. > > Hope this is understandable :) > > Thanks. > > -- julien and marcello, MEXT chairs > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Feb 16 05:22:41 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 601DB28C1AF; Sat, 16 Feb 2008 05:22:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WOO2dqhueVQ; Sat, 16 Feb 2008 05:22:40 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EB493A6A4F; Sat, 16 Feb 2008 05:22:40 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A34C03A6A4F for ; Sat, 16 Feb 2008 05:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nD03sm0Zx8T9 for ; Sat, 16 Feb 2008 05:22:38 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id 4994B3A6A3C for ; Sat, 16 Feb 2008 05:22:38 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id 16so756052fgg.41 for ; Sat, 16 Feb 2008 05:22:36 -0800 (PST) Received: by 10.86.28.5 with SMTP id b5mr3717483fgb.47.1203168156690; Sat, 16 Feb 2008 05:22:36 -0800 (PST) Received: by 10.86.35.18 with HTTP; Sat, 16 Feb 2008 05:22:36 -0800 (PST) Message-ID: <729b68be0802160522k5d4e2f3ndddcf2ca61c1340e@mail.gmail.com> Date: Sat, 16 Feb 2008 14:22:36 +0100 From: "Jean-Michel Combes" To: "Ivancic, William D. (GRC-RCN0)" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: Cc: opsec@ops.ietf.org, mext@ietf.org Subject: Re: [MEXT] Regarding realistic deployment and operations of Mobile-IP. X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, 2008/2/15, Ivancic, William D. (GRC-RCN0) : > (This message has been cross posted to Operational Security Capabilities > for IP Network Infrastructure (opsec) in hopes of getting some response > from firewall administrators) > > > Regarding realistic deployment and operations of Mobile-IP. > > Two documents were review: > > Guidelines for firewall vendors regarding MIPv6 traffic > draft-krishnan-mip6-firewall-vendor-02 > > and > > Guidelines for firewall administrators regarding MIPv6 traffic > draft-krishnan-mip6-firewall-admin-02 > > These two documents provide a "technical" solution to enabling > Mobile-IPv6 to operate through firewalls. In all cases, some security > has to be relaxed to enable operation. > > In my experience there are three elements to all network design: the > architecture, the protocol and the policy. These two documents assume a > firewall is in place for security and how to generically configure that > firewall. > > Item #1: > ========== > Perhaps a document is needed to address the policy and architecture > portions of mobile-ip operations. For example: > > If my policy states no IPsec can pass the firewall, IKEv2 is dead and so > is MIPv6 which uses IKEv2. Now, if I architect the network such that > all mobile units allowed to operate through the firewall are on specific > networks within my corporate network, I may be able to get the policy > makers to modify policy as I have reduced the security risks relative to > the overall corporate network. IMO, this is already the case (i.e. base your security policy on the HoA, or more precisely, on the range of addresses from which are based the HoAs) > > Question #1: Is it realistic to believe that security policy will be > modified to enable capabilities such a mobile-ip in a corporate network? IMO again, this is an optimization (e.g. the FW could allow, in a first step, only IKEv2 exchanges and incoming BUs. After, when the FW sees an outgoing BA, it allows all the rest of the traffic for the specific HoA). > > > Item #2: > =========== > Regarding the admin-02 document: > > If the Home Agent or Mobile Nodes are behind my corporate firewall, I > have knowledge of what network space is mobile-ip "allowed". As such, I > may be able to convince the security policy makers to "allow" specific > signaling to specific networks and be able to realistically manage this > as filters would be via network address rather than host address. Also, > most initial communication from the mobile nodes (MN) is outbound first. > > If the Corresponding Node (CN) is behind the firewall, and the mobile > node initiates communication, I suspect that this is an administrative > nightmare unless all CNs are place on mobile-ip "allowed" networks. > > Question #2; Is it reasonable to expect a firewall administrator to > manually manage firewall rules on a per host basis - particularly with > regard to CNs inside the firewall? Maybe, you can: - just allow MIPv6 signalling in a first step and after a BA, allow all the rest of the traffic. - just put CN in a dedicated DMZ in the case where CN are usually used by MN (e.g. WWW server) > > Item #3 > ============ > Would a vendor consider implementing the firewall-vendor > recommendations? > If security policy would not permit such operations, the effort to > implement the firewall-vendor recommendations provides zero return on > investment. It appears to be a classic chicken/egg problem. > > > Comment: > =========== > Until something like dynamic firewall technology comes about, practical > management of firewalls needs to be considered and intelligent > architecting of the network may help. > The firewall-vendor document > actually does specify some cleaver ways to partially dynamically > configure a firewall. The owner of the Home Agent and Mobile Nodes has > knowledge of those hosts and routers and therefore has a reasonable > sense of what will be allowed through the firewall. The corporate > network that is protecting a corresponding node has much less knowledge. > Thus, communicating to CNs that are behind a firewall seems much more > problematic without knowledge of the MN. Sorry, maybe I missed one point, but what are you waiting for exactly from the WGs? Best regards. JMC. > > /will > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From jrruss@att.com Sat Feb 16 13:05:56 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94AE73A6A8E for ; Sat, 16 Feb 2008 13:05:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.977 X-Spam-Level: X-Spam-Status: No, score=-18.977 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX_IMAGE=3, DYN_RDNS_AND_INLINE_IMAGE=0.001, EXTRA_MPART_TYPE=1, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=1, HTML_SHORT_LINK_IMG_1=0.001, MPART_ALT_DIFF=0.739, MY_CID_AND_STYLE=1.54, PART_CID_STOCK=1.635, PART_CID_STOCK_LESS=0.384, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_GIF_ATTACH=1.42, SARE_HTML_IMG_ONLY=1.666, STOCK_IMG_CTYPE=0.907, STOCK_IMG_HDR_FROM=0.001, STOCK_IMG_HTML=0.001, TVD_FW_GRAPHIC_NAME_LONG=1.08, TVD_SPACE_RATIO=2.219, T_TVD_FW_GRAPHIC_ID1=0.01, URIBL_BLACK=20, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMnQoPxPA0nr for ; Sat, 16 Feb 2008 13:05:56 -0800 (PST) Received: from ppp91-76-200-189.pppoe.mtu-net.ru (ppp91-76-200-189.pppoe.mtu-net.ru [91.76.200.189]) by core3.amsl.com (Postfix) with ESMTP id 6E59228C1C7 for ; Sat, 16 Feb 2008 13:05:47 -0800 (PST) Message-ID: <000b01c870df$01d1a857$51206b8f@gpeqomn> From: "clarance heidi" To: Subject: to: Date: Sat, 16 Feb 2008 19:18:22 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0006_01C870DF.01CCED42" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C870DF.01CCED42 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0007_01C870DF.01CCED42" ------=_NextPart_001_0007_01C870DF.01CCED42 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://ginestice.com ------=_NextPart_001_0007_01C870DF.01CCED42 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_001_0007_01C870DF.01CCED42-- ------=_NextPart_000_0006_01C870DF.01CCED42 Content-Type: image/gif; name="wandercum.gif" Content-Transfer-Encoding: base64 Content-ID: <000801c870df$01cced42$51206b8f@gpeqomn> R0lGODlhLgIjAdUAAKRxTdEhJciVbunIuNeqjLeFXmIICOW8qa6ZjY1dPKITFNfT0WxaVHVLLtK4 pQxu3uKymtVMTSoeFtKff+61xqp8ee7Y1n96f9GboLQ3Orexr9zb28jHxteOiFs5JEU4M////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAAuAiMBAAb/QJBw SCwaj8ikcslsOp/QqHRKrVqv2Kx2y+16v+CweKy1mM9oNHnNbrvf8Lh8Tq/H0QOHfn/o8xdmdoKD hIWGh4iJikp4fnsTkASSf4AWi5eYmZqbnJ1sjY58kpAFpZF7gJ6qq6ytrq9zZ3mikbW1pqccA5aw vb6/wMGtaXnFj6O3AqQAAAXKeru8iA/U1MLX2Nnah8SztATK4eLiAAkAEw4Du4rV1tvv8PHyW92h oaSl+frKBQkJAtA2JGr3YJ7BgwgTCql3DxmkcfucQSpXIOC0dgozatzYS5Y6Yw0f8tNHMp+AfgCg XazGsaXLl4vMFIt2D2K4kjhLmZOUqhBB/5hAgwp9IzPdRz72HEKM2CwfM4uEfg6dSrUqFpkWjh77 phQis1JN9UEVJNWq2bNojYBKqsdW1wm4TjKbG7ZiuqgY0+rdO3RDJW+AtUJA5iwuXJJyzVHMp5Js Xr6QI2f0uzWpSLeHTWZmysxfYQLr7JSVTLr0tgUa2iKYFNIh68EnNd/8SrecuWeh6Yw2zbu3ItQc NCBAwAEJ5dXgACL1pnrc0n0iwXaejlv0Y9/Ys9Pxi+ACg+8fwjNAoEHgkA0OhicP9/oYPuixZ8uW bnvuM2lydmvfzx/McfDhBSjgBxeYl1oCzpTTDGgfefQISnPJ9px8BdSmTHG6XdffEwF06P9hBp0Q JOKGv6HWHQMBSqCiBAN+oCID5QmHoAANeHBOOmk46MdJ/vhT10nPyNVMbM1YeNcc+nXh4ZJLLOlh k04GAEuUUmoi4pUskUjIBicOuOKXKbIo3nBOFYkgeeow9EhiPeK0zI8VegYafm8kyQWVVSJBJZRO ThllJlgGmqWWdHCAAIrhfanoooqON+RmPS6Y5gKCKRWnYogJGWFh/qxmXhx2bpHBnkmQqqepraA6 kKCsEioHet4hmiijtK5I4KOERYqbOlw5d+lXmlVooQDMoIOkhl+oSgSeeRqh7CrP+sRqq666ASuA AtaqLYtNIXcUAhVIxBqvb33GT30RCav/LmN0thHqFtGCwGypf/rZJzuBFpFvtZ901+Ks29b6QQPO oJJVHqc4kLDCN5HUFDpw1aaPxPflh6wX8c576r2vxGvdlUmAzO8Y1/6rIsABgxneP0b1IYvCOxa8 Y2w5iSssXWWa5EC7bLyrBZ4b1+usx5wQfazISvg88hUlezmriyenDOaNH0VDKbmwyezQxGF9NZLE Nxe8gMWDihEts80OYfQma4OK9BIXL51F0/+i7KWYKE8NQR8NOrgekLacS1/OQILVo4+mDEC2O2M8 i3baQniMdhVAcwi00RqH8TYTZZOB5RGfU0V33S6W3mIDDfhTI60pVT3py3+Le1mF9AG7/2mZhy/I s+dxKyn0spMPzXERjz8Z9JOjBq9E8RkzTy/Hvw8ROhWbE7E5yNQKkT1Qo5MeYOq5YwoAora+yLfr 9UQnO4VzIX5zbbb5SMDuYyidReXAZ66248wbT3z/0fsfAP0nwP4dYU/4s96IrFA96S3QgdMaUQQL EhTUXKBFspLVyhQDtjitrlHns1qOKNWWzVwGArRrX6QMp5gWog5BioOD/e4XwOIVkICRGyAO5aVD Jh2whx364QCF6DwjNBAKRwTB9SbIxAe6hEve8Z4GU1eXdI0vbx8I4QgbQRjDLON9kapN6uLkAQ+k jjj0A8MMsaCq5D0pesoCIuTkGEThAf/RjkO84eOMmEQnJHGJTQwkBV/CgVhh8F9jdA7gEuMBRu1N i1sk1y0eJZGcxW9TYUmAmMyBxjR2YY1XUNWf4EhKVOmPh5lLYA4TeEr9tRKAfAQlEv7oRCUKSnvT wmUfDwLFASEKWy+swDNgE53ZfPBLCEBfJIsSOy9akoMppF0DVkTFZFbCk1mQJeVM2adS+nCVNWSl KlE5PHJ+U49pG6cq86hAbcayd4Cs5S3b6c5sFBJb4hHQd27zSEck41w1gtqKANC3La6FmJfxCvzo A45GiimRlDjDF+o5BW4yyVSiPJtFywnOc45zf8P7qDnrCFKRQrB3T6DlbqZHz4vtch7/1/qlBlcm zMGEcDBbu0kCjqmiBijToC9DzlvWk0LqVEgAFqgAmIJJJvUERKJaoKgUMHovqpZTcr9r3pJAVNId 5s+jAewqAfHEVbjVcgoq1dAR13pWhaAHQCiaYgUY5Dp/dhGgZVRUPwsayQn4AwIHy1qQwtE1nDnj mGYc4/vEBQ0RYjNpKPUd9Cb7zY2eE4/+0ypYOfrVsXK2syQdaWghK1VdwlOebbWlnV4qDy7JdEAN OEddeWXXUVSyHzyVAEEhGclDJYBBGMDAmoYpH7qYY6d5PdkLi9RBpzb2mlIoLRSsmlnKbvayRKzu Z0Ur1tGicwhu9Cpom9U21Ua2CWnt/xxbV5tahGwgit8BJtVmaxn1kTG5LPppI7JCoxtVYHzfia1y JkFUMZojoFDzADR/ZdhFCve5gUDvee9UL6FV2JviHW93n1fZsGq4o3L8sISlm17GmbZzJ0XxiU2s EQ7EdYoMaN1a6opT29Isfg6VgDVfh5WPYKBwCLrABSXwnbna9VzGBR9+bXSzw/nIsOECnHN1EeGQ TRheo7Rwlq/qYRFrVrvY/S6I77hhP7Y3pe2Np4rNu2bWwsO1+TQjALzFEBrX+D3wc6hPD7Dfg0mS WOEyg3fC9WB/FrccSs4xk+MHvjAOLlz5CC4GKEBpSlf5nYNcAwK5fFEMexezefoySf+JRl06iphz ZzZzqNTM4hS3esWZnsyQwwNRx3rEznfejBgd+hW64rpwGFiIcMZ1ZE0BAHyoo+avavRCTDms15QO bri+gqZPtdQNm77slrXd5TJz93ij7va3RdvDU5uVxGlGLXvXfeV3LGDILBKwretcqS7C79g9RaF9 +FzX2BxAmFgjNmboc7jVydk2uGW2s3M2aQz818ndSo1f9NXun9lwvFEq65iZUOpPb/zjHAazHDVe XpaiNd0rTe16K66N9yaYZVgBKq4tNZ3j7lRFyTwAuJixmqoxbAJZQYpNmfkQmwmr4I1UcH0mcGzk xrYwNGv4tO8NafX05MRvKGJ3w7n/XW+LOtTi7jjkpituipe2xLFeeZtT3Vp4f8DIQJ1xbbvoZNWp 6L9m9NcHdqxzgNDEEVabRWYo2ZkeoY7WHDwJsp9+WwxYAANVpDqhd3ZtbO8RnVwPs5jHDWpvgxvs Xed42Vv6aiSiXK0qT710fcGlBO847gft59YQ3Wh/ONRFCACBBoT8epxS2aAIi9i6WKg6hQMLLi9c 7jgo8N+GgdGwncS65ZWHceyaFORf93x2wx16Pml+lm4G/6rVHTe1l56XCHA9X2FfbwL8F8Cla7bq bl+BSqQm8OjgWyRjFrYkF7+MwCIRO+V0lJRU51A4tfNk1IZG0jd9H3VxGLc8Yhdy/9zXdWI3dk5Q Xmy2ZuLnarFGemmneuXHdvEAZ0QGdDzGfj43GBWAYLQmf4ZXOuEiVJNyAOOSBiBAdERCGyoUg7EV FuDQdMbnDBSAAQ0QHzfWgytUbWwGB5eHeeKFVSHVZZblcSDHeVGggRt4fmY3SGjXhWvHbhxoECY4 HgcDeyPEK4eiaADIQjh2d4CXFcykf2mIUzvYFPGDdFUUhIlGRQJAAQSDhElYeLlTAeQhEKuXhdS3 dVGoUVlFhY/oYeI0esljbqj2UmVhcrAWgmJYeuH3DhqAIiyCgmhYh4eiMmU0IwgXPyrSOkYhh0G3 V3VoWzxILHlYfA+DCwN4eGb0W/8Y4AGLNIiEWIgSl4hkJ1JPCIWgFlrZt3Xbh0PXN4Xdh2mnlYnV sy8eKH4jaIywUEilszOlmIZGeDK0JiBjVBu2xyJ7gwdzuFc0hmdcU3eKNRKSkACJFVCog0Iz8hzG VXfNgCbcaDlfl2GutE6QyGla9koGGYnfR1qsVjbTsz1bqI1hyHItt4ZZFI5pCADmmGBG1Y+aJAF/ yI7taIMyY2g1c4uo8zDE8gz2mFhlZEaAiCv8eIs9cgGG6AABmYEmdUrLCIHaZ2505F1DaYkjJkgQ iZQsZn4fCGuEdEF7B4saaQEOwJG8mFxzNnwE10h75hFF4XcHIAD/IEld9GxOlkj/NxEOLxmTqQiI EuErYFR3CSBkhriTTeCTjOh97BSUQVmUPwmUWuiBTQSCTASGniiCY4gQoRhjKViKBGAbMXkBDsAA FwAuwqI+heciBfB3ihNYj9SS/mQOCIMTA2h4/6Aci7SWbPlbR6hIwiiXdIkAdil6A4mB1YeXzQiF QHmb1BeYhJlLhlmYIEiRhzmbw3AoMDKVgVUhzOYBMfJjl0lMBKdJDbCOxQA7Ybkgj6BJjjeatONB hkcwBEZcLphXwnSa7GFfSng4dGmcemmFY2abRRBeZEWBGjefkrhHGSeBBrR51DOYxClB5FeRBMqF CXFPBaKRPkYsZYQ66sF0kmKD/w+hIJCpWzvCZzJxGBFqgxy5W96Jh/KXOvlnks9QAGzJlsJ0gJjx NcPYaDF2Ae5ZCIvYBlRyn4qIl/UzT5cYo5IBRdUZjiBBLDWCICxYU3uVNbfIInahDBm6bzvSoTXh FMmHOuLJb8lRj0l3osIkO+VydOHZaADAo3Izpuj3HWkoHA/6SMu5UwsyTIAneMTypdzSAYmDQuzB X8WyMJKgD6VJpUeYJrABG/bIIlFjI3Tqprl2hwVXe2JKpo4aD96IALCYHlFEUxWBf4sxopAkobZY fB+kdLtSFKVgg0V4IwTWZDvlp7/1d6ABDrklAQLGpYlqbF+6T436qLiqDbuXkf9UCZVU+mRwdzAQ CpY/FXyJ4acC5QF2oRT8lhXNN3u0h6wyRpWkikLTtCixWguzqqipyqgWmavg6hKL6azhcZ6G2IK3 IULZOV/ooxWdao+HpyirCgEdMGnX+Xi4khydkaUoiqHUyismyigKJkzaKntFh6qq+h23Gq4My3rp N1coshr/MI5792Pg2KS4EkIrGDHzF69gAhD2ihX6tqz4wJGECiaXagZzQpUBqyi0pqLtYYfcmrAM sLANe7Ou8G4M0ILJtCACshod4K9BRzO7clPREa2vSmSkGnxHtTeEgW8nejKbmaEyMQAFcK0uq2DD FLMF1qKNZpwk6BiZlphV8In/uISzBzpofUBQDGAoO/tjwkUMGhppKGmLAuh0OeayglWvLdMWzMmv bEkwGJoHsnC1AgurW2uwXctov1qz36pqZIsXCqQ5ZmugaGtPlTmae6Ya1vkytogzrrGD7gevSXsy cehnSIpcJ9pIf6U4CnMGrpq3H6uns+ql3RpfMWq5hpAlkfuf7WR6l3ugksqyOSehK9sIdqsMclIL lkkAO0G6WEsrO/OOPKJYjKusgkuVSMVfYolfisJYinuwXou7j4tmZ5sX6FsQj2ENjIN6JoZS7tC+ 6xuCtlS/oEO/C8S+6os96jUo+hu8nuAXZ6iGOFKH/bCktyGIKUEAwGiiDRom/47kZ+QiERQ6EuoS W/w2tWH5t6xDu7XLuM2WuxQ0QVs4wul7whhRYk5pvw7UhPdLcRP5EyS8Yg0IwJsgwJ4ptDmCMNqJ Eg4jLrcBk1HLKBXgc4lrQn9TLLtAhCbZD7K7Ir7ItTQHwv4gwroEQS3sv/rrhWO7v9bDwkrkkFd8 xUu5v03ZwlgMw0mZxqoFxltsw6tgCRI8b3jgfpyycArifv9GMM25urSidHJiaO9hEr2Gr34gLElb nR48xZ5qq+VrZmeLxueLv10soHyEZlysxpR8btaYwvQbyVnMv3A8DFXLfvSqE+AzdfZ4JukRW+U5 xGCyVFQ0nd36f/9gAdr5mP+I9sTAqKnhm4S3ywAJYMVu3MVgXL/vy79aHLnyq8nO7JDJLMOffMxb LM2jzArsJ7e45RmGM7CZgberm1emE7hgGoC1Q4hU+od5+q4x+SWI+su407hh+sgSBsrFTM1eLMmG ScOQpc/IvMn9HEuhDMP2/M8vfM3YvMOTkoNDe0ndnKfvhyj4GM7keI8rBB9E+2wUAQFew0K8eHcE Vl8zCz7z3Ltla8KTO9CTm8yodskBjc8wbaCvxtJl7M//69IIHccKrc3TsaVs2gG+aBsTTc7hLH8/ Uq8JldQTUxj39n8SEMWy57SYOYzmQMwsrdKRHM1fbMzG/NLL3MZkfMb+bM//Ny3JNQ2Rx5zTnLDT oHAY4EKvFMF0vyWWu2xGRC3EDXrRsppr5WLB51x4zLbI0knLwlzSuvufTkTTIlPG0tzYkRXN82vJ L02Y+JxyTnnYap0I9VDK6hBcfoArO1EBPlLUfoqsRv2Wgs3XCfV8eEh7EHOkMruDjWzYYo0FLKXY 1ohpJ0VP9Vx5u13W4KeNBr3PKe3CmJ3Z3NBnNAawcxVcdA0uA/vA5FzaCocp7GFTbFFfjLxcUjpg Ub01tvurNtvbyF3ea3Br9NXZ9Rpto3uu8RW49/irX2rdC/OmNyXSHcAm8t0mUgzegC3e9DxRtW3e BF4GV/NcIOHZleZw/8U1/6S936maeHzrjul934m6nsi1wN/t30IN4CbtLgNe4CJeBVXbWPYQQpBX GOcq2sdm1/ENg7mTrxpb4bQVEnTK2gNYYzYu27U8zAHuBcc94kLeBCXe2d7SrBu8pYYILgjQ4tMN 4eiCCzdI4+0X23eoQv1tbx3+QuM95F7eBugdtzXIqYI4HE7+4rW3UOC7qVS+4TWpOr5cbDzu4UH+ 5XaeCXXcMjXu3Dn5c03OAMxG3THeYAnTmG3+y4OYqnH+wSrpuB9+55B+CTg8E3N8pTMzbYCO5oPO XLJq6BXutDpuKWAEjNiN6MQX4V0e6areBZXOHMsRM38u6IO+1Ii6foJxPv93ptoNk5nL6uYly7iO XuerPuxbkhrDtgfHDhiqIdqyroBVJOUUXrVasYK5HrriqzoaXuqi3oOpk+rE/u1M4+rG3reCx+zN fjsSUuiBV+MW7uvbzgypwxbvzmjBHuLgfu+GEIvILgp70OQwju7pXt9j7uq33hpdimjzCupdgTvF 5+34/vBSQJXjbmjgEkY9HfDpqe6fjuvyjhmxU3gbvvDh7eOPDvEmfwcDQIMK834sP4iu6fHRzu4z zvGq/cE7leXii871fvI8HxOTYJl9vtrQbu0hHfPa3u7anX9lCe+LPu956PA9H/VJ8K++JnhDVe3I ENW4NvM0b/Cxjcjeva3/DN8jUC/1Zl8EM8H1MovzsG20FH7oc6flguvrr0n2P372eH8Vek7txqvt UmzfgE/lM/dI4H3ASU8zCEvywp73jE8Pey8Y73zib8/xxSr4ki/qRBryzgeSZd/4Z78Bn17rkq/2 QzfH7Qr3tSuaBo/4qKr49u75sM/qPpf2oj/6an/6uL/xCp/zq69rPdj5sR/1/1rlFF7qt7/ulj/t Xa/lh4/4v3/3wR/9jDALg6+xk6/8yJ/8fC/nwtL8iV7F0C/94k8EqEv61s/1uY/e2n/5ItEM3l8m 8QP844/vy430XZ/+lY//uh/b7g8EByGESDBOkAJloQBwJhIPqRRUtV6x/1ntltv1fsFh8ZhcNp/R afWa3Xa/4WHLgF4f2u9CvL4+9/cB9wIF+fKKkgAKDI+SlpianqKmHuIqLS8xMzU3OTs9P9UIC0dJ B/9MT0VVFxEVhw4ZHR8jJylBb3FzdXd5e30vV0uF8VJRiweDYQWYXpUbl2ehJKd+q62vsbO1t72O k4ORw8W/m5GYm51lI6epuN3f4ePl57/Ahwm984nH0dHNXcvFUkdrEj2DBxEmVKgJH799xvQ1dOjv 3550A6HUWriRY0ePHudIFOkwIkmL/Q6do/gMGqSMBT/GlDmTpq+RN8eVzEkuJcCVz5gQpFaTaFGj R9c8VLoUYtOQO5MdWv/GSiBGdraQZtW6NevTAV6ZQgXrh2xZnSdRmiMyqmpLoe24xpU7VyFYe06/ njU7EeVaZX5/NnJ5lW5hw4e12cWJ99hex47R9iUgAHDggRoRZ9a8MUBnz59BhxY9mnRp06dRp1a9 mnXr0bVcx5Y9m3Zt27dx59a9m3dv37+BBxcuG/Zw48eRJ1e+nHlz58+h7y4enXp169exZw+w+SNm 7t/Bhxffxvt48+fRpy+fnn1793TXv5c/n37M+PXx59f/7v5+//8BxKW/AAks0EA3BjxQwQUZ7CLB BiGM8MAHJazQwvwovFDDDdWD6Qu4QADRPqwOEtEKErEw0ZIMO1KxDBT/OcyFRRBd5KhGhW7kJEea dvwQxhhvmZFEuGrBikYjMzzyRO+U9IIKD0Msr8glo+xRxHamXPLKLKuAMsoqh6Smxy+z4PLJoXz0 cosziaQESi7BJLNJMNtkEchKhMySRir5nJOLJgENM80+BSWzS1vQ3BHLQw0Nscwfa9wSSUYP/THF IhEt1FBFhwQj0UkpDVRLSkPVtNE7g1RzTVMr5bNUOFe9AstC/YyVUD0xJfVULRY9FU1XZbXUV1pZ /RPGOYX11EpNLRWV0GB1fRRVXYSEtlVHn402jFmB5RZYW0sF91JrHUT01S6lTZdXFJ2tcttjmTVj qGS7NVJcb8PNVtxp/z+pVl9stTR1zDeJHdXJNnXFV85i13VTYXjXjXZLcgsaGGJX6Y34RGVBBXhc fedFMlNyF+bXE39JzZXkSn/18VGCz3QZ5l/NZFjdOmHClN1PcV35W2Mb5vlFWCP2sOWAj4yZ5U3j U9XkS+z8ZcwJO11o6qe1irqXq6l2eh6usT5K613ADhubss2uaey02W6bP6/djlvut4+e2+67z4Yb 7735BmXtvgEPfI2/BS/c8HfrPlzxxYdOnPHHIV/V8cgpj5zwyjG/W+uMyUC7RHXtg+Nyay6WN/Oo PTfMxNS3Yf1jj1bnXOPK85zZ4oltnzT3YHdHmnOVv+w9TZ4dFvlTa//ZNH5y3lvmGs6a2fSdSr1Z Pl544B9HvfRdgeb9X4TzDR/gdrmf3eCSfwYd1JHJn7Xj8u/NlGj1R86WfWLfL/fl71+nXHv6xTCx f6VIck1L2s7mZ76EyU9762NU++q3wDH4yXnNU1mvkpczm4FOgpfa2emo57Na6Y9kCiOgAr3nsfOh LXbIk50H0RWqBxbsexs03wgRlz45zTB+7wLgtT6Iuf+hT1vdq1cHVXjERr3vYbLzFgRdtjEZBo+G 7lpiFY14xQli8Yk8rKEPiRjGILoubZujWZIuyCwmueh50DtjCAOmRDo5sWfYct8bHYbEpXHMgp2T 0hpjeEfwFbGAcsT/XpwsB8fMLZJvo2PkI8PmSEhOclqSpOQlOWRJTG6yQprk5CcZ5ElQjrJAoiTl Kf1jSlSusj6qZOUr3eNKWM7yPLKk5S3BY0tc7jIzuuTlL+GjyBa9sHHL02PWjAm7NJARb768BjN/ SEJCIgWa7khdNeeGMqYZzYYzRJjw4tRE6Y0ThdGsGcXQiE5u+ixoLVyZIJmovN+NEZDc/OPM4Oc/ OEJRiwfrGPjaFTIXDvRnydRZwpSIw/6Js5/STKIA7yerhHZzh1SU6LUaOtHzPVKbDFVoCe11wwiK caTM89LURni8W1GInx9tGAcxiEBDJnOKkpLjrg6aUUbaCV/8dCiR/3rYT/Kxk6giNVgVy9ZTLs7T XP2rqPtiKL6Ndq9+87qpO6PJUWESjKBWLNc/g1qnlHmUoj8dKQIFRkcKRtCYe3KquwQqxTje1FjF Q6gen4hUbMrNjC/DYz69KbICHnCbeaxemNSEUjWuJ3ZbhRc+l4WZnDLNd0E0KR0xVkeJ4ZGwe43b EDHhWfOIllrEBGZpaQpY8pgWQ6y1pmtPmyqakvatVBtRbDmxAd3qVl7CxO1vQbLbBQxXuLxFHG2B m9xqFHcDVmDucPkIW+VO1x3FBQFvn2vdryKXut31hHaxy9wqCHe70vXueXuxWyyoN7zGVW9duYte +cJBu85tbn3tC/9f886Xv7kFL3nDm4X3+nW//TWwJcQ73udet7kCNq4H43tgCcvhvwpuMIO3MGCk TZjDuliwhd374PVquHqdW63UOKgGzxY4b6nlhdPY6FsCs5g+H14wie1LYtCqmMaD256P4xDhk/XY b6ZlpksPlF0QN5i8Dm7yhqN7wGUh8rAzDSHwkndZZVF5jlo+bIHbuE4dQliAYByrmMPlWL+WM4EH uxB7L/ze9mYYv3TaYlYlx78OIrmgAKWoSn2qWjOTdIBhPaRRharGMad4s5oV9FQh9GEGyxnHk9Yt Bwh854VmLKWDXFib3xooUO8Zy3WD5kmxt8+0alp8DE1iAJsFqcf/8pTI77mxBXCN6yVrobgcuHCJ YY1nRFtRr2fAahgHbcKXFhUNKi3klukaRU+7WroxRqHnhPyd7OZa15b+9YgZ7Gsya9rVWXwYhEEK RrIyG6Pr1mizl1roYT+aeeneplyHti9t8flO2eXAvx3g625X2tL//rYZpTxPdaJ6xluctjy3DE6i ybjh5OQ3rJI6687Kz4+4amM7iZntzQj3AB2IQAZEE4EIdAAC3eb1pQ0+7g6LrtannQMGKpABlJNG 5xGogAMs8HKYi9ukM3+DyFdpAQwAYOepUUAGOjCAEQtXA5iW+X4uACGko3IAGDi5a1Te8hxfuuqZ 9k/Wjf7mDmRA/wFgV/nKpX5fshO96GlvkM7wnne9753vfff73wGPqQs0vTVvV7kihAtwvts9lIF3 /OMhH3nJ4z0CbXe74X2eF7IvnvFdm/znQR960V/A8pc3fAYqkGsOaOACnO98KUUfe9nPvu+lb00G MP921ON69a3f++sNRHvhD1/4F5hN7lWucwAMQPGuBz6AJgvlq3uZzXqvN7CvT2V77h3ltl8N8k+u 8wqsXgN9fz6BDr3HNT+7nHNkLM7yrP7t5934pImAacDf8wwkAAOsN//5oS9BHGdyBlBY8g6GMEqk 0mrv8A//kK/nFKABLsD/nA8A9eP9XidpNop40Mz9jsbThuVbcP+G/krj/hwQ83RO556OAcrv/yxw P+5psVbojCpLsL7sA+MJWSyr7zrD+zpD5UwD93JP/xQgAluwAvUrrmiu4qos2oINQVxLkcoMyHjM xUin5vLNzpqQsmbQ2W4GsdLvnwBps2qwFggvNEywBB8wBRXAACTQ7/yotpapj77IjqYJ2k7M2F5o CnmsD++wdbAwDrWwy6aJA8csUvBOrsSwA5uKzARPDU9jDdnQDf9OEKeHs0JuB5VqffYryyyueHQH ExnNVqqqnv5qBEMRBCcqeuZwnSAL4gKL+ghxaQTpE9lvDNvP+qJq4cTqhC4LUxIAEtVwCNmwDRmg Elmt3c5qD8f/CH0Mi904pg65ENCqBhr7xIvOJXyUkAuR7d1KKhmhShupjRO7iohChgPzB/twMfrK 0AvPTGh8sR2loP6Ojxgn0QB8zwUHLdFG7Z3cJM3IkApfhUmCKoWssaaekdD4kSBzkYa+EdYczd1S Br4ckaz+CmOyj6tuEN90EafA0CDx7QYn4Qw/w/BO8PRSMAMMYCUBzxJJDd4Q8NPeTQ/LMR7tjdhG Mc+2USK7MSR1yFkech9nUiFfLSatbaUsa6wM8o1qsF4miw5F0KZ+cRJIz/7ScBhRMgVX8hiR8QmH UrE2DYkwCCalMdbI0Sevxs/KcRPF0ojY8qnS0axeEojiBdEC/wqevioq8xJcJAV6YrKdQJL7RgMI U0MIdS8l2xAfWzIZG6ofPZCcZpHfzA0WvQpacoeBrmwRvRD+UBHSpC+cqkopHW4zjaewepEJZxE0 v+wWr4Qi+bIvty/7HDEw864CrJI1slLnVtIAAu8FobAw2HEQ3wTk3BIT4e8zV3MD884HY6PtDBMx 27ABetM3BXIuiO86sfPvEoA5S9IkQ6MIPePpUpLtEjMf4ZA6/TCYsnM92dMMB/MBT6MIx7MIDcAD HA89W6s99TM7GcAqDfPtSqMIBRQxt/I+8bOV9jNBh68qufMHUTA8ezAA2k5A5VMFWdJAD3Q+FHRD Z48BGtQz/v8TQiVUQim0RMmzPh8vQxGUQ1lU8gYPPE8jBUU0PEsUPNmuQDFUReWjRXn08dIQRp2O REm0Ris0MSFPR41OSJ/uQ0UDSCe0REl0JRGAuAhuEJFUwjZgQCM0QEd0Qke0B2u0Pz/AAFiwzqbv Sg1sAYi0S5s0QqH0SekTPI1R4KrUStG0vzRAQL9UTkHjSbtUPonUAIrwAwLgAxRgSqnUn7buTicp T9+0S9nOTSNVTok0TumzTBO1vBj1wBxVT/3US8G0Umt0N1dyTC+ATkUMMPEwE7AJxnIyLnSJuyiu GhY1Kzq1Ur+0BydVVNuwVwVVUBH1yQZLKFcEC1Xk2IAzEMn/Rll1hFkPQ01FdecsD04DVUB/lVQx tU6xz80Y0bw8cQtTs9FcURRtEZx6S/tAURa5J8zIVf3KtV37bFYvMeFksWIosz6ylFe3dEhFVVAT k1QVgAGoNFVVdVBazVvVUs/YqbHq0K1EUzLjjxstUrLiTaemMBzFCKbKqq4aVq+WUT9UUl+7r1pX 0ldJdTc/IFi11U4n85hcEp4YtraOTdn2xyc3kiwnct4aa412dl8CLQH3zQoNzeModuH+QwNKljx5 lWT/9V93cwIHNrqS7SxxtieBiNFmNihx0mbpbVWBSmd/bNn+MiAP9qhyUmjDsnyOMmidVSuy9Fc7 w1+t1VJ//zVOd9NpUbbqonZ41MopwaxiHTZ98motz+qihM3hMBJsf+hnL/Zjl0hjb9JrHfcuHTc/ LqBk5VZue5VufRVvTzZbV5ZlYyWxWEwHL/Nm56oxY/AcB6sT0xVoIXNdVxcMUbEzxZJo5y8po+gd 6TWObFc/1BRg/bVu7xZzT/Z4S1VvzbRg01NDatUonldDEMB4i5d4r/V6kbc+VTZ0RTcLM6lt5SJ6 NWQDGEB4qTd70bc+oXZ5h7V5N0R8eQR8sWYDxhR5PTd9sVV5hVVR5XdTR2kByhd/BVgC1Fd/uXdb /TdNOSCABRh5CbiADXi8IBJ+E5iROGB6H7iBDeCBJYABEP9Ab1G1mPq3gkFpAzSAASQghfH3gT/A gzXghVGVYPmWhLF00lhvTAk4hzd4hyWghRHggw1YhqWWhrGU6k74Aj4giZOYAS7AhWHY12IY3tCW iHGr18jvhbEY4P4tir+t4yiYiiuH257L4Aa2jK+rCr8YjCOnvbbtxlZritU4tto4wY5OXsWGtQzQ WXFnhN2MV7TBjkPLmRBDjJusi+sYjnOJj51KaQCRG9LYCQ2nWsx1dK0HXtn1my5yXuXpI2czFqWN h7p1dweSsH7xuDD54bzyXTdOlfM4kWYrYf/QqwaJJ8dRL5dygxpXGT+ZiqhWtWLqcWU2Ew2XGg8y BG8FZGr/mW316ZUJV5S/dsaO8xD7+Kpa2d747Jd/VmNKCgfbz2ATrZhz+ZuRMlGm2ZUtppnL+Znl 8Jb/pJwzChHT9uJYUQdjGS6vNpg7LqrouWvDmXIL0Z2zR9XQeS83xdAGml6kUpxtuWwFt5dJORp3 Emu1tluouYLiebEMC1lAqaPuFWjsqXXrlWdBjltIt3Ypc61mp9z4WTPP8f1uR4P8cYJzF5J/lwAV +UIE+VUbWSYemVVvmqJ5KafX2ZF/2qezQnwdk5SEupiv8Laoqaipa6njOO2keqpnrqqtmsOwOqsl bKu52sC8+qv5K6zFWr7IuqzP66zRurvU+pVE4wre2go+/wOuQSMMtiML7hoE5lquQ4Ou67oKOmML AlsLBluIANnACluv8zqx6RqwF/uxwYCxB3uyIZuvLVuw8xoLGPuyaeew+yuxC3uzFbuxR5uzucAz +Ho7QPuuV9u08TqzSfu1DRuRDyy0M7uvHZu0W9sLAlu1R3u3bduvUVu2CRu2XZtx2pqVcPu4FRu3 d7sLJju3gfuvmVuzjTu3i3uZe/qUgpu5pzu2T5u1pfu2WbuysTu8MTu9tRuqb+m5Rfu7zxu6YZuy z9u9r7u6Rbu01/tA7fuvp3uvv0CyH/u59Tuu4xu8ERxyknutefu+8zu/kduzGfz5FnzCcavCLfy0 MByUtAmjw5c7w6k4CAAAOw== ------=_NextPart_000_0006_01C870DF.01CCED42-- From mext-bounces@ietf.org Sun Feb 17 14:55:17 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 878DC3A6B82; Sun, 17 Feb 2008 14:55:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFKRs9lClBPM; Sun, 17 Feb 2008 14:55:16 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C8673A6ACE; Sun, 17 Feb 2008 14:55:16 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECC503A6856 for ; Sun, 17 Feb 2008 14:55:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrB1HhbJe4zr for ; Sun, 17 Feb 2008 14:55:14 -0800 (PST) Received: from mail.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by core3.amsl.com (Postfix) with ESMTP id C1F503A67EE for ; Sun, 17 Feb 2008 14:55:13 -0800 (PST) Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by mail.tcs.hut.fi (Postfix) with ESMTP id 33C8F2C020D22; Mon, 18 Feb 2008 00:55:11 +0200 (EET) Date: Mon, 18 Feb 2008 00:55:11 +0200 (EET) From: Wassim Haddad To: Julien Laganier In-Reply-To: <200802121631.35572.julien.IETF@laposte.net> Message-ID: References: <200802111135.44252.julien.IETF@laposte.net> <200802121631.35572.julien.IETF@laposte.net> MIME-Version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] [Recharter.2] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, [C] IP tunneling optimization [CR] Binding Revocation for IP Mobility [CR] Extend DSMIPv6 Home Network Support Regards, Wassim H. On Tue, 12 Feb 2008, Julien Laganier wrote: > Folks, > > This is the next step in the recharter process. We'd like to get input > from WG participants on what should be the items included in > rechartering, what are their priorities, and who is willing to > sustain the effort. When that step is completed we will take the WG > input and discuss with our AD to move forward with deciding what to > include or not in the charter. Your input should be sent to the list > during the following two weeks, by 2008-02-26. > > Please pick from the list of items below the items you think the WG > should work on, and order them in decreasing priority (just to make > sure, first priority items goes first in the list you're making :). > > List of items: > > Binding Revocation for IP Mobility > MIPv6 home link operation in various SDOs > IP Tunneling Optimization in a Mobile Environment > Generic Notification Message for Mobile IPv6 > GRE requirements for IPv6 mobility > 4283bis to extend MN identifier to other identifiers > Mobile IPv6 Bootstrapping for the Authentication Option Protocol > Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions > Virtual Home Link configuration for Mobile IPv6 > Extend DSMIPv6 Home Network Support > > Also, please prefix each of the items in your list with the letters E, C > and/or R if you're willing to: > > - [E]dit: Are you willing to edit the draft corresponding to the > item. > > - [C]ontribute: Are you willing to propose text for the draft. > > - [R]eview: Are you willing to review new revisions of the draft when > being asked by the chairs. > > As an example, that could be one input list: > > E MIPv6 home link operation in various SDOs > CR Binding Revocation for IP Mobility > R IP Tunneling Optimization in a Mobile Environment > > meaning that the MIPv6 home link is first priority and you volunteer to > edit, Binding revocation is second priority and you're willing to > contribute and review, while IP tunneling optimization is third > priority and you're willing to review. > > Hope this is understandable :) > > Thanks. > > -- julien and marcello, MEXT chairs > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Feb 17 19:48:19 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06EA43A6C4C; Sun, 17 Feb 2008 19:48:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-xXAtHWhQPT; Sun, 17 Feb 2008 19:48:18 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2B443A6B9B; Sun, 17 Feb 2008 19:48:17 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 116FD3A6B55 for ; Sun, 17 Feb 2008 19:48:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q22Arc5tI0dn for ; Sun, 17 Feb 2008 19:48:16 -0800 (PST) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 19C0D3A68D6 for ; Sun, 17 Feb 2008 19:48:15 -0800 (PST) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id m1I3mDHe020739; Mon, 18 Feb 2008 12:48:13 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb1) with ESMTP id m1I3mDi01820; Mon, 18 Feb 2008 12:48:13 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili06) with ESMTP id m1I3mCR19335; Mon, 18 Feb 2008 12:48:12 +0900 (JST) Received: from NW-Sephiroth ([10.81.113.116]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Feb 2008 11:47:05 +0800 Received: from NWSephiroth by NW-Sephiroth (PGP Universal service); Mon, 18 Feb 2008 11:47:03 +0800 X-PGP-Universal: processed; by NW-Sephiroth on Mon, 18 Feb 2008 11:47:03 +0800 From: "Benjamin Lim" To: "'Julien Laganier'" References: <200802111135.44252.julien.IETF@laposte.net> <200802121631.35572.julien.IETF@laposte.net> Date: Mon, 18 Feb 2008 11:47:03 +0800 Message-ID: <018801c871e0$ec597dc0$7571510a@psl.local> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 thread-index: AchtjL333P0KYouCQJ+w+EHv/8YzZwEVAfKA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <200802121631.35572.julien.IETF@laposte.net> X-OriginalArrivalTime: 18 Feb 2008 03:47:05.0318 (UTC) FILETIME=[ED9D4860:01C871E0] Cc: mext@ietf.org Subject: Re: [MEXT] [Recharter.2] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, My list. [C,R] Generic Notification Message for Mobile IPv6 [C,R] IP Tunneling Optimization in a Mobile Environment Regards, Benjamin Lim > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Julien Laganier > Sent: Tuesday, February 12, 2008 11:32 PM > To: mext@ietf.org > Subject: [MEXT] [Recharter.2] > > Folks, > > This is the next step in the recharter process. We'd like to > get input from WG participants on what should be the items > included in rechartering, what are their priorities, and who > is willing to sustain the effort. When that step is completed > we will take the WG input and discuss with our AD to move > forward with deciding what to include or not in the charter. > Your input should be sent to the list during the following > two weeks, by 2008-02-26. > > Please pick from the list of items below the items you think > the WG should work on, and order them in decreasing priority > (just to make sure, first priority items goes first in the > list you're making :). > > List of items: > > Binding Revocation for IP Mobility > MIPv6 home link operation in various SDOs IP Tunneling > Optimization in a Mobile Environment Generic Notification > Message for Mobile IPv6 GRE requirements for IPv6 mobility > 4283bis to extend MN identifier to other identifiers Mobile > IPv6 Bootstrapping for the Authentication Option Protocol > Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY > extensions Virtual Home Link configuration for Mobile IPv6 > Extend DSMIPv6 Home Network Support > > Also, please prefix each of the items in your list with the > letters E, C and/or R if you're willing to: > > - [E]dit: Are you willing to edit the draft corresponding to the > item. > > - [C]ontribute: Are you willing to propose text for the draft. > > - [R]eview: Are you willing to review new revisions of the draft when > being asked by the chairs. > > As an example, that could be one input list: > > E MIPv6 home link operation in various SDOs CR Binding > Revocation for IP Mobility R IP Tunneling Optimization in a > Mobile Environment > > meaning that the MIPv6 home link is first priority and you > volunteer to edit, Binding revocation is second priority and > you're willing to contribute and review, while IP tunneling > optimization is third priority and you're willing to review. > > Hope this is understandable :) > > Thanks. > > -- julien and marcello, MEXT chairs > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Feb 17 23:37:58 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 121D13A6C8B; Sun, 17 Feb 2008 23:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.441 X-Spam-Level: X-Spam-Status: No, score=-1.441 tagged_above=-999 required=5 tests=[AWL=-1.004, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6MCdWUOEavF; Sun, 17 Feb 2008 23:37:57 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A3703A6BD5; Sun, 17 Feb 2008 23:37:57 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E0723A6BD5 for ; Sun, 17 Feb 2008 23:37:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTnLyoYNC33r for ; Sun, 17 Feb 2008 23:37:55 -0800 (PST) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.190]) by core3.amsl.com (Postfix) with ESMTP id 127063A69AC for ; Sun, 17 Feb 2008 23:37:54 -0800 (PST) Received: by rv-out-0910.google.com with SMTP id l15so1094799rvb.49 for ; Sun, 17 Feb 2008 23:37:52 -0800 (PST) Received: by 10.141.198.9 with SMTP id a9mr336285rvq.219.1203320272782; Sun, 17 Feb 2008 23:37:52 -0800 (PST) Received: from ?203.178.143.221? ( [203.178.143.221]) by mx.google.com with ESMTPS id b5sm10978762rva.20.2008.02.17.23.37.51 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 17 Feb 2008 23:37:52 -0800 (PST) Message-Id: <7C5C82DC-66BA-4C6E-9195-4B773C8D3542@gmail.com> From: RYUJI WAKIKAWA To: mext@ietf.org Mime-Version: 1.0 (Apple Message framework v915) Date: Mon, 18 Feb 2008 16:37:49 +0900 X-Mailer: Apple Mail (2.915) Subject: [MEXT] firewall docs review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Suresh and authors, I was asked to review draft-krishnan-mip6-firewall-admin-02 and draft-krishnan-mip6-firewall-vendor-02. - Can current filtering mechanism check the IP options field?! If yes, the document should mention which IP options are appeared for which packets. An example is DST Opt for BU and RTHDR for BA. Otherwise, the operator might just block all the packets having RTHDR option regardless of BA. For example, in section 3.1 of draft-admin , Destination Address: Address of HA <-- adding Dest option (HoA option)? Next Header: 50 (ESP) Mobility Header Type: 5 (BU) - missing authentication option and DSMIP support? DSMIP will introduce much complexity to firewall setup. - RO is optional in the RFC3775. I am not sure you can treat RO signaling as same as the BU/BA for firewall filters setup. It might be good if you provide the minimum set of rules (BU/BA only) and the full set of rules (All MH signaling). - why are these two separate documents? regards, ryuji _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Feb 17 23:44:59 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C91113A6C98; Sun, 17 Feb 2008 23:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.194 X-Spam-Level: X-Spam-Status: No, score=-1.194 tagged_above=-999 required=5 tests=[AWL=-0.757, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmOHYavSHC4A; Sun, 17 Feb 2008 23:44:59 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A63C73A6C8B; Sun, 17 Feb 2008 23:44:58 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 090483A69F5 for ; Sun, 17 Feb 2008 23:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hy7QjjFApToT for ; Sun, 17 Feb 2008 23:44:56 -0800 (PST) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.187]) by core3.amsl.com (Postfix) with ESMTP id EB33B3A6C79 for ; Sun, 17 Feb 2008 23:44:55 -0800 (PST) Received: by rv-out-0910.google.com with SMTP id l15so1096063rvb.49 for ; Sun, 17 Feb 2008 23:44:51 -0800 (PST) Received: by 10.140.172.19 with SMTP id u19mr3588836rve.114.1203320691673; Sun, 17 Feb 2008 23:44:51 -0800 (PST) Received: from ?203.178.143.221? ( [203.178.143.221]) by mx.google.com with ESMTPS id b21sm8904695rvf.34.2008.02.17.23.44.49 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 17 Feb 2008 23:44:50 -0800 (PST) From: RYUJI WAKIKAWA To: Suresh Krishnan In-Reply-To: <47B605EE.1050707@ericsson.com> References: <47B605EE.1050707@ericsson.com> Message-Id: Mime-Version: 1.0 (Apple Message framework v915) Date: Mon, 18 Feb 2008 16:44:47 +0900 X-Mailer: Apple Mail (2.915) Cc: mext@ietf.org Subject: Re: [MEXT] firewall-vendor and firewall-admin review - editorial X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Suresh, On 2008/02/16, at 6:36, Suresh Krishnan wrote: > Hi William, > Thanks for the comments. Please find my responses inline > >> Recommendation/Question #4 >> =========================== >> Regarding the firewall-vendor document. >> >> In today's MIP deployments (v6, v4, NEMO), when MIP signaling is >> blocked >> by a firewall, does that firewall return any type of message to allow >> one to debug the system? Quite a few years ago when I did NEMO IPv4 >> with a T-Mobile network we were operating fine one day and the next >> day >> everything broke. It turned out T-Mobile started administratively >> filtering on what we considered an open network. At least we >> received >> "administratively filtered" messages and could track down the >> problem. >> http://roland.grc.nasa.gov/~ivancic/t-mobile/administrative_filtering.pd >> f >> >> My recommendation is that vendors should provide some type of uniform >> signaling to indicate that MIP signaling was administratively >> filtered. >> Perhaps some new ICMP message or at least a recommendation of which >> to >> send. > > ICMPv6 Type 1 (Destination unreachable) message with code 1 - > communication with destination administratively prohibited seems > like a > good fit for this, but I am open to the idea of a new type/code Any notification is useful to know the firewall condition for the debugging purpose. But how can the MIP6 stack process these ICMP packets? Are you going to specify the new MN's behavior here ? regards, ryuji > Thanks > Suresh > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Feb 18 02:40:48 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2B453A6CB4; Mon, 18 Feb 2008 02:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.036 X-Spam-Level: X-Spam-Status: No, score=0.036 tagged_above=-999 required=5 tests=[AWL=-1.604, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfjRSuZAzkwh; Mon, 18 Feb 2008 02:40:47 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D4F328C27B; Mon, 18 Feb 2008 02:40:47 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 937ED28C27B for ; Mon, 18 Feb 2008 02:40:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNdjL9FLhiCo for ; Mon, 18 Feb 2008 02:40:44 -0800 (PST) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.191]) by core3.amsl.com (Postfix) with ESMTP id 8E6DE3A682B for ; Mon, 18 Feb 2008 02:40:43 -0800 (PST) Received: by mu-out-0910.google.com with SMTP id i10so1323433mue.3 for ; Mon, 18 Feb 2008 02:40:40 -0800 (PST) Received: by 10.78.124.9 with SMTP id w9mr8624853huc.24.1203331239198; Mon, 18 Feb 2008 02:40:39 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id 7sm1678104nfv.35.2008.02.18.02.40.37 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Feb 2008 02:40:38 -0800 (PST) From: Julien Laganier To: Basavaraj Patil Date: Mon, 18 Feb 2008 11:40:50 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200802181140.50899.julien.IETF@laposte.net> Cc: mext@ietf.org Subject: [MEXT] DSMIP6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Friday 15 February 2008, Basavaraj Patil wrote: > Hi Julien, > > In terms of priority, I hope the DS-MIP6 I-D > is pretty high. The > milestones indicate completion of this work by Dec 07. Hopefully we > can get it out by IETF71 at least. I am willing to help on getting > this thru. Hi Raj, Thanks for the offer. For now I don't think there's much you can do -- We're waiting for an update of the draft resolving WGLC comments. Best, --julien _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Feb 18 02:41:02 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F17528C345; Mon, 18 Feb 2008 02:41:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.325 X-Spam-Level: X-Spam-Status: No, score=-1.325 tagged_above=-999 required=5 tests=[AWL=1.112, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gHQMwswCjBx; Mon, 18 Feb 2008 02:41:01 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7FC328C303; Mon, 18 Feb 2008 02:40:59 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80ACD3A6CC7 for ; Mon, 18 Feb 2008 02:40:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLEzwJhCdZdK for ; Mon, 18 Feb 2008 02:40:57 -0800 (PST) Received: from hitachihk8.hitachi.cn (static-ip-174-194-65-202.rev.dyxnet.com [202.65.194.174]) by core3.amsl.com (Postfix) with ESMTP id 3AE1D3A6BAB for ; Mon, 18 Feb 2008 02:40:57 -0800 (PST) Received: (qmail 16150 invoked from network); 18 Feb 2008 10:40:53 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk8;3afbface5389d51681a86fe28a294dee; Received: from unknown (HELO hitachihk7.hitachi.cn) (170.95.94.4) by 170.95.94.11 with SMTP; 18 Feb 2008 10:40:53 -0000 Received: (qmail 23325 invoked from network); 18 Feb 2008 10:40:53 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk7;0096e942bb8c465f61933713747fcc33; Received: from hchidc401.hitachi-china.com (170.95.94.69) by 172.16.10.10 with SMTP; 18 Feb 2008 10:40:53 -0000 Received: from hchibjrdpyang ([10.96.2.35]) by hchidc401.hitachi-china.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Feb 2008 18:40:52 +0800 From: "Peng Yang" To: "'Julien Laganier'" , Date: Mon, 18 Feb 2008 18:40:52 +0800 Message-ID: <029301c8721a$bbf9de10$2302600a@hitachichina.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <200802121631.35572.julien.IETF@laposte.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-OriginalArrivalTime: 18 Feb 2008 10:40:52.0528 (UTC) FILETIME=[BBC8E300:01C8721A] X-Scanned-By-hitachihk7: Virus scan performed by network-box X-Scanned-By-hitachihk7: Scanner file id is hitachihk7-1203331253.383-23320-000 X-Scanned-By-hitachihk7: No known viruses found in message (received+scanned in 0.01/0.03 secs) X-Scanned-By-hitachihk7: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Scanned-By-hitachihk8: Virus scan performed by network-box X-Scanned-By-hitachihk8: Scanner file id is hitachihk8-1203331253.730-16138-000 X-Scanned-By-hitachihk8: No known viruses found in message (received+scanned in 0.04/0.07 secs) X-Scanned-By-hitachihk8: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Scanned-By-hitachihk8: Whitelisted with valid signature (outbound via Network Box hitachihk7) Subject: Re: [MEXT] [Recharter.2] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, Julien: My list is added below: [E] Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions [CR] MIPv6 home link operation in various SDOs [R] Generic Notification Message for Mobile IPv6 [R] IP Tunneling Optimization in a Mobile Environment. Thanks a lot BRG P.Y > >-----Original Message----- > >From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > >Julien Laganier > >Sent: Tuesday, February 12, 2008 11:32 PM > >To: mext@ietf.org > >Subject: [MEXT] [Recharter.2] > > > >Folks, > > > >This is the next step in the recharter process. We'd like to get input > >from WG participants on what should be the items included in > >rechartering, what are their priorities, and who is willing to > >sustain the effort. When that step is completed we will take the WG > >input and discuss with our AD to move forward with deciding what to > >include or not in the charter. Your input should be sent to the list > >during the following two weeks, by 2008-02-26. > > > >Please pick from the list of items below the items you think the WG > >should work on, and order them in decreasing priority (just to make > >sure, first priority items goes first in the list you're making :). > > > >List of items: > > > >Binding Revocation for IP Mobility > >MIPv6 home link operation in various SDOs > >IP Tunneling Optimization in a Mobile Environment > >Generic Notification Message for Mobile IPv6 > >GRE requirements for IPv6 mobility > >4283bis to extend MN identifier to other identifiers > >Mobile IPv6 Bootstrapping for the Authentication Option Protocol > >Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions > >Virtual Home Link configuration for Mobile IPv6 > >Extend DSMIPv6 Home Network Support > > > >Also, please prefix each of the items in your list with the letters E, C > >and/or R if you're willing to: > > > >- [E]dit: Are you willing to edit the draft corresponding to the > > item. > > > >- [C]ontribute: Are you willing to propose text for the draft. > > > >- [R]eview: Are you willing to review new revisions of the draft when > > being asked by the chairs. > > > >As an example, that could be one input list: > > > >E MIPv6 home link operation in various SDOs > >CR Binding Revocation for IP Mobility > >R IP Tunneling Optimization in a Mobile Environment > > > >meaning that the MIPv6 home link is first priority and you volunteer to > >edit, Binding revocation is second priority and you're willing to > >contribute and review, while IP tunneling optimization is third > >priority and you're willing to review. > > > >Hope this is understandable :) > > > >Thanks. > > > >-- julien and marcello, MEXT chairs > >_______________________________________________ > >MEXT mailing list > >MEXT@ietf.org > >http://www.ietf.org/mailman/listinfo/mext Disclaimer: The contents of this e-mail, and its attachments, if any, are confidential and may be protected by law against any unauthorized use. If you have received this e-mail by mistake or have reason to believe that you are not the intended recipient, please notify the sender by reply e-mail as soon as possible and delete it from your computer system immediately thereafter. If you are not the intended recipient, you must not copy this e-mail or attachment or disclose the contents to any other person. While we have made every effort to keep our network virus free, we take no responsibility for any computer virus which might be transferred by way of this e-mail. _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Feb 18 02:57:30 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9619C28C305; Mon, 18 Feb 2008 02:57:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.26 X-Spam-Level: X-Spam-Status: No, score=-0.26 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VR69veWPx1jj; Mon, 18 Feb 2008 02:57:29 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A69FB3A6C0A; Mon, 18 Feb 2008 02:57:29 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26ABF28C1D9 for ; Mon, 18 Feb 2008 02:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQqtynveFoCb for ; Mon, 18 Feb 2008 02:57:26 -0800 (PST) Received: from rodin.i2r.a-star.edu.sg (rodin.i2r.a-star.edu.sg [192.122.139.27]) by core3.amsl.com (Postfix) with ESMTP id 5269A3A6C0A for ; Mon, 18 Feb 2008 02:57:24 -0800 (PST) Received: from rodin.i2r.a-star.edu.sg (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id C205E13B67E; Mon, 18 Feb 2008 01:31:18 +0800 (SGT) Received: from mailfe01.teak.local.net (unknown [192.122.134.9]) by rodin.i2r.a-star.edu.sg (Postfix) with ESMTP id B4F1C13B673; Mon, 18 Feb 2008 01:31:18 +0800 (SGT) Received: from precision5570 ([192.168.137.53]) by mailfe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Feb 2008 18:56:33 +0800 Message-ID: <003201c8721d$0ae7f190$3589a8c0@precision5570> From: "QIU Ying" To: "RYUJI WAKIKAWA" , References: <7C5C82DC-66BA-4C6E-9195-4B773C8D3542@gmail.com> Date: Mon, 18 Feb 2008 18:57:24 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 18 Feb 2008 10:56:33.0447 (UTC) FILETIME=[EC9DBB70:01C8721C] Subject: Re: [MEXT] firewall docs review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, Ryuji Thanks for your comments. My response is inline. ----- Original Message ----- "RYUJI WAKIKAWA" wrote > Hi Suresh and authors, > > I was asked to review draft-krishnan-mip6-firewall-admin-02 and > draft-krishnan-mip6-firewall-vendor-02. > > - Can current filtering mechanism check the IP options field?! No. Current firewall filter does not support to check the IP options field. > If yes, the document should mention which IP options are appeared > for which packets. > An example is DST Opt for BU and RTHDR for BA. > Otherwise, the operator might just block all the packets having > RTHDR option regardless of BA. > > For example, in section 3.1 of draft-admin , > Destination Address: Address of HA > <-- adding Dest > option (HoA option)? > Next Header: 50 (ESP) > Mobility Header Type: 5 (BU) For draft-admin, which purpose is BCP, so we could not solicit the function here. But we could provide the filter in draft-vender. > > - missing authentication option and DSMIP support? > DSMIP will introduce much complexity to firewall setup. The target of these two draft is to make MIP6 signalling pass through the firewalls. So, in my opinion, the issue of authentication and DSMIP might be out of the scope. > > - RO is optional in the RFC3775. I am not sure you can treat > RO signaling as same as the BU/BA for firewall filters setup. > It might be good if you provide the minimum set of rules (BU/BA > only) > and the full set of rules (All MH signaling). Good comments. Regards and Thanks Qiu Ying > > - why are these two separate documents? > > regards, > ryuji > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext ------------ Institute For Infocomm Research - Disclaimer -------------This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you.-------------------------------------------------------- _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Feb 18 03:14:45 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E12F528C33E; Mon, 18 Feb 2008 03:14:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.158 X-Spam-Level: X-Spam-Status: No, score=-3.158 tagged_above=-999 required=5 tests=[AWL=-0.721, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L31XaWOd0dJM; Mon, 18 Feb 2008 03:14:45 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00B763A6CB2; Mon, 18 Feb 2008 03:14:45 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD3023A6CAD for ; Mon, 18 Feb 2008 03:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKCYmuliIyWl for ; Mon, 18 Feb 2008 03:14:43 -0800 (PST) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by core3.amsl.com (Postfix) with ESMTP id D9A783A6817 for ; Mon, 18 Feb 2008 03:14:42 -0800 (PST) Received: from [221.219.117.104] (helo=IBM-x60) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.63) (envelope-from ) id 1JR3xE-0002PI-QW; Mon, 18 Feb 2008 19:14:37 +0800 Date: Mon, 18 Feb 2008 19:14:37 +0800 From: "xuke" To: "mext" Organization: Institute of Computer Network and Technology, Tsinghua University X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Message-Id: Cc: xuke Subject: Re: [MEXT] [Recharter.2] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: xuke@mail.tsinghua.edu.cn List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi All, I would like to support: [CR] Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions Regards, xuke Tsinghua University >On Feb 12, 2008 7:31 AM, Julien Laganier wrote: >> Folks, >> >> This is the next step in the recharter process. We'd like to get input >> from WG participants on what should be the items included in >> rechartering, what are their priorities, and who is willing to >> sustain the effort. When that step is completed we will take the WG >> input and discuss with our AD to move forward with deciding what to >> include or not in the charter. Your input should be sent to the list >> during the following two weeks, by 2008-02-26. >> >> Please pick from the list of items below the items you think the WG >> should work on, and order them in decreasing priority (just to make >> sure, first priority items goes first in the list you're making :). >> >> List of items: >> >> Binding Revocation for IP Mobility >> MIPv6 home link operation in various SDOs >> IP Tunneling Optimization in a Mobile Environment >> Generic Notification Message for Mobile IPv6 >> GRE requirements for IPv6 mobility >> 4283bis to extend MN identifier to other identifiers >> Mobile IPv6 Bootstrapping for the Authentication Option Protocol >> Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions >> Virtual Home Link configuration for Mobile IPv6 >> Extend DSMIPv6 Home Network Support >> >> Also, please prefix each of the items in your list with the letters E, C >> and/or R if you're willing to: >> >> - [E]dit: Are you willing to edit the draft corresponding to the >> item. >> >> - [C]ontribute: Are you willing to propose text for the draft. >> >> - [R]eview: Are you willing to review new revisions of the draft when >> being asked by the chairs. >> >> As an example, that could be one input list: >> >> E MIPv6 home link operation in various SDOs >> CR Binding Revocation for IP Mobility >> R IP Tunneling Optimization in a Mobile Environment >> >> meaning that the MIPv6 home link is first priority and you volunteer to >> edit, Binding revocation is second priority and you're willing to >> contribute and review, while IP tunneling optimization is third >> priority and you're willing to review. >> >> Hope this is understandable :) >> >> Thanks. >> >> -- julien and marcello, MEXT chairs >> _______________________________________________ >> MEXT mailing list >> MEXT at ietf.org >> http://www.ietf.org/mailman/listinfo/mext >> _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Feb 18 03:45:31 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3192128C3C3; Mon, 18 Feb 2008 03:45:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LNF5ELO0SsE; Mon, 18 Feb 2008 03:45:30 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AE2628C3A9; Mon, 18 Feb 2008 03:45:29 -0800 (PST) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2F6BA3A6C0A; Mon, 18 Feb 2008 03:45:00 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080218114501.2F6BA3A6C0A@core3.amsl.com> Date: Mon, 18 Feb 2008 03:45:01 -0800 (PST) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-nemo-mib-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-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 Mobility EXTensions for IPv6 Working Group of the IETF. Title : NEMO Management Information Base Author(s) : S. Gundavelli, et al. Filename : draft-ietf-mext-nemo-mib-00.txt Pages : 41 Date : 2008-02-15 This memo defines a portion of the Management Information Base (MIB), the network mobility support (NEMO) MIB, for use with network management protocols in the Internet community. In particular, the NEMO MIB will be used to monitor and control a mobile ipv6 node with NEMO functionality. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-mib-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-mext-nemo-mib-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-mext-nemo-mib-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: <2008-02-18033104.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mext-nemo-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mext-nemo-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-18033104.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext --NextPart-- From mext-bounces@ietf.org Mon Feb 18 07:02:10 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0BC728C428; Mon, 18 Feb 2008 07:02:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.274 X-Spam-Level: X-Spam-Status: No, score=0.274 tagged_above=-999 required=5 tests=[AWL=0.711, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4EpgP-CNXwVQ; Mon, 18 Feb 2008 07:02:10 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED31D28C400; Mon, 18 Feb 2008 07:01:46 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D90628C3C4 for ; Mon, 18 Feb 2008 07:01:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6GKrYmgRBSE for ; Mon, 18 Feb 2008 07:01:45 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.192.232]) by core3.amsl.com (Postfix) with ESMTP id 2B8AD28C431 for ; Mon, 18 Feb 2008 07:01:09 -0800 (PST) Received: (qmail 18042 invoked from network); 18 Feb 2008 16:01:04 +0100 Received: from unknown (HELO M90Teco) (217.169.232.206) by server9.hosting2go.nl with SMTP; 18 Feb 2008 16:01:03 +0100 From: "Teco Boot" To: "'Julien Laganier'" References: <200802111135.44252.julien.IETF@laposte.net> <200802121631.35572.julien.IETF@laposte.net> In-Reply-To: Date: Mon, 18 Feb 2008 16:00:24 +0100 Message-ID: <000001c8723f$121fa8f0$365efad0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AchtjO7XSseQUsrrTq6UG9o/kp371gEpQ1cQAAJCZlA= Content-Language: nl Cc: mext@ietf.org Subject: Re: [MEXT] [Recharter.2] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien, here my list. R IP Tunneling Optimization in a Mobile Environment R Extend DSMIPv6 Home Network Support R GRE requirements for IPv6 mobility Teco _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Feb 18 07:07:15 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77C0F28C3B9; Mon, 18 Feb 2008 07:07:15 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: illegal encoding [base64] for MIME type message/external-body X-Spam-Flag: NO X-Spam-Score: -0.264 X-Spam-Level: X-Spam-Status: No, score=-0.264 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xy8SNVWJD6E1; Mon, 18 Feb 2008 07:07:14 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 734EB28C369; Mon, 18 Feb 2008 07:07:08 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91CFF28C374 for ; Mon, 18 Feb 2008 07:07:06 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: illegal encoding [base64] for MIME type message/external-body Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxLe1zSdd3hu for ; Mon, 18 Feb 2008 07:07:05 -0800 (PST) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 9DD0128C3B8 for ; Mon, 18 Feb 2008 07:04:42 -0800 (PST) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile14) with ESMTP id m1IF4ea1008444 for ; Tue, 19 Feb 2008 00:04:40 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb3) with ESMTP id m1IF4e519103 for ; Tue, 19 Feb 2008 00:04:40 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili06) with ESMTP id m1IF4dR04681 for ; Tue, 19 Feb 2008 00:04:39 +0900 (JST) Received: from ncc1701e.sg.panasonic.com ([10.81.113.10]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Feb 2008 23:03:31 +0800 Received: by ncc1701e.sg.panasonic.com (Postfix, from userid 1000) id 4329D26518C2; Mon, 18 Feb 2008 23:04:19 +0800 (SGT) From: Chan-Wah Ng To: mext Content-Type: multipart/mixed; boundary="=-gdQqPOhQC+knSoTJ9VC4" Organization: Panasonic Singapore Labs Date: Mon, 18 Feb 2008 23:04:18 +0800 Message-Id: <1203347058.7675.4.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.2 X-OriginalArrivalTime: 18 Feb 2008 15:03:32.0529 (UTC) FILETIME=[6D7A3210:01C8723F] Subject: [MEXT] [Fwd: I-D Action:draft-ng-nemo-ce-req-02.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: chanwah.ng@sg.panasonic.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --=-gdQqPOhQC+knSoTJ9VC4 Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello all, we have published a new version of the CE requirements for NEMO RO -- see forwarded mail below. The changes include: * Added "Protocol Harmony" as requirement * Added "Separability" and "Multihoming" as desired feature * Elaborated more on some of the explanations of requirements The draft is also currently more in-line with the aeronautics's draft in terms of format. /rgds /cwng -------- Forwarded Message -------- From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ng-nemo-ce-req-02.txt Date: Mon, 18 Feb 2008 06:15:01 -0800 (PST) A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Consumer Electronics Requirements for Network Mobility Route Optimization Author(s) : C. Ng, et al. Filename : draft-ng-nemo-ce-req-02.txt Pages : 16 Date : 2008-02-16 This document illustrates different deployments of Network Mobility (NEMO) from the consumer electronics perspective. From these deployments, a set of requirements is deduced for Route Optimization (RO) with NEMO. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ng-nemo-ce-req-02.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-ng-nemo-ce-req-02.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-ng-nemo-ce-req-02.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 http://www.ietf.org/mailman/listinfo/i-d-announce --=-gdQqPOhQC+knSoTJ9VC4 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluCkNvbnRlbnQtSUQ6IDwyMDA4LTAyLTE4MDYwNzE3Lkkt REBpZXRmLm9yZz4KCkVOQ09ESU5HIG1pbWUKRklMRSAvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW5n LW5lbW8tY2UtcmVxLTAyLnR4dAo= --=-gdQqPOhQC+knSoTJ9VC4 Content-Type: Message/External-body; name="draft-ng-nemo-ce-req-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluCkNvbnRlbnQtSUQ6IDwyMDA4LTAyLTE4MDYwNzE3Lkkt RFxAaWV0Zi5vcmc+Cgo= --=-gdQqPOhQC+knSoTJ9VC4 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext --=-gdQqPOhQC+knSoTJ9VC4-- From mext-bounces@ietf.org Mon Feb 18 07:18:54 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCD173A67F4; Mon, 18 Feb 2008 07:18:54 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: illegal encoding [base64] for MIME type message/external-body X-Spam-Flag: NO X-Spam-Score: -0.397 X-Spam-Level: X-Spam-Status: No, score=-0.397 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFGjyzrg9XV8; Mon, 18 Feb 2008 07:18:54 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84BDE3A67F7; Mon, 18 Feb 2008 07:18:53 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19F4128C41A for ; Mon, 18 Feb 2008 07:18:52 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: illegal encoding [base64] for MIME type message/external-body Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5YRwfj+QxRq for ; Mon, 18 Feb 2008 07:18:51 -0800 (PST) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 7E93728C256 for ; Mon, 18 Feb 2008 07:18:50 -0800 (PST) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile12) with ESMTP id m1IFIlwr004178 for ; Tue, 19 Feb 2008 00:18:47 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb1) with ESMTP id m1IFIli04015 for ; Tue, 19 Feb 2008 00:18:47 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili07) with ESMTP id m1IFIlb04868 for ; Tue, 19 Feb 2008 00:18:47 +0900 (JST) Received: from ncc1701e.sg.panasonic.com ([10.81.113.10]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Feb 2008 23:17:39 +0800 Received: by ncc1701e.sg.panasonic.com (Postfix, from userid 1000) id 574C726518C2; Mon, 18 Feb 2008 23:18:27 +0800 (SGT) From: Chan-Wah Ng To: mext Content-Type: multipart/mixed; boundary="=-t1BS05pseF9rFRB5pXt9" Organization: Panasonic Singapore Labs Date: Mon, 18 Feb 2008 23:18:27 +0800 Message-Id: <1203347907.8866.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.2 X-OriginalArrivalTime: 18 Feb 2008 15:17:40.0382 (UTC) FILETIME=[66D64BE0:01C87241] Subject: [MEXT] [Fwd: I-D Action:draft-ng-mobopts-multihoming-01.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: chanwah.ng@sg.panasonic.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --=-t1BS05pseF9rFRB5pXt9 Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello all, forwarded is the announcement of the update of a draft on multihoming optimizations for Mobile IPv6. Although this is more of a research-oriented effort, it might nonetheless be of interest to people in the Mext WG, since it discuss about possible enhancements to Mobile IPv6 for multihomed nodes, Comments are welcomed and appreciated. /rgds /cwng -------- Forwarded Message -------- From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ng-mobopts-multihoming-01.txt Date: Mon, 18 Feb 2008 06:15:01 -0800 (PST) A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : On Mobile IPv6 Optimization and Multihoming Author(s) : C. Ng, K. Aso Filename : draft-ng-mobopts-multihoming-01.txt Pages : 19 Date : 2008-02-16 This memo explores the possible areas of extensions to MIPv6 route optimization in the considerations of multihomed nodes. The intention is to raise awareness in the research community, leading to a possible extension to RFC 4651. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ng-mobopts-multihoming-01.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-ng-mobopts-multihoming-01.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-ng-mobopts-multihoming-01.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 http://www.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ Mobopts mailing list Mobopts@ietf.org http://www.ietf.org/mailman/listinfo/mobopts --=-t1BS05pseF9rFRB5pXt9 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluCkNvbnRlbnQtSUQ6IDwyMDA4LTAyLTE4MDYwNzM1Lkkt REBpZXRmLm9yZz4KCkVOQ09ESU5HIG1pbWUKRklMRSAvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW5n LW1vYm9wdHMtbXVsdGlob21pbmctMDEudHh0Cg== --=-t1BS05pseF9rFRB5pXt9 Content-Type: Message/External-body; name="draft-ng-mobopts-multihoming-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluCkNvbnRlbnQtSUQ6IDwyMDA4LTAyLTE4MDYwNzM1Lkkt RFxAaWV0Zi5vcmc+Cgo= --=-t1BS05pseF9rFRB5pXt9 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext --=-t1BS05pseF9rFRB5pXt9-- From mext-bounces@ietf.org Mon Feb 18 07:43:10 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4840F28C3A8; Mon, 18 Feb 2008 07:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.323 X-Spam-Level: X-Spam-Status: No, score=0.323 tagged_above=-999 required=5 tests=[AWL=-0.241, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, MIME_HTML_MOSTLY=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlEMUhklzQgy; Mon, 18 Feb 2008 07:43:08 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 270033A6CEC; Mon, 18 Feb 2008 07:43:08 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A570F3A6CE3 for ; Mon, 18 Feb 2008 07:43:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juYzozS13PWW for ; Mon, 18 Feb 2008 07:43:04 -0800 (PST) Received: from web84111.mail.mud.yahoo.com (web84111.mail.mud.yahoo.com [68.142.206.198]) by core3.amsl.com (Postfix) with SMTP id 9BDDA3A6CEC for ; Mon, 18 Feb 2008 07:43:04 -0800 (PST) Received: (qmail 96957 invoked by uid 60001); 18 Feb 2008 15:43:02 -0000 X-YMail-OSG: eASiwvMVM1norY_NKBwcA2ErYNVGAA0NMJTzobQL61TFUJp3oa9AMRGX4dsreiwzVSFYknLUvy7lYLspqwdpuvvXkeYPEdyOM6Kklh.3eyC5RHg- Received: from [206.16.17.212] by web84111.mail.mud.yahoo.com via HTTP; Mon, 18 Feb 2008 07:43:01 PST X-Mailer: YahooMailRC/818.31 YahooMailWebService/0.7.162 Date: Mon, 18 Feb 2008 07:43:01 -0800 (PST) From: Behcet Sarikaya To: Julien Laganier , mext@ietf.org MIME-Version: 1.0 Message-ID: <109030.90673.qm@web84111.mail.mud.yahoo.com> Subject: Re: [MEXT] Home Link operation over p2p links X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0822364409==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0822364409== Content-Type: multipart/alternative; boundary="0-687559432-1203349381=:90673" --0-687559432-1203349381=:90673 Content-Type: text/plain; charset=us-ascii Hi Julien, We have submitted our draft on the prefix management for home link operation over p2p links, it is at: http://tools.ietf.org/wg/mext/draft-sarikaya-mext-homelink-prefix-delegation-00.txt The idea is that home link operation should deal with prefix mgmt for MN's not just for MR's. Regards, Behcet ----- Original Message ---- From: Julien Laganier To: mext@ietf.org Sent: Thursday, February 14, 2008 10:24:46 AM Subject: Re: [MEXT] Home Link operation over p2p links Hello Vijay, Thanks for submitting the draft in time! This is definitely helpful to assess the rechartering work item you proposed. I have couple of comments on your draft: > 3.1. Detecting Attachment to the Home Link > > In Mobile IPv6, a mobile node detects that it has attached to the > home link when it receives a router advertisement with the home > prefix. Some of the point-to-point links like IPsec tunnels and > PMIPv6 tunnels do not support running neighbor discovery in the > tunnels. When the home link is created by concatenating a GTP > tunnel with a PMIPv6 tunnel or an IPsec tunnel with PMIPv6 tunnels, > it becomes difficult for a router advertisement to be sent over the > concatenated tunnels. When "concatenating a GTP tunnel with a PMIPv6 tunnel", the RS can be sent through the GTP tunnel by the MN, up to the MAG. Then the MAG replies with an RA containing the Home Network Prefix, so there doesn't seem to be an issue. Am I missing something? When "concatenating an IPsec tunnel with a PMIPv6 tunnel", the MN cannot send the RS through the IPsec tunnel, and likewise, the MAG wouldn't be able to reply with an RA containing the Home Network Prefix. However, isn't the main issue at stake here the fact that IPsec "interfaces" are not fully fledged IPv6 interface, i.e. they do not support link-local addresses and multicast, etc. See Pasi's draft describing the issues and possible solution: draft-eronen-ipsec-ikev2-ipv6-config-02.txt It seems to me that if what Pasi proposes was implemented in the HA implementing IKEv2, then the issues your draft describe w.r.t. detecting home link attachment would vanish. If that is the case, wouldn't the right approach be to fix IPsec rather than extending MIPv6 because IPsec has a deficiency? > 3.2. Bootstrapping > > Mobile IPv6 bootstrapping [8] and [9] depends on the use of IKEv2 > between the mobile node and the home agent to bootstrap the MIPv6 > home address. According to RFC 3775, when the mobile node is > attached to the home link, it does not have to run IKEv1/IKEv2 > with the home agent to setup the necessary security associations. > Most often, the IKEv2 exchange is triggered by the need to send a > binding update. So if the mobile node boots up the home link, it may > not be able to use IKEv2 to bootstrap the MIPv6 home address. Purely based on RFC3775 the MN does not have to run IKE to setup SA's with HA when it is attached on its home link (But note that here we're talking about bootstrapping and that wasn't part of 3775 so we can't reason uniquely in terms of what 3775 says). However, the only ways for a MN to figure out that it is attached on its home link are either to compare its home address with the prefix advertized on-link in RA's. In the case of bootstrapping the MN does not know its home address before hand, thus it can't conclude that it is home before it acquire a home address via bootstrapping. By default it will thus assume it is not at home and initiate bootstrapping. Hence there is a need to send a BU to get the Home Address. As you note "the IKEv2 exchange is triggered by the need to send a binding update", thus I assume IKEv2 would be triggered to acquire an home address. Then the MN can conclude it is home (because HoA included in RA's PIO) and drop the IKE and IPsec association. It is true that it isn't written down but to me it looks logical that an implementor would follow these steps. Do you think such a procedure is inappropriate? > The IKEv2 exchange is only used to bootstrap the MIPv6 home > address. The DS-MIPv6 [11] IPv4 home address is obtained by the > mobile node using the exchange of Binding Update and Binding > Acknowledgement with the home agent. The Mobile Network Prefixes > required for mobile router operation, as described in [10], may also > obtained using the Binding Update and Binding Acknowledgement > exchange between the mobile router and the home agent. This is > specified in [12]. According to the current specifications, the > mobile node (or the mobile router) does not send a Binding Update to > the home agent when it is attached to the home link. Regarding IPv4 home address allocation, the same reasoning applies as with bootstrapping of the MIPv6 home address above: there would be a need to send a BU (to get the IPv4 HoA) thus IKE would be triggered, and dropped down once the v4 address is known. Regarding Mobile Network Prefix Assignment, there's no agreement yet whether this is done with extensions to BUs and BAs, or using DHCP. If it was done using DHCP it could work provided that DHCP requests can be sent thru the point-to-point link. Francis has proposed a method where a DHCP relay is collocated on the MR, and thus only unicast DHCP messages have to be sent and received. Therefore it would work well on a point-to-point link. > Since it is not typical for the mobile node to initiate an IKEv2 > exchange with its home agent and not possible to send a Binding > Update from the home link, there is a need for other bootstrapping > mechanisms that would work across all point-to-point home links. > However, this would result in the mobile node using different > bootstrapping mechanisms depending on the point-to-point that > appears as the home link. The mobile node would also end with using > different bootstrapping mechanisms when attached to the home link and > when attached to the visited link. To avoid this, it would be > desirable to use the same bootstrapping mechanisms irrespective of > the point-to-point link that appears as the home link and/or the > visited link. But it looks like the same IKEv2 based bootstrapping mechanism is used in everycase, it is just that once the MN figures out it is at home it can drop the IKE and IPsec SA's. > 3.4. Forwarding at the Home Agent > > According to RFC 3775, when the mobile node is attached to the > home link, it behaves as a regular IPv6 host and is able to > send/receive packets directly without going through the home agent. > In case the home agent needs to send any packet to the mobile node, > it has a valid neighbor cache entry for the mobile node which is then > used to forward packets to the mobile node. > > When point-to-point links are used a home links, then the packets > meant for the mobile node always reach the home agent first and > are then forwarded to the mobile node. However, the home agent > cannot construct a neighbor cache entry for the mobile node, since > most of the point-to-point links mentioned in Section 1 do not > support sending neighbor solicitation and receiving neighbor > advertisement messages. Again, if IPsec was fixed as in Pasi's proposal then it would work just fine. Other point-to-point links happily carry multicast traffic. > 3.5. Indicating Service Selection Option > > A new extension, the Service Selection for Mobile IPv6, has been > specified in [13] for the mobile node to indicate to the home > agent which service it wants to access. The Service Selection option > is sent in the Binding Update. When the mobile node boots up in the > home link, it won't be able to indicate the service it wants to > access to the home agent, since the Binding Update message is not > sent from the home link. > > It is possible to indicate the Service the mobile node wants to > access in the IKEv2 exchange with the home agent. The service > information is encoded in the IDr payload in the IKEv2 exchange. > However, this requires the mobile node to initiate an IKEv2 > exchange with the mobile node from the home link. According to RFC > 3775, the mobile node does not have to initiate an IKEv2 exchange > when it boots up in the home link. Same goes here than for bootstrapping. There's indeed a need to send a BU, so does the MN, then IKEv2 kicks in, BU is sent out, and no problem. In conclusion I am not sure there's a clear case to extend MIPv6. Maybe there's some room for a document clarifying how implementation should behave with bootstrapping while on the home link. What do you think? Best, --julien On Wednesday 13 February 2008, Vijay Devarapalli wrote: > Hello folks, > > Here is a draft that describes issues with the mobile node > booting up on the home link over point-to-point links. It > describes the issues and suggests a possible solution. > > http://www.ietf.org/internet-drafts/draft-devarapalli-mext-mipv6-home >-link-00.txt > > Comments/reviews are welcome. > > Vijay > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext --0-687559432-1203349381=:90673 Content-Type: text/html; charset=us-ascii
Hi Julien,
  We have submitted our draft on the prefix management for home link operation over p2p links, it is at:
http://tools.ietf.org/wg/mext/draft-sarikaya-mext-homelink-prefix-delegation-00.txt
The idea is that home link operation should deal with prefix mgmt for MN's not just for MR's.
  Regards,

Behcet

----- Original Message ----
From: Julien Laganier <julien.IETF@laposte.net>
To: mext@ietf.org
Sent: Thursday, February 14, 2008 10:24:46 AM
Subject: Re: [MEXT] Home Link operation over p2p links

Hello Vijay,

Thanks for submitting the draft in time! This is definitely helpful to
assess the rechartering work item you proposed.

<chair hat off>

I have couple of comments on your draft:

> 3.1.  Detecting Attachment to the Home Link
>
>    In Mobile IPv6, a mobile node detects that it has attached to the
>    home link when it receives a router advertisement with the home
>    prefix.  Some of the point-to-point links like IPsec tunnels and
>    PMIPv6 tunnels do not support running neighbor discovery in the
>    tunnels.  When the home link is created by concatenating a GTP
> tunnel with a PMIPv6 tunnel or an IPsec tunnel with PMIPv6 tunnels,
> it becomes difficult for a router advertisement to be sent over the
> concatenated tunnels.

When "concatenating a GTP tunnel with a PMIPv6 tunnel", the RS can be
sent through the GTP tunnel by the MN, up to the MAG. Then the MAG
replies with an RA containing the Home Network Prefix, so there doesn't
seem to be an issue. Am I missing something?

When "concatenating an IPsec tunnel with a PMIPv6 tunnel", the MN cannot
send the RS through the IPsec tunnel, and likewise, the MAG wouldn't be
able to reply with an RA containing the Home Network Prefix. However,
isn't the main issue at stake here the fact that IPsec "interfaces" are
not fully fledged IPv6 interface, i.e. they do not support link-local
addresses and multicast, etc. See Pasi's draft describing the issues
and possible solution:

    draft-eronen-ipsec-ikev2-ipv6-config-02.txt

It seems to me that if what Pasi proposes was implemented in the HA
implementing IKEv2, then the issues your draft describe w.r.t.
detecting home link attachment would vanish. If that is the case,
wouldn't the right approach be to fix IPsec rather than extending MIPv6
because IPsec has a deficiency?

> 3.2.  Bootstrapping
>
>    Mobile IPv6 bootstrapping [8] and [9] depends on the use of IKEv2
>    between the mobile node and the home agent to bootstrap the MIPv6
>    home address.  According to RFC 3775, when the mobile node is
>    attached to the home link, it does not have to run IKEv1/IKEv2
> with the home agent to setup the necessary security associations.
> Most often, the IKEv2 exchange is triggered by the need to send a
> binding update.  So if the mobile node boots up the home link, it may
> not be able to use IKEv2 to bootstrap the MIPv6 home address.

Purely based on RFC3775 the MN does not have to run IKE to setup SA's
with HA when it is attached on its home link (But note that here we're
talking about bootstrapping and that wasn't part of 3775 so we can't
reason uniquely in terms of what 3775 says). However, the only ways for
a MN to figure out that it is attached on its home link are either to
compare its home address with the prefix advertized on-link in RA's.

In the case of bootstrapping the MN does not know its home address
before hand, thus it can't conclude that it is home before it acquire a
home address via bootstrapping.

By default it will thus assume it is not at home and initiate
bootstrapping. Hence there is a need to send a BU to get the Home
Address. As you note "the IKEv2 exchange is triggered by the need to
send a binding update", thus I assume IKEv2 would be triggered to
acquire an home address.

Then the MN can conclude it is home (because HoA included in RA's PIO)
and drop the IKE and IPsec association.

It is true that it isn't written down but to me it looks logical that an
implementor would follow these steps. Do you think such a procedure is
inappropriate?

>    The IKEv2 exchange is only used to bootstrap the MIPv6 home
> address. The DS-MIPv6 [11] IPv4 home address is obtained by the
> mobile node using the exchange of Binding Update and Binding
> Acknowledgement with the home agent.  The Mobile Network Prefixes
> required for mobile router operation, as described in [10], may also
> obtained using the Binding Update and Binding Acknowledgement
> exchange between the mobile router and the home agent.  This is
> specified in [12]. According to the current specifications, the
> mobile node (or the mobile router) does not send a Binding Update to
> the home agent when it is attached to the home link.

Regarding IPv4 home address allocation, the same reasoning applies as
with bootstrapping of the MIPv6 home address above: there would be a
need to send a BU (to get the IPv4 HoA) thus IKE would be triggered,
and dropped down once the v4 address is known.

Regarding Mobile Network Prefix Assignment, there's no agreement yet
whether this is done with extensions to BUs and BAs, or using DHCP. If
it was done using DHCP it could work provided that DHCP requests can be
sent thru the point-to-point link. Francis has proposed a method where
a DHCP relay is collocated on the MR, and thus only unicast DHCP
messages have to be sent and received. Therefore it would work well on
a point-to-point link.

>    Since it is not typical for the mobile node to initiate an IKEv2
>    exchange with its home agent and not possible to send a Binding
>    Update from the home link, there is a need for other bootstrapping
>    mechanisms that would work across all point-to-point home links.
>    However, this would result in the mobile node using different
>    bootstrapping mechanisms depending on the point-to-point that
> appears as the home link.  The mobile node would also end with using
> different bootstrapping mechanisms when attached to the home link and
> when attached to the visited link.  To avoid this, it would be
> desirable to use the same bootstrapping mechanisms irrespective of
> the point-to-point link that appears as the home link and/or the
> visited link.

But it looks like the same IKEv2 based bootstrapping mechanism is used
in everycase, it is just that once the MN figures out it is at home it
can drop the IKE and IPsec SA's.

> 3.4.  Forwarding at the Home Agent
>
>    According to RFC 3775, when the mobile node is attached to the
> home link, it behaves as a regular IPv6 host and is able to
> send/receive packets directly without going through the home agent.
> In case the home agent needs to send any packet to the mobile node,
> it has a valid neighbor cache entry for the mobile node which is then
> used to forward packets to the mobile node.
>
>    When point-to-point links are used a home links, then the packets
>    meant for the mobile node always reach the home agent first and
> are then forwarded to the mobile node.  However, the home agent
> cannot construct a neighbor cache entry for the mobile node, since
> most of the point-to-point links mentioned in Section 1 do not
> support sending neighbor solicitation and receiving neighbor
> advertisement messages.

Again, if IPsec was fixed as in Pasi's proposal then it would work just
fine. Other point-to-point links happily carry multicast traffic.

> 3.5.  Indicating Service Selection Option
>
>    A new extension, the Service Selection for Mobile IPv6, has been
>    specified in [13] for the mobile node to indicate to the home
> agent which service it wants to access.  The Service Selection option
> is sent in the Binding Update.  When the mobile node boots up in the
> home link, it won't be able to indicate the service it wants to
> access to the home agent, since the Binding Update message is not
> sent from the home link.
>
>    It is possible to indicate the Service the mobile node wants to
>    access in the IKEv2 exchange with the home agent.  The service
>    information is encoded in the IDr payload in the IKEv2 exchange.
>    However, this requires the mobile node to initiate an IKEv2
> exchange with the mobile node from the home link.  According to RFC
> 3775, the mobile node does not have to initiate an IKEv2 exchange
> when it boots up in the home link.

Same goes here than for bootstrapping. There's indeed a need to send a
BU, so does the MN, then IKEv2 kicks in, BU is sent out, and no
problem.

In conclusion I am not sure there's a clear case to extend MIPv6. Maybe
there's some room for a document clarifying how implementation should
behave with bootstrapping while on the home link.

What do you think?

Best,

--julien

On Wednesday 13 February 2008, Vijay Devarapalli wrote:
> Hello folks,
>
> Here is a draft that describes issues with the mobile node
> booting up on the home link over point-to-point links. It
> describes the issues and suggests a possible solution.
>
> http://www.ietf.org/internet-drafts/draft-devarapalli-mext-mipv6-home
>-link-00.txt
>
> Comments/reviews are welcome.
>
> Vijay
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> http://www.ietf.org/mailman/listinfo/mext


_______________________________________________
MEXT mailing list
MEXT@ietf.org
http://www.ietf.org/mailman/listinfo/mext

--0-687559432-1203349381=:90673-- --===============0822364409== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext --===============0822364409==-- From mext-bounces@ietf.org Mon Feb 18 12:13:56 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A770E3A686F; Mon, 18 Feb 2008 12:13:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.707 X-Spam-Level: X-Spam-Status: No, score=-0.707 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKHFjZ+FpNDU; Mon, 18 Feb 2008 12:13:47 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 450E13A6D46; Mon, 18 Feb 2008 12:13:47 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B40F28C370 for ; Mon, 18 Feb 2008 12:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F52IHlqh2xuA for ; Mon, 18 Feb 2008 12:13:45 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 076093A6CDB for ; Mon, 18 Feb 2008 12:13:45 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 7A290198D6C for ; Mon, 18 Feb 2008 22:13:41 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 5170C19880F for ; Mon, 18 Feb 2008 22:13:36 +0200 (EET) Message-ID: <47B9E6E6.3020901@piuha.net> Date: Mon, 18 Feb 2008 12:13:26 -0800 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: mext@ietf.org References: <20080218193001.F28C43A6899@core3.amsl.com> In-Reply-To: <20080218193001.F28C43A6899@core3.amsl.com> X-Virus-Scanned: ClamAV using ClamSMTP Subject: [MEXT] draft-arkko-mext-rfc3775-altcoa-check-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi all, I have posted a draft that suggests a modification of the rules regarding Alternate Care-of Address checking. The rationale for the change is in the draft -- it is something that came up during the interim; there are closed networks that apply Mobile IPv6 and ingress filtering, and it would be useful in those networks to be able to be strict about what addresses the option can contain. The big question is if something today relies on the option value being able to differ from the source IP address. The draft talks about this as well and preliminarily I do not see a problem. But I would appreciate discussion on this. Jari > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Verifying Correctness of Alternate Care-of Address Option > Author(s) : J. Arkko > Filename : draft-arkko-mext-rfc3775-altcoa-check-00.txt > Pages : 6 > Date : 2008-02-18 > > This document revises the RFC 3775 rules on how Alternate Care-of > Address option is processed. Alternate Care-of Address option is > used to carry the current care-of address inside a Mobility Header > message. This is used in addition to the source address in the > packet in order to ensure that the care-of address is protected by > IPsec ESP, the security mechanism that protects Mobility Header > messages. Unfortunately, RFC 3775 did not require verification that > the source address and care-of address are the same. This document > adds that requirement. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-arkko-mext-rfc3775-altcoa-check-00.txt > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Feb 18 12:43:26 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BD393A6E05; Mon, 18 Feb 2008 12:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[AWL=-1.453, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+xPVa+OwJAR; Mon, 18 Feb 2008 12:43:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BB8228C583; Mon, 18 Feb 2008 12:40:20 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA84728C583 for ; Mon, 18 Feb 2008 12:40:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZEjGa5m6V-x for ; Mon, 18 Feb 2008 12:40:17 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id D0FF828C551 for ; Mon, 18 Feb 2008 12:38:58 -0800 (PST) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 18 Feb 2008 12:38:56 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m1IKcuxr030462 for ; Mon, 18 Feb 2008 12:38:56 -0800 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m1IKcuuM007431 for ; Mon, 18 Feb 2008 20:38:56 GMT Date: Mon, 18 Feb 2008 12:38:56 -0800 (PST) From: Sri Gundavelli To: mext@ietf.org Message-ID: MIME-Version: 1.0 Content-ID: Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [MEXT] I-D Action:draft-ietf-mext-nemo-mib-00.txt (fwd) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org We have addressed the comments that we received on this draft. Special thanks to Alex for his thorough review. Please review and comment. Regards Sri ---------- Forwarded message ---------- Date: Mon, 18 Feb 2008 03:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-nemo-mib-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : NEMO Management Information Base Author(s) : S. Gundavelli, et al. Filename : draft-ietf-mext-nemo-mib-00.txt Pages : 41 Date : 2008-02-15 This memo defines a portion of the Management Information Base (MIB), the network mobility support (NEMO) MIB, for use with network management protocols in the Internet community. In particular, the NEMO MIB will be used to monitor and control a mobile ipv6 node with NEMO functionality. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-mib-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-mext-nemo-mib-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-mext-nemo-mib-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. _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Feb 18 12:52:21 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22B7C28C6BA; Mon, 18 Feb 2008 12:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.864 X-Spam-Level: X-Spam-Status: No, score=-1.864 tagged_above=-999 required=5 tests=[AWL=-1.427, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Of1DUkO09K3; Mon, 18 Feb 2008 12:52:19 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C31E3A6C3F; Mon, 18 Feb 2008 12:49:58 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8755D28C5C4 for ; Mon, 18 Feb 2008 12:49:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBW4uKDPOC8q for ; Mon, 18 Feb 2008 12:49:56 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 808F03A6D97 for ; Mon, 18 Feb 2008 12:45:06 -0800 (PST) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 18 Feb 2008 12:45:02 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m1IKj25U025946 for ; Mon, 18 Feb 2008 12:45:02 -0800 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m1IKj2uM010475 for ; Mon, 18 Feb 2008 20:45:02 GMT Date: Mon, 18 Feb 2008 12:45:01 -0800 (PST) From: Sri Gundavelli To: mext@ietf.org Message-ID: MIME-Version: 1.0 Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [MEXT] New Version Notification for draft-sgundave-mext-gre-tunnel-request-option-00 (fwd) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org We have posted the draft on GRE Tunnel Request option that can be used by a mobile node/mobile router for requesting GRE encapsulation mode. Regards Sri ---------- Forwarded message ---------- Date: Mon, 18 Feb 2008 02:27:58 -0800 (PST) From: IETF I-D Submission Tool To: sgundave@cisco.com Cc: kleung@cisco.com Subject: New Version Notification for draft-sgundave-mext-gre-tunnel-request-option-00 A new version of I-D, draft-sgundave-mext-gre-tunnel-request-option-00.txt has been successfuly submitted by Sri Gundavelli and posted to the IETF repository. Filename: draft-sgundave-mext-gre-tunnel-request-option Revision: 00 Title: GRE Tunnel Request Option for Mobile IPv6 Creation_date: 2008-02-17 WG ID: Independent Submission Number_of_pages: 10 Abstract: This document specifies a new mobility option for use in Mobile IPv6 Binding Update and Binding Acknowledgement messages. This option can be used by a mobile node or a mobile router to request the home agent to enable GRE encapsulation mode for the datagram tunneling. The GRE encapsulation mode can be negotiated for IPv6 transport and also for the IPv4 transport when using Dual-Stack Mobile IPv6 extensions. The IETF Secretariat. _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Feb 18 14:39:00 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E1F43A6D97; Mon, 18 Feb 2008 14:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.765 X-Spam-Level: X-Spam-Status: No, score=-1.765 tagged_above=-999 required=5 tests=[AWL=-1.328, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8N4euyiWZOg5; Mon, 18 Feb 2008 14:38:59 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC6553A68B8; Mon, 18 Feb 2008 14:38:59 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42D3C3A6812 for ; Mon, 18 Feb 2008 14:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3zbNLA24ejk for ; Mon, 18 Feb 2008 14:38:57 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 7F4103A6CDA for ; Mon, 18 Feb 2008 14:38:56 -0800 (PST) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 18 Feb 2008 14:38:54 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m1IMcsA5014421; Mon, 18 Feb 2008 14:38:54 -0800 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1IMcrJh001354; Mon, 18 Feb 2008 22:38:54 GMT Date: Mon, 18 Feb 2008 14:38:53 -0800 (PST) From: Sri Gundavelli To: Jari Arkko In-Reply-To: <47B9E6E6.3020901@piuha.net> Message-ID: References: <20080218193001.F28C43A6899@core3.amsl.com> <47B9E6E6.3020901@piuha.net> MIME-Version: 1.0 Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] draft-arkko-mext-rfc3775-altcoa-check-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Jari, For seperating the control and data plane, there are some folks who are thinking of using Alt-CoA option to carry a different address than what is in the source address of the field. There seem to be some proposals in WiMAX, applying PMIP and with the functional split of MAG, using this option for registering the tunnel endpoint which is on a different entity. That wont work with this new restriction. Not sure, if we can control this enforcement using a config option. Personally, I dont have any issue with this change. Regards Sri On Mon, 18 Feb 2008, Jari Arkko wrote: > Hi all, > > I have posted a draft that suggests a modification of the rules > regarding Alternate Care-of Address checking. The rationale for the > change is in the draft -- it is something that came up during the > interim; there are closed networks that apply Mobile IPv6 and ingress > filtering, and it would be useful in those networks to be able to be > strict about what addresses the option can contain. > > The big question is if something today relies on the option value being > able to differ from the source IP address. The draft talks about this as > well and preliminarily I do not see a problem. But I would appreciate > discussion on this. > > Jari > >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> Title : Verifying Correctness of Alternate Care-of Address Option >> Author(s) : J. Arkko >> Filename : draft-arkko-mext-rfc3775-altcoa-check-00.txt >> Pages : 6 >> Date : 2008-02-18 >> >> This document revises the RFC 3775 rules on how Alternate Care-of >> Address option is processed. Alternate Care-of Address option is >> used to carry the current care-of address inside a Mobility Header >> message. This is used in addition to the source address in the >> packet in order to ensure that the care-of address is protected by >> IPsec ESP, the security mechanism that protects Mobility Header >> messages. Unfortunately, RFC 3775 did not require verification that >> the source address and care-of address are the same. This document >> adds that requirement. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-arkko-mext-rfc3775-altcoa-check-00.txt >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Feb 18 18:36:54 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 310893A6D7C; Mon, 18 Feb 2008 18:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.245 X-Spam-Level: X-Spam-Status: No, score=-1.245 tagged_above=-999 required=5 tests=[AWL=-0.808, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AVucEHBI5od; Mon, 18 Feb 2008 18:36:53 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 400D63A6955; Mon, 18 Feb 2008 18:36:53 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC9923A6890 for ; Mon, 18 Feb 2008 18:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ShAyYbIBNcf for ; Mon, 18 Feb 2008 18:36:51 -0800 (PST) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id B8FAC3A6955 for ; Mon, 18 Feb 2008 18:36:50 -0800 (PST) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile11) with ESMTP id m1J2alAd000878; Tue, 19 Feb 2008 11:36:47 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb2) with ESMTP id m1J2alH02968; Tue, 19 Feb 2008 11:36:47 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili05) with ESMTP id m1J2ak122078; Tue, 19 Feb 2008 11:36:46 +0900 (JST) Received: from NW-Sephiroth ([10.81.113.116]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Feb 2008 10:35:39 +0800 Received: from NWSephiroth by NW-Sephiroth (PGP Universal service); Tue, 19 Feb 2008 10:35:36 +0800 X-PGP-Universal: processed; by NW-Sephiroth on Tue, 19 Feb 2008 10:35:36 +0800 From: "Benjamin Lim" To: "'Jari Arkko'" References: <20080218193001.F28C43A6899@core3.amsl.com> <47B9E6E6.3020901@piuha.net> Date: Tue, 19 Feb 2008 10:35:36 +0800 Message-ID: <032201c872a0$1be44e20$7571510a@psl.local> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AchyaqiNoS1YCe5vQo6p/cBdoXV2CwANGziQ In-Reply-To: <47B9E6E6.3020901@piuha.net> X-OriginalArrivalTime: 19 Feb 2008 02:35:39.0456 (UTC) FILETIME=[1D746400:01C872A0] Cc: mext@ietf.org Subject: Re: [MEXT] draft-arkko-mext-rfc3775-altcoa-check-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Jari, Two questions. 1) In section 3, > If the address in the Alternate Care-of Address option > is not the same as either the home address or the Source > Address field in the IPv6 header of the Binding Update > packet, then by default the receiving node MUST send > back a Binding Acknowledgement with status code > TBD-BY-IANA (mismatching source address)." Does the HA/CN send this BA to the address specified in the BU source address field or the the address specified in the AltCoA field? 2) Does the MN need to reply something back to the HA/CN when receiving this BA mesage? Regards, Benjamin Lim > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Jari Arkko > Sent: Tuesday, February 19, 2008 4:13 AM > To: mext@ietf.org > Subject: [MEXT] draft-arkko-mext-rfc3775-altcoa-check-00.txt > > Hi all, > > I have posted a draft that suggests a modification of the > rules regarding Alternate Care-of Address checking. The > rationale for the change is in the draft -- it is something > that came up during the interim; there are closed networks > that apply Mobile IPv6 and ingress filtering, and it would be > useful in those networks to be able to be strict about what > addresses the option can contain. > > The big question is if something today relies on the option > value being able to differ from the source IP address. The > draft talks about this as well and preliminarily I do not see > a problem. But I would appreciate discussion on this. > > Jari > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > > Title : Verifying Correctness of Alternate > Care-of Address Option > > Author(s) : J. Arkko > > Filename : draft-arkko-mext-rfc3775-altcoa-check-00.txt > > Pages : 6 > > Date : 2008-02-18 > > > > This document revises the RFC 3775 rules on how Alternate Care-of > > Address option is processed. Alternate Care-of Address > option is used > > to carry the current care-of address inside a Mobility > Header message. > > This is used in addition to the source address in the > packet in order > > to ensure that the care-of address is protected by IPsec ESP, the > > security mechanism that protects Mobility Header messages. > > Unfortunately, RFC 3775 did not require verification that > the source > > address and care-of address are the same. This document adds that > > requirement. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-arkko-mext-rfc3775-altcoa-ch > > eck-00.txt > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Feb 18 19:01:07 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B601D3A6826; Mon, 18 Feb 2008 19:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.086 X-Spam-Level: X-Spam-Status: No, score=-1.086 tagged_above=-999 required=5 tests=[AWL=-0.649, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpNg49s1HP1b; Mon, 18 Feb 2008 19:01:06 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C77FC3A6915; Mon, 18 Feb 2008 19:01:06 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C360B3A6915 for ; Mon, 18 Feb 2008 19:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6EN4MyycJK4 for ; Mon, 18 Feb 2008 19:01:04 -0800 (PST) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.185]) by core3.amsl.com (Postfix) with ESMTP id 2B5683A6826 for ; Mon, 18 Feb 2008 19:01:03 -0800 (PST) Received: by rv-out-0910.google.com with SMTP id l15so1317754rvb.49 for ; Mon, 18 Feb 2008 19:01:00 -0800 (PST) Received: by 10.141.99.4 with SMTP id b4mr4317097rvm.275.1203390060537; Mon, 18 Feb 2008 19:01:00 -0800 (PST) Received: from ?203.178.143.221? ( [203.178.143.221]) by mx.google.com with ESMTPS id l31sm2516830rvb.27.2008.02.18.19.00.57 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Feb 2008 19:00:59 -0800 (PST) From: RYUJI WAKIKAWA To: QIU Ying In-Reply-To: <003201c8721d$0ae7f190$3589a8c0@precision5570> X-Priority: 3 References: <7C5C82DC-66BA-4C6E-9195-4B773C8D3542@gmail.com> <003201c8721d$0ae7f190$3589a8c0@precision5570> Message-Id: <950BDB72-2EF2-4C61-AA25-40059B1F1D04@gmail.com> Mime-Version: 1.0 (Apple Message framework v915) Date: Tue, 19 Feb 2008 12:00:55 +0900 X-Mailer: Apple Mail (2.915) Cc: mext@ietf.org Subject: Re: [MEXT] firewall docs review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, Qiu On 2008/02/18, at 19:57, QIU Ying wrote: > Hi, Ryuji > > Thanks for your comments. My response is inline. > > ----- Original Message ----- "RYUJI WAKIKAWA" wrote > > >> Hi Suresh and authors, >> >> I was asked to review draft-krishnan-mip6-firewall-admin-02 and >> draft-krishnan-mip6-firewall-vendor-02. >> >> - Can current filtering mechanism check the IP options field?! > > No. Current firewall filter does not support to check the IP options > field. It's up to implementation, isn't it? I can easily setup the firewall with PC which can check the IP options... Which firewall products are you assuming? Are there substantial reasons to say NO here? > >> If yes, the document should mention which IP options are appeared >> for which packets. >> An example is DST Opt for BU and RTHDR for BA. >> Otherwise, the operator might just block all the packets having >> RTHDR option regardless of BA. >> >> For example, in section 3.1 of draft-admin , >> Destination Address: Address of HA >> <-- adding Dest >> option (HoA option)? >> Next Header: 50 (ESP) >> Mobility Header Type: 5 (BU) > > For draft-admin, which purpose is BCP, so we could not solicit the > function here. But we could provide the filter in draft-vender. > >> >> - missing authentication option and DSMIP support? >> DSMIP will introduce much complexity to firewall setup. > > The target of these two draft is to make MIP6 signalling pass > through the firewalls. So, in my opinion, the issue of > authentication and DSMIP might be out of the scope. DSMIP seems to be adapted to many deployment case. why not:-) ryuji >> >> - RO is optional in the RFC3775. I am not sure you can treat >> RO signaling as same as the BU/BA for firewall filters setup. >> It might be good if you provide the minimum set of rules (BU/BA >> only) >> and the full set of rules (All MH signaling). > > Good comments. > > Regards and Thanks > Qiu Ying > > >> >> - why are these two separate documents? >> >> regards, >> ryuji >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> http://www.ietf.org/mailman/listinfo/mext > > > ------------ Institute For Infocomm Research - Disclaimer > -------------This email is confidential and may be privileged. If > you are not the intended recipient, please delete it and notify us > immediately. Please do not copy or use it for any purpose, or > disclose its contents to any other person. Thank > you.-------------------------------------------------------- _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Feb 19 01:19:00 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D2C53A6DD8; Tue, 19 Feb 2008 01:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[AWL=-0.363, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgictZRvIyo2; Tue, 19 Feb 2008 01:19:00 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A06628C4D8; Tue, 19 Feb 2008 01:18:55 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D61FD28C4AE for ; Tue, 19 Feb 2008 01:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jeG7bp8TM1t for ; Tue, 19 Feb 2008 01:18:53 -0800 (PST) Received: from mxs1.siemens.at (mxs1.siemens.at [194.138.12.131]) by core3.amsl.com (Postfix) with ESMTP id 430E83A696D for ; Tue, 19 Feb 2008 01:18:51 -0800 (PST) Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs1.siemens.at with ESMTP id m1J9IaVf028521; Tue, 19 Feb 2008 10:18:36 +0100 Received: from nets139a.ww300.siemens.net ([158.226.129.97]) by vies1k7x.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id m1J9IUl1018074; Tue, 19 Feb 2008 10:18:36 +0100 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Feb 2008 10:17:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Feb 2008 10:15:53 +0100 Message-ID: <3C31CDD06342EA4A8137716247B1CD68036C7ACF@zagh223a.ww300.siemens.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] draft-arkko-mext-rfc3775-altcoa-check-00.txt Thread-Index: Achyf0tycxiME4i+Tbu0RFrhEOZ5OgAVDlRw References: <20080218193001.F28C43A6899@core3.amsl.com><47B9E6E6.3020901@piuha.net> From: "Premec, Domagoj" To: "Sri Gundavelli" X-OriginalArrivalTime: 19 Feb 2008 09:17:48.0179 (UTC) FILETIME=[4B4B5630:01C872D8] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::080219101836-0B21CBB0-7E264773/0-0/0-15 X-purgate-size: 3483/0 Cc: mext@ietf.org Subject: Re: [MEXT] draft-arkko-mext-rfc3775-altcoa-check-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Sri, There was such a proposal in WiMAX, but this was before PMIP6 work in the IETF. Current discussions in WiMAX do not mention alt-CoA in this context. OTOH, any MAG could have a control plane blade and several data plane blades, so the concept is generally applicable. regards domagoj > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Sri Gundavelli > Sent: 18. veljaca 2008 23:39 > To: Jari Arkko > Cc: mext@ietf.org > Subject: Re: [MEXT] draft-arkko-mext-rfc3775-altcoa-check-00.txt > > Hi Jari, > > For seperating the control and data plane, there are some > folks who are thinking of using Alt-CoA option to carry a > different address than what is in the source address of the > field. There seem to be some proposals in WiMAX, applying > PMIP and with the functional split of MAG, using this option > for registering the tunnel endpoint which is on a different > entity. That wont work with this new restriction. Not sure, > if we can control this enforcement using a config option. > Personally, I dont have any issue with this change. > > Regards > Sri > > > On Mon, 18 Feb 2008, Jari Arkko wrote: > > > Hi all, > > > > I have posted a draft that suggests a modification of the rules > > regarding Alternate Care-of Address checking. The rationale for the > > change is in the draft -- it is something that came up during the > > interim; there are closed networks that apply Mobile IPv6 > and ingress > > filtering, and it would be useful in those networks to be > able to be > > strict about what addresses the option can contain. > > > > The big question is if something today relies on the option value > > being able to differ from the source IP address. The draft > talks about > > this as well and preliminarily I do not see a problem. But I would > > appreciate discussion on this. > > > > Jari > > > >> A New Internet-Draft is available from the on-line > Internet-Drafts directories. > >> > >> Title : Verifying Correctness of Alternate > Care-of Address Option > >> Author(s) : J. Arkko > >> Filename : draft-arkko-mext-rfc3775-altcoa-check-00.txt > >> Pages : 6 > >> Date : 2008-02-18 > >> > >> This document revises the RFC 3775 rules on how Alternate Care-of > >> Address option is processed. Alternate Care-of Address option is > >> used to carry the current care-of address inside a Mobility Header > >> message. This is used in addition to the source address in the > >> packet in order to ensure that the care-of address is protected by > >> IPsec ESP, the security mechanism that protects Mobility Header > >> messages. Unfortunately, RFC 3775 did not require > verification that > >> the source address and care-of address are the same. This > document > >> adds that requirement. > >> > >> A URL for this Internet-Draft is: > >> > http://www.ietf.org/internet-drafts/draft-arkko-mext-rfc3775-altcoa-c > >> heck-00.txt > >> > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > http://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Feb 19 01:50:30 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB40A28C4DE; Tue, 19 Feb 2008 01:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.529 X-Spam-Level: X-Spam-Status: No, score=-0.529 tagged_above=-999 required=5 tests=[AWL=-2.929, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_BAD_ID=2.837, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzIz-TwY4yMn; Tue, 19 Feb 2008 01:50:29 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF4183A6DF1; Tue, 19 Feb 2008 01:50:29 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 512533A69A8 for ; Tue, 19 Feb 2008 01:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvXE8nUtpyyd for ; Tue, 19 Feb 2008 01:50:28 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 836583A6A75 for ; Tue, 19 Feb 2008 01:50:28 -0800 (PST) Received: from chelo-it-uc3m-es.it.uc3m.es (chelo-it-uc3m-es.it.uc3m.es [163.117.139.32])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp01.uc3m.es (Postfix) with ESMTP id 90EF13C51C2;Tue, 19 Feb 2008 10:50:24 +0100 (CET) Message-Id: <33E73C11-496C-4BCD-B9AF-00761DE0B8E5@it.uc3m.es> From: marcelo bagnulo braun To: mext@ietf.org Mime-Version: 1.0 (Apple Message framework v915) Date: Tue, 19 Feb 2008 10:50:23 +0100 X-Mailer: Apple Mail (2.915) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-5.4115 TC:1F TRN:7 TV:5.0.1023(15738.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: Julien Laganier Subject: [MEXT] Call for agenda items X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, As you know, we are meeting in Philadelphia, so if you want to present something, please let us know, so we can prepare the agenda for the meeting. thanks, Julien and marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Feb 19 04:14:31 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDE053A6990; Tue, 19 Feb 2008 04:14:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.136 X-Spam-Level: X-Spam-Status: No, score=-1.136 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndxNZfXzF4p3; Tue, 19 Feb 2008 04:14:30 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84D623A68A6; Tue, 19 Feb 2008 04:14:30 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29C5B28C3B1 for ; Tue, 19 Feb 2008 04:14:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIvrUXWrpJ47 for ; Tue, 19 Feb 2008 04:14:28 -0800 (PST) Received: from omta04ps.mx.bigpond.com (omta04ps.mx.bigpond.com [144.140.83.156]) by core3.amsl.com (Postfix) with ESMTP id 849A13A68A6 for ; Tue, 19 Feb 2008 04:14:26 -0800 (PST) Received: from oaamta06ps.mx.bigpond.com ([124.190.105.201]) by omta04ps.mx.bigpond.com with ESMTP id <20080219121423.DAPS15911.omta04ps.mx.bigpond.com@oaamta06ps.mx.bigpond.com> for ; Tue, 19 Feb 2008 12:14:23 +0000 Received: from PC20005 ([124.190.105.201]) by oaamta06ps.mx.bigpond.com with ESMTP id <20080219121421.USSH15981.oaamta06ps.mx.bigpond.com@PC20005>; Tue, 19 Feb 2008 12:14:21 +0000 From: "Hesham Soliman" To: "'Julien Laganier'" , , Date: Tue, 19 Feb 2008 23:13:55 +1000 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchjOp+tBBZPPj39Q6+7x6ZGZVfkIgPvM+kg X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A090204.47BAC81D.016B,ss=1,fgs=0 Subject: [MEXT] DSMIPv6 Security considerations section 5.1 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi all, Sorry this took a long time but viruses (human ones) don't consider IETF deadlines! Here is a new take on section 5.1. There is a couple of Pasi's comments the I didn't include and have some clarifying questions on them below. Please keep reading after the text. Section 5.1: ============= After the mobile node detects movement it configures a new care-of address. If the mobile node is in an IPv4-only network, it removes binding update list entries for correspondent nodes since route optimisation cannot be supported. This may cause inbound packet losses as remote correspondent node are unaware of such movement. To avoid confusion in the correspondent node, the mobile node SHOULD deregister its binding with each correspondent node by sending a deregistration binding update. The deregistration binding update message is tunnelled to the home agent and onto the correspondent node. Following this, the mobile node sends the binding update message to the home agent. If the mobile node is in an IPv6- enabled network, the binding update is sent without IPv4/UDP encapsulation. If the mobile node is in an IPv4-only network, it encapsulates the BU in UDP/IPv4 as discussed in sections 4.2 and 4.4. In order to be able to send the binding update while in an IPv4-only network, the mobile node needs to use the new IPv4 care-of address in the outer header, which is different from the care-of address used in the existing tunnel. This should be done without permanently updating the tunnel within the mobile node's implementation in order to allow the mobile node to receive packets on the old care-of address until the binding acknowledgement is received. The method used to achieve this effect is implementation dependent and is outside the scope of this specification. Upon receiving the binding update message, the home agent updates its security association to include the mobile node's address as the tunnel header IP source address and the new port number. When the mobile node is located in a private IPv4 network (which is detected as described above), the new address and port number are allocated by the NAT. Based on the setting of the K flag in the binding update, the home agent updates its IKE security association to include the tunnel header IP address as that received in the outer header of the binding update message. The home agent may also need to change NAT traversal fields in the IKE_SA to enable the dyanmic update of the IP address and port number based on the reception of authenticated IKE messages, or authenticated packets using tunnel mode ESP. The dynamic updates are described in section 2.23 of RFC 4306. In order to allow the DSMIPv6 implementation in the home agent to detect the presence of a NAT on the path to the mobile node, it needs to compare the outer IPv4 source address with the IPv4 address in the alt-care-of address option. This implies that the information in the outer header will be preserved after IPsec processing and made available to the DSMIPv6 implementation in the home agent. Depending on the home agent's implementation, meeting this requirement may require changes to the IPsec implementation. The home agent will also enable or disable UDP encapsulation for outgoing ESP packets for the purpose of NAT traversal. If the mobile node were located in a private IPv4 network the address and port number are likely to be wrong as the NAT would likely allocate a different address and port number to traffic encapsulated in IPsec tunnels or to IKE messages. Hence, the mobile node updates the IKE SA in one of two ways. If the K flag was set, the mobile node SHOULD send an empty informational message, which results in the IKE module in the home agent to dynamically update the SA information. The IKE implementation in the home agent is REQUIRED to support this feature. Alternatively, the IKE SA should be re-negotiated. Note that updating the IKE SA MUST take place after the mobile node has sent the binding update and received the acknowledgement from the home agent. It is important to note that if the mobile node is located behind a NAT, its IPv4 care-of address seen by the DSMIPv6 module in the home agent upon receiving the binding update will differ from the IPv4 care-of address seen by the IKE module and the care-of address used for forwarding IPsec tunnel mode traffic. This is due to the fact that the NAT will probably allocate a different IP address and port number to each traffic stream. Hence, it is probable that different modules in the home agent will have a different care-of address that should be used for encapsulating traffic to the mobile node. After successfully processing the binding update, the home agent sends the binding acknowledgement to the mobile node's care-of address as received in the outer header of the packet containing the binding update. Upon receiving the binding acknowledgement the mobile node updates its local Security Association information to include the tunnel header IP source address, which is the the home agent's address. The mobile node may also need to enable or disable UDP encapsulation for outgoing ESP packets for the purpose of NAT traversal. The mobile node MAY use [MOBIKE] to update its IKE SA with the home agent. Using MOBIKE requires negotiating this capability with the home agent when establishing the SA. In this case, the mobile node and the home agent need not update their IPsec SAs locally as this step is performed by MOBIKE. Furthermore, the use of MOBIKE allows the mobile node to update the SA independently of the binding update exchange. Hence, there is no need for the mobile node to wait for a binding acknowledgement before performing MOBIKE. The use of MOBIKE is OPTIONAL in this specification. > 3) The spec has to say something about using port 500 vs. port 4500 > for IPsec traffic, since the text in RFC 4306 Section 2.23 won't > work as is (MOBIKE had to deal with this issue as well, see RFC > 4555 Section 3.3). > > 4) Text has to mention that MN needs to enable/disable sending > IPsec keep-alives (for port 4500) depending on whether it's behind > a NAT or not. => I assume point 4) above is somewhat related to what we say about point 3). I read section 3.3 of RFC 4555 but I'm still unsure about what to say here. Are you recommending that we follow the same route as Mobike and use port 4500 if the MN and HA support it? In this case, I guess there is something to say about point 4) because 4500 is used even if there is no NAT. Otherwise, if we only use 4500 if a NAT is detected then it's obvious that we have to always send kepp alives on port 4500. Am I missing something? If you have suggested text for point 3) that would be great. Thanks, Hesham > > Best regards, > Pasi _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Feb 19 04:45:00 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CA5F3A6AA6; Tue, 19 Feb 2008 04:45:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.737 X-Spam-Level: X-Spam-Status: No, score=-0.737 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLeed3+xqA24; Tue, 19 Feb 2008 04:44:59 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 112FC28C4E8; Tue, 19 Feb 2008 04:44:59 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F3CE28C4E8 for ; Tue, 19 Feb 2008 04:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFFt0pjgLmzi for ; Tue, 19 Feb 2008 04:44:56 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by core3.amsl.com (Postfix) with ESMTP id B16353A6A60 for ; Tue, 19 Feb 2008 04:44:55 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id d21so626024nfb.39 for ; Tue, 19 Feb 2008 04:44:52 -0800 (PST) Received: by 10.78.175.14 with SMTP id x14mr11235202hue.12.1203425091931; Tue, 19 Feb 2008 04:44:51 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id f6sm3598466nfh.21.2008.02.19.04.44.49 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Feb 2008 04:44:51 -0800 (PST) From: Julien Laganier To: Pasi.Eronen@nokia.com Date: Tue, 19 Feb 2008 13:45:07 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200802191345.08554.julien.IETF@laposte.net> Cc: mext@ietf.org, Hesham Soliman Subject: [MEXT] Offlist -- Re: DSMIPv6 Security considerations section 5.1 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Pasi, Thanks again for spending time reviewing and discussing the DSMIPv6 specification. Hesham has posted updated text trying to address the concerns you had. We'd really like to resolve any remaining issues you might still have before the cut-off on next Monday. Would be great if you had time to review the updated text ASAP and posts your impressions on the mailing list so that we can discuss the way forward. Thanks, and best regards, --julien On Tuesday 19 February 2008, Hesham Soliman wrote: > Hi all, > > Sorry this took a long time but viruses (human ones) don't consider > IETF deadlines! Here is a new take on section 5.1. There is a couple > of Pasi's comments the I didn't include and have some clarifying > questions on them below. Please keep reading after the text. > > Section 5.1: > ============= > > After the mobile node detects movement it configures a new care-of > address. If the mobile node is in an IPv4-only network, it removes > binding update list entries for correspondent nodes since route > optimisation cannot be supported. This may cause inbound packet > losses as remote correspondent node are unaware of such movement. To > avoid confusion in the correspondent node, the mobile node SHOULD > deregister its binding with each correspondent node by sending a > deregistration binding update. The deregistration binding update > message is tunnelled to the home agent and onto the correspondent > node. > > Following this, the mobile node sends the binding update message to > the home agent. If the mobile node is in an IPv6- enabled network, > the binding update is sent without IPv4/UDP encapsulation. If the > mobile node is in an IPv4-only network, it encapsulates the BU in > UDP/IPv4 as discussed in sections 4.2 and 4.4. In order to be able to > send the binding update while in an IPv4-only network, the mobile > node needs to use the new IPv4 care-of address in the outer header, > which is different from the care-of address used in the existing > tunnel. This should be done without permanently updating the tunnel > within the mobile node's implementation in order to allow the mobile > node to receive packets on the old care-of address until the binding > acknowledgement is received. The method used to achieve this effect > is implementation dependent and is outside the scope of this > specification. > > > Upon receiving the binding update message, the home agent updates its > security association to include the mobile node's address as the > tunnel header IP source address and the new port number. When the > mobile node is located in a private IPv4 network (which is detected > as described above), the new address and port number are allocated by > the NAT. Based on the setting of the K flag in the binding update, > the home agent updates its IKE security association to include the > tunnel header IP address as that received in the outer header of the > binding update message. The home agent may also need to change NAT > traversal fields in the IKE_SA to enable the dyanmic update of the IP > address and port number based on the reception of authenticated IKE > messages, or authenticated packets using tunnel mode ESP. The > dynamic updates are described in section 2.23 of RFC 4306. > > In order to allow the DSMIPv6 implementation in the home agent to > detect the presence of a NAT on the path to the mobile node, it > needs to compare the outer IPv4 source address with the IPv4 address > in the alt-care-of address option. This implies that the information > in the outer header will be preserved after IPsec processing and made > available to the DSMIPv6 implementation in the home agent. Depending > on the home agent's implementation, meeting this requirement may > require changes to the IPsec implementation. > > The home agent will also enable or disable UDP encapsulation for > outgoing ESP packets for the purpose of NAT traversal. If the mobile > node were located in a private IPv4 network the address and port > number are likely to be wrong as the NAT would likely allocate a > different address and port number to traffic encapsulated in IPsec > tunnels or to IKE messages. Hence, the mobile node updates the IKE > SA in one of two ways. If the K flag was set, the mobile node SHOULD > send an empty informational message, which results in the IKE module > in the home agent to dynamically update the SA information. The IKE > implementation in the home agent is REQUIRED to support this feature. > Alternatively, the IKE SA should be re-negotiated. Note that > updating the IKE SA MUST take place after the mobile node has sent > the binding update and received the acknowledgement from the home > agent. > > It is important to note that if the mobile node is located behind a > NAT, its IPv4 care-of address seen by the DSMIPv6 module in the home > agent upon receiving the binding update will differ from the IPv4 > care-of address seen by the IKE module and the care-of address used > for forwarding IPsec tunnel mode traffic. This is due to the fact > that the NAT will probably allocate a different IP address and port > number to each traffic stream. Hence, it is probable that different > modules in the home agent will have a different care-of address that > should be used for encapsulating traffic to the mobile node. > > After successfully processing the binding update, the home agent > sends the binding acknowledgement to the mobile node's care-of > address as received in the outer header of the packet containing the > binding update. > > Upon receiving the binding acknowledgement the mobile node updates > its local Security Association information to include the tunnel > header IP source address, which is the the home agent's address. The > mobile node may also need to enable or disable UDP encapsulation for > outgoing ESP packets for the purpose of NAT traversal. > > The mobile node MAY use [MOBIKE] to update its IKE SA with the home > agent. Using MOBIKE requires negotiating this capability with the > home agent when establishing the SA. In this case, the mobile node > and the home agent need not update their IPsec SAs locally as this > step is performed by MOBIKE. Furthermore, the use of MOBIKE allows > the mobile node to update the SA independently of the binding update > exchange. Hence, there is no need for the mobile node to wait for a > binding acknowledgement before performing MOBIKE. The use of MOBIKE > is OPTIONAL in this specification. > > > 3) The spec has to say something about using port 500 vs. port > > 4500 for IPsec traffic, since the text in RFC 4306 Section 2.23 > > won't work as is (MOBIKE had to deal with this issue as well, see > > RFC 4555 Section 3.3). > > > > 4) Text has to mention that MN needs to enable/disable sending > > IPsec keep-alives (for port 4500) depending on whether it's behind > > a NAT or not. > > => I assume point 4) above is somewhat related to what we say about > point 3). I read section 3.3 of RFC 4555 but I'm still unsure about > what to say here. Are you recommending that we follow the same route > as Mobike and use port 4500 if the MN and HA support it? In this > case, I guess there is something to say about point 4) because 4500 > is used even if there is no NAT. Otherwise, if we only use 4500 if a > NAT is detected then it's obvious that we have to always send kepp > alives on port 4500. Am I missing something? > If you have suggested text for point 3) that would be great. > > Thanks, > Hesham > > > Best regards, > > Pasi _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Feb 19 05:39:34 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F70D28C55E; Tue, 19 Feb 2008 05:39:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.839 X-Spam-Level: X-Spam-Status: No, score=-0.839 tagged_above=-999 required=5 tests=[AWL=-0.402, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3k7pbAmHWU8Y; Tue, 19 Feb 2008 05:39:33 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FBFA3A6A8F; Tue, 19 Feb 2008 05:39:33 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF1503A6A14 for ; Tue, 19 Feb 2008 05:39:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MkxiPbGMJCG for ; Tue, 19 Feb 2008 05:39:31 -0800 (PST) Received: from ndjsbar02.ndc.nasa.gov (ndjsbar02.ndc.nasa.gov [198.120.25.39]) by core3.amsl.com (Postfix) with ESMTP id 1AA893A69D0 for ; Tue, 19 Feb 2008 05:39:30 -0800 (PST) Received: from ndjsxgw03.ndc.nasa.gov (ndjsxgw03.ndc.nasa.gov [129.166.32.111]) by ndjsbar02.ndc.nasa.gov (Spam Firewall) with ESMTP id CDA53524091; Tue, 19 Feb 2008 07:39:27 -0600 (CST) Received: from ndjsxgw03.ndc.nasa.gov (ndjsxgw03.ndc.nasa.gov [129.166.32.111]) by ndjsbar02.ndc.nasa.gov with ESMTP id IOAD7BgzF4NTXFF9; Tue, 19 Feb 2008 07:39:27 -0600 (CST) Received: from NDJSEVS23A.ndc.nasa.gov ([129.166.32.223]) by ndjsxgw03.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Feb 2008 07:39:27 -0600 MIME-Version: 1.0 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Date: Tue, 19 Feb 2008 07:39:16 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] firewall-vendor and firewall-admin review - editorial Thread-Index: AchyAiaOMSlm9ogrRWCHMIqCJh8EuwA+ht7A References: <47B605EE.1050707@ericsson.com> From: "Ivancic, William D. (GRC-RCN0)" To: "RYUJI WAKIKAWA" , "Suresh Krishnan" X-OriginalArrivalTime: 19 Feb 2008 13:39:27.0576 (UTC) FILETIME=[D8DD3580:01C872FC] Cc: mext@ietf.org Subject: Re: [MEXT] firewall-vendor and firewall-admin review - editorial X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Comments In line: > >> > >> My recommendation is that vendors should provide some type > of uniform > >> signaling to indicate that MIP signaling was administratively > >> filtered. > >> Perhaps some new ICMP message or at least a recommendation > of which > >> to send. > > > > ICMPv6 Type 1 (Destination unreachable) message with code 1 - > > communication with destination administratively prohibited > seems like > > a good fit for this, but I am open to the idea of a new type/code > > Any notification is useful to know the firewall condition for > the debugging purpose. > But how can the MIP6 stack process these ICMP packets? > Are you going to specify the new MN's behavior here ? > > regards, > ryuji Ruuji, I don't think it is necessary to specify new MN behaviour. It would just be nice BCP to have a consistant ICMP message - probably not even a new one - so that if/when things break it is a little easier to track down. The suggested ICMPv6 Type 1 reply seems reasonable to me. /will _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Feb 19 06:18:51 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C21C28C54E; Tue, 19 Feb 2008 06:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.406 X-Spam-Level: **** X-Spam-Status: No, score=4.406 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STNjxitlWICm; Tue, 19 Feb 2008 06:18:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B45B28C588; Tue, 19 Feb 2008 06:18:50 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDBDC28C581 for ; Tue, 19 Feb 2008 06:18:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nYdoQB7W8O4 for ; Tue, 19 Feb 2008 06:18:49 -0800 (PST) Received: from csnet1.cs.tsinghua.edu.cn (csnet1.cs.tsinghua.edu.cn [166.111.68.226]) by core3.amsl.com (Postfix) with SMTP id 9A21C28C4FF for ; Tue, 19 Feb 2008 06:18:48 -0800 (PST) Received: (qmail 21581 invoked by uid 0); 19 Feb 2008 14:32:41 -0000 Received: from unknown (HELO ThinkPad) (lihaitao@219.243.215.253) by csnet1.cs.tsinghua.edu.cn with SMTP; 19 Feb 2008 14:32:41 -0000 Date: Tue, 19 Feb 2008 22:18:44 +0800 From: "lihaitao" To: "mext" Message-ID: <200802192144272888731@csnet1.cs.tsinghua.edu.cn> X-mailer: Foxmail 6, 10, 201, 20 [cn] Mime-Version: 1.0 Subject: Re: [MEXT] [Recharter.2] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0839812967==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============0839812967== Content-Type: multipart/alternative; boundary="=====003_Dragon867045702135_=====" This is a multi-part message in MIME format. --=====003_Dragon867045702135_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgQWxsLA0KDQpJIHdvdWxkIGxpa2UgdG8gc3VwcG9ydDoNCg0KW0NSXSBJbnRlcmFjdGlvbiBi ZXR3ZWVuIE1vYmlsZSBJUHY2IGFuZCBJUHNlYy9JS0UgYnkgUEZfS0VZIGV4dGVuc2lvbnMNCg0K UmVnYXJkcw0KDQoNCg0KMjAwOC0wMi0xOSANCg0KDQoNCkxpIEhhaVRhbyAgIMDuuqPMzg0KDQpG SVQgNKOtMTA0LERlcHQub2YgQ29tcHV0ZXIgU2NpZW5jZSBhbmQgVGVjaG5vbG9neQ0KDQpUc2lu Z2h1YSBVbml2ZXJzaXR5LEJlaWppbmcsUC5SLkNoaW5hDQoNCk9mZmljZTowMTAtNjI3OTU4MTgt Njg1NA0KDQpFbWFpbDogICBsaWhhaXRhb0Bjc25ldDEuY3MudHNpbmdodWEuZWR1LmNuDQo= --=====003_Dragon867045702135_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC42MDAwLjE2NTQ0IiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT5CTE9DS1FVT1RFIHsNCglNQVJH SU4tVE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLUxFRlQ6IDJlbQ0KfQ0KT0wg ew0KCU1BUkdJTi1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4DQp9DQpVTCB7DQoJTUFSR0lO LVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHgNCn0NCjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9E WSBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogdmVyZGFuYSI+DQo8RElWPjxG T05UIGZhY2U9VmVyZGFuYSBzaXplPTI+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+ SGkgQWxsLDxCUj48QlI+SSB3b3VsZCBsaWtlIHRvIA0Kc3VwcG9ydDo8QlI+PEJSPltDUl0gSW50 ZXJhY3Rpb24gYmV0d2VlbiBNb2JpbGUgSVB2NiBhbmQgSVBzZWMvSUtFIGJ5IFBGX0tFWSANCmV4 dGVuc2lvbnM8QlI+PEJSPlJlZ2FyZHM8QlI+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNl PVZlcmRhbmEgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxG T05UIGZhY2U9VmVyZGFuYSBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJViBhbGlnbj1s ZWZ0PjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jYzBjMGMwIHNpemU9Mj4yMDA4LTAyLTE5IA0K PC9GT05UPjwvRElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+DQo8SFIgc3R5bGU9IldJRFRI OiAxMjJweDsgSEVJR0hUOiAycHgiIGFsaWduPWxlZnQgU0laRT0yPg0KDQo8RElWPjxGT05UIGZh Y2U9VmVyZGFuYSBjb2xvcj0jYzBjMGMwIHNpemU9Mj48U1BBTj4NCjxESVY+DQo8RElWPjxGT05U IGZhY2U9VmVyZGFuYSBzaXplPTI+TGkgSGFpVGFvJm5ic3A7Jm5ic3A7IMDuuqPMzjwvRk9OVD48 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+ RklUIDSjrTEwNCxEZXB0Lm9mIENvbXB1dGVyIFNjaWVuY2UgYW5kIA0KVGVjaG5vbG9neTwvRk9O VD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXpl PTI+VHNpbmdodWEgDQpVbml2ZXJzaXR5LEJlaWppbmcsUC5SLkNoaW5hPC9GT05UPjwvRElWPg0K PERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj5PZmZpY2U6 MDEwLTYyNzk1ODE4LTY4NTQ8L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPkVtYWlsOiZuYnNwOyZuYnNwOyA8QSANCmhyZWY9Im1h aWx0bzpsaWhhaXRhb0Bjc25ldDEuY3MudHNpbmdodWEuZWR1LmNuIj5saWhhaXRhb0Bjc25ldDEu Y3MudHNpbmdodWEuZWR1LmNuPC9BPjwvRk9OVD48L0RJVj48L0RJVj48L1NQQU4+PC9GT05UPjwv RElWPjwvRk9OVD48L0JPRFk+PC9IVE1MPg0K --=====003_Dragon867045702135_=====-- --===============0839812967== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext --===============0839812967==-- From mext-bounces@ietf.org Tue Feb 19 07:10:19 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B6D328C5FE; Tue, 19 Feb 2008 07:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.535 X-Spam-Level: X-Spam-Status: No, score=-0.535 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXqKk3+76pga; Tue, 19 Feb 2008 07:10:18 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6E1A28C606; Tue, 19 Feb 2008 07:10:18 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CA0728C55D for ; Tue, 19 Feb 2008 07:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSx53el+nTBa for ; Tue, 19 Feb 2008 07:10:16 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id ABFCB28C4FF for ; Tue, 19 Feb 2008 07:10:16 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 8BFC9198D6C; Tue, 19 Feb 2008 17:10:13 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 1A7FD19880F; Tue, 19 Feb 2008 17:08:03 +0200 (EET) Message-ID: <47BAF09C.8050503@piuha.net> Date: Tue, 19 Feb 2008 07:07:08 -0800 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: "Premec, Domagoj" , Sri Gundavelli References: <20080218193001.F28C43A6899@core3.amsl.com><47B9E6E6.3020901@piuha.net> <3C31CDD06342EA4A8137716247B1CD68036C7ACF@zagh223a.ww300.siemens.net> In-Reply-To: <3C31CDD06342EA4A8137716247B1CD68036C7ACF@zagh223a.ww300.siemens.net> X-Virus-Scanned: ClamAV using ClamSMTP Cc: mext@ietf.org Subject: Re: [MEXT] draft-arkko-mext-rfc3775-altcoa-check-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Premec, Sri, Distributed MN or MAG implementations might indeed have a need to use multiple source addresses. Its not clear to me though that there are cases where you simply cannot use one source address and care-of address consistently. E.g., can a control plane blade send a packet with a source address that belongs to a data plane blade? Input from implementors sought on this. Of course, if all else fails you can configure this check off. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Feb 19 07:54:56 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17FC428C60A; Tue, 19 Feb 2008 07:54:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCPPoon4HqaO; Tue, 19 Feb 2008 07:54:55 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29A0B3A6E0C; Tue, 19 Feb 2008 07:54:55 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCA5C3A6E0C for ; Tue, 19 Feb 2008 07:54:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jZzxWvx-171 for ; Tue, 19 Feb 2008 07:54:53 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id EFD1C3A6E0F for ; Tue, 19 Feb 2008 07:54:52 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id C72D5198D6C; Tue, 19 Feb 2008 17:54:49 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 13A13198D06; Tue, 19 Feb 2008 17:54:45 +0200 (EET) Message-ID: <47BAFBBB.2050700@piuha.net> Date: Tue, 19 Feb 2008 07:54:35 -0800 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: Benjamin Lim References: <20080218193001.F28C43A6899@core3.amsl.com> <47B9E6E6.3020901@piuha.net> <032201c872a0$1be44e20$7571510a@psl.local> In-Reply-To: <032201c872a0$1be44e20$7571510a@psl.local> X-Virus-Scanned: ClamAV using ClamSMTP Cc: mext@ietf.org Subject: Re: [MEXT] draft-arkko-mext-rfc3775-altcoa-check-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Benjamin, Thanks for your review. > Does the HA/CN send this BA to the address specified in the BU source > address field or the the address specified in the AltCoA field? > I have assumed that RFC 3775 Section 9.5.4 rules will apply. I will add an explicit statement about this. Note that the 9.5.4 rules imply a number of things, including for instance, that the message is sent to the source address (unless source was a multicast address). > 2) Does the MN need to reply something back to the HA/CN when receiving this > BA mesage? > No, general rules from RFC 3775 Section 11.7.3 apply: ... the mobile node can take steps to correct the cause of the error and retransmit the Binding Update ... Jari _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Feb 19 08:01:17 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40A1A28C60F; Tue, 19 Feb 2008 08:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.707 X-Spam-Level: X-Spam-Status: No, score=-1.707 tagged_above=-999 required=5 tests=[AWL=-1.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4m4h++F9l7aR; Tue, 19 Feb 2008 08:01:16 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AA873A6E04; Tue, 19 Feb 2008 08:01:16 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B76A03A6DF5 for ; Tue, 19 Feb 2008 08:01:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oceBnx8VoR8i for ; Tue, 19 Feb 2008 08:01:14 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 9388E3A68AE for ; Tue, 19 Feb 2008 08:01:13 -0800 (PST) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 19 Feb 2008 08:00:39 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m1JG0dkJ013397; Tue, 19 Feb 2008 08:00:39 -0800 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1JG0cJh004000; Tue, 19 Feb 2008 16:00:38 GMT Date: Tue, 19 Feb 2008 08:00:38 -0800 (PST) From: Sri Gundavelli To: Jari Arkko In-Reply-To: <47BAF09C.8050503@piuha.net> Message-ID: References: <20080218193001.F28C43A6899@core3.amsl.com><47B9E6E6.3020901@piuha.net> <3C31CDD06342EA4A8137716247B1CD68036C7ACF@zagh223a.ww300.siemens.net> <47BAF09C.8050503@piuha.net> MIME-Version: 1.0 Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] draft-arkko-mext-rfc3775-altcoa-check-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Jari, On Tue, 19 Feb 2008, Jari Arkko wrote: > Premec, Sri, > > Distributed MN or MAG implementations might indeed have a need to use > multiple source addresses. Its not clear to me though that there are > cases where you simply cannot use one source address and care-of address > consistently. E.g., can a control plane blade send a packet with a > source address that belongs to a data plane blade? Input from > implementors sought on this. > In the blade architecture systems, probably this is common as Premec pointed out. I do not think, using the source of the data plane in the control packets will help, as the BA will not come back to the control endpoint. All that will be there in the data card will be some routing state. > Of course, if all else fails you can configure this check off. Sure Sri _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Feb 19 08:04:43 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C06B28C606; Tue, 19 Feb 2008 08:04:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.644 X-Spam-Level: X-Spam-Status: No, score=-1.644 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOZS-r4GpYVh; Tue, 19 Feb 2008 08:04:42 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08E2428C5AB; Tue, 19 Feb 2008 08:04:42 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD25528C5D1 for ; Tue, 19 Feb 2008 08:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DToe0jCdQV5A for ; Tue, 19 Feb 2008 08:04:40 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id E3A673A6ACC for ; Tue, 19 Feb 2008 08:04:39 -0800 (PST) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 19 Feb 2008 08:04:37 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m1JG4bKJ010861; Tue, 19 Feb 2008 08:04:37 -0800 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m1JG4buM007780; Tue, 19 Feb 2008 16:04:37 GMT Date: Tue, 19 Feb 2008 08:04:37 -0800 (PST) From: Sri Gundavelli To: "Premec, Domagoj" In-Reply-To: <3C31CDD06342EA4A8137716247B1CD68036C7ACF@zagh223a.ww300.siemens.net> Message-ID: References: <20080218193001.F28C43A6899@core3.amsl.com><47B9E6E6.3020901@piuha.net> <3C31CDD06342EA4A8137716247B1CD68036C7ACF@zagh223a.ww300.siemens.net> MIME-Version: 1.0 Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] draft-arkko-mext-rfc3775-altcoa-check-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Premec, On Tue, 19 Feb 2008, Premec, Domagoj wrote: > Hi Sri, > > There was such a proposal in WiMAX, but this was before PMIP6 work in the IETF. Current discussions in WiMAX do not mention alt-CoA in this context. > Ok. If its not being used, that's good. > OTOH, any MAG could have a control plane blade and several data plane blades, so the concept is generally applicable. > Yes, I agree. Sri _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Feb 19 08:58:12 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4178828C5E7; Tue, 19 Feb 2008 08:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.461 X-Spam-Level: X-Spam-Status: No, score=0.461 tagged_above=-999 required=5 tests=[AWL=-1.402, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MANGLED_HOME=2.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyzAp0sV6cv3; Tue, 19 Feb 2008 08:58:10 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EBD428C271; Tue, 19 Feb 2008 08:58:10 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C90AB3A6A22 for ; Tue, 19 Feb 2008 08:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VyBhHujYOly for ; Tue, 19 Feb 2008 08:58:08 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by core3.amsl.com (Postfix) with ESMTP id B13A53A6821 for ; Tue, 19 Feb 2008 08:58:07 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id d21so676132nfb.39 for ; Tue, 19 Feb 2008 08:58:04 -0800 (PST) Received: by 10.78.66.5 with SMTP id o5mr11669313hua.22.1203440283358; Tue, 19 Feb 2008 08:58:03 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id f7sm570851nfh.2.2008.02.19.08.57.59 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Feb 2008 08:58:01 -0800 (PST) From: Julien Laganier To: Vijay Devarapalli Date: Tue, 19 Feb 2008 17:58:17 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <47B36D00.8020707@azairenet.com> <200802141724.48978.julien.IETF@laposte.net> <47B48A76.3090007@azairenet.com> In-Reply-To: <47B48A76.3090007@azairenet.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200802191758.18464.julien.IETF@laposte.net> Cc: mext@ietf.org Subject: Re: [MEXT] Home Link operation over p2p links X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Vijay, On Thursday 14 February 2008, Vijay Devarapalli wrote: > Hi Julien, > > Thanks for reviewing the document. A few high level comments > first. > > - When the home agent receives a Binding Update from a mobile > node on the home link, it is treated as a de-registration BU. > This is according to RFC 3775 and has not been updated by any > spec. When the home agent receives this BU from the mobile > node, if it does not have a valid binding cache entry, it > responds with the status 133 (Not home agent for this mobile > node) in the binding ack. When the mobile node boots up in > the point-to-point home link, the home agent does not have a > valid binding cache entry for the mobile node. The DS-MIPv6 > IPv4 home address and Mobile Network prefixes will not be > sent in the binding ack, since the Binding Update is seen as > a failed one. This is one of the reasons why we introduced a > new flag in the Binding Update. You're right. I overlooked that fact. But anyway if you conclude you're home from the IKEv2 exchange (because the INTERNAL_IP6_ADDRESS either fits in the prefix advertized from RAs or is in the same prefix that the "external" address the node configured on the home link), why would you need to send a BU. The IPv4 home address could be obtained from DCHPv4 (one could also think it comes thru an INTERNAL_IP4_ADDRESS in the IKEv2 exchange but let's not digress :) The mobile network prefix can come from DHCPv6 PD. > - I am aware of Pasi's draft on making IPsec tunnels look like > regular IPv6 links. It might be a good idea, but the problem is > that this draft has no "home" right now. Not sure if it will > get standardized in the time frame we are looking at. Some of > the architectures quoted in the draft are supposed to be > finalized this year. While I completely agree it is important to get specifications needed by SDOs relying on IETF protocols out in a timely fashion, as a general principle I do not think we should base protocol design decision on time constraints. This can be debated of course :) > - Regarding the mobile router using DHCPv6 prefix delegation > to acquire the mobile network prefixes when at home, there are > some issues. Since the mobile router is reachable only over the > p2p link, the home agent becomes the default router where all > the packets meant for the mobile router's mobile network > prefixes arrive. The home agent according to RFC 3963 does not > create forwarding entries for the mobile router prefixes until > it receives a Binding Update from the mobile router with the > prefixes in the message. The home agent does not advertise > reachability for the mobile network prefixes either until > there is a valid binding cache entry for the mobile router. When at home, why couldn't the mobile network prefix comes directly out of DHCPv6 PD, without BU. When a network prefix is delegated to a router, presumably forwarding entries for that prefix pointing to that router comes in place. If the router is a mobile router, when it leaves home it can send BUs to get that routed through a tunnel. What am I missing? > - Regarding the solution proposed in the draft, if it turns out > that we can resolve all the issues without having to introduce > a new flag in the Binding Update, that is fine with me. Great. > I am not going to respond in detail to your comments below, yet. > I want to check if you agree with the comments above first. Ok. --julien > Julien Laganier wrote: > > Hello Vijay, > > > > Thanks for submitting the draft in time! This is definitely helpful > > to assess the rechartering work item you proposed. > > > > > > > > I have couple of comments on your draft: > >> 3.1. Detecting Attachment to the Home Link > >> > >> In Mobile IPv6, a mobile node detects that it has attached to > >> the home link when it receives a router advertisement with the > >> home prefix. Some of the point-to-point links like IPsec tunnels > >> and PMIPv6 tunnels do not support running neighbor discovery in > >> the tunnels. When the home link is created by concatenating a GTP > >> tunnel with a PMIPv6 tunnel or an IPsec tunnel with PMIPv6 > >> tunnels, it becomes difficult for a router advertisement to be > >> sent over the concatenated tunnels. > > > > When "concatenating a GTP tunnel with a PMIPv6 tunnel", the RS can > > be sent through the GTP tunnel by the MN, up to the MAG. Then the > > MAG replies with an RA containing the Home Network Prefix, so there > > doesn't seem to be an issue. Am I missing something? > > > > When "concatenating an IPsec tunnel with a PMIPv6 tunnel", the MN > > cannot send the RS through the IPsec tunnel, and likewise, the MAG > > wouldn't be able to reply with an RA containing the Home Network > > Prefix. However, isn't the main issue at stake here the fact that > > IPsec "interfaces" are not fully fledged IPv6 interface, i.e. they > > do not support link-local addresses and multicast, etc. See Pasi's > > draft describing the issues and possible solution: > > > > draft-eronen-ipsec-ikev2-ipv6-config-02.txt > > > > It seems to me that if what Pasi proposes was implemented in the HA > > implementing IKEv2, then the issues your draft describe w.r.t. > > detecting home link attachment would vanish. If that is the case, > > wouldn't the right approach be to fix IPsec rather than extending > > MIPv6 because IPsec has a deficiency? > > > >> 3.2. Bootstrapping > >> > >> Mobile IPv6 bootstrapping [8] and [9] depends on the use of > >> IKEv2 between the mobile node and the home agent to bootstrap the > >> MIPv6 home address. According to RFC 3775, when the mobile node > >> is attached to the home link, it does not have to run IKEv1/IKEv2 > >> with the home agent to setup the necessary security associations. > >> Most often, the IKEv2 exchange is triggered by the need to send a > >> binding update. So if the mobile node boots up the home link, it > >> may not be able to use IKEv2 to bootstrap the MIPv6 home address. > > > > Purely based on RFC3775 the MN does not have to run IKE to setup > > SA's with HA when it is attached on its home link (But note that > > here we're talking about bootstrapping and that wasn't part of 3775 > > so we can't reason uniquely in terms of what 3775 says). However, > > the only ways for a MN to figure out that it is attached on its > > home link are either to compare its home address with the prefix > > advertized on-link in RA's. > > > > In the case of bootstrapping the MN does not know its home address > > before hand, thus it can't conclude that it is home before it > > acquire a home address via bootstrapping. > > > > By default it will thus assume it is not at home and initiate > > bootstrapping. Hence there is a need to send a BU to get the Home > > Address. As you note "the IKEv2 exchange is triggered by the need > > to send a binding update", thus I assume IKEv2 would be triggered > > to acquire an home address. > > > > Then the MN can conclude it is home (because HoA included in RA's > > PIO) and drop the IKE and IPsec association. > > > > It is true that it isn't written down but to me it looks logical > > that an implementor would follow these steps. Do you think such a > > procedure is inappropriate? > > > >> The IKEv2 exchange is only used to bootstrap the MIPv6 home > >> address. The DS-MIPv6 [11] IPv4 home address is obtained by the > >> mobile node using the exchange of Binding Update and Binding > >> Acknowledgement with the home agent. The Mobile Network Prefixes > >> required for mobile router operation, as described in [10], may > >> also obtained using the Binding Update and Binding Acknowledgement > >> exchange between the mobile router and the home agent. This is > >> specified in [12]. According to the current specifications, the > >> mobile node (or the mobile router) does not send a Binding Update > >> to the home agent when it is attached to the home link. > > > > Regarding IPv4 home address allocation, the same reasoning applies > > as with bootstrapping of the MIPv6 home address above: there would > > be a need to send a BU (to get the IPv4 HoA) thus IKE would be > > triggered, and dropped down once the v4 address is known. > > > > Regarding Mobile Network Prefix Assignment, there's no agreement > > yet whether this is done with extensions to BUs and BAs, or using > > DHCP. If it was done using DHCP it could work provided that DHCP > > requests can be sent thru the point-to-point link. Francis has > > proposed a method where a DHCP relay is collocated on the MR, and > > thus only unicast DHCP messages have to be sent and received. > > Therefore it would work well on a point-to-point link. > > > >> Since it is not typical for the mobile node to initiate an > >> IKEv2 exchange with its home agent and not possible to send a > >> Binding Update from the home link, there is a need for other > >> bootstrapping mechanisms that would work across all point-to-point > >> home links. However, this would result in the mobile node using > >> different bootstrapping mechanisms depending on the point-to-point > >> that appears as the home link. The mobile node would also end > >> with using different bootstrapping mechanisms when attached to the > >> home link and when attached to the visited link. To avoid this, > >> it would be desirable to use the same bootstrapping mechanisms > >> irrespective of the point-to-point link that appears as the home > >> link and/or the visited link. > > > > But it looks like the same IKEv2 based bootstrapping mechanism is > > used in everycase, it is just that once the MN figures out it is at > > home it can drop the IKE and IPsec SA's. > > > >> 3.4. Forwarding at the Home Agent > >> > >> According to RFC 3775, when the mobile node is attached to the > >> home link, it behaves as a regular IPv6 host and is able to > >> send/receive packets directly without going through the home > >> agent. In case the home agent needs to send any packet to the > >> mobile node, it has a valid neighbor cache entry for the mobile > >> node which is then used to forward packets to the mobile node. > >> > >> When point-to-point links are used a home links, then the > >> packets meant for the mobile node always reach the home agent > >> first and are then forwarded to the mobile node. However, the > >> home agent cannot construct a neighbor cache entry for the mobile > >> node, since most of the point-to-point links mentioned in Section > >> 1 do not support sending neighbor solicitation and receiving > >> neighbor advertisement messages. > > > > Again, if IPsec was fixed as in Pasi's proposal then it would work > > just fine. Other point-to-point links happily carry multicast > > traffic. > > > >> 3.5. Indicating Service Selection Option > >> > >> A new extension, the Service Selection for Mobile IPv6, has > >> been specified in [13] for the mobile node to indicate to the home > >> agent which service it wants to access. The Service Selection > >> option is sent in the Binding Update. When the mobile node boots > >> up in the home link, it won't be able to indicate the service it > >> wants to access to the home agent, since the Binding Update > >> message is not sent from the home link. > >> > >> It is possible to indicate the Service the mobile node wants to > >> access in the IKEv2 exchange with the home agent. The service > >> information is encoded in the IDr payload in the IKEv2 > >> exchange. However, this requires the mobile node to initiate an > >> IKEv2 exchange with the mobile node from the home link. According > >> to RFC 3775, the mobile node does not have to initiate an IKEv2 > >> exchange when it boots up in the home link. > > > > Same goes here than for bootstrapping. There's indeed a need to > > send a BU, so does the MN, then IKEv2 kicks in, BU is sent out, and > > no problem. > > > > In conclusion I am not sure there's a clear case to extend MIPv6. > > Maybe there's some room for a document clarifying how > > implementation should behave with bootstrapping while on the home > > link. > > > > What do you think? > > > > Best, > > > > --julien > > > > On Wednesday 13 February 2008, Vijay Devarapalli wrote: > >> Hello folks, > >> > >> Here is a draft that describes issues with the mobile node > >> booting up on the home link over point-to-point links. It > >> describes the issues and suggests a possible solution. > >> > >> http://www.ietf.org/internet-drafts/draft-devarapalli-mext-mipv6-h > >>ome -link-00.txt > >> > >> Comments/reviews are welcome. > >> > >> Vijay > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> http://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Feb 19 08:59:47 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC84F28C68E; Tue, 19 Feb 2008 08:59:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.736 X-Spam-Level: X-Spam-Status: No, score=-0.736 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yh690YJSwy9t; Tue, 19 Feb 2008 08:59:45 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B3C628C56B; Tue, 19 Feb 2008 08:59:45 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC8FB28C4F7 for ; Tue, 19 Feb 2008 08:59:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0xciL5OUYuH for ; Tue, 19 Feb 2008 08:59:43 -0800 (PST) Received: from mxs1.siemens.at (mxs1.siemens.at [194.138.12.131]) by core3.amsl.com (Postfix) with ESMTP id 6D33528C5E7 for ; Tue, 19 Feb 2008 08:59:42 -0800 (PST) Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs1.siemens.at with ESMTP id m1JGxatp017421; Tue, 19 Feb 2008 17:59:36 +0100 Received: from nets138a.ww300.siemens.net ([158.226.129.97]) by vies1k7x.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id m1JGxZVP004476; Tue, 19 Feb 2008 17:59:36 +0100 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Feb 2008 17:59:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Feb 2008 17:59:31 +0100 Message-ID: <3C31CDD06342EA4A8137716247B1CD68036F30EB@zagh223a.ww300.siemens.net> In-Reply-To: <47B4731B.8000702@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [MEXT] [Fwd: I-D Action:draft-krishnan-mext-ha-redirect-00.txt] Thread-Index: AchvKvaJiYFxqrTMQoKna6o9j+UWRAD5yKPA References: <47B338F4.60808@ericsson.com> <47B4731B.8000702@azairenet.com> From: "Premec, Domagoj" To: X-OriginalArrivalTime: 19 Feb 2008 16:59:35.0032 (UTC) FILETIME=[CDDD9780:01C87318] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::080219175936-0B21CBB0-569154C4/0-0/0-15 X-purgate-size: 6676/0 Cc: mext@ietf.org Subject: Re: [MEXT] [Fwd: I-D Action:draft-krishnan-mext-ha-redirect-00.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Suresh, Yet another alternative (in addition to what George and Vijay already suggested) would be: the HA could accept the initial BU, send BAck with the very short lifetime and then send the HA switch message. Using this method the HA would still be able to get rid of the MN in a matter of seconds. Though not very elegant. regards domagoj > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Vijay Devarapalli > Sent: 14. veljaca 2008 17:58 > To: George Tsirtsis > Cc: mext@ietf.org > Subject: Re: [MEXT] [Fwd: I-D > Action:draft-krishnan-mext-ha-redirect-00.txt] > > George Tsirtsis wrote: > > Hi Suresh, > > > > Your proposal seems to be based on the fact that RFC5142 > (HA-switch) > > is not sufficient since it only works for MNs already registered in > > the HA. You argue then that an HA should be able to redirect an MN > > during initial registration (to which I agree). > > So, while this sounds reasonable, when IPSEC is used to secure MIP6 > > signaling, would it not make more sense to get this information > > earlier? e.g., during the IKEv2 exchange? > > > > It is also worth noting that depending what kind of bootstrapping > > mechanism used the MN may already know a number of > alternative HAs, in > > which case a BA with appropriate status (e.g., 130 Insufficient > > resources) would also work. > > > > Again, however, I am not saying that your suggestion is wrong, but > > that it is possibly applied to the wrong protocol. > > > > Thoughts? > > Agree. When RFC 5026 was being standardized, there was > proposal to re-direct the mobile node during the IKEv2 exchange using > IKEv2 anycast addresses. There were some issues found with > the mechanism during the IESG review. It was about the > destination address on the outgoing IKE_SA_INIT (anycast > address) not matching the source address of the IKE_SA_INIT > response (unicast address of the selected HA). Firewalls or > NATs could drop these packets. So it was removed from the > document during the IESG review. > > In some offline discussions, it was decided to move that > mechanism to a separate draft and also introduce an explicit > REDIRECT payload in the IKE_SA_INIT response from an anycast > address. I was supposed to have submitted this document > months ago, but due to various reasons, I haven't yet. I am > planning to submit it by this Monday. > > Vijay > > > George > > > > On Wed, Feb 13, 2008 at 6:37 PM, Suresh Krishnan > > wrote: > >> Hi Folks, > >> We submitted a draft about redirecting MNs to other HAs for > >> overload prevention, load balancing or other purposes. We would > >> appreciate any comments and suggestions on this document. > >> > >> Thanks > >> Authors > >> > >> -------- Original Message -------- > >> Subject: I-D Action:draft-krishnan-mext-ha-redirect-00.txt > >> Date: Wed, 13 Feb 2008 10:30:01 -0800 (PST) > >> From: Internet-Drafts@ietf.org > >> Reply-To: internet-drafts@ietf.org > >> To: i-d-announce@ietf.org > >> > >> A New Internet-Draft is available from the on-line > Internet-Drafts > >> directories. > >> > >> Title : Redirecting Binding Updates in MIPv6 > >> Author(s) : S. Krishnan, et al. > >> Filename : draft-krishnan-mext-ha-redirect-00.txt > >> Pages : 9 > >> Date : 2008-02-13 > >> > >> This document specifies a new Home Agent Redirect > mechanism, where > >> an initially contacted Home Agent can let the Mobile Node > knows that > >> it needs to connect to an alternate Home Agent to get mobility > >> services for overload prevention and/or load balancing purposes. > >> This document proposes a new error code for the binding > >> acknowledgement message and a new mobility option to be > carried on > >> the binding acknowledgement message for this purpose. > >> > >> A URL for this Internet-Draft is: > >> > >> > http://www.ietf.org/internet-drafts/draft-krishnan-mext-ha-redirect-0 > >> 0.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-krishnan-mext-ha-redirect-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-krishnan-mext-ha-redirect-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. > >> > >> > >> > >> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> http://www.ietf.org/mailman/listinfo/mext > >> > >> > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > http://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Feb 19 18:11:06 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9269728C675; Tue, 19 Feb 2008 18:11:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.447 X-Spam-Level: X-Spam-Status: No, score=-0.447 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMgv2W4JIJG9; Tue, 19 Feb 2008 18:11:04 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD2E63A6B4F; Tue, 19 Feb 2008 18:11:04 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97F3E3A68D3 for ; Tue, 19 Feb 2008 18:11:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B39jYMhBUGhm for ; Tue, 19 Feb 2008 18:11:02 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [61.144.161.55]) by core3.amsl.com (Postfix) with ESMTP id BE14A3A6876 for ; Tue, 19 Feb 2008 18:11:02 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JWI005BDM21KY@szxga03-in.huawei.com> for mext@ietf.org; Wed, 20 Feb 2008 10:10:49 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JWI00AU1M219N@szxga03-in.huawei.com> for mext@ietf.org; Wed, 20 Feb 2008 10:10:49 +0800 (CST) Received: from y66262 ([10.164.9.65]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JWI00A68M20K5@szxml03-in.huawei.com> for mext@ietf.org; Wed, 20 Feb 2008 10:10:49 +0800 (CST) Date: Wed, 20 Feb 2008 10:10:48 +0800 From: Robert Yang To: brian.haley@hp.com, vijay.devarapalli@azairenet.com Message-id: <008901c87365$cf6f7b20$4109a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Thread-index: AchzZc8NuFsPNJMPTZOwlXuE+/Cvjg== Cc: mext@ietf.org Subject: [MEXT] One issue about RFC 5142(Mobility Header Home Agent Switch Message) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, Brian, Vijay and all In section 6.1 of RFC 5142 it says that: it (MN) MUST send a Binding Error message with the Status field set to 2 (unrecognized MH Type value) if it does not support the message type. But my Question is that: (1)Binding error message is sent from CN instead of MN as described in rfc3775; (2) HA switch message is a new message for entities such as MN, HA in rfc3775, so MN as well as HA should be updated to support this message; B/R Robert Yang **************************************************************************** *********** This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! **************************************************************************** ************* _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Feb 19 18:36:00 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8602428C0FE; Tue, 19 Feb 2008 18:36:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.753 X-Spam-Level: X-Spam-Status: No, score=-100.753 tagged_above=-999 required=5 tests=[AWL=-0.316, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7Piaoe13fSM; Tue, 19 Feb 2008 18:35:58 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 720763A6BD8; Tue, 19 Feb 2008 18:35:58 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE9B43A6BD4 for ; Tue, 19 Feb 2008 18:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMlB32dOsUPa for ; Tue, 19 Feb 2008 18:35:56 -0800 (PST) Received: from g4t0017.houston.hp.com (g4t0017.houston.hp.com [15.201.24.20]) by core3.amsl.com (Postfix) with ESMTP id 3BD2F3A6BCF for ; Tue, 19 Feb 2008 18:35:56 -0800 (PST) Received: from g4t0017.houston.hp.com (localhost.localdomain [127.0.0.1]) by receive-from-antispam-filter (Postfix) with SMTP id 2A6DF385CA; Wed, 20 Feb 2008 02:35:53 +0000 (UTC) Received: from mailstation.cce.hp.com (mailstation.zcce.gate.cpqcorp.net [16.104.192.124]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by g4t0017.houston.hp.com (Postfix) with ESMTP id 2522038472; Wed, 20 Feb 2008 02:35:53 +0000 (UTC) Received: from [192.168.1.101] (c-24-62-100-177.hsd1.ma.comcast.net [24.62.100.177]) by mailstation.cce.hp.com (Postfix) with ESMTP id 0D834C068; Tue, 19 Feb 2008 20:40:22 -0600 (CST) Message-ID: <47BB9206.4090803@hp.com> Date: Tue, 19 Feb 2008 21:35:50 -0500 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Robert Yang References: <008901c87365$cf6f7b20$4109a40a@china.huawei.com> In-Reply-To: <008901c87365$cf6f7b20$4109a40a@china.huawei.com> Cc: mext@ietf.org Subject: Re: [MEXT] One issue about RFC 5142(Mobility Header Home Agent Switch Message) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Robert, Robert Yang wrote: > Hi, Brian, Vijay and all > In section 6.1 of RFC 5142 it says that: it (MN) MUST send a Binding Error > message with the Status field set to 2 (unrecognized MH Type value) if it > does not support the message type. > But my Question is that: > (1)Binding error message is sent from CN instead of MN as described in > rfc3775; Yes, this is something Hui pointed-out too, and I know that what entities are allowed to send Binding Errors is under revision for 3775-bis, so I'll suggest that text be relaxed further than just allowing CNs and HAs to send it. After all, a MN is going to pretty much implement all of the CN functionality, so it's not a stretch to allow it to send a Binding Error. > (2) HA switch message is a new message for entities such as MN, HA in > rfc3775, so MN as well as HA should be updated to support this message; Yes, updating the Linux implementation is on my to-do list, I can't speak for any other vendors. Thanks for the feedback, -Brian _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Feb 19 22:50:18 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09D1828C41D; Tue, 19 Feb 2008 22:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.045 X-Spam-Level: X-Spam-Status: No, score=0.045 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_26=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTpQoHdd17LK; Tue, 19 Feb 2008 22:50:16 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8A6F3A6D50; Tue, 19 Feb 2008 22:50:16 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B04233A6860 for ; Tue, 19 Feb 2008 22:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgCdStRVD6dH for ; Tue, 19 Feb 2008 22:50:13 -0800 (PST) Received: from rodin.i2r.a-star.edu.sg (rodin.i2r.a-star.edu.sg [192.122.139.27]) by core3.amsl.com (Postfix) with ESMTP id 0D30A3A6D50 for ; Tue, 19 Feb 2008 22:50:12 -0800 (PST) Received: from rodin.i2r.a-star.edu.sg (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id BBB9A13B66D; Tue, 19 Feb 2008 21:24:03 +0800 (SGT) Received: from mailfe01.teak.local.net (unknown [192.122.134.9]) by rodin.i2r.a-star.edu.sg (Postfix) with ESMTP id AD41413B666; Tue, 19 Feb 2008 21:24:03 +0800 (SGT) Received: from precision5570 ([192.168.137.53]) by mailfe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 14:49:19 +0800 Message-ID: <003a01c8738c$d4656690$3589a8c0@precision5570> From: "QIU Ying" To: "RYUJI WAKIKAWA" References: <7C5C82DC-66BA-4C6E-9195-4B773C8D3542@gmail.com> <003201c8721d$0ae7f190$3589a8c0@precision5570> <950BDB72-2EF2-4C61-AA25-40059B1F1D04@gmail.com> Date: Wed, 20 Feb 2008 14:50:07 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 20 Feb 2008 06:49:19.0665 (UTC) FILETIME=[B7D1BA10:01C8738C] Cc: mext@ietf.org Subject: Re: [MEXT] firewall docs review X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, Ryuji On February 19, 2008 11:00 AM, RYUJI WAKIKAWA wrote > Hi, Qiu > > On 2008/02/18, at 19:57, QIU Ying wrote: > >> Hi, Ryuji >> >> Thanks for your comments. My response is inline. >> >> ----- Original Message ----- "RYUJI WAKIKAWA" wrote >> >> >>> Hi Suresh and authors, >>> >>> I was asked to review draft-krishnan-mip6-firewall-admin-02 and >>> draft-krishnan-mip6-firewall-vendor-02. >>> >>> - Can current filtering mechanism check the IP options field?! >> >> No. Current firewall filter does not support to check the IP options >> field. > > It's up to implementation, isn't it? > I can easily setup the firewall with PC which can check the IP options... > Which firewall products are you assuming? > > Are there substantial reasons to say NO here? Do you mean to use the filter of routing header? If I am not wrong, the current ip6tables (e.g. in Linux) only support route header in type 0. But the formats between type 0 and type 2 route header are a bit of difference. It's why we should suggest the modification in vendor-draft instead of the admin-draft. Anyway, if most current firewalls already implement this feature, we should mention it in admin-draft > >> >>> If yes, the document should mention which IP options are appeared >>> for which packets. >>> An example is DST Opt for BU and RTHDR for BA. >>> Otherwise, the operator might just block all the packets having >>> RTHDR option regardless of BA. >>> >>> For example, in section 3.1 of draft-admin , >>> Destination Address: Address of HA >>> <-- adding Dest >>> option (HoA option)? >>> Next Header: 50 (ESP) >>> Mobility Header Type: 5 (BU) >> >> For draft-admin, which purpose is BCP, so we could not solicit the >> function here. But we could provide the filter in draft-vender. >> >>> >>> - missing authentication option and DSMIP support? >>> DSMIP will introduce much complexity to firewall setup. >> >> The target of these two draft is to make MIP6 signalling pass through >> the firewalls. So, in my opinion, the issue of authentication and DSMIP >> might be out of the scope. > > DSMIP seems to be adapted to many deployment case. > why not:-) In my opinion, the dual stack issues are more focused on the process on the two-peers of communication. A firewall, which is located on middle-way, is just take care the IP headers. A traffic packet is either IPv4 packet or IPv6 packet no matter if it includes dual stock information. So I do not think it was necessary to require a firewall to detect the dual stack information. These 2 drafts are about the modification of IPv6 firewall. If IPv4 issues should be considered too, we could raise other drafts Regards Qiu Ying > > ryuji > >>> >>> - RO is optional in the RFC3775. I am not sure you can treat >>> RO signaling as same as the BU/BA for firewall filters setup. >>> It might be good if you provide the minimum set of rules (BU/BA >>> only) >>> and the full set of rules (All MH signaling). >> >> Good comments. >> >> Regards and Thanks >> Qiu Ying >> >> >>> >>> - why are these two separate documents? >>> >>> regards, >>> ryuji >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> http://www.ietf.org/mailman/listinfo/mext ------------ Institute For Infocomm Research - Disclaimer -------------This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you.-------------------------------------------------------- _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Feb 20 00:07:30 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52C023A691F; Wed, 20 Feb 2008 00:07:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.538 X-Spam-Level: X-Spam-Status: No, score=-0.538 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DO6mVLLiTyzA; Wed, 20 Feb 2008 00:07:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BFFF3A6930; Wed, 20 Feb 2008 00:07:28 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 998FE3A6930 for ; Wed, 20 Feb 2008 00:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPXIeT6qpTKk for ; Wed, 20 Feb 2008 00:07:22 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [61.144.161.7]) by core3.amsl.com (Postfix) with ESMTP id 1656D3A691F for ; Wed, 20 Feb 2008 00:07:22 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JWJ00JCM2K1G1@szxga04-in.huawei.com> for mext@ietf.org; Wed, 20 Feb 2008 16:07:13 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JWJ00CAW2K1AB@szxga04-in.huawei.com> for mext@ietf.org; Wed, 20 Feb 2008 16:07:13 +0800 (CST) Received: from y66262 ([10.164.9.65]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JWJ00ELR2K04Y@szxml03-in.huawei.com> for mext@ietf.org; Wed, 20 Feb 2008 16:07:13 +0800 (CST) Date: Wed, 20 Feb 2008 16:07:12 +0800 From: Robert Yang In-reply-to: <47BB9206.4090803@hp.com> To: 'Brian Haley' Message-id: <002d01c87397$994793c0$4109a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Thread-index: AchzaVOEBXeiTPH6Qb6knc2fmyxNCgAI7tiw Cc: mext@ietf.org Subject: Re: [MEXT] One issue about RFC 5142(Mobility Header Home Agent Switch Message) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, Brian, thanks for your reply, please see in line! > > Hi Robert, > > Robert Yang wrote: > > Hi, Brian, Vijay and all > > In section 6.1 of RFC 5142 it says that: it (MN) MUST send a Binding Error > > message with the Status field set to 2 (unrecognized MH Type value) if it > > does not support the message type. > > But my Question is that: > > (1)Binding error message is sent from CN instead of MN as described in > > rfc3775; > > Yes, this is something Hui pointed-out too, and I know that what > entities are allowed to send Binding Errors is under revision for > 3775-bis, so I'll suggest that text be relaxed further than just > allowing CNs and HAs to send it. After all, a MN is going to pretty > much implement all of the CN functionality, so it's not a stretch to > allow it to send a Binding Error. > OK > > (2) HA switch message is a new message for entities such as MN, HA in > > rfc3775, so MN as well as HA should be updated to support this message; > > Yes, updating the Linux implementation is on my to-do list, I can't > speak for any other vendors. > Sorry if mislead you. What I want to say is that, since not all the MN can support HA switching message, IMHO maybe it is desirable to help HA to distinguish them. B/R Robert Yang > Thanks for the feedback, > > -Brian _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Feb 20 02:29:57 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B3DC3A6E16; Wed, 20 Feb 2008 02:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.353 X-Spam-Level: *** X-Spam-Status: No, score=3.353 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivQJ9VONilL7; Wed, 20 Feb 2008 02:29:56 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 900F13A6E35; Wed, 20 Feb 2008 02:29:56 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC30A3A6E16 for ; Wed, 20 Feb 2008 02:29:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6WLFoDFGnaN for ; Wed, 20 Feb 2008 02:29:54 -0800 (PST) Received: from csnet1.cs.tsinghua.edu.cn (csnet1.cs.tsinghua.edu.cn [166.111.68.226]) by core3.amsl.com (Postfix) with SMTP id B47713A6ADD for ; Wed, 20 Feb 2008 02:29:53 -0800 (PST) Received: (qmail 28469 invoked by uid 0); 20 Feb 2008 10:44:19 -0000 Received: from unknown (HELO loopy-c8eebeddf) (qiminpeng@162.105.210.182) by csnet1.cs.tsinghua.edu.cn with SMTP; 20 Feb 2008 10:44:19 -0000 Date: Wed, 20 Feb 2008 18:29:49 +0800 From: "=?GB2312?B?xuuVRsX0?=" To: "mext" X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Message-Id: <20080220102953.B47713A6ADD@core3.amsl.com> Subject: Re: [MEXT] [Recharter.2] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi All, I would like to support: [CR] Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions Regards Minpeng Qi qiminpeng@csnet1.cs.tsinghua.edu.cn 2008-02-20 _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Feb 20 03:21:28 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2A4B28C764; Wed, 20 Feb 2008 03:21:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.175 X-Spam-Level: X-Spam-Status: No, score=-100.175 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MetH1-OAmjza; Wed, 20 Feb 2008 03:21:27 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE8CD28C158; Wed, 20 Feb 2008 03:21:27 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEFD428C130 for ; Wed, 20 Feb 2008 03:21:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4p65RJn48Ht for ; Wed, 20 Feb 2008 03:21:25 -0800 (PST) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.232]) by core3.amsl.com (Postfix) with ESMTP id 5F48F28C158 for ; Wed, 20 Feb 2008 03:21:25 -0800 (PST) Received: by wx-out-0506.google.com with SMTP id s8so2303202wxc.31 for ; Wed, 20 Feb 2008 03:21:22 -0800 (PST) Received: by 10.114.169.2 with SMTP id r2mr4188559wae.76.1203506481084; Wed, 20 Feb 2008 03:21:21 -0800 (PST) Received: by 10.115.74.17 with HTTP; Wed, 20 Feb 2008 03:21:21 -0800 (PST) Message-ID: <7db42a3e0802200321g1f3be5b0v6b31b2766c351fcb@mail.gmail.com> Date: Wed, 20 Feb 2008 19:21:21 +0800 From: "Dr. Daniel Wong" To: mext@ietf.org MIME-Version: 1.0 Content-Disposition: inline X-Google-Sender-Auth: b6b55b88f2c387b0 Subject: [MEXT] draft-wong-mext-simultaneous-ps-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org dear all, We have submitted an IETF draft on simultaneous mobility, by Wong, Dutta and Schulzrinne. We believe this is a problem faced by Mobile IPv6 as well as some other mobility protocols, and would appreciate comments on it, both in the mailing list and also in IETF 71 in Philadelphia. The URL is http://www.ietf.org/internet-drafts/draft-wong-mext-simultaneous-ps-00.txt thanks! -- Dr. Daniel Wong Assistant Professor Malaysia University of Science and Technology ** check out my book on wireless IP at http://www.must.edu.my/~dwong/book.html ** _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Feb 20 03:36:39 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11E5928C570; Wed, 20 Feb 2008 03:36:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=-1.920, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1791asq5MoR; Wed, 20 Feb 2008 03:36:38 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA7123A6947; Wed, 20 Feb 2008 03:36:37 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B57BC3A67DF for ; Wed, 20 Feb 2008 03:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gN5j6cPWXlOc for ; Wed, 20 Feb 2008 03:36:36 -0800 (PST) Received: from ws000774.tietoenator.com (ws000774.tietoenator.com [193.12.181.129]) by core3.amsl.com (Postfix) with ESMTP id 9E0DD3A69D8 for ; Wed, 20 Feb 2008 03:36:35 -0800 (PST) X-AuditID: c10cb581-000011cc00000680-4b-47bc10b846d7 Received: from stingray.eu.tieto.com ([192.176.143.13]) by ws000774.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 12:36:24 +0100 Received: from corvette.eu.tieto.com ([192.176.143.143]) by stingray.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 12:36:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 20 Feb 2008 12:36:29 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] DSMIPv6 Security considerations section 5.1 Thread-Index: AchjOp+tBBZPPj39Q6+7x6ZGZVfkIgPvM+kgAC5nnHA= References: From: To: , , , X-OriginalArrivalTime: 20 Feb 2008 11:36:30.0557 (UTC) FILETIME=[D63B30D0:01C873B4] X-Brightmail-Tracker: AAAAAA== Subject: Re: [MEXT] DSMIPv6 Security considerations section 5.1 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Just a small comment below. > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Hesham Soliman > Sent: 19. februar 2008 14:14 > To: 'Julien Laganier'; Pasi.Eronen@nokia.com; mext@ietf.org > Subject: [MEXT] DSMIPv6 Security considerations section 5.1 > > In order to allow the DSMIPv6 implementation in the home > agent to detect the > presence of a NAT on the path to the mobile node, it needs > to compare the > outer IPv4 source address with the IPv4 address in the > alt-care-of address > option. This implies that the information in the outer header will be --> "will be" to be replaced with "will have to be" > preserved after IPsec processing and made available to the DSMIPv6 > implementation in the home agent. Depending on the home agent's > implementation, meeting this requirement may require changes > to the IPsec > implementation. Christian _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Feb 20 04:12:50 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AA3828C7CC; Wed, 20 Feb 2008 04:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Am7LKMkWKMwp; Wed, 20 Feb 2008 04:12:49 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72B1328C7DB; Wed, 20 Feb 2008 04:12:49 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE96828C6AF for ; Wed, 20 Feb 2008 04:12:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hd6ePlANpuvJ for ; Wed, 20 Feb 2008 04:12:45 -0800 (PST) Received: from bart.inescn.pt (bart.inescn.pt [192.35.246.9]) by core3.amsl.com (Postfix) with ESMTP id E840428C7FE for ; Wed, 20 Feb 2008 04:12:42 -0800 (PST) Received: from localhost (bart.inescn.pt [127.0.0.1]) by bart.inescn.pt (8.13.8/8.13.8/5) with ESMTP id m1KCCZmP024731; Wed, 20 Feb 2008 12:12:35 GMT X-Virus-Scanned: amavisd-new at inescporto.pt Received: from bart.inescn.pt ([127.0.0.1]) by localhost (bart.inescn.pt [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Jvk3KdYPeUb4; Wed, 20 Feb 2008 12:12:14 +0000 (WET) Received: from [194.117.26.86] (icelollix.inescn.pt [194.117.26.86]) by bart.inescn.pt (8.13.8/8.13.8/39) with ESMTP id m1KCCBSv024717; Wed, 20 Feb 2008 12:12:11 GMT Message-ID: <47BC191A.4070000@inescporto.pt> Date: Wed, 20 Feb 2008 12:12:10 +0000 From: Rute Sofia User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: "Dr. Daniel Wong" References: <7db42a3e0802200321g1f3be5b0v6b31b2766c351fcb@mail.gmail.com> In-Reply-To: <7db42a3e0802200321g1f3be5b0v6b31b2766c351fcb@mail.gmail.com> Cc: mext@ietf.org Subject: Re: [MEXT] draft-wong-mext-simultaneous-ps-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Daniel, some comments to the draft after a quick look and mostly related to MIP . - Intro, it would be better to state up front that you the problem you mention only applies to active sessions between a MN and a *mobile* CN, particularly if there is any form of direct binding registration between them. You mention two devices on the move but only later state that they are actually the parties in an active session. - terminology, * define what you mean with "border router"; "backbone router"; "edge router", given that later you have a scenario using this terminology but never defined it. 4.1 Typo in "Since both home agents are stationary and can always be reached through IP routing simultaneous mobility does present a problem to MIPv4."; I believe you mean DOES NOT Concerning MIPv6. Even though the problem is real and may start to happen more frequently with the increase of mobile devices and more complex mobility patterns, there are some things that are not clear with the description you provide: - while on the move and based upon scenario 3, you state that the BU information sent by MN1 to MN2 (CN) does not reach the latter. You need to be more explicit. There are two possible cases: a) MN1 performs the "correspondent registration" and immediately moves to a new attachment point; b) MN1 performed a L2 handover (is already attached to the new location) and starts the BU exchange with HA *and* CNs. We have the same process for the second MN (CN) a) could be more problematic than b) given that MN1 sends a BU that never reaches the CN. However, what you never explain in detail is the ack that is sent by the CN. For b), it must be mentioned that the CoAs have different states, according to RFC4866 (section 3.5, concurrent CoAs tests; verified/unverified addresses). Specifically for the case of MIPv6, there are some details that need to be worked upon to really understand the implications of having two participating nodes in a session simultaneously moving... BR, Rute Dr. Daniel Wong wrote: > dear all, > > We have submitted an IETF draft on simultaneous mobility, by Wong, > Dutta and Schulzrinne. We believe this is a problem faced by Mobile > IPv6 as well as some other mobility protocols, and would appreciate > comments on it, both in the mailing list and also in IETF 71 in > Philadelphia. The URL is > http://www.ietf.org/internet-drafts/draft-wong-mext-simultaneous-ps-00.txt > > thanks! > -- Rute Sofia, PhD (rsofia@inescporto.pt, +351 22 2094263) http://www.inescporto.pt/utm/~ian/ Area Leader/Responsa'vel de A'rea IAN: Internet Architectures and Networking UTM: Telecommunications and Networking Unit INESC Porto _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Feb 20 06:16:27 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0972528C189; Wed, 20 Feb 2008 06:16:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.133 X-Spam-Level: X-Spam-Status: No, score=-1.133 tagged_above=-999 required=5 tests=[AWL=-0.696, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8n0Sn2oieb-M; Wed, 20 Feb 2008 06:16:25 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B43B3A6E46; Wed, 20 Feb 2008 06:16:25 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7EFD3A6E4E for ; Wed, 20 Feb 2008 06:16:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBTIG-scxW5P for ; Wed, 20 Feb 2008 06:16:22 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 5097E3A6E38 for ; Wed, 20 Feb 2008 06:16:21 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1KEFiKB030061; Wed, 20 Feb 2008 16:16:08 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 16:14:25 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 16:14:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 20 Feb 2008 16:14:22 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DSMIPv6 Security considerations section 5.1 Thread-Index: AchjOp+tBBZPPj39Q6+7x6ZGZVfkIgPvM+kgADG59NA= References: From: To: , X-OriginalArrivalTime: 20 Feb 2008 14:14:24.0631 (UTC) FILETIME=[E5382870:01C873CA] X-Nokia-AV: Clean Cc: julien.IETF@laposte.net Subject: Re: [MEXT] DSMIPv6 Security considerations section 5.1 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Hesham, Thanks for the updated text; this is getting much better. I'd also like to see some clarifications elsewhere in the document about the five (not three, as some text claimed) different encapsulations that are possible when in IPv4-only network, and how/when they get used (in particular, how the encapsulation type negotiation in BU/BAck interacts, or does not interact, with IPsec SPD). See comments inline: > -----Original Message----- > From: ext Hesham Soliman [mailto:Hesham@elevatemobile.com] > Sent: 19 February, 2008 15:14 > To: 'Julien Laganier'; Eronen Pasi (Nokia-NRC/Helsinki); mext@ietf.org > Subject: DSMIPv6 Security considerations section 5.1 > > Hi all, > > Sorry this took a long time but viruses (human ones) don't > consider IETF deadlines! Here is a new take on section 5.1. There > is a couple of Pasi's comments the I didn't include and have some > clarifying questions on them below. Please keep reading after the > text. > > Section 5.1: > ============= > > After the mobile node detects movement it configures a new > care-of address. If the mobile node is in an IPv4-only network, > it removes binding update list entries for correspondent nodes > since route optimisation cannot be supported. This may cause > inbound packet losses as remote correspondent node are unaware of > such movement. To avoid confusion in the correspondent node, the > mobile node SHOULD deregister its binding with each correspondent > node by sending a deregistration binding update. The > deregistration binding update message is tunnelled to the home > agent and onto the correspondent node. Starting the next paragraph with "following this" suggests that deregistrations are done before sending BU. If the old care-of address (and existing tunnel) are no longer working, this obviously isn't possible (and deregistrations are sent only after tunnel has been updated). > Following this, the mobile node sends the binding update message > to the home agent. If the mobile node is in an IPv6- enabled > network, the binding update is sent without IPv4/UDP > encapsulation. If the mobile node is in an IPv4-only network, it > encapsulates the BU in UDP/IPv4 as discussed in sections 4.2 and > 4.4. Maybe "If the mobile node is an IPv4-only network, after IPsec processing the BU is encapsulated in UDP/IPv4 as discussed in sections 4.2 and 4.4."? > In order to be able to send the binding update while in an > IPv4-only network, the mobile node needs to use the new IPv4 > care-of address in the outer header, which is different from the > care-of address used in the existing tunnel. This should be done > without permanently updating the tunnel within the mobile node's > implementation in order to allow the mobile node to receive > packets on the old care-of address until the binding > acknowledgement is received. The method used to achieve this > effect is implementation dependent and is outside the scope of > this specification. Ok so far, but I'd suggest adding text along these lines: "This implies that the IP forwarding function (which selects the interface or tunnel through which a packet is sent) is not based solely on the destination address: some IPv6 packets destined to the home agent are sent via the existing tunnel, while BUs are sent using the new care-of address. Since BUs are protected by IPsec, the forwarding function cannot necessarily determine the correct treatment from the packet headers. Thus, the DSMIPv6 implementation has to attach additional information to BUs, and this information has to be preserved after IPsec processing and made available to the forwarding function. Depending on the mobile node's implementation, meeting this requirement may require changes to the IPsec implementation." Next, I'd suggest some reordering of the text to improve readability and correctness (I'm reordering the quoted text here): "Upon receiving a BU encapsulated in UDP/IPv4, the home agent processes it as follows:" > In order to allow the DSMIPv6 implementation in the home agent to > detect the presence of a NAT on the path to the mobile node, it > needs to compare the outer IPv4 source address with the IPv4 > address in the alt-care-of address option. This implies that the > information in the outer header will be preserved after IPsec > processing and made available to the DSMIPv6 implementation in > the home agent. Depending on the home agent's implementation, > meeting this requirement may require changes to the IPsec > implementation. Ok. > Upon receiving the binding update message, the home agent updates > its security association to include the mobile node's address as > the tunnel header IP source address and the new port number. > When the mobile node is located in a private IPv4 network (which > is detected as described above), the new address and port number > are allocated by the NAT. Several nits: Updating the port number here is not correct (it will be wrong even when no NAT is present). It's not the "tunnel header IP *source* address" on the HA. There can be more than one SA. Also, explicitly saying "tunnel mode" would clarify. Suggested rephrasing: "Upon receiving the binding update message, the home agent updates its tunnel mode security association to include the mobile node's care-of address as the remote tunnel header address, and 4500 as the port number." > If the mobile node were located in a private IPv4 network the > address and port number are likely to be wrong as the NAT would > likely allocate a different address and port number to traffic > encapsulated in IPsec tunnels or to IKE messages. add "; the mobile node provides the correct values in a separate exchange, as descibed below." > The home agent will also enable or disable UDP encapsulation for > outgoing ESP packets for the purpose of NAT traversal. Ok. > Based on the setting of the K flag in the binding update, the > home agent updates its IKE security association to include the > tunnel header IP address as that received in the outer header of > the binding update message. Hmm -- I guess this means that DSMIPv6 requires the HA to support the K flag? (i.e. always set it in BAcks if it was set in BU?) Is this requirement mentioned somewhere else in the spec? Also, port number needs to be reset for non-NAT case. "If the Key Management Mobility Capability (K) bit was set in the binding update, the home agent updates its IKE security associations to include the mobile node's care-of address as the peer address and 4500 as the port number." > The home agent may also need to change NAT traversal fields in > the IKE_SA to enable the dyanmic update of the IP address and > port number based on the reception of authenticated IKE messages, > or authenticated packets using tunnel mode ESP. The dynamic > updates are described in section 2.23 of RFC 4306. Ok. Add: "As described above, when the mobile node is located in a private IPv4 network, the address and port number used for IPsec and IKE traffic is not yet known by the home agent at this point." > Hence, the > mobile node updates the IKE SA in one of two ways. If the K flag > was set, "in the BAck"? (or is the HA required to support this?) > the mobile node SHOULD send an empty informational > message, which results in the IKE module in the home agent to > dynamically update the SA information. The IKE implementation in > the home agent is REQUIRED to support this > feature. Alternatively, the IKE SA should be re-negotiated. Note > that updating the IKE SA MUST take place after the mobile node > has sent the binding update and received the acknowledgement from > the home agent. Seems OK. > It is important to note that if the mobile node is located behind > a NAT, its IPv4 care-of address seen by the DSMIPv6 module in the > home agent upon receiving the binding update will differ from the > IPv4 care-of address seen by the IKE module and the care-of > address used for forwarding IPsec tunnel mode traffic. This is > due to the fact that the NAT will probably allocate a different > IP address and port number to each traffic stream. Hence, it is > probable that different modules in the home agent will have a > different care-of address that should be used for encapsulating > traffic to the mobile node. Suggest moving some of this text to separate subsection, which should also discuss the complications caused by dynamic updates. > After successfully processing the binding update, the home agent > sends the binding acknowledgement to the mobile node's care-of > address as received in the outer header of the packet containing > the binding update. Add "Note that if the BU was rejected, the BAck is sent to the same address where the BU was received from. This may require special treatment in IP forwarding and/or IPsec processing which resembles sending of BUs in the mobile node (described above)." > Upon receiving the binding acknowledgement the mobile node > updates its local Security Association information to include the "local tunnel mode Security Associations" > tunnel header IP source address, which is the the home agent's > address. It probably needs to update both source and destination. On MN, source is the care-of address; destination is the HA. > The mobile node may also need to enable or disable UDP > encapsulation for outgoing ESP packets for the purpose of NAT > traversal. ", and sending of keep-alives" > The mobile node MAY use [MOBIKE] to update its IKE SA with the > home agent. Using MOBIKE requires negotiating this capability > with the home agent when establishing the SA. In this case, the > mobile node and the home agent need not update their IPsec SAs > locally as this step is performed by MOBIKE. Furthermore, the > use of MOBIKE allows the mobile node to update the SA > independently of the binding update exchange. Hence, there is no > need for the mobile node to wait for a binding acknowledgement > before performing MOBIKE. The use of MOBIKE is OPTIONAL in this > specification. Hmm, "need not update" is probably not totally correct; should it be "MUST NOT" or something? (I'm not totally sure, but if it's both, it's probably not totally right) > > 3) The spec has to say something about using port 500 vs. port > > 4500 for IPsec traffic, since the text in RFC 4306 Section > > 2.23 won't work as is (MOBIKE had to deal with this issue as > > well, see RFC 4555 Section 3.3). > > > > 4) Text has to mention that MN needs to enable/disable sending > > IPsec keep-alives (for port 4500) depending on whether it's > > behind a NAT or not. > > => I assume point 4) above is somewhat related to what we say > about point 3). I read section 3.3 of RFC 4555 but I'm still > unsure about what to say here. Are you recommending that we > follow the same route as Mobike and use port 4500 if the MN and > HA support it? > > In this case, I guess there is something to say about point 4) > because 4500 is used even if there is no NAT. Otherwise, if we > only use 4500 if a NAT is detected then it's obvious that we have > to always send kepp alives on port 4500. Am I missing something? > If you have suggested text for point 3) that would be great. Using port 4500 always (as MOBIKE does) would IMHO be simpler than switching back and forth between ports 500 and 4500. (BTW, if you have a temporary draft-of-draft version available somewhere, I could take a quick look before the submission.) Best regards, Pasi _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Feb 20 07:00:02 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D57528C807; Wed, 20 Feb 2008 07:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.228 X-Spam-Level: X-Spam-Status: No, score=-1.228 tagged_above=-999 required=5 tests=[AWL=-0.790, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FiUdaVqpGj+s; Wed, 20 Feb 2008 07:00:01 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62B9828C7B9; Wed, 20 Feb 2008 07:00:01 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4918328C213 for ; Wed, 20 Feb 2008 07:00:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIQMxNXhFM31 for ; Wed, 20 Feb 2008 06:59:59 -0800 (PST) Received: from cluster-b.mailcontrol.com (cluster-b.mailcontrol.com [217.68.146.190]) by core3.amsl.com (Postfix) with ESMTP id 9F58B28C18C for ; Wed, 20 Feb 2008 06:59:58 -0800 (PST) Received: from rly28b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly28b.srv.mailcontrol.com (MailControl) with ESMTP id m1KExb1H032762 for ; Wed, 20 Feb 2008 14:59:39 GMT Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly28b.srv.mailcontrol.com (MailControl) id m1KEvvfM029488 for mext@ietf.org; Wed, 20 Feb 2008 14:57:57 GMT Received: from eundsmtpout02.pan.eu ([168.87.60.204]) by rly28b-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id m1KEvjOr028241; Wed, 20 Feb 2008 14:57:54 +0000 (GMT) Received: from eundadmi02.pan.eu ([10.109.33.23]) by eundsmtpout02.pan.eu (Lotus Domino Release 7.0.2) with ESMTP id 2008022015574551-322591 ; Wed, 20 Feb 2008 15:57:45 +0100 Received: from VPN-MRelay-02.PRDCG.Panasonic.de ([10.100.176.57]) by eundadmi02.pan.eu (Lotus Domino Release 7.0.3) with ESMTP id 2008022015574324-405097 ; Wed, 20 Feb 2008 15:57:43 +0100 Received: from localhost ([127.0.0.1]) by VPN-MRelay-02.PRDCG.Panasonic.de; Wed, 20 Feb 2008 15:59:57 +0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <7db42a3e0802200321g1f3be5b0v6b31b2766c351fcb@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] draft-wong-mext-simultaneous-ps-00 Thread-Index: Achzst+cDNv//ktRQYeyasa66WxpQgACKEMA References: <7db42a3e0802200321g1f3be5b0v6b31b2766c351fcb@mail.gmail.com> To: "Dr. Daniel Wong" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB7655D9@lan-ex-02.panasonic.de> Date: Wed, 20 Feb 2008 15:57:26 +0100 From: "Kilian Weniger" X-MIMETrack: Itemize by SMTP Server on EUNDADMI02/EUR/Matsushita(Release 7.0.3|September 26, 2007) at 20.02.2008 15:57:43, Serialize by Router on EUNDADMI02/EUR/Matsushita(Release 7.0.3|September 26, 2007) at 20.02.2008 15:57:45, Serialize complete at 20.02.2008 15:57:45, Itemize by SMTP Server on EUNDSMTPOUT02/EUR/PANEXTOUT(Release 7.0.2|September 26, 2006) at 02/20/2008 03:57:45 PM, Serialize by Router on EUNDSMTPOUT02/EUR/PANEXTOUT(Release 7.0.2|September 26, 2006) at 02/20/2008 03:57:54 PM, Serialize complete at 02/20/2008 03:57:54 PM Content-class: urn:content-classes:message X-Scanned-By: MailControl A-08-00-01 (www.mailcontrol.com) on 10.66.1.138 Cc: mext@ietf.org Subject: Re: [MEXT] draft-wong-mext-simultaneous-ps-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Daniel, according to section 6.1 of RFC3775, Mobile IPv6 nodes always send mobility header messages (e.g., Binding Update, HoTi, and CoTi messages) without applying Binding Cache/Binding Update List check. Based on this I suppose BU/HoTi/CoTi messages are sent to the correspondent node's *home address* and not to the corresponent node's care-of address. This implies that mobility header messages are always routed over correspondent node's home agent and that the condition for simultaneous mobility problem as described in the draft ("Binding updates are sent directly to the most current known address (known by the sender) of the intended recipient Mobile Host.") should not be fulfilled. Even though one or two Binding Updates may get lost during a simultaneous mobility event, the mobile nodes should always be able to recover from this due to the routing of retransmitted mobility header messages over the home agents. The relevant text in section 6.1 of RFC3775 is: "Mobility Header messages MUST NOT be sent with a type 2 routing header, except as described in Section 9.5.4 for Binding Acknowledgement. Mobility Header messages also MUST NOT be used with a Home Address destination option, except as described in Section 11.7.1 and Section 11.7.2 for Binding Update. Binding Update List or Binding Cache information (when present) for the destination MUST NOT be used in sending Mobility Header messages. That is, Mobility Header messages bypass both the Binding Cache check described in Section 9.3.2 and the Binding Update List check described in Section 11.3.1 which are normally performed for all packets. This applies even to messages sent to or from a correspondent node which is itself a mobile node. " BR, Kilian > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Dr. Daniel Wong > Sent: Mittwoch, 20. Februar 2008 12:21 > To: mext@ietf.org > Subject: [MEXT] draft-wong-mext-simultaneous-ps-00 > > dear all, > > We have submitted an IETF draft on simultaneous mobility, by Wong, > Dutta and Schulzrinne. We believe this is a problem faced by Mobile > IPv6 as well as some other mobility protocols, and would appreciate > comments on it, both in the mailing list and also in IETF 71 in > Philadelphia. The URL is > http://www.ietf.org/internet-drafts/draft-wong-mext-simultaneo > us-ps-00.txt > > thanks! > > -- > Dr. Daniel Wong > Assistant Professor > Malaysia University of Science and Technology > ** check out my book on wireless IP at > http://www.must.edu.my/~dwong/book.html ** > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext > > Panasonic R&D Center Germany GmbH 63225 Langen, Hessen, Germany Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas Micke _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Feb 20 08:57:17 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EDCB28C669; Wed, 20 Feb 2008 08:57:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.718 X-Spam-Level: X-Spam-Status: No, score=-0.718 tagged_above=-999 required=5 tests=[AWL=-0.631, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWJusQtVoFy1; Wed, 20 Feb 2008 08:57:16 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B84628C1ED; Wed, 20 Feb 2008 08:57:16 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC9B328C286 for ; Wed, 20 Feb 2008 08:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEoqYga42kPm for ; Wed, 20 Feb 2008 08:57:13 -0800 (PST) Received: from givry.fdupont.fr (unknown [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by core3.amsl.com (Postfix) with ESMTP id 119D128C227 for ; Wed, 20 Feb 2008 08:57:02 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m1KGuvo3012318; Wed, 20 Feb 2008 17:56:57 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200802201656.m1KGuvo3012318@givry.fdupont.fr> From: Francis Dupont To: Jari Arkko In-reply-to: Your message of Mon, 18 Feb 2008 12:13:26 PST. <47B9E6E6.3020901@piuha.net> Date: Wed, 20 Feb 2008 17:56:57 +0100 Cc: mext@ietf.org Subject: Re: [MEXT] draft-arkko-mext-rfc3775-altcoa-check-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org In your previous mail you wrote: I have posted a draft that suggests a modification of the rules regarding Alternate Care-of Address checking. The rationale for the change is in the draft -- it is something that came up during the interim; there are closed networks that apply Mobile IPv6 and ingress filtering, and it would be useful in those networks to be able to be strict about what addresses the option can contain. The big question is if something today relies on the option value being able to differ from the source IP address. The draft talks about this as well and preliminarily I do not see a problem. But I would appreciate discussion on this. => there is a known case: in the return to home it is useful to have different source and care-of addresses. For instance the source address can be a link-local address when the care-of address is by definition the home address. So I propose to relax your new requirement by: 1- accepting the source address or the home address as a valid care-of address; 2- make the check policy-based with the check "on" for the default policy ("on" ::= perform the check and reject the BU when it fails). Thanks Francis.Dupont@fdupont.fr PS: 1- is already in the IPsec between MN and CN I-D (as it removes the return routability check it must not open the door to fake care-of attacks. The rrcookie I-D provides a router routability check at the CN initiative so it allows a less drastic policy (i.e., perform the check and when it fails use the rrcookie to valid the new care-of). _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Feb 20 09:25:43 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1F9028C85B; Wed, 20 Feb 2008 09:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.453 X-Spam-Level: X-Spam-Status: No, score=-0.453 tagged_above=-999 required=5 tests=[AWL=-0.366, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHhVu-ZdJ0pX; Wed, 20 Feb 2008 09:25:42 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6EBF28C53E; Wed, 20 Feb 2008 09:25:42 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB23928C5E9 for ; Wed, 20 Feb 2008 09:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDu9mU-oB1+g for ; Wed, 20 Feb 2008 09:25:41 -0800 (PST) Received: from givry.fdupont.fr (unknown [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by core3.amsl.com (Postfix) with ESMTP id E72A128C1FF for ; Wed, 20 Feb 2008 09:25:40 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m1KHPanr012657; Wed, 20 Feb 2008 18:25:36 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200802201725.m1KHPanr012657@givry.fdupont.fr> From: Francis Dupont To: marcelo bagnulo braun In-reply-to: Your message of Tue, 19 Feb 2008 10:50:23 +0100. <33E73C11-496C-4BCD-B9AF-00761DE0B8E5@it.uc3m.es> Date: Wed, 20 Feb 2008 18:25:36 +0100 Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Call for agenda items X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org In your previous mail you wrote: As you know, we are meeting in Philadelphia, so if you want to present something, please let us know, so we can prepare the agenda for the meeting. => I believe you should discuss about new Jari's proposal to disallow the "alternate" term in the alternate care-of address sub-option. Thanks Francis.Dupont@fdupont.fr _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Feb 20 09:56:29 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDABF28C848; Wed, 20 Feb 2008 09:56:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.518 X-Spam-Level: X-Spam-Status: No, score=-4.518 tagged_above=-999 required=5 tests=[AWL=-2.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxqmcO+0Qx38; Wed, 20 Feb 2008 09:56:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C048328C98B; Wed, 20 Feb 2008 09:56:01 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E7EE28C96F for ; Wed, 20 Feb 2008 09:56:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oARrFe8jShlO for ; Wed, 20 Feb 2008 09:55:58 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id A1F1328C99F for ; Wed, 20 Feb 2008 09:55:27 -0800 (PST) Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 20 Feb 2008 18:55:24 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1KHtOnc026433; Wed, 20 Feb 2008 18:55:24 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1KHtMp6001875; Wed, 20 Feb 2008 17:55:22 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 18:55:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 20 Feb 2008 18:54:58 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC053707B3@xmb-ams-337.emea.cisco.com> In-Reply-To: <018801c871e0$ec597dc0$7571510a@psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [Recharter.2] thread-index: AchtjL333P0KYouCQJ+w+EHv/8YzZwEVAfKAAIGXtgA= From: "Pascal Thubert (pthubert)" To: "Julien Laganier" X-OriginalArrivalTime: 20 Feb 2008 17:55:23.0690 (UTC) FILETIME=[C43C00A0:01C873E9] Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] [Recharter.2] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien: Here's my list: C IP Tunneling Optimization in a Mobile Environment R Generic Notification Message for Mobile IPv6 R GRE requirements for IPv6 mobility R Virtual Home Link configuration for Mobile IPv6 R Extend DSMIPv6 Home Network Support Pascal > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf >> Of Julien Laganier >> Sent: Tuesday, February 12, 2008 11:32 PM >> To: mext@ietf.org >> Subject: [MEXT] [Recharter.2] >> >> Folks, >> >> This is the next step in the recharter process. We'd like to >get input >> from WG participants on what should be the items included in >> rechartering, what are their priorities, and who is willing >to sustain >> the effort. When that step is completed we will take the WG >input and >> discuss with our AD to move forward with deciding what to include or >> not in the charter. >> Your input should be sent to the list during the following >two weeks, >> by 2008-02-26. >> >> Please pick from the list of items below the items you think the WG >> should work on, and order them in decreasing priority (just to make >> sure, first priority items goes first in the list you're making :). >> >> List of items: >> >> Binding Revocation for IP Mobility >> MIPv6 home link operation in various SDOs IP Tunneling >Optimization in >> a Mobile Environment Generic Notification Message for Mobile >IPv6 GRE >> requirements for IPv6 mobility 4283bis to extend MN identifier to >> other identifiers Mobile >> IPv6 Bootstrapping for the Authentication Option Protocol >Interaction >> between Mobile IPv6 and IPsec/IKE by PF_KEY extensions Virtual Home >> Link configuration for Mobile IPv6 Extend DSMIPv6 Home >Network Support >> >> Also, please prefix each of the items in your list with the >letters E, >> C and/or R if you're willing to: >> >> - [E]dit: Are you willing to edit the draft corresponding to the >> item. >> >> - [C]ontribute: Are you willing to propose text for the draft. >> >> - [R]eview: Are you willing to review new revisions of the draft when >> being asked by the chairs. >> >> As an example, that could be one input list: >> >> E MIPv6 home link operation in various SDOs CR Binding >Revocation for >> IP Mobility R IP Tunneling Optimization in a Mobile Environment >> >> meaning that the MIPv6 home link is first priority and you volunteer >> to edit, Binding revocation is second priority and you're willing to >> contribute and review, while IP tunneling optimization is third >> priority and you're willing to review. >> >> Hope this is understandable :) >> >> Thanks. >> >> -- julien and marcello, MEXT chairs >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> http://www.ietf.org/mailman/listinfo/mext >> > > >_______________________________________________ >MEXT mailing list >MEXT@ietf.org >http://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Feb 20 10:18:54 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC4CC28C8FE; Wed, 20 Feb 2008 10:18:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.832 X-Spam-Level: X-Spam-Status: No, score=-1.832 tagged_above=-999 required=5 tests=[AWL=0.605, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40PoIujOFUeE; Wed, 20 Feb 2008 10:18:54 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EC1E3A6E71; Wed, 20 Feb 2008 10:18:46 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60DF33A6A3C for ; Wed, 20 Feb 2008 10:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WVLQYl2NyIQ for ; Wed, 20 Feb 2008 10:18:44 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by core3.amsl.com (Postfix) with ESMTP id 1DF293A6E84 for ; Wed, 20 Feb 2008 10:18:36 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id 16so1994810fgg.41 for ; Wed, 20 Feb 2008 10:18:33 -0800 (PST) Received: by 10.86.90.2 with SMTP id n2mr8486534fgb.66.1203531513157; Wed, 20 Feb 2008 10:18:33 -0800 (PST) Received: by 10.86.35.18 with HTTP; Wed, 20 Feb 2008 10:18:33 -0800 (PST) Message-ID: <729b68be0802201018n59ebf617h80a688bab59ea06d@mail.gmail.com> Date: Wed, 20 Feb 2008 19:18:33 +0100 From: "Jean-Michel Combes" To: "Julien Laganier" In-Reply-To: <200802121631.35572.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Disposition: inline References: <200802111135.44252.julien.IETF@laposte.net> <200802121631.35572.julien.IETF@laposte.net> Cc: mext@ietf.org Subject: Re: [MEXT] [Recharter.2] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, 2008/2/12, Julien Laganier : > Folks, > [snip] > > List of items: > Blank vote for me. > > Also, please prefix each of the items in your list with the letters E, C > and/or R if you're willing to: > > - [E]dit: Are you willing to edit the draft corresponding to the > item. > > - [C]ontribute: Are you willing to propose text for the draft. > > - [R]eview: Are you willing to review new revisions of the draft when > being asked by the chairs. > But I am ready to review some drafts (mainly, from a security point of view) if necessary. Best regards. JMC. > > Thanks. > > -- julien and marcello, MEXT chairs > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Feb 20 10:55:33 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F2B328C1F7; Wed, 20 Feb 2008 10:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.914 X-Spam-Level: X-Spam-Status: No, score=-0.914 tagged_above=-999 required=5 tests=[AWL=-0.477, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6xrF1iC282A; Wed, 20 Feb 2008 10:55:32 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F3D23A6E47; Wed, 20 Feb 2008 10:55:32 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CCEB3A67D5 for ; Wed, 20 Feb 2008 10:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IEyEogsK+2k for ; Wed, 20 Feb 2008 10:55:30 -0800 (PST) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id 6367628C222 for ; Wed, 20 Feb 2008 10:55:30 -0800 (PST) Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Feb 2008 10:55:27 -0800 Message-ID: <47BC779D.2050705@azairenet.com> Date: Wed, 20 Feb 2008 10:55:25 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Robert Yang References: <008901c87365$cf6f7b20$4109a40a@china.huawei.com> In-Reply-To: <008901c87365$cf6f7b20$4109a40a@china.huawei.com> X-OriginalArrivalTime: 20 Feb 2008 18:55:27.0234 (UTC) FILETIME=[281D2E20:01C873F2] Cc: mext@ietf.org Subject: Re: [MEXT] One issue about RFC 5142(Mobility Header Home Agent Switch Message) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Robert, Robert Yang wrote: > Hi, Brian, Vijay and all > In section 6.1 of RFC 5142 it says that: it (MN) MUST send a Binding Error > message with the Status field set to 2 (unrecognized MH Type value) if it > does not support the message type. > But my Question is that: > (1)Binding error message is sent from CN instead of MN as described in > rfc3775; I think RFC 3775 already supports mobile node sending a Binding Error with status set to '2'. Section 11.2 (part of MN Operation section) says > All IPv6 mobile nodes MUST observe the rules described in Section 9.2 > when processing Mobility Headers. Section 9.2 (part of CN operation section) says > o The MH Type field MUST have a known value (Section 6.1.1). > Otherwise, the node MUST discard the message and issue a Binding > Error message as described in Section 9.3.3, with Status field set > to 2 (unrecognized MH Type value). Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Feb 20 11:32:08 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02AB03A6E19; Wed, 20 Feb 2008 11:32:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[AWL=-0.463, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhc2Gthcw2Uh; Wed, 20 Feb 2008 11:32:07 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34FE828CB04; Wed, 20 Feb 2008 11:30:18 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 366BF28C9FD for ; Wed, 20 Feb 2008 11:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMW3pFtQxp3n for ; Wed, 20 Feb 2008 11:30:10 -0800 (PST) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id D112728CAFE for ; Wed, 20 Feb 2008 11:29:32 -0800 (PST) Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Feb 2008 11:29:29 -0800 Message-ID: <47BC7F97.30905@azairenet.com> Date: Wed, 20 Feb 2008 11:29:27 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Jari Arkko References: <20080218193001.F28C43A6899@core3.amsl.com> <47B9E6E6.3020901@piuha.net> In-Reply-To: <47B9E6E6.3020901@piuha.net> X-OriginalArrivalTime: 20 Feb 2008 19:29:29.0702 (UTC) FILETIME=[E9851060:01C873F6] Cc: mext@ietf.org Subject: Re: [MEXT] draft-arkko-mext-rfc3775-altcoa-check-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Jari, I believe the original motivation for the alt CoA option was for the mobile node to be able to bind a new care-of address to its home address if it knows ahead of time that it would be soon handing over the access network where the new care-of address is valid. (I need to check with Charlie, this what I remember though). But we never found a use for the above. So we almost deprecated it once. But later on, when IPsec ESP was mandated for protecting a Binding Update, the alt CoA option was needed to protect the care-of address (since ESP offers no protection to the IPv6 header). So considering this, I am ok with requiring the HA to check if the address in the alt CoA option matches with the source address in the IPv6 header. This shouldn't impact FMIPv6 or DS-MIPv6. In DS-MIPv6, its the IPv4 CoA option that carries the IPv4 care-of address. In FMIPv6, the PAR is aware of the new CoA. However, we might need some explicit text in 4068bis to make sure the PAR would process the Fast BU even if the address in the alt CoA option is different from the source address. I will check with Rajeev. Finally, should we handle this as part of 3775bis? Vijay Jari Arkko wrote: > Hi all, > > I have posted a draft that suggests a modification of the rules > regarding Alternate Care-of Address checking. The rationale for the > change is in the draft -- it is something that came up during the > interim; there are closed networks that apply Mobile IPv6 and ingress > filtering, and it would be useful in those networks to be able to be > strict about what addresses the option can contain. > > The big question is if something today relies on the option value being > able to differ from the source IP address. The draft talks about this as > well and preliminarily I do not see a problem. But I would appreciate > discussion on this. > > Jari > >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> Title : Verifying Correctness of Alternate Care-of Address Option >> Author(s) : J. Arkko >> Filename : draft-arkko-mext-rfc3775-altcoa-check-00.txt >> Pages : 6 >> Date : 2008-02-18 >> >> This document revises the RFC 3775 rules on how Alternate Care-of >> Address option is processed. Alternate Care-of Address option is >> used to carry the current care-of address inside a Mobility Header >> message. This is used in addition to the source address in the >> packet in order to ensure that the care-of address is protected by >> IPsec ESP, the security mechanism that protects Mobility Header >> messages. Unfortunately, RFC 3775 did not require verification that >> the source address and care-of address are the same. This document >> adds that requirement. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-arkko-mext-rfc3775-altcoa-check-00.txt >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Feb 20 17:40:57 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD24128C278; Wed, 20 Feb 2008 17:40:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGBsQ7kcei9Q; Wed, 20 Feb 2008 17:40:56 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAD3B3A6A79; Wed, 20 Feb 2008 17:40:56 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D26903A6A79 for ; Wed, 20 Feb 2008 17:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOXO3M1Fld4C for ; Wed, 20 Feb 2008 17:40:55 -0800 (PST) Received: from szxga02-in.huawei.com (unknown [61.144.161.54]) by core3.amsl.com (Postfix) with ESMTP id D00213A6888 for ; Wed, 20 Feb 2008 17:40:54 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JWK00403FBP96@szxga02-in.huawei.com> for mext@ietf.org; Thu, 21 Feb 2008 09:40:37 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JWK00M7NFBO3M@szxga02-in.huawei.com> for mext@ietf.org; Thu, 21 Feb 2008 09:40:37 +0800 (CST) Received: from y66262 ([10.164.9.65]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JWK00B92FBOWG@szxml03-in.huawei.com> for mext@ietf.org; Thu, 21 Feb 2008 09:40:36 +0800 (CST) Date: Thu, 21 Feb 2008 09:40:35 +0800 From: Robert Yang In-reply-to: <47BC779D.2050705@azairenet.com> To: 'Vijay Devarapalli' Message-id: <00a401c8742a$c1170960$4109a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Thread-index: Achz8inDMCCPPFF9R7WqH9MWuPf7ZwAOItzQ Cc: mext@ietf.org Subject: Re: [MEXT] One issue about RFC 5142(Mobility Header Home Agent Switch Message) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org OK, thanks! B/R Robert Yang **************************************************************************** *********** This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! **************************************************************************** ************* > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Thursday, February 21, 2008 2:55 AM > To: Robert Yang > Cc: brian.haley@hp.com; mext@ietf.org > Subject: Re: One issue about RFC 5142(Mobility Header Home Agent Switch > Message) > > Hi Robert, > > Robert Yang wrote: > > Hi, Brian, Vijay and all > > In section 6.1 of RFC 5142 it says that: it (MN) MUST send a Binding Error > > message with the Status field set to 2 (unrecognized MH Type value) if it > > does not support the message type. > > But my Question is that: > > (1)Binding error message is sent from CN instead of MN as described in > > rfc3775; > > I think RFC 3775 already supports mobile node sending a Binding Error > with status set to '2'. Section 11.2 (part of MN Operation section) says > > > All IPv6 mobile nodes MUST observe the rules described in Section 9.2 > > when processing Mobility Headers. > > Section 9.2 (part of CN operation section) says > > > o The MH Type field MUST have a known value (Section 6.1.1). > > Otherwise, the node MUST discard the message and issue a Binding > > Error message as described in Section 9.3.3, with Status field set > > to 2 (unrecognized MH Type value). > > Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Feb 21 01:58:00 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D4E628CA91; Thu, 21 Feb 2008 01:58:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.447 X-Spam-Level: X-Spam-Status: No, score=-0.447 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3i6uGRuW9tg; Thu, 21 Feb 2008 01:57:59 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A1C228CA73; Thu, 21 Feb 2008 01:57:59 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C1B328C9AE for ; Thu, 21 Feb 2008 01:57:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mirFwDL2gulw for ; Thu, 21 Feb 2008 01:57:56 -0800 (PST) Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.91.200]) by core3.amsl.com (Postfix) with ESMTP id 9ED2B28C9FC for ; Thu, 21 Feb 2008 01:57:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clarinet.u-strasbg.fr (Postfix) with ESMTP id 159BDE6DAC for ; Thu, 21 Feb 2008 10:57:52 +0100 (CET) Received: from clarinet.u-strasbg.fr ([127.0.0.1]) by localhost (clarinet.u-strasbg.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpTtezfZpJHz for ; Thu, 21 Feb 2008 10:57:51 +0100 (CET) Received: from [130.79.91.222] (unknown [130.79.91.222]) by clarinet.u-strasbg.fr (Postfix) with ESMTP id C42B0E6DA1 for ; Thu, 21 Feb 2008 10:57:51 +0100 (CET) Message-Id: <654FF284-3A57-4FEB-8435-DB4C940C15C3@lsiit.u-strasbg.fr> From: Romain KUNTZ To: mext@ietf.org In-Reply-To: <47B9E6E6.3020901@piuha.net> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 21 Feb 2008 10:57:51 +0100 References: <20080218193001.F28C43A6899@core3.amsl.com> <47B9E6E6.3020901@piuha.net> X-Mailer: Apple Mail (2.919.2) Subject: Re: [MEXT] draft-arkko-mext-rfc3775-altcoa-check-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello, On 2008/02/18, at 21:13, Jari Arkko wrote: > I have posted a draft that suggests a modification of the rules > regarding Alternate Care-of Address checking. The rationale for the > change is in the draft -- it is something that came up during the > interim; there are closed networks that apply Mobile IPv6 and ingress > filtering, and it would be useful in those networks to be able to be > strict about what addresses the option can contain. > > The big question is if something today relies on the option value > being > able to differ from the source IP address. I think the current MCoA draft (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-05 ) allows (or at least does not prevent) the use of the alternate-coa option e.g. to register a CoA from one interface with a BU sent from another interface. Section 6.3 * If C flag is not set and an alternate care-of address is present, the care-of address is taken from the Alternate Care-of address mobility option. Regards, -- Romain KUNTZ kuntz@lsiit.u-strasbg.fr Louis Pasteur University - Networks and Protocols Team _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Feb 21 11:28:55 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5864228CADB; Thu, 21 Feb 2008 11:28:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.717 X-Spam-Level: X-Spam-Status: No, score=-0.717 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKT1KzhaRTk1; Thu, 21 Feb 2008 11:28:49 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AEE028C99C; Thu, 21 Feb 2008 11:28:49 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 525A428C65C for ; Thu, 21 Feb 2008 11:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxkyHMzk4QIY for ; Thu, 21 Feb 2008 11:28:47 -0800 (PST) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 5B07C28CAE9 for ; Thu, 21 Feb 2008 11:27:59 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: ASINGH1@motorola.com X-Msg-Ref: server-4.tower-128.messagelabs.com!1203622074!23112821!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 12324 invoked from network); 21 Feb 2008 19:27:54 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-4.tower-128.messagelabs.com with SMTP; 21 Feb 2008 19:27:54 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m1LJRsuf027095 for ; Thu, 21 Feb 2008 12:27:54 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id m1LJRrcQ018963 for ; Thu, 21 Feb 2008 13:27:54 -0600 (CST) Received: from de01exm71.ds.mot.com (de01exm71.am.mot.com [10.176.8.27]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id m1LJRrw6018952 for ; Thu, 21 Feb 2008 13:27:53 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Feb 2008 14:27:52 -0500 Message-ID: In-Reply-To: <654FF284-3A57-4FEB-8435-DB4C940C15C3@lsiit.u-strasbg.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] draft-arkko-mext-rfc3775-altcoa-check-00.txt Thread-Index: Ach0cFFOjmtuycf+T361bHJRaAlBZAATxPKQ References: <20080218193001.F28C43A6899@core3.amsl.com><47B9E6E6.3020901@piuha.net> <654FF284-3A57-4FEB-8435-DB4C940C15C3@lsiit.u-strasbg.fr> From: "Singh Ajoy-ASINGH1" To: X-CFilter-Loop: Reflected Subject: Re: [MEXT] draft-arkko-mext-rfc3775-altcoa-check-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, Jari / All. Sorry for delayed response. I also think there is an use case for alt-CoA in PMIPv6 context. So, I support the idea of keeping this in current MIPv6 spec. Regards, Ajoy From: "Premec, Domagoj" Date: Tue, 19 Feb 2008 10:15:53 +0100 Cc: mext at ietf.org Thread-index: Achyf0tycxiME4i+Tbu0RFrhEOZ5OgAVDlRw Thread-topic: [MEXT] draft-arkko-mext-rfc3775-altcoa-check-00.txt ------------------------------------------------------------------------ -------- Hi Sri, There was such a proposal in WiMAX, but this was before PMIP6 work in the IETF. Current discussions in WiMAX do not mention alt-CoA in this context. OTOH, any MAG could have a control plane blade and several data plane blades, so the concept is generally applicable. regards domagoj > -----Original Message----- > From: mext-bounces at ietf.org [mailto:mext-bounces at ietf.org] On > Behalf Of Sri Gundavelli > Sent: 18. veljaca 2008 23:39 > To: Jari Arkko > Cc: mext at ietf.org > Subject: Re: [MEXT] draft-arkko-mext-rfc3775-altcoa-check-00.txt > > Hi Jari, > > For seperating the control and data plane, there are some > folks who are thinking of using Alt-CoA option to carry a > different address than what is in the source address of the > field. There seem to be some proposals in WiMAX, applying > PMIP and with the functional split of MAG, using this option > for registering the tunnel endpoint which is on a different > entity. That wont work with this new restriction. Not sure, > if we can control this enforcement using a config option. > Personally, I dont have any issue with this change. > > Regards > Sri > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Feb 21 15:11:24 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DE0228C50C; Thu, 21 Feb 2008 15:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.584 X-Spam-Level: X-Spam-Status: No, score=-0.584 tagged_above=-999 required=5 tests=[AWL=-0.747, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_24=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWASbKyl4KGJ; Thu, 21 Feb 2008 15:11:21 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93D213A6A24; Thu, 21 Feb 2008 15:11:21 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C5883A6ABE for ; Thu, 21 Feb 2008 15:11:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oaFgkuEwjhT8 for ; Thu, 21 Feb 2008 15:11:17 -0800 (PST) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id 8232C3A6A24 for ; Thu, 21 Feb 2008 15:11:17 -0800 (PST) Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Feb 2008 15:11:13 -0800 Message-ID: <47BE0511.5010409@azairenet.com> Date: Thu, 21 Feb 2008 15:11:13 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: George Tsirtsis References: <47AC84E3.2030605@azairenet.com> In-Reply-To: X-OriginalArrivalTime: 21 Feb 2008 23:11:13.0878 (UTC) FILETIME=[0DD6F760:01C874DF] Cc: Julien Laganier , Ryuji Wakikawa , mext@ietf.org Subject: Re: [MEXT] WGLC for draft-ietf-monami6-multiplecoa-05.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi George, Thanks again for a very detailed review. I am not responding to your high level comments on this email. I will respond to those on the thread between you and Ryuji. For the comments you made inline in the text, please see below. George Tsirtsis wrote: > ------------------------------------------------------------------------------------------------------------------------------- > 1. Introduction > > ... > > But assigning a single home address to a node is more > advantageous than assigning multiple home addresses because > applications do not need to be aware of the multiplicity of home > addresses. > > GT> I am not sure I agree with this statement. I think effective use > of multiple home addresses by applications is a better and more robust > technique but it does require applications to be written in a certain > way. Multiple CoAs allow multihoming awareness to be outsourced to a > different part of the IP stack but, especially when combined with per > flow bindings, it results in routing that is not purely destination > address based. This is not necessarily a good thing for Internet > routing as a whole and only acceptable because it is only confined in > HAs. I think we can have a bit better applicability statement that is > more objective and looks at the big picture. i.e., at the > architectural limitations of this approach. I think the paragraph about advantages of using one home address over multiple home addresses should be removed. Using multiple home address is really out of scope for this document. This document should only talk about the advantages of being able to use multiple interfaces (care-of addresses) for connectivity. Re-wrote the Introduction section. A mobile node may use various types of network interfaces to obtain durable and wide area network connectivity. This is increasingly become true with mobile nodes having multiple interfaces such as 802.2, 802.11, 802.16, cellular radios, etc.. The motivations for and benefits of using multiple points of attachment are discussed in [ID-MOTIVATION]. When a mobile node with multiple interfaces uses Mobile IPv6 [RFC-3775] for mobility management, it cannot use its multiple interfaces to send and receive packets while taking advantage of session continuity provided by Mobile IPv6. This is because Mobile IPv6 allows the mobile node to only bind one care-of address at a time with its home address. This document proposes extensions to Mobile IPv6 to allow a mobile node to register multiple care-of addresses for a home address and create multiple binding cache entries. A new Binding Identification (BID) number is created for each binding the mobile node wants to create and sent in the binding update. The home agent that receives this Binding Update creates separate binding for each BID. The BID information is stored in the corresponding binding cache entry. The BID information can now be used to identify individual bindings. The same extensions can also be used in Binding Updates sent to the correspondent nodes. > ... > 3. Protocol Overview > > A new extension called the Binding identification number (BID) is > > GT> I think the name of the extension is "Binding Identifier Mobility > Option"? The extension is the use of a binding identification number with each binding. The mobility option is just carrying the binding identification number. > with the existing entry, the home agent MUST create a new binding > cache entry for the new care-of address and BID. The mobile node can > register multiple care-of addresses either independently in > individual Binding Updates or multiple at once in a single Binding > Update. > > If the mobile host wishes to register its binding with a > correspondent node, it must perform return routability operations. > This includes managing a Care-of Keygen token per care-of address and > exchanging CoTi and CoT message with the correspondent node for each > care-of address. It is RECOMMENDED that the mobile node uses the > same BID that it used with the home agent for a particular care-of > address. > > GT> I do not see why this is RECOMMENDED either :-). At most this is > a MAY, since I can not think of any reason why this not totally an > implementation decision. Changed it to 'MAY'. > Status > > When the Binding Identifier mobility option is included in a > Binding Acknowledgement, this field overwrites the status field > correspondent to each binding in the Binding Acknowledgement. If > this field is zero, the receiver MUST use the registration status > stored in the Binding Acknowledgement message. This Status field > can be used to carry error information for a Care-of Test message. > The status is 8-bit unsigned integer. > > The possible status codes > are the same as the status codes of Binding Acknowledgement. > > GT> This is not true, right? New values are defined in section 4.5. > Care-of address (C) flag I think the intention here is to say that we are not creating a new IANA registry. We are re-using the Binding Ack status code registry. > The mobile node MUST include a Binding Identifier mobility option in > the Care-of Test Init message. It MUST NOT set any flags in the > mobility option. The receiver (i.e. correspondent node) will > calculate a care-of Keygen token as specified in [RFC-3775] and reply > with a Care-of Test message, with the Binding Identifier mobility > option as described in Section 6.2. When the mobile node receives > the Care-of Test message, the message is verified as in [RFC-3775]. > If a Binding Identifier mobility option is not present in the CoT > message in reply to the CoTI message that included a Binding > Identifier mobility option, the mobile node must assume that the > correspondent node does not support Multiple Care-of Address > registration. Thus, the mobile node MUST NOT use a Binding > Identifier mobility option in any future Binding Updates to that > correspondent node. The mobile node MAY skip re-sending regular CoTI > message and keep the received care-of Keygen token for the regular > Binding Update. > > > GT> Should we also say anything about Enhanced RO based on RFC4866? No opinion on this. > 5.6.2. Using only Interface attached to the Visited Link > > The mobile node returns home and shuts down the interface attached to > the home link as shown in Figure 10. Before shutting down the > interface, any binding for the care-of address previously associated > with the interface should be deleted. To delete the binding cache > entry, the mobile node MUST send a de-registration Binding Update > with the lifetime set to zero and include the corresponding BID > information. This scenario is not the most efficient because all the > traffic to and from the mobile node is going through the bi- > directional tunnel, whereas the mobile node is now accessible at one > hop on the home link from its home agent. > > GT> This scenario is still confusing to me. My understanding is that > in this scenario the MN simply DOES NOT connect to the home link. If > the MN connected to a link that is identified or detected to be its > home link, it simply disconnects without sending a BU to the HA. So, > as far as the HA is concerned the MN is NOT connected at its home link > and operations continue as normal. The paragraph above, however, says > something different which does not match my understanding at all. Am I > confused? No. It is possible for the mobile node to just shut down the interface with which it is attached to the home link. But there is still a binding at the home agent that binds the home address to the care-of address previously associated with this interface. The above paragraph, I think, describes how to delete that binding. > > from the home link. When the mobile node returns home, the home > agent deletes the binding cache and stops proxying for the home > address so that a mobile node can configure its home address on the > interface attached to the home link. In this specification, a mobile > node may return home, configure the home address on the interface > attached to the home link, but still use the interfaces attached to > the foreign links. In this case, a possible conflict arises when the > both the home agent and the mobile node try to defend the home > address. If the home agent stops proxying for the home address, the > packets are always routed to the interface attached to the home link > and are never routed to the interfaces attached to the visited links. > It is required to avoid the conflict between the home agent and the > mobile node, while still allowing the simultaneous use of home and > foreign links. The following describes the mechanism for achieving > this. > > In this specification, the home agent MUST intercept all the packets > meant for the mobile node and decide whether to send the traffic > directly to the home address on the link or tunnel to the care-of > address. The home agent intercepts all the packets even when the > mobile node is attached to the home link through one of its > interfaces. The home agent would make this decision based on the > type of packets and flows. How to make this decision is out of scope > in this document. The critical part would be to create a neighbor > cache entry for the mobile node so that the home agent can deliver > the packets on-link. The home agent would need to know the Layer-2 > address of the interface with which the mobile node is attached to > the home link. In order to create the neighbor cache entry for the > mobile node, following operations are required. > > The mobile node sends a de-registration Binding Update to the home > agent from the interface attached to the home link. In the Binding > Update, the BID mobility option must include the BID the mobile node > had previously associated with the interface attached to the home > link. > > GT> When was this association done? What does "previously" refer to? When this interface was attached to the visited link previously it had a care-of address and a BID associated with it. > The 'H' flag MUST be set in the BID mobility option. The 'C' > flag MUST NOT be set and the care-of address field MUST NOT be > included. When the 'H' flag is set, the home agent recognizes that > the mobile node wants to continue using interfaces attached to both > home and visited links. If the 'H' flag is unset, the home agent > deletes either all the bindings or the binding corresponding to the > BID included in the Binding Identifier mobility option. > > When the home agent sends the Binding Acknowledgement, it MUST set > the status value to either 0 [Binding Update Accepted] or to [MCOA > RETURNHOME WO/NDP (TBD)] in the BID mobility option depending on home > agent configuration at the home link. The new values are: > > o Binding Update Accepted (0): NDP is permitted for the home address > at the home link. This is regular returning home operation of > [RFC-3775] > > o MCOA RETURNHOME WO/NDP (TBD): NDP is prohibited for the home > address at the home link > > When the home agent is the only router at the home link, it can > intercept all the packets by normal IP routing without using proxying > for the home address. It stops proxy ND for the requested home > address and responds with the [Binding Update Accepted] status value > to the mobile node. The neighbor cache entry for the mobile node is > created by the regular exchange of Neighbor Solicitation and Neighbor > Advertisement. If the home agent is not the only router on the home > link, it MUST continue defending the home address by proxy neighbor > discovery in order to intercept the mobile node's traffic. The home > agent, then, returns [MCOA RETURNHOME WO/NDP] value in the Status > field of the BID mobility option. The home agent also learns the > mobile node's layer-2 address (i.e., MAC address) during this binding > de-registration. It stores the learnt layer-2 address in a neighbor > cache entry for the mobile node so that it can construct the layer-2 > header for the packets meant for the mobile node and forwards them > directly to the mobile node's interface attached to the home link. > > According to [RFC-3775], the mobile node MUST NOT assign the home > address to the interface attached to the home link and MUST NOT > attempt NDP operations for the home address before the completion of > binding de-registration. It MUST NOT send and reply to Neighbor > Solicitation for the home address. The home address MUST be > tentative address at this moment until it receives Binding > Acknowledgement with success status value. > > When the mobile node receives the Binding Acknowledgement and BID > mobility option, it assigns home address to the interface attached to > the home link according to the status field of the BID. If the value > is [Binding Update Accepted], the mobile node can start defending the > home address using regular Neighbor Discovery. > > If the mobile node receives the [MCOA RETURNHOME WO/NDP], it MUST NOT > defend its home address on the home link. When the mobile node sends > packets from the interface attached to the home link, it MUST learn > the layer 2 address (i.e., MAC address) of the next hop (i.e. default > router, it can be home agent) during the binding de- registration and > construct the packet including layer 2 header with the learnt layer-2 > address of the default router or the home agent. > > > GT> Something needs to be said about the lifetime of the BU with 'H' > flag set. If the MN has to send a de-reg to the HA with Lifetime=0 and > 'H' set, for how ling is this state valid? What happens to the > lifetime of the other bindings?? Needs to be discussed as part of overall binding lifetime issue. > > 5.7. Receiving Binding Acknowledgement > > The verification of a Binding Acknowledgement is the same as Mobile > IPv6 (section 11.7.3 of [RFC-3775]). The operation for sending a > Binding Acknowledgement is described in Section 6.3. > > If a mobile node includes a Binding Identifier mobility option in a > Binding Update with the 'A' flag set, a Binding Acknowledgement MUST > carry a Binding Identifier mobility option. If no such mobility > option is included in the Binding Acknowledgement in response to a > Binding Update for multiple care-of address registration, this > indicates that the originating node of the Binding Acknowledgement > does not support processing the Binding Identifier mobility option. > The mobile node MUST then stop multiple care-of address registration > with that node. > > If a Binding Identifier mobility option is present in the received > Binding Acknowledgement, the mobile node checks the status field in > the option. If the status value in the Binding Identifier mobility > option is zero, the mobile node uses the value in the Status field of > the Binding Acknowledgement. Otherwise, it uses the value in the > Status field of the Binding Identifier mobility option. > > If the status code is greater than or equal to 128, the mobile node > starts relevant operations according to the error code. Otherwise, > the mobile node assumes that the originator (home agent or > correspondent node) successfully registered the binding information > and BID for the mobile node. > > o If the Status value is [MCOA PROHIBITED], the mobile node MUST > stop registering multiple bindings to the node that sent the > Binding Acknowledgement. > > o If the Status value is [MCOA BULK REGISTRATION NOT SUPPORT], the > mobile node SHOULD stop using bulk registrations with the node > that sent the Binding Acknowledgement. > > o If [MCOA MALFORMED] is specified, it indicates that the binding > identifier mobility option is formatted wrongly. For example, if > the 'C' flag is set, all mobility options MUST have 'C' flag. It > is same for 'O' flag. > > GT> What do you mean here with the 'C' and 'O' flags? It is not clear. > Also it is not nice to find MUSTs with respect on how to use the flags > when talking about the error codes. These MUSTs, if needed, should be > moved elsewhere. I think the example needs to be deleted. Other sections in the document describe why the status MCOA_MALFORMED is returned in a binding ack (or the status field in the BID option). > Beside the difference in the size of packets, there is no difference > between the two. The routing path does not get affected. With > extensions specified in this document, the mobile node is capable of > using multiple care-of addresses for outgoing packets. This is a > problem on the home agent side because it must verify the Care-of > address for all the packets received from the mobile node (i.e. > ingress filtering). When the mobile node uses the Home Address > option, the home agent MAY check the care-of address in the packet > with the registered binding entries. This causes additional overhead > to the home agent. Therefore, the mobile node SHOULD use the bi- > directional tunnel even if it registers a binding(s) to the home > agent. > > GT> This confuses me a bit. Is there anything different from RFC3775? > Why is this section needed? I think it should be deleted. When packets are tunneled to the home agent, the home agent checks if the source address on the outer IPv6 header matches the care-of address in the binding cache entry. The only exception is when the packet contains a binding update. So the sentence in the above paragraph is actually not valid. > 5.10. Bootstrapping > > When a mobile node bootstraps and registers multiple bindings for the > first time, it SHOULD set the 'O' flag in the Binding Identifier > mobility option. > > GT> Should this be a MUST? Otherwise what is the behavior of the HA? Not necessary, since we have a recovery mechanism (Status code 135, sequence number out of window) in RFC 3775. The binding ack will tell the mobile node which sequence number to use. > 6. Home Agent and Correspondent Node Operation > > 6.1. Searching Binding Cache with Binding Identifier > > If either a correspondent node or a home agent has multiple bindings > for a mobile node in their binding cache database, it can use any of > the bindings to communicate with the mobile node. How to select the > most suitable binding from the binding cache database is out of scope > in this document. > > Whenever a correspondent node searches a binding cache for a home > address, it SHOULD uses both the home address and the BID as the > search key if it knows the corresponding BID. > > GT> This is a bid strange. Why would the HA or CN use a BID as a key? > The HoA is used as a key because the HA/CN want to send a packet with > the HoA as destination address, which causes Mobile IP to use the HoA > as a key to find an appropriate CoA. I do not think that the BIDs are > needed for this. With MCoA, the only difference is that a lookup of > the HoA will return multiple CoAs; and which one is used is out of > scope for this document. > > GT> So, the BIDs are only used as key when the receiver processes a BU > message including a BID Mobility option. Is this what this is about? I think the text here assumes that the HA or the CN when trying to send/forward a packet, the packet gets mapped (based on the source/destination IP, source/destination port, and protocol) to a particular BID. Then the BID is used as a key along with the home address. This needs some more discussion, before we can decide what text goes into this section. > 6.3. Processing Binding Update > > If a Binding Update does not contain a Binding Identifier mobility > option, its processing is same as in [RFC-3775]. If the receiver > already has multiple bindings for the home address, it MUST replace > all the existing bindings by the received binding. As a result, the > receiver node MUST have only one binding cache entry for the mobile > node. If the Binding Update is for de-registration, the receiver > MUST delete all existing bindings from its Binding Cache. > > If the Binding Update contains a Binding Identifier mobility > option(s), it is validated according to section 9.5.1 of [RFC-3775] > and the following steps. > > o If the home registration flag is set in the Binding Update, the > home agent MUST carefully operate Duplicate Address Detection > (DAD) for the received home address. If the home agent has > already had a binding(s) for the mobile node, it MUST avoid > running DAD for the home address on the home link when it receives > the Binding Update. > > GT> Why is this here? This is normal RFC3775 operation and should not > be affected by MCoA, no? I think the difference is that in RFC 3775, if there is a valid binding cache entry for the home address already, the new BU would be for just refreshing the binding. In MCoA case, the new BU could be for adding another care-of address. But in both cases, the home agent MUST NOT run DAD again for the home address. So the behavior the same. The paragraph can be removed. > The receiver MUST process the Binding Identifier mobility option(s) > in the following steps. When a correspondent node sends a Binding > Acknowledgement, the status value MUST be always stored in the Status > field of the Binding Acknowledgement and the Status field of Binding > Identifier mobility option set to zero. > > GT> The last sentence does not make sense. Please rephrase. The last sentence and the next paragraph are in the wrong place. Moving them to the end of section after the BID option processing steps. > MUST reject the Binding Identifier mobility option and returns the > status value set to [MCOA MALFORMED]. The operation of 'D' flag > is described in Section 8 > > o When multiple Binding Identifier mobility options are present in > the Binding Update, it is treated as bulk registration. If the > receiving node is a correspondent node, it MUST reject the Binding > Update and returns the status value in the binding acknowledgement > set to [MCOA BULK REGISTRATION NOT SUPPORT] > > o If the Lifetime field in the Binding Update is set to zero, the > receiving node deletes the binding entry that corresponds to the > BID in the Binding Identifier mobility option. If the receiving > node does not have an appropriate binding for the BID, it MUST > reject the Binding Update and send a Binding Acknowledgement with > status set to 133 [not home agent for this mobile node]. > > GT>This does not make sense. If the BID does not exist then the > binding never existed or has already been deleted so I would send a BA > and BID Mobility option with status 0. Status 133 means that the HoA > is not valid...which is a different issue already covered in RFC3775. > Also please move this bullet one place down to be next to Lifetime != > zero case. No. This is required from RFC 3775. If a mobile node sends a de-registration BU (with lifetime 0) and if the home agent does not have a binding, it must send a binding ack with status 133. Sending a binding ack with status 0 would tell the mobile node that the de-registration BU was successfully processed and the corresponding binding cache entry was deleted. This is not the case. > Update, the receiving nodes creates new binding(s). > > * If only the 'O' flag is set in the Binding Identifier mobility > option, the home agent removes all the existing bindings and > registers the received bindings. > > * If the receiver has a regular binding which does not have BID > for the mobile node, it must not process the binding update. > The receiver should sent a binding acknowledgement with status > set to [MCOA BID CONFLICT]. > > GT> This makes no sense. What do you mean? This is to handle the case where the home agent has a binding cache entry with no BID information, but receives a binding update with a BID option. The home agent does not know what BID to assign to the CoA in the binding cache entry. So instead it sends an error with status BID_CONFLICT. > Acknowledgement with status set to 0 [Binding Update accepted]. > > * If the receiver does not have a binding entry for the BID, it > registers a new binding for the BID and responds with a Binding > Acknowledgement with status set to 0 [Binding Update accepted]. > > GT> What happens if one receives a new BID mapped to a CoA already in > the binding cache (but mapped to different BID?) Is this allowed? Is > this how one can change the BIDs it is using? I think the mobile node has to delete the earlier one and then create new bindings. > 6.4. Sending Binding Refresh Request > > When a node (home agent or correspondent node) sends a Binding > Refresh Request for a particular binding created with the BID, the > node SHOULD include the Binding Identifier mobility option in the > Binding Refresh Request. > > GT> This needs a bit more...which BID mobility option is included? > Just one? All of them? Again we need to be clear what the lifetime > does and how it relates to each of the CoAs. Tied to the lifetime issue again. > > 6.5. Receiving Packets from Mobile Node > > When a node receives packets with a Home Address destination option > from a mobile node, it MUST check that the care-of address that > appears in the source address field of the IPv6 header MUST be equal > to one of the care-of addresses in the binding cache entry. If no > binding is found, the packets MUST be silently discarded. > > GT> Why don't we just point to RFC3775 and say that the exact same > processing is used here? There is a minor difference. The source address in the IPv6 header can match "any" care-of address in the binding cache entry. In RFC 3775, there was only care-of address in the binding cache and that had to match with the source address in the IPv6 header. > 7. Network Mobility Applicability > > The binding management mechanisms are the same for a mobile host that > uses Mobile IPv6 and for a mobile router that is using the NEMO Basic > Support protocol [RFC-3963]. Therefore the extensions described in > this document can also be used to support a mobile router with > multiple care-of addresses. Figure 5 shows an example format of a > Binding Update sent by a mobile router. > > IPv6 header (src=CoA, dst=HA) > IPv6 Home Address Option > ESP Header > Mobility header > -BU > Mobility Options > - Binding Identifier > - Mobile Network Prefix > > Figure 5: NEMO Binding Update > > > > > > GT> Why is this example here? I would remove it together with the last > sentence. I think it just shows the use of a BID option in a BU sent by a mobile router. The BU sent by the mobile router has the Mobile Network Prefix option, which isn't there in a normal BU. But I agree this example is not required. Will remove it. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Feb 21 15:26:27 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C11E3A6CF9; Thu, 21 Feb 2008 15:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.86 X-Spam-Level: X-Spam-Status: No, score=-0.86 tagged_above=-999 required=5 tests=[AWL=-0.423, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3InaFZ71IpoT; Thu, 21 Feb 2008 15:26:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24B8D3A6A86; Thu, 21 Feb 2008 15:26:26 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93E233A67C0 for ; Thu, 21 Feb 2008 15:26:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7wfItLUj9nh for ; Thu, 21 Feb 2008 15:26:24 -0800 (PST) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id 959513A6AEA for ; Thu, 21 Feb 2008 15:26:24 -0800 (PST) Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Feb 2008 15:26:21 -0800 Message-ID: <47BE089C.2060707@azairenet.com> Date: Thu, 21 Feb 2008 15:26:20 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: George Tsirtsis References: <47AC84E3.2030605@azairenet.com> <55AB1BB1-1C3B-4C6E-8E04-5584C9669B17@gmail.com> In-Reply-To: X-OriginalArrivalTime: 21 Feb 2008 23:26:21.0191 (UTC) FILETIME=[2AA3F170:01C874E1] Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] WGLC for draft-ietf-monami6-multiplecoa-05.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org George Tsirtsis wrote: >>> - a BU with lifetime=0 and H=1 indicates the MN is at home link, but >>> the lifetime of other BIDs is not affected. >> right. >> >>> How is the home link >>> state maintained though? This looks like hard state at the moment and >>> I do not like it. Any ideas? >> I might miss your question. I am a bit confused. A BU with the 'H' flag set is used only for simultaneous home and visited link operation. Why would the lifetime be zero in this BU? In fact the mobile node is requesting the home agent to intercept all packets even though it is attached to the home link through one of its interfaces. There should be a lifetime associated with the kind of home agent behavior. George, I agree we shouldn't create some state on the home agent that might not expire because there is a Mobile IP signaling message that does not explicitly delete it. However, we might still have to explain how the home agent handles a BU with lifetime set to zero and the 'H' flag set to 1. Vijay >> >> HA should verify the reachability of the mobile node at the home link. >> If the reachability is missed, the HA should clean up the all the home >> link states. >> > > GT> Yes, this is what I think is not ideal. Mobile IP, as most well > designed IP protocols, is a soft state protocol, and all of its state > is associated with lifetimes which are maintained by signaling. We are > now seem to be saying that when you have a home link, and although the > HA must maintain state for that fact, that state is "hard" and can > only be cleared by mechanisms that are outside protocol itself e.g., > L2 triggers indicating the link is down. > > GT> I think a possible alternative which is even implied (but not > clearly stated) by the current draft, is to use the lifetime > maintained by the visited links. In other words, in the H=1 scenario, > the MN has at least one other binding corresponding to a visited link. > That visited link CoA is associated in the HA with a Lifetime. This > same Lifetime value should be what maintains the home link state. The > difference is that the MN does not maintain the home link state > directly (i.e., it only has to send a BU with H=1 once) and then the > state is maintained by the Lifetime associated with visited link BIDs. > The implication is that if the MN deregisters all of its visited link > CoAs the home link state is automatically removed i.e., it is as if > the MN sent a BU with Lifetime=0 and no BID extensions. > Does this make sense? > >>> 2) Changing BIDs. the draft indicates that BIDs can be changed for >>> privacy reasons. While I still do not understand what these reasons >>> are, >> The point is not privacy or security reason, but MN can always pick a >> new BID. >> > > GT> But for what reason? the draft somehow implies that this is a good > practice....while I think it is rather dangerous practice since it > would cause uneccessary and difficult to dimension for BU signaling > traffic. > >>> I also do not see anywhere how BIDs can be changed. Is is done by >>> sending a BU with a new BID mapped to a CoA that is already in the >>> binding cache (but mapped to another BID)? >> yes. >> >>> I indicate that this could >>> be added somewhere inline, but some additional care also needs to be >>> taken e.g., can you reuse the BID you are replacing in the same BU? >> This seems to be corner-case, but we will clarify it. >> > > GT> Yes, do. But also I would warn against doing this for no particular reason. > >>> 3) Section 5.6.2 (using only IF attached to visitied) is very >>> confusing: I copy here the comment I also placed inline below: >>> My understanding is that in this scenario the MN simply DOES NOT >>> connect to the home link. If the MN connected to a link which is >>> identified or detected to be its home link, it simply disconnects >>> without sending a BU to the HA. So, as far as the HA is concerned the >>> MN is NOT connected at its home link and operations continue as >>> normal. The text in this section, however, says something different >>> which does not match my understanding at all. Am I confused? >> We need one more operation here. >> >> What about the binding cache for the CoA previously assigned to the >> interface(which is now disconnected)? >> The interface is now disconnected, but the old binding cache for the >> previous CoA assigned to that interface >> might be still active at the home agent. >> It should explicitly send de-registration BU for that binding cache, >> since >> MN has other active interfaces to send that BU. >> > > GT> What CoA previously assigned are you talking about? At a home or a > visited link? We do not use CoAs in home links (are we?), and CoAs on > visited links are normal case in this scenario. I do not understand. > > > \> We will revise the texts of section 5.6.2. >> thanks _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Feb 21 22:33:59 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 722F63A6839; Thu, 21 Feb 2008 22:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.707 X-Spam-Level: X-Spam-Status: No, score=-0.707 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKZi736E1w0Q; Thu, 21 Feb 2008 22:33:45 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 213C13A6B93; Thu, 21 Feb 2008 22:33:45 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 642E03A6B93 for ; Thu, 21 Feb 2008 22:33:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4msIvE9IxtwP for ; Thu, 21 Feb 2008 22:33:43 -0800 (PST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 507923A6B1F for ; Thu, 21 Feb 2008 22:33:43 -0800 (PST) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 238191EF12D for ; Fri, 22 Feb 2008 08:33:38 +0200 (EET) Received: from [IPv6:2001:14b8:400:101:20e:7fff:fef8:6a7b] (unknown [IPv6:2001:14b8:400:101:20e:7fff:fef8:6a7b]) by n2.nomadiclab.com (Postfix) with ESMTP id DF6C91EF11B for ; Fri, 22 Feb 2008 08:33:37 +0200 (EET) Message-ID: <47BE6C9A.6060105@nomadiclab.com> Date: Fri, 22 Feb 2008 08:32:58 +0200 From: Heikki Mahkonen User-Agent: Thunderbird 2.0.0.9 (X11/20071212) MIME-Version: 1.0 To: mext@ietf.org References: <20080218193001.F28C43A6899@core3.amsl.com> <47B9E6E6.3020901@piuha.net> <654FF284-3A57-4FEB-8435-DB4C940C15C3@lsiit.u-strasbg.fr> In-Reply-To: <654FF284-3A57-4FEB-8435-DB4C940C15C3@lsiit.u-strasbg.fr> X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [MEXT] draft-arkko-mext-rfc3775-altcoa-check-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, Romain KUNTZ wrote: > Hello, > > I think the current MCoA draft (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-05 > ) allows (or at least does not prevent) the use of the alternate-coa > option e.g. to register a CoA from one interface with a BU sent from > another interface. > > Section 6.3 > > * If C flag is not set and an alternate care-of address is > present, the care-of address is taken from the Alternate > Care-of address mobility option. ==> The MCoA draft uses the C flag to indicate whether it is a BU message for a bulk or single registration. If the C flag is not set the BU is a single registration and the CoA must be taken from the Alt. CoA option. In this case I think it must be the same as the source address of the BU message (MN has only one CoA). If the C flag is set, CoAs for each binding are taken from the BID options. In the bulk case I think that the Alt. CoA option is omitted altogether. At least the MCoA draft says that "...The alternate care-of address option MUST be omitted when ESP is used to protect a binding update." (Section 5.4 Binding Bulk Registration). If for some reason the MN doesn't use ESP and adds Alt. CoA option I think that it must have same CoA as source address and in Alt. CoA option. So therefore I don't think that the new Alt. CoA check draft intervenes with the MCoA draft... BR, Heikki _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Feb 21 22:56:18 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D300E28C1B7; Thu, 21 Feb 2008 22:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.557 X-Spam-Level: X-Spam-Status: No, score=-0.557 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FuFZ+RHUgbcq; Thu, 21 Feb 2008 22:56:17 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D50E53A6808; Thu, 21 Feb 2008 22:56:17 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8131B3A692D for ; Thu, 21 Feb 2008 22:56:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kw+grZFegepG for ; Thu, 21 Feb 2008 22:56:16 -0800 (PST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 9AD6F3A6808 for ; Thu, 21 Feb 2008 22:56:16 -0800 (PST) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 386331EF12D for ; Fri, 22 Feb 2008 08:56:12 +0200 (EET) Received: from [IPv6:2001:14b8:400:101:20e:7fff:fef8:6a7b] (unknown [IPv6:2001:14b8:400:101:20e:7fff:fef8:6a7b]) by n2.nomadiclab.com (Postfix) with ESMTP id 04B981EF11B for ; Fri, 22 Feb 2008 08:56:12 +0200 (EET) Message-ID: <47BE71E4.6040703@nomadiclab.com> Date: Fri, 22 Feb 2008 08:55:32 +0200 From: Heikki Mahkonen User-Agent: Thunderbird 2.0.0.9 (X11/20071212) MIME-Version: 1.0 To: mext@ietf.org References: <20080218193001.F28C43A6899@core3.amsl.com><47B9E6E6.3020901@piuha.net> <654FF284-3A57-4FEB-8435-DB4C940C15C3@lsiit.u-strasbg.fr> In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [MEXT] draft-arkko-mext-rfc3775-altcoa-check-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, Singh Ajoy-ASINGH1 wrote: > Hi, Jari / All. > > Sorry for delayed response. I also think there is an use case for > alt-CoA in PMIPv6 context. > So, I support the idea of keeping this in current MIPv6 spec. > ==> In PMIP case there might be use for Alt. CoA option (at least when using HW that has separated CPs and UPs). The use of Alt. CoA option is also described in the PMIPV6 draft. However, PMIPv6 uses Proxy Binding Updates and Acknowledgments so the new checking in the new draft doesn't need to be applied for PMIPv6, rigtht? I mean the draft says that "When an Alternate Care-of Address option is present in a Binding Update message, perform the following additional test:". If this new check is also needed for the PMIPv6, then I think PMIPv6 requires a new option to carry the CoA used for signaling (address of the CP) inside the ESP protected part of the message. Then the Alt. CoA option can be used to carry the address for the PMIPv6 tunnel endpoint (address of the UP). Never the less, I think that the CP needs to know the address of the UP to add it into the Alt. CoA option, so I guess it would be doable to use the same UP address also for signaling (as a source address of the PBU)... BR, Heikki _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Feb 22 04:31:08 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E41228C355; Fri, 22 Feb 2008 04:31:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.674 X-Spam-Level: X-Spam-Status: No, score=-0.674 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLE83rsGLq3e; Fri, 22 Feb 2008 04:31:07 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62EB628C327; Fri, 22 Feb 2008 04:31:07 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A73728C32E for ; Fri, 22 Feb 2008 04:31:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQeXG5h6BaaG for ; Fri, 22 Feb 2008 04:31:05 -0800 (PST) Received: from mxs2.siemens.at (mxs2.siemens.at [194.138.12.133]) by core3.amsl.com (Postfix) with ESMTP id 33DD728C327 for ; Fri, 22 Feb 2008 04:31:05 -0800 (PST) Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs2.siemens.at with ESMTP id m1MCV5kG000486; Fri, 22 Feb 2008 13:31:05 +0100 Received: from nets139a.ww300.siemens.net ([158.226.129.97]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id m1MCUq2I024100; Fri, 22 Feb 2008 13:30:58 +0100 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Feb 2008 13:30:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 22 Feb 2008 13:30:43 +0100 Message-ID: <3C31CDD06342EA4A8137716247B1CD6803750856@zagh223a.ww300.siemens.net> In-Reply-To: <47BE71E4.6040703@nomadiclab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] draft-arkko-mext-rfc3775-altcoa-check-00.txt Thread-Index: Ach1IJCw79HLTCrwS96MAkVxAME6bgAK7EGg References: <20080218193001.F28C43A6899@core3.amsl.com><47B9E6E6.3020901@piuha.net> <654FF284-3A57-4FEB-8435-DB4C940C15C3@lsiit.u-strasbg.fr> <47BE71E4.6040703@nomadiclab.com> From: "Premec, Domagoj" To: "Heikki Mahkonen" , X-OriginalArrivalTime: 22 Feb 2008 12:30:43.0986 (UTC) FILETIME=[BE408F20:01C8754E] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::080222133105-0AEA1BB0-078BBC92/0-0/0-15 X-purgate-size: 2444/999999 Subject: Re: [MEXT] draft-arkko-mext-rfc3775-altcoa-check-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Heikki, > Never the less, I think that the CP needs to know the > address of the UP to add it into the Alt. CoA option, so I > guess it would be doable to use the same UP address also for > signaling (as a source address of the PBU)... By using the same address for CP and UP the CP messages would arrive at the user plane blade which is not able to deal with them. In addition, if the LMA would send unsolicited messages to the MAG (like Binding Revocation), the LMA needs to save two different CoAs in the BCE: one for signalling (source IP) and another for data plane (alt-CoA). regards domagoj > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Heikki Mahkonen > Sent: 22. veljaca 2008 07:56 > To: mext@ietf.org > Subject: Re: [MEXT] draft-arkko-mext-rfc3775-altcoa-check-00.txt > > Hi, > > Singh Ajoy-ASINGH1 wrote: > > Hi, Jari / All. > > > > Sorry for delayed response. I also think there is an use case for > > alt-CoA in PMIPv6 context. > > So, I support the idea of keeping this in current MIPv6 spec. > > > ==> In PMIP case there might be use for Alt. CoA option (at > least when using HW that has separated CPs and UPs). The use > of Alt. CoA option is also described in the PMIPV6 draft. > However, PMIPv6 uses Proxy Binding Updates and > Acknowledgments so the new checking in the new draft doesn't > need to be applied for PMIPv6, rigtht? I mean the draft says > that "When an Alternate Care-of Address option is present in > a Binding Update message, perform the following additional test:". > > If this new check is also needed for the PMIPv6, then I think > PMIPv6 requires a new option to carry the CoA used for > signaling (address of the CP) inside the ESP protected part > of the message. Then the Alt. CoA option can be used to carry > the address for the PMIPv6 tunnel endpoint (address of the > UP). Never the less, I think that the CP needs to know the > address of the UP to add it into the Alt. CoA option, so I > guess it would be doable to use the same UP address also for > signaling (as a source address of the PBU)... > > BR, > > Heikki > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Feb 22 05:39:09 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 647703A6CA9; Fri, 22 Feb 2008 05:39:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.828 X-Spam-Level: X-Spam-Status: No, score=-0.828 tagged_above=-999 required=5 tests=[AWL=-0.391, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksm8hBBg-b-4; Fri, 22 Feb 2008 05:39:08 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E4BE3A6C16; Fri, 22 Feb 2008 05:39:08 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 608F83A6C54 for ; Fri, 22 Feb 2008 05:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTM1KAbC27vJ for ; Fri, 22 Feb 2008 05:39:05 -0800 (PST) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 407EA3A6817 for ; Fri, 22 Feb 2008 05:39:05 -0800 (PST) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile11) with ESMTP id m1MDd0M3001230 for ; Fri, 22 Feb 2008 22:39:00 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb1) with ESMTP id m1MDd0t00759 for ; Fri, 22 Feb 2008 22:39:00 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili01) with ESMTP id m1MDcwP08977 for ; Fri, 22 Feb 2008 22:38:59 +0900 (JST) Received: from NW-Sephiroth ([10.238.16.146]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Feb 2008 21:37:49 +0800 Received: from NWSephiroth by NW-Sephiroth (PGP Universal service); Fri, 22 Feb 2008 21:37:45 +0800 X-PGP-Universal: processed; by NW-Sephiroth on Fri, 22 Feb 2008 21:37:45 +0800 From: "Benjamin Lim" To: Date: Fri, 22 Feb 2008 21:37:40 +0800 Message-ID: <000001c87558$19fc34f0$9210ee0a@psl.local> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_01C8759B.281F74F0" X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ach1N34kfN18aZdPScSZ76Id88bUGAAH2kMQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 22 Feb 2008 13:37:49.0848 (UTC) FILETIME=[1DDA5980:01C87558] Subject: [MEXT] FW: I-D Action:draft-lim-mext-multiple-coa-verify-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C8759B.281F74F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, We have submitted an updated draft regarding the binding of 'fake' CoA at HA. In this update, the changes are: - Reference latest MCoA draft that specify the problem. - Added two more solutions (limiting care-of address binding at HA and CoA test using 'symbiotic' relationship) for analysis. Appreciate comments. Regards, Benjamin Lim -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Friday, February 22, 2008 5:45 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-lim-mext-multiple-coa-verify-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Verification of Care-of Addresses in Multiple Bindings Registration Author(s) : B. Lim, et al. Filename : draft-lim-mext-multiple-coa-verify-01.txt Pages : 19 Date : 2008-02-22 Using multiple care-of address registration, there is a possibility that a malicious mobile node could create multiple care-of address bindings that does not belong to the mobile node at its home agent. The home agent would accept these bindings without verifying them due to the trust relationship it has with the mobile node. With these bindings, the mobile node can launch attacks by asking the home agent to flood the victims of these care-of addresses with useless packets. To mitigate such a problem, this memo introduces a verification mechanism that the home agent would use in order to verify the care-of addresses for the mobile node before using them for packet routing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lim-mext-multiple-coa-verify-01.tx t 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-lim-mext-multiple-coa-verify-01.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-lim-mext-multiple-coa-verify-01.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_000_0001_01C8759B.281F74F0 Content-Type: Message/External-body; name="ATT00004.dat" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00004.dat" Content-Type: text/plain Content-ID: <2008-02-22014013.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lim-mext-multiple-coa-verify-01.txt ------=_NextPart_000_0001_01C8759B.281F74F0 Content-Type: Message/External-body; name="draft-lim-mext-multiple-coa-verify-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-lim-mext-multiple-coa-verify-01.txt" Content-Type: text/plain Content-ID: <2008-02-22014013.I-D\@ietf.org> ------=_NextPart_000_0001_01C8759B.281F74F0 Content-Type: text/plain; name="ATT00007.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00007.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org http://www.ietf.org/mailman/listinfo/i-d-announce ------=_NextPart_000_0001_01C8759B.281F74F0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext ------=_NextPart_000_0001_01C8759B.281F74F0-- From mext-bounces@ietf.org Fri Feb 22 09:13:16 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56B243A6CAC; Fri, 22 Feb 2008 09:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.461 X-Spam-Level: X-Spam-Status: No, score=-0.461 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODta5Q2qrFkf; Fri, 22 Feb 2008 09:13:15 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31C8B3A6CF4; Fri, 22 Feb 2008 09:13:14 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E74B3A6CE2 for ; Fri, 22 Feb 2008 09:13:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCyzhFv-huVG for ; Fri, 22 Feb 2008 09:13:11 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id E22433A6C86 for ; Fri, 22 Feb 2008 09:11:44 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 4EB11198D6D; Fri, 22 Feb 2008 19:11:40 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id EBDFF198D06; Fri, 22 Feb 2008 19:11:37 +0200 (EET) Message-ID: <47BEF5D9.9060402@piuha.net> Date: Fri, 22 Feb 2008 17:18:33 +0100 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: Francis Dupont References: <200802201656.m1KGuvo3012318@givry.fdupont.fr> In-Reply-To: <200802201656.m1KGuvo3012318@givry.fdupont.fr> X-Virus-Scanned: ClamAV using ClamSMTP Cc: mext@ietf.org Subject: Re: [MEXT] draft-arkko-mext-rfc3775-altcoa-check-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Francis, > => there is a known case: in the return to home it is useful to have > different source and care-of addresses. For instance the source address > can be a link-local address when the care-of address is by definition > the home address. > So I propose to relax your new requirement by: > 1- accepting the source address or the home address as a valid care-of > address; > 2- make the check policy-based with the check "on" for the default policy > ("on" ::= perform the check and reject the BU when it fails). > OK -- thanks for this. I actually already changed this due to someone else's comment. The text now reads: "If the address in the Alternate Care-of Address option is not the same as either the home address or the Source Address field in the IPv6 header of the Binding Update packet, then ..." Jari _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Feb 22 11:12:58 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C29373A6CCA; Fri, 22 Feb 2008 11:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.305 X-Spam-Level: X-Spam-Status: No, score=0.305 tagged_above=-999 required=5 tests=[AWL=-1.558, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MANGLED_TOOL=2.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COZpgwpxzOPA; Fri, 22 Feb 2008 11:12:57 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 923823A6CCE; Fri, 22 Feb 2008 11:12:57 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 897AC28C36D for ; Fri, 22 Feb 2008 11:12:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mR9qCxVq3xh5 for ; Fri, 22 Feb 2008 11:12:51 -0800 (PST) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id 608DF28C3EF for ; Fri, 22 Feb 2008 11:12:02 -0800 (PST) Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Feb 2008 11:11:58 -0800 Message-ID: <47BF1E7D.1070308@azairenet.com> Date: Fri, 22 Feb 2008 11:11:57 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ryuji Wakikawa References: <47AC84E3.2030605@azairenet.com> <47BE0511.5010409@azairenet.com> In-Reply-To: X-OriginalArrivalTime: 22 Feb 2008 19:11:58.0245 (UTC) FILETIME=[CBA0F550:01C87586] Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] WGLC for draft-ietf-monami6-multiplecoa-05.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Ryuji Wakikawa wrote: > We should treat the lifetime of that home state and the other real > bindings separately. > > When the MN sends a BU with H flag set, it should not use bulk > registration and send it as an individual BU. > The lifetime field MUST be set to the appropriate lifetime for that home > state. > HA can always treat this BU as de-registration BU because the source > address and home address are same. > In addition to that, H flag can also tell this is deregistration BU. > MN should renew the home state while it is at the home link. > > If you are fine with this, I will prepare for additional texts. This would mean that a BU with the 'H' flag set is a special de-registration BU that deletes the binding cache entry but creates some special state that says certain flows can be delivered directly over the home link. What is the lifetime in this BU? How do we delete this state later on? Does the mobile node send a BU with lifetime set to 0 and 'H' flag set to '1'? This needs more discussion. It might be better not to add any text to the draft right now. >>> Beside the difference in the size of packets, there is no difference >>> between the two. The routing path does not get affected. With >>> extensions specified in this document, the mobile node is capable of >>> using multiple care-of addresses for outgoing packets. This is a >>> problem on the home agent side because it must verify the Care-of >>> address for all the packets received from the mobile node (i.e. >>> ingress filtering). When the mobile node uses the Home Address >>> option, the home agent MAY check the care-of address in the packet >>> with the registered binding entries. This causes additional overhead >>> to the home agent. Therefore, the mobile node SHOULD use the bi- >>> directional tunnel even if it registers a binding(s) to the home >>> agent. >>> GT> This confuses me a bit. Is there anything different from RFC3775? >>> Why is this section needed? > > > When MN establishes a tunnel with its HA and sends packets to the HA, > will MN should send packets with HoA option (RO) or IP-in-IP (non RO)? > RFC3775 does not clearly explain this. HA can be treated as a CN. > The way of address verification is slightly different between > packets sent with HoA option and with IP-in-IP. > >> I think it should be deleted. When packets are tunneled to the >> home agent, the home agent checks if the source address on the >> outer IPv6 header matches the care-of address in the binding >> cache entry. > > Most of implementation verifies the source address > with the tunnel states (Not with BC database) > >> The only exception is when the packet contains >> a binding update. So the sentence in the above paragraph is >> actually not valid. > > This check MUST be done with the binding cache database. > > > This paragraph is to explain how to avoid the overhead of the address > verification in MCoA. > > If the BC database is used for source address verification, > HA might search the BC database recursively to match the CoA and the > source address. > It is because BID (to match the exact BC) is not stored in the data > packets. > The cost can be O-(n) if 'n' bindings are registered. > > Therefore, HA should verify the address validity with the tunnel states. > HA can verify the packets with the tunnel states by comparing the source > and destination pair. > The cost can be decreased to O-(1). > > HA MUST check all the packets from MNs, this additional overhead of MCoA > is not negligible. > It might be implementation issue though. Ryuji, the mobile node uses the home address option for only the signaling messages that are sent to the home agent. I don't see that as a lot of traffic that needs an optimization in terms of source address check. I think we stick to what we have in RFC 3775 (i.e., the mobile node can either tunnel or send packets with home address option to the HA). We should not recommend one over the other in the MCoA draft. I still think we should delete this paragraph. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Feb 22 11:41:03 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2D4828C4FC; Fri, 22 Feb 2008 11:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[AWL=-1.032, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfFRhVnuXFUD; Fri, 22 Feb 2008 11:41:03 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1408E28CAD8; Fri, 22 Feb 2008 11:40:12 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8F8C28C282 for ; Fri, 22 Feb 2008 11:40:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dNfC+09v7kb for ; Fri, 22 Feb 2008 11:40:09 -0800 (PST) Received: from web54405.mail.yahoo.com (web54405.mail.yahoo.com [206.190.49.135]) by core3.amsl.com (Postfix) with SMTP id CF16528CBB8 for ; Fri, 22 Feb 2008 11:39:02 -0800 (PST) Received: (qmail 51345 invoked by uid 60001); 22 Feb 2008 19:38:58 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=kuDUQZuvxB+kHJn2BbrV56bXBUe6PCXMXN4x3REYqT+MuDQoZE7RrLMHLZUxB/r6/wbIvUK+81kFagqyma472f4perqoH1oPRglu8GTszdp1Y66jRmAstUPvIIHi/ZqMx0s263tMHZBiP8EGzeMBt7XHFIRAscEoiUIRJEw1d7c=; X-YMail-OSG: 4ubPkSAVM1kvYpEoNx_yhT8GLepgQl4tET_U6Q5ZAqdPnoJeGuGomBYLcmUuYAuJsrgDQ0X4kdGdipnvsfNXhgpvNtdIwFE1UI1OO3DnDtAgXIFouFHvmVrK6Ze0Fw-- Received: from [67.181.58.20] by web54405.mail.yahoo.com via HTTP; Fri, 22 Feb 2008 11:38:57 PST X-Mailer: YahooMailRC/818.31 YahooMailWebService/0.7.162 Date: Fri, 22 Feb 2008 11:38:57 -0800 (PST) From: "M. Vanderveen" To: Vijay Devarapalli MIME-Version: 1.0 Message-ID: <98953.50404.qm@web54405.mail.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] WGLC for draft-ietf-monami6-multiplecoa-05.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Vijay, Regarding switching the mobile operation from regular (RFC-3775 compliant) to mcoa compliant: there is a paragraph on page 7 explaining how to fall back on regular operation. It is not obvious to me what the operation should be in the other case, where the mobile was operating under RFC-3775 only, and had registered a CoA without a BID, but then later on decides to register additional CoAs (one of which may or may not be the original CoA) with BIDs. Perhaps this can be added to the following paragraph: "If there is an existing binding cache entry for the mobile node, and the if the BID in the Binding Update does not match the one with the existing entry, the home agent MUST create a new binding cache entry for the new care-of address and BID. " If the additional CoAs have BIDs, what is the HA to do with the original CoA that was not registered with a BID. Is this case even possible? Trivially, if one of the additional CoAs actually matches the original one, then that binding cache can be updated to include a BID. Not sure if the original CoA is not included in this later mcoa BU. Thanks Michaela ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Feb 22 12:02:07 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97DC428CBAA; Fri, 22 Feb 2008 12:02:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gd-K7F3bz+VB; Fri, 22 Feb 2008 12:02:07 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8987328C6D0; Fri, 22 Feb 2008 12:00:03 -0800 (PST) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7691C3A684C; Fri, 22 Feb 2008 12:00:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080222200001.7691C3A684C@core3.amsl.com> Date: Fri, 22 Feb 2008 12:00:01 -0800 (PST) Cc: mext@ietf.org Subject: [MEXT] I-D ACTION:draft-ietf-mext-nemo-ro-automotive-req-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-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 Mobility EXTensions for IPv6 Working Group of the IETF. Title : Automotive Industry Requirements for NEMO Route Optimization Author(s) : R. Baldessari, T. Ernst, M. Lenardi Filename : draft-ietf-mext-nemo-ro-automotive-req-00.txt Pages : 24 Date : 2008-2-18 This document specifies requirements for NEMO Route Optimization techniques as identified by the automotive industry. Requirements are gathered from the Car2Car Communication Consortium and ISO Technical Committee 204 Working Group 16 (CALM). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-ro-automotive-req-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-mext-nemo-ro-automotive-req-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 --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext --NextPart-- From mext-bounces@ietf.org Fri Feb 22 13:02:50 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6139D28C199; Fri, 22 Feb 2008 13:02:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbsH-vQcVfFn; Fri, 22 Feb 2008 13:02:49 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 414F628C293; Fri, 22 Feb 2008 13:02:49 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47F0628C374 for ; Fri, 22 Feb 2008 13:02:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRB6cRoutbaG for ; Fri, 22 Feb 2008 13:02:42 -0800 (PST) Received: from rutherford.zen.co.uk (rutherford.zen.co.uk [212.23.3.142]) by core3.amsl.com (Postfix) with ESMTP id 039E428C36D for ; Fri, 22 Feb 2008 13:01:54 -0800 (PST) Received: from [82.69.47.50] (helo=PC20005) by rutherford.zen.co.uk with esmtp (Exim 4.63) (envelope-from ) id 1JSf1g-0007VO-Rb; Fri, 22 Feb 2008 21:01:48 +0000 From: "Hesham Soliman" To: , Date: Sat, 23 Feb 2008 08:01:23 +1000 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: AchjOp+tBBZPPj39Q6+7x6ZGZVfkIgPvM+kgADG59NAAZIK0oA== X-Originating-Rutherford-IP: [82.69.47.50] Cc: julien.IETF@laposte.net Subject: Re: [MEXT] DSMIPv6 Security considerations section 5.1 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Pasi, Thanks for all the comments. Everything is in the text and I'll send it separately. A couple of responses below. > > Based on the setting of the K flag in the binding update, the > > home agent updates its IKE security association to include the > > tunnel header IP address as that received in the outer header of > > the binding update message. > > Hmm -- I guess this means that DSMIPv6 requires the HA to support > the K flag? (i.e. always set it in BAcks if it was set in BU?) > Is this requirement mentioned somewhere else in the spec? => I don't think we need to require this. We should continue with the 3775 philosophy. If the K flag is not supported then other means should be used to update the IKE SA, i.e. dynamic updates, or rerunning IKE. In many cases the updates to the IKE SA will need those messages anyway. Agree? > > Also, port number needs to be reset for non-NAT case. > > "If the Key Management Mobility Capability (K) bit was set in the > binding update, the home agent updates its IKE security > associations to include the mobile node's care-of address as the > peer address and 4500 as the port number." > > > The home agent may also need to change NAT traversal fields in > > the IKE_SA to enable the dyanmic update of the IP address and > > port number based on the reception of authenticated IKE messages, > > or authenticated packets using tunnel mode ESP. The dynamic > > updates are described in section 2.23 of RFC 4306. > > Ok. > > Add: > > "As described above, when the mobile node is located in a private > IPv4 network, the address and port number used for IPsec and IKE > traffic is not yet known by the home agent at this point." > > > Hence, the > > mobile node updates the IKE SA in one of two ways. If the K flag > > was set, > > "in the BAck"? (or is the HA required to support this?) => In the BA, I've corrected this. > > => I assume point 4) above is somewhat related to what we say > > about point 3). I read section 3.3 of RFC 4555 but I'm still > > unsure about what to say here. Are you recommending that we > > follow the same route as Mobike and use port 4500 if the MN and > > HA support it? > > > > In this case, I guess there is something to say about point 4) > > because 4500 is used even if there is no NAT. Otherwise, if we > > only use 4500 if a NAT is detected then it's obvious that we have > > to always send kepp alives on port 4500. Am I missing something? > > If you have suggested text for point 3) that would be great. > > Using port 4500 always (as MOBIKE does) would IMHO be simpler > than switching back and forth between ports 500 and 4500. => Ok, I guess this is implicit in your comments already. > > (BTW, if you have a temporary draft-of-draft version available > somewhere, I could take a quick look before the submission.) => I can't send it tonight but will send it to you offline on the weekend, feel free to let me know before the deadline if you have any comments. I'll have intermittend connectivity on Monday. Thanks for your help with this complex section! Hesham > > Best regards, > Pasi > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Feb 22 13:03:01 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF17028C429; Fri, 22 Feb 2008 13:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.545 X-Spam-Level: X-Spam-Status: No, score=-0.545 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvTlxzu1bhjP; Fri, 22 Feb 2008 13:03:01 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F412A28C2EB; Fri, 22 Feb 2008 13:02:58 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35F9D28C3C0 for ; Fri, 22 Feb 2008 13:02:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMY5rk44434P for ; Fri, 22 Feb 2008 13:02:51 -0800 (PST) Received: from rutherford.zen.co.uk (rutherford.zen.co.uk [212.23.3.142]) by core3.amsl.com (Postfix) with ESMTP id E7A5D28C402 for ; Fri, 22 Feb 2008 13:02:50 -0800 (PST) Received: from [82.69.47.50] (helo=PC20005) by rutherford.zen.co.uk with esmtp (Exim 4.63) (envelope-from ) id 1JSf2c-0007v9-9R; Fri, 22 Feb 2008 21:02:46 +0000 From: "Hesham Soliman" To: , Date: Sat, 23 Feb 2008 08:02:21 +1000 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: AchjOp+tBBZPPj39Q6+7x6ZGZVfkIgPvM+kgADG59NAAeAvLQA== X-Originating-Rutherford-IP: [82.69.47.50] Cc: julien.IETF@laposte.net Subject: [MEXT] Updated text- DSMIPv6 Security considerations section 5.1 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Here is the updated section. After the mobile node detects movement it configures a new care-of address. If the mobile node is in an IPv4-only network, it removes binding update list entries for correspondent nodes since route optimisation cannot be supported. This may cause inbound packet losses as remote correspondent node are unaware of such movement. To avoid confusion in the correspondent node, the mobile node SHOULD deregister its binding with each correspondent node by sending a deregistration binding update. The deregistration binding update message is tunnelled to the home agent and onto the correspondent node. This is done after the mobile node updates the home agent with its new location as discussed below. The mobile node sends the binding update message to the home agent. If the mobile node is in an IPv6-enabled network, the binding update is sent without IPv4/UDP encapsulation. If the mobile node is in an IPv4-only network, then after IPsec processing of the BU message, it encapsulates the BU in UDP/IPv4 as discussed in sections 4.2 and 4.4. In order to be able to send the binding update while in an IPv4-only network, the mobile node needs to use the new IPv4 care-of address in the outer header, which is different from the care-of address used in the existing tunnel. This should be done without permanently updating the tunnel within the mobile node's implementation in order to allow the mobile node to receive packets on the old care-of address until the binding acknowledgement is received. The method used to achieve this effect is implementation dependent and is outside the scope of this specification. This implies that the IP forwarding function (which selects the interface or tunnel through which a packet is sent) is not based solely on the destination address: some IPv6 packets destined to the home agent are sent via the existing tunnel, while BUs are sent using the new care-of address. Since BUs are protected by IPsec, the forwarding function cannot necessarily determine the correct treatment from the packet headers. Thus, the DSMIPv6 implementation has to attach additional information to BUs, and this information has to be preserved after IPsec processing and made available to the forwarding function, or additional DSMIP processing added to the forwarding function. Depending on the mobile node's implementation, meeting this requirement may require changes to the IPsec implementation. Upon receiving the binding update message encapsulated in UDP/IPv4, the home agent processes it as follows. In order to allow the DSMIPv6 implementation in the home agent to detect the presence of a NAT on the path to the mobile node, it needs to compare the outer IPv4 source address with the IPv4 address in the alt-care-of address option. This implies that the information in the outer header will be preserved after IPsec processing and made available to the DSMIPv6 implementation in the home agent. Depending on the home agent's implementation, meeting this requirement may require changes to the IPsec implementation. The home agent updates its tunnel mode security association to include the mobile node's care-of address as the remote tunnel header address, and 4500 as the port number. If the mobile node were located in a private IPv4 network the address and port number are likely to be wrong as the NAT would likely allocate a different address and port number to traffic encapsulated in IPsec tunnels or to IKE messages; the mobile node provides the correct information in a separate exchange as described below.When the mobile node is located in a private IPv4 network (which is detected as described above), the new address and port number are allocated by the NAT. If the Key Management Mobility Capability (K) bit was set in the binding update, the home agent updates its IKE security associations to include the mobile node's care-of address as the peer address and 4500 as the port number. The home agent may also need to change NAT traversal fields in the IKE_SA to enable the dyanmic update of the IP address and port number based on the reception of authenticated IKE messages, or authenticated packets using tunnel mode ESP. The dynamic updates are described in section 2.23 of RFC 4306. As described above, when the mobile node is located in a private IPv4 network, the address and port number used for IPsec and IKE traffic is not yet known by the home agent at this point. The home agent will also enable or disable UDP encapsulation for outgoing ESP packets for the purpose of NAT traversal. The mobile node updates the IKE SA in one of two ways. If the K flag was set in the binding acknowledgement message, the mobile node SHOULD send an empty informational message, which results in the IKE module in the home agent to dynamically update the SA information. The IKE implementation in the home agent is REQUIRED to support this feature. Alternatively, the IKE SA should be re-negotiated. Note that updating the IKE SA MUST take place after the mobile node has sent the binding update and received the acknowledgement from the home agent. It is important to note that if the mobile node is located behind a NAT, its IPv4 care-of address seen by the DSMIPv6 module in the home agent upon receiving the binding update will differ from the IPv4 care-of address seen by the IKE module and the care-of address used for forwarding IPsec tunnel mode traffic. This is due to the fact that the NAT will probably allocate a different IP address and port number to each traffic stream. Hence, it is probable that different modules in the home agent will have a different care-of address that should be used for encapsulating traffic to the mobile node. After successfully processing the binding update, the home agent sends the binding acknowledgement to the mobile node's care-of address as received in the outer header of the packet containing the binding update. Note that if the BU was rejected, the BAck is sent to the same address where the BU was received from. This may require special treatment in IP forwarding and/or IPsec processing which resembles sending of BUs in the mobile node (described above). Upon receiving the binding acknowledgement the mobile node updates its local tunnel mode Security Association information to include the tunnel header IP source address, which is the the home agent's address and the tunnel header IP destination, which is the mobile node's care-of address. The mobile node may also need to enable or disable UDP encapsulation for outgoing ESP packets for the purpose of NAT traversal and the sending of keep alives. The mobile node MAY use [MOBIKE] to update its IKE SA with the home agent. Using MOBIKE requires negotiating this capability with the home agent when establishing the SA. In this case, the mobile node and the home agent MUST NOT update their IPsec SAs locally as this step is performed by MOBIKE. Furthermore, the use of MOBIKE allows the mobile node to update the SA independently of the binding update exchange. Hence, there is no need for the mobile node to wait for a binding acknowledgement before performing MOBIKE. The use of MOBIKE is OPTIONAL in this specification. _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Feb 22 21:42:45 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 871993A6988; Fri, 22 Feb 2008 21:42:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.244 X-Spam-Level: X-Spam-Status: No, score=0.244 tagged_above=-999 required=5 tests=[AWL=-1.619, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MANGLED_TOOL=2.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ashiR-aN15yX; Fri, 22 Feb 2008 21:42:44 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62B2F3A6951; Fri, 22 Feb 2008 21:42:44 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9E753A67E6 for ; Fri, 22 Feb 2008 21:42:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKgGzVjEpaOL for ; Fri, 22 Feb 2008 21:42:41 -0800 (PST) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.188]) by core3.amsl.com (Postfix) with ESMTP id 818793A6951 for ; Fri, 22 Feb 2008 21:42:41 -0800 (PST) Received: by rv-out-0910.google.com with SMTP id l15so391988rvb.49 for ; Fri, 22 Feb 2008 21:42:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; bh=r5KQQFlwdLO28Dec45vf/aM8+/EmahajXj/hoasMuBk=; b=TW83AsdgaxOzGwkqpQuOwVmaRM0oE71paY2cQxMNlcrJnbmahNrfcLL0v3TSVIq8hQ1bgU0+tgt+SNgcHflNtMaXP9MKG3+tDLS/ODiMEUIEukxGQnofLlLmODeeg7rrLz41x2rdnzkGBERlM1iwX9oHqcbM4SLl9bi15viHKCQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; b=vzVj6nURmkmQBRvhqPu3rJpeHnDsusQ6jCg1Z/tS9dPd6asUvJ35vHvnz+Pc4o2lhDajM1HeDvJrWia54cn+JOukjhqmGLkuZHpPuzBCCCXBMI7CkOXZUt7FmhAKMyppSKUgywlGUem4lBcW0//yPzhToL5ylwWzRzqIVhtMSX4= Received: by 10.140.193.16 with SMTP id q16mr10261rvf.173.1203745356388; Fri, 22 Feb 2008 21:42:36 -0800 (PST) Received: from dhcp-143-220.sfc.wide.ad.jp ( [203.178.143.220]) by mx.google.com with ESMTPS id c19sm5222902rvf.30.2008.02.22.21.42.33 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Feb 2008 21:42:34 -0800 (PST) From: RYUJI WAKIKAWA To: Vijay Devarapalli In-Reply-To: <47BF1E7D.1070308@azairenet.com> References: <47AC84E3.2030605@azairenet.com> <47BE0511.5010409@azairenet.com> <47BF1E7D.1070308@azairenet.com> Message-Id: <71BB702D-A4F7-483A-BD0C-AA91AB13799F@gmail.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sat, 23 Feb 2008 14:42:31 +0900 X-Mailer: Apple Mail (2.919.2) Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] WGLC for draft-ietf-monami6-multiplecoa-05.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Vijay, On 2008/02/23, at 4:11, Vijay Devarapalli wrote: > Ryuji Wakikawa wrote: > >> We should treat the lifetime of that home state and the other real >> bindings separately. >> When the MN sends a BU with H flag set, it should not use bulk >> registration and send it as an individual BU. >> The lifetime field MUST be set to the appropriate lifetime for that >> home state. >> HA can always treat this BU as de-registration BU because the >> source address and home address are same. >> In addition to that, H flag can also tell this is deregistration BU. >> MN should renew the home state while it is at the home link. >> If you are fine with this, I will prepare for additional texts. > > This would mean that a BU with the 'H' flag set is a special > de-registration BU that deletes the binding cache entry but > creates some special state that says certain flows can be > delivered directly over the home link. What is the lifetime > in this BU? The H-flag indicates to HA that MN is at home. The state is not something link binding cache. I mean that state is the information of MN existence at the home link. When MN sends de-registration BU with H flag, HA will start special operation for that MN. > How do we delete this state later on? Does the mobile node > send a BU with lifetime set to 0 and 'H' flag set to '1'? > This needs more discussion. It might be better not to add > any text to the draft right now. right. If HA can detect the MN's existence at the home link without any states, we don't need this operation. HA can delete the state as soon as MR leaves the home link. >>>> Beside the difference in the size of packets, there is no >>>> difference >>>> between the two. The routing path does not get affected. With >>>> extensions specified in this document, the mobile node is >>>> capable of >>>> using multiple care-of addresses for outgoing packets. This is a >>>> problem on the home agent side because it must verify the Care-of >>>> address for all the packets received from the mobile node (i.e. >>>> ingress filtering). When the mobile node uses the Home Address >>>> option, the home agent MAY check the care-of address in the packet >>>> with the registered binding entries. This causes additional >>>> overhead >>>> to the home agent. Therefore, the mobile node SHOULD use the bi- >>>> directional tunnel even if it registers a binding(s) to the home >>>> agent. >>>> GT> This confuses me a bit. Is there anything different from >>>> RFC3775? >>>> Why is this section needed? >> When MN establishes a tunnel with its HA and sends packets to the HA, >> will MN should send packets with HoA option (RO) or IP-in-IP (non >> RO)? >> RFC3775 does not clearly explain this. HA can be treated as a CN. >> The way of address verification is slightly different between >> packets sent with HoA option and with IP-in-IP. >>> I think it should be deleted. When packets are tunneled to the >>> home agent, the home agent checks if the source address on the >>> outer IPv6 header matches the care-of address in the binding >>> cache entry. >> Most of implementation verifies the source address >> with the tunnel states (Not with BC database) >>> The only exception is when the packet contains >>> a binding update. So the sentence in the above paragraph is >>> actually not valid. >> This check MUST be done with the binding cache database. >> This paragraph is to explain how to avoid the overhead of the >> address verification in MCoA. >> If the BC database is used for source address verification, >> HA might search the BC database recursively to match the CoA and >> the source address. >> It is because BID (to match the exact BC) is not stored in the data >> packets. >> The cost can be O-(n) if 'n' bindings are registered. >> Therefore, HA should verify the address validity with the tunnel >> states. >> HA can verify the packets with the tunnel states by comparing the >> source and destination pair. >> The cost can be decreased to O-(1). >> HA MUST check all the packets from MNs, this additional overhead of >> MCoA is not negligible. >> It might be implementation issue though. > > Ryuji, the mobile node uses the home address option for only > the signaling messages that are sent to the home agent. > I don't see that as a lot of traffic that needs an optimization > in terms of source address check. How can you say so? RFC3775 does support tunneled packets and RO-packets between MN and HA. If we can fix to use either tunnel or hoa option for data packets in RFC3775-bis, i am fine to remove this text. > I think we stick to what we > have in RFC 3775 (i.e., the mobile node can either tunnel > or send packets with home address option to the HA). We > should not recommend one over the other in the MCoA draft. I > still think we should delete this paragraph. OK. I think we should discuss this possible issue in the 3775-bis discussion. I don't see any strong reasons to have two way to send packets from MN to HA. ryuji > Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From angus39fermin1@fujitsu.com Sun Feb 24 03:22:40 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 157783A6945 for ; Sun, 24 Feb 2008 03:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.458 X-Spam-Level: X-Spam-Status: No, score=-5.458 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_RELAY_NODNS=1.451, GB_ROLEX=5, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_TR=0.935, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, SARE_SPEC_ROLEX=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yCt8CDAI4Fn for ; Sun, 24 Feb 2008 03:22:39 -0800 (PST) Received: from dsl88-246-36481.ttnet.net.tr (unknown [88.246.142.129]) by core3.amsl.com (Postfix) with ESMTP id 0DD1D3A67CF for ; Sun, 24 Feb 2008 03:21:44 -0800 (PST) Message-ID: <000601c876d7$067e97f2$5ccf068c@qckhg> From: "lem lindsay" To: "Fay Parks" Subject: exclusive watches, brand name quality rolex Date: Sun, 24 Feb 2008 09:34:12 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 The finest of luxury timepieces!! At the LOWEST prices... http://fetalphysicalfin.com/ From mext-bounces@ietf.org Sun Feb 24 08:58:59 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38A1928C412; Sun, 24 Feb 2008 08:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.653 X-Spam-Level: X-Spam-Status: No, score=-0.653 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMetJfw5wmP2; Sun, 24 Feb 2008 08:58:58 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 658073A6A7C; Sun, 24 Feb 2008 08:58:57 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FAA03A6C42 for ; Sun, 24 Feb 2008 08:58:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJem80vPgIRi for ; Sun, 24 Feb 2008 08:58:46 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id A7CCE3A6BF9 for ; Sun, 24 Feb 2008 08:58:38 -0800 (PST) Received: from [212.214.188.66] (helo=PC20005) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1JTKBK-0001NO-QI; Mon, 25 Feb 2008 03:58:31 +1100 From: "Hesham Soliman" To: "'Acee Lindem'" , Date: Mon, 25 Feb 2008 03:58:00 +1000 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcheiDxI2YiNx2K5S6+PE1ZnJEdeFgYhIHTA In-Reply-To: <9014772B-8AD0-4291-B28A-548CD0DBD6B3@lindem.com> Subject: Re: [MEXT] I-D ACTION:draft-ietf-mext-nemo-v4traversal-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I've updated the draft with your comment, a couple of responses below though. > > - Page 8, 1st paragraph - It says "If this option is not > including..." yet > it said previously that the option "MUST" be included. > Perhaps, the "MUST" > should have been a "MAY". => No I think the MUST is correct. The rest of the sentence explains why the option would not be included despite the "MUST". > > - Page 9, second paragraph - Replace "to the IPv4 care-of > address." with > "in an IPv4 header specifying the IPv4 care-of > address as the > destination." => I replaced it with " to the IPv4 care-of address, which was included in the source address of the IPv4 header encapsulating the binding update". > - Page 11, IPv4 home address - It says "should be defended by > the home agent". This > terminology is usually associated for IPv6 Duplicate Address > Detection. What > does it mean for IPv4? => It's the same thing that an IPv4 HA does, I don't see anything specific to v6. > > - Page 20, 4th bullet - It says "mobile node MAY include the > IPv4 home...". Yet in > section 2.3.1 on the top of page 8, it says > "therefore SHOULD > NOT include the > option...". => Yes for a completely different reason. In page 8 it talks about a missing option, in page 20 it talks about a present option that indicates an error in allocation. > - Page 26, IANA Assignments - Should there be a new > registry for > TLV-Header > encapsulations types? => Sadly yes but I think it needs IETF concensus. Thanks for your comments, Hesham _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Feb 24 11:33:30 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABF0F3A6C6C; Sun, 24 Feb 2008 11:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.671 X-Spam-Level: X-Spam-Status: No, score=-0.671 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDA+WStu-Kga; Sun, 24 Feb 2008 11:33:29 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8009C3A6AE6; Sun, 24 Feb 2008 11:33:29 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4F703A6AE6 for ; Sun, 24 Feb 2008 11:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i87Jq2EZ7YZa for ; Sun, 24 Feb 2008 11:33:26 -0800 (PST) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id DA63228C15B for ; Sun, 24 Feb 2008 11:33:26 -0800 (PST) Received: from [127.0.0.1] ([98.207.82.216]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sun, 24 Feb 2008 11:33:21 -0800 Message-ID: <47C1C67F.8040804@azairenet.com> Date: Sun, 24 Feb 2008 11:33:19 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Julien Laganier References: <47B36D00.8020707@azairenet.com> <200802141724.48978.julien.IETF@laposte.net> <47B48A76.3090007@azairenet.com> <200802191758.18464.julien.IETF@laposte.net> In-Reply-To: <200802191758.18464.julien.IETF@laposte.net> X-OriginalArrivalTime: 24 Feb 2008 19:33:21.0555 (UTC) FILETIME=[1D5E0630:01C8771C] Cc: mext@ietf.org Subject: Re: [MEXT] Home Link operation over p2p links X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien, Sorry for the delay in my response. Julien Laganier wrote: > Hi Vijay, > > On Thursday 14 February 2008, Vijay Devarapalli wrote: >> Hi Julien, >> >> Thanks for reviewing the document. A few high level comments >> first. >> >> - When the home agent receives a Binding Update from a mobile >> node on the home link, it is treated as a de-registration BU. >> This is according to RFC 3775 and has not been updated by any >> spec. When the home agent receives this BU from the mobile >> node, if it does not have a valid binding cache entry, it >> responds with the status 133 (Not home agent for this mobile >> node) in the binding ack. When the mobile node boots up in >> the point-to-point home link, the home agent does not have a >> valid binding cache entry for the mobile node. The DS-MIPv6 >> IPv4 home address and Mobile Network prefixes will not be >> sent in the binding ack, since the Binding Update is seen as >> a failed one. This is one of the reasons why we introduced a >> new flag in the Binding Update. > > You're right. I overlooked that fact. But anyway if you conclude you're > home from the IKEv2 exchange (because the INTERNAL_IP6_ADDRESS either > fits in the prefix advertized from RAs or is in the same prefix that > the "external" address the node configured on the home link), The INTERNAL_IP6_ADDRESS configuration payload does not carry the prefix length in it. Just the 128-bit address. An address "fitting" in a prefix is not sufficient to conclude you are at home. Having said, the mobile node can use the IKEv2 exchange to figure out if it is at home. RFC 5026 defines a new configuration payload attribute called the MIP6_HOME_PREFIX attribute. This can be used to obtain the home prefix. > why would > you need to send a BU. The draft tries to analyze all the issues, figuring out you are attached to the home link, associating the address you obtain via the p2p link mechanism with the MIPv6 virtual interface, bootstrapping parameters that are obtained as part of the BU/BAck transfer, etc... > The IPv4 home address could be obtained from DCHPv4 (one could also > think it comes thru an INTERNAL_IP4_ADDRESS in the IKEv2 exchange but > let's not digress :) > > The mobile network prefix can come from DHCPv6 PD. Yes, all these are possible. >> - I am aware of Pasi's draft on making IPsec tunnels look like >> regular IPv6 links. It might be a good idea, but the problem is >> that this draft has no "home" right now. Not sure if it will >> get standardized in the time frame we are looking at. Some of >> the architectures quoted in the draft are supposed to be >> finalized this year. > > While I completely agree it is important to get specifications needed by > SDOs relying on IETF protocols out in a timely fashion, as a general > principle I do not think we should base protocol design decision on > time constraints. Having a spec completed in the IETF is different from getting the IPsec vendors to implement it any time soon. > This can be debated of course :) Yes, but over beer. :) >> - Regarding the mobile router using DHCPv6 prefix delegation >> to acquire the mobile network prefixes when at home, there are >> some issues. Since the mobile router is reachable only over the >> p2p link, the home agent becomes the default router where all >> the packets meant for the mobile router's mobile network >> prefixes arrive. The home agent according to RFC 3963 does not >> create forwarding entries for the mobile router prefixes until >> it receives a Binding Update from the mobile router with the >> prefixes in the message. The home agent does not advertise >> reachability for the mobile network prefixes either until >> there is a valid binding cache entry for the mobile router. > > When at home, why couldn't the mobile network prefix comes directly out > of DHCPv6 PD, without BU. When a network prefix is delegated to a > router, presumably forwarding entries for that prefix pointing to that > router comes in place. Not if the mobile router is on the home link. Anyway, I don't think a DHCPv6 relay (that is on the home agent) creates forwarding entries for the mobile network prefix delegated to the mobile router. You still need a BU for setting up forwarding. >>> In conclusion I am not sure there's a clear case to extend MIPv6. >>> Maybe there's some room for a document clarifying how >>> implementation should behave with bootstrapping while on the home >>> link. >>> >>> What do you think? Even if we conclude that we don't need to extend the Binding Update with a flag, I would like us to work on a document that describes how the mobile node boots up on a p2p link attached to the home agent and concludes that it is on the home link. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Feb 24 12:25:00 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 346C128C1C1; Sun, 24 Feb 2008 12:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.66 X-Spam-Level: X-Spam-Status: No, score=-0.66 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvVVg-9H0jdh; Sun, 24 Feb 2008 12:24:59 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42D983A6A37; Sun, 24 Feb 2008 12:24:59 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22ADB3A6A37 for ; Sun, 24 Feb 2008 12:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPAR4AKdY9Co for ; Sun, 24 Feb 2008 12:24:57 -0800 (PST) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id 77D9E3A69DC for ; Sun, 24 Feb 2008 12:24:57 -0800 (PST) Received: from [127.0.0.1] ([98.207.82.216]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sun, 24 Feb 2008 12:24:52 -0800 Message-ID: <47C1D291.2040705@azairenet.com> Date: Sun, 24 Feb 2008 12:24:49 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: mext@ietf.org References: <47B36D00.8020707@azairenet.com> In-Reply-To: <47B36D00.8020707@azairenet.com> X-OriginalArrivalTime: 24 Feb 2008 20:24:52.0323 (UTC) FILETIME=[4F9BCB30:01C87723] Subject: Re: [MEXT] Home Link operation over p2p links X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello, I updated the document to include a paragraph explaining that the home agent treats the BU sent from the home link, when the mobile node boots up, as a de-registration BU and responds with status '133' in the binding ack. http://www.ietf.org/internet-drafts/draft-devarapalli-mext-mipv6-home-link-01.txt Vijay Vijay Devarapalli wrote: > Hello folks, > > Here is a draft that describes issues with the mobile node > booting up on the home link over point-to-point links. It > describes the issues and suggests a possible solution. > > http://www.ietf.org/internet-drafts/draft-devarapalli-mext-mipv6-home-link-00.txt > > Comments/reviews are welcome. > > Vijay > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Feb 24 13:00:06 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4CEF28C46E; Sun, 24 Feb 2008 13:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2t+x5hOI98k; Sun, 24 Feb 2008 13:00:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF54328C21B; Sun, 24 Feb 2008 13:00:04 -0800 (PST) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1C2023A6A37; Sun, 24 Feb 2008 13:00:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080224210002.1C2023A6A37@core3.amsl.com> Date: Sun, 24 Feb 2008 13:00:02 -0800 (PST) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-monami6-multiplecoa-06.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-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 Mobility EXTensions for IPv6 Working Group of the IETF. Title : Multiple Care-of Addresses Registration Author(s) : T. Ernst, et al. Filename : draft-ietf-monami6-multiplecoa-06.txt Pages : 42 Date : 2008-02-24 According to the current Mobile IPv6 specification, a mobile node may have several care-of addresses, but only one, called the primary care-of address, that can be registered with its home agent and the correspondent nodes. However, for matters of cost, bandwidth, delay, etc, it is useful for the mobile node to get Internet access through multiple accesses simultaneously, in which case the mobile node would be configured with multiple active IPv6 care-of addresses. This document proposes extensions to the Mobile IPv6 protocol to register and use multiple care-of addresses. The extensions proposed in this document can be used by Mobile Routers using the NEMO (Network Mobility) Basic Support protocol as well. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-06.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-monami6-multiplecoa-06.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-monami6-multiplecoa-06.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: <2008-02-24125139.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-monami6-multiplecoa-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-monami6-multiplecoa-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-24125139.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext --NextPart-- From mext-bounces@ietf.org Sun Feb 24 18:15:04 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA01428C25E; Sun, 24 Feb 2008 18:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5Fq+CuqQtQt; Sun, 24 Feb 2008 18:15:02 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD0083A6891; Sun, 24 Feb 2008 18:15:02 -0800 (PST) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EDF343A687E; Sun, 24 Feb 2008 18:15:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080225021501.EDF343A687E@core3.amsl.com> Date: Sun, 24 Feb 2008 18:15:01 -0800 (PST) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-aero-reqs-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-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 Mobility EXTensions for IPv6 Working Group of the IETF. Title : NEMO Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks Author(s) : W. Eddy, et al. Filename : draft-ietf-mext-aero-reqs-01.txt Pages : 27 Date : 2008-02-24 This document describes the requirements and desired properties of NEMO Route Optimization techniques for use in global networked communications systems for aeronautics and space exploration. This version has been reviewed by members of the International Civil Aviation Orgnanization (ICAO) and other aeronautical communications standards bodies, and contributed to by a number of aeronautical communications experts outside the normal IETF process. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-aero-reqs-01.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-mext-aero-reqs-01.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-mext-aero-reqs-01.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: <2008-02-24180112.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mext-aero-reqs-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mext-aero-reqs-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-24180112.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext --NextPart-- From mext-bounces@ietf.org Sun Feb 24 23:33:49 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0F6D28C27B; Sun, 24 Feb 2008 23:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[AWL=-0.670, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZGf7Gdi9PpP; Sun, 24 Feb 2008 23:33:48 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 529653A69AD; Sun, 24 Feb 2008 23:33:48 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B916328C1D2 for ; Sun, 24 Feb 2008 23:33:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 619wO25r7xSe for ; Sun, 24 Feb 2008 23:33:46 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 699DC28C2A7 for ; Sun, 24 Feb 2008 23:32:52 -0800 (PST) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1P7WRL1018882; Mon, 25 Feb 2008 09:32:35 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 09:32:08 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 09:32:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Feb 2008 09:32:06 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] DSMIPv6 Security considerations section 5.1 Thread-Index: AchjOp+tBBZPPj39Q6+7x6ZGZVfkIgPvM+kgADG59NAAZIK0oACL6BuA References: From: To: , X-OriginalArrivalTime: 25 Feb 2008 07:32:08.0328 (UTC) FILETIME=[86ED5880:01C87780] X-Nokia-AV: Clean Subject: Re: [MEXT] DSMIPv6 Security considerations section 5.1 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hesham Soliman wrote: > > Hmm -- I guess this means that DSMIPv6 requires the HA to support > > the K flag? (i.e. always set it in BAcks if it was set in BU?) > > Is this requirement mentioned somewhere else in the spec? > > => I don't think we need to require this. We should continue with > the 3775 philosophy. If the K flag is not supported then other means > should be used to update the IKE SA, i.e. dynamic updates, or > rerunning IKE. In many cases the updates to the IKE SA will need > those messages anyway. Agree? I'm OK with not requiring the K flag, but then the text needs to describe both cases (in the previous version there was some text that IMHO seemed to assume that K flag is always supported -- but I haven't checked the latest text yet). Best regards, Pasi _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Feb 25 04:40:50 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6330028C410; Mon, 25 Feb 2008 04:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.336 X-Spam-Level: X-Spam-Status: No, score=-0.336 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 976Ax8JTyvQI; Mon, 25 Feb 2008 04:40:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D8AB3A6BBB; Mon, 25 Feb 2008 04:40:46 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 557CC3A6BBB for ; Mon, 25 Feb 2008 04:40:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id altdNVFaRLXE for ; Mon, 25 Feb 2008 04:40:44 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.188]) by core3.amsl.com (Postfix) with ESMTP id DAEA83A69CE for ; Mon, 25 Feb 2008 04:40:43 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id i7so1376219tid.25 for ; Mon, 25 Feb 2008 04:40:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:user-agent:cc:mime-version:content-disposition:date:content-type:content-transfer-encoding:message-id:sender; bh=JXNOEHZDDByRK9jwEvFHy+9FpkQwSW9zVTUiikUgiVw=; b=kt2YI5gD9cC4snEUGN8D2TS8YbHPiA5JS+xEBN3LITChA314I7uSw0LzL3sa3Oft9XV10DKlYUcjey+WGkj8BwVFFMrpMsB+nGvcivwSyGAqMFQG6JuTh6Il+IZGWAncoUsCUD7bO9DP0trC83YvPwzmsDZM9DVlDhOYi9IVBWM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:user-agent:cc:mime-version:content-disposition:date:content-type:content-transfer-encoding:message-id:sender; b=Qku8NqW+2N9DDcY8MGn1g9QOzefCvR3pkJkJZSLzelM4jPUPrl45Z6+2/AsRv0CmBIHwfYnSPYoGiR5AAb94Kx5ViH1bFT1patm6Ip5b9cjaXc8U6G5BvmyhFo6jof2D2tclMo0A2kQhcsGH1SpwVKgRl+t/XIWI7FeA8Hjf3RQ= Received: by 10.150.53.2 with SMTP id b2mr1061451yba.110.1203943234663; Mon, 25 Feb 2008 04:40:34 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id d24sm215798nfh.22.2008.02.25.04.40.31 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Feb 2008 04:40:33 -0800 (PST) From: Julien Laganier To: mext@ietf.org User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) MIME-Version: 1.0 Content-Disposition: inline Date: Mon, 25 Feb 2008 13:41:04 +0100 Message-Id: <200802251341.06025.julien.IETF@laposte.net> Cc: draft-ietf-mext-aero-reqs@tools.ietf.org Subject: [MEXT] [WGLC] draft-ietf-mext-aero-reqs-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Folks, Hereby we're issuing a WGLC for draft-ietf-mext-aero-reqs-01 This is a 2 weeks WGLC that will last until Monday, March 10th. We = kindly ask the WG to review the last changes that were made and provide = comments if needed. If you have no comments and think the document is ready to be submitted = to IESG, please do send a note stating that to the WG ML. Additional information about the document is below: =A0=A0=A0=A0=A0=A0=A0=A0Title =A0 =A0 =A0 =A0 =A0 : NEMO Route Optimization= Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks =A0=A0=A0=A0=A0=A0=A0=A0Author(s) =A0 =A0 =A0 : W. Eddy, et al. =A0=A0=A0=A0=A0=A0=A0=A0Filename =A0 =A0 =A0 =A0: draft-ietf-mext-aero-reqs= -01.txt =A0=A0=A0=A0=A0=A0=A0=A0Pages =A0 =A0 =A0 =A0 =A0 : 27 =A0=A0=A0=A0=A0=A0=A0=A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2008-02-24 This document describes the requirements and desired properties of NEMO Route Optimization techniques for use in global networked communications systems for aeronautics and space exploration. This version has been reviewed by members of the International Civil Aviation Orgnanization (ICAO) and other aeronautical communications standards bodies, and contributed to by a number of aeronautical communications experts outside the normal IETF process. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-aero-reqs-01.txt Thank you for your support. --julien and marcelo, MEXT chairs _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Feb 25 05:56:44 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF17D28C678; Mon, 25 Feb 2008 05:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.404 X-Spam-Level: * X-Spam-Status: No, score=1.404 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_ORG=0.611, MANGLED_TOOL=2.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KLUNeXazJ8z; Mon, 25 Feb 2008 05:56:44 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82E3928C669; Mon, 25 Feb 2008 05:51:03 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66ECF28C66E for ; Mon, 25 Feb 2008 05:51:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1g9O3awh5qSU for ; Mon, 25 Feb 2008 05:50:55 -0800 (PST) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.189]) by core3.amsl.com (Postfix) with ESMTP id 47CEB28C631 for ; Mon, 25 Feb 2008 05:48:44 -0800 (PST) Received: by gv-out-0910.google.com with SMTP id i36so469144gve.15 for ; Mon, 25 Feb 2008 05:48:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=pbFWJXiqb/yVM6/S4XotIm6x4IlncW+PcW05ERi1W5Q=; b=rk5nWqaids74WAychUy9+3vM+S0RY8eJPUdYlMY63u7B+WXpBi3yYpqiWWIf6EzqbP0dMOSuaFNsDSnrP98cdRqDJYl9XQAi+82R5DsAULqAtsk9hEYfYXOSieo8fJiZMkvcuKAWYU8trrJ7yo7mJWEvpMYCXOUt02TUjMd9vHQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=t00jbxFN4NqWT8pYtpziHb5esX6EkpVYoFVMwjz9ijavmq6jfeoUKkZ+fIZJ07xZVvTByWwBOIBYMl2Yq08HyzqYc5wbVlfuuwoSFy6oUDF7DYY7yrFn8wtFJ2398IbYzOL8vhjPgL8SPrkSA0h7TiwwGW9yWOPnBYWZHGzGn/Q= Received: by 10.142.240.9 with SMTP id n9mr2239194wfh.79.1203947315864; Mon, 25 Feb 2008 05:48:35 -0800 (PST) Received: by 10.142.177.9 with HTTP; Mon, 25 Feb 2008 05:48:35 -0800 (PST) Message-ID: Date: Mon, 25 Feb 2008 13:48:35 +0000 From: "George Tsirtsis" To: "RYUJI WAKIKAWA" In-Reply-To: <71BB702D-A4F7-483A-BD0C-AA91AB13799F@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <47AC84E3.2030605@azairenet.com> <47BE0511.5010409@azairenet.com> <47BF1E7D.1070308@azairenet.com> <71BB702D-A4F7-483A-BD0C-AA91AB13799F@gmail.com> Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] WGLC for draft-ietf-monami6-multiplecoa-05.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Vijay/Ryuji, Thanks again for revising the document. I have not read the latest version yet but by looking at your replies I think we are getting there. A few issues, however, still remain which you indicate in your e-mails. Would it be possible to summarize these separately so we can resolve them? Anything we can not resolve on the list we can then discuss in the IETF meeting; hopefully you have requested a slot for this? In the mean time I will also try to go over the new draft. Thanks again George On Sat, Feb 23, 2008 at 5:42 AM, RYUJI WAKIKAWA wrote: > Hi Vijay, > > > On 2008/02/23, at 4:11, Vijay Devarapalli wrote: > > > Ryuji Wakikawa wrote: > > > >> We should treat the lifetime of that home state and the other real > >> bindings separately. > >> When the MN sends a BU with H flag set, it should not use bulk > >> registration and send it as an individual BU. > >> The lifetime field MUST be set to the appropriate lifetime for that > >> home state. > >> HA can always treat this BU as de-registration BU because the > >> source address and home address are same. > >> In addition to that, H flag can also tell this is deregistration BU. > >> MN should renew the home state while it is at the home link. > >> If you are fine with this, I will prepare for additional texts. > > > > This would mean that a BU with the 'H' flag set is a special > > de-registration BU that deletes the binding cache entry but > > creates some special state that says certain flows can be > > delivered directly over the home link. What is the lifetime > > in this BU? > > The H-flag indicates to HA that MN is at home. > The state is not something link binding cache. > I mean that state is the information of MN existence at the home link. > When MN sends de-registration BU with H flag, HA will start special > operation for that MN. > > > > How do we delete this state later on? Does the mobile node > > send a BU with lifetime set to 0 and 'H' flag set to '1'? > > This needs more discussion. It might be better not to add > > any text to the draft right now. > > right. > If HA can detect the MN's existence at the home link without any states, > we don't need this operation. > HA can delete the state as soon as MR leaves the home link. > > > > >>>> Beside the difference in the size of packets, there is no > >>>> difference > >>>> between the two. The routing path does not get affected. With > >>>> extensions specified in this document, the mobile node is > >>>> capable of > >>>> using multiple care-of addresses for outgoing packets. This is a > >>>> problem on the home agent side because it must verify the Care-of > >>>> address for all the packets received from the mobile node (i.e. > >>>> ingress filtering). When the mobile node uses the Home Address > >>>> option, the home agent MAY check the care-of address in the packet > >>>> with the registered binding entries. This causes additional > >>>> overhead > >>>> to the home agent. Therefore, the mobile node SHOULD use the bi- > >>>> directional tunnel even if it registers a binding(s) to the home > >>>> agent. > >>>> GT> This confuses me a bit. Is there anything different from > >>>> RFC3775? > >>>> Why is this section needed? > >> When MN establishes a tunnel with its HA and sends packets to the HA, > >> will MN should send packets with HoA option (RO) or IP-in-IP (non > >> RO)? > >> RFC3775 does not clearly explain this. HA can be treated as a CN. > >> The way of address verification is slightly different between > >> packets sent with HoA option and with IP-in-IP. > >>> I think it should be deleted. When packets are tunneled to the > >>> home agent, the home agent checks if the source address on the > >>> outer IPv6 header matches the care-of address in the binding > >>> cache entry. > >> Most of implementation verifies the source address > >> with the tunnel states (Not with BC database) > >>> The only exception is when the packet contains > >>> a binding update. So the sentence in the above paragraph is > >>> actually not valid. > >> This check MUST be done with the binding cache database. > >> This paragraph is to explain how to avoid the overhead of the > >> address verification in MCoA. > >> If the BC database is used for source address verification, > >> HA might search the BC database recursively to match the CoA and > >> the source address. > >> It is because BID (to match the exact BC) is not stored in the data > >> packets. > >> The cost can be O-(n) if 'n' bindings are registered. > >> Therefore, HA should verify the address validity with the tunnel > >> states. > >> HA can verify the packets with the tunnel states by comparing the > >> source and destination pair. > >> The cost can be decreased to O-(1). > >> HA MUST check all the packets from MNs, this additional overhead of > >> MCoA is not negligible. > >> It might be implementation issue though. > > > > Ryuji, the mobile node uses the home address option for only > > the signaling messages that are sent to the home agent. > > I don't see that as a lot of traffic that needs an optimization > > in terms of source address check. > > How can you say so? > RFC3775 does support tunneled packets and RO-packets between MN and HA. > If we can fix to use either tunnel or hoa option for data packets in > RFC3775-bis, > i am fine to remove this text. > > > > I think we stick to what we > > have in RFC 3775 (i.e., the mobile node can either tunnel > > or send packets with home address option to the HA). We > > should not recommend one over the other in the MCoA draft. I > > still think we should delete this paragraph. > > OK. I think we should discuss this possible issue in the 3775-bis > discussion. > I don't see any strong reasons to have two way to send packets from MN > to HA. > > ryuji > > > Vijay > > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Feb 25 13:55:11 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D25A928D11B; Mon, 25 Feb 2008 13:55:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, MIME_HTML_MOSTLY=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IMY70MFKDjU; Mon, 25 Feb 2008 13:55:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BC363A6E09; Mon, 25 Feb 2008 13:16:16 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00C913A6E07 for ; Mon, 25 Feb 2008 13:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TiKK-6bRKuwi for ; Mon, 25 Feb 2008 13:16:10 -0800 (PST) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.121]) by core3.amsl.com (Postfix) with ESMTP id E0DB03A6E40 for ; Mon, 25 Feb 2008 13:09:23 -0800 (PST) Received: from [192.168.2.2] (really [66.57.16.220]) by cdptpa-omta04.mail.rr.com with ESMTP id <20080225210917.MUXH16911.cdptpa-omta04.mail.rr.com@[192.168.2.2]>; Mon, 25 Feb 2008 21:09:17 +0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <915AF806-4126-4B6F-AA15-C41BC92EBC3B@lindem.com> From: Acee Lindem Date: Mon, 25 Feb 2008 16:08:59 -0500 To: Hesham Soliman X-Mailer: Apple Mail (2.753) Cc: mext@ietf.org Subject: Re: [MEXT] ID ACTION:draft-ietf-mext-nemo-v4traversal-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0158514758==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0158514758== Content-Type: multipart/alternative; boundary=Apple-Mail-5-180756380 --Apple-Mail-5-180756380 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Hesham, On Feb 24, 2008, at 12:58 PM, Hesham Soliman wrote: > I've updated the draft with your comment, a couple of responses below > though. > >> >> - Page 8, 1st paragraph - It says "If this option is not >> including..." yet >> it said previously that the option "MUST" be included. >> Perhaps, the "MUST" >> should have been a "MAY". > > => No I think the MUST is correct. The rest of the sentence > explains why the > option would not be included despite the "MUST". Specifying "MUST" and providing backward compatibility usually don't go together. So, when you say: In addition, if the binding update included an IPv4 home address option, the binding acknowledgement MUST include the IPv4 address acknowledgment option as described later in this specification. It is contradictory to define the action when it is not specified. If this option is not included in the binding acknowledgement and the IPv4 home address option was included in the binding update, the mobile node MUST assume that the home agent does not support the IPv4 home address option and therefore SHOULD NOT include the option in future binding updates to that home agent address. But I guess you understood my comment but disagree with the logic. I think people will be able to figure it either way but that "MAY" is more correct. > >> >> - Page 9, second paragraph - Replace "to the IPv4 care-of >> address." with >> "in an IPv4 header specifying the IPv4 care-of >> address as the >> destination." > > => I replaced it with " to the IPv4 care-of address, which was > included in > the source address of the IPv4 header encapsulating the binding > update". Ok. > >> - Page 11, IPv4 home address - It says "should be defended by >> the home agent". This >> terminology is usually associated for IPv6 Duplicate Address >> Detection. What >> does it mean for IPv4? > > => It's the same thing that an IPv4 HA does, I don't see anything > specific > to v6. You'll note that RFC 3344 doesn't refer to defending the IPv4 home address on the home link. My point is that the term "defending" is usually associated with MIP6 and IPv6 DAD on the home link. > >> >> - Page 20, 4th bullet - It says "mobile node MAY include the >> IPv4 home...". Yet in >> section 2.3.1 on the top of page 8, it says >> "therefore SHOULD >> NOT include the >> option...". > > => Yes for a completely different reason. In page 8 it talks about > a missing > option, in page 20 it talks about a present option that indicates > an error > in allocation. Right - I agree. This is the situation where the IPv4 allocation fails - not where it isn't supported. Sorry for the confusion. > > >> - Page 26, IANA Assignments - Should there be a new >> registry for >> TLV-Header >> encapsulations types? > > => Sadly yes but I think it needs IETF concensus. That's fine. But if this is an independent number space, it should have its own registry. Thanks, Acee > > Thanks for your comments, > Hesham > --Apple-Mail-5-180756380 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Hesham,

On Feb 24, 2008, at 12:58 PM, Hesham = Soliman wrote:

I've updated the draft with your = comment, a couple of responses below

=
=A0=A0 =A0 - Page 8, 1st = paragraph - It says "If this option is not =A0
=A0=A0 =A0 =A0 it said previously = that the option "MUST" be included. =A0
Perhaps, = the "MUST"
=A0=A0 =A0 =A0 should have been a = "MAY".
=3D> No I think the MUST is = correct. The rest of the sentence explains why the
option would not be included despite the = "MUST".

Specifying "MUST" and = providing backward compatibility usually don't go together. =A0So, when = you say:=A0
=A0
=A0=A0 In addition, if the binding update included an = IPv4 home address option,
=A0=A0 = the binding acknowledgement MUST include the IPv4 = address
=A0=A0 acknowledgment option = as described later in this specification.
It is contradictory to define = the action when it is not specified.

=A0=A0 If this option is not included in the = binding
=A0=A0 acknowledgement and = the IPv4 home address option was included in the
=A0=A0 binding update, the mobile node MUST assume = that the home agent does
=A0=A0 = not support the IPv4 home address option and therefore SHOULD = NOT
=A0=A0 include the option in = future binding updates to that home agent
=A0=A0 address.

But I guess = you understood my comment but disagree with the logic. I think people = will be able to figure it either way but that "MAY" is more = correct.=A0



=
=A0=A0 =A0 - Page 9, second = paragraph - Replace "to the IPv4 care-of =A0
=A0=A0 =A0 =A0 "in an IPv4 header = specifying the IPv4 care-of=A0
address = as the =A0
destination."

=3D> = I replaced it with " to the IPv4 care-of address, which was included = in
the source address of the IPv4 header = encapsulating the binding update".

Ok.



=
=A0=A0 =A0 - Page 11, IPv4 home = address - It says "should be defended by =A0
the home = agent". This
=A0=A0 =A0 =A0 terminology is = usually associated for IPv6 Duplicate Address =A0
=A0=A0 =A0 =A0 does it mean for = IPv4?
=3D> It's the same thing that = an IPv4 HA does, I don't see anything specific
to v6.

You'll note that RFC 3344 = doesn't refer to defending the IPv4 home address on the home link. My = point is that the term "defending" is usually associated with MIP6 and = IPv6 DAD on the home link.=A0




=
=A0=A0 =A0 - Page 20, 4th bullet = - It says "mobile node MAY include the =A0
IPv4 = home...". Yet in
=A0=A0 =A0 =A0 section 2.3.1 on = the top of page 8, it says=A0
=A0
NOT = include the
=A0=A0 =A0 =A0 option...".
=

=3D> Yes for a completely different reason. In = page 8 it talks about a missing
option, in = page 20 it talks about a present option that indicates an = error
in = allocation.

Right - I agree. This is = the situation where the IPv4 allocation fails - not where it isn't = supported. Sorry for the confusion.=A0




=A0=A0 =A0 - Page 26, IANA = Assignments - Should there be a new=A0
registry = for =A0
TLV-Header
=A0=A0 =A0 =A0 encapsulations = types?
=3D> Sadly yes but I think it = needs IETF concensus.

That's fine. But if this = is an independent number space, it should have its own = registry.


Thanks,
Acee
=




Thanks for your comments,
Hesham


= --Apple-Mail-5-180756380-- --===============0158514758== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext --===============0158514758==-- From mext-bounces@ietf.org Mon Feb 25 15:09:32 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA9C128D80B; Mon, 25 Feb 2008 15:09:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlnZPrmjGi+Z; Mon, 25 Feb 2008 15:09:31 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF23F28D432; Mon, 25 Feb 2008 14:15:10 -0800 (PST) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C65F428CCD1; Mon, 25 Feb 2008 14:15:01 -0800 (PST) Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080225221501.C65F428CCD1@core3.amsl.com> Date: Mon, 25 Feb 2008 14:15:01 -0800 (PST) Cc: mext@ietf.org Subject: [MEXT] I-D ACTION:draft-ietf-mext-nemo-v4traversal-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6) Author(s) : H. Soliman Filename : draft-ietf-mext-nemo-v4traversal-01.txt Pages : 31 Date : 2008-2-25 The current Mobile IPv6 and NEMO specifications support IPv6 only. This specification extends those standards to allow the registration of IPv4 addresses and prefixes, respectively, and the transport of both IPv4 and IPv6 packets over the tunnel to the home agent. This specification also allows the Mobile Node to roam over both IPv6 and IPv4, including the case where Network Address Translation is present on the path between the mobile node and its home agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-v4traversal-01.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-mext-nemo-v4traversal-01.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 _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Feb 25 15:10:06 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B937128D089; Mon, 25 Feb 2008 15:10:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.45 X-Spam-Level: X-Spam-Status: No, score=0.45 tagged_above=-999 required=5 tests=[AWL=-1.413, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MANGLED_TOOL=2.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXuPIDKa4yYY; Mon, 25 Feb 2008 15:10:04 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 883E528D186; Mon, 25 Feb 2008 14:47:26 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A549528CD7C for ; Mon, 25 Feb 2008 14:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6KR8PPKpUYy for ; Mon, 25 Feb 2008 14:47:24 -0800 (PST) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id DAEA228CD83 for ; Mon, 25 Feb 2008 14:33:01 -0800 (PST) Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Feb 2008 14:32:56 -0800 Message-ID: <47C34217.4020909@azairenet.com> Date: Mon, 25 Feb 2008 14:32:55 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: George Tsirtsis , RYUJI WAKIKAWA References: <47AC84E3.2030605@azairenet.com> <47BE0511.5010409@azairenet.com> <47BF1E7D.1070308@azairenet.com> <71BB702D-A4F7-483A-BD0C-AA91AB13799F@gmail.com> In-Reply-To: X-OriginalArrivalTime: 25 Feb 2008 22:32:56.0674 (UTC) FILETIME=[5E407420:01C877FE] Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] WGLC for draft-ietf-monami6-multiplecoa-05.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I think, there are three issues we haven't addressed yet. - Lifetime for the bindings. Should we maintain the lifetime for each binding separately or do all the bindings have the same lifetime. - In the simultaneous home and visited link operation, how does the HA delete the state about forwarding packets to the mobile node's home address on the home link? When the does the state expire. We added some text, but might require further discussion. - On whether we should consider enhanced RO for this draft. Not sure if there are any issues. Ryuji, anything else? Vijay George Tsirtsis wrote: > Hi Vijay/Ryuji, > > Thanks again for revising the document. I have not read the latest > version yet but by looking at your replies I think we are getting > there. A few issues, however, still remain which you indicate in your > e-mails. Would it be possible to summarize these separately so we can > resolve them? Anything we can not resolve on the list we can then > discuss in the IETF meeting; hopefully you have requested a slot for > this? > > In the mean time I will also try to go over the new draft. > > Thanks again > George > > On Sat, Feb 23, 2008 at 5:42 AM, RYUJI WAKIKAWA > wrote: >> Hi Vijay, >> >> >> On 2008/02/23, at 4:11, Vijay Devarapalli wrote: >> >> > Ryuji Wakikawa wrote: >> > >> >> We should treat the lifetime of that home state and the other real >> >> bindings separately. >> >> When the MN sends a BU with H flag set, it should not use bulk >> >> registration and send it as an individual BU. >> >> The lifetime field MUST be set to the appropriate lifetime for that >> >> home state. >> >> HA can always treat this BU as de-registration BU because the >> >> source address and home address are same. >> >> In addition to that, H flag can also tell this is deregistration BU. >> >> MN should renew the home state while it is at the home link. >> >> If you are fine with this, I will prepare for additional texts. >> > >> > This would mean that a BU with the 'H' flag set is a special >> > de-registration BU that deletes the binding cache entry but >> > creates some special state that says certain flows can be >> > delivered directly over the home link. What is the lifetime >> > in this BU? >> >> The H-flag indicates to HA that MN is at home. >> The state is not something link binding cache. >> I mean that state is the information of MN existence at the home link. >> When MN sends de-registration BU with H flag, HA will start special >> operation for that MN. >> >> >> > How do we delete this state later on? Does the mobile node >> > send a BU with lifetime set to 0 and 'H' flag set to '1'? >> > This needs more discussion. It might be better not to add >> > any text to the draft right now. >> >> right. >> If HA can detect the MN's existence at the home link without any states, >> we don't need this operation. >> HA can delete the state as soon as MR leaves the home link. >> >> >> >> >>>> Beside the difference in the size of packets, there is no >> >>>> difference >> >>>> between the two. The routing path does not get affected. With >> >>>> extensions specified in this document, the mobile node is >> >>>> capable of >> >>>> using multiple care-of addresses for outgoing packets. This is a >> >>>> problem on the home agent side because it must verify the Care-of >> >>>> address for all the packets received from the mobile node (i.e. >> >>>> ingress filtering). When the mobile node uses the Home Address >> >>>> option, the home agent MAY check the care-of address in the packet >> >>>> with the registered binding entries. This causes additional >> >>>> overhead >> >>>> to the home agent. Therefore, the mobile node SHOULD use the bi- >> >>>> directional tunnel even if it registers a binding(s) to the home >> >>>> agent. >> >>>> GT> This confuses me a bit. Is there anything different from >> >>>> RFC3775? >> >>>> Why is this section needed? >> >> When MN establishes a tunnel with its HA and sends packets to the HA, >> >> will MN should send packets with HoA option (RO) or IP-in-IP (non >> >> RO)? >> >> RFC3775 does not clearly explain this. HA can be treated as a CN. >> >> The way of address verification is slightly different between >> >> packets sent with HoA option and with IP-in-IP. >> >>> I think it should be deleted. When packets are tunneled to the >> >>> home agent, the home agent checks if the source address on the >> >>> outer IPv6 header matches the care-of address in the binding >> >>> cache entry. >> >> Most of implementation verifies the source address >> >> with the tunnel states (Not with BC database) >> >>> The only exception is when the packet contains >> >>> a binding update. So the sentence in the above paragraph is >> >>> actually not valid. >> >> This check MUST be done with the binding cache database. >> >> This paragraph is to explain how to avoid the overhead of the >> >> address verification in MCoA. >> >> If the BC database is used for source address verification, >> >> HA might search the BC database recursively to match the CoA and >> >> the source address. >> >> It is because BID (to match the exact BC) is not stored in the data >> >> packets. >> >> The cost can be O-(n) if 'n' bindings are registered. >> >> Therefore, HA should verify the address validity with the tunnel >> >> states. >> >> HA can verify the packets with the tunnel states by comparing the >> >> source and destination pair. >> >> The cost can be decreased to O-(1). >> >> HA MUST check all the packets from MNs, this additional overhead of >> >> MCoA is not negligible. >> >> It might be implementation issue though. >> > >> > Ryuji, the mobile node uses the home address option for only >> > the signaling messages that are sent to the home agent. >> > I don't see that as a lot of traffic that needs an optimization >> > in terms of source address check. >> >> How can you say so? >> RFC3775 does support tunneled packets and RO-packets between MN and HA. >> If we can fix to use either tunnel or hoa option for data packets in >> RFC3775-bis, >> i am fine to remove this text. >> >> >> > I think we stick to what we >> > have in RFC 3775 (i.e., the mobile node can either tunnel >> > or send packets with home address option to the HA). We >> > should not recommend one over the other in the MCoA draft. I >> > still think we should delete this paragraph. >> >> OK. I think we should discuss this possible issue in the 3775-bis >> discussion. >> I don't see any strong reasons to have two way to send packets from MN >> to HA. >> >> ryuji >> >> > Vijay >> >> _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Feb 25 17:47:10 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF39B28CB4C; Mon, 25 Feb 2008 17:47:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.413 X-Spam-Level: X-Spam-Status: No, score=0.413 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MANGLED_TOOL=2.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPG7QaHmavqP; Mon, 25 Feb 2008 17:47:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88B6B28C759; Mon, 25 Feb 2008 17:37:26 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9402128C74D for ; Mon, 25 Feb 2008 17:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71ZkFb75Gyub for ; Mon, 25 Feb 2008 17:37:23 -0800 (PST) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.227]) by core3.amsl.com (Postfix) with ESMTP id 7C26E3A6EAD for ; Mon, 25 Feb 2008 17:27:01 -0800 (PST) Received: by wr-out-0506.google.com with SMTP id 58so1394720wri.25 for ; Mon, 25 Feb 2008 17:26:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; bh=vUf5Qc2wJ8tmH7U3TIoxOd/gBGUwWj4vTDPt7z1E//U=; b=RFZ1FPFfMHgcHm0esPXl0oFZfRycSeNOEIHA+gggzArKmufGkJ7Kkp48tunYf9Hfnb+eYQ/XOwd3dkLS8W+ZAu0rYpJd02jugKHRWYHpxpMNLZSUISSNwwbQbkCck6D8a3US8AXMrfJzjceyWM8u0iPUXRp0U5exh3c0OZrzpUc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; b=fbOgQbpoQfKhovLo9ruIY6hc1cAzkTzdoyoCGimy1pvzSueWE1q3RFcLx0Rq73UqBb6ae9W3Dxq75mRhVmaUE6TY9nIddfnkCa4T2ogZrzKuBphbewuMu8Nwu8NtRP2UWpzIU4hIYnaClal9gCRdyZaniBrnjOu4FmCUowrO5jY= Received: by 10.140.82.38 with SMTP id f38mr2738913rvb.30.1203989214184; Mon, 25 Feb 2008 17:26:54 -0800 (PST) Received: from dhcp-143-220.sfc.wide.ad.jp ( [203.178.143.220]) by mx.google.com with ESMTPS id k2sm14152929rvb.36.2008.02.25.17.26.52 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Feb 2008 17:26:53 -0800 (PST) From: RYUJI WAKIKAWA To: Vijay Devarapalli In-Reply-To: <47C34217.4020909@azairenet.com> References: <47AC84E3.2030605@azairenet.com> <47BE0511.5010409@azairenet.com> <47BF1E7D.1070308@azairenet.com> <71BB702D-A4F7-483A-BD0C-AA91AB13799F@gmail.com> <47C34217.4020909@azairenet.com> Message-Id: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 26 Feb 2008 10:26:50 +0900 X-Mailer: Apple Mail (2.919.2) Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] WGLC for draft-ietf-monami6-multiplecoa-05.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi George and Vijay, Yes, the below three issues must be addressed. I'll summarize the issues and provide possible solutions per issue. ryuji On 2008/02/26, at 7:32, Vijay Devarapalli wrote: > I think, there are three issues we haven't addressed yet. > > - Lifetime for the bindings. Should we maintain the lifetime for > each binding separately or do all the bindings have the same > lifetime. > > - In the simultaneous home and visited link operation, how does > the HA delete the state about forwarding packets to the mobile > node's home address on the home link? When the does the state > expire. We added some text, but might require further discussion. > > - On whether we should consider enhanced RO for this draft. Not > sure if there are any issues. > > Ryuji, anything else? > > Vijay > > George Tsirtsis wrote: >> Hi Vijay/Ryuji, >> Thanks again for revising the document. I have not read the latest >> version yet but by looking at your replies I think we are getting >> there. A few issues, however, still remain which you indicate in your >> e-mails. Would it be possible to summarize these separately so we can >> resolve them? Anything we can not resolve on the list we can then >> discuss in the IETF meeting; hopefully you have requested a slot for >> this? >> In the mean time I will also try to go over the new draft. >> Thanks again >> George >> On Sat, Feb 23, 2008 at 5:42 AM, RYUJI WAKIKAWA >> wrote: >>> Hi Vijay, >>> >>> >>> On 2008/02/23, at 4:11, Vijay Devarapalli wrote: >>> >>> > Ryuji Wakikawa wrote: >>> > >>> >> We should treat the lifetime of that home state and the other >>> real >>> >> bindings separately. >>> >> When the MN sends a BU with H flag set, it should not use bulk >>> >> registration and send it as an individual BU. >>> >> The lifetime field MUST be set to the appropriate lifetime for >>> that >>> >> home state. >>> >> HA can always treat this BU as de-registration BU because the >>> >> source address and home address are same. >>> >> In addition to that, H flag can also tell this is >>> deregistration BU. >>> >> MN should renew the home state while it is at the home link. >>> >> If you are fine with this, I will prepare for additional texts. >>> > >>> > This would mean that a BU with the 'H' flag set is a special >>> > de-registration BU that deletes the binding cache entry but >>> > creates some special state that says certain flows can be >>> > delivered directly over the home link. What is the lifetime >>> > in this BU? >>> >>> The H-flag indicates to HA that MN is at home. >>> The state is not something link binding cache. >>> I mean that state is the information of MN existence at the home >>> link. >>> When MN sends de-registration BU with H flag, HA will start special >>> operation for that MN. >>> >>> >>> > How do we delete this state later on? Does the mobile node >>> > send a BU with lifetime set to 0 and 'H' flag set to '1'? >>> > This needs more discussion. It might be better not to add >>> > any text to the draft right now. >>> >>> right. >>> If HA can detect the MN's existence at the home link without any >>> states, >>> we don't need this operation. >>> HA can delete the state as soon as MR leaves the home link. >>> >>> >>> >>> >>>> Beside the difference in the size of packets, there is no >>> >>>> difference >>> >>>> between the two. The routing path does not get affected. >>> With >>> >>>> extensions specified in this document, the mobile node is >>> >>>> capable of >>> >>>> using multiple care-of addresses for outgoing packets. This >>> is a >>> >>>> problem on the home agent side because it must verify the >>> Care-of >>> >>>> address for all the packets received from the mobile node >>> (i.e. >>> >>>> ingress filtering). When the mobile node uses the Home >>> Address >>> >>>> option, the home agent MAY check the care-of address in the >>> packet >>> >>>> with the registered binding entries. This causes additional >>> >>>> overhead >>> >>>> to the home agent. Therefore, the mobile node SHOULD use >>> the bi- >>> >>>> directional tunnel even if it registers a binding(s) to the >>> home >>> >>>> agent. >>> >>>> GT> This confuses me a bit. Is there anything different from >>> >>>> RFC3775? >>> >>>> Why is this section needed? >>> >> When MN establishes a tunnel with its HA and sends packets to >>> the HA, >>> >> will MN should send packets with HoA option (RO) or IP-in-IP (non >>> >> RO)? >>> >> RFC3775 does not clearly explain this. HA can be treated as a CN. >>> >> The way of address verification is slightly different between >>> >> packets sent with HoA option and with IP-in-IP. >>> >>> I think it should be deleted. When packets are tunneled to the >>> >>> home agent, the home agent checks if the source address on the >>> >>> outer IPv6 header matches the care-of address in the binding >>> >>> cache entry. >>> >> Most of implementation verifies the source address >>> >> with the tunnel states (Not with BC database) >>> >>> The only exception is when the packet contains >>> >>> a binding update. So the sentence in the above paragraph is >>> >>> actually not valid. >>> >> This check MUST be done with the binding cache database. >>> >> This paragraph is to explain how to avoid the overhead of the >>> >> address verification in MCoA. >>> >> If the BC database is used for source address verification, >>> >> HA might search the BC database recursively to match the CoA and >>> >> the source address. >>> >> It is because BID (to match the exact BC) is not stored in the >>> data >>> >> packets. >>> >> The cost can be O-(n) if 'n' bindings are registered. >>> >> Therefore, HA should verify the address validity with the tunnel >>> >> states. >>> >> HA can verify the packets with the tunnel states by comparing the >>> >> source and destination pair. >>> >> The cost can be decreased to O-(1). >>> >> HA MUST check all the packets from MNs, this additional >>> overhead of >>> >> MCoA is not negligible. >>> >> It might be implementation issue though. >>> > >>> > Ryuji, the mobile node uses the home address option for only >>> > the signaling messages that are sent to the home agent. >>> > I don't see that as a lot of traffic that needs an optimization >>> > in terms of source address check. >>> >>> How can you say so? >>> RFC3775 does support tunneled packets and RO-packets between MN >>> and HA. >>> If we can fix to use either tunnel or hoa option for data packets in >>> RFC3775-bis, >>> i am fine to remove this text. >>> >>> >>> > I think we stick to what we >>> > have in RFC 3775 (i.e., the mobile node can either tunnel >>> > or send packets with home address option to the HA). We >>> > should not recommend one over the other in the MCoA draft. I >>> > still think we should delete this paragraph. >>> >>> OK. I think we should discuss this possible issue in the 3775-bis >>> discussion. >>> I don't see any strong reasons to have two way to send packets >>> from MN >>> to HA. >>> >>> ryuji >>> >>> > Vijay >>> >>> > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Feb 25 17:48:20 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AB2228C13D; Mon, 25 Feb 2008 17:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.693 X-Spam-Level: X-Spam-Status: No, score=-0.693 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tk3btXoqKB2; Mon, 25 Feb 2008 17:48:19 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C80628C228; Mon, 25 Feb 2008 17:42:53 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 276C028C228 for ; Mon, 25 Feb 2008 17:42:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kPEyIso0BXg for ; Mon, 25 Feb 2008 17:42:51 -0800 (PST) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.225]) by core3.amsl.com (Postfix) with ESMTP id 3758F3A6DD5 for ; Mon, 25 Feb 2008 17:34:31 -0800 (PST) Received: by wr-out-0506.google.com with SMTP id 58so1399897wri.25 for ; Mon, 25 Feb 2008 17:34:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; bh=Y7VSTEo2Onzl6z852+FfyNxoBqoBoDG2/6cA4oO/Npg=; b=se75ZHej1Ui8tD8D8mICs2R47NrBAGWtMrPvyipKE67toDQIrWG8igmCvzVDFhz5Rirn7TU5A4WqN3jlJedaS4xfjlUGT/SlQSfSV8WMukn/Y8Z89SebVUSGXZftnMj8KHAOH/2AAzNyUYkUQseE4/rkgxHKb9QZSrhAlxXFYNw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; b=upu7JC1znl2q9youuaI5U+OR7T5/9ydkOLBXdiyZHF9L3DjEommX59k8sIzty9kq3kGIOSfiAv9UQU7LaUE5PIJWQjrl5rBy+BQBv+nnW1rChf8ZwzfpMph0mPuuXXI382g8GPKolUyzIPbFUGK0AnV07xDuPqHhVSv8HEMtm+0= Received: by 10.140.207.3 with SMTP id e3mr2733147rvg.262.1203989664144; Mon, 25 Feb 2008 17:34:24 -0800 (PST) Received: from dhcp-143-220.sfc.wide.ad.jp ( [203.178.143.220]) by mx.google.com with ESMTPS id k2sm14170311rvb.36.2008.02.25.17.34.22 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Feb 2008 17:34:23 -0800 (PST) From: RYUJI WAKIKAWA To: M. Vanderveen In-Reply-To: <98953.50404.qm@web54405.mail.yahoo.com> References: <98953.50404.qm@web54405.mail.yahoo.com> Message-Id: <33F598EC-22A7-4436-B864-96E132416782@gmail.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 26 Feb 2008 10:34:20 +0900 X-Mailer: Apple Mail (2.919.2) Cc: mext@ietf.org Subject: Re: [MEXT] WGLC for draft-ietf-monami6-multiplecoa-05.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Michaela thanks for comments. On 2008/02/23, at 4:38, M. Vanderveen wrote: > > Hello Vijay, > > > > Regarding switching the mobile operation from regular (RFC-3775 > compliant) to mcoa compliant: there is a paragraph on page 7 > explaining how to fall back on regular operation. It is not obvious > to me what the operation should be in the other case, where the > mobile was operating under RFC-3775 only, and had registered a CoA > without a BID, but then later on decides to register additional CoAs > (one of which may or may not be the original CoA) with BIDs. see section 5.9: Bootstrapping. The MN sends BU with O flag set so that it can replace the regular binding with MCoA-bindings. Otherwise, according to section 6.3, HA rejects BU. * If the receiver has a regular binding which does not have BID for the mobile node, it must not process the binding update. The receiver should sent a binding acknowledgement with status set to [MCOA BID CONFLICT]. > > Perhaps this can be added to the following paragraph: > > "If there is an existing binding cache entry for the mobile > > node, and the if the BID in the Binding Update does not match the > one > > with the existing entry, the home agent MUST create a new binding > > cache entry for the new care-of address and BID. > " > > If the additional CoAs have BIDs, what is the HA to do with the > original CoA that was not registered with a BID. Is this case even > possible? The HA rejects the MCoA-BU and expects another BU with O flag set. regards ryuji > Trivially, if one of the additional CoAs actually matches the > original one, then that binding cache can be updated to include a > BID. Not sure if the original CoA is not included in this later mcoa > BU. > > Thanks > Michaela > > > > > > > > > > > > > ____________________________________________________________________________________ > Never miss a thing. Make Yahoo your home page. > http://www.yahoo.com/r/hs > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Feb 25 23:56:40 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54CAC28C3DD; Mon, 25 Feb 2008 23:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[AWL=-0.224, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lpm8lihwu3e5; Mon, 25 Feb 2008 23:56:39 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C3B93A695D; Mon, 25 Feb 2008 23:56:39 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2D3D3A695D for ; Mon, 25 Feb 2008 23:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRkFDCEjOz4s for ; Mon, 25 Feb 2008 23:56:36 -0800 (PST) Received: from hpsmtp-eml18.kpnxchange.com (hpsmtp-eml18.kpnxchange.com [213.75.38.118]) by core3.amsl.com (Postfix) with ESMTP id 9C78A3A68F0 for ; Mon, 25 Feb 2008 23:56:35 -0800 (PST) Received: from hpsmtp-eml09.kpnxchange.com ([213.75.38.109]) by hpsmtp-eml18.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 08:56:29 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml09.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 08:56:29 +0100 From: "Teco Boot" To: "'Hesham Soliman'" References: <20080225221501.C65F428CCD1@core3.amsl.com> In-Reply-To: <20080225221501.C65F428CCD1@core3.amsl.com> Date: Tue, 26 Feb 2008 08:56:24 +0100 Message-ID: <003d01c8784d$153244d0$3f96ce70$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ach4DCVA8/PDNaz0T5Oa2Psj9Ojc7QAP1Oog Content-Language: nl X-OriginalArrivalTime: 26 Feb 2008 07:56:29.0264 (UTC) FILETIME=[18203D00:01C8784D] Cc: mext@ietf.org Subject: Re: [MEXT] I-D ACTION:draft-ietf-mext-nemo-v4traversal-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, A late comment on the TLV encapsulation: I think the TLV-header UDP encapsulation could be used for IP Tunneling Optimization. For this reason, I would like to keep the overhead as small as possible. Do we really need the Reserved field? And is a length field of only one octet not a little bit to small? Encapsulated payload could exceed 255 octets. Teco. > -----Oorspronkelijk bericht----- > Van: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] Namens > Internet-Drafts@ietf.org > Verzonden: maandag 25 februari 2008 23:15 > Aan: i-d-announce@ietf.org > CC: mext@ietf.org > Onderwerp: [MEXT] I-D ACTION:draft-ietf-mext-nemo-v4traversal-01.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Mobility EXTensions for IPv6 Working > Group of the IETF. > > Title : Mobile IPv6 support for dual stack Hosts and > Routers (DSMIPv6) > Author(s) : H. Soliman > Filename : draft-ietf-mext-nemo-v4traversal-01.txt > Pages : 31 > Date : 2008-2-25 > > The current Mobile IPv6 and NEMO specifications support IPv6 only. > This specification extends those standards to allow the registration > of IPv4 addresses and prefixes, respectively, and the transport of > both IPv4 and IPv6 packets over the tunnel to the home agent. This > specification also allows the Mobile Node to roam over both IPv6 and > IPv4, including the case where Network Address Translation is > present > on the path between the mobile node and its home agent. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-v4traversal- > 01.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-mext-nemo-v4traversal-01.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 > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Feb 26 02:26:26 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 243A828C17B; Tue, 26 Feb 2008 02:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.627 X-Spam-Level: X-Spam-Status: No, score=-1.627 tagged_above=-999 required=5 tests=[AWL=-0.541, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, MIME_HTML_MOSTLY=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NQNPLKdsG4T; Tue, 26 Feb 2008 02:26:24 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D087D3A6BDF; Tue, 26 Feb 2008 02:26:24 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56A4528C0D7 for ; Tue, 26 Feb 2008 02:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Px0OfYmumTR4 for ; Tue, 26 Feb 2008 02:26:22 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 4003A3A6C20 for ; Tue, 26 Feb 2008 02:26:21 -0800 (PST) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 11:26:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Feb 2008 11:26:12 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [MEXT] [Recharter.2] Thread-Index: Ach4YgK/BwoghUV/S3Sz5g4vrHA2IA== From: To: X-OriginalArrivalTime: 26 Feb 2008 10:26:14.0091 (UTC) FILETIME=[038009B0:01C87862] Cc: mext@ietf.org Subject: Re: [MEXT] [Recharter.2] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1608638740==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============1608638740== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C87862.02F14BDE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C87862.02F14BDE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 Hi Julien, =20 I'd like to support: =20 [R] MIPv6 home link operation in various SDOs [R] Generic Notification Message for Mobile IPv6=20 [R] Virtual Home Link configuration for Mobile IPv6 =20 =20 Pierrick =20 >=20 >> -----Original Message----- >> From: mext-bounces at ietf.org [mailto:mext-bounces at ietf.org] On Behalf=20 >> Of Julien Laganier >> Sent: Tuesday, February 12, 2008 11:32 PM >> To: mext at ietf.org >> Subject: [MEXT] [Recharter.2] >>=20 >> Folks, >>=20 >> This is the next step in the recharter process. We'd like to=20 >get input=20 >> from WG participants on what should be the items included in=20 >> rechartering, what are their priorities, and who is willing=20 >to sustain=20 >> the effort. When that step is completed we will take the WG=20 >input and=20 >> discuss with our AD to move forward with deciding what to include or=20 >> not in the charter. >> Your input should be sent to the list during the following=20 >two weeks,=20 >> by 2008-02-26. >>=20 >> Please pick from the list of items below the items you think the WG=20 >> should work on, and order them in decreasing priority (just to make=20 >> sure, first priority items goes first in the list you're making :). >>=20 >> List of items: >>=20 >> Binding Revocation for IP Mobility >> MIPv6 home link operation in various SDOs IP Tunneling=20 >Optimization in=20 >> a Mobile Environment Generic Notification Message for Mobile=20 >IPv6 GRE=20 >> requirements for IPv6 mobility 4283bis to extend MN identifier to=20 >> other identifiers Mobile >> IPv6 Bootstrapping for the Authentication Option Protocol=20 >Interaction=20 >> between Mobile IPv6 and IPsec/IKE by PF_KEY extensions Virtual Home=20 >> Link configuration for Mobile IPv6 Extend DSMIPv6 Home=20 >Network Support >>=20 >> Also, please prefix each of the items in your list with the=20 >letters E,=20 >> C and/or R if you're willing to: >>=20 >> - [E]dit: Are you willing to edit the draft corresponding to the >> item.=20 >>=20 >> - [C]ontribute: Are you willing to propose text for the draft. >>=20 >> - [R]eview: Are you willing to review new revisions of the draft when >> being asked by the chairs. >>=20 >> As an example, that could be one input list: >>=20 >> E MIPv6 home link operation in various SDOs CR Binding=20 >Revocation for=20 >> IP Mobility R IP Tunneling Optimization in a Mobile Environment >>=20 >> meaning that the MIPv6 home link is first priority and you volunteer=20 >> to edit, Binding revocation is second priority and you're willing to=20 >> contribute and review, while IP tunneling optimization is third=20 >> priority and you're willing to review. >>=20 >> Hope this is understandable :) >>=20 >> Thanks. >>=20 >> -- julien and marcello, MEXT chairs >> _______________________________________________ >> MEXT mailing list >> MEXT at ietf.org >> http://www.ietf.org/mailman/listinfo/mext =20 >>=20 >=20 =20 ------_=_NextPart_001_01C87862.02F14BDE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

Hi Julien,
 
I'd like =
to support:
 
[R] =
MIPv6 home link operation in various SDOs
[R] Generic Notification Message for Mobile IPv6 =

[R] Virtual Home Link configuration for Mobile =
IPv6
 
 
Pierrick
 
> <=
/span>
>> -----Original =
Message-----
>> From: mext-bounces at =
ietf.org [mailto:mext-bounces at ietf.org] On Behalf =

>> Of Julien Laganier
>> Sent: Tuesday, February 12, 2008 11:32 =
PM
>> To: mext at =
ietf.org
>> Subject: [MEXT] =
[Recharter.2]
>> 
>> Folks,
>> 
>> This is the next step in the recharter process. We'd like to =

>get input 
>> from WG participants on what =
should be the items included in =

>> rechartering, what are their =
priorities, and who is willing 
>to sustain 
>> the effort. When that step is =
completed we will take the WG 
>input and 
>> discuss with our AD to move forward with deciding what =
to include or 
>> not in the =
charter.
>> Your input should be sent to the list during the =
following 
>two weeks, 
>> by =
2008-02-26.
>> 
>> Please pick from the list of items below the items you =
think the WG 
>> should work on, and order them in decreasing priority =
(just to make 
>> sure, first priority items =
goes first in the list you're making =
:).
>> 
>> List of items:
>> 
>> Binding Revocation for IP =
Mobility
>> MIPv6 home link operation in various =
SDOs IP Tunneling =

>Optimization in =

>> a Mobile Environment Generic =
Notification Message for Mobile =

>IPv6 GRE 
>> requirements for IPv6 =
mobility 4283bis to extend MN identifier to =

>> other identifiers Mobile
<= pre>>> IPv6 Bootstrapping for the Authentication Option = Protocol 
>Interaction 
>> between Mobile IPv6 and IPsec/IKE by PF_KEY extensions Virtual Home =

>> Link configuration for Mobile IPv6 Extend DSMIPv6 Home =

>Network Support
>> 
>> Also, please prefix each of the items in your list with =
the 
>letters E, 
>> C and/or R if you're willing =
to:
>> 
>> - [E]dit: Are you willing to =
edit the draft corresponding to =
the
>>   =
item. 
>> 
>> - [C]ontribute: Are you =
willing to propose text for the =
draft.
>> 
>> - [R]eview: Are you willing =
to review new revisions of the draft =
when
>>   being asked by the =
chairs.
>> 
>> As an example, that could be one input =
list:
>> 
>> E MIPv6 home link operation in =
various SDOs CR Binding =

>Revocation for 
>> IP Mobility R IP Tunneling =
Optimization in a Mobile =
Environment
>> 
>> meaning that the MIPv6 home link is first priority and =
you volunteer 
>> to edit, Binding revocation =
is second priority and you're willing to =

>> contribute and review, while IP tunneling optimization is third =

>> priority and you're willing =
to review.
>> 
>> Hope this is understandable =
:)
>> 
>> Thanks.
>> 
>> -- julien and marcello, MEXT =
chairs
>> =
_______________________________________________<=
/pre>
>> MEXT mailing =
list
>> MEXT at =
ietf.org
>> http://www.ietf.org/mailman/listinfo/me=
xt
>> =

> 



 
------_=_NextPart_001_01C87862.02F14BDE-- --===============1608638740== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext --===============1608638740==-- From mext-bounces@ietf.org Tue Feb 26 06:12:59 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7533828C4FD; Tue, 26 Feb 2008 06:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.445 X-Spam-Level: X-Spam-Status: No, score=-0.445 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSO8TG421PKQ; Tue, 26 Feb 2008 06:12:58 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67A2128C44F; Tue, 26 Feb 2008 06:12:46 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 135133A6BBF; Tue, 26 Feb 2008 06:12:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdQDN860vPTs; Tue, 26 Feb 2008 06:12:42 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 5264128C4AD; Tue, 26 Feb 2008 06:12:32 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 8B919198D66; Tue, 26 Feb 2008 16:12:25 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 4D017198D62; Tue, 26 Feb 2008 16:12:25 +0200 (EET) Message-ID: <47C41E49.5020808@piuha.net> Date: Tue, 26 Feb 2008 16:12:25 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: mext@ietf.org, Dhcwg References: <20080226140849.01C053A6C13@core3.amsl.com> In-Reply-To: <20080226140849.01C053A6C13@core3.amsl.com> X-Virus-Scanned: ClamAV using ClamSMTP Cc: ietf@ietf.org Subject: Re: [MEXT] Last Call: draft-ietf-mip6-hiopt (DHCP Options for Home Information Discovery in MIPv6) to Proposed Standard X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org FYI -- this draft is being Last Called for the second time, due to having changed substantially as a result of earlier reviews. > The IESG has received a request from the Mobility for IPv6 WG (mip6) to > consider the following document: > > - 'DHCP Options for Home Information Discovery in MIPv6 ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2008-03-11. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-mip6-hiopt-11.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15105&rfc_flag=0 > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Feb 26 07:21:17 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EEF128C49D; Tue, 26 Feb 2008 07:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.479 X-Spam-Level: X-Spam-Status: No, score=-0.479 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUIz1dkbuNoN; Tue, 26 Feb 2008 07:21:16 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FFBB28C3B0; Tue, 26 Feb 2008 07:21:16 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7A3C28C40F for ; Tue, 26 Feb 2008 07:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bm4jjZFM7NZP for ; Tue, 26 Feb 2008 07:21:13 -0800 (PST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by core3.amsl.com (Postfix) with ESMTP id 540B628C29E for ; Tue, 26 Feb 2008 07:21:13 -0800 (PST) Received: by ug-out-1314.google.com with SMTP id u2so2695661uge.46 for ; Tue, 26 Feb 2008 07:21:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:mime-version:content-type:message-id:sender; bh=b8nxuD0Y/muzHbcj6To9NXEQdeaMmNFW85A6GHmv8O8=; b=iHqCKOzj23dqa0ssP4WFl1kGjbOuwC5skwV+nhDvCKiHUx0n360F8KWSK1psUYxSf2fcrcRIsRCcJu6anQNqC154FoCTdeBdCvR6rJV1FBGmpekAyIcPte/uYM89VyPD4Nq2nmmKI5JOPnw2rONg5/MQLNEB2m0GrH5TyS7khgg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:mime-version:content-type:message-id:sender; b=Wthx3RyLo1mJX+19Sy6/HlNvEkiGzbcgYJrUk2ZuVA3PUuyLtqpjI2KugWIvAEi7cK25lFk2roC6GzI4SukOC7To4SlKi++R2OG8WTeZZd43U1WlEEsbxL2O91QUsr7yZxxy2rkkYgrQGN6X2n7XSU/v58gTBjBGp6qWXqziZ9E= Received: by 10.66.236.13 with SMTP id j13mr4961063ugh.30.1204039266181; Tue, 26 Feb 2008 07:21:06 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id g30sm7730789ugd.54.2008.02.26.07.21.02 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Feb 2008 07:21:04 -0800 (PST) From: Julien Laganier To: mext@ietf.org Date: Tue, 26 Feb 2008 16:21:45 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_K6CxHx9m9Jn+OAA" Message-Id: <200802261621.46073.julien.IETF@laposte.net> Subject: [MEXT] Fwd: [Mip6] Last Call: draft-ietf-mip6-hiopt (DHCP Options for Home Information Discovery in MIPv6) to Proposed Standard X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --Boundary-00=_K6CxHx9m9Jn+OAA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-00=_K6CxHx9m9Jn+OAA Content-Type: message/rfc822; name="forwarded message" Content-Transfer-Encoding: 7bit Content-Description: The IESG : [Mip6] Last Call: draft-ietf-mip6-hiopt (DHCP Options for Home Information Discovery in MIPv6) to Proposed Standard Content-Disposition: inline Return-Path: Received: from mwinf8202.laposte.net (mwinf8202.laposte.net) by mwinb8204 (SMTP Server) with LMTP; Tue, 26 Feb 2008 15:10:15 +0100 X-Sieve: Server Sieve 2.2 Received: from meplus.info (localhost [127.0.0.1]) by mwinf8202.laposte.net (SMTP Server) with ESMTP id 35B7E24000AE for ; Tue, 26 Feb 2008 15:10:15 +0100 (CET) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mwinf8202.laposte.net (SMTP Server) with ESMTP id CD84D2400094 for ; Tue, 26 Feb 2008 15:10:13 +0100 (CET) X-ME-UUID: 20080226141013841.CD84D2400094@mwinf8202.laposte.net Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9F8128C28D; Tue, 26 Feb 2008 06:08:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PkxSoV0Xlv3X; Tue, 26 Feb 2008 06:08:51 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B923228C2DD; Tue, 26 Feb 2008 06:08:51 -0800 (PST) X-Original-To: mip6@ietf.org Delivered-To: mip6@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 01C053A6C13; Tue, 26 Feb 2008 06:08:48 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20080226140849.01C053A6C13@core3.amsl.com> Date: Tue, 26 Feb 2008 06:08:49 -0800 (PST) Cc: mip6@ietf.org Subject: [Mip6] Last Call: draft-ietf-mip6-hiopt (DHCP Options for Home Information Discovery in MIPv6) to Proposed Standard X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-me-spamlevel: not-spam X-me-spamrating: 5.921207 X-UID: 42547 X-Length: 3338 The IESG has received a request from the Mobility for IPv6 WG (mip6) to consider the following document: - 'DHCP Options for Home Information Discovery in MIPv6 ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-03-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mip6-hiopt-11.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15105&rfc_flag=0 _______________________________________________ Mip6 mailing list Mip6@ietf.org http://www.ietf.org/mailman/listinfo/mip6 --Boundary-00=_K6CxHx9m9Jn+OAA Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext --Boundary-00=_K6CxHx9m9Jn+OAA-- From mext-bounces@ietf.org Tue Feb 26 07:21:29 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09D3A28C515; Tue, 26 Feb 2008 07:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.493 X-Spam-Level: X-Spam-Status: No, score=-0.493 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tl0Vr6493o4t; Tue, 26 Feb 2008 07:21:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10A6728C508; Tue, 26 Feb 2008 07:21:26 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFB3D28C517 for ; Tue, 26 Feb 2008 07:21:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id teHBz3Cujh-R for ; Tue, 26 Feb 2008 07:21:23 -0800 (PST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by core3.amsl.com (Postfix) with ESMTP id A82DB28C3AE for ; Tue, 26 Feb 2008 07:21:22 -0800 (PST) Received: by ug-out-1314.google.com with SMTP id u2so2695661uge.46 for ; Tue, 26 Feb 2008 07:21:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:mime-version:content-type:message-id:sender; bh=ngZy9cZmVc2c1pbFGGkkoms8xTmaPV0GdiW023S2IxE=; b=arK0Muc42nIWeA89EMvg8IeYeFjbTdjPMK1r/k6u+eNguGcpBvIAZplSMa2PQQxgnf2PMeL6KL+G1ACEWFbs//4lOT2bRX3BbBQNMql9DpRbj1u1/JJyTMa2ErxH0bzmHRYS/KS6ckkVLvrh2W38yjGhj4VixZka0IVRj3+htHY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:mime-version:content-type:message-id:sender; b=Bfb+DZpaTD3HF0mboE5ucyUWm2eUkFrxUhTxnSQEgcOy8Xx9pjfB2oep34MwshOvKcKMulSzTUMvUtZeC6lEU/mA9j9caKDA7sIx+CBzoW8wAEzEH1xsfUrPxqWqHpX5ZUACxJacMkYrU7GR6IRlF7L/6sMfnQERp6sJpXfLYzg= Received: by 10.66.221.18 with SMTP id t18mr4951153ugg.80.1204039276591; Tue, 26 Feb 2008 07:21:16 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id 31sm7754892ugg.47.2008.02.26.07.21.14 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Feb 2008 07:21:15 -0800 (PST) From: Julien Laganier To: mext@ietf.org Date: Tue, 26 Feb 2008 16:22:00 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_Y6CxHt0z4yYnM+/" Message-Id: <200802261622.00893.julien.IETF@laposte.net> Subject: [MEXT] Fwd: [Mip6] I-D Action:draft-ietf-mip6-hiopt-11.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --Boundary-00=_Y6CxHt0z4yYnM+/ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-00=_Y6CxHt0z4yYnM+/ Content-Type: message/rfc822; name="forwarded message" Content-Transfer-Encoding: 7bit Content-Description: Internet-Drafts@ietf.org: [Mip6] I-D Action:draft-ietf-mip6-hiopt-11.txt Content-Disposition: inline Return-Path: Received: from mwinf8303.laposte.net (mwinf8303.laposte.net) by mwinb8204 (SMTP Server) with LMTP; Fri, 22 Feb 2008 07:01:56 +0100 X-Sieve: Server Sieve 2.2 Received: from meplus.info (localhost [127.0.0.1]) by mwinf8303.laposte.net (SMTP Server) with ESMTP id E18502400084 for ; Fri, 22 Feb 2008 07:01:55 +0100 (CET) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mwinf8303.laposte.net (SMTP Server) with ESMTP id 79421240008B for ; Fri, 22 Feb 2008 07:01:55 +0100 (CET) X-ME-UUID: 20080222060155496.79421240008B@mwinf8303.laposte.net Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06DDB28CA61; Thu, 21 Feb 2008 22:00:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BILGX3uh6XrW; Thu, 21 Feb 2008 22:00:06 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 829973A6C29; Thu, 21 Feb 2008 22:00:04 -0800 (PST) X-Original-To: mip6@ietf.org Delivered-To: mip6@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id BBA0E3A698C; Thu, 21 Feb 2008 22:00:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080222060001.BBA0E3A698C@core3.amsl.com> Date: Thu, 21 Feb 2008 22:00:01 -0800 (PST) Cc: mip6@ietf.org Subject: [Mip6] I-D Action:draft-ietf-mip6-hiopt-11.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-me-spamlevel: not-spam X-me-spamrating: 8.218492 X-UID: 40788 X-Length: 5399 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : DHCP Options for Home Information Discovery in MIPv6 Author(s) : H. Jang, et al. Filename : draft-ietf-mip6-hiopt-11.txt Pages : 23 Date : 2008-02-21 This draft defines a DHCP-based scheme to enable dynamic discovery of Mobile IPv6 home network information. New DHCP options are defined which allow a mobile node to request the home agent IP address, FQDN, or home network prefix and obtain it via the DHCP response. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-hiopt-11.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-mip6-hiopt-11.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-mip6-hiopt-11.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: <2008-02-21214848.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-hiopt-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-hiopt-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-21214848.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org http://www.ietf.org/mailman/listinfo/mip6 --NextPart-- --Boundary-00=_Y6CxHt0z4yYnM+/ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext --Boundary-00=_Y6CxHt0z4yYnM+/-- From mext-bounces@ietf.org Tue Feb 26 07:21:31 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF8C528C52A; Tue, 26 Feb 2008 07:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.507 X-Spam-Level: X-Spam-Status: No, score=-0.507 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5H5VM6UVt592; Tue, 26 Feb 2008 07:21:31 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C8E128C51F; Tue, 26 Feb 2008 07:21:30 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3262928C508 for ; Tue, 26 Feb 2008 07:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEG-9a3H9Svy for ; Tue, 26 Feb 2008 07:21:28 -0800 (PST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by core3.amsl.com (Postfix) with ESMTP id 1B77A28C506 for ; Tue, 26 Feb 2008 07:21:26 -0800 (PST) Received: by ug-out-1314.google.com with SMTP id u2so2695661uge.46 for ; Tue, 26 Feb 2008 07:21:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:mime-version:content-type:message-id:sender; bh=gfTh9AyQDXjSVlujetjex/CQtYnWrWzJWycLPwRe+Eg=; b=ladjjNB430DUADjzBIYQrR5QUpnwhMVksSE2qd8awAUn6Ds3+Y+e77AivDc1zR+b+pGbTRKlAUKb2xp/cdjeJ0w7sceOBxg4azay5rPLr5v4eLNRly0pkTJiA+4zZJTpC3RimdqMFM2k6hZr8hvPpfSPJhiCA6e+CWHppj730Pk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:mime-version:content-type:message-id:sender; b=k8IrdnZC/1xkHD6RtwFxd01YKw8pEJEWN9tDMt7YAGU27MC3WrwHZeW5vwDuMPMxT5eut+OaVj5rdqG5d7YYZnK6LYGMZjpOX5PliQ3Ym/7oFcSCPNJ3BJVbcICbH+EJ4cwklhuNBVILiw6XGZc91T95aXiRERpEut7SWv143Dw= Received: by 10.67.121.2 with SMTP id y2mr4951098ugm.78.1204039280917; Tue, 26 Feb 2008 07:21:20 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id m1sm2485837ugc.51.2008.02.26.07.21.19 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Feb 2008 07:21:20 -0800 (PST) From: Julien Laganier To: mext@ietf.org Date: Tue, 26 Feb 2008 16:22:05 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_e6CxHTiFK3C1dbd" Message-Id: <200802261622.06296.julien.IETF@laposte.net> Subject: [MEXT] Fwd: [Mip6] I-D Action:draft-ietf-mip6-cn-ipsec-07.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --Boundary-00=_e6CxHTiFK3C1dbd Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-00=_e6CxHTiFK3C1dbd Content-Type: message/rfc822; name="forwarded message" Content-Transfer-Encoding: 7bit Content-Description: Internet-Drafts@ietf.org: [Mip6] I-D Action:draft-ietf-mip6-cn-ipsec-07.txt Content-Disposition: inline Return-Path: Received: from mwinf8202.laposte.net (mwinf8202.laposte.net) by mwinb8204 (SMTP Server) with LMTP; Sat, 23 Feb 2008 14:45:08 +0100 X-Sieve: Server Sieve 2.2 Received: from meplus.info (localhost [127.0.0.1]) by mwinf8202.laposte.net (SMTP Server) with ESMTP id 1241D240008D for ; Sat, 23 Feb 2008 14:45:08 +0100 (CET) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mwinf8202.laposte.net (SMTP Server) with ESMTP id 807C82400088 for ; Sat, 23 Feb 2008 14:45:07 +0100 (CET) X-ME-UUID: 20080223134507526.807C82400088@mwinf8202.laposte.net Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E710728C28E; Sat, 23 Feb 2008 05:45:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id am1D6KMhFYUD; Sat, 23 Feb 2008 05:45:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73AE53A6990; Sat, 23 Feb 2008 05:45:05 -0800 (PST) X-Original-To: mip6@ietf.org Delivered-To: mip6@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 44B743A698E; Sat, 23 Feb 2008 05:45:02 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080223134502.44B743A698E@core3.amsl.com> Date: Sat, 23 Feb 2008 05:45:02 -0800 (PST) Cc: mip6@ietf.org Subject: [Mip6] I-D Action:draft-ietf-mip6-cn-ipsec-07.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-me-spamlevel: not-spam X-me-spamrating: 4.514023 X-UID: 41296 X-Length: 5503 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Using IPsec between Mobile and Correspondent IPv6 Nodes Author(s) : F. Dupont, J. Combes Filename : draft-ietf-mip6-cn-ipsec-07.txt Pages : 11 Date : 2008-02-23 Mobile IPv6 uses IPsec to protect signaling between the Mobile Node and the Home Agent. This document defines how IPsec can be used between the Mobile Node and Correspondent Nodes for Home Address Option validation and protection of mobility signaling for Route Optimization. The configuration details for IPsec and IKE are also provided. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-cn-ipsec-07.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-mip6-cn-ipsec-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-cn-ipsec-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-23053943.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-cn-ipsec-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-cn-ipsec-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-23053943.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org http://www.ietf.org/mailman/listinfo/mip6 --NextPart-- --Boundary-00=_e6CxHTiFK3C1dbd Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext --Boundary-00=_e6CxHTiFK3C1dbd-- From mext-bounces@ietf.org Tue Feb 26 07:21:42 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93A5928C4A3; Tue, 26 Feb 2008 07:21:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.52 X-Spam-Level: X-Spam-Status: No, score=-0.52 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXbgVHpSSfRQ; Tue, 26 Feb 2008 07:21:41 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40EF228C51F; Tue, 26 Feb 2008 07:21:39 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2FF228C52A for ; Tue, 26 Feb 2008 07:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHlxxe4Eu72v for ; Tue, 26 Feb 2008 07:21:34 -0800 (PST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by core3.amsl.com (Postfix) with ESMTP id F2DB628C456 for ; Tue, 26 Feb 2008 07:21:33 -0800 (PST) Received: by ug-out-1314.google.com with SMTP id u2so2695661uge.46 for ; Tue, 26 Feb 2008 07:21:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:mime-version:content-type:message-id:sender; bh=f9K+qatj6RvSejqWmCcb+nUNibrFZhxJedh4WL4CDEU=; b=srrZ8HGFf9Ja7FhSyZfwy5Kzyq8vdLD32ezTPpC3i91joXhRcEFaYMAzzWVImjqxFKJLQ5vr21FdnGYCxztbiAX2k377CEZjGPRVCkznuVNMSG3JO0PXPrqSTQk4ELYEZP6yuNEYEaWtGQAm7WZa8ksh/c7ZC9/gjvY0Y+uX8qQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:mime-version:content-type:message-id:sender; b=M/8oGosctAbPOBg4QbBj8hHbeYU8EA2mpn05yqiVpNVezhBkOEPS9qOwxCCnisYRkNQdeBmVA7HMuJCLBwoR+CIzt4inGL8iEnrLxCT6a2OfMItGtoarCuMYGo58k94y/hPQ2r1wlNp1mZFxcbyP9D/tNNc+n2DesqGLahXb0zM= Received: by 10.67.40.15 with SMTP id s15mr4961148ugj.46.1204039287940; Tue, 26 Feb 2008 07:21:27 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id u6sm7707846uge.83.2008.02.26.07.21.26 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Feb 2008 07:21:27 -0800 (PST) From: Julien Laganier To: mext@ietf.org Date: Tue, 26 Feb 2008 16:22:12 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_k6CxH9LIgHnkkoz" Message-Id: <200802261622.12976.julien.IETF@laposte.net> Subject: [MEXT] Fwd: [Mip6] I-D Action:draft-ietf-mip6-whyauthdataoption-05.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --Boundary-00=_k6CxH9LIgHnkkoz Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-00=_k6CxH9LIgHnkkoz Content-Type: message/rfc822; name="forwarded message" Content-Transfer-Encoding: 7bit Content-Description: Internet-Drafts@ietf.org: [Mip6] I-D Action:draft-ietf-mip6-whyauthdataoption-05.txt Content-Disposition: inline Return-Path: Received: from mwinf8216.laposte.net (mwinf8216.laposte.net) by mwinb8204 (SMTP Server) with LMTP; Tue, 26 Feb 2008 00:16:30 +0100 X-Sieve: Server Sieve 2.2 Received: from meplus.info (localhost [127.0.0.1]) by mwinf8216.laposte.net (SMTP Server) with ESMTP id 665D43C0008B for ; Tue, 26 Feb 2008 00:16:30 +0100 (CET) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mwinf8216.laposte.net (SMTP Server) with ESMTP id E55063C0008E for ; Tue, 26 Feb 2008 00:16:29 +0100 (CET) X-ME-UUID: 20080225231629939.E55063C0008E@mwinf8216.laposte.net Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AB3D28D30D; Mon, 25 Feb 2008 15:08:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkySIQkh-E8e; Mon, 25 Feb 2008 15:08:40 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4895B28C6E1; Mon, 25 Feb 2008 14:00:04 -0800 (PST) X-Original-To: mip6@ietf.org Delivered-To: mip6@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7186328C68A; Mon, 25 Feb 2008 14:00:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080225220001.7186328C68A@core3.amsl.com> Date: Mon, 25 Feb 2008 14:00:01 -0800 (PST) Cc: mip6@ietf.org Subject: [Mip6] I-D Action:draft-ietf-mip6-whyauthdataoption-05.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-me-spamlevel: not-spam X-me-spamrating: 7.060984 X-UID: 42247 X-Length: 5961 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Why Authentication Data suboption is needed for MIP6 Author(s) : B. Patil, G. Dommety Filename : draft-ietf-mip6-whyauthdataoption-05.txt Pages : 17 Date : 2008-02-25 Mobile IPv6 defines a set of messages that enable the mobile node (MN) to authenticate and perform registration with its home agent (HA). These authentication signaling messages between the mobile node and home agent are secured by an IPsec SA that is established between the MN and HA. The MIP6 working group has specified a mechanism to secure the binding update and binding acknowledgement messages using an authentication option, similar to the authentication option in Mobile IPv4, carried within the messages that are exchanged between the MN and HA to establish a binding. This document provides the justifications as to why the authentication option mechanism was needed for Mobile IPv6 deployment in certain environments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-whyauthdataoption-05.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-mip6-whyauthdataoption-05.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-mip6-whyauthdataoption-05.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: <2008-02-25134824.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-whyauthdataoption-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-whyauthdataoption-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-25134824.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org http://www.ietf.org/mailman/listinfo/mip6 --NextPart-- --Boundary-00=_k6CxH9LIgHnkkoz Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext --Boundary-00=_k6CxH9LIgHnkkoz-- From mext-bounces@ietf.org Tue Feb 26 15:04:36 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 978D73A68BD; Tue, 26 Feb 2008 15:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.022 X-Spam-Level: X-Spam-Status: No, score=0.022 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2o0UsItat+EI; Tue, 26 Feb 2008 15:04:35 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59D9E28C739; Tue, 26 Feb 2008 15:04:35 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 813483A68BD for ; Tue, 26 Feb 2008 15:04:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nb33G52diDBO for ; Tue, 26 Feb 2008 15:04:33 -0800 (PST) Received: from mailrelay001.isp.belgacom.be (mailrelay001.isp.belgacom.be [195.238.6.51]) by core3.amsl.com (Postfix) with ESMTP id A37823A6CCB for ; Tue, 26 Feb 2008 15:04:32 -0800 (PST) X-Belgacom-Dynamic: yes Received: from 241.19-241-81.adsl-dyn.isp.belgacom.be (HELO PC20005) ([81.241.19.241]) by relay.skynet.be with ESMTP; 27 Feb 2008 00:04:24 +0100 From: "Hesham Soliman" To: "'Acee Lindem'" Date: Wed, 27 Feb 2008 10:04:00 +1000 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <915AF806-4126-4B6F-AA15-C41BC92EBC3B@lindem.com> Thread-Index: Ach3/zgAKBeUn7u+S8KCj3SKN6hElwAx1urQ Cc: mext@ietf.org Subject: Re: [MEXT] ID ACTION:draft-ietf-mext-nemo-v4traversal-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0776577867==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============0776577867== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C5_01C87928.13AEBA90" This is a multi-part message in MIME format. ------=_NextPart_000_00C5_01C87928.13AEBA90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit though. - Page 8, 1st paragraph - It says "If this option is not including..." yet it said previously that the option "MUST" be included. Perhaps, the "MUST" should have been a "MAY". => No I think the MUST is correct. The rest of the sentence explains why the option would not be included despite the "MUST". Specifying "MUST" and providing backward compatibility usually don't go together. So, when you say: In addition, if the binding update included an IPv4 home address option, the binding acknowledgement MUST include the IPv4 address acknowledgment option as described later in this specification. It is contradictory to define the action when it is not specified. If this option is not included in the binding acknowledgement and the IPv4 home address option was included in the binding update, the mobile node MUST assume that the home agent does not support the IPv4 home address option and therefore SHOULD NOT include the option in future binding updates to that home agent address. But I guess you understood my comment but disagree with the logic. I think people will be able to figure it either way but that "MAY" is more correct. => Yes I understand your concern but a "MAY" is the wrong way to go because the option has to be acknowledged. So there are two ways to do this, either we say that the HA MUST support the option and ignore that a bug could cause the HA to not send the option, or we keep the text as is. I think the current text is ultra conservative and covers the MN's actions in case the HA contained a bug that made it not send the option. I don't see any harm in this. - Page 11, IPv4 home address - It says "should be defended by the home agent". This terminology is usually associated for IPv6 Duplicate Address Detection. What does it mean for IPv4? => It's the same thing that an IPv4 HA does, I don't see anything specific to v6. You'll note that RFC 3344 doesn't refer to defending the IPv4 home address on the home link. My point is that the term "defending" is usually associated with MIP6 and IPv6 DAD on the home link. => I guess I see it as an english word. The HA in 3344 defends the address in the same way it does in v6. The word defend is just a word that is not tied to v6. - Page 26, IANA Assignments - Should there be a new registry for TLV-Header encapsulations types? => Sadly yes but I think it needs IETF concensus. That's fine. But if this is an independent number space, it should have its own registry. = > It's in the latest draft. Hesham Thanks, Acee Thanks for your comments, Hesham ------=_NextPart_000_00C5_01C87928.13AEBA90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
though.


- Page=20 8, 1st paragraph - It says "If this option is not
including..." yet
it said=20 previously that the option "MUST" be included.
Perhaps, the "MUST"
should=20 have been a "MAY".

=3D> No I think the MUST is correct. = The rest of=20 the sentence explains why the
option would not be included despite the=20 "MUST".
Specifying "MUST" and providing backward compatibility usually = don't go=20 together. So, when you say:
In addition, if the binding update included an IPv4 home = address=20 option,
the binding acknowledgement MUST include the IPv4 = address
acknowledgment=20 option as described later in this specification.

It = is=20 contradictory to define the action when it is not specified.

If this option is not included in the binding
acknowledgement and the IPv4 home address option was included = in=20 the
binding update, the mobile node MUST assume that the home = agent=20 does
not support the IPv4 home address option and therefore SHOULD = NOT
include the option in future binding updates to that home=20 agent
address.

But I guess you understood my comment but = disagree=20 with the logic. I think people will be able to figure it either way = but that=20 "MAY" is more  
 correct.  
 
=3D> Yes I understand your concern = but a "MAY" is=20 the wrong way to go because the option has to be acknowledged. So = there are=20 two ways to do this, either we say that the HA MUST support = the option=20 and ignore that a bug could cause the HA to not send the option, or we = keep=20 the text as is. I think the current text is ultra conservative and = covers the=20 MN's actions in case the HA contained a bug that made it not send the = option.=20 I don't see any harm in this. 
- Page=20 11, IPv4 home address - It says "should be defended by
the home agent". This
terminology is usually = associated for=20 IPv6 Duplicate Address
Detection. What
does it=20 mean for IPv4?

=3D> It's the same thing that an IPv4 = HA does, I=20 don't see anything specific
to v6.
You'll note that RFC 3344 doesn't refer to defending the IPv4 = home=20 address on the home link. My point is that the term "defending" is = usually=20 associated with MIP6 and IPv6 DAD on the home link.  
 
=3D> I guess I see it as an english word. The HA = in 3344=20 defends the address in the same way it does in v6. The word defend is = just a=20 word that is not tied to v6. 

- Page 26, IANA Assignments - = Should=20 there be a new =
registry for
TLV-Header
encapsulations = types?

=3D> Sadly yes but I think it needs = IETF=20 concensus.
That's fine. But if this is an independent number space, it = should have=20 its own registry.
 
=3D >=20 It's in the latest draft.
 
Hesham 

Thanks,
Acee




Thanks for your comments,
Hesham


------=_NextPart_000_00C5_01C87928.13AEBA90-- --===============0776577867== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext --===============0776577867==-- From mext-bounces@ietf.org Tue Feb 26 15:11:50 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 994CA3A6D09; Tue, 26 Feb 2008 15:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.464 X-Spam-Level: X-Spam-Status: No, score=-0.464 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydcLUO+1xe4Y; Tue, 26 Feb 2008 15:11:49 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97CD728C517; Tue, 26 Feb 2008 15:11:49 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD47828C674 for ; Tue, 26 Feb 2008 15:11:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHEkVgsRUrQx for ; Tue, 26 Feb 2008 15:11:48 -0800 (PST) Received: from mailrelay001.isp.belgacom.be (mailrelay001.isp.belgacom.be [195.238.6.51]) by core3.amsl.com (Postfix) with ESMTP id B861628C517 for ; Tue, 26 Feb 2008 15:11:47 -0800 (PST) X-Belgacom-Dynamic: yes Received: from 241.19-241-81.adsl-dyn.isp.belgacom.be (HELO PC20005) ([81.241.19.241]) by relay.skynet.be with ESMTP; 27 Feb 2008 00:11:40 +0100 From: "Hesham Soliman" To: "'Teco Boot'" Date: Wed, 27 Feb 2008 10:11:16 +1000 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <003d01c8784d$153244d0$3f96ce70$@nl> Thread-Index: Ach4DCVA8/PDNaz0T5Oa2Psj9Ojc7QAP1OogACJrLwA= Cc: mext@ietf.org Subject: Re: [MEXT] I-D ACTION:draft-ietf-mext-nemo-v4traversal-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > A late comment on the TLV encapsulation: > I think the TLV-header UDP encapsulation could be used for > IP Tunneling > Optimization. For this reason, I would like to keep the > overhead as small as > possible. Do we really need the Reserved field? => Yes I think we need the 32-bit alignment. I'm not worried about 1 byte. > And is a length field of only one octet not a little bit to small? > Encapsulated payload could exceed 255 octets. => Yes, good catch, it's a bug, it should be 2 bytes. Hesham > Teco. > > > -----Oorspronkelijk bericht----- > > Van: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] Namens > > Internet-Drafts@ietf.org > > Verzonden: maandag 25 februari 2008 23:15 > > Aan: i-d-announce@ietf.org > > CC: mext@ietf.org > > Onderwerp: [MEXT] I-D > ACTION:draft-ietf-mext-nemo-v4traversal-01.txt > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Mobility EXTensions for > IPv6 Working > > Group of the IETF. > > > > Title : Mobile IPv6 support for dual stack Hosts and > > Routers (DSMIPv6) > > Author(s) : H. Soliman > > Filename : draft-ietf-mext-nemo-v4traversal-01.txt > > Pages : 31 > > Date : 2008-2-25 > > > > The current Mobile IPv6 and NEMO specifications support IPv6 only. > > This specification extends those standards to allow the > registration > > of IPv4 addresses and prefixes, respectively, and the > transport of > > both IPv4 and IPv6 packets over the tunnel to the home > agent. This > > specification also allows the Mobile Node to roam over > both IPv6 and > > IPv4, including the case where Network Address Translation is > > present > > on the path between the mobile node and its home agent. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-v4traversal- > > 01.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-mext-nemo-v4traversal-01.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 > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > http://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Feb 26 17:57:51 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6037228C326; Tue, 26 Feb 2008 17:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.366 X-Spam-Level: X-Spam-Status: No, score=-1.366 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxc3Rk7TW3Me; Tue, 26 Feb 2008 17:57:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15A1E3A6B8D; Tue, 26 Feb 2008 17:57:50 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CAAB3A68F1 for ; Tue, 26 Feb 2008 17:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZU0heiGHzP2O for ; Tue, 26 Feb 2008 17:57:47 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 738DF28C156 for ; Tue, 26 Feb 2008 17:57:21 -0800 (PST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 26 Feb 2008 17:57:15 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1R1vF1s026912; Tue, 26 Feb 2008 17:57:15 -0800 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id m1R1vFqN010251; Wed, 27 Feb 2008 01:57:15 GMT Date: Tue, 26 Feb 2008 17:57:14 -0800 (PST) From: Sri Gundavelli To: Hesham Soliman In-Reply-To: Message-ID: References: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1769; t=1204077435; x=1204941435; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[MEXT]=20I-D=20ACTION=3Adraft-ietf-mext -nemo-v4traversal-01.txt |Sender:=20; bh=otEH862Eg+w2O/ZHkrF/LbjCL8iBLQMfYaYA8GntLzw=; b=zyCwBIy8SoQWRHt4g8WHLvinAupBI9yW9bvHp7CnM/wMJ5iWU7NJouLw2c 0cjjOLy84h15irJQoA1OxWMvdqr3doalVlXntQzudXOZG/V6REQIDWhPGpGm FvoG+qM2HJ; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] I-D ACTION:draft-ietf-mext-nemo-v4traversal-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hesham, We have the "P" flag to the BU/BA messages in Proxy Mobile IPv6. So, this draft should reflect that. I just do not know why IANA is not managing this bit space, we can easily make an error and two drafts will endup with the same bit value. Vijay: One more example why this needs to be under IANA administration. We were debating why there is no registry for MIP4, MIP6 or DHCP protocol message flags. Sri ----------- 3.1.3 The Binding Update Message extensions This specification extends the Binding Update message with two new flags. The flags are shown and described below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|M|R|F|T| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > P Flag after the R flag. 3.2.3 Extensions to the Binding Acknowledgement message This specification extends the binding acknowledgement message with a new flag. The new flag is shown and described below. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status |K|R|T| Reserved| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > P Flag after the R flag. _______________________________________________ MEXT mailing list MEXT@ietf.org http://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Feb 27 00:29:22 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D83E3A6DAE; Wed, 27 Feb 2008 00:29:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[AWL=0.887, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gIA77towd5k; Wed, 27 Feb 2008 00:29:21 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C88F3A6966; Wed, 27 Feb 2008 00:29:21 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 356CF3A6966 for ; Wed, 27 Feb 2008 00:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zG+r766PZVWs for ; Wed, 27 Feb 2008 00:29:14 -0800 (PST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by core3.amsl.com (Postfix) with ESMTP id 426053A6806 for ; Wed, 27 Feb 2008 00:29:13 -0800 (PST) Received: by ug-out-1314.google.com with SMTP id u2so506511uge.46 for ; Wed, 27 Feb 2008 00:29:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=Z7AFv8Hm7o25KZwY2XpS9PZItYEkUvXp8SruTm4aFY0=; b=pSlQYUJdfLnnbMq+ForTYVAKnSgS969rtd3rVspIpyWzq2XV+gCzvNa8BFseEhQibp4RIv6yusUFPsFy6Gf4ND86P+LxqoM3X76rlIKEFKl/ap0HyOlG2CJnZfnoSAFfOW5AfOmo4cQXLlaItQc+gP/KrIfrDbRGCXky3jMRybQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=IYjB7oKoGOIB2c77B1ZiCi78wo1Njh+c/PlsteMXGh/2+KPf2sN8UpOXwR46q+ppzHW4AH9cj484O03AtGjdk9CBBLC3+DemGGbtHDj8vHpjpPthFIh9vBPYE2NtqE5iwMX8GoC0LHci9JvYno72T9DZ958elsxA1JnYbqK74HI= Received: by 10.67.116.15 with SMTP id t15mr726889ugm.21.1204100946888; Wed, 27 Feb 2008 00:29:06 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id 27sm944972ugp.19.2008.02.27.00.29.04 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Feb 2008 00:29:06 -0800 (PST) From: Julien Laganier To: mext@ietf.org Date: Wed, 27 Feb 2008 09:29:52 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200802111135.44252.julien.IETF@laposte.net> <200802121631.35572.julien.IETF@laposte.net> In-Reply-To: <200802121631.35572.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200802270929.53287.julien.IETF@laposte.net> Subject: Re: [MEXT] [Recharter.2] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Folks, The input period to the rechartering process has concluded. Thanks to the participants. The chairs will now discuss with our AD and come back to the WG with an updated charter proposal. Stay tuned. Thanks. --julien and marcelo, MEXT chairs. On Tuesday 12 February 2008, Julien Laganier wrote: > Folks, > > This is the next step in the recharter process. We'd like to get > input from WG participants on what should be the items included in > rechartering, what are their priorities, and who is willing to > sustain the effort. When that step is completed we will take the WG > input and discuss with our AD to move forward with deciding what to > include or not in the charter. Your input should be sent to the list > during the following two weeks, by 2008-02-26. > > Please pick from the list of items below the items you think the WG > should work on, and order them in decreasing priority (just to make > sure, first priority items goes first in the list you're making :). > > List of items: > > Binding Revocation for IP Mobility > MIPv6 home link operation in various SDOs > IP Tunneling Optimization in a Mobile Environment > Generic Notification Message for Mobile IPv6 > GRE requirements for IPv6 mobility > 4283bis to extend MN identifier to other identifiers > Mobile IPv6 Bootstrapping for the Authentication Option Protocol > Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions > Virtual Home Link configuration for Mobile IPv6 > Extend DSMIPv6 Home Network Support > > Also, please prefix each of the items in your list with the letters > E, C and/or R if you're willing to: > > - [E]dit: Are you willing to edit the draft corresponding to the > item. > > - [C]ontribute: Are you willing to propose text for the draft. > > - [R]eview: Are you willing to review new revisions of the draft when > being asked by the chairs. > > As an example, that could be one input list: > > E MIPv6 home link operation in various SDOs > CR Binding Revocation for IP Mobility > R IP Tunneling Optimization in a Mobile Environment > > meaning that the MIPv6 home link is first priority and you volunteer > to edit, Binding revocation is second priority and you're willing to > contribute and review, while IP tunneling optimization is third > priority and you're willing to review. > > Hope this is understandable :) > > Thanks. > > -- julien and marcello, MEXT chairs > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > http://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Feb 27 01:08:58 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C84B128C6E3; Wed, 27 Feb 2008 01:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.34 X-Spam-Level: X-Spam-Status: No, score=-0.34 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fbgH+p9HKVL; Wed, 27 Feb 2008 01:08:53 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FDF53A6DE5; Wed, 27 Feb 2008 01:08:51 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A5CA3A6DD4 for ; Wed, 27 Feb 2008 01:08:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZiEd62kuDOo for ; Wed, 27 Feb 2008 01:08:46 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.192.232]) by core3.amsl.com (Postfix) with ESMTP id E1F993A6DE8 for ; Wed, 27 Feb 2008 01:07:31 -0800 (PST) Received: (qmail 25066 invoked from network); 27 Feb 2008 10:07:22 +0100 Received: from unknown (HELO M90Teco) (217.169.232.206) by server9.hosting2go.nl with SMTP; 27 Feb 2008 10:07:22 +0100 From: "Teco Boot" To: "'Hesham Soliman'" References: <003d01c8784d$153244d0$3f96ce70$@nl> In-Reply-To: Date: Wed, 27 Feb 2008 10:06:42 +0100 Message-ID: <001301c87920$23f0b0f0$6bd212d0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ach4DCVA8/PDNaz0T5Oa2Psj9Ojc7QAP1OogACJrLwAAElUXMA== Content-Language: nl Cc: mext@ietf.org Subject: Re: [MEXT] I-D ACTION:draft-ietf-mext-nemo-v4traversal-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org >>>> TLV-header UDP encapsulation: > > And is a length field of only one octet not a little bit to small? > > Encapsulated payload could exceed 255 octets. > > => Yes, good catch, it's a bug, it should be 2 bytes. Are we sure we need the payload length field? UDP length is already available, and this new length field is simply UDP_Length - 12. I do not prefer a mandatory 32-bit alignment carrying only a single octet type field. What about type dependent padding? For types with 32-bit alignment: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For types with low overhead: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Type | +-+-+-+-+-+-+-+-+ Teco. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Feb 27 03:59:55 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D325D28C70A; Wed, 27 Feb 2008 03:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.441 X-Spam-Level: X-Spam-Status: No, score=-0.441 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwXTOfQHyi4R; Wed, 27 Feb 2008 03:59:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5591A28C47B; Wed, 27 Feb 2008 03:59:50 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7552928C431 for ; Wed, 27 Feb 2008 03:59:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ki173014fbP for ; Wed, 27 Feb 2008 03:59:48 -0800 (PST) Received: from yotelheathrow.etvinteractive.com (unknown [135.196.150.194]) by core3.amsl.com (Postfix) with SMTP id 6DC3528C110 for ; Wed, 27 Feb 2008 03:59:47 -0800 (PST) Received: from [10.6.2.57] (helo=PC20005) by yotelheathrow.etvinteractive.com with esmtp (Exim 3.36 #1 (Debian)) id 1JUKvf-000522-00; Wed, 27 Feb 2008 11:58:31 +0000 From: "Hesham Soliman" To: "'Teco Boot'" Date: Wed, 27 Feb 2008 22:59:13 +1000 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Ach4DCVA8/PDNaz0T5Oa2Psj9Ojc7QAP1OogACJrLwAAElUXMAAIblqQ In-Reply-To: <001301c87920$23f0b0f0$6bd212d0$@nl> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: mext@ietf.org Subject: Re: [MEXT] I-D ACTION:draft-ietf-mext-nemo-v4traversal-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Personally, I *strongly* prefer not to touch this. I would have preferred not to have this silly TLV in the first place but to put it in context (this is my personal opionion of course) this field will not be used by MN. The reason IMO for having this was NETLMM people wanting to encapsulate things like GRE... For those cases saving 3 bytes is not really worth it. Hesham > -----Original Message----- > From: Teco Boot [mailto:teco@inf-net.nl] > Sent: Wednesday, February 27, 2008 7:07 PM > To: 'Hesham Soliman' > Cc: mext@ietf.org > Subject: RE: [MEXT] I-D > ACTION:draft-ietf-mext-nemo-v4traversal-01.txt > > >>>> TLV-header UDP encapsulation: > > > And is a length field of only one octet not a little > bit to small? > > > Encapsulated payload could exceed 255 octets. > > > > => Yes, good catch, it's a bug, it should be 2 bytes. > Are we sure we need the payload length field? > UDP length is already available, and this new length field is simply > UDP_Length - 12. > > I do not prefer a mandatory 32-bit alignment carrying only a > single octet > type field. > What about type dependent padding? > > For types with 32-bit alignment: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Reserved > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > For types with low overhead: > > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > | Type | > +-+-+-+-+-+-+-+-+ > > Teco. > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Feb 27 04:03:59 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E980728C70D; Wed, 27 Feb 2008 04:03:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.442 X-Spam-Level: X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgLSz6tqGnR8; Wed, 27 Feb 2008 04:03:59 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0030A28C4E3; Wed, 27 Feb 2008 04:03:59 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 148DF3A6DE4 for ; Wed, 27 Feb 2008 04:03:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kkf+-OMnsGvq for ; Wed, 27 Feb 2008 04:03:54 -0800 (PST) Received: from yotelheathrow.etvinteractive.com (unknown [135.196.150.194]) by core3.amsl.com (Postfix) with SMTP id D164228C5E8 for ; Wed, 27 Feb 2008 04:03:51 -0800 (PST) Received: from [10.6.2.57] (helo=PC20005) by yotelheathrow.etvinteractive.com with esmtp (Exim 3.36 #1 (Debian)) id 1JUKzb-00056b-00; Wed, 27 Feb 2008 12:02:35 +0000 From: "Hesham Soliman" To: "'Sri Gundavelli'" Date: Wed, 27 Feb 2008 23:03:17 +1000 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Ach45BT82vgZ7gwDQ3izrvalGgNCUwAXQBPQ In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: mext@ietf.org Subject: Re: [MEXT] I-D ACTION:draft-ietf-mext-nemo-v4traversal-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org ok thanks. Hesham > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com] > Sent: Wednesday, February 27, 2008 11:57 AM > To: Hesham Soliman > Cc: mext@ietf.org > Subject: Re: [MEXT] I-D > ACTION:draft-ietf-mext-nemo-v4traversal-01.txt > > Hesham, > > We have the "P" flag to the BU/BA messages in Proxy Mobile IPv6. So, > this draft should reflect that. I just do not know why IANA is not > managing this bit space, we can easily make an error and two drafts > will endup with the same bit value. Vijay: One more example why this > needs to be under IANA administration. We were debating why there is > no registry for MIP4, MIP6 or DHCP protocol message flags. > > Sri > > > ----------- > 3.1.3 The Binding Update Message extensions > > This specification extends the Binding Update message > with two new > flags. The flags are shown and described below. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence # > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |A|H|L|K|M|R|F|T| Reserved | Lifetime > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > P Flag after the R flag. > > > 3.2.3 Extensions to the Binding Acknowledgement message > > This specification extends the binding acknowledgement > message with a > new flag. The new flag is shown and described below. > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Status > |K|R|T| Reserved| > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence # | Lifetime > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > P Flag after the R flag. > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Feb 27 06:19:19 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EA8528C376; Wed, 27 Feb 2008 06:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.46 X-Spam-Level: X-Spam-Status: No, score=0.46 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0i2kmhW6+e0V; Wed, 27 Feb 2008 06:19:17 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADEEE3A6A71; Wed, 27 Feb 2008 06:19:17 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2C663A6E0A for ; Wed, 27 Feb 2008 06:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efgH5zgsII8P for ; Wed, 27 Feb 2008 06:19:15 -0800 (PST) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.121]) by core3.amsl.com (Postfix) with ESMTP id E3F433A6A71 for ; Wed, 27 Feb 2008 06:19:14 -0800 (PST) Received: from [192.168.2.2] (really [66.57.16.220]) by cdptpa-omta01.mail.rr.com with ESMTP id <20080227141907.WOAI10595.cdptpa-omta01.mail.rr.com@[192.168.2.2]>; Wed, 27 Feb 2008 14:19:07 +0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <24E5D46F-5CC3-4533-BFE3-F53F15604AB4@lindem.com> From: Acee Lindem Date: Wed, 27 Feb 2008 09:18:46 -0500 To: Hesham Soliman X-Mailer: Apple Mail (2.753) Cc: mext@ietf.org Subject: Re: [MEXT] ID ACTION:draft-ietf-mext-nemo-v4traversal-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1610658932==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1610658932== Content-Type: multipart/alternative; boundary=Apple-Mail-12-328943116 --Apple-Mail-12-328943116 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Hesham, Sounds good. See one suggestion below. On Feb 26, 2008, at 7:04 PM, Hesham Soliman wrote: >> though. >> >>> >>> - Page 8, 1st paragraph - It says "If this option is not >>> including..." yet >>> it said previously that the option "MUST" be included. >>> Perhaps, the "MUST" >>> should have been a "MAY". >> >> => No I think the MUST is correct. The rest of the sentence >> explains why the >> option would not be included despite the "MUST". > > Specifying "MUST" and providing backward compatibility usually > don't go together. So, when you say: > In addition, if the binding update included an IPv4 home address > option, > the binding acknowledgement MUST include the IPv4 address > acknowledgment option as described later in this specification. > > It is contradictory to define the action when it is not specified. > > If this option is not included in the binding > acknowledgement and the IPv4 home address option was included in the > binding update, the mobile node MUST assume that the home agent does > not support the IPv4 home address option and therefore SHOULD NOT > include the option in future binding updates to that home agent > address. > > But I guess you understood my comment but disagree with the logic. > I think people will be able to figure it either way but that "MAY" > is more > correct. > > => Yes I understand your concern but a "MAY" is the wrong way to go > because the option has to be acknowledged. So there are two ways to > do this, either we say that the HA MUST support the option and > ignore that a bug could cause the HA to not send the option, or we > keep the text as is. I think the current text is ultra conservative > and covers the MN's actions in case the HA contained a bug that > made it not send the option. I don't see any harm in this. If you make another update after the AD review, I would explicitly differentiate between the backward compatibility case and the dual- stack case. In other words, replace "the home agent MUST" with "a home agent supporting this specification MUST". Thanks, Acee > >>> - Page 11, IPv4 home address - It says "should be defended by >>> the home agent". This >>> terminology is usually associated for IPv6 Duplicate Address >>> Detection. What >>> does it mean for IPv4? >> >> => It's the same thing that an IPv4 HA does, I don't see anything >> specific >> to v6. > > You'll note that RFC 3344 doesn't refer to defending the IPv4 home > address on the home link. My point is that the term "defending" is > usually associated with MIP6 and IPv6 DAD on the home link. > > => I guess I see it as an english word. The HA in 3344 defends the > address in the same way it does in v6. The word defend is just a > word that is not tied to v6. > > >> - Page 26, IANA Assignments - Should there be a new >>> registry for >>> TLV-Header >>> encapsulations types? >> >> => Sadly yes but I think it needs IETF concensus. > > That's fine. But if this is an independent number space, it should > have its own registry. > > = > It's in the latest draft. > > Hesham > > Thanks, > Acee > > > >> >> Thanks for your comments, >> Hesham >> > --Apple-Mail-12-328943116 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Hesham,=A0

Sounds good. =A0See one suggestion = below.=A0

On Feb 26, 2008, at 7:04 PM, Hesham = Soliman wrote:

=
though.

=

=
- Page 8, 1st paragraph - = It says "If this option is not
including..." yet
it said previously that the = option "MUST" be included.
Perhaps, the "MUST"
should have been a = "MAY".

=
=3D> No I think the MUST is correct. = The rest of the sentence explains why the
option would not be included despite the = "MUST".

=
Specifying "MUST" and providing backward compatibility usually = don't go together. So, when you say:
In addition, if the = binding update included an IPv4 home address option,
=
the binding acknowledgement MUST include = the IPv4 address
acknowledgment option as described later in = this specification.

It is contradictory to define the action = when it is not specified.

If this option is not included in the = binding
acknowledgement and the = IPv4 home address option was included in the
binding update, the mobile node MUST = assume that the home agent does
not support the IPv4 home address option and therefore SHOULD = NOT
include the option in future = binding updates to that home agent
address.

But I guess you understood my comment but disagree with the = logic. I think people will be able to figure it either way but that = "MAY" is more=A0=A0
=A0correct.=A0=A0
=A0
=3D> Yes I understand your concern but=A0a "MAY" is the = wrong way to go because the option has to be acknowledged. So there are = two ways to do this, either we say that the HA MUST support the=A0option = and ignore that a bug could cause the HA to not send the option, or we = keep the text as is. I think the current text is ultra conservative = and covers the MN's actions in case the HA contained a bug that made = it not send the option. I don't see any=A0harm in = this.=A0

If you = make another update after the AD review, I would explicitly = differentiate between the backward compatibility case and the=A0dual-stack= case.=A0In other words, replace "the home agent MUST" with "a home = agent supporting this specification MUST".=A0

Thanks,
Acee=A0





- Page 11, IPv4 = home address - It says "should be defended by
the home agent". This
terminology is usually associated = for IPv6 Duplicate Address
Detection. What
does it mean for = IPv4?

=
=3D> It's the same thing that an IPv4 = HA does, I don't see anything specific
to v6.

You'll note that RFC = 3344 doesn't refer to defending the IPv4 home address on the home = link. My point is that the term "defending" is usually associated with = MIP6 and IPv6 DAD on the home link.=A0=A0
=A0
=3D> I guess=A0I see it as an english word. The=A0HA in = 3344 defends the address in the same way it does in v6. The word = defend is just a word that is not tied to v6.=A0
=

=

=
- Page 26, IANA = Assignments - Should there be a new
registry for
=
TLV-Header
encapsulations = types?

=
=3D> Sadly yes but I think it needs = IETF concensus.

That's fine. But if this = is an independent number space, it should have its own = registry.
=A0
=3D=A0> It's=A0in the latest = draft.
=A0
=
Hesham=A0

=
Thanks,
Acee



=

Thanks for your comments,
Hesham



= --Apple-Mail-12-328943116-- --===============1610658932== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============1610658932==-- From mext-bounces@ietf.org Wed Feb 27 07:17:58 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B75B28C741; Wed, 27 Feb 2008 07:17:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.837 X-Spam-Level: ** X-Spam-Status: No, score=2.837 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, MIME_HTML_MOSTLY=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECu7Xw6oa3MS; Wed, 27 Feb 2008 07:17:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 766C73A6990; Wed, 27 Feb 2008 07:17:26 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 767E83A6990 for ; Wed, 27 Feb 2008 07:17:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gasCvhyaa9G for ; Wed, 27 Feb 2008 07:17:13 -0800 (PST) Received: from host47.ipowerweb.com (host47.ipowerweb.com [66.235.195.154]) by core3.amsl.com (Postfix) with ESMTP id 90F893A6983 for ; Wed, 27 Feb 2008 07:17:13 -0800 (PST) Received: from [71.239.41.219] (helo=latx1) by host47.ipowerweb.com with esmtpa (Exim 4.63) (envelope-from ) id 1JUOkR-0002w0-8f; Wed, 27 Feb 2008 08:03:12 -0800 From: "Robert J Marks" To: "'Acee Lindem'" , "'Hesham Soliman'" References: <24E5D46F-5CC3-4533-BFE3-F53F15604AB4@lindem.com> Date: Wed, 27 Feb 2008 09:17:13 -0600 Organization: Marks Mobile Consulting, LLC Message-ID: <002d01c87953$d53adbf0$0201a8c0@latx1> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 thread-index: Ach5Ui2jbjFPOICNSEuOaUEYDy+EPgAAlVwg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <24E5D46F-5CC3-4533-BFE3-F53F15604AB4@lindem.com> X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host47.ipowerweb.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - marksmob.com Cc: mext@ietf.org Subject: Re: [MEXT] ID ACTION:draft-ietf-mext-nemo-v4traversal-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0149927425==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============0149927425== Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01C87921.8AA06BF0" This is a multi-part message in MIME format. ------=_NextPart_000_002E_01C87921.8AA06BF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Acee, Perhaps this is a minor point, but I do not agree with your suggested wording. Any draft's requirements apply only to entities supporting that draft. A draft cannot place requirements on an entity that does not support the draft. So all MUST requirements in a draft, by definition, can be assumed to be read as " An entity supporting this draft MUST.." Perhaps a better place to note the problem and MN action is in section 4.4, in the bullet on page 20 dealing with absence of an IPv4 address acknowledgement option when the IPv4 home address option was present in the binding update. Perhaps the following blue text should be added: - If no IPv4 address acknowledgement option were present, and an IPv4 home address option was present in the binding update, the mobile node MUST only create one binding update list entry for its IPv6 home address. The mobile node MUST assume that the home agent does not support the IPv4 home address option and therefore SHOULD NOT include the option in future binding updates to that home agent address. The mobile node MAY include the IPv4 home address option in future binding updates to other home agents. Bob _____ From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Acee Lindem Sent: Wednesday, February 27, 2008 8:19 AM To: Hesham Soliman Cc: mext@ietf.org Subject: Re: [MEXT] ID ACTION:draft-ietf-mext-nemo-v4traversal-00.txt Hi Hesham, Sounds good. See one suggestion below. On Feb 26, 2008, at 7:04 PM, Hesham Soliman wrote: though. - Page 8, 1st paragraph - It says "If this option is not including..." yet it said previously that the option "MUST" be included. Perhaps, the "MUST" should have been a "MAY". => No I think the MUST is correct. The rest of the sentence explains why the option would not be included despite the "MUST". Specifying "MUST" and providing backward compatibility usually don't go together. So, when you say: In addition, if the binding update included an IPv4 home address option, the binding acknowledgement MUST include the IPv4 address acknowledgment option as described later in this specification. It is contradictory to define the action when it is not specified. If this option is not included in the binding acknowledgement and the IPv4 home address option was included in the binding update, the mobile node MUST assume that the home agent does not support the IPv4 home address option and therefore SHOULD NOT include the option in future binding updates to that home agent address. But I guess you understood my comment but disagree with the logic. I think people will be able to figure it either way but that "MAY" is more correct. => Yes I understand your concern but a "MAY" is the wrong way to go because the option has to be acknowledged. So there are two ways to do this, either we say that the HA MUST support the option and ignore that a bug could cause the HA to not send the option, or we keep the text as is. I think the current text is ultra conservative and covers the MN's actions in case the HA contained a bug that made it not send the option. I don't see any harm in this. If you make another update after the AD review, I would explicitly differentiate between the backward compatibility case and the dual-stack case. In other words, replace "the home agent MUST" with "a home agent supporting this specification MUST". Thanks, Acee - Page 11, IPv4 home address - It says "should be defended by the home agent". This terminology is usually associated for IPv6 Duplicate Address Detection. What does it mean for IPv4? => It's the same thing that an IPv4 HA does, I don't see anything specific to v6. You'll note that RFC 3344 doesn't refer to defending the IPv4 home address on the home link. My point is that the term "defending" is usually associated with MIP6 and IPv6 DAD on the home link. => I guess I see it as an english word. The HA in 3344 defends the address in the same way it does in v6. The word defend is just a word that is not tied to v6. - Page 26, IANA Assignments - Should there be a new registry for TLV-Header encapsulations types? => Sadly yes but I think it needs IETF concensus. That's fine. But if this is an independent number space, it should have its own registry. = > It's in the latest draft. Hesham Thanks, Acee Thanks for your comments, Hesham ------=_NextPart_000_002E_01C87921.8AA06BF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Acee,

 

Perhaps this is a minor point, but = I do not agree with your suggested wording.

 

Any draft’s requirements = apply only to entities supporting that draft. A draft cannot place requirements on = an entity that does not support the draft. So all MUST requirements in a = draft, by definition, can be assumed to be read as “ An entity supporting this draft = MUST….”

 

Perhaps a better place to note the = problem and MN action is in section 4.4, in the bullet on page 20 dealing with = absence of an IPv4 address acknowledgement option when the IPv4 home address = option was present in the binding update. Perhaps the following blue text should be = added:

 

   - If no IPv4 address =
acknowledgement option were present, and =
an
     IPv4 home address =
option was present in the binding update, =
the
     mobile node MUST =
only create one binding update list entry for =
its
     IPv6 home =
address.  The mobile node MUST =
assume that the home =
agent
     does not support the IPv4 home =
address option and therefore =
SHOULD
     NOT include the option in future =
binding updates to that home =
agent
     address.  The mobile node MAY include the IPv4 home address =
option
     in future binding =
updates to other home =
agents.

 

 

Bob

From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Acee Lindem
Sent: Wednesday, February = 27, 2008 8:19 AM
To: Hesham Soliman
Cc: mext@ietf.org
Subject: Re: [MEXT] ID ACTION:draft-ietf-mext-nemo-v4traversal-00.txt

 

Hi Hesham,

 

Sounds good. See one suggestion below. =

 

On Feb 26, 2008, at 7:04 PM, Hesham Soliman = wrote:



though.

 

 

- Page 8, 1st paragraph - It says "If this option is not =

including..." yet

it said previously that the option "MUST" be included. =

Perhaps, the "MUST"

should have been a "MAY".

 

=3D> No I think the MUST is correct. The rest of the sentence = explains why the

option would not be included despite the = "MUST".

 

Specifying "MUST" and providing backward compatibility usually don't go together. So, when you say: =

In addition, if the binding update included an = IPv4 home address option,

the binding acknowledgement MUST include the IPv4 address

acknowledgment option as described later in this specification.

 

It is contradictory to define the action when it = is not specified.

 

If this option is not included in the = binding

acknowledgement and the IPv4 home address option = was included in the

binding update, the mobile node MUST assume that = the home agent does

not support the IPv4 home address option and = therefore SHOULD NOT

include the option in future binding updates to = that home agent

address.

 

But I guess you understood my comment but = disagree with the logic. I think people will be able to figure it either way but that "MAY" is more

correct.

=3D> Yes I understand your = concern but a "MAY" is the wrong way to go because the option has to be acknowledged. So there are two ways to do this, either we say that the = HA MUST support the option and ignore that a bug could cause the HA to not send = the option, or we keep the text as is. I think the current text is ultra conservative and covers the MN's actions in case the HA contained a bug = that made it not send the option. I don't see any harm in = this. =

 

If you make another update after the AD review, I would = explicitly differentiate between the backward compatibility case and the dual-stack = case. In other words, replace "the home agent MUST" with "a = home agent supporting this specification MUST".

 

Thanks,

Acee

 

 

 



 

- Page 11, IPv4 home address - It says "should be defended = by

the home agent". This

terminology is usually associated for IPv6 Duplicate Address =

Detection. What

does it mean for IPv4?

 

=3D> It's the same thing that an IPv4 HA does, I don't see = anything specific

to v6.

 

You'll note that RFC 3344 doesn't refer to defending the IPv4 = home address on the home link. My point is that the term = "defending" is usually associated with MIP6 and IPv6 DAD on the home link. =

=3D> I guess I see it as an = english word. The HA in 3344 defends the address in the same way it does in v6. The = word defend is just a word that is not tied to v6. =

 

 

- Page 26, IANA Assignments - Should there be a new

registry for

TLV-Header

encapsulations types?

 

=3D> Sadly yes but I think it needs IETF = concensus.

 

That's fine. But if this is an independent number space, it = should have its own registry.

=3D > It's in the latest = draft.

Hesham =

 

Thanks,

Acee

 

 



 

Thanks for your comments,

Hesham

 

 

 

------=_NextPart_000_002E_01C87921.8AA06BF0-- --===============0149927425== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============0149927425==-- From mext-bounces@ietf.org Wed Feb 27 08:04:59 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11B7728C80A; Wed, 27 Feb 2008 08:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.706 X-Spam-Level: * X-Spam-Status: No, score=1.706 tagged_above=-999 required=5 tests=[AWL=-1.457, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P12qJ3cI-Rzp; Wed, 27 Feb 2008 08:04:58 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89E4D3A6E0F; Wed, 27 Feb 2008 08:04:35 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3EEA28C4E3 for ; Wed, 27 Feb 2008 08:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVTjKFnUc-XO for ; Wed, 27 Feb 2008 08:04:28 -0800 (PST) Received: from web84112.mail.mud.yahoo.com (web84112.mail.mud.yahoo.com [68.142.206.199]) by core3.amsl.com (Postfix) with SMTP id F37023A6C52 for ; Wed, 27 Feb 2008 08:04:23 -0800 (PST) Received: (qmail 58326 invoked by uid 60001); 27 Feb 2008 16:04:17 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=lbcdAxY14qqEfMG4DfSyOQ7hJ7NfDnJGgbRe8N/InXVfhZb8a59Z4QEZYxHBdC0cqYuv18V80DwzNbubhVYJChyap59EHUX5b7YH3YHFaXlEgl8+UAOJqlhFx9X2lopYK/Li0sdSW2gr3JtNwvvpaUzK25/mZqzXMFYiGizwpag=; X-YMail-OSG: HPb63kEVM1nYKNpNy6UIIMzYXguYGDk5MNpgpDkB60sDOZMBj2EKZ.qETL1ZXjY83A-- Received: from [206.16.17.212] by web84112.mail.mud.yahoo.com via HTTP; Wed, 27 Feb 2008 08:04:17 PST X-Mailer: YahooMailRC/818.31 YahooMailWebService/0.7.162 Date: Wed, 27 Feb 2008 08:04:17 -0800 (PST) From: Behcet Sarikaya To: Teco Boot MIME-Version: 1.0 Message-ID: <285050.57753.qm@web84112.mail.mud.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] NEMO-PD - DHCP support on Mobile Network X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1592358337==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1592358337== Content-Type: multipart/alternative; boundary="0-456907668-1204128257=:57753" --0-456907668-1204128257=:57753 Content-Type: text/plain; charset=us-ascii I saw this a bit outdated message and have a few comments: Regards, Behcet ----- Original Message ---- From: Teco Boot To: mext@ietf.org Sent: Thursday, December 6, 2007 12:58:13 PM Subject: [MEXT] NEMO-PD - DHCP support on Mobile Network On the two drafts for NEMO prefix delegation, I wonder how we can support DHCP on Mobile Network. I think there are two options, DHCP Relay or running DHCP Server on MR itself. For the latter, we need not only a prefix, but also data for DHCP options. [behcet] Agreed. A solution not requiring DHCP on MR is probably better approach. Remark on overhead, I think the prefix delegation signaling has low overhead, depending on lifetimes. Lifetime can be a order longer that BU (PD: hours, days, months; BU: seconds, minutes). [behcet] Agreed. However, MR sends BUs more frequently and a BU with prefix request option is sent every now and then. I think the main problem with draft-ietf-nemo-prefix-delegation-02 is that DHCP/AAA PD signaling is missing. I wrote a draft to solve this problem but it was too late to submit it. Teco. -----Inline Attachment Follows----- _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --0-456907668-1204128257=:57753 Content-Type: text/html; charset=us-ascii
I saw this a bit outdated message and have a few comments:


Regards,

Behcet
----- Original Message ----
From: Teco Boot <teco@inf-net.nl>
To: mext@ietf.org
Sent: Thursday, December 6, 2007 12:58:13 PM
Subject: [MEXT] NEMO-PD - DHCP support on Mobile Network

On the two drafts for NEMO prefix delegation, I wonder how we can support DHCP on Mobile Network. I think there are two options, DHCP Relay or running DHCP Server on MR itself. For the latter, we need not only a prefix, but also data for DHCP options.

 

[behcet] Agreed. A solution not requiring DHCP on MR is probably better approach.


Remark on overhead, I think the prefix delegation signaling has low overhead, depending on lifetimes. Lifetime can be a order longer that BU (PD: hours, days, months; BU: seconds, minutes).

 

[behcet] Agreed. However, MR sends BUs more frequently and a BU with prefix request option is sent every now and then.

I think the main problem with draft-ietf-nemo-prefix-delegation-02 is that DHCP/AAA PD signaling is missing.

I wrote a draft to solve this problem but it was too late to submit it.




Teco.

 

 



-----Inline Attachment Follows-----

_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www1.ietf.org/mailman/listinfo/mext

--0-456907668-1204128257=:57753-- --===============1592358337== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============1592358337==-- From mext-bounces@ietf.org Wed Feb 27 08:16:31 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 685D528C7FE; Wed, 27 Feb 2008 08:16:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.391 X-Spam-Level: X-Spam-Status: No, score=-0.391 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ectOPGauJ+2V; Wed, 27 Feb 2008 08:16:25 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D055328C7C1; Wed, 27 Feb 2008 08:16:25 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F028828C77F for ; Wed, 27 Feb 2008 08:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pwb4G5g2aB7 for ; Wed, 27 Feb 2008 08:16:24 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.192.232]) by core3.amsl.com (Postfix) with ESMTP id 6716C28C80B for ; Wed, 27 Feb 2008 08:16:15 -0800 (PST) Received: (qmail 31354 invoked from network); 27 Feb 2008 17:16:06 +0100 Received: from unknown (HELO M90Teco) (217.169.232.206) by server9.hosting2go.nl with SMTP; 27 Feb 2008 17:16:06 +0100 From: "Teco Boot" To: "'Hesham Soliman'" References: <001301c87920$23f0b0f0$6bd212d0$@nl> In-Reply-To: Date: Wed, 27 Feb 2008 17:15:25 +0100 Message-ID: <003e01c8795c$094b96c0$1be2c440$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ach4DCVA8/PDNaz0T5Oa2Psj9Ojc7QAP1OogACJrLwAAElUXMAAIblqQAAGz7UA= Content-Language: nl Cc: mext@ietf.org Subject: Re: [MEXT] I-D ACTION:draft-ietf-mext-nemo-v4traversal-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Hesham, I understand your opinion on alignment. But: I think DSMIP6 provides the basics for what we could use for compressed payload transport. Then, I prefer the one octet type header. But at that time, there would be a limitation by the current specification. Agreed that the length field is redundant? Agreed the payload is not 32-bit aligned? Regards, Teco > -----Oorspronkelijk bericht----- > Van: Hesham Soliman [mailto:Hesham@elevatemobile.com] > Verzonden: woensdag 27 februari 2008 13:59 > Aan: 'Teco Boot' > CC: mext@ietf.org > Onderwerp: RE: [MEXT] I-D ACTION:draft-ietf-mext-nemo-v4traversal- > 01.txt > > Personally, I *strongly* prefer not to touch this. I would have > preferred > not to have this silly TLV in the first place but to put it in context > (this > is my personal opionion of course) this field will not be used by MN. > The > reason IMO for having this was NETLMM people wanting to encapsulate > things > like GRE... For those cases saving 3 bytes is not really worth it. > > Hesham > > > -----Original Message----- > > From: Teco Boot [mailto:teco@inf-net.nl] > > Sent: Wednesday, February 27, 2008 7:07 PM > > To: 'Hesham Soliman' > > Cc: mext@ietf.org > > Subject: RE: [MEXT] I-D > > ACTION:draft-ietf-mext-nemo-v4traversal-01.txt > > > > >>>> TLV-header UDP encapsulation: > > > > And is a length field of only one octet not a little > > bit to small? > > > > Encapsulated payload could exceed 255 octets. > > > > > > => Yes, good catch, it's a bug, it should be 2 bytes. > > Are we sure we need the payload length field? > > UDP length is already available, and this new length field is simply > > UDP_Length - 12. > > > > I do not prefer a mandatory 32-bit alignment carrying only a > > single octet > > type field. > > What about type dependent padding? > > > > For types with 32-bit alignment: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > > 7 8 9 0 1 > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type | Reserved > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > For types with low overhead: > > > > 0 1 2 3 4 5 6 7 > > +-+-+-+-+-+-+-+-+ > > | Type | > > +-+-+-+-+-+-+-+-+ > > > > Teco. > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Feb 27 10:42:00 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF8723A6DE8; Wed, 27 Feb 2008 10:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.751 X-Spam-Level: * X-Spam-Status: No, score=1.751 tagged_above=-999 required=5 tests=[AWL=-1.227, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, MIME_HTML_MOSTLY=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFQrbkPt0p5i; Wed, 27 Feb 2008 10:41:59 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36CA83A698E; Wed, 27 Feb 2008 10:41:59 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCF883A6B01 for ; Wed, 27 Feb 2008 10:41:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wezGLvd+MUAy for ; Wed, 27 Feb 2008 10:41:56 -0800 (PST) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.120]) by core3.amsl.com (Postfix) with ESMTP id 105D53A6A54 for ; Wed, 27 Feb 2008 10:41:55 -0800 (PST) Received: from [192.168.2.2] (really [66.57.16.220]) by cdptpa-omta01.mail.rr.com with ESMTP id <20080227184147.BZTU10595.cdptpa-omta01.mail.rr.com@[192.168.2.2]>; Wed, 27 Feb 2008 18:41:47 +0000 In-Reply-To: <002d01c87953$d53adbf0$0201a8c0@latx1> References: <24E5D46F-5CC3-4533-BFE3-F53F15604AB4@lindem.com> <002d01c87953$d53adbf0$0201a8c0@latx1> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <39C69CC7-28A6-4D8A-AE7D-096AADEAF4D6@lindem.com> From: Acee Lindem Date: Wed, 27 Feb 2008 13:41:26 -0500 To: Robert J Marks X-Mailer: Apple Mail (2.753) Cc: mext@ietf.org, 'Hesham Soliman' Subject: Re: [MEXT] ID ACTION:draft-ietf-mext-nemo-v4traversal-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0113361563==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0113361563== Content-Type: multipart/alternative; boundary=Apple-Mail-16-344703219 --Apple-Mail-16-344703219 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Hi Robert, I'd agree if this were a completely new protocol. However, it is an =20 OPTIONAL enhancement on top of the existing Mobile IPv6 protocol and, =20= as such, must address backward compatibility for the BAs from HAs not =20= supporting the specification. The text you suggest would also help =20 clarify this. Acee On Feb 27, 2008, at 10:17 AM, Robert J Marks wrote: > Hi Acee, > > Perhaps this is a minor point, but I do not agree with your =20 > suggested wording. > > Any draft=92s requirements apply only to entities supporting that =20 > draft. A draft cannot place requirements on an entity that does not =20= > support the draft. So all MUST requirements in a draft, by =20 > definition, can be assumed to be read as =93 An entity supporting =20 > this draft MUST=85.=94 > > Perhaps a better place to note the problem and MN action is in =20 > section 4.4, in the bullet on page 20 dealing with absence of an =20 > IPv4 address acknowledgement option when the IPv4 home address =20 > option was present in the binding update. Perhaps the following =20 > blue text should be added: > > - If no IPv4 address acknowledgement option were present, and an > IPv4 home address option was present in the binding update, the > mobile node MUST only create one binding update list entry for =20= > its > IPv6 home address. The mobile node MUST assume that the home =20 > agent > does not support the IPv4 home address option and therefore =20 > SHOULD > NOT include the option in future binding updates to that home =20 > agent > address. The mobile node MAY include the IPv4 home address =20 > option > in future binding updates to other home agents. > > > Bob > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On =20 > Behalf Of Acee Lindem > Sent: Wednesday, February 27, 2008 8:19 AM > To: Hesham Soliman > Cc: mext@ietf.org > Subject: Re: [MEXT] ID ACTION:draft-ietf-mext-nemo-v4traversal-00.txt > > Hi Hesham, > > Sounds good. See one suggestion below. > > On Feb 26, 2008, at 7:04 PM, Hesham Soliman wrote: > > >> though. >> >>> >>> - Page 8, 1st paragraph - It says "If this option is not >>> including..." yet >>> it said previously that the option "MUST" be included. >>> Perhaps, the "MUST" >>> should have been a "MAY". >> >> =3D> No I think the MUST is correct. The rest of the sentence =20 >> explains why the >> option would not be included despite the "MUST". >> >> Specifying "MUST" and providing backward compatibility usually =20 >> don't go together. So, when you say: >> In addition, if the binding update included an IPv4 home address =20 >> option, >> the binding acknowledgement MUST include the IPv4 address >> acknowledgment option as described later in this specification. >> >> It is contradictory to define the action when it is not specified. >> >> If this option is not included in the binding >> acknowledgement and the IPv4 home address option was included in the >> binding update, the mobile node MUST assume that the home agent does >> not support the IPv4 home address option and therefore SHOULD NOT >> include the option in future binding updates to that home agent >> address. >> >> But I guess you understood my comment but disagree with the logic. =20= >> I think people will be able to figure it either way but that "MAY" =20= >> is more >> correct. >> =3D> Yes I understand your concern but a "MAY" is the wrong way to =20= >> go because the option has to be acknowledged. So there are two =20 >> ways to do this, either we say that the HA MUST support the option =20= >> and ignore that a bug could cause the HA to not send the option, =20 >> or we keep the text as is. I think the current text is ultra =20 >> conservative and covers the MN's actions in case the HA contained =20 >> a bug that made it not send the option. I don't see any harm in this. > > If you make another update after the AD review, I would explicitly =20 > differentiate between the backward compatibility case and the dual-=20 > stack case. In other words, replace "the home agent MUST" with "a =20 > home agent supporting this specification MUST". > > Thanks, > Acee > > > > > > >>> - Page 11, IPv4 home address - It says "should be defended by >>> the home agent". This >>> terminology is usually associated for IPv6 Duplicate Address >>> Detection. What >>> does it mean for IPv4? >> >> =3D> It's the same thing that an IPv4 HA does, I don't see anything =20= >> specific >> to v6. > > You'll note that RFC 3344 doesn't refer to defending the IPv4 home =20 > address on the home link. My point is that the term "defending" is =20 > usually associated with MIP6 and IPv6 DAD on the home link. > =3D> I guess I see it as an english word. The HA in 3344 defends the =20= > address in the same way it does in v6. The word defend is just a =20 > word that is not tied to v6. > > >> - Page 26, IANA Assignments - Should there be a new >>> registry for >>> TLV-Header >>> encapsulations types? >> >> =3D> Sadly yes but I think it needs IETF concensus. > > That's fine. But if this is an independent number space, it should =20 > have its own registry. > =3D > It's in the latest draft. > Hesham > > Thanks, > Acee > > > > > > Thanks for your comments, > Hesham > > > --Apple-Mail-16-344703219 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252 Hi Robert,
I'd agree if this were a completely new protocol. = However, it is an OPTIONAL enhancement on top of the existing Mobile = IPv6 protocol and, as such, must address backward compatibility for the = BAs from HAs not supporting the specification. The text you suggest = would also help clarify this.=A0

Acee=A0

=A0

= On Feb 27, 2008, at 10:17 AM, Robert J Marks wrote:

Hi = Acee,
=A0
Perhaps this is a minor point, but I = do not agree with your suggested = wording.
=A0
Any draft=92s requirements apply only = to entities supporting that draft. A draft cannot place requirements on = an entity that does not support the draft. So all MUST requirements in a = draft, by definition, can be assumed to be read as =93 An entity=A0supporting this draft=A0MUST=85.=94
Perhaps a better place to note the problem and MN action = is in section 4.4, in the bullet on page 20 dealing with absence of an = IPv4 address acknowledgement option when the IPv4 home address option = was present in the binding update. Perhaps the following=A0blue=A0text should be = added:
=A0
=A0=A0 =
- If no IPv4 address acknowledgement option were present, and =
an
=A0=A0=A0=A0 IPv4 =
home address option was present in the binding update, =
the
=A0=A0=A0=A0 mobile =
node MUST only create one binding update list entry for =
its
=A0=A0=A0=A0 IPv6 =
home address. =A0The =
mobile node MUST assume that the home =
agent
=A0=A0=A0 =A0does not support =
the IPv4 home address option and therefore =
SHOULD
=A0=A0=A0 =A0NOT include the option in future binding updates to =
that home agent
=A0 =A0=A0=A0address.=A0 The mobile node MAY include the IPv4 home address =
option
=A0=A0=A0 =A0in =
future binding updates =A0
=A0mext-bounces@ietf.org [mailto:mext-bounces@ietf.org]=A0On Behalf Of=A0Acee = Lindem
Sent:=A0Wednesday, February 27, 2008 = 8:19 AM
To:=A0Hesham Soliman
Cc:=A0mext@ietf.org
Subject:=A0Re: [MEXT] ID = ACTION:draft-ietf-mext-nemo-v4traversal-00.txt
=A0
Hi = Hesham,
Sounds good. See one = suggestion below.
On Feb 26, = 2008, at 7:04 PM, Hesham Soliman = wrote:
- Page 8, 1st = paragraph - It says "If this option is = not
including..." = yet
it said = previously that the option "MUST" be = included.
Perhaps, the = "MUST"
should have = been a "MAY".
=3D> No I = think the MUST is correct. The rest of the sentence explains why = the
option would = not be included despite the = "MUST".
Specifying = "MUST" and providing backward compatibility usually don't go together. = So, when you = say:
In addition, if the binding update = included an IPv4 home address = option,
the binding acknowledgement MUST include the IPv4 = address
acknowledgment option as described later = in this specification.
=A0
It is contradictory to define the action when it is not = specified.
If this option is not = included in the binding
acknowledgement and the IPv4 home address = option was included in the
binding update, the mobile node MUST = assume that the home agent = does
not support the IPv4 home address option and therefore = SHOULD NOT
include the option in future binding = updates to that home agent
But I guess you understood my comment but disagree with the = logic. I think people will be able to figure it either way but that = "MAY" is more
=3D> Yes = I understand your concern but a "MAY" is the wrong way to go because the = option has to be acknowledged. So there are two ways to do this, either = we say that the HA MUST support the option and ignore that a bug could = cause the HA to not send the option, or we keep the text as is. I think = the current text is ultra conservative and covers the MN's actions in = case the HA contained a bug that made it not send the option. I don't = see any harm in this.
If you make = another update after the AD review, I would explicitly differentiate = between the backward compatibility case and the dual-stack case. In = other words, replace "the home agent MUST" with "a home agent supporting = this specification MUST".
- Page 11, IPv4 home address - It says = "should be defended by
the home agent". = This
terminology = is usually associated for IPv6 Duplicate = Address
Detection. = What
does it mean = for IPv4?
=3D> It's = the same thing that an IPv4 HA does, I don't see anything = specific
to = v6.
You'll note = that RFC 3344 doesn't refer to defending the IPv4 home address on the = home link. My point is that the term "defending" is usually associated = with MIP6 and IPv6 DAD on the home = link.
=3D> I guess I see it as an = english word. The HA in 3344 defends the address in the same way it does = in v6. The word defend is just a word that is not tied to = v6.
- Page 26, IANA Assignments - Should there = be a new
registry = for
encapsulations = types?
=3D> Sadly = yes but I think it needs IETF = concensus.
That's fine. = But if this is an independent number space, it should have its own = registry.
=3D > = It's in the latest draft.
Thanks for = your comments,
X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0101728C59E; Wed, 27 Feb 2008 17:49:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.381 X-Spam-Level: X-Spam-Status: No, score=-0.381 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1WfS7-pxyNl; Wed, 27 Feb 2008 17:49:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E88EC3A6A88; Wed, 27 Feb 2008 17:49:25 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E0573A6993; Wed, 27 Feb 2008 17:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIvqafpNE-V0; Wed, 27 Feb 2008 17:49:18 -0800 (PST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by core3.amsl.com (Postfix) with ESMTP id 67D4B3A695A; Wed, 27 Feb 2008 17:49:18 -0800 (PST) Received: from ep_ms5_bk (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 <0JWX00D51E9CZU@mailout1.samsung.com>; Thu, 28 Feb 2008 10:46:24 +0900 (KST) Received: from ep_spt02 (ms5.samsung.com [203.254.225.113]) by ms5.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JWX00JA0E9CGC@ms5.samsung.com>; Thu, 28 Feb 2008 10:46:24 +0900 (KST) Content-return: prohibited Date: Thu, 28 Feb 2008 01:46:24 +0000 (GMT) From: Heejin Jang To: Bud Millwood Message-id: <27156126.196941204163184300.JavaMail.weblogic@epml14> MIME-version: 1.0 MIME-version: 1.0 X-Priority: 3 Msgkey: 20080228014446181@heejin.jang X-MTR: 20080228014446181@heejin.jang X-EPLocale: ko_KR.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-EPHeader: ML Cc: "dhcwg@ietf.org" , draft-ietf-mip6-hiopt@tools.ietf.org, "mext@ietf.org" Subject: Re: [MEXT] [dhcwg] Last Call: draft-ietf-mip6-hiopt (DHCP Options for Home Information Discovery in MIPv6) to Proposed Standard X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: heejin.jang@samsung.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, Bud. It's a good point. When designing the sub-option 2, we intended to make it (Home Network Prefix Sub-options) specific to the sub-option 2. However, it seems that we don't need to make such a limitation. We'll change the 'Home Network Prefix Sub-options' to 'Home Network Prefix options' in the figure for message format, and revise the texts as below. In section 3.1.1 Old: Home Network Prefix Sub-options Options associated with the IPv6 Home Network Prefix. Currently there is no sub-option available. New: Home Network Prefix options Options associated with the IPv6 Home Network Prefix. Thanks for your kind and helpful comment. :) -Best regards, Heejin. > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > On Behalf Of Bud Millwood > Sent: Wednesday, February 27, 2008 6:36 PM > To: dhcwg@ietf.org > Cc: mext@ietf.org > Subject: Re: [dhcwg] Last Call: draft-ietf-mip6-hiopt (DHCP > Options for HomeInformation Discovery in MIPv6) to Proposed Standard > > On Tuesday 26 February 2008 15:12, Jari Arkko wrote: > > > FYI -- this draft is being Last Called for the second time, due to > > having changed substantially as a result of earlier reviews. > > > > > The IESG has received a request from the Mobility for > IPv6 WG (mip6) > > > to consider the following document: > > > > > > - 'DHCP Options for Home Information Discovery in MIPv6 ' > > > as a Proposed Standard > > Section 3.1.1, the encoding for suboption 2 is the "standard" > encoding for a prefix with one exception that I can see: > > "Home Network Prefix Sub-options" > > This option is almost exactly like option 26 with one major > exception: The "options" part of this suboption are > subencoded options, not top-level DHCPv6 options like with option 26. > > Is that really right? The text for suboption 2 says: "Options > associated with the IPv6 Home Network Prefix. Currently there > is no sub-option available." > > That implies that this area is open for further definition of > options, whereas in the case of option 26, my understanding > was that any options found in that option would *not* be > specific to that option. > > - Bud > > Bud Millwood > Weird Solutions, Inc. > http://www.weird-solutions.com > tel: +46 8 758 3700 > fax: +46 8 758 3687 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Feb 27 23:38:53 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE6963A69F9; Wed, 27 Feb 2008 23:38:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.634 X-Spam-Level: X-Spam-Status: No, score=-0.634 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uaPkaWmfqLSP; Wed, 27 Feb 2008 23:38:47 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 376B43A6A20; Wed, 27 Feb 2008 23:38:47 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2D8F3A6A20; Wed, 27 Feb 2008 23:38:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qljfljafpzTi; Wed, 27 Feb 2008 23:38:43 -0800 (PST) Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id CB2F43A6A43; Wed, 27 Feb 2008 23:38:43 -0800 (PST) Received: from [127.0.0.1] ([98.207.82.216]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Feb 2008 23:38:36 -0800 Message-ID: <47C664F9.6020301@azairenet.com> Date: Wed, 27 Feb 2008 23:38:33 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: mext@ietf.org, Netlmm Content-Type: multipart/mixed; boundary="------------050601040901030006010703" X-OriginalArrivalTime: 28 Feb 2008 07:38:36.0675 (UTC) FILETIME=[EDA3A530:01C879DC] Subject: [MEXT] [Fwd: RFC 5149 on Service Selection for Mobile IPv6] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --------------050601040901030006010703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI. --------------050601040901030006010703 Content-Type: message/rfc822; name="RFC 5149 on Service Selection for Mobile IPv6.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="RFC 5149 on Service Selection for Mobile IPv6.eml" Received: from mail.ietf.org ([64.170.98.32]) by mail2.azairenet.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Feb 2008 11:47:06 -0800 Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F7AC28C8F1; Wed, 27 Feb 2008 11:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+xMCMiW3iKv; Wed, 27 Feb 2008 11:41:41 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6B463A6E82; Wed, 27 Feb 2008 11:39:42 -0800 (PST) X-Original-To: ietf-announce@core3.amsl.com Delivered-To: ietf-announce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20DFF3A6909 for ; Wed, 27 Feb 2008 11:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFllAYvgqUGQ for ; Wed, 27 Feb 2008 11:39:40 -0800 (PST) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 49B5A3A6E71 for ; Wed, 27 Feb 2008 11:39:40 -0800 (PST) Received: by bosco.isi.edu (Postfix, from userid 70) id 11247116EB6; Wed, 27 Feb 2008 11:39:34 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 5149 on Service Selection for Mobile IPv6 From: rfc-editor@rfc-editor.org Message-Id: <20080227193934.11247116EB6@bosco.isi.edu> Date: Wed, 27 Feb 2008 11:39:34 -0800 (PST) Cc: rfc-editor@rfc-editor.org X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Announcements List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ietf-announce-bounces@ietf.org Errors-To: ietf-announce-bounces@ietf.org Return-Path: ietf-announce-bounces@ietf.org X-OriginalArrivalTime: 27 Feb 2008 19:47:10.0352 (UTC) FILETIME=[8A9BA900:01C87979] A new Request for Comments is now available in online RFC libraries. RFC 5149 Title: Service Selection for Mobile IPv6 Author: J. Korhonen, U. Nilsson, V. Devarapalli Status: Informational Date: February 2008 Mailbox: jouni.korhonen@teliasonera.com, ulf.s.nilsson@teliasonera.com, vijay.devarapalli@azairenet.com Pages: 9 Characters: 18746 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-korhonen-mip6-service-06.txt URL: http://www.rfc-editor.org/rfc/rfc5149.txt In some Mobile IPv6 deployments, identifying the mobile node or the mobility service subscriber is not enough to distinguish between multiple services possibly provisioned to the said mobile node and its mobility service subscription. A capability to specify different services in addition to the mobile node identity can be leveraged to provide flexibility for mobility service providers on provisioning multiple services to one mobility service subscription. This document describes a Service Selection Mobility Option for both conventional Mobile IPv6 and Proxy Mobile IPv6 that is intended to assist home agents to make a specific service selection for the mobility service subscription during the binding registration procedure. This memo provides information for the Internet community. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --------------050601040901030006010703 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --------------050601040901030006010703-- From mext-bounces@ietf.org Thu Feb 28 00:39:49 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AB2128C409; Thu, 28 Feb 2008 00:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JyPsTe8Dn7a; Thu, 28 Feb 2008 00:39:44 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E04313A6A28; Thu, 28 Feb 2008 00:39:44 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12DEE3A6B0A for ; Mon, 18 Feb 2008 03:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QPQGAn04cni for ; Mon, 18 Feb 2008 03:05:50 -0800 (PST) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by core3.amsl.com (Postfix) with ESMTP id E2DB528C207 for ; Mon, 18 Feb 2008 03:05:49 -0800 (PST) Received: from [221.219.117.104] (helo=IBM-x60) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.63) (envelope-from ) id 1JR3pX-0006Kw-Mh; Mon, 18 Feb 2008 19:06:40 +0800 Date: Mon, 18 Feb 2008 19:05:42 +0800 From: "xuke" To: "mext" Organization: Institute of Computer Network and Technology, Tsinghua University X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Message-Id: X-Mailman-Approved-At: Thu, 28 Feb 2008 00:39:43 -0800 Cc: xuke Subject: Re: [MEXT] [Recharter.2] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: xuke@mail.tsinghua.edu.cn List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi All, I would like to support: [CR] Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions Regards, xuke Tsinghua University On Feb 12, 2008 7:31 AM, Julien Laganier wrote: > Folks, > > This is the next step in the recharter process. We'd like to get input > from WG participants on what should be the items included in > rechartering, what are their priorities, and who is willing to > sustain the effort. When that step is completed we will take the WG > input and discuss with our AD to move forward with deciding what to > include or not in the charter. Your input should be sent to the list > during the following two weeks, by 2008-02-26. > > Please pick from the list of items below the items you think the WG > should work on, and order them in decreasing priority (just to make > sure, first priority items goes first in the list you're making :). > > List of items: > > Binding Revocation for IP Mobility > MIPv6 home link operation in various SDOs > IP Tunneling Optimization in a Mobile Environment > Generic Notification Message for Mobile IPv6 > GRE requirements for IPv6 mobility > 4283bis to extend MN identifier to other identifiers > Mobile IPv6 Bootstrapping for the Authentication Option Protocol > Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions > Virtual Home Link configuration for Mobile IPv6 > Extend DSMIPv6 Home Network Support > > Also, please prefix each of the items in your list with the letters E, C > and/or R if you're willing to: > > - [E]dit: Are you willing to edit the draft corresponding to the > item. > > - [C]ontribute: Are you willing to propose text for the draft. > > - [R]eview: Are you willing to review new revisions of the draft when > being asked by the chairs. > > As an example, that could be one input list: > > E MIPv6 home link operation in various SDOs > CR Binding Revocation for IP Mobility > R IP Tunneling Optimization in a Mobile Environment > > meaning that the MIPv6 home link is first priority and you volunteer to > edit, Binding revocation is second priority and you're willing to > contribute and review, while IP tunneling optimization is third > priority and you're willing to review. > > Hope this is understandable :) > > Thanks. > > -- julien and marcello, MEXT chairs > _______________________________________________ > MEXT mailing list > MEXT at ietf.org > http://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Feb 28 00:39:53 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0433128C4B9; Thu, 28 Feb 2008 00:39:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.8 X-Spam-Level: * X-Spam-Status: No, score=1.8 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MANGLED_TOOL=2.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrZ9-CZYQSjD; Thu, 28 Feb 2008 00:39:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 672F028C215; Thu, 28 Feb 2008 00:39:45 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2B8228C6D0 for ; Fri, 22 Feb 2008 06:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GIfTFJhgfyS for ; Fri, 22 Feb 2008 06:30:00 -0800 (PST) Received: from mail.wakikawa.net (airmax.sfc.wide.ad.jp [203.178.143.74]) by core3.amsl.com (Postfix) with SMTP id A0CB128CBF1 for ; Fri, 22 Feb 2008 06:29:22 -0800 (PST) Received: (qmail 3209 invoked from network); 22 Feb 2008 23:24:22 +0000 Received: from unknown (HELO localhost) (127.0.0.1) by 0 with SMTP; 22 Feb 2008 23:24:22 +0000 Resent-To: mext@ietf.org From: Ryuji Wakikawa To: Vijay Devarapalli In-Reply-To: <47BE0511.5010409@azairenet.com> Resent-From: Ryuji Wakikawa References: <47AC84E3.2030605@azairenet.com> <47BE0511.5010409@azairenet.com> Message-Id: Resent-Date: Fri, 22 Feb 2008 23:29:17 +0900 Mime-Version: 1.0 (Apple Message framework v915) Date: Fri, 22 Feb 2008 11:16:19 +0900 X-Mailer: Apple Mail (2.915) Resent-Message-Id: <20080222142922.A0CB128CBF1@core3.amsl.com> X-Mailman-Approved-At: Thu, 28 Feb 2008 00:39:43 -0800 Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] WGLC for draft-ietf-monami6-multiplecoa-05.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi George and Vijay, I add my comments inline. I deleted some paragraph which I agreed with George and/or Vijay. On 2008/02/22, at 8:11, Vijay Devarapalli wrote: > Hi George, > > Thanks again for a very detailed review. > > I am not responding to your high level comments on this email. I > will respond to those on the thread between you and Ryuji. For > the comments you made inline in the text, please see below. > > George Tsirtsis wrote: >> The mobile node MUST include a Binding Identifier mobility option in >> the Care-of Test Init message. It MUST NOT set any flags in the >> mobility option. The receiver (i.e. correspondent node) will >> calculate a care-of Keygen token as specified in [RFC-3775] and >> reply >> with a Care-of Test message, with the Binding Identifier mobility >> option as described in Section 6.2. When the mobile node receives >> the Care-of Test message, the message is verified as in [RFC-3775]. >> If a Binding Identifier mobility option is not present in the CoT >> message in reply to the CoTI message that included a Binding >> Identifier mobility option, the mobile node must assume that the >> correspondent node does not support Multiple Care-of Address >> registration. Thus, the mobile node MUST NOT use a Binding >> Identifier mobility option in any future Binding Updates to that >> correspondent node. The mobile node MAY skip re-sending regular >> CoTI >> message and keep the received care-of Keygen token for the regular >> Binding Update. >> GT> Should we also say anything about Enhanced RO based on RFC4866? > > No opinion on this. I don't have opinion neither. > > >> 5.6.2. Using only Interface attached to the Visited Link >> The mobile node returns home and shuts down the interface attached >> to >> the home link as shown in Figure 10. Before shutting down the >> interface, any binding for the care-of address previously associated >> with the interface should be deleted. To delete the binding cache >> entry, the mobile node MUST send a de-registration Binding Update >> with the lifetime set to zero and include the corresponding BID >> information. This scenario is not the most efficient because all >> the >> traffic to and from the mobile node is going through the bi- >> directional tunnel, whereas the mobile node is now accessible at one >> hop on the home link from its home agent. >> GT> This scenario is still confusing to me. My understanding is that >> in this scenario the MN simply DOES NOT connect to the home link. If >> the MN connected to a link that is identified or detected to be its >> home link, it simply disconnects without sending a BU to the HA. So, >> as far as the HA is concerned the MN is NOT connected at its home >> link >> and operations continue as normal. The paragraph above, however, says >> something different which does not match my understanding at all. >> Am I >> confused? > > No. It is possible for the mobile node to just shut down the > interface with which it is attached to the home link. But there > is still a binding at the home agent that binds the home address > to the care-of address previously associated with this interface. > The above paragraph, I think, describes how to delete that > binding. As soon as the interface is attached to the home link, the MN should explicitly delete the previous binding of that interface if necessary. > > > >> The 'H' flag MUST be set in the BID mobility option. The 'C' >> flag MUST NOT be set and the care-of address field MUST NOT be >> included. When the 'H' flag is set, the home agent recognizes that >> the mobile node wants to continue using interfaces attached to both >> home and visited links. If the 'H' flag is unset, the home agent >> deletes either all the bindings or the binding corresponding to the >> BID included in the Binding Identifier mobility option. >> When the home agent sends the Binding Acknowledgement, it MUST set >> the status value to either 0 [Binding Update Accepted] or to [MCOA >> RETURNHOME WO/NDP (TBD)] in the BID mobility option depending on >> home >> agent configuration at the home link. The new values are: >> o Binding Update Accepted (0): NDP is permitted for the home >> address >> at the home link. This is regular returning home operation of >> [RFC-3775] >> o MCOA RETURNHOME WO/NDP (TBD): NDP is prohibited for the home >> address at the home link >> When the home agent is the only router at the home link, it can >> intercept all the packets by normal IP routing without using >> proxying >> for the home address. It stops proxy ND for the requested home >> address and responds with the [Binding Update Accepted] status value >> to the mobile node. The neighbor cache entry for the mobile node is >> created by the regular exchange of Neighbor Solicitation and >> Neighbor >> Advertisement. If the home agent is not the only router on the home >> link, it MUST continue defending the home address by proxy neighbor >> discovery in order to intercept the mobile node's traffic. The home >> agent, then, returns [MCOA RETURNHOME WO/NDP] value in the Status >> field of the BID mobility option. The home agent also learns the >> mobile node's layer-2 address (i.e., MAC address) during this >> binding >> de-registration. It stores the learnt layer-2 address in a neighbor >> cache entry for the mobile node so that it can construct the layer-2 >> header for the packets meant for the mobile node and forwards them >> directly to the mobile node's interface attached to the home link. >> According to [RFC-3775], the mobile node MUST NOT assign the home >> address to the interface attached to the home link and MUST NOT >> attempt NDP operations for the home address before the completion of >> binding de-registration. It MUST NOT send and reply to Neighbor >> Solicitation for the home address. The home address MUST be >> tentative address at this moment until it receives Binding >> Acknowledgement with success status value. >> When the mobile node receives the Binding Acknowledgement and BID >> mobility option, it assigns home address to the interface attached >> to >> the home link according to the status field of the BID. If the >> value >> is [Binding Update Accepted], the mobile node can start defending >> the >> home address using regular Neighbor Discovery. >> If the mobile node receives the [MCOA RETURNHOME WO/NDP], it MUST >> NOT >> defend its home address on the home link. When the mobile node >> sends >> packets from the interface attached to the home link, it MUST learn >> the layer 2 address (i.e., MAC address) of the next hop (i.e. >> default >> router, it can be home agent) during the binding de- registration >> and >> construct the packet including layer 2 header with the learnt >> layer-2 >> address of the default router or the home agent. >> GT> Something needs to be said about the lifetime of the BU with 'H' >> flag set. If the MN has to send a de-reg to the HA with Lifetime=0 >> and >> 'H' set, for how ling is this state valid? What happens to the >> lifetime of the other bindings?? > > Needs to be discussed as part of overall binding lifetime issue. good point. We should treat the lifetime of that home state and the other real bindings separately. When the MN sends a BU with H flag set, it should not use bulk registration and send it as an individual BU. The lifetime field MUST be set to the appropriate lifetime for that home state. HA can always treat this BU as de-registration BU because the source address and home address are same. In addition to that, H flag can also tell this is deregistration BU. MN should renew the home state while it is at the home link. If you are fine with this, I will prepare for additional texts. >> Beside the difference in the size of packets, there is no difference >> between the two. The routing path does not get affected. With >> extensions specified in this document, the mobile node is capable of >> using multiple care-of addresses for outgoing packets. This is a >> problem on the home agent side because it must verify the Care-of >> address for all the packets received from the mobile node (i.e. >> ingress filtering). When the mobile node uses the Home Address >> option, the home agent MAY check the care-of address in the packet >> with the registered binding entries. This causes additional >> overhead >> to the home agent. Therefore, the mobile node SHOULD use the bi- >> directional tunnel even if it registers a binding(s) to the home >> agent. >> GT> This confuses me a bit. Is there anything different from RFC3775? >> Why is this section needed? When MN establishes a tunnel with its HA and sends packets to the HA, will MN should send packets with HoA option (RO) or IP-in-IP (non RO)? RFC3775 does not clearly explain this. HA can be treated as a CN. The way of address verification is slightly different between packets sent with HoA option and with IP-in-IP. > I think it should be deleted. When packets are tunneled to the > home agent, the home agent checks if the source address on the > outer IPv6 header matches the care-of address in the binding > cache entry. Most of implementation verifies the source address with the tunnel states (Not with BC database) > The only exception is when the packet contains > a binding update. So the sentence in the above paragraph is > actually not valid. This check MUST be done with the binding cache database. This paragraph is to explain how to avoid the overhead of the address verification in MCoA. If the BC database is used for source address verification, HA might search the BC database recursively to match the CoA and the source address. It is because BID (to match the exact BC) is not stored in the data packets. The cost can be O-(n) if 'n' bindings are registered. Therefore, HA should verify the address validity with the tunnel states. HA can verify the packets with the tunnel states by comparing the source and destination pair. The cost can be decreased to O-(1). HA MUST check all the packets from MNs, this additional overhead of MCoA is not negligible. It might be implementation issue though. > >> 6. Home Agent and Correspondent Node Operation >> 6.1. Searching Binding Cache with Binding Identifier >> If either a correspondent node or a home agent has multiple bindings >> for a mobile node in their binding cache database, it can use any of >> the bindings to communicate with the mobile node. How to select the >> most suitable binding from the binding cache database is out of >> scope >> in this document. >> Whenever a correspondent node searches a binding cache for a home >> address, it SHOULD uses both the home address and the BID as the >> search key if it knows the corresponding BID. >> GT> This is a bid strange. Why would the HA or CN use a BID as a key? >> The HoA is used as a key because the HA/CN want to send a packet with >> the HoA as destination address, which causes Mobile IP to use the HoA >> as a key to find an appropriate CoA. I do not think that the BIDs are >> needed for this. With MCoA, the only difference is that a lookup of >> the HoA will return multiple CoAs; and which one is used is out of >> scope for this document. >> GT> So, the BIDs are only used as key when the receiver processes a >> BU >> message including a BID Mobility option. Is this what this is about? Yes, this was my intention. This document does not deal with flow distribution (i.e. how to decide which CoA is used for data packets). >> > I think the text here assumes that the HA or the CN when > trying to send/forward a packet, the packet gets mapped (based > on the source/destination IP, source/destination port, and > protocol) to a particular BID. Then the BID is used as a key > along with the home address. We should not assume any flow distribution scheme in the MCoA. > This needs some more discussion, before we can decide what > text goes into this section. I will clarify that the BID is used as a key only for signaling. > >> 6.3. Processing Binding Update >> If a Binding Update does not contain a Binding Identifier mobility >> option, its processing is same as in [RFC-3775]. If the receiver >> already has multiple bindings for the home address, it MUST replace >> all the existing bindings by the received binding. As a result, the >> receiver node MUST have only one binding cache entry for the mobile >> node. If the Binding Update is for de-registration, the receiver >> MUST delete all existing bindings from its Binding Cache. >> If the Binding Update contains a Binding Identifier mobility >> option(s), it is validated according to section 9.5.1 of [RFC-3775] >> and the following steps. >> o If the home registration flag is set in the Binding Update, the >> home agent MUST carefully operate Duplicate Address Detection >> (DAD) for the received home address. If the home agent has >> already had a binding(s) for the mobile node, it MUST avoid >> running DAD for the home address on the home link when it >> receives >> the Binding Update. >> GT> Why is this here? This is normal RFC3775 operation and should not >> be affected by MCoA, no? > > I think the difference is that in RFC 3775, if there is a valid > binding cache entry for the home address already, the new BU > would be for just refreshing the binding. In MCoA case, the > new BU could be for adding another care-of address. But in both > cases, the home agent MUST NOT run DAD again for the home > address. So the behavior the same. The paragraph can be removed. OK > > > >> Acknowledgement with status set to 0 [Binding Update >> accepted]. >> * If the receiver does not have a binding entry for the BID, it >> registers a new binding for the BID and responds with a >> Binding >> Acknowledgement with status set to 0 [Binding Update >> accepted]. >> GT> What happens if one receives a new BID mapped to a CoA already in >> the binding cache (but mapped to different BID?) Is this allowed? Is >> this how one can change the BIDs it is using? > > I think the mobile node has to delete the earlier one and > then create new bindings. My answer is that the mobile node creates two bindings for the same CoA. The HA/CN uses the HoA and BID as the search key. If MN want to renew the BID value, it should de-register the older one and register a new binding with a new BID value. >> 6.4. Sending Binding Refresh Request >> When a node (home agent or correspondent node) sends a Binding >> Refresh Request for a particular binding created with the BID, the >> node SHOULD include the Binding Identifier mobility option in the >> Binding Refresh Request. >> GT> This needs a bit more...which BID mobility option is included? >> Just one? All of them? Again we need to be clear what the lifetime >> does and how it relates to each of the CoAs. > > Tied to the lifetime issue again. HA/CN should send BRR with all the BID options only if the bulk registration is used by MN. The same lifetime is used only in the bulk registration. If MN uses separate BUs, the binding lifetime can be managed independently. thanks ryuji > Vijay > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Feb 28 06:49:30 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79F5228C431; Thu, 28 Feb 2008 06:49:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.48 X-Spam-Level: X-Spam-Status: No, score=0.48 tagged_above=-999 required=5 tests=[AWL=-0.942, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJD9x99HZXfS; Thu, 28 Feb 2008 06:49:25 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7B703A6EC2; Thu, 28 Feb 2008 06:49:23 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AABB3A6EA0 for ; Thu, 28 Feb 2008 06:49:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgws9tTGSVDM for ; Thu, 28 Feb 2008 06:49:17 -0800 (PST) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id AF8473A6ED3 for ; Thu, 28 Feb 2008 06:49:16 -0800 (PST) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile12) with ESMTP id m1SEn8i5022654; Thu, 28 Feb 2008 23:49:08 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb2) with ESMTP id m1SEn8t02947; Thu, 28 Feb 2008 23:49:08 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili04) with ESMTP id m1SEn8R23791; Thu, 28 Feb 2008 23:49:08 +0900 (JST) Received: from NW-Sephiroth ([10.238.16.135]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Feb 2008 22:47:52 +0800 Received: from NWSephiroth by NW-Sephiroth (PGP Universal service); Thu, 28 Feb 2008 22:47:41 +0800 X-PGP-Universal: processed; by NW-Sephiroth on Thu, 28 Feb 2008 22:47:41 +0800 From: "Benjamin Lim" To: "'Ryuji Wakikawa'" References: Date: Thu, 28 Feb 2008 22:47:35 +0800 Message-ID: <000001c87a18$dd770df0$8710ee0a@psl.local> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ach55YDa9sC6LUnXS72BR2n/WBtxRgAMc1Iw In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 28 Feb 2008 14:47:53.0307 (UTC) FILETIME=[E5C9CAB0:01C87A18] Cc: mext@ietf.org Subject: Re: [MEXT] WGLC for draft-ietf-monami6-multiplecoa-05.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ryuji, Pls see inline. =8==8<=8== > >> GT> Something needs to be said about the lifetime of the > BU with 'H' > >> flag set. If the MN has to send a de-reg to the HA with Lifetime=0 > >> and 'H' set, for how ling is this state valid? What happens to the > >> lifetime of the other bindings?? > > > > Needs to be discussed as part of overall binding lifetime issue. > > good point. > We should treat the lifetime of that home state and the > other real bindings separately. > > When the MN sends a BU with H flag set, it should not use > bulk registration and send it as an individual BU. > The lifetime field MUST be set to the appropriate lifetime > for that home state. [Ben] You are giving a lifetime to home state. Can it now called home binding? If so, why should it be treated differently from other bindings? Furthermore, you mention below that MN must renew this 'home state', isn't this like renewing normal bindings? If this is so, I cannot see why bulk registration cannot be used. The only reason I see bulk reg not use previously is because of lifetime == 0 and if bulk reg is use, this implies all CoAs specified in the BU will have lifetime == 0. But now, since you assign a lifetime to 'home state', then what is the reason of restricting bulk reg? Regards, Benjamin Lim > HA can always treat this BU as de-registration BU because the > source address and home address are same. > In addition to that, H flag can also tell this is deregistration BU. > MN should renew the home state while it is at the home link. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Feb 28 19:44:57 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 972BF28C252; Thu, 28 Feb 2008 19:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.357 X-Spam-Level: X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkDlcjif5l3x; Thu, 28 Feb 2008 19:44:52 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 023783A6AF4; Thu, 28 Feb 2008 19:44:52 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8533E3A6AF4 for ; Thu, 28 Feb 2008 19:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4l1yWNtTnv0P for ; Thu, 28 Feb 2008 19:44:49 -0800 (PST) Received: from sd-1637.dedibox.fr (sd-1637.dedibox.fr [88.191.18.91]) by core3.amsl.com (Postfix) with ESMTP id F129E3A6A3F for ; Thu, 28 Feb 2008 19:44:48 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by sd-1637.dedibox.fr (Postfix) with ESMTP id 7814CA3CF0; Fri, 29 Feb 2008 04:44:40 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at sd-1637.dedibox.fr Received: from sd-1637.dedibox.fr ([127.0.0.1]) by localhost (sd-1637.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDVs3Bux+N5r; Fri, 29 Feb 2008 04:44:36 +0100 (CET) Received: from [10.0.1.19] (jules.nautilus6.org [203.178.138.2]) by sd-1637.dedibox.fr (Postfix) with ESMTP id 25DFCA3AE5; Fri, 29 Feb 2008 04:44:34 +0100 (CET) Message-ID: <47C77F9D.2050802@hongo.wide.ad.jp> Date: Fri, 29 Feb 2008 12:44:29 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: X-Enigmail-Version: 0.95.6 Cc: mext@ietf.org Subject: Re: [MEXT] I-D ACTION:draft-ietf-mext-nemo-v4traversal-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello, I have another question related to the TLV use. Since BU are supposed to = always be sent in vanilla UDP encapsulation (this is a MUST in the = draft) we are likely to receive both TLV-encapsulated and = vanilla-encapsulated packets on the same port, right? Therefore my question is: how the receiver is supposed to guess how to = decapsulate the packet? Does it rely on the first bytes following the = UDP header, to recognize IP or IPv6 packet? In this case we don't need = the TLV or TV at all, do we? Thank you for any answer on this... (even telling that my question makes = no sense if I missed something, thanks!) Best regards, Sebastien Hesham Soliman a =E9crit : > Personally, I *strongly* prefer not to touch this. I would have preferred > not to have this silly TLV in the first place but to put it in context (t= his > is my personal opionion of course) this field will not be used by MN. The > reason IMO for having this was NETLMM people wanting to encapsulate things > like GRE... For those cases saving 3 bytes is not really worth it. = > = > Hesham = > = > > -----Original Message----- > > From: Teco Boot [mailto:teco@inf-net.nl] = > > Sent: Wednesday, February 27, 2008 7:07 PM > > To: 'Hesham Soliman' > > Cc: mext@ietf.org > > Subject: RE: [MEXT] I-D = > > ACTION:draft-ietf-mext-nemo-v4traversal-01.txt > > = > > >>>> TLV-header UDP encapsulation: > > > > And is a length field of only one octet not a little = > > bit to small? > > > > Encapsulated payload could exceed 255 octets. > > > = > > > =3D> Yes, good catch, it's a bug, it should be 2 bytes. > > Are we sure we need the payload length field? > > UDP length is already available, and this new length field is simply > > UDP_Length - 12. > > = > > I do not prefer a mandatory 32-bit alignment carrying only a = > > single octet > > type field. > > What about type dependent padding? > > = > > For types with 32-bit alignment: > > = > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 = > > 7 8 9 0 1 > > = > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type | Reserved = > > | > > = > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > = > > For types with low overhead: > > = > > 0 1 2 3 4 5 6 7 = > > +-+-+-+-+-+-+-+-+ > > | Type | > > +-+-+-+-+-+-+-+-+ > > = > > Teco. > > = > > = > > = > = > = > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > = -- = Sebastien Decugis http://www.nautilus6.org _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Feb 29 05:57:02 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCE7D3A6B57; Fri, 29 Feb 2008 05:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.066 X-Spam-Level: X-Spam-Status: No, score=0.066 tagged_above=-999 required=5 tests=[AWL=-0.893, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvGUyKEG45hT; Fri, 29 Feb 2008 05:56:58 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3106F3A6F3C; Fri, 29 Feb 2008 05:56:58 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B47A03A6F3E for ; Fri, 29 Feb 2008 05:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKcrF3NfMnTd for ; Fri, 29 Feb 2008 05:56:50 -0800 (PST) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.230]) by core3.amsl.com (Postfix) with ESMTP id 3D8DC3A6F37 for ; Fri, 29 Feb 2008 05:56:50 -0800 (PST) Received: by wr-out-0506.google.com with SMTP id 50so154184wra.25 for ; Fri, 29 Feb 2008 05:56:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; bh=tE5idu6mzP65n0sjUDgZdPF5eYAI7Cm1RCELNau4WJk=; b=S6xDkHUhy71h02oiTElmdjZbnNV3nx/FLJZowICP+VkZiNz8Aj+oWDpszT8ozz9ZHdUzSW2Dmw7Ee4Ge4wuTwBsQP0jP+TYT7b11c2RLi/+qnq6XZKW9nyjtl1ycZa0fWfFH0Cp7y++UpT8Vibep6w6izIpi7ItIlKuaW4jjgmE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; b=dHqvzrXHclqzJ9XXK+mDyYqW5fFUyN1NY76y0ueBwmLnCwUbmw51XGO4I7faFxGjvoesKhU5yV+JqyqTN9fT9OgCrr9pS/Curw8N52JFzD2mLAvFeIE+gnTrgBDU2volJIzxSNECiVcq3cRxbfHnpThAZj7cvHCLc6NbHhX3CvY= Received: by 10.141.15.19 with SMTP id s19mr6351746rvi.39.1204293401161; Fri, 29 Feb 2008 05:56:41 -0800 (PST) Received: from dhcp-143-207.sfc.wide.ad.jp ( [203.178.143.207]) by mx.google.com with ESMTPS id c20sm13103269rvf.33.2008.02.29.05.56.38 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Feb 2008 05:56:39 -0800 (PST) From: RYUJI WAKIKAWA To: Benjamin Lim In-Reply-To: <000001c87a18$dd770df0$8710ee0a@psl.local> References: <000001c87a18$dd770df0$8710ee0a@psl.local> Message-Id: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 29 Feb 2008 22:56:36 +0900 X-Mailer: Apple Mail (2.919.2) Cc: mext@ietf.org Subject: Re: [MEXT] WGLC for draft-ietf-monami6-multiplecoa-05.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Benjamin, On 2008/02/28, at 23:47, Benjamin Lim wrote: > Hi Ryuji, > > Pls see inline. > > =3D8=3D=3D8<=3D8=3D=3D >>>> GT> Something needs to be said about the lifetime of the >> BU with 'H' >>>> flag set. If the MN has to send a de-reg to the HA with Lifetime=3D0 >>>> and 'H' set, for how ling is this state valid? What happens to the >>>> lifetime of the other bindings?? >>> >>> Needs to be discussed as part of overall binding lifetime issue. >> >> good point. >> We should treat the lifetime of that home state and the >> other real bindings separately. >> >> When the MN sends a BU with H flag set, it should not use >> bulk registration and send it as an individual BU. >> The lifetime field MUST be set to the appropriate lifetime >> for that home state. > [Ben] You are giving a lifetime to home state. Can it now called home > binding? If so, why should it be treated differently from other = > bindings? The above text is my personal answer to George. The latest document does not use home binding and does not treat this state as a binding (home binding). > Furthermore, you mention below that MN must renew this 'home state', = > isn't > this like renewing normal bindings? If this is so, I cannot see why = > bulk The question should be that "do we really need to treat this state as = a binding?" My first thought is NO. This is too much, because the home agent can = always detects the MN's existence at the home link. Since the MN sends a deregistration BU to the home agent, home agent can records the mac address or wireless association, etc. (i.e. any mechanism to detect the node availability at the link). Do we really need to control this state at L3 ? > registration cannot be used. The only reason I see bulk reg not use > previously is because of lifetime =3D=3D 0 and if bulk reg is use, this = > implies > all CoAs specified in the BU will have lifetime =3D=3D 0. But now, since = > you > assign a lifetime to 'home state', then what is the reason of = > restricting > bulk reg? Right, if we use the lifetime for home binding, we can use the bulk = registration. regards, ryuji ps. Mobicom08 and Mobiarch08 CFP are attached below!!!! ------------------------------------------------------------------------- CALL FOR PAPERS MobiCom 2008 The Fourteenth Annual International Conference on Mobile Computing and Networking September 14-19, 2007 San Francisco Bay Area, CA, USA http://www.sigmobile.org/mobicom/2008/ Sponsored by ACM SIGMOBILE ------------------------------------------------------------------------- ACM MobiCom is the premier international conference dedicated to addressing the challenges in the areas of mobile computing and wireless and mobile networking. It has served as an exciting international forum since 1995, addressing networks, systems, algorithms, and applications that support the symbiosis of mobile computers and wireless networks. This year, we will continue this tradition, but we especially encourage the submission of papers in the experimental systems area. This area has seen exciting developments in recent years and explicit efforts will be taken to represent it strongly at MobiCom this year. Authors are invited to submit full papers, challenges papers, student posters, and research demos and exhibits, presenting new research related to the theory or practice of mobile computing and/or wireless and mobile networking. All submissions must describe original research, not published or currently under review for another conference or journal. Areas of interest include, but are not limited to: * Operating system and middleware support for mobile computing and networking * Architectures, protocols, and algorithms to cope with mobility, limited bandwidth, limited power and/or intermittent connectivity * Fundamental understanding of mobile computing and wireless = networking * Wireless and mobile techniques for delay tolerant, mobile ad hoc, and wireless sensor networks * Security, privacy, and trustworthiness of mobile and wireless = systems * Wireless access technologies (e.g. mesh systems, PANs) * Integration and interworking of wired and wireless networks * Protocols exploiting novel technologies such as UWB, MIMO, directional antennas, and software radios * Techniques for dynamic spectrum use * Architectures, algorithms and protocols for cognitive wireless networks and their integration in the Internet * Modeling, measurement and simulation of mobile networks * Experimental test-beds for mobile/wireless networks * Performance evaluation of mobile and wireless networks, protocols, and systems * Next generation (beyond 802.11) wireless technologies and related systems and protocols Submission Instructions Detailed instructions on how and where to submit your paper can be found at http://www.sigmobile.org/mobicom/2008/cfp.pdf IMPORTANT DATES: Abstracts submission due: March 7, 2008 Paper submission due: March 14, 2008 Notification of acceptance: June 19, 2008 Camera-ready version due: July 7, 2008 General Chair - jj@soe.ucsc.edu: J.J. Garcia-Luna-Aceves, UC Santa Cruz and PARC Technical Co-Chairs - mobicom08_pcchairs@acm.org: Raghupathy (Siva) Sivakumar, Georgia Tech Peter Steenkiste, Carnegie Mellon University FOR MORE INFORMATION: Please contact the General Chair or Program Co-Chairs for more information. For information on ACM SIGMOBILE and = the MobiCom series of conferences, see http://www.sigmobile.org/ or contact mobicom_info@acm.org. ------------------------------------------------------------------------- CALL FOR PAPERS ACM MobiArch 2008 An ACM SIGCOMM 2008 Workshop Seattle, WA, USA, August 22, 2008 The 3rd ACM International Workshop on Mobility in the Evolving Internet Architecture Paper registration deadline: March 17, 2008 ------------------------------------------------------------------------- http://www.sigcomm.org/sigcomm2008/workshops/mobiarch/ Recent developments in wireless access technologies and mobile devices are beginning to make widespread user, terminal and network mobility a reality in the commercial Internet. At the same time, the Internet architecture struggles to incorporate the functionality that will = sustain this increasingly more mobile and more dynamic Internet use. Efficient mobility management and mobility optimizations, locator-identifier splits, multihoming, security and related network operation and management functions are still in the early stages of development. It = is, however, already clear that supporting widespread mobility poses to significantly impact the original end-to-end design of the Internet. At the same time, critical momentum is building to significantly revise or even replace the current Internet architecture. Several substantial Future Internet initiatives have started in Europe, the US and Asia, and the topic is also actively being discussed in the vendor and network operator communities. These Future Internet efforts offer the exciting opportunity to design radically different approaches to supporting host and network mobility and multihoming, and may eventually lead to an internetwork architecture with significantly more advanced mobility features than those that the piecemeal extensions of the current = Internet protocols result in. MobiArch'08 welcomes submissions from both researchers and practitioners that explore recent advances in architectures, protocols and emerging technologies to enable mobility and multihoming in the Internet, as well as concepts and designs to support widespread mobility and multihoming = in future internetworks. Early results, position papers, systems and measurement papers are particularly welcome. TOPICS MobiArch'08 covers all aspects related to mobility in the current and future Internet, including, but not limited to: * Architectures and protocols for mobility support at all layers of the Internet protocol stack, as well as cross-layer approaches * Novel concepts to support widespread mobility and multihoming in a Future Internet * Routing and addressing issues (including locator/identifier splits) and their impact on the Internet architecture * Multihoming, including flow distribution and load-sharing for wireless and mobility * Performance evaluation, experimentation and modeling of Internet mobility * Models for mobility patterns and their experimental validation * New wireless technologies and services and their impact on the Internet architecture * Location management, positioning and data management for wireless and mobility * Accounting, access control, security and privacy issues and their impact on the Internet architecture * Social, economic, scalability and deployment issues SUBMISSION GUIDELINES Submissions must be no longer than six pages, including all figures and references, must be in PDF format, and must follow the ACM formatting guidelines (http://www.acm.org/sigs/publications/proceedings-templates). Submissions that do not adhere to these requirements will be rejected without further review. Peer review is single-blind; the authors names and affiliations are to = be included on the submission. Submissions cannot be previously published = or be under concurrent review elsewhere. The submission of position papers is encouraged; please clearly identify position papers as such when submitting. Papers may be submitted at http://edas.info/newPaper.php?c=3D6140 IMPORTANT DATES March 17, 2008 Registration of paper abstract March 24, 2008 Submissions due May 1, 2008 Notification of acceptance June 9, 2008 Camera ready version due August 22, 2008 Workshop date TECHNICAL PROGRAM COMMITTEE Lars Eggert (co-chair, Nokia Research Center, FI) Linda Doyle (co-chair, Trinity College, IE) Rui Aguiar (Universidade de Aveiro, PT) Bengt Ahlgren (Swedish Institute of Computer Science, SE) Jari Arkko (Ericsson, FI) Marcelo Bagnulo (University Carlos III of Madrid, ES) Olivier Bonaventure (Universit=E9 Catholique de Louvain, BE) Wesley Eddy (NASA/Verizon (US) Joseph Evans (University of Kansas, US) Ted Faber (USC Information Sciences Institute, US) Stephen Hailes (University College London, UK) Roger Karrer (T-Labs, DE) Rajeev Koodli (Nokia Research Center, US) Donal O'Mahony (Trinity College, IE) J=F6rg Ott (Helsinki University of Technology, FI) Guru Parulkar (Stanford University, US) Dipankar Raychaudhuri (Rutgers University, US) Dave Thaler (Microsoft, US) Ryuji Wakikawa (Keio University, JP) Klaus Wehrle (RWTH Aachen University, DE) Lixia Zhang (UCLA, US) _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Feb 29 09:01:35 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CE6F28C621; Fri, 29 Feb 2008 09:01:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceD+p4y-0ak9; Fri, 29 Feb 2008 09:01:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B8FA3A68D4; Fri, 29 Feb 2008 09:01:28 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E66B228C3FE for ; Fri, 29 Feb 2008 09:01:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGO+l+3-8++V for ; Fri, 29 Feb 2008 09:01:20 -0800 (PST) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.188]) by core3.amsl.com (Postfix) with ESMTP id D13F828C414 for ; Fri, 29 Feb 2008 09:01:19 -0800 (PST) Received: by rv-out-0910.google.com with SMTP id l15so2377047rvb.49 for ; Fri, 29 Feb 2008 09:01:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:content-type:content-transfer-encoding:subject:mime-version:date:references:x-mailer; bh=uO/R9FctK+xf40f49bN8yavjJiZGueofHLnvFj6bmjI=; b=Wqgh/bE7TdCIq1LqxKHWrN1Aa2wZTL0KAM8TGM1fFDB+jySq633XBtPEXJgHZCFcesuEGgYe/qPnF2zGoJk4fidr7mdnBcv9WhTh0MHzPw02ObLohQr3FfsTGnkRIFiaz0e9ahj+1uvu9EGYKE+Epg6zIdsedQYiL8dLiWbs5Cs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding:subject:mime-version:date:references:x-mailer; b=u53hfYOicOgjF0pnO0Bt4DtlJt7y0Lo8N4xafZ+2jaIxGkuP/sDJnSlKO6tXTAORrD/sibOIWiDQakr5KBxZQa0ddzqJxbo0x5SpHPw4hjDAMVav1uSxg7kaDIzjLf5aQpWeRj07ll0GbbaoPNIC8BRkajyb9DIZdT4q2Ldtn8I= Received: by 10.140.188.10 with SMTP id l10mr6531383rvf.6.1204304472100; Fri, 29 Feb 2008 09:01:12 -0800 (PST) Received: from dhcp-143-207.sfc.wide.ad.jp ( [203.178.143.207]) by mx.google.com with ESMTPS id b5sm18986714rva.20.2008.02.29.09.01.10 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Feb 2008 09:01:11 -0800 (PST) Message-Id: <9A637D42-4BE3-45A8-9537-C98DAFA68153@gmail.com> From: RYUJI WAKIKAWA To: mext@ietf.org Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sat, 1 Mar 2008 02:01:08 +0900 References: <3F416151-DE78-471B-92BB-355495A69C6D@gmail.com> X-Mailer: Apple Mail (2.919.2) Subject: [MEXT] Fwd: [netlmm] comments on draft-ietf-netlmm-pmip6-ipv4-support-02 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org SGkgSGVzaGFtLAoKSSByZWNlbnRseSBnb3QgY29tbWVudHMgZnJvbSBQcmVtZWMgYWJvdXQgRFNN SVAgc3VwcG9ydCBvbiBQTUlQLgpTb21lIG9mIGNvbW1lbnRzIGFyZSByZWxhdGVkIHRvIHRoZSBi YXNlIERTTUlQIHNwZWMuCk9yaWdpbmFsIG1haWwgd2FzIGF0dGFjaGVkIGJlbG93LgoKc3VtbWFy eS4KCjEuIFdoZW4gTU4gYWNxdWlyZXMgYSBwcml2YXRlIElQdjQgSG9BIGFuZCBvYnRhaW5zIGEg cHJpdmF0ZSBJUHY0IENvQSAgCmF0IGEgdmlzaXRlZCBuZXR3b3JrLAogICBib3RoIGFkZHJlc3Nl cyBjYW4gYmUgc2FtZSBiZWNhdXNlIG9mIHByaXZhdGUgc3BhY2UuIFRoaXMgbWF5IGNhdXNlICAK cHJvYmxlbS4KICAgV2Ugc2hvdWxkIG5vdCBhbGxvdyB0aGUgcHJpdmF0ZSBob21lIGFkZHJlc3Mu CgoyLiBJZiBNTiB3YW50cyB0byByZW1vdmUgYSBiaW5kaW5nIG9ubHkgZm9yIElQdjQgSG9BLCBo b3cgY2FuIE1OIGRlLSAKcmVnaXN0ZXIgdGhlIGJpbmRpbmc/CiAgIElmIGl0IHNlbmRzIGEgZGVy ZWdpYXRyYXRpb24gQlUsIGJpbmRpbmdzIG9mIGJvdGggSVB2NCBhbmQgSVB2NiAgCkhvQXMgYXJl IHJlbW92ZWQgYXQgdGhlIEhBLgoKMy4gVGhlcmUgaXMgbm8gbGVhc2UgdGltZSBmb3IgYW4gSVB2 NCBob21lIGFkZHJlc3Mgd2hlbiBNTiBvYnRhaW5zIGl0ICAKYnkgQlUvQkEgZXhjaGFuZ2UuCiAg ICBEbyB3ZSBuZWVkIGxpZmV0aW1lIGZpZWxkIGluIHRoZSBJUHY0IGFkZHJlc3MgYWNrbm93bGVk Z2VtZW50ICAKb3B0aW9uPwogICAgSW4gTUlQdjYsIEhBIGdpdmVzIHRoZSBsZWFzZSB0aW1lIGZv ciBJUHY2IGhvbWUgYWRkcmVzcwogICAgIGJ5IHRoZSBwcmVmaXggaW5mb3JtYXRpb24gb3B0aW9u IGNhcnJpZWQgYnkgTVBBIGFuZCBSQS4KCnJlZ2FyZHMsCnJ5dWppCkJlZ2luIGZvcndhcmRlZCBt ZXNzYWdlOgoKPiDlt67lh7rkuro6IFJZVUpJIFdBS0lLQVdBIDxyeXVqaS53YWtpa2F3YUBnbWFp bC5jb20+Cj4g5pel5pmCOiAyMDA45bm0M+aciDHml6UgMTo0NDo1MjpKU1QKPiDlrpvlhYg6ICJQ cmVtZWMsIERvbWFnb2oiIDxkb21hZ29qLnByZW1lY0BzaWVtZW5zLmNvbT4KPiBDYzogTmV0TE1N IExpc3QgTWFpbGluZyA8bmV0bG1tQGlldGYub3JnPgo+IOS7tuWQjTogUmU6IFtuZXRsbW1dIGNv bW1lbnRzIG9uIGRyYWZ0LWlldGYtbmV0bG1tLXBtaXA2LWlwdjQtIAo+IHN1cHBvcnQtMDIKPgo+ IERlYXIgUHJlbWVjLAo+Cj4gVGhhbmtzIGZvciBjb21tZW50cy4gSSBhcG9sb2dpemUgbXkgbGF0 ZSByZXBseS4KPgo+IFdlIGRpZG4ndCBzdWJtaXQgdGhlIG5ldyB2ZXJzaW9uIGF0IHRoZSBkZWFk bGluZSBvZiB0aGlzIElFVEYuCj4gU3JpIGFuZCBJIGFyZSB3b3JraW5nIG9uIHRoZSBkb2N1bWVu dCByaWdodCBub3cgYW5kCj4gd2lsbCB1cGxvYWQgdGhlIG5ldyBkb2N1bWVudCB0byB3ZWJzZXJ2 ZXIgc29vbi4KPiBXZSdsbCBzZW5kIHRoZSBVUkwgd2hlbmV2ZXIgaXQncyByZWFkeS4KPgo+IE9u IDIwMDgvMDIvMjAsIGF0IDA6MjQsIFByZW1lYywgRG9tYWdvaiB3cm90ZToKPgo+PiBIaSBSeXVq aSwKPj4KPj4gSSByZXZpZXdlZCB0aGUgSVB2NC1vdmVyLVBNSVA2IGRyYWZ0IGFuZCBJIGhhdmUg c29tZSBxdWVzdGlvbnMgdG8gIAo+PiB3aGljaCBJIGNvdWxkbid0IGZpbmQgYW5zd2VycyBpbiB0 aGUgZHJhZnQsIHBsZWFzZSBzZWUgbXkgZGV0YWlsZWQgIAo+PiBjb21tZW50cyBiZWxvdy4KPj4g UHJpdmF0ZSBhZGRyZXNzZXM6Cj4+IFRoZSBkb2N1bWVudCBkb2Vzbid0IGhhbmRsZSBwcml2YXRl IElQIGFkZHJlc3NlcyBleHBsaWNpdGVseS4gSSAgCj4+IHRoaW5rIHRoZXJlIGFyZSBzb21lIGlz c3VlcyByZXN1bHRpbmcgZnJvbSB0aGUgdXNlIG9mIHByaXZhdGUgSVAgIAo+PiBhZGRyZXNzZXMg YW5kIGl0IHdvdWxkIGJlIGdvb2QgaWYgdGhlIGRvY3VtZW50IHdvdWxkIGRlc2NyaWJlIHRoZW0u ICAKPj4gV2hlcmUgYXBwcm9wcmlhdGUsIGEgaGludCBhdCB0aGUgc29sdXRpb24gY291bGQgYWxz byBiZSBwcm92aWRlZC4KPgo+IFdlIGJhc2ljYWxseSBmb2xsb3cgdGhlIERTTUlQdjYgc3BlYy4u Cj4gRFNNSVB2NiBzdXBwb3J0cyBwcml2YXRlIGFkZHJlc3MgZm9yIGJvdGggQ29BIGFuZCBIb0Eu IFRoZXJlZm9yZSwgIAo+IFBNSVAgYWxzbyBzdXBwb3J0cyBwcml2YXRlIGFkZHJlc3MgOi0pCj4K PiBXZSBkb24ndCBzZWUgYW55IGlzc3VlcyB0byBzdXBwb3J0IHByaXZhdGUgYWRkcmVzcyBzbyBm YXIuCj4gSWYgeW91IHNlZSBhbnkgUE1JUCBzcGVjaWZpYyBpc3N1ZXMgb2YgdGhlIHByaXZhdGUg YWRkcmVzcyB1c2UsCj4gd2UnbGwgY2xlYXJseSBhZGRyZXNzIHRoZSBpc3N1ZXMuCj4KPj4gTUFH cyAoYWNjZXNzIG5ldHdvcmspIGFuZCBMTUEgKGNvcmUgbmV0d29yaykgY291bGQgYmUgaW4gZGlm ZmVyZW50ICAKPj4gYWRtaW5pc3RyYXRpdmUgZG9tYWlucy4gTUFHcyBpbiB0aGUgYWNjZXNzIG5l dHdvcmsgYXJlIHVzaW5nICAKPj4gcHJpdmF0ZSBhZGRyZXNzZXMgZm9yIHRoZWlyIG93biBhZGRy ZXNzZXMgYW5kIExNQSBhc3NpZ25zIHByaXZhdGUgIAo+PiBhZGRyZXNzZXMgdG8gdGhlIE1Ocy4g SXQgbWF5IGhhcHBlbiB0aGF0IHRoZSBMTUEgYXNzaWducyB0aGUgIAo+PiBhZGRyZXNzIHggdG8g dGhlIE1OIGFuZCB0aGF0IHRoaXMgc2FtZSBhZGRyZXNzIGlzIHVzZWQgYnkgdGhlIE1BRyAgCj4+ IGFzIGl0cyBvd24gYWRkcmVzcyAob24gdGhlIGludGVyZmFjZSBmYWNpbmcgdGhlIE1OKS4gVGhp cyB0eXBlIG9mICAKPj4gY29sbGlzaW9uIGlzIHNvbWV3aGF0IHNpbWlsYXIgdG8gdGhlIExMQSBj b2xsaXNpb24gaW4gdGhlIGJhc2VsaW5lICAKPj4gZG9jdW1lbnQuIFRoZSBzb2x1dGlvbiBjb3Vs ZCBiZSBzaW1pbGFyIHRvIHRoZSBzb2x1dGlvbiBmb3IgTExBIGluICAKPj4gdGhlIGJhc2VsaW5l IHNwZWMuCj4KPiBpbnRlcmVzdGluZyBpc3N1ZTotKQo+IFllcywgdGhpcyBpcyBwcm9ibGVtLiBC dXQgaXQgbG9va3MgbGlrZSB0aGlzIGlzIG5vdCBzcGVjaWZpYyB0byAgCj4gUE1JUHY2IHY0IHN1 cHBvcnQgd29yay4KPiBUaGlzIGlzc3VlIGNhbiBiZSBhbHNvIGhhcHBlbmVkIHRvIHRoZSBvcmln aW5hbCBEU01JUC4KPiBJZiBIQSBwcm92aWRlcyBhIHByaXZhdGUgSG9BIGFuZCBNTiBvYnRhaW5z IGEgcHJpdmF0ZSBDb0EgYXQgdGhlICAKPiB2aXNpdGluZyBuZXR3b3JrLAo+IGJvdGggYWRkcmVz c2VzIGNhbiBiZSBkdXBsaWNhdGVkIGluIHNvbWUgc2NlbmFyaW9zLi4uCj4KPiBPbmUgc29sdXRp b24gZm9yIHRoaXMgaXMgdG8gcHJvaGliaXQgdXNpbmcgYSBwcml2YXRlIGhvbWUgYWRkcmVzcyBp biAgCj4gRFNNSVAuCj4gSSdtIG5vdCBzdXJlIHdoZXRoZXIgdGhpcyBtb2RpZmljYXRpb24gaXMg YWNjZXB0YWJsZSBvciBub3QuLgo+Cj4+IElmIHRoZSBNQUcgaXMgcGFydCBvZiBtdWx0aXBsZSBu ZXRsbW0gZG9tYWlucyBpdCBtYXkgaGFwcGVuIHRoYXQgIAo+PiBMTUFzIGZyb20gZGlmZmVyZW50 IGRvbWFpbnMgYXNzaWduIHRoZSBzYW1lIGFkZHJlc3MgdG8gdGhlIE1OcyAgCj4+IGF0dGFjaGVk IHRvIHRoZSBzYW1lIE1BRy4gVGhlIE1BRyBjYW4gaGFuZGxlIHN1Y2ggYSBzaXR1YXRpb24gYW5k ICAKPj4ga2VlcCB0aGUgTU5zIHdpdGggdGhlIHNhbWUgYWRkcmVzc2VzIGFwYXJ0IChhcyBmYXIg YXMgdGhvc2UgIAo+PiBhZGRyZXNzZXMgY29tZSBmcm9tIGRpZmZlcmVudCBMTUFzKS4gQWx0aG91 Z2ggdGhlIHNvbHV0aW9uIGlzICAKPj4gaW1wbGVtZW50YXRpb24gc3BlY2lmaWMgYW5kIHJlcXVp cmVzIG5vIHByb3RvY29sIGNoYW5nZXMgaXQgbWF5IGJlICAKPj4gd29ydGh3aGlsZSB0byBtYWtl IHRoZSBpbXBsZW1lbnRvcnMgYXdhcmUgb2YgdGhpcyBzaXR1YXRpb24uCj4KPiBPSywgaSBhZ3Jl ZSB0aGF0IHRoZXJlIGFyZSBzb21lIHRyaWNreSBzY2VuYXJpb3Mgd2hlbiBwcml2YXRlICAKPiBh ZGRyZXNzZXMgYXJlIHVzZWQgaW4gUE1JUC4KPiBUaGlzIHNob3VsZCBiZSBhbHNvIGRlc2NyaWJl ZCBpbiB0aGUgRFNNSVB2NiBiYXNlIGRvY3VtZW50LCB0b28uCj4gV2UnbGwgcHJlcGFyZSBmb3Ig dGV4dHMgYWJvdXQgdGhlIHByaXZhdGUgYWRkcmVzcyB1c2FnZS4KPgo+Pgo+PiBUaGUgYmFzZWxp bmUgc3BlYyBhbGxvd3MgZm9yIGxvY2FsIHJvdXRpbmcgYXQgdGhlIE1BRy4gVXNhZ2Ugb2YgIAo+ PiBwcml2YXRlIGFkZHJlc3NlcyBtYWtlcyB0aGlzIG1vcmUgY29tcGxpY2F0ZS4gSWYgdGhlIE1O cyBhcmUgZnJvbSAgCj4+IGRpZmZlcmVudCBuZXRsbW0gZG9tYWlucyB0aGVuIGxvY2FsIHJvdXRp bmcgZm9yIHN1Y2ggTU5zIHNob3VsZCBiZSAgCj4+IGRpc2FibGVkLCBvdGhlcndpc2UgTU4gbWln aHQgZW5kIHVwIHRhbGtpbmcgdG8gYSB3cm9uZyBDTi4KPgo+IFJpZ2h0LiBNQUcgU0hPVUxEIE5P VCBvcGVyYXRlIGxvY2FsIHJvdXRpbmcgaWYgdGhlIHNvdXJjZSBhbmQgIAo+IGRlc3RpbmF0aW9u IGFkZHJlc3NlcyBhcmUgcHJpdmF0ZS4KPiBXZSdsbCBmaXggdGhpcy4KPgo+PiBEZWZhdWx0IHJv dXRlcjoKPj4gVGhlIGJhc2VsaW5lIHNwZWMgZGVzY3JpYmVzIHRoZSBpc3N1ZXMgcmVsYXRlZCB0 byB0aGUgZGVmYXVsdCAgCj4+IHJvdXRlciBhbmQgdGhlIE1OIG1vdmVtZW50IC8gbGluayBjaGFu Z2UgKHNlY3Rpb24gNi45LjMpLiBJUHY0IGhvc3QgIAo+PiBtYXkgbGVhcm4gdGhlIGRlZmF1bHQg cm91dGVyIGFkZHJlc3MgdmlhIERIQ1B2NCBhbmQgUlMvUkEuIEkgd291bGQgIAo+PiBsaWtlIHRv IHNlZSBhIHNpbWlsYXIgcGFyYWdyYXBoIGZvciB2NCwgZGlzY3Vzc2luZyBob3cgdGhlIGhvc3Qg IAo+PiBtYWludGFpbnMgaXRzIGRlZmF1bHQgcm91dGVyIGxpc3QgYWNjcm9zcyBtb3ZlbWVudHMg YW5kIGFueSByZWxhdGVkICAKPj4gaXNzdWVzLgo+Cj4gUmlnaHQuCj4gU3JpIGFjdHVhbGx5IGhh dmUgcHJlcGFyZWQgc29tZSB0ZXh0cyBmb3IgZGVmYXVsdCByb3V0ZXIgaGFuZGxpbmcuCj4KPgo+ PiBEdWFsIHN0YWNrIE1TCj4+IHNlY3Rpb24gMy4xIElQdjQgSG9tZSBBZGRyZXNzIEFzc2lnbm1l bnQKPj4gQmVzaWRlcyB0aGUgdHdvIG1lc3NhZ2UgZmxvd3MgZm9yIHY0IGFkZHJlc3MgYXNzaWdu bWVudCwgSSB3b3VsZCAgCj4+IGxpa2UgdG8gYSBzZWUgYW4gYWRkaXRpb25hbCBtZXNzYWdlIGZs b3cgZm9yIGEgZHVhbCBzdGFjayBNUyB3aGljaCAgCj4+IGlzIGFzc2lnbmVkIGJvdGggSVB2NiBh bmQgSVB2NCBhZGRyZXNzLiBCb3RoIGZpZ3VyZSAyIGFuZCBmaWd1cmUgMyAgCj4+IGxlYXZlIHRo ZSBpbXByZXNzaW9uIHRoYXQgREhDUHY0IG1lc3NhZ2VzIGFyZSB1c2VkIGFzIGEgdHJpZ2dlciBm b3IgIAo+PiBQQlUuIFRoaXMgaXMgaW4gY29udHJhc3QgdG8gdjYgY2FzZSB3aGVyZSB0aGUgbGlu ayBhdHRhY2htZW50IGV2ZW50ICAKPj4gaXMgdXNlZCB0byB0cmlnZ2VyIFBCVS4gSWYgdGhlIE1T IGlzIGR1YWwgc3RhY2tlZCwgd2lsbCB0aGVyZSBiZSAgCj4+IHR3byBQQlVzLCBvbmUgZm9yIHY2 IHVwb24gdGhlIGF0dGFjaG1lbnQgdG8gdGhlIGxpbmssIGFuZCBhIHNlY29uZCAgCj4+IG9uZSBm b3IgdjQgYWRkcmVzcyB3aGVuIHRoZSBESENQdjQgbWVzc2FnZSBpcyBkZXRlY3RlZD8KPgo+IFJJ Z2h0LCBQQlUgaXMgdHJpZ2dlcmVkIGJ5IHRoZSBsaW5rIGF0dGFjaG1lbnQsIGFuZCBub3QgYnkg dGhlIERIQ1AgIAo+IG1lc3NhZ2UuCj4gVGhlIGZpZ3VyZSBjYW4gYmUgbWlzcmVhZCBzb21laG93 Li4KPiBXZSdsbCBmaXggdGhlIGZpZ3VyZXMuCj4KPiBPbmx5IG9uZSBQQlUgaXMgc3VmZmljaWVu dCBmb3IgYm9odCBJUHY0IGFuZCBJUHY2IEhvQSBhcyBEU01JUHY2IGRvZXMuCj4KPj4gSXMgdGhl IE1BRyBhYmxlIHRvIHJlbW92ZSBvbmx5IHY0IEhvQSBmcm9tIHRoZSBMTUE/IEZvciBleGFtcGxl LCBpZiAgCj4+IHRoZSBNUyBpcyBkdWFsIHN0YWNrZWQgYW5kIGl0IHNlbmRzIERIQ1BSRUxFQVNF LCB0aGUgTUFHIHNob3VsZCBiZSAgCj4+IGFibGUgdG8gcmVtb3ZlIHRoZSB2NCBIb0EgYnV0IGxl YXZlIHRoZSB2NiBwYXJ0IGluIHRoZSBCQ0UgaW50YWN0LiAgCj4+IEknbSBub3Qgc3VyZSBpZiB0 aGUgcHJvdG9jb2wgYWxsb3dzIGZvciBpdC4KPgo+IEdvb2QgcG9pbnQuCj4KPiBEU01JUCBhY3R1 YWxseSBjYW5ub3Qgb3BlcmF0ZSB0aGlzLgo+IFRoZXJlIGlzIG5vIHdheSB0byByZWdpc3RlciBh IGJpbmRpbmcgb25seSBmb3IgSVB2NCBIb0EsIGJlY2F1c2UKPiB0aGUgc291cmNlIGFkZHJlc3Mg b2YgdGhlIGlubmVyIElQdjYgaGVhZGVyIE1VU1QgYmUgc2V0IHRvIElQdjYgaG9tZSAgCj4gYWRk cmVzcy4KPiBEU01JUHY2IGFsd2F5cyBhc3N1bWVzIElQdjYgaG9tZSBhZGRyZXNzIGFzc2lnbm1l bnQuCj4gVGhlIEhBIHJlbW92ZXMgYmluZGluZ3Mgb2YgYm90aCBJUHY0IGFuZCBJUHY2IEhvQSBp ZiB0aGUgbGlmZXRpbWUgb2YgIAo+IEJVIGlzIHNldCB0byB6ZXJvIGluIERTTUlQLgo+Cj4gSG93 ZXZlciwgaW4gUE1JUCBjYXNlLCB0aGUgSVB2NiBob21lIGFkZHJlc3MgaXMgbm90IHN0b3JlZCBp biB0aGUgIAo+IHNvdXJjZSBhZGRyZXNzIGZpZWxkLgo+IFRoZSBzb3VyY2UgYWRkcmVzcyBpcyBm aWxsZWQgd2l0aCB0aGUgTUFHJ3MgYWRkcmVzcyAoUC1Db0EpLgo+IFRoZXJlZm9yZSwgdGhlIE1B RyBjYW4gY29udHJvbCB3aGljaCBob21lIGFkZHJlc3Mgd2lsbCBiZSByZWdpc3RlcmVkICAKPiB0 bwo+IExNQSB3aXRoIGEgc2luZ2xlIEJVIGJ5IGNoYW5naW5nIHRoZSBjYXJyaWVkIG1vYmlsaXR5 IG9wdGlvbnMuCj4KPiBGb3IgZXhhbXBsZSwKPiAtIElmIE1BRyByZWdpc3RlcnMgb25seSBJUHY0 IGhvbWUgYWRkcmVzcywgaXQgY2FuIGluY2x1ZGUgSVB2NCBob21lICAKPiBhZGRyZXNzIG9wdGlv biBvbmx5Lgo+IC0gSWYgaXQgcmVnaXN0ZXJzIG9ubHkgSVB2NiBob21lIGFkZHJlc3MsIGl0IGNh biBpbmNsdWRlIEhvbWUgIAo+IE5ldHdvcmsgUHJlZml4IG9wdGlvbiBvbmx5Lgo+Cj4+IFdoYXQg aWYgdGhlIGxlYXNlIHRpbWUgZm9yIHY0IEhvQSBleHBpcmVzPyBJcyBNQUcgYWx3YXlzIGFibGUg dG8gIAo+PiBkZXRlY3QgdGhpcyBhbmQgZG9lcyBpdCBuZWVkIHRvIHJlYWN0PyBJZiBMTUEgZGV0 ZWN0cyBsZWFzZSB0aW1lICAKPj4gZXhwaXJ5LCBpcyBpdCBhYmxlIHRvIHRlbGwgdGhlIE1BRyB0 byByZXZva2Ugb25seSB2NCBzZXNzaW9uPyAgCj4+IChtYXliZSBsZWFzZSB0aW1lIGFuZCBiaW5k aW5nIGxpZmV0aW1lIGNvdWxkIGJlIGtlcHQgc3luY2hyb25pemVkICAKPj4gdG8gbWluaW1pemUg dGhlIGlzc3Vlcz8pCj4KPiBJZiBESENQIGlzIHVzZWQsIE1BRyAoREhDUC1TIG9yIERIQ1AtUikg Y2FuIGdlbmVyYXRlL2ludGVyY2VwdCB0aGUgIAo+IERIQ1AgbWVzc2FnZSBmb3IgdGhlIGxlYXNl IGV4cGlyYXRpb24uCj4gTUFHIGNhbiBzZW5kIGEgZGUtcmVnaXN0cmF0aW9uIHByb3h5IGJpbmRp bmcgdXBkYXRlIHRvIExNQS4KPiBJIGFtIG5vdCBzdXJlIHdoZXRoZXIgSUtFIGFzc2lnbnMgdGhl IGxlYXNlIHRpbWUgdG8gSVB2NCBob21lICAKPiBhZGRyZXNzZXMuCj4KPiBBbnl3YXksIGlmIExN QSBjb250cm9scyB0aGUgbGVhc2UgdGltZSwgTE1BIG11c3QgcmV2b2tlIHRoZSB2NCAgCj4gc2Vz c2lvbi4KPiBXZSBuZWVkIHNvbWUgcmV2b2NhdGlvbiBtZWNoYW5pc20gaGVyZS4uLkFobWFkIQo+ Cj4gSW4gRFNNSVAsIHdoZW4gTU4gYWNxdWlyZXMgYW4gSVB2NCBIb0EgdGhyb3VnaCB0aGUgYmlu ZGluZyAgCj4gcmVnaXN0cmF0aW9uCj4gKHNldCAwLjAuMC4wIGluIHRoZSBJUHY0IGhvbWUgYWRk cmVzcyBvcHRpb24pLCAgdGhlcmUgaXMgbm8gbGVhc2UgIAo+IHRpbWUgZm9yIElQdjQgaG9tZSBh ZGRyZXNzLgo+Cj4+IEhvdyBhYm91dCByZXF1aXJlaW5nIHRoYXQgdjQtY2FwYWJsZSBNQUcgbXVz dCBhY2NlcHQgdGhlIElQdjQgIAo+PiBBZGRyZXNzIEFja25vd2xlZGdtZW50IG9wdGlvbiBpbiB0 aGUgQkFjayBldmVuIGlmIGl0IGRpZCBub3QgcHV0ICAKPj4gdGhlIElQdjQgSG9tZSBBZGRyZXNz IG9wdGlvbiBpbiB0aGUgQlU/IFRoaXMgd291bGQgYWRkcmVzcyB0aGUgY2FzZSAgCj4+IHdoZXJl IHRoZSBuZXcgTUFHIGlzIG5vdCBhd2FyZSBvZiBJUCBzZXNzaW9uIHR5cGVzICh2Ni92NCkgYXQg dGhlICAKPj4gcHJldmlvdXMgTUFHLiBJZiBhIG5ldyBNQUcgd291bGQgc2VuZCBhIFBCVSB3aXRo IG9ubHkgdGhlIE5IUCAgCj4+IG9wdGlvbiAoZGVmYXVsdCBiZWhhdmlvdXIpIHRoZSBMTUEgd291 bGQgc3RpbGwgYmUgYWJsZSB0byB0ZWxsIGl0ICAKPj4gdGhhdCB0aGUgTVMgaGFzIGEgdjQgc2Vz c2lvbiBhbmQgdGhlIEhvQSBmb3IgdGhhdCB2NCBzZXNzaW9uLgo+Cj4geWVzIGFuZCBuby4KPiBN QUcgY2FuIGxlYXJuIHRoZSBNUyB0eXBlICh2NCBvciB2NikgYnkgcmVjZWl2aW5nIHRoZSBJUHY0 IGFkZHJlc3MgIAo+IGFjayBvcHRpb24uCj4gSG93ZXZlciwgaWYgREhDUCBpcyB1c2VkLCBNQUcg bmVlZCB0byBiZSBlaXRoZXIgREhDUCBzZXJ2ZXIgb3IgREhDUCAgCj4gcmVsYXkuCj4gQWZ0ZXIg cmVjZWl2aW5nIHRoZSBQQkEsIEl0IG1pZ2h0IGJlIHRvbyBsYXRlIHRvIGludGVyYWN0IHdpdGgg REhDUCAgCj4gc2VxdWVuY2UuCj4KPiBJIHRoaW5rIE1BRyBzaG91bGQga25vdyB0aGUgY2xpZW50 IHR5cGUgYmVmb3JlIHNlbmRpbmcgUEJVLgo+Cj4+IERIQ1Agc2VydmVyOgo+PiBzZWN0aW9uIDMu MQo+PiBXb3VsZCBpdCBtYWtlIHNlbnNlIHRvIHJlcXVpcmUgdGhlIERIQ1Agc2VydmVyIHRvIHNl dCB0aGUgc3VibmV0ICAKPj4gbWFzayBmb3IgdjQgSG9BIHRvIDI1NS4yNTUuMjU1LjI1NT8gVGhp cyB3b3VsZCBiZSBpbiBhY2NvcmRhbmNlICAKPj4gd2l0aCBhIHBvaW50LXRvLXBvaW50IGxpbmsg bW9kZWwuCj4KPiBDb3JyZWN0Lgo+IE90aGVyd2lzZSBBUlAgaXMgcnVuIGZvciBkZXN0aW5hdGlv biBhZGRyZXNzZXMgb2YgdGhlIHNhbWUgc3VibmV0Lgo+IFdlJ2xsIGZpeCB0aGlzLgo+Cj4+IExl dHRpbmcgdGhlIE1OIGdvIGludG8gdGhlIFJFQklORCBzdGF0ZSBuZWdhdGl2ZWx5IGFmZmVjdHMg dGhlIE1OICAKPj4gaWRsZSBtb2RlIG9wZXJhdGlvbiwgdGhlcmUgd2lsbCBiZSBtYW55IHJldHJh bnNtaXNzaW9ucyB3YWtpbmcgdXAgIAo+PiB0aGUgTU4uIEl0IHdvdWxkIGJlIGhlbHBmdWwgdG8g bWVudGlvbiB0aGlzIGludGVyYWN0aW9uIGluIHRoZSBzcGVjICAKPj4gc28gdGhhdCBkZXBsb3lt ZW50cyBhcmUgYXdhcmUgb2YgdGhlIHRyYWRlLW9mZnMgYmVmb3JlIHRoZXkgZGVjaWRlICAKPj4g d2hpY2ggb3B0aW9uIHRvIHVzZS4KPgo+IE9LCj4KPj4KPj4KPj4gZWRpdG9yaWFsOgo+Pgo+PiBz ZWN0aW9uIDEKPj4+IFRoaXMgc3BlY2lmaWNhdGlvbiByZXF1aXJlcyB0aGF0IHRoZSBsb2NhbCBt b2JpbGl0eSBhbmNob3IgYW5kIHRoZQo+Pj4gbW9iaWxlIGFjY2VzcyBnYXRld2F5IGFyZSBib3Ro IElQdjYgY2FwYWJsZSBhbmQgSVB2NiBlbmFibGVkLAo+Pj4gaXJyZXNwZWN0aXZlIG9mIHRoZSB0 eXBlIG9mIHRyYW5zcG9ydCBuZXR3b3JrIChJUHY0IG9yIElQdjYpLAo+Pj4gY29ubmVjdGluZyB0 aGVzZSB0d28gZW50aXRpZXMuCj4+IEF0IHRoZSBNQUcsIHdlIGNhbiBkaWZmZXJlbnRpYXRlIGJl dHdlZW4gdGhlIElQdjYgc3VwcG9ydCB0b3dhcmRzICAKPj4gdGhlIExNQSBhbmQgdGhlIElQdjYg c3VwcG9ydCBmb3IgdGhlIGhvc3RzLiBJIGFncmVlIHRoYXQgZm9ybWVyIGlzICAKPj4gbWFuZGF0 b3J5LiBJIHRoaW5rIGl0IG1ha2VzIHNlbnNlIHRvIGFsbG93IE1BR3MgdG8gc3VwcG9ydCBvbmx5 IHY0ICAKPj4gb24gaW50ZXJmYWNlcyBmYWNpbmcgdGhlIE1OLiBNYXliZSB0aGlzIGNvdWxkIGJl IGNsYXJpZmllZCBpbiB0aGUgIAo+PiBwYXJhZ3JhcGggYWJvdmU/Cj4KPiBTdXJlLiBUaGUgcG9p bnQgaXMgdGhhdCBib3RoIExNQSBhbmQgTUFHIE1VU1QgaGF2ZSBJUHY2IGFkZHJlc3MgdG8gIAo+ IGV4Y2hhbmdlIGJpbmRpbmcgc2lnbmFscy4KPiBXZSBkaWRuJ3QgY2xlYXJseSBtZW50aW9uIHRo YXQgSVB2NiBpcyBzdXBwb3J0ZWQgd2hpY2ggaW50ZXJmYWNlLCAgCj4gaGVyZS4KPgo+PiBzZWN0 aW9uIDM6Cj4+PiBGdXJ0aGVyLCB3aGVuIHRoZSBtb2JpbGUgbm9kZSBhZnRlcgo+Pj4gb2J0YWlu aW5nIHRoZSBJUHY0IG9yIElQdjQvSVB2NiBhZGRyZXNzIGNvbmZpZ3VyYXRpb24gb24gdGhlIGFj Y2Vzcwo+Pj4gbGluaywgcGVyZm9ybXMgYW4gaW50ZXItdGVjaG5vbG9neSBoYW5kb2ZmLCB0aGUg bmV0d29yayB3aWxsIGVuc3VyZQo+Pj4gdGhlIG1vYmlsZSBub2RlIHdpbGwgYmUgYWJsZSB0byB1 c2UgdGhlIHNhbWUgSVB2NC9JUHY2IGFkZHJlc3MKPj4+IGNvbmZpZ3VyYXRpb24gb24gdGhlIG5l dyBpbnRlcmZhY2UuCj4+IE5vdCBldmVyeSBpbnRlci10ZWNoIGhhbmRvdmVyIHByZXNlcnZlcyB0 aGUgSVAgc2Vzc2lvbiwgdGhlICAKPj4gYmFzZWxpbmUgc3BlYyBwcm92aWRlcyBhIHNldCBvZiBy dWxlcyB0byBkZXRlcm1pbmUgaWYgdGhpcyBpcyBhICAKPj4gaGFuZG92ZXIgb3IgYSBzaW11bHRh bmVvdXMgYWNjZXNzLiBQbGVhc2UgYWRkIGEgcG9pbnRlciB0byBzZWN0aW9uICAKPj4gNS40IG9m IHRoZSBiYXNlbGluZSBzcGVjLgo+Cj4gT0suCj4KPj4gc2VjdGlvbiAzLjEKPj4+IFRoZSBtb2Jp bGUgYWNjZXNzIGdhdGV3YXkgTVVTVCBzZXQgdGhlIGtub3duIElQdjQgaG9tZQo+Pj4gcHJlZml4 IHRvIHRoZSBJUHY0IEhvbWUgQWRkcmVzcyBmaWVsZCBhbmQgdGhlIFByZWYgZmllbGQgb2YgdGhl IElQdjQKPj4+IGhvbWUgYWRkcmVzcyBvcHRpb24gW0lELURTTUlQNl0uCj4+IEl0IGRvZXNuJ3Qg cmVhZCB3ZWxsLCBtYXliZSBpdCBjb3VsZCBiZSByZS13b3JkZWQ6Cj4+ICJUaGUgbW9iaWxlIGFj Y2VzcyBnYXRld2F5IE1VU1QgdXNlIHRoZSBvYnRhaW5lZCBJUHY0IGhvbWUgYWRkcmVzcyAgCj4+ IHRvIGluaXRpYWxpemUgdGhlIElQdjQgSG9tZSBBZGRyZXNzIGFuZCBQcmVmIGZpZWxkcyBpbiB0 aGUgSVB2NCAgCj4+IEhvbWUgQWRkcmVzcyBvcHRpb24uIgo+PiBzZWN0aW9uIDMuMi4yCj4+PiBI b3dldmVyLCBzaW5jZSBQcm94eQo+Pj4gICAgTW9iaWxlIElQdjYgc3VwcG9ydHMgb25seSBJUHY0 IGNhcGFibGUgbm9kZSwgSVB2NiBob21lIGFkZHJlc3MgaXMKPj4+ICAgIG5vdCBhbHdheXMgYXZh aWxhYmxlIG9uIHRoZSB0ZXJtaW5hbC4KPj4gU3VnZ2VzdHMgcmUtd29yZGluZzoKPj4gIkhvd2V2 ZXIsIHNpbmNlIFByb3h5IE1vYmlsZSBJUHY2IHN1cHBvcnRzIGFsc28gSVB2NC1vbmx5IG5vZGVz LCAgCj4+IElQdjYgaG9tZSBhZGRyZXNzIGlzIG5vdCBhbHdheXMgYXZhaWxhYmxlIG9uIHRoZSB0 ZXJtaW5hbC4iCj4+Cj4+PiBSZWNlaXZpbmcgQmluZGluZyBSZWdpc3RyYXRpb24gUmVwbHk6Cj4+ IHMvQmluZGluZyBSZWdpc3RyYXRpb24gUmVwbHkvQmluZGluZyBBY2tub3dsZWRnbWVudCBtZXNz YWdlLwo+Pgo+Pj4gbyAgVGhlIElQdjQgSG9tZSBBZGRyZXNzIG9wdGlvbiBbSUQtRFNNSVA2XSBN VVNUIGJlIHByZXNlbnQuICBUaGUKPj4+ICAgIGFkZHJlc3MgdmFsdWUgTUFZIGJlIHNldCAwLjAu MC4wIG9yIHRvIGEgc3BlY2lmaWMgdmFsdWUuCj4+IEFkZCBmb2xsb3dpbmcgc2VudGVuY2U6ICJJ ZiBJUHY0IEhvbWUgQWRkcmVzcyBPcHRpb24gaXMgaW5jbHVkZWQgIAo+PiB0aGVuIHRoZSBIb21l IE5ldHdvcmsgUHJlZml4IG9wdGlvbiBbSUQtUE1JUDZdIE1BWSBiZSBvbWl0dGVkLiIKPgo+IGFn cmVlLCB3ZSdsbCBmaXggYWxsIHRoZSBhYm92ZSBjb3JyZWN0aW9uLgo+Cj4+PiBvICBXaGVuIGEg bW9iaWxlIG5vZGUgb2J0YWlucyBhbiBJUHY0IGhvbWUgYWRkcmVzcyBmcm9tIERIQ1Agc2VydmVy LAo+Pj4gICAgdGhlIG1vYmlsZSBhY2Nlc3MgZ2F0ZXdheSBTSE9VTEQgcmVjb3JkIHRoZSBhc3Np Z25lZCBJUHY0IGhvbWUKPj4+ICAgIGFkZHJlc3MgaW4gdGhlIHBvbGljeSBwcm9maWxlLiAgQSBu ZXcgbW9iaWxlIGFjY2VzcyBnYXRld2F5IGNhbgo+Pj4gICAgc2VuZCBhIHByb3h5IGJpbmRpbmcg dXBkYXRlIHdoZW4gYSBtb2JpbGUgbm9kZSByb2FtcyB0byB0aGUgbmV3Cj4+PiAgICBtb2JpbGUg YWNjZXNzIGdhdGV3YXkuCj4+IEknbSBjb25mdXNlZCBieSB0aGUgbGFzdCBzZW50ZW5jZS4gRG8g eW91IG1lYW4gdGhhdCB0aGUgb2xkIE1BRyBjYW4gIAo+PiBzZW5kIGEgZGUtcmVnaXN0cmF0aW9u IFBCVSB3aGVuIHRoZSBNTiBnb2VzIGF3YXk/IElmIHllcywgcGxlYXNlICAKPj4gcmV3b3JkIHRv IG1ha2UgaXQgbW9yZSBjbGVhci4KPgo+IFRoaXMgdGV4dCBoYXMgYmVlbiByZW1vdmVkLgo+Cj4+ IEZpZ3VyZXMgNCwgNSwgOCBhbmQgMTEgc2hvdyB0aGUgc3RydWN0dXJlIG9mIFBCVSBhbmQgUEJB Y2sgIAo+PiBtZXNzYWdlcy4gU29tZSBvcHRpb25zIGFyZSBtYXJrZWQgYXMgb3B0aW9uYWwsIHNv bWUgYXMgbWFuZGF0b3J5ICAKPj4gYW5kIHNvbWUgYXJlIG5vdCBtYXJrZWQgYXQgYWxsLiBJIHdv dWxkIHN1Z2dlc3QgdG8gZmxhZyBhbGwgb3B0aW9ucyAgCj4+IGFzIGVpdGhlciBtYW5kYXRvcnkg b3Igb3B0aW9uYWwuCj4KPiBvaywgd2Ugd2lsbCBmaXggdGhlc2UuCj4KPiBUaGFua3MgYWdhaW4g Zm9yIGRldGFpbGVkIGNvbW1lbnRzLgo+IEkgYXBvbG9naXplIG91ciBkZWxheSB0byBzdWJtaXQg dGhlIG5ldyB2ZXJzaW9uLgo+Cj4gSSdsbCBzZW5kIGFub3RoZXIgbWFpbCB0byBNRVhUIHRvIHBv aW50IG91dCBzb21lIGZ1bmRhbWVudGFsIGlzc3VlcyAgCj4gb2YgRFNNSVAuCj4KPiByZWdhcmRz LAo+IHJ5dWppCj4KPiBwcy4gTW9iaWNvbTA4IGFuZCBNb2JpYXJjaDA4IENGUCBhcmUgYXR0YWNo ZWQgYmVsb3chISEhCj4KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gICAgICAgICAgICAgICAgICAgICAg IENBTEwgRk9SIFBBUEVSUwo+Cj4gICAgICAgICAgICAgICAgICAgICAgICAgIE1vYmlDb20gMjAw OAo+ICAgICAgICAgICBUaGUgRm91cnRlZW50aCBBbm51YWwgSW50ZXJuYXRpb25hbCBDb25mZXJl bmNlCj4gICAgICAgICAgICAgICBvbiBNb2JpbGUgQ29tcHV0aW5nIGFuZCBOZXR3b3JraW5nCj4K PiAgICAgICAgICAgICAgICAgICAgICAgU2VwdGVtYmVyIDE0LTE5LCAyMDA3Cj4gICAgICAgICAg ICAJICAgU2FuIEZyYW5jaXNjbyBCYXkgQXJlYSwgQ0EsIFVTQQo+ICAgICAgICAgICAgIGh0dHA6 Ly93d3cuc2lnbW9iaWxlLm9yZy9tb2JpY29tLzIwMDgvCj4gICAgICAgICAgICAgICAgICAgU3Bv bnNvcmVkIGJ5IEFDTSBTSUdNT0JJTEUKPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gQUNNIE1vYmlDb20g aXMgdGhlIHByZW1pZXIgaW50ZXJuYXRpb25hbCBjb25mZXJlbmNlIGRlZGljYXRlZCB0bwo+IGFk ZHJlc3NpbmcgdGhlIGNoYWxsZW5nZXMgaW4gdGhlIGFyZWFzIG9mIG1vYmlsZSBjb21wdXRpbmcg YW5kCj4gd2lyZWxlc3MgYW5kIG1vYmlsZSBuZXR3b3JraW5nLiAgSXQgaGFzIHNlcnZlZCBhcyBh biBleGNpdGluZwo+IGludGVybmF0aW9uYWwgZm9ydW0gc2luY2UgMTk5NSwgYWRkcmVzc2luZyBu ZXR3b3Jrcywgc3lzdGVtcywKPiBhbGdvcml0aG1zLCBhbmQgYXBwbGljYXRpb25zIHRoYXQgc3Vw cG9ydCB0aGUgc3ltYmlvc2lzIG9mIG1vYmlsZQo+IGNvbXB1dGVycyBhbmQgd2lyZWxlc3MgbmV0 d29ya3MuIFRoaXMgeWVhciwgd2Ugd2lsbCBjb250aW51ZQo+IHRoaXMgdHJhZGl0aW9uLCBidXQg d2UgZXNwZWNpYWxseSBlbmNvdXJhZ2UgdGhlIHN1Ym1pc3Npb24gb2YgcGFwZXJzCj4gaW4gdGhl IGV4cGVyaW1lbnRhbCBzeXN0ZW1zIGFyZWEuICBUaGlzIGFyZWEgaGFzIHNlZW4gZXhjaXRpbmcK PiBkZXZlbG9wbWVudHMgaW4gcmVjZW50IHllYXJzIGFuZCBleHBsaWNpdCBlZmZvcnRzIHdpbGwg YmUgdGFrZW4gdG8KPiByZXByZXNlbnQgaXQgc3Ryb25nbHkgYXQgTW9iaUNvbSB0aGlzIHllYXIu Cj4KPiBBdXRob3JzIGFyZSBpbnZpdGVkIHRvIHN1Ym1pdCBmdWxsIHBhcGVycywgY2hhbGxlbmdl cyBwYXBlcnMsIHN0dWRlbnQKPiBwb3N0ZXJzLCBhbmQgcmVzZWFyY2ggZGVtb3MgYW5kIGV4aGli aXRzLCBwcmVzZW50aW5nIG5ldyByZXNlYXJjaAo+IHJlbGF0ZWQgdG8gdGhlIHRoZW9yeSBvciBw cmFjdGljZSBvZiBtb2JpbGUgY29tcHV0aW5nIGFuZC9vciB3aXJlbGVzcwo+IGFuZCBtb2JpbGUg bmV0d29ya2luZy4gQWxsIHN1Ym1pc3Npb25zIG11c3QgZGVzY3JpYmUgb3JpZ2luYWwgIAo+IHJl c2VhcmNoLAo+IG5vdCBwdWJsaXNoZWQgb3IgY3VycmVudGx5IHVuZGVyIHJldmlldyBmb3IgYW5v dGhlciBjb25mZXJlbmNlIG9yCj4gam91cm5hbC4gQXJlYXMgb2YgaW50ZXJlc3QgaW5jbHVkZSwg YnV0IGFyZSBub3QgbGltaXRlZCB0bzoKPgo+ICogT3BlcmF0aW5nIHN5c3RlbSBhbmQgbWlkZGxl d2FyZSBzdXBwb3J0IGZvciBtb2JpbGUgY29tcHV0aW5nIGFuZAo+ICAgbmV0d29ya2luZwo+ICog QXJjaGl0ZWN0dXJlcywgcHJvdG9jb2xzLCBhbmQgYWxnb3JpdGhtcyB0byBjb3BlIHdpdGggbW9i aWxpdHksCj4gICBsaW1pdGVkIGJhbmR3aWR0aCwgbGltaXRlZCBwb3dlciBhbmQvb3IgaW50ZXJt aXR0ZW50IGNvbm5lY3Rpdml0eQo+ICogRnVuZGFtZW50YWwgdW5kZXJzdGFuZGluZyBvZiBtb2Jp bGUgY29tcHV0aW5nIGFuZCB3aXJlbGVzcyAgCj4gbmV0d29ya2luZwo+ICogV2lyZWxlc3MgYW5k IG1vYmlsZSB0ZWNobmlxdWVzIGZvciBkZWxheSB0b2xlcmFudCwgbW9iaWxlIGFkIGhvYywKPiAg IGFuZCB3aXJlbGVzcyBzZW5zb3IgbmV0d29ya3MKPiAqIFNlY3VyaXR5LCBwcml2YWN5LCBhbmQg dHJ1c3R3b3J0aGluZXNzIG9mIG1vYmlsZSBhbmQgd2lyZWxlc3MgIAo+IHN5c3RlbXMKPiAqIFdp cmVsZXNzIGFjY2VzcyB0ZWNobm9sb2dpZXMgKGUuZy4gbWVzaCBzeXN0ZW1zLCBQQU5zKQo+ICog SW50ZWdyYXRpb24gYW5kIGludGVyd29ya2luZyBvZiB3aXJlZCBhbmQgd2lyZWxlc3MgbmV0d29y a3MKPiAqIFByb3RvY29scyBleHBsb2l0aW5nIG5vdmVsIHRlY2hub2xvZ2llcyBzdWNoIGFzIFVX QiwgTUlNTywKPiAgIGRpcmVjdGlvbmFsIGFudGVubmFzLCBhbmQgc29mdHdhcmUgcmFkaW9zCj4g KiBUZWNobmlxdWVzIGZvciBkeW5hbWljIHNwZWN0cnVtIHVzZQo+ICogQXJjaGl0ZWN0dXJlcywg YWxnb3JpdGhtcyBhbmQgcHJvdG9jb2xzIGZvciBjb2duaXRpdmUgd2lyZWxlc3MKPiAgIG5ldHdv cmtzIGFuZCB0aGVpciBpbnRlZ3JhdGlvbiBpbiB0aGUgSW50ZXJuZXQKPiAqIE1vZGVsaW5nLCBt ZWFzdXJlbWVudCBhbmQgc2ltdWxhdGlvbiBvZiBtb2JpbGUgbmV0d29ya3MKPiAqIEV4cGVyaW1l bnRhbCB0ZXN0LWJlZHMgZm9yIG1vYmlsZS93aXJlbGVzcyBuZXR3b3Jrcwo+ICogUGVyZm9ybWFu Y2UgZXZhbHVhdGlvbiBvZiBtb2JpbGUgYW5kIHdpcmVsZXNzIG5ldHdvcmtzLCBwcm90b2NvbHMs Cj4gICBhbmQgc3lzdGVtcwo+ICogTmV4dCBnZW5lcmF0aW9uIChiZXlvbmQgODAyLjExKSB3aXJl bGVzcyB0ZWNobm9sb2dpZXMgYW5kIHJlbGF0ZWQKPiAgIHN5c3RlbXMgYW5kIHByb3RvY29scwo+ Cj4gU3VibWlzc2lvbiBJbnN0cnVjdGlvbnMKPiBEZXRhaWxlZCBpbnN0cnVjdGlvbnMgb24gaG93 IGFuZCB3aGVyZSB0byBzdWJtaXQgeW91ciBwYXBlciBjYW4gYmUKPiBmb3VuZCBhdCBodHRwOi8v d3d3LnNpZ21vYmlsZS5vcmcvbW9iaWNvbS8yMDA4L2NmcC5wZGYKPgo+IElNUE9SVEFOVCBEQVRF UzoKPiBBYnN0cmFjdHMgc3VibWlzc2lvbiBkdWU6IE1hcmNoIDcsIDIwMDgKPiBQYXBlciBzdWJt aXNzaW9uIGR1ZTogTWFyY2ggMTQsIDIwMDgKPiBOb3RpZmljYXRpb24gb2YgYWNjZXB0YW5jZTog SnVuZSAxOSwgMjAwOAo+IENhbWVyYS1yZWFkeSB2ZXJzaW9uIGR1ZTogSnVseSA3LCAyMDA4Cj4K PiBHZW5lcmFsIENoYWlyIC0gampAc29lLnVjc2MuZWR1Ogo+IEouSi4gR2FyY2lhLUx1bmEtQWNl dmVzLCBVQyBTYW50YSBDcnV6IGFuZCBQQVJDCj4KPiBUZWNobmljYWwgQ28tQ2hhaXJzIC0gbW9i aWNvbTA4X3BjY2hhaXJzQGFjbS5vcmc6Cj4gUmFnaHVwYXRoeSAoU2l2YSkgU2l2YWt1bWFyLCBH ZW9yZ2lhIFRlY2gKPiBQZXRlciBTdGVlbmtpc3RlLCBDYXJuZWdpZSBNZWxsb24gVW5pdmVyc2l0 eQo+Cj4gRk9SIE1PUkUgSU5GT1JNQVRJT046IFBsZWFzZSBjb250YWN0IHRoZSBHZW5lcmFsIENo YWlyIG9yIFByb2dyYW0KPiBDby1DaGFpcnMgZm9yIG1vcmUgaW5mb3JtYXRpb24uICBGb3IgaW5m b3JtYXRpb24gb24gQUNNIFNJR01PQklMRSAgCj4gYW5kIHRoZQo+IE1vYmlDb20gc2VyaWVzIG9m IGNvbmZlcmVuY2VzLCBzZWUgaHR0cDovL3d3dy5zaWdtb2JpbGUub3JnLyBvciAgCj4gY29udGFj dAo+IG1vYmljb21faW5mb0BhY20ub3JnLgo+Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+ICAgICAgICAg ICAgICAgICAgICAgICAgIENBTEwgRk9SIFBBUEVSUwo+Cj4gICAgICAgICAgICAgICAgICAgICAg ICBBQ00gTW9iaUFyY2ggMjAwOAo+ICAgICAgICAgICAgICAgICAgQW4gQUNNIFNJR0NPTU0gMjAw OCBXb3Jrc2hvcAo+ICAgICAgICAgICAgICAgIFNlYXR0bGUsIFdBLCBVU0EsIEF1Z3VzdCAyMiwg MjAwOAo+Cj4gICAgICAgICAgICAgIFRoZSAzcmQgQUNNIEludGVybmF0aW9uYWwgV29ya3Nob3Ag b24KPiAgICAgICAgICBNb2JpbGl0eSBpbiB0aGUgRXZvbHZpbmcgSW50ZXJuZXQgQXJjaGl0ZWN0 dXJlCj4gICAgICAgICAgICAgUGFwZXIgcmVnaXN0cmF0aW9uIGRlYWRsaW5lOiBNYXJjaCAxNywg MjAwOAo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPgo+ICAgICAgaHR0cDovL3d3dy5zaWdjb21tLm9yZy9z aWdjb21tMjAwOC93b3Jrc2hvcHMvbW9iaWFyY2gvCj4KPiBSZWNlbnQgZGV2ZWxvcG1lbnRzIGlu IHdpcmVsZXNzIGFjY2VzcyB0ZWNobm9sb2dpZXMgYW5kIG1vYmlsZSBkZXZpY2VzCj4gYXJlIGJl Z2lubmluZyB0byBtYWtlIHdpZGVzcHJlYWQgdXNlciwgdGVybWluYWwgYW5kIG5ldHdvcmsgbW9i aWxpdHkgYQo+IHJlYWxpdHkgaW4gdGhlIGNvbW1lcmNpYWwgSW50ZXJuZXQuIEF0IHRoZSBzYW1l IHRpbWUsIHRoZSBJbnRlcm5ldAo+IGFyY2hpdGVjdHVyZSBzdHJ1Z2dsZXMgdG8gaW5jb3Jwb3Jh dGUgdGhlIGZ1bmN0aW9uYWxpdHkgdGhhdCB3aWxsICAKPiBzdXN0YWluCj4gdGhpcyBpbmNyZWFz aW5nbHkgbW9yZSBtb2JpbGUgYW5kIG1vcmUgZHluYW1pYyBJbnRlcm5ldCB1c2UuIEVmZmljaWVu dAo+IG1vYmlsaXR5IG1hbmFnZW1lbnQgYW5kIG1vYmlsaXR5IG9wdGltaXphdGlvbnMsIGxvY2F0 b3ItaWRlbnRpZmllcgo+IHNwbGl0cywgbXVsdGlob21pbmcsIHNlY3VyaXR5IGFuZCByZWxhdGVk IG5ldHdvcmsgb3BlcmF0aW9uIGFuZAo+IG1hbmFnZW1lbnQgZnVuY3Rpb25zIGFyZSBzdGlsbCBp biB0aGUgZWFybHkgc3RhZ2VzIG9mIGRldmVsb3BtZW50LiAgCj4gSXQgaXMsCj4gaG93ZXZlciwg YWxyZWFkeSBjbGVhciB0aGF0IHN1cHBvcnRpbmcgd2lkZXNwcmVhZCBtb2JpbGl0eSBwb3NlcyB0 bwo+IHNpZ25pZmljYW50bHkgaW1wYWN0IHRoZSBvcmlnaW5hbCBlbmQtdG8tZW5kIGRlc2lnbiBv ZiB0aGUgSW50ZXJuZXQuCj4KPiBBdCB0aGUgc2FtZSB0aW1lLCBjcml0aWNhbCBtb21lbnR1bSBp cyBidWlsZGluZyB0byBzaWduaWZpY2FudGx5ICAKPiByZXZpc2UKPiBvciBldmVuIHJlcGxhY2Ug dGhlIGN1cnJlbnQgSW50ZXJuZXQgYXJjaGl0ZWN0dXJlLiBTZXZlcmFsIHN1YnN0YW50aWFsCj4g RnV0dXJlIEludGVybmV0IGluaXRpYXRpdmVzIGhhdmUgc3RhcnRlZCBpbiBFdXJvcGUsIHRoZSBV UyBhbmQgQXNpYSwgIAo+IGFuZAo+IHRoZSB0b3BpYyBpcyBhbHNvIGFjdGl2ZWx5IGJlaW5nIGRp c2N1c3NlZCBpbiB0aGUgdmVuZG9yIGFuZCBuZXR3b3JrCj4gb3BlcmF0b3IgY29tbXVuaXRpZXMu IFRoZXNlIEZ1dHVyZSBJbnRlcm5ldCBlZmZvcnRzIG9mZmVyIHRoZSBleGNpdGluZwo+IG9wcG9y dHVuaXR5IHRvIGRlc2lnbiByYWRpY2FsbHkgZGlmZmVyZW50IGFwcHJvYWNoZXMgdG8gc3VwcG9y dGluZyAgCj4gaG9zdAo+IGFuZCBuZXR3b3JrIG1vYmlsaXR5IGFuZCBtdWx0aWhvbWluZywgYW5k IG1heSBldmVudHVhbGx5IGxlYWQgdG8gYW4KPiBpbnRlcm5ldHdvcmsgYXJjaGl0ZWN0dXJlIHdp dGggc2lnbmlmaWNhbnRseSBtb3JlIGFkdmFuY2VkIG1vYmlsaXR5Cj4gZmVhdHVyZXMgdGhhbiB0 aG9zZSB0aGF0IHRoZSBwaWVjZW1lYWwgZXh0ZW5zaW9ucyBvZiB0aGUgY3VycmVudCAgCj4gSW50 ZXJuZXQKPiBwcm90b2NvbHMgcmVzdWx0IGluLgo+Cj4gTW9iaUFyY2gnMDggd2VsY29tZXMgc3Vi bWlzc2lvbnMgZnJvbSBib3RoIHJlc2VhcmNoZXJzIGFuZCAgCj4gcHJhY3RpdGlvbmVycwo+IHRo YXQgZXhwbG9yZSByZWNlbnQgYWR2YW5jZXMgaW4gYXJjaGl0ZWN0dXJlcywgcHJvdG9jb2xzIGFu ZCBlbWVyZ2luZwo+IHRlY2hub2xvZ2llcyB0byBlbmFibGUgbW9iaWxpdHkgYW5kIG11bHRpaG9t aW5nIGluIHRoZSBJbnRlcm5ldCwgYXMgIAo+IHdlbGwKPiBhcyBjb25jZXB0cyBhbmQgZGVzaWdu cyB0byBzdXBwb3J0IHdpZGVzcHJlYWQgbW9iaWxpdHkgYW5kICAKPiBtdWx0aWhvbWluZyBpbgo+ IGZ1dHVyZSBpbnRlcm5ldHdvcmtzLiAgRWFybHkgcmVzdWx0cywgcG9zaXRpb24gcGFwZXJzLCBz eXN0ZW1zIGFuZAo+IG1lYXN1cmVtZW50IHBhcGVycyBhcmUgcGFydGljdWxhcmx5IHdlbGNvbWUu Cj4KPiBUT1BJQ1MKPiBNb2JpQXJjaCcwOCBjb3ZlcnMgYWxsIGFzcGVjdHMgcmVsYXRlZCB0byBt b2JpbGl0eSBpbiB0aGUgY3VycmVudCBhbmQKPiBmdXR1cmUgSW50ZXJuZXQsIGluY2x1ZGluZywg YnV0IG5vdCBsaW1pdGVkIHRvOgo+Cj4gKiBBcmNoaXRlY3R1cmVzIGFuZCBwcm90b2NvbHMgZm9y IG1vYmlsaXR5IHN1cHBvcnQgYXQgYWxsIGxheWVycwo+ICAgb2YgdGhlIEludGVybmV0IHByb3Rv Y29sIHN0YWNrLCBhcyB3ZWxsIGFzIGNyb3NzLWxheWVyIGFwcHJvYWNoZXMKPiAqIE5vdmVsIGNv bmNlcHRzIHRvIHN1cHBvcnQgd2lkZXNwcmVhZCBtb2JpbGl0eSBhbmQgbXVsdGlob21pbmcKPiAg IGluIGEgRnV0dXJlIEludGVybmV0Cj4gKiBSb3V0aW5nIGFuZCBhZGRyZXNzaW5nIGlzc3VlcyAo aW5jbHVkaW5nIGxvY2F0b3IvaWRlbnRpZmllcgo+ICAgc3BsaXRzKSBhbmQgdGhlaXIgaW1wYWN0 IG9uIHRoZSBJbnRlcm5ldCBhcmNoaXRlY3R1cmUKPiAqIE11bHRpaG9taW5nLCBpbmNsdWRpbmcg ZmxvdyBkaXN0cmlidXRpb24gYW5kIGxvYWQtc2hhcmluZyBmb3IKPiAgIHdpcmVsZXNzIGFuZCBt b2JpbGl0eQo+ICogUGVyZm9ybWFuY2UgZXZhbHVhdGlvbiwgZXhwZXJpbWVudGF0aW9uIGFuZCBt b2RlbGluZyBvZgo+ICAgSW50ZXJuZXQgbW9iaWxpdHkKPiAqIE1vZGVscyBmb3IgbW9iaWxpdHkg cGF0dGVybnMgYW5kIHRoZWlyIGV4cGVyaW1lbnRhbCB2YWxpZGF0aW9uCj4gKiBOZXcgd2lyZWxl c3MgdGVjaG5vbG9naWVzIGFuZCBzZXJ2aWNlcyBhbmQgdGhlaXIgaW1wYWN0IG9uIHRoZQo+ICAg SW50ZXJuZXQgYXJjaGl0ZWN0dXJlCj4gKiBMb2NhdGlvbiBtYW5hZ2VtZW50LCBwb3NpdGlvbmlu ZyBhbmQgZGF0YSBtYW5hZ2VtZW50IGZvcgo+ICAgd2lyZWxlc3MgYW5kIG1vYmlsaXR5Cj4gKiBB Y2NvdW50aW5nLCBhY2Nlc3MgY29udHJvbCwgc2VjdXJpdHkgYW5kIHByaXZhY3kgaXNzdWVzIGFu ZAo+ICAgdGhlaXIgaW1wYWN0IG9uIHRoZSBJbnRlcm5ldCBhcmNoaXRlY3R1cmUKPiAqIFNvY2lh bCwgZWNvbm9taWMsIHNjYWxhYmlsaXR5IGFuZCBkZXBsb3ltZW50IGlzc3Vlcwo+Cj4gU1VCTUlT U0lPTiBHVUlERUxJTkVTCj4gU3VibWlzc2lvbnMgbXVzdCBiZSBubyBsb25nZXIgdGhhbiBzaXgg cGFnZXMsIGluY2x1ZGluZyBhbGwgZmlndXJlcyAgCj4gYW5kCj4gcmVmZXJlbmNlcywgbXVzdCBi ZSBpbiBQREYgZm9ybWF0LCBhbmQgbXVzdCBmb2xsb3cgdGhlIEFDTSBmb3JtYXR0aW5nCj4gZ3Vp ZGVsaW5lcyAoaHR0cDovL3d3dy5hY20ub3JnL3NpZ3MvcHVibGljYXRpb25zL3Byb2NlZWRpbmdz LSAKPiB0ZW1wbGF0ZXMpLgo+IFN1Ym1pc3Npb25zIHRoYXQgZG8gbm90IGFkaGVyZSB0byB0aGVz ZSByZXF1aXJlbWVudHMgd2lsbCBiZSByZWplY3RlZAo+IHdpdGhvdXQgZnVydGhlciByZXZpZXcu Cj4gUGVlciByZXZpZXcgaXMgc2luZ2xlLWJsaW5kOyB0aGUgYXV0aG9ycyBuYW1lcyBhbmQgYWZm aWxpYXRpb25zIGFyZSAgCj4gdG8gYmUKPiBpbmNsdWRlZCBvbiB0aGUgc3VibWlzc2lvbi4gU3Vi bWlzc2lvbnMgY2Fubm90IGJlIHByZXZpb3VzbHkgIAo+IHB1Ymxpc2hlZCBvcgo+IGJlIHVuZGVy IGNvbmN1cnJlbnQgcmV2aWV3IGVsc2V3aGVyZS4gVGhlIHN1Ym1pc3Npb24gb2YgcG9zaXRpb24g IAo+IHBhcGVycwo+IGlzIGVuY291cmFnZWQ7IHBsZWFzZSBjbGVhcmx5IGlkZW50aWZ5IHBvc2l0 aW9uIHBhcGVycyBhcyBzdWNoIHdoZW4KPiBzdWJtaXR0aW5nLgo+IFBhcGVycyBtYXkgYmUgc3Vi bWl0dGVkIGF0IGh0dHA6Ly9lZGFzLmluZm8vbmV3UGFwZXIucGhwP2M9NjE0MAo+Cj4gSU1QT1JU QU5UIERBVEVTCj4gTWFyY2ggMTcsIDIwMDggICAgICAgIFJlZ2lzdHJhdGlvbiBvZiBwYXBlciBh YnN0cmFjdAo+IE1hcmNoIDI0LCAyMDA4ICAgICAgICBTdWJtaXNzaW9ucyBkdWUKPiBNYXkgMSwg MjAwOCAgICAgICAgICAgTm90aWZpY2F0aW9uIG9mIGFjY2VwdGFuY2UKPiBKdW5lIDksIDIwMDgg ICAgICAgICAgQ2FtZXJhIHJlYWR5IHZlcnNpb24gZHVlCj4gQXVndXN0IDIyLCAyMDA4ICAgICAg IFdvcmtzaG9wIGRhdGUKPgo+Cj4gVEVDSE5JQ0FMIFBST0dSQU0gQ09NTUlUVEVFCj4gTGFycyBF Z2dlcnQgICAgICAgICAgIChjby1jaGFpciwgTm9raWEgUmVzZWFyY2ggQ2VudGVyLCBGSSkKPiBM aW5kYSBEb3lsZSAgICAgICAgICAgKGNvLWNoYWlyLCBUcmluaXR5IENvbGxlZ2UsIElFKQo+IFJ1 aSBBZ3VpYXIgICAgICAgICAgICAoVW5pdmVyc2lkYWRlIGRlIEF2ZWlybywgUFQpCj4gQmVuZ3Qg QWhsZ3JlbiAgICAgICAgIChTd2VkaXNoIEluc3RpdHV0ZSBvZiBDb21wdXRlciBTY2llbmNlLCBT RSkKPiBKYXJpIEFya2tvICAgICAgICAgICAgKEVyaWNzc29uLCBGSSkKPiBNYXJjZWxvIEJhZ251 bG8gICAgICAgKFVuaXZlcnNpdHkgQ2FybG9zIElJSSBvZiBNYWRyaWQsIEVTKQo+IE9saXZpZXIg Qm9uYXZlbnR1cmUgICAoVW5pdmVyc2l0w6kgQ2F0aG9saXF1ZSBkZSBMb3V2YWluLCBCRSkKPiBX ZXNsZXkgRWRkeSAgICAgICAgICAgKE5BU0EvVmVyaXpvbiAoVVMpCj4gSm9zZXBoIEV2YW5zICAg ICAgICAgIChVbml2ZXJzaXR5IG9mIEthbnNhcywgVVMpCj4gVGVkIEZhYmVyICAgICAgICAgICAg IChVU0MgSW5mb3JtYXRpb24gU2NpZW5jZXMgSW5zdGl0dXRlLCBVUykKPiBTdGVwaGVuIEhhaWxl cyAgICAgICAgKFVuaXZlcnNpdHkgQ29sbGVnZSBMb25kb24sIFVLKQo+IFJvZ2VyIEthcnJlciAg ICAgICAgICAoVC1MYWJzLCBERSkKPiBSYWplZXYgS29vZGxpICAgICAgICAgKE5va2lhIFJlc2Vh cmNoIENlbnRlciwgVVMpCj4gRG9uYWwgTydNYWhvbnkgICAgICAgIChUcmluaXR5IENvbGxlZ2Us IElFKQo+IErDtnJnIE90dCAgICAgICAgICAgICAgKEhlbHNpbmtpIFVuaXZlcnNpdHkgb2YgVGVj aG5vbG9neSwgRkkpCj4gR3VydSBQYXJ1bGthciAgICAgICAgIChTdGFuZm9yZCBVbml2ZXJzaXR5 LCBVUykKPiBEaXBhbmthciBSYXljaGF1ZGh1cmkgKFJ1dGdlcnMgVW5pdmVyc2l0eSwgVVMpCj4g RGF2ZSBUaGFsZXIgICAgICAgICAgIChNaWNyb3NvZnQsIFVTKQo+IFJ5dWppIFdha2lrYXdhICAg ICAgICAoS2VpbyBVbml2ZXJzaXR5LCBKUCkKPiBLbGF1cyBXZWhybGUgICAgICAgICAgKFJXVEgg QWFjaGVuIFVuaXZlcnNpdHksIERFKQo+IExpeGlhIFpoYW5nICAgICAgICAgICAoVUNMQSwgVVMp Cj4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCk1FWFQg bWFpbGluZyBsaXN0Ck1FWFRAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tZXh0Cg==