From mext-bounces@ietf.org Wed Jul 2 05:56:48 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D2B33A6C02; Wed, 2 Jul 2008 05:56:48 -0700 (PDT) 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 C323C3A6C02 for ; Wed, 2 Jul 2008 05:56:47 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skvui8ftuO84 for ; Wed, 2 Jul 2008 05:56:46 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 355D73A692B for ; Wed, 2 Jul 2008 05:56:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,737,1204502400"; d="scan'208";a="13282955" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 02 Jul 2008 12:56:48 +0000 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 m62CulV8023067; Wed, 2 Jul 2008 14:56:47 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m62Culwh001706; Wed, 2 Jul 2008 12:56:47 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Jul 2008 14:56:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Jul 2008 14:56:08 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05E79165@xmb-ams-337.emea.cisco.com> In-Reply-To: <4D35478224365146822AE9E3AD4A26660302C052@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [mext] #7: DSMIPv6 BU format and RFC 3775 [TeroKauppinen] Thread-Index: AcjbChe/sGvJxlr9SAi8/S15JzVU+QABcWQgAAG90tAAShrSIA== References: <4D35478224365146822AE9E3AD4A26660302C052@exchtewks3.starentnetworks.com> From: "Pascal Thubert (pthubert)" To: "Koodli, Rajeev" , "Vijay Devarapalli" , "Sri Gundavelli (sgundave)" X-OriginalArrivalTime: 02 Jul 2008 12:56:47.0200 (UTC) FILETIME=[161D5600:01C8DC43] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=14427; t=1215003407; x=1215867407; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[MEXT]=20[mext]=20#7=3A=20DSMIPv6=20BU= 20format=20and=20RFC=203775=20[TeroKauppinen] |Sender:=20; bh=QnloeVDsLwWfStLbG1DLeNuEvqGbFVlbAOYrHXUnGWw=; b=C1JNzDsr5d4CmyHw/oSGIolWyJ1edAyG9A0aPM8Af0TPwu5I9O9xd3ALgP zrAsyFj27zbDj9DjeUrfuX2RsYOfUjODHBKErrdHlEy7KyjLgLyHboG2msU8 L3LDYL3h4s; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: charliep@computer.org, mext@ietf.org, tero.kauppinen@ericsson.com Subject: Re: [MEXT] [mext] #7: DSMIPv6 BU format and RFC 3775 [TeroKauppinen] 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 Rajiv and all: We had a thread to promote this around the times of MIPv6 draft 23 or 24. I mean the HA yielding when the MN pops up (DAD or NA) on the home link, because after all it is only a proxy. That did not end up in the spec, because - I suspect - it was too late in the process at that time. My view is that we should let the MN join the home link with its Home Address and then deregister if it can. To get there, we need a way to let the HA either yield silently or announce that it is only a proxy so that the real owner is not deterred and is allowed to take over the address anyway. The spirit of the cuurent RFC 3775 is exactly the opposite; RFC 3775 says: " The Override Flag (O) in the Advertisement MUST be set, indicating that the Advertisement SHOULD override any existing Neighbor Cache entry at any node receiving it. " So unless all the process runs smoothly we end up in a situation where the stale information (the HA owns the address) is actually winning against the real thing (the MN owns the address). I would support that 3775bis reverses that behaviour. Note: I'd also favor an option in the NA where the HA exposes the MIP sequence counter, so that another stale HA would yield silently as opposed to keep defending the address for lifetime. Pascal >-----Original Message----- >From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Koodli, Rajeev >Sent: mardi 1 juillet 2008 03:23 >To: Vijay Devarapalli; Sri Gundavelli (sgundave) >Cc: charliep@computer.org; tero.kauppinen@ericsson.com; mext@ietf.org >Subject: Re: [MEXT] [mext] #7: DSMIPv6 BU format and RFC 3775 >[TeroKauppinen] > > >Hi Vijay, > >> The mobile node can't claim its home address until the HA stops proxy >> neighbor discovery for the home address. >> >> RFC 3775 is quite explicit about this. >> >> In >> particular, the mobile node is unable to use its home address as >the >> Source Address in the Neighbor Solicitation until the home agent >> stops defending the home address. >> > >[RKo:>] To stop proxying, ND (2461, 4861) allows a node to send the >Unsolicited NA with 'O' bit set to 1, which has the effect of >over-riding proxy NC entry. I remember 2461 stating that use of 'O=1' >allows the actual node (i.e., not the proxy) to announce its presence on >the link. A de-registration BU only informs the HA. Unsolicited NA with >'O=1' informs all nodes on the link. We could consider UNA to be sent to >address the proxying issue. However, I guess we still need BU with >lifetime=0, perhaps because you can secure the BU today (and SEND is not >deployed, yet). > >-Rajeev > > > >> Vijay >> >> the HA can only release the binding as it cant >> > defend the address. Is this not an inconsistent state, both HA and >> > MN defending that address ? May be the best thing for the HA is >> > log the error and release the binding. >> > >> > Sri >> > >> > >> > On Mon, 30 Jun 2008, Vijay Devarapalli wrote: >> > >> > > Hi Charlie, >> > > >> > > I think the text in RFC 3775 needs to be fixed. RFC 3775 assumes >> that a >> > > binding update is sent with the home address option and with the >> care-of >> > > address stored either in the source address in the IPv6 header or >in >> > > alternate care-of address option. So it specifies that if the >> care-of >> > address >> > > matches the home address in the home address option, it is safe >for >> the >> > home >> > > agent to assume that the binding update was sent from the home >link >> and >> > can >> > > be treated as a de-registration BU. >> > > >> > > In practice, I have never seen a Binding Update, where the >lifetime >> is >> > > non-zero and the care-of address matches the home address, from a >> mobile >> > node >> > > implementation. Only the TAHI test suite sends such a binding >> update, >> > since >> > > they have to test conformance to RFC 3775. :) If the mobile node >> detects >> > that >> > > its care-of address matches the home address, it knows it has >> returned >> > home >> > > and sets the lifetime to zero in the binding update it sends to >the >> home >> > > agent. >> > > >> > > I would suggest removing it and treat only the binding update with >> > lifetime >> > > set to zero as a de-registration. It would help in simplifying the >> > > de-registration procedure a little bit. >> > > >> > > Vijay >> > > >> > > >> > > Charles E. Perkins wrote: >> > >> >> > >> Hello folks, >> > >> >> > >> So far, I did not find a persuasive reason to make >> > >> changes to RFC 3775 related to this issue with >> > >> DSMIPv6. Unless someone can suggest text that might >> > >> be needed, I would recommend to close this issue >> > >> without modification to rfc3775bis. >> > >> >> > >> Regards, >> > >> Charlie P. >> > >> >> > >> >> > >> >> > >> mext wrote: >> > >> > Ticket #7: DSMIPv6 BU format and RFC 3775 [Tero Kauppinen >> > >> > ] >> > >> > >> > >> > DSMIPv6 BU format and RFC 3775 >> > >> > Tero Kauppinen >> > >> > >> > >> > While reading the current version of DSMIPv6 >> > >> > (draft-ietf-mip6-nemo-v4traversal-06) and I came across with >> one >> > >> > sentence which strikes me as odd. >> > >> > >> > >> > "4.2. NAT detection and traversal >> > >> > >> > >> > NAT detection is done when the initial binding update >> message is >> > >> > sent >> > >> > from the mobile node to the home agent. When located in an >> IPv4- >> > only >> > >> > foreign link, the mobile node sends the binding update >> message >> > >> > encapsulated in UDP and IPv4. The source address of the >IPv6 >> > packet >> > >> > is the mobile node's IPv6 home address. The destination >> address >> > is >> > >> > the IPv6 address of the home agent. The IPv4 header >contains >> the >> > >> > IPv4 >> > >> > care-of address in the source address field and the IPv4 >> address >> > of >> > >> > the home agent in the destination address field. >> > >> > >> > >> > When the home agent receives the encapsulated binding >update >> it >> > >> > compares the IPv4 address of the source address field in >the >> > IPv4 >> > >> > header with the IPv4 address in the source address of the >> IPv6 >> > >> > header." >> > >> > >> > >> > If the IPv6 header contains the mobile node's IPv6 home >> address, >> > how >> > >> > can >> > >> > it ever match with the IPv4 address of the source address >field >> in >> > the >> > >> > IPv4 header? Furthermore, RFC3775 in 9.5.1. says "If the >> Lifetime >> > >> > specified in the Binding Update is zero or the specified >> care-of >> > >> > address >> > >> > matches the home address for the binding, then this is a >> request to >> > >> > delete the cached binding for the home address." >> > >> > >> > >> > So, >> > >> > >> > >> > (1) Should the IPv6 header actually contain an IPv4 mapped >IPv6 >> > >> > address? >> > >> > >> > >> > Or >> > >> > >> > >> > (2) Should the IPv4 address of the source address field in >the >> IPv4 >> > >> > header be compared with the address specified in the packet's >> IPv4 >> > CoA >> > >> > option? >> > >> > >> > >> > >> ------------------------------------------------------------------- >> > -- >> > >> > >> > >> > George Tsirtsis >> > >> > >> > >> > I would go with (2), as I think this was the intention (i.e., >I >> > >> > consider this a typo). >> > >> > >> > >> > It is not, however, clear to me what the relevance of the >> quoted >> > text >> > >> > from 3775 is. >> > >> > Whether (1) or (2) is used it should not result in the >> condition of >> > >> > CoA==HoA in the BU. >> > >> > >> > >> > >> ------------------------------------------------------------------- >> > -- >> > >> > >> > >> > Pascal Thubert >> > >> > >> > >> > I favor 1) and the text seems to be a leftover from your >> original >> > draft >> > >> > which worked that way. >> > >> > But I remember that the question was cut against it by the >> chairs >> > >> > because there was no proper consensus either way. >> > >> > >> > >> > Now I really hate the idea of a BU process that would have to >> > figure if >> > >> > a BU is a registration or deregistration just because the >> packet >> > was >> > >> > received over an interface that is an IPv4 tunnel as opposed >to >> the >> > >> > Home >> > >> > Link. That seems plain wrong. I have a tendency to think that >> > what's >> > >> > wrong is really RFC 3775 (lifetime 0 should be the way to >> > deregister) >> > >> > but unless we revise it, I'd suggest we keep consistent with >> that >> > >> > foundation RFC. If we REALLY do not want a mapped address as >> > source, >> > >> > then maybe we could use the UNSPECIFIED address instead? >> > >> > >> > >> > >> ------------------------------------------------------------------- >> > -- >> > >> > >> > >> > Vijay Devarapalli : >> > >> > >> > >> > > "4.2. NAT detection and traversal >> > >> > > >> > >> > > NAT detection is done when the initial binding update >> message >> > is >> > >> > sent >> > >> > > from the mobile node to the home agent. When located in >an >> > >> > IPv4-only >> > >> > > foreign link, the mobile node sends the binding update >> message >> > >> > > encapsulated in UDP and IPv4. The source address of the >> IPv6 >> > packet >> > >> > > is the mobile node's IPv6 home address. The destination >> address >> > is >> > >> > > the IPv6 address of the home agent. The IPv4 header >> contains >> > the >> > >> > IPv4 >> > >> > > care-of address in the source address field and the IPv4 >> > address of >> > >> > > the home agent in the destination address field. >> > >> > > >> > >> > > When the home agent receives the encapsulated binding >> update it >> > >> > > compares the IPv4 address of the source address field in >> the >> > IPv4 >> > >> > > header with the IPv4 address in the source address of the >> IPv6 >> > >> > > header." >> > >> > >> > >> > This text is old. The home agent needs to compare it with the >> IPv4 >> > >> > address in the IPv4 CoA option. So this paragraph should >> actually >> > >> > say >> > >> > >> > >> > When the home agent receives the encapsulated binding >update >> it >> > >> > compares the IPv4 address of the source address field in >the >> > IPv4 >> > >> > header with the IPv4 address in the IPv4 care-of address >> option >> > >> > in the Binding Update. >> > >> > >> > >> > > If the IPv6 header contains the mobile node's IPv6 home >> address, >> > >> > how can >> > >> > > it ever match with the IPv4 address of the source address >> field in >> > the >> > >> > > IPv4 header? Furthermore, RFC3775 in 9.5.1. says "If the >> Lifetime >> > >> > > specified in the Binding Update is zero or the specified >> care-of >> > >> > address >> > >> > > matches the home address for the binding, then this is a >> request >> > to >> > >> > > delete the cached binding for the home address." >> > >> > >> > >> > This text needs to be clarified in RFC 3775. Regarding the >> actual >> > >> > "violation", I don't think there is a conflict. The DS-MIPv6 >> > >> > binding update has an IPv4 CoA option (similar to the alt CoA >> > >> > option) which when present dictates a different behavior on >the >> > >> > home agent that implements DS-MIPv6 extensions. It is more >like >> > >> > DS-MIPv6 updates MIPv6 home agent behavior when the IPv4 CoA >> > >> > option is present. >> > >> > >> > >> > >> > >> > >> ------------------------------------------------------------------- >> > -- >> > >> > >> > >> > Basavaraj Patil >> > >> > >> > >> > Option 2 is what I believe the intent has been. Option 2 IMO >is >> a >> > >> > better >> > >> > choice even though it does diverge from RFC3775 design. But >> given >> > that >> > >> > this >> > >> > I-D is extending the base MIP6 RFC, I believe it is okay to >> proceed >> > >> > with >> > >> > option 2. >> > >> > >> > >> > >> > >> > >> ------------------------------------------------------------------- >> > -- >> > >> > >> > >> > Hesham Soliman >> > >> > >> > >> > => The relevance of the quote from 3775 is that we're putting >> the >> > HoA >> > >> > in >> > >> > the >> > >> > src address of a normal registration. The text says that the >> > receiver >> > >> > of a >> > >> > BU with the HoA in the src address field would assume it's a >> > >> > de-registration, which is obviously not what we want. Hence >my >> > question >> > >> > about violating 3775. >> > >> > >> > >> > >> > >> > >> -----------------------------------+-------------------------------- >> > -------- >> > >> > >> > >> > Reporter: charliep@computer.org | Owner: >> > charliep@computer.org >> > >> > Type: enhancement | Status: new >> > >> > Priority: minor | Milestone: >> > >> > Component: RFC3775 changes >> > >> > | Version: Severity: Active WG >> > >> > Document | Keywords: >> > >> > >> -----------------------------------+-------------------------------- >> > -------- >> > >> > >> > >> >> > >> _______________________________________________ >> > >> MEXT mailing list >> > >> MEXT@ietf.org >> > >> https://www.ietf.org/mailman/listinfo/mext >> > > >> > > >> > > _______________________________________________ >> > > MEXT mailing list >> > > MEXT@ietf.org >> > > https://www.ietf.org/mailman/listinfo/mext >> > > >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >_______________________________________________ >MEXT mailing list >MEXT@ietf.org >https://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 Jul 2 07:19:39 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3E5B3A6C09; Wed, 2 Jul 2008 07:19:38 -0700 (PDT) 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 B82033A6C09 for ; Wed, 2 Jul 2008 07:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.338 X-Spam-Level: X-Spam-Status: No, score=-6.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QonbjRWBmKhu for ; Wed, 2 Jul 2008 07:19:36 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id C1E103A6C08 for ; Wed, 2 Jul 2008 07:19:36 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m62EJO4n024728; Wed, 2 Jul 2008 09:19:45 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Jul 2008 09:20:14 -0500 Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Jul 2008 09:20:13 -0500 Message-ID: <486B8EDD.4070807@ericsson.com> Date: Wed, 02 Jul 2008 10:21:17 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: mext@ietf.org X-OriginalArrivalTime: 02 Jul 2008 14:20:13.0119 (UTC) FILETIME=[BDDFF4F0:01C8DC4E] Subject: [MEXT] New Text for home link detection in RFC3775bis 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org The WG had consensus to fold in text from draft-krishnan-mext-hld into RFC3775bis. Here is the proposed text for doing so. Feel free to edit. This change is made in Section 11.5.4 OLD TEXT ======== A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.1), when the mobile node detects that its home subnet prefix is again on-link. NEW TEXT ======== When an MN detects that it has arrived on a new link using the movement detection algorithm in use (Section 11.5.1) it performs the following steps to determine if it is on the home link. o The MN performs the procedure described in Section 11.5.2 and configures an address referred to as the Current MN Address (CMA). It also stores all the on-link prefix(es) received in the RA along with their prefix lengths in a conceptual list called the Current Link Prefix List (CLPL). o If the home prefix has been statically pre-configured on the MN it checks if the home prefix matches one of the prefixes in the CLPL. If it does, the MN concludes that it has returned home. o If the home prefix has not been statically configured the MN uses some form of bootstrapping procedure (e.g. RFC5026) to determine the home prefix. It then checks if the home prefix matches one of the prefixes in the CLPL. If it does, the MN concludes that it has returned home. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jul 2 11:01:41 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFDAF3A696D; Wed, 2 Jul 2008 11:01:41 -0700 (PDT) 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 B5D513A696D for ; Wed, 2 Jul 2008 11:01:40 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSGVVH3NXkGc for ; Wed, 2 Jul 2008 11:01:39 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id D2C743A687E for ; Wed, 2 Jul 2008 11:01:39 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so448684rvf.49 for ; Wed, 02 Jul 2008 11:01:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=FIAR9p+jdn8fKb16ofHEfUnuULXWmCLLPLvCystfOH0=; b=aLOVafv6BXVATmraX/GgtLjciterMVq74ePkAFpNHJRxOVJxu3OAw0IJ6gln+3E80t JO+xDmUM0Amr/jCyZ52s3OtK7aMSfeRCg5Tw39j25RIw6UMWz0K4BLZYfJ8tkWChZmTP 47fqZ2yBVhWb8K8QRaaVnd8Adz7hwGTGpvYJg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=CfypVG7iXfNwyZguhrobg9wl6tr9rxcVqpq9o9B6dYGpb54RBrRfNeV0wja69sXMcE WRXlWIrd4/e1bbsSRlOMpXAirsykCFBViwUcTE75K4TQJs60OB9iAU2rDHCd6vPFAojx 4IBYwA5gkSZbo5SHxwQHEIQnhzsH76rkeHrZU= Received: by 10.141.49.6 with SMTP id b6mr4556785rvk.89.1215021709220; Wed, 02 Jul 2008 11:01:49 -0700 (PDT) Received: by 10.140.164.11 with HTTP; Wed, 2 Jul 2008 11:01:49 -0700 (PDT) Message-ID: Date: Wed, 2 Jul 2008 11:01:49 -0700 From: "fan zhao" To: "Suresh Krishnan" In-Reply-To: <486B8EDD.4070807@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline References: <486B8EDD.4070807@ericsson.com> Cc: mext@ietf.org Subject: Re: [MEXT] New Text for home link detection in RFC3775bis 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, I have a quick comment: the Home Link Detection is not only performed during handover, but also during initial attach. The new text is proposed into section 11.5.4. "Returning Home", which seems to me that the new text only applies to the handover case. Therefore, my oponion is to have a new (sub)section called "Home Link Detection" somewhere, and refer to this new section in section 11.5.4. What do you think? Sincerely, fan On Wed, Jul 2, 2008 at 7:21 AM, Suresh Krishnan wrote: > The WG had consensus to fold in text from draft-krishnan-mext-hld into > RFC3775bis. Here is the proposed text for doing so. Feel free to edit. > > > > This change is made in Section 11.5.4 > > OLD TEXT > ======== > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > > NEW TEXT > ======== > When an MN detects that it has arrived on a new link using the > movement detection algorithm in use (Section 11.5.1) it performs the > following steps to determine if it is on the home link. > > o The MN performs the procedure described in Section 11.5.2 and > configures an address referred to as the Current MN Address (CMA). > It also stores all the on-link prefix(es) received in the RA along > with their prefix lengths in a conceptual list called the Current > Link Prefix List (CLPL). > > o If the home prefix has been statically pre-configured on the MN > it checks if the home prefix matches one of the prefixes in the > CLPL. If it does, the MN concludes that it has returned home. > > o If the home prefix has not been statically configured the MN uses > some form of bootstrapping procedure (e.g. RFC5026) to determine > the home prefix. It then checks if the home prefix matches one of > the prefixes in the CLPL. If it does, the MN concludes that it has > returned home. > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://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 Jul 2 11:13:42 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CFE43A6CA2; Wed, 2 Jul 2008 11:13:42 -0700 (PDT) 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 0051C3A6CA2 for ; Wed, 2 Jul 2008 11:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.364 X-Spam-Level: X-Spam-Status: No, score=-6.364 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glV7o4EjLGXd for ; Wed, 2 Jul 2008 11:13:40 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 089823A6C84 for ; Wed, 2 Jul 2008 11:13:39 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m62IDmOs007644; Wed, 2 Jul 2008 13:13:48 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Jul 2008 13:14:28 -0500 Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Jul 2008 13:14:27 -0500 Message-ID: <486BC5C4.8000900@ericsson.com> Date: Wed, 02 Jul 2008 14:15:32 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: fan zhao References: <486B8EDD.4070807@ericsson.com> In-Reply-To: X-OriginalArrivalTime: 02 Jul 2008 18:14:27.0864 (UTC) FILETIME=[7727D980:01C8DC6F] Cc: mext@ietf.org Subject: Re: [MEXT] New Text for home link detection in RFC3775bis 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Fan, Sounds like a good idea. Cheers Suresh fan zhao wrote: > Hi Suresh, > > I have a quick comment: > the Home Link Detection is not only performed during handover, > but also during initial attach. The new text is proposed into section > 11.5.4. "Returning Home", which seems to me that the new text > only applies to the handover case. > > Therefore, my oponion is to have a new (sub)section called "Home Link > Detection" somewhere, and refer to this new section in section 11.5.4. > What do you think? > > Sincerely, > fan > > On Wed, Jul 2, 2008 at 7:21 AM, Suresh Krishnan > wrote: >> The WG had consensus to fold in text from draft-krishnan-mext-hld into >> RFC3775bis. Here is the proposed text for doing so. Feel free to edit. >> >> >> >> This change is made in Section 11.5.4 >> >> OLD TEXT >> ======== >> A mobile node detects that it has returned to its home link through >> the movement detection algorithm in use (Section 11.5.1), when the >> mobile node detects that its home subnet prefix is again on-link. >> >> NEW TEXT >> ======== >> When an MN detects that it has arrived on a new link using the >> movement detection algorithm in use (Section 11.5.1) it performs the >> following steps to determine if it is on the home link. >> >> o The MN performs the procedure described in Section 11.5.2 and >> configures an address referred to as the Current MN Address (CMA). >> It also stores all the on-link prefix(es) received in the RA along >> with their prefix lengths in a conceptual list called the Current >> Link Prefix List (CLPL). >> >> o If the home prefix has been statically pre-configured on the MN >> it checks if the home prefix matches one of the prefixes in the >> CLPL. If it does, the MN concludes that it has returned home. >> >> o If the home prefix has not been statically configured the MN uses >> some form of bootstrapping procedure (e.g. RFC5026) to determine >> the home prefix. It then checks if the home prefix matches one of >> the prefixes in the CLPL. If it does, the MN concludes that it has >> returned home. >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://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 Jul 3 06:02:26 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D78FD3A6946; Thu, 3 Jul 2008 06:02:26 -0700 (PDT) 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 7AD4F3A67EB for ; Thu, 3 Jul 2008 06:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFF7jem-RiMn for ; Thu, 3 Jul 2008 06:02:24 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 1DB753A6946 for ; Thu, 3 Jul 2008 06:01:43 -0700 (PDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Jul 2008 11:07:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Jul 2008 11:07:02 +0200 Message-ID: In-Reply-To: <486BC5C4.8000900@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] New Text for home link detection in RFC3775bis Thread-Index: Acjcb2QUm0U6PUCzTomJtngbAUP3OAAeq8dg References: <486B8EDD.4070807@ericsson.com> <486BC5C4.8000900@ericsson.com> From: To: , X-OriginalArrivalTime: 03 Jul 2008 09:07:09.0793 (UTC) FILETIME=[2C8D9D10:01C8DCEC] Cc: mext@ietf.org Subject: Re: [MEXT] New Text for home link detection in RFC3775bis 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="===============1472319291==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============1472319291== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8DCEC.2C736809" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8DCEC.2C736809 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I hope that the following can hepl: If the MN has no configuration then A otherwise B. A: Bootstrap o The MN has neither IP address, nor the HA IP address, nor home IP = prefix, o The MN connects to a network, obtains a link IP prefix and acquires or = forms an IP address (MN@) o The MN discovers the HA IP address and its home IP prefixes o The MN compares the prefix of its IP address (MN@) with the home IP = prefixes - If those prefixes match then the MN is in its home network, = HoA=3DMN@, and the HA is the HA for this HoA. The MN initiates IP = sessions with classical routing. - If not then the MN is in a foreign network, CoA=3DMN@, the HA is a = HA for the MN. The MN will form a HoA from home prefixes or will request = a HoA from the HA and will exchange a BU/BA with the HA. The MN = initiates IP sessions using MIP. B. Handover o The MN has a HoA, the HA IP address and its home IP prefixes o The MN connects to the network and obtains a link IP prefix o The MN compares the link IP prefix with the HoA IP prefix - If those prefixes match then the MN is in its home network + If the MN has no CoA: It means that the MN is always on its home = network. It has made no IP handover therefore it does not need to send a = BU. The MN continues its IP sessions with classical routing. + If the MN already has a CoA: It means that the MN returns at its = home network then it has to sends a BU to deregister. The MN continues = its IP sessions with classical routing. - If the prefixes do not match then the MN is in a foreign network + if the MN has no CoA: It means that the MN comes from its home = network then it forms (or acquires) a CoA with the link prefix on which = it has just connected and sends a BU to its HA. The MN continues its IP = sessions using MIP. + If the MN already has a CoA: * If the link prefixes and the CoA prefix match: It means that the = MN is always on the same foreign network. It has made no IP handover = therefore it does not need to send a BU. The MN continues its IP = sessions using MIP. * If the link prefixes and the CoA prefix do not match: it means = that the MN has made IP handover towards another foreign network = therefore it has to form (or acquire) a CoA with the link prefix on = which it has just connected and to send a BU to its HA to update its = registration. The MN continues its IP sessions using MIP. o Note that when the mobile node connects on a new visited network it = may need to discover the HA of this network if available. The mobile = node may have to use this HA for next IP sessions. Sincerly, Kassi -----Message d'origine----- De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la part de = Suresh Krishnan Envoy=E9 : mercredi 2 juillet 2008 20:16 =C0 : fan zhao Cc : mext@ietf.org Objet : Re: [MEXT] New Text for home link detection in RFC3775bis Hi Fan, Sounds like a good idea. Cheers Suresh fan zhao wrote: > Hi Suresh, >=20 > I have a quick comment: > the Home Link Detection is not only performed during handover, but=20 > also during initial attach. The new text is proposed into section=20 > 11.5.4. "Returning Home", which seems to me that the new text only=20 > applies to the handover case. >=20 > Therefore, my oponion is to have a new (sub)section called "Home Link=20 > Detection" somewhere, and refer to this new section in section 11.5.4. > What do you think? >=20 > Sincerely, > fan >=20 > On Wed, Jul 2, 2008 at 7:21 AM, Suresh Krishnan=20 > wrote: >> The WG had consensus to fold in text from draft-krishnan-mext-hld=20 >> into RFC3775bis. Here is the proposed text for doing so. Feel free to = edit. >> >> >> >> This change is made in Section 11.5.4 >> >> OLD TEXT >> =3D=3D=3D=3D=3D=3D=3D=3D >> A mobile node detects that it has returned to its home link through >> the movement detection algorithm in use (Section 11.5.1), when the >> mobile node detects that its home subnet prefix is again on-link. >> >> NEW TEXT >> =3D=3D=3D=3D=3D=3D=3D=3D >> When an MN detects that it has arrived on a new link using the >> movement detection algorithm in use (Section 11.5.1) it performs = the >> following steps to determine if it is on the home link. >> >> o The MN performs the procedure described in Section 11.5.2 and >> configures an address referred to as the Current MN Address = (CMA). >> It also stores all the on-link prefix(es) received in the RA = along >> with their prefix lengths in a conceptual list called the = Current >> Link Prefix List (CLPL). >> >> o If the home prefix has been statically pre-configured on the MN >> it checks if the home prefix matches one of the prefixes in the >> CLPL. If it does, the MN concludes that it has returned home. >> >> o If the home prefix has not been statically configured the MN = uses >> some form of bootstrapping procedure (e.g. RFC5026) to determine >> the home prefix. It then checks if the home prefix matches one = of >> the prefixes in the CLPL. If it does, the MN concludes that it = has >> returned home. >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext ------_=_NextPart_001_01C8DCEC.2C736809 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [MEXT] New Text for home link detection in RFC3775bis

Hi = all,

I = hope that the following can hepl:

 If the MN has no configuration then A otherwise = B.

A: = Bootstrap

o = The MN has neither IP address, nor the HA IP address, nor home IP = prefix,

o = The MN connects to a network, obtains a link IP prefix and acquires or = forms an IP address (MN@)

o = The MN discovers the HA IP address and its home IP = prefixes

o = The MN compares the prefix of its IP address (MN@) with the home IP = prefixes

      - = If those prefixes match then the MN is in its home network, HoA=3DMN@, = and the HA is the HA for this HoA. The MN initiates IP sessions with = classical routing.

      - = If not then the MN is in a foreign network, CoA=3DMN@, the HA is a HA = for the MN. The MN will form a HoA from home prefixes or will request a = HoA from the HA and will exchange a BU/BA with the HA. The MN initiates = IP sessions using MIP.

B. = Handover

o = The MN has a HoA, the HA IP address and its home IP = prefixes

o = The MN connects to the network and obtains a link IP = prefix

o = The MN compares the link IP prefix with the HoA IP = prefix

      - = If those prefixes match then the MN is in its home = network

              + = If the MN has no CoA: It means that the MN is always on its home = network. It has made no IP handover therefore it does not need to send a = BU. The MN continues its IP sessions with classical = routing.

              + = If the MN already has a CoA: It means that the MN returns at its home = network then it has to sends a BU to deregister. The MN continues its IP = sessions with classical routing.

      - = If the prefixes do not match then the MN is in a foreign = network

              + = if the MN has no CoA: It means that the MN comes from its home network = then it forms (or acquires) a CoA with the link prefix on which it has = just connected and sends a BU to its HA. The MN continues its IP = sessions using MIP.

              + = If the MN already has a CoA:

                  * = If the link prefixes and the CoA prefix match: It means that the MN is = always on the same foreign network. It has made no IP handover therefore = it does not need to send a BU. The MN continues its IP sessions using = MIP.

                  * = If the link prefixes and the CoA prefix do not match: it means that the = MN has made IP handover towards another foreign network therefore it has = to form (or acquire) a CoA with the link prefix on which it has just = connected and to send a BU to its HA to update its registration. The MN = continues its IP sessions using MIP.

o = Note that when the mobile node connects on a new visited network it may = need to discover the HA of this network if available. The mobile node = may have to use this HA for next IP sessions.

Sincerly,

Kassi


-----Message = d'origine-----
De : = mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la part de Suresh = Krishnan
Envoy=E9 : mercredi = 2 juillet 2008 20:16
=C0 : fan = zhao
Cc : = mext@ietf.org
Objet : Re: [MEXT] = New Text for home link detection in RFC3775bis

Hi Fan,
   Sounds = like a good idea.

Cheers
Suresh

fan zhao = wrote:
> Hi = Suresh,
>
> I have a quick = comment:
> the Home Link = Detection is not only performed during handover, but
> also during = initial attach. The new text is proposed into section
> 11.5.4.  = "Returning Home", which seems to me that the new text only =
> applies to the = handover case.
>
> Therefore, my = oponion is to have a new (sub)section called "Home Link =
> Detection" = somewhere, and refer to this new section in section = 11.5.4.
> What do you = think?
>
> = Sincerely,
> = fan
>
> On Wed, Jul 2, = 2008 at 7:21 AM, Suresh Krishnan
> = <suresh.krishnan@ericsson.com> wrote:
>> The WG had = consensus to fold in text from draft-krishnan-mext-hld
>> into = RFC3775bis. Here is the proposed text for doing so. Feel free to = edit.
>>
>>
>>
>> This change = is made in Section 11.5.4
>>
>> OLD = TEXT
>> = =3D=3D=3D=3D=3D=3D=3D=3D
>>   = A mobile node detects that it has returned to its home link = through
>>   = the movement detection algorithm in use (Section 11.5.1), when = the
>>   = mobile node detects that its home subnet prefix is again = on-link.
>>
>> NEW = TEXT
>> = =3D=3D=3D=3D=3D=3D=3D=3D
>>   = When an MN detects that it has arrived on a new link using = the
>>   = movement detection algorithm in use (Section 11.5.1) it performs = the
>>   = following steps to determine if it is on the home link.
>>
>>   = o  The MN performs the procedure described in Section 11.5.2 = and
>>      configures an = address referred to as the Current MN Address (CMA).
>>      It also stores all = the on-link prefix(es) received in the RA along
>>      with their prefix = lengths in a conceptual list called the Current
>>      Link Prefix List = (CLPL).
>>
>>   = o  If the home prefix has been statically pre-configured on the = MN
>>      it checks if the = home prefix matches one of the prefixes in the
>>      CLPL. If it does, = the MN concludes that it has returned home.
>>
>>   = o  If the home prefix has not been statically configured the MN = uses
>>      some form of = bootstrapping procedure (e.g. RFC5026) to determine
>>      the home prefix. = It then checks if the home prefix matches one of
>>      the prefixes in = the CLPL. If it does, the MN concludes that it has
>>      returned = home.
>>
>> = _______________________________________________
>> MEXT = mailing list
>> = MEXT@ietf.org
>> = https://www.ietf.org/mailman/listinfo/mext
>>

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

------_=_NextPart_001_01C8DCEC.2C736809-- --===============1472319291== 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 --===============1472319291==-- From mext-bounces@ietf.org Fri Jul 4 01:49:00 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4014E3A6AFC; Fri, 4 Jul 2008 01:49:00 -0700 (PDT) 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 609083A6AFC for ; Fri, 4 Jul 2008 01:48:59 -0700 (PDT) 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_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyDIVzwOT1Bc for ; Fri, 4 Jul 2008 01:48:57 -0700 (PDT) Received: from smtp-2.dlr.de (smtp-3.dlr.de [195.37.61.187]) by core3.amsl.com (Postfix) with ESMTP id 39F173A6AAA for ; Fri, 4 Jul 2008 01:48:56 -0700 (PDT) Received: from exbe04.intra.dlr.de ([192.168.35.37]) by smtp-2.dlr.de with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Jul 2008 10:49:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Jul 2008 10:49:02 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-bauer-mext-aero-topology-00 thread-index: AcjdsazrrtTrR7ReQNuEh49hMeZB9AAAFUog From: To: X-OriginalArrivalTime: 04 Jul 2008 08:49:03.0356 (UTC) FILETIME=[CF663BC0:01C8DDB2] Subject: [MEXT] New Version Notification for draft-bauer-mext-aero-topology-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-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Dear all, For those interested in the work on aeronautical NEMO RO: we have written a= draft that provides an overview of the topology of the Aeronautical Teleco= mmunications Network. It is supposed to be useful for the upcoming solution space analysis that s= hould take place over the next couple of weeks. Cheers Christian -----Urspr=FCngliche Nachricht----- Von: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] = Gesendet: Freitag, 4. Juli 2008 10:41 An: Bauer, Christian Cc: Ayaz, Serkan Betreff: New Version Notification for draft-bauer-mext-aero-topology-00 = A new version of I-D, draft-bauer-mext-aero-topology-00.txt has been succes= sfuly submitted by Christian Bauer and posted to the IETF repository. Filename: draft-bauer-mext-aero-topology Revision: 00 Title: ATN Topology Considerations for Aeronautical NEMO RO Creation_date: 2008-07-04 WG ID: Independent Submission Number_of_pages: 16 Abstract: The intention of this draft is to provide an overview of the topology of the Aeronautical Telecommunications Network to help with the analysis of the possible options of NEMO RO within this context. The intention is to allow taking the existing NEMO RO solution space analysis document and cross-check it with the aeronautical environment presented within this document. = = The IETF Secretariat. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 7 17:46:48 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 525FD28C390; Mon, 7 Jul 2008 17:46:48 -0700 (PDT) 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 5682428C38E for ; Mon, 7 Jul 2008 17:46:45 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlH52RH0R90k for ; Mon, 7 Jul 2008 17:46:43 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id A4A8528C393 for ; Mon, 7 Jul 2008 17:46:23 -0700 (PDT) Received: from [66.245.12.28] (helo=[192.168.1.4]) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KG1Le-0004WN-EO; Mon, 07 Jul 2008 20:46:29 -0400 Message-ID: <4872B8DD.8030104@computer.org> Date: Mon, 07 Jul 2008 17:46:21 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Vijay Devarapalli References: <063.eee1db399c39efaaf5a50a65984c5bdf@tools.ietf.org> <4869122D.5090701@computer.org> <48696974.2030503@wichorus.com> In-Reply-To: <48696974.2030503@wichorus.com> X-ELNK-Trace: 5a185a306015b1a28a306fc704168558239a348a220c26099fb341889e41687e8075f82b57fd02132601a10902912494350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.245.12.28 Cc: mext@ietf.org Subject: Re: [MEXT] [mext] #7: DSMIPv6 BU format and RFC 3775 [Tero Kauppinen ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: charliep@computer.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Vijay, If this interpretation is removed, then what remains is an error condition or, worse, unspecified behavior. I think the simplification amounts a very small amount of code reduction in one place followed by a potentially much larger addition of code in another place. Plus then we'll have to haggle over exactly just how to resolve the error condition or whatever you want to call it. In this case, I don't see that anything is broken enough to warrant making the suggested change. On the other hand, since I am all in favor of actual simplifications, I'm happy to take fully considered arguments (and text). Regards, Charlie P. Vijay Devarapalli wrote: > Hi Charlie, > > I think the text in RFC 3775 needs to be fixed. RFC 3775 assumes that a > binding update is sent with the home address option and with the care-of > address stored either in the source address in the IPv6 header or in > alternate care-of address option. So it specifies that if the care-of > address matches the home address in the home address option, it is safe > for the home agent to assume that the binding update was sent from the > home link and can be treated as a de-registration BU. > > In practice, I have never seen a Binding Update, where the lifetime is > non-zero and the care-of address matches the home address, from a mobile > node implementation. Only the TAHI test suite sends such a binding > update, since they have to test conformance to RFC 3775. :) If the > mobile node detects that its care-of address matches the home address, > it knows it has returned home and sets the lifetime to zero in the > binding update it sends to the home agent. > > I would suggest removing it and treat only the binding update with > lifetime set to zero as a de-registration. It would help in simplifying > the de-registration procedure a little bit. > > Vijay > > > Charles E. Perkins wrote: >> >> Hello folks, >> >> So far, I did not find a persuasive reason to make >> changes to RFC 3775 related to this issue with >> DSMIPv6. Unless someone can suggest text that might >> be needed, I would recommend to close this issue >> without modification to rfc3775bis. >> >> Regards, >> Charlie P. >> >> >> >> mext wrote: >>> Ticket #7: DSMIPv6 BU format and RFC 3775 [Tero Kauppinen >>> ] >>> >>> DSMIPv6 BU format and RFC 3775 >>> Tero Kauppinen >>> >>> While reading the current version of DSMIPv6 >>> (draft-ietf-mip6-nemo-v4traversal-06) and I came across with one >>> sentence which strikes me as odd. >>> >>> "4.2. NAT detection and traversal >>> >>> NAT detection is done when the initial binding update message is >>> sent >>> from the mobile node to the home agent. When located in an IPv4-only >>> foreign link, the mobile node sends the binding update message >>> encapsulated in UDP and IPv4. The source address of the IPv6 packet >>> is the mobile node's IPv6 home address. The destination address is >>> the IPv6 address of the home agent. The IPv4 header contains the >>> IPv4 >>> care-of address in the source address field and the IPv4 address of >>> the home agent in the destination address field. >>> >>> When the home agent receives the encapsulated binding update it >>> compares the IPv4 address of the source address field in the IPv4 >>> header with the IPv4 address in the source address of the IPv6 >>> header." >>> >>> If the IPv6 header contains the mobile node's IPv6 home address, how >>> can >>> it ever match with the IPv4 address of the source address field in the >>> IPv4 header? Furthermore, RFC3775 in 9.5.1. says "If the Lifetime >>> specified in the Binding Update is zero or the specified care-of >>> address >>> matches the home address for the binding, then this is a request to >>> delete the cached binding for the home address." >>> >>> So, >>> >>> (1) Should the IPv6 header actually contain an IPv4 mapped IPv6 >>> address? >>> >>> Or >>> >>> (2) Should the IPv4 address of the source address field in the IPv4 >>> header be compared with the address specified in the packet's IPv4 CoA >>> option? >>> >>> --------------------------------------------------------------------- >>> >>> George Tsirtsis >>> >>> I would go with (2), as I think this was the intention (i.e., I >>> consider this a typo). >>> >>> It is not, however, clear to me what the relevance of the quoted text >>> from 3775 is. >>> Whether (1) or (2) is used it should not result in the condition of >>> CoA==HoA in the BU. >>> >>> --------------------------------------------------------------------- >>> >>> Pascal Thubert >>> >>> I favor 1) and the text seems to be a leftover from your original draft >>> which worked that way. >>> But I remember that the question was cut against it by the chairs >>> because there was no proper consensus either way. >>> >>> Now I really hate the idea of a BU process that would have to figure if >>> a BU is a registration or deregistration just because the packet was >>> received over an interface that is an IPv4 tunnel as opposed to the >>> Home >>> Link. That seems plain wrong. I have a tendency to think that what's >>> wrong is really RFC 3775 (lifetime 0 should be the way to deregister) >>> but unless we revise it, I'd suggest we keep consistent with that >>> foundation RFC. If we REALLY do not want a mapped address as source, >>> then maybe we could use the UNSPECIFIED address instead? >>> >>> --------------------------------------------------------------------- >>> >>> Vijay Devarapalli : >>> >>> > "4.2. NAT detection and traversal >>> > >>> > NAT detection is done when the initial binding update message >>> is sent >>> > from the mobile node to the home agent. When located in an >>> IPv4-only >>> > foreign link, the mobile node sends the binding update message >>> > encapsulated in UDP and IPv4. The source address of the IPv6 >>> packet >>> > is the mobile node's IPv6 home address. The destination address is >>> > the IPv6 address of the home agent. The IPv4 header contains >>> the IPv4 >>> > care-of address in the source address field and the IPv4 >>> address of >>> > the home agent in the destination address field. >>> > >>> > When the home agent receives the encapsulated binding update it >>> > compares the IPv4 address of the source address field in the IPv4 >>> > header with the IPv4 address in the source address of the IPv6 >>> > header." >>> >>> This text is old. The home agent needs to compare it with the IPv4 >>> address in the IPv4 CoA option. So this paragraph should actually >>> say >>> >>> When the home agent receives the encapsulated binding update it >>> compares the IPv4 address of the source address field in the IPv4 >>> header with the IPv4 address in the IPv4 care-of address option >>> in the Binding Update. >>> >>> > If the IPv6 header contains the mobile node's IPv6 home address, >>> how can >>> > it ever match with the IPv4 address of the source address field in >>> the >>> > IPv4 header? Furthermore, RFC3775 in 9.5.1. says "If the Lifetime >>> > specified in the Binding Update is zero or the specified care-of >>> address >>> > matches the home address for the binding, then this is a request to >>> > delete the cached binding for the home address." >>> >>> This text needs to be clarified in RFC 3775. Regarding the actual >>> "violation", I don't think there is a conflict. The DS-MIPv6 >>> binding update has an IPv4 CoA option (similar to the alt CoA >>> option) which when present dictates a different behavior on the >>> home agent that implements DS-MIPv6 extensions. It is more like >>> DS-MIPv6 updates MIPv6 home agent behavior when the IPv4 CoA >>> option is present. >>> >>> >>> --------------------------------------------------------------------- >>> >>> Basavaraj Patil >>> >>> Option 2 is what I believe the intent has been. Option 2 IMO is a >>> better >>> choice even though it does diverge from RFC3775 design. But given that >>> this >>> I-D is extending the base MIP6 RFC, I believe it is okay to proceed >>> with >>> option 2. >>> >>> >>> --------------------------------------------------------------------- >>> >>> Hesham Soliman >>> >>> => The relevance of the quote from 3775 is that we're putting the >>> HoA in >>> the >>> src address of a normal registration. The text says that the >>> receiver of a >>> BU with the HoA in the src address field would assume it's a >>> de-registration, which is obviously not what we want. Hence my question >>> about violating 3775. >>> >>> >>> -----------------------------------+---------------------------------------- >>> >>> Reporter: charliep@computer.org | Owner: charliep@computer.org >>> Type: enhancement | Status: >>> new Priority: minor | >>> Milestone: Component: RFC3775 changes >>> | Version: Severity: Active WG >>> Document | Keywords: >>> -----------------------------------+---------------------------------------- >>> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 7 17:51:12 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45CC628C377; Mon, 7 Jul 2008 17:51:12 -0700 (PDT) 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 EAB0128C14D for ; Mon, 7 Jul 2008 17:51:10 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDHMUbYwIL8A for ; Mon, 7 Jul 2008 17:51:10 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 0FA3F28C377 for ; Mon, 7 Jul 2008 17:51:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=YoTNJSR4hm8neuBDnGR2hDzwqOQDnG+jnMxDAmeXU3JvJZaJtVbdpSc83n0cy1Um; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [66.245.12.28] (helo=[192.168.1.4]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1KG1QD-0001TB-Vy; Mon, 07 Jul 2008 20:51:11 -0400 Message-ID: <4872B9F5.1040704@earthlink.net> Date: Mon, 07 Jul 2008 17:51:01 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: mext@ietf.org References: <200803271024.49601.julien.IETF@laposte.net><48654BFB.5000005@earthlink.net> <87ej6hzr5x.fsf@natisbad.org> In-Reply-To: X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5281a6710e810a06640e5251f94a5760b9350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.245.12.28 Subject: Re: [MEXT] Issue #2: Recommendation for closure on on "Use of DHAADmechanism" 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello folks, I think on this issue #2, that we have pretty good consensus as long as the following paragraph is not added to the text of rfc3775bis: > * Finally, it should be noted that the specification of ICMP to carry > > * DHAAD incurs a certain deployability risk related to the perceived > > * insecurity of ICMP messages. Many ISPs are blocking ICMP on all links > > * except the first hop, because ICMP is known to be a vehicle for DoS > > * attacks and other sorts of threats. If anyone wants to champion the inclusion of this text, please do so soon. Otherwise, I'll go ahead with the other suggested changes on this topic but not include this ICMP-related paragraph. Regards, Charlie P. Vijay Devarapalli wrote: >>> * Finally, it should be noted that the specification of ICMP to >>> > carry > >>> * DHAAD incurs a certain deployability risk related to the >>> > perceived > >>> * insecurity of ICMP messages. Many ISPs are blocking ICMP on all >>> >> links >> >>> * except the first hop, because ICMP is known to be a vehicle for >>> > DoS > >>> * attacks and other sorts of threats. >>> >> IMHO, this should go. >> > > I agree, but for a different reason though. If ICMP is blocked, isn't it > obvious that DHAAD messages can't make it through? > > Viujay > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From hqqotzrq@aims1.every1.net Mon Jul 7 21:41: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 93CAF3A681B; Mon, 7 Jul 2008 21:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.888 X-Spam-Level: *** X-Spam-Status: No, score=3.888 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ivp6h+Kx3Ivb; Mon, 7 Jul 2008 21:41:53 -0700 (PDT) Received: from proxyrouter1.eatontownpolice.com (unknown [81.214.33.221]) by core3.amsl.com (Postfix) with SMTP id 9C5CD3A6405; Mon, 7 Jul 2008 21:41:46 -0700 (PDT) Received: from 67.72.25.046 (mta037.email-value.com) (67.72.25.046) by rly04.mail.ejobs.every1.net with ESMTP; Mon, 07 Jul 2008 21:41:56 -0800 Received: (qmail 3754 invoked by alias); Mon, 07 Jul 2008 21:41:56 -0800 Domainkey-Signature: a=vob-vbl1; q=dns; c=qcqsw; s=s1960; d=z2c.net; b=in7PlxTzxLq8PAXT6ugQFpFsQmgNaaTJnikDro7FxKvx4m7uRH/2qpGZ92Ef0KAgteL3FRfXPTtAg3VUgs6lMudK7if2wOeqnqhlIPr1C7ofcYIeyfqFA4jA5+bzur9niuzLcd8CsAIXUCPPyCP0ApN7= Message-ID: <362965958178619aws5srr8pu6.9047940549902.Mail.news@slope.musicforchrist.5u.com> Date: Mon, 07 Jul 2008 21:41:56 -0800 (PDT) From: "abbey" To: mpls-request@lists.ietf.org Subject: hello from abbey Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-mpm: 362965958178619aws5srr8pu6 Hi It`s abbey again. Will you ever contact me? I made those nude pictures especially for you and I wont write to you again! If you wanna see them just drop me a line at: babbey0@hugdr.info From mext-bounces@ietf.org Tue Jul 8 09:30:44 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C470E3A6A86; Tue, 8 Jul 2008 09:30:44 -0700 (PDT) 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 694943A69B8 for ; Tue, 8 Jul 2008 09:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAu1intyO9Az for ; Tue, 8 Jul 2008 09:30:39 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id E3AEB3A6982 for ; Tue, 8 Jul 2008 09:30:38 -0700 (PDT) Received: from localhost ([127.0.0.1]:47409 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1KGG5T-0000DB-Ck; Tue, 08 Jul 2008 18:30:43 +0200 MIME-Version: 1.0 From: "mext" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software To: charliep@computer.org X-Trac-Project: mext Date: Tue, 08 Jul 2008 16:30:43 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://www3.tools.ietf.org/wg/mext/trac/ticket/8 Message-ID: <063.7622031672aced0787b70d358cb06abb@tools.ietf.org> X-Trac-Ticket-ID: 8 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, julien.IETF@laposte.net, mext@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: julien.IETF@laposte.net, mext@ietf.org Subject: [MEXT] "[mext] #8: Application using the care-of address " X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mext@ietf.org 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 Ticket #8: Application using the care-of address RFC3775 mentions two times the possibility to use the care-of address as a source address in outgoing packets. In the first occurence, RFC3775 says that APIs to control this use are out-of-scope, but since an API that allows an application to require the care-of address to be used in outgoing packets has been specified since then in RFC5014, RFC3775bis could mention RFC5014 as an example of such an API. In the second occurence, RFC3775 says that a multicast application could use the care-of address as a source address in outgoing packets if it know the care-of address, but since RFC5014 allows to use the care-of address as a source address without requiring the application to knows the address itself that should be corrected in RFC3775bis. See below the two slight modifications, plus the additional informative reference. Please let me know what you think. Thanks, --julien ------------------------------------------------------------------------- OLD: o The mobile node MAY choose to directly use one of its care-of addresses as the source of the packet, not requiring the use of a Home Address option in the packet. This is particularly useful for short-term communication that may easily be retried if it fails. Using the mobile node's care-of address as the source for such queries will generally have a lower overhead than using the mobile node's home address, since no extra options need be used in either the query or its reply. Such packets can be routed normally, directly between their source and destination without relying on Mobile IPv6. If application running on the mobile node has no particular knowledge that the communication being sent fits within this general type of communication, however, the mobile node should not use its care-of address as the source of the packet in this way. The choice of the most efficient communications method is application specific, and outside the scope of this specification. The APIs necessary for controlling the choice are also out of scope. NEW: o The mobile node MAY choose to directly use one of its care-of addresses as the source of the packet, not requiring the use of a Home Address option in the packet. This is particularly useful for short-term communication that may easily be retried if it fails. Using the mobile node's care-of address as the source for such queries will generally have a lower overhead than using the mobile node's home address, since no extra options need be used in either the query or its reply. Such packets can be routed normally, directly between their source and destination without relying on Mobile IPv6. If application running on the mobile node has no particular knowledge that the communication being sent fits within this general type of communication, however, the mobile node should not use its care-of address as the source of the packet in this way. The choice of the most efficient communications method is application specific, and outside the scope of this specification. The APIs necessary for controlling the choice are also out of | scope. One example of such an API is described in the IPv6 Socket | API for Source Address Selection specification [RFC5014]. -------------------------------------------------------------------------- OLD: A mobile node that wishes to send packets to a multicast group also has two options: 1. Send directly on the foreign link being visited. The application is aware of the care-of address and uses it as a source address for multicast traffic, just like it would use a stationary address. The mobile node MUST NOT use Home Address destination option in such traffic. NEW: A mobile node that wishes to send packets to a multicast group also has two options: 1. Send directly on the foreign link being visited. | The application uses the care-of address as a source address for | multicast traffic, just like it would use a stationary address. | This requires that the application either knows the care-of | address, or uses an API such as the IPv6 Socket API for Source | Address Selection specification [RFC5014] to request the stack to | use the care-of address as a source address in sent packets. The mobile node MUST NOT use Home Address destination option in such traffic. -------------------------------------------------------------------------- NEW: 18.2. Informative References | [RFC5014] Nordmark, E., Chakrabarti, S., and Laganier, J., "IPv6 | Socket API for Source Address Selection", RFC 5014, | September 2007. ---- [editorial note by Charles E. Perkins]: Following this, there was a discussion about how to enable an IKE daemon to use the care-of address. Since that seems out of scope for rfc3775bis, I have not included it as part the discussion for this issue. ----------------------------------------+----------------------------------- Reporter: charliep@computer.org | Owner: charliep@computer.org Type: enhancement | Status: new Priority: minor | Milestone: Component: draft-ietf-mext-rfc3775bis | Version: Severity: Active WG Document | Keywords: ----------------------------------------+----------------------------------- -- Ticket URL: mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 8 10:31:20 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5412C3A68D6; Tue, 8 Jul 2008 10:31:20 -0700 (PDT) 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 20C773A6780 for ; Tue, 8 Jul 2008 10:31:19 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPn1o0ROreB8 for ; Tue, 8 Jul 2008 10:31:18 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id E56803A6A90 for ; Tue, 8 Jul 2008 10:31:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=j9i9KC4yhsZVYvkn9tc5emzoreVCa0DfeZK2bnRniaLJC8XghZEYRCo3t3eYklvl; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [75.26.137.116] (helo=[10.166.255.10]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1KGH1v-0003EH-LU; Tue, 08 Jul 2008 13:31:08 -0400 Message-ID: <4873A45A.7020106@earthlink.net> Date: Tue, 08 Jul 2008 10:31:06 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Arnaud Ebalard , Julien Laganier References: <200806050918.05372.julien.IETF@laposte.net> <200806061144.23200.julien.IETF@laposte.net> <20080606100743.GA12803@sd-5945.dedibox.fr> <200806061349.32192.julien.IETF@laposte.net> <878wxgungh.fsf@natisbad.org> In-Reply-To: <878wxgungh.fsf@natisbad.org> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52fdbe85386ccdece4caaa4c7437a6f9b8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Cc: mext@ietf.org Subject: Re: [MEXT] [rfc3775] Application using the care-of address 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello folks, It seems to me that socket handling by IKE versus availability of the Care-of Address from MIPv6 is out of scope for rfc3775bis. I've created a new issue for Julien's original proposed (informational) update. Up until now, I haven't included the text for the IKE socket handling question as part of the background discussion for the new issue, but I can always go back and add it later if need be. Regards, Charlie P. Arnaud Ebalard wrote: > Hi Julien and sorry for the latency, > > Julien Laganier writes: > > >>>> RFC5014 allows a sending process to express to the IP stack its >>>> preference for a CoA to be selected as source address in outbound >>>> packets, and then allows the process to verify that the selected >>>> source address is indeed a CoA: >>>> >>>> ... snip ... >>>> >>> I think you miss the point. >>> >> I guess I do... >> > > With 5014, you can manage to get a socket that will use a CoA as source > address (with the ability to verify it is indeed a CoA). For common > applications, I imagine that this is just fine because they simply > do not care about the address itself but simply want to use a CoA and > delegate the address decision to the system. > > For the interaction between MIPv6 and IPsec/IKE, a more direct path is > needed (IMHO, other developers that have spent time on the code should > comment) at various moments where the MIPv6 process must influence the > IPsec stack and the IKE daemon in a very specific way: > > - Bootstrapping (handling of transport mode SA by IKE) > - Update of in-kernel SP/SA on movement > - Update of IKE-daemon mirrored SP/SA on movement > - Update of IKE_SA endpoints on movements > - ... > > I think that in the specific case of bootstrapping, it would be possible > to specifically mark the SP (or SA information to be negotiated, even if > it would introduce a daemon/system specific issue in some way) for the > IKE daemon to use a CoA. From your previous code samples, I think that > the IKE daemon will manage to get a socket using a CoA as source, > retrieve this CoA and consider it the expected source address to use for > the negotiation of the IKE_SA (the socket is directly usable but the @ > is certainly needed for internal tasks). After scratching my head, I > think what you propose could take off, but probably won't fly well or at > all. An IKE daemon differs from a common app regarding handling of > adresses: it has to be very careful and handle things at a somewhat > lower level than a common app. > > I also have some questions (don't hesitate to reply with pointers if it > is documented) associated with your expected use of 5014 for MIPv6 > bootstrapping by IKE: what happens when there are multiple addresses on > the system (for instance a native, an ULA and a 6to4 address). What is > their status? all CoA? The MIPv6 process will choose one specific > address for the binding with its HoA (source of the BU when it leaves > the MN) based on specific internal policies. What gives the insurance > that this address will be the one that the IKE daemon will use if it > implements 5014 for bootstrapping? > > To continue on that path, do you see a simple way for the IKE daemon to > update its IKE_SA endpoints on movement with a new CoA (item 4 in my > previous list)? How will it be warned to do the change? What are the > expected actions to be taken? > > Because a decision has already been taken on the interest of some work > on such a mechanism by the WG, I should probably keep the following > additional question for me: what about items 2 and 3? > > In the end, it is obvious that a MIPv6 process needs to interact with > IPsec/IKE. I'd like to be proven false by some implementations (MIPv6, > IKE, IPsec stack) that could use what is currently on the table > (normalized documents, i.e. RFC) to provide something that works. > > Cheers, > > a+ > > ------------------------------------------------------------------------ > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 8 11:02:24 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BEBD3A67C1; Tue, 8 Jul 2008 11:02:24 -0700 (PDT) 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 AF4253A68D9 for ; Tue, 8 Jul 2008 11:02:22 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lavo+y7X30st for ; Tue, 8 Jul 2008 11:02:22 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id CB5C13A67C1 for ; Tue, 8 Jul 2008 11:02:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=mHatLRKSyrMuKAMKFzPwtvuXzi2X3764+rFKYe9JIZ8v58nGbaBmYbyeyMLOzPVl; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [75.26.137.116] (helo=[10.166.255.10]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1KGHVy-0006vD-9B; Tue, 08 Jul 2008 14:02:10 -0400 Message-ID: <4873AB9F.2020205@earthlink.net> Date: Tue, 08 Jul 2008 11:02:07 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Ashutosh Dutta References: <4843B64E.8040307@it.uc3m.es><48550B35.1010703@research.telcordia.com> <20080615164421.rtkgtgdu88wgg0gk@webcartero01.uc3m.es> <4855D812.3090403@research.telcordia.com> <48581C31.5080200@piuha.net> <48590EEC.6000107@research.telcordia.com> In-Reply-To: <48590EEC.6000107@research.telcordia.com> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f525eda5985483a843cfcbdbdf72dfbe96e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Cc: Wong Kuok Shoong , mext@ietf.org Subject: Re: [MEXT] RFC3775 update - Simultaneous Mobility 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Ashutosh, Ashutosh Dutta wrote: > >> Did I miss anything? Based on the above, I have a few questions: >> >> - If we need to specify something new action on this, should this action >> be triggered by (a) data traffic or (b) lack of response to RR packets? >> > > Ans> It should be triggered by lack of response to RR packets. > What if the mobile node used some perceived loss of data traffic as a trigger to retry the return routability signaling? > >> - Or is it simply wrong to attempt to do the signaling to the peer's >> care-of address, maybe we should require doing it via the home address >> instead? >> > > Ans> Yes, it is better to do it via the home address. Maybe it would be better to go by way of the home address only after signaling to the correspondent's care-of address fails once. I think it is agreed that this is a rare scenario, and so we should not penalize the overwhelming preponderance of cases when there is a simple remedy for errors in the rare case. > >> - Why is this issue specific to simultaneous movement? Wouldn't it >> happen also if the peer rebooted and got a new address, as well? >> > > Ans> I think this problem could be applied to other scenarios that you > have described as well. Also, it is a matter of timing. > In the case of reboots, there isn't much hope for continuity of real time communications. So I would expect all binding cache entries and so on to be lost and/or invalidated in this situation. So I do not think the same solution would be applicable. Regards, Charlie P. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 8 11:23:45 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C09B3A6893; Tue, 8 Jul 2008 11:23:45 -0700 (PDT) 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 4DF293A67B4 for ; Tue, 8 Jul 2008 11:23:44 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQeATBE0d0N2 for ; Tue, 8 Jul 2008 11:23:43 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.249]) by core3.amsl.com (Postfix) with ESMTP id 621D73A6839 for ; Tue, 8 Jul 2008 11:23:43 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so1261325and.122 for ; Tue, 08 Jul 2008 11:23:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=dq6xNufFShSFmwwS5OXwz8P488MOASOgLOkvwuKLEvM=; b=pjSCjCYtEMIQAk3uJU6BUPE5VjQbfioUs1MnJfhTGpAe7jlHhGgXTtAmSI5emuLbZ/ mk3C306UUMnsn3vXDxWij5QTPg9qHX7M2CJUsClC2WQkvbENBcm6thaHQmt2KbHCTfA+ Spw4CtkaRl5hLtyyvebB8vV784CDd015q33Zc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Y5SzpE1sxw9wIjo5d+LdQeaJhXkh41Oyna8nrFPSVUrhS4taGdAerpoJoVbx90rat6 ph3HFVTjT1CnQellSIcJ1q2/kbnxrVH3qgAj1D5/rwW3+ei2OuA/EcR7vnsbdnUN/NeQ 1AuRk0jHEss8IfIOp65Tf3yeB9p/izfHnHZ/A= Received: by 10.101.70.15 with SMTP id x15mr5386388ank.126.1215541430858; Tue, 08 Jul 2008 11:23:50 -0700 (PDT) Received: by 10.100.57.5 with HTTP; Tue, 8 Jul 2008 11:23:50 -0700 (PDT) Message-ID: Date: Tue, 8 Jul 2008 11:23:50 -0700 From: "fan zhao" To: mext@ietf.org In-Reply-To: <20080706174502.6A6393A68F3@core3.amsl.com> MIME-Version: 1.0 Content-Disposition: inline References: <20080706174502.6A6393A68F3@core3.amsl.com> Subject: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-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, We have submitted a draft on using IKEv2 to assign a Mobile Network Prefix to the Mobile Router. Comments, questions and suggestions are highly appreciated. Thanks. BR, Fan ---------- Forwarded message ---------- From: Date: 2008/7/6 Subject: I-D Action:draft-zhao-mext-mnp-ikev2-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IKEv2 based Mobile Network Prefix Assignment Author(s) : F. Zhao, et al. Filename : draft-zhao-mext-mnp-ikev2-00.txt Pages : 13 Date : 2008-07-06 This document proposes a mechanism for the Mobile Router to dynamically obtain the Mobile Network Prefix through IKEv2. The mechanisms to renew, release and update the allocated Mobile Network Prefixes are also described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zhao-mext-mnp-ikev2-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 8 11:27:46 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1732828C228; Tue, 8 Jul 2008 11:27:46 -0700 (PDT) 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 91F0A3A6931 for ; Tue, 8 Jul 2008 11:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grvOTV4b-sGb for ; Tue, 8 Jul 2008 11:27:43 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id F1DBE3A69D3 for ; Tue, 8 Jul 2008 11:27:42 -0700 (PDT) Received: from localhost ([127.0.0.1]:45536 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1KGHuX-0000Kl-0i; Tue, 08 Jul 2008 20:27:34 +0200 MIME-Version: 1.0 From: "mext" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software To: charliep@computer.org X-Trac-Project: mext Date: Tue, 08 Jul 2008 18:27:32 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://www3.tools.ietf.org/wg/mext/trac/ticket/9 Message-ID: <063.937d8196bafcef17c10b32862bdeef90@tools.ietf.org> X-Trac-Ticket-ID: 9 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, adutta@research.telcordia.com, mext@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: mext@ietf.org Subject: [MEXT] [mext] #9: Simultaneous Mobility [Ashutosh Dutta ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mext@ietf.org 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 Ticket #9: Simultaneous Mobility [Ashutosh Dutta ] Ashutosh Dutta I have not seen anywhere about the fall back option if the mobile is already operating in RO mode. Section 11.8 in RFC 3775 discusses about the re-transmission of Care-of Test Init messages and Binding Update that may go on indefinitely. "The retransmissions by the mobile node MUST use an exponential back- off process in which the timeout period is doubled upon each retransmission, until either the node receives a response or the timeout period reaches the value MAX_BINDACK_TIMEOUT. The mobile node MAY continue to send these messages at this slower rate indefinitely." However, if the retransmission goes on for indefinitely due to simultaneous mobility and there is no fall back option, it might affect the real-time communication because of the delayed RO. Thus, we will probably need to find some solution either by specifying it as part of RFC 3775bis or some other solution. It would be good to have some discussion on how to take care of this specific problem. Proposal: add the following text in section 11.8 after second paragraph in page 137. In certain scenarios such as in case of simultaneous mobility where both correspondent host and mobile host move at the same time, route optimization may not complete because of failed return routability procedures or failed binding updates. In such cases, the mobile node SHOULD fall back to resume normal bidirectional tunneling in order to avoid long delays in communication. The mobile node may run the bidirectional tunneling in parallel with the route optimization procedure until the RO procedure is successful. Bidirectional tunneling will start after RO procedure is not successful within a timeout period of MAX_RO_FAILURE (needs to be defined) and may continue to be the dafault option for that session if the RO procedure does not complete within the specified final timeout value of MAX_BINDACK_TIMEOUT. --------------------------------------------------------------------- Daniel Wong : ... Continuing to retry RO while falling back on reverse tunneling in parallel might be faster, but might have some new tricky protocol and timing issues that need to be carefully thought through. We would need to specify the correspondent host, home agent and mobile host behaviors carefully. If it is not done in parallel (say, it stops trying RO after one retry, and just falls back to reverse tunneling), then it may or may not have to use reverse tunneling for the rest of the session. maybe it could try RO again the next time it moves or something. --------------------------------------------------------------------- Hesham Soliman wrote: I think the text is not clear enough for specification language. Comments inline >> In certain scenarios such as in case of simultaneous mobility where >> both correspondent host and mobile host move at the same time, route >> optimization may not complete because of failed return routability >> procedures or failed binding updates. In such cases, the mobile SHOULD => ^^ node >> have the fall back option to resume bidirectional tunneling in order => Need to reword this, perhaps remove "have the" and "option" >> to avoid long delays in communication. Such an option could occur >> after a suitable timeout period. new/ => What's the timeout period? Do you retry RO in parallel? Or retry RO once before falling back to bidirectional tunnelling? There are several variations that can be done. I think falling back permanently to bidirectional tunnelling should be the last resort. Hesham --------------------------------------------------------------------- Jari Arkko : There are a couple of issues that interact: 1) Mobile nodes cannot send traffic from their new care-of address directly to a correspondent node before they have sent the RO BU to the it (Section 11.3.1). This cannot happen before they have executed the full return routability procedure. From this we can conclude that if there is any data traffic to the correspondent node, it will have to go through the correspondent node's home address and home agent. 2) What is the reaction of the correspondent node when it receives tunneled traffic? See Section 11.7.2. But return routability packets are exempt from this rule. 3) Whether the usual RO rules for the destination apply to RR packets or not; as far as I know there are no special rules for them. Did I miss anything? Based on the above, I have a few questions: - If we need to specify something new action on this, should this action be triggered by (a) data traffic or (b) lack of response to RR packets? - Or is it simply wrong to attempt to do the signaling to the peer's care-of address, maybe we should require doing it via the home address instead? - Why is this issue specific to simultaneous movement? Wouldn't it happen also if the peer rebooted and got a new address, as well? --------------------------------------------------------------------- Charles E. Perkins wrote: [>> == Jari Arkko ] [[BR]] [> Ans> == Ashutosh Dutta ] [[BR]] >> - If we need to specify something new action on this, >> should this action be triggered by (a) data traffic or >> (b) lack of response to RR packets? > Ans> It should be triggered by lack of response to RR packets. What if the mobile node used some perceived loss of data traffic as a trigger to retry the return routability signaling? >> - Or is it simply wrong to attempt to do the signaling >> to the peer's care-of address, maybe we should require >> doing it via the home address instead? > Ans> Yes, it is better to do it via the home address. Maybe it would be better to go by way of the home address only after signaling to the correspondent's care-of address fails once. I think it is agreed that this is a rare scenario, and so we should not penalize the overwhelming preponderance of cases when there is a simple remedy for errors in the rare case. >> - Why is this issue specific to simultaneous movement? Wouldn't it >> happen also if the peer rebooted and got a new address, as well? >> > > Ans> I think this problem could be applied to other scenarios > that you have described as well. Also, it is a matter of timing. In the case of reboots, there isn't much hope for continuity of real time communications. So I would expect all binding cache entries and so on to be lost and/or invalidated in this situation. So I do not think the same solution would be applicable. --------------------------------------------------------------------- Reference: http://www.ietf.org/internet-drafts/draft-wong-mext-simultaneous-ps-00.txt http://argreenhouse.com/IETF/draft-wong-mext-simultaneous-ps-00e.txt http://argreenhouse.com/IETF/wong-dutta-mext-ietf71.ppt ----------------------------------------+----------------------------------- Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: minor | Milestone: Component: draft-ietf-mext-rfc3775bis | Version: Severity: Active WG Document | Keywords: ----------------------------------------+----------------------------------- -- Ticket URL: mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 8 11:33:50 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E41593A6988; Tue, 8 Jul 2008 11:33:50 -0700 (PDT) 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 636A628C23B for ; Tue, 8 Jul 2008 11:33:50 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dn9itHTdFSw for ; Tue, 8 Jul 2008 11:33:46 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 5D9933A6801 for ; Tue, 8 Jul 2008 11:33:46 -0700 (PDT) Received: from [75.26.137.116] (helo=[10.166.255.10]) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KGI0f-0002AN-RV; Tue, 08 Jul 2008 14:33:54 -0400 Message-ID: <4873B30D.5010807@computer.org> Date: Tue, 08 Jul 2008 11:33:49 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Alexandru Petrescu References: <4843B64E.8040307@it.uc3m.es> <4843C104.3030706@gmail.com> <4844BFFE.9020005@piuha.net> <48450179.8020004@gmail.com> <484525C6.4030709@piuha.net> <484530B2.40501@gmail.com> In-Reply-To: <484530B2.40501@gmail.com> X-ELNK-Trace: 5a185a306015b1a28a306fc704168558239a348a220c2609cb5d6a15c013612ece8b8985bd55704a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Cc: mext@ietf.org Subject: Re: [MEXT] TC/flow label copying X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: charliep@computer.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello folks, It seems to me that this does not need to have an issue created in the tracker. But if I'm wrong, let me know and I'll collect the discussion and create a new ticket. Regards, Charlie P. Alexandru Petrescu wrote: > Jari Arkko wrote: >> Alex, >> >>> YEs, it was item 1: referenced spec (rfc2473) does have the words >>> about the possibility to copy the TC/Flow labels or insert >>> pre-configured values. However, at least one widespread >>> implementation doesn't implement the latter feature. >>> >>> I think if some implementers realize there may be some issue in >>> which qos is used with mip6 then we may need to clarify 3775. >>> Otherwise, if in practice this aspect was not identified by some >>> implementers then we may continue as now until the need becomes >>> apparent. >> I understand what you want to do. But if our situation is that >> implementors are ignoring IETF RFCs, its not going to be helped by >> publishing more RFCs. And including things in category 1 would be a >> never-ending task. Lets focus on the other categories where we can >> actually add some value. And hopefully because of you raising this >> issue now here on the list some implementors are now going back to >> fix their code :-) > > I agree on the value adding part and I somehow disagree suggesting stuff > to implementers. I am here to suggest back stuff to specifiers. > > I often notice differences between what's being specified and what's > getting widely implemented. Protocols don't make it to even a WG item > yet get deployed, and Proposed Standards protocols whose implementation > is still to happen - but I disgress. > > Let me stop commenting on this and come back to Chair's reminder on > 3775bis next steps. > > Alex > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 8 12:12:24 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B179628C267; Tue, 8 Jul 2008 12:12:24 -0700 (PDT) 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 B1AA528C217 for ; Tue, 8 Jul 2008 12:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbjshOIuAQzN for ; Tue, 8 Jul 2008 12:12:22 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id AB62C28C26D for ; Tue, 8 Jul 2008 12:12:09 -0700 (PDT) Received: from localhost ([127.0.0.1]:56053 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1KGIbi-0005eB-9u; Tue, 08 Jul 2008 21:12:11 +0200 MIME-Version: 1.0 From: "mext" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software To: charliep@computer.org X-Trac-Project: mext Date: Tue, 08 Jul 2008 19:12:10 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://www3.tools.ietf.org/wg/mext/trac/ticket/10 Message-ID: <063.656e681e1cbaab808ead0da6cff452c0@tools.ietf.org> X-Trac-Ticket-ID: 10 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, ryuji.wakikawa@gmail.com, mext@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: mext@ietf.org Subject: [MEXT] [mext] #10: The usage of "HA lifetime" [Ryuji Wakikawa ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mext@ietf.org 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 Ticket #10: The usage of "HA lifetime" [Ryuji Wakikawa ] Does the MN remove the HA entry used for current home registration, when the lifetime of that HA is expired? Or, does the MN start discovering the HA again and re-send the BU to the newly discovered HA? ... if MN manages the HA lifetime if the lifetime is available, we need some operational description when the lifetime is not available. RFC3775 clearly said that the HA entry MUST be deleted when its lifetime is expired. BUT the lifetime is not always available... :[[BR]] 1. George Tsirtsis [[BR]] No cache. MN does not record the HA information in its home agent list.[[BR]] 2. Vijay Devarapalli [[BR]] Local configuration matter. No modification is required to RFC3775.[[BR]] I personally agree with Vijay, but I think we need some clarification for this in the bis. We might need to define the default value for the locally configured HA lifetime.. ------------------------------------------------------------------------- Benjamin Lim wrote: Base on my understanding of 3775 sect 11.4.1, it does not specifically mention what MN will do to the list of HA address received in DHAAD reply. I think the confusion comes in because the section state one possible way to do home registration is to perform a sequential trial of each home agent address in the list (e.g. test 1st HA address --> fail --> test 2nd HA address --> fail --> until end of list or succeed.) So this implies that MN should store the list of HA address in order to do the above action. Whether this list is store temporary (just to find HA) or permenantly (info for MN in case HA goes down) is not mention. Maybe we should add some clarifying text for this matter? ----------------------------------------+----------------------------------- Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: minor | Milestone: Component: draft-ietf-mext-rfc3775bis | Version: Severity: Active WG Document | Keywords: ----------------------------------------+----------------------------------- -- Ticket URL: mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 8 12:20:10 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B729628C298; Tue, 8 Jul 2008 12:20:10 -0700 (PDT) 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 B143428C297 for ; Tue, 8 Jul 2008 12:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.300, 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 WFygul26kCKz for ; Tue, 8 Jul 2008 12:20:07 -0700 (PDT) Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id 8907628C265 for ; Tue, 8 Jul 2008 12:20:06 -0700 (PDT) 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 1KGIjS-0000ub-Ov; Tue, 08 Jul 2008 21:20:11 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: "fan zhao" References: <20080706174502.6A6393A68F3@core3.amsl.com> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:080708:fanzhao828@gmail.com::SSCDFgbVtZNEyUZf:000000000000000000000000000000000000000000pbH X-Hashcash: 1:20:080708:mext@ietf.org::YLAXPYXqTzNWcziJ:00006cei Date: Tue, 08 Jul 2008 21:19:43 +0200 In-Reply-To: (fan zhao's message of "Tue, 8 Jul 2008 11:23:50 -0700") Message-ID: <871w24ji9c.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-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="===============0215480779==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0215480779== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Transfer-Encoding: quoted-printable Hi, "fan zhao" writes: > We have submitted a draft on using IKEv2 to assign a Mobile Network > Prefix to the Mobile Router. Comments, questions and suggestions > are highly appreciated. > Thanks. Comments inline below. > 3. New Attribute Format > > We propose a new IKEv2 Configuration Attribute, called > MOBILE_NETWORK_PREFIX6. This attribute is carried in the IKEv2 > Configuration Payload and is used to convey an IPv6 Mobile Network > Prefix between the Mobile Router and the Home Agent. Figure 1 shows > the format of the MOBILE_NETWORK_PREFIX6 Configuration Attribute. > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |R| Attribute Type | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Prefix Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | IPv6 Mobile Network Prefix | > | | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Prefix Length | > +-+-+-+-+-+-+-+-+ > > Figure 1: The format of the MOBILE_NETWORK_PREFIX6 attribute > > Reserved (1 bit) > > This bit MUST be set to zero and MUST be ignored on receipt. > > Attribute Type (15 bits) > > A unique identifier for the MOBILE_NETWORK_PREFIX6 attribute > (to be determined by IANA). > > Length (2 octets) > > Length in octets of fields, including IPv6 Mobile Network > Prefix, Prefix Lifetime and Prefix Length. This can be 0 or > 21. > > Prefix Lifetime (4 octets) > > The length of time period during which the Mobile Network > Prefix remains valid. This should not be longer than the > lifetime of the IKE security association used when the Mobile > Network Prefix is assigned to the Mobile Router. I have no strong opinion on this specific topic but: Why limiting the prefix lifetime so that it is smaller than the SA lifetime? For me, the prefix and prefix lifetime are MIPv6 related information and SA lifetime are IKE-related information. > Prefix Length (1 octet) > > The length in bits of the Mobile Network Prefix specified in > the IPv6 Mobile Network Prefix field. > > When the Mobile Router requests a new Mobile Network Prefix, the > Mobile Router includes the MOBILE_NETWORK_PREFIX6 attribute in the > CFG_REQUEST payload and the value of the Length field is zero or the > IPv6 Mobile Network Prefix field is set as zero. The Mobile Router > may indicate the preferred Mobile Network Prefix in this attribute > and the Home Agent should return the indicated Mobile Network Prefix, > if available. The Mobile Router may explicitly request a lifetime by > specifying a value in the Prefix Lifetime field. Such value must not > be zero if the Mobile Router specifies a preferred Mobile Network > Prefix and is set as 2^32-1 if the Mobile Router wants the assigned > Mobile Network Prefix remains valid for the lifetime of the IKEv2 > security association. The Mobile Router may request multiple Mobile > Network Prefixes by using multiple MOBILE_NETWORK_PREFIX6 attributes > in one IKEv2 request message. This leads to a question: who decides how many prefixes will be configured and on which interfaces? The MR or the HA? How will the MR decide to assign prefix1 and prefix2 to interface A and interface B (or the reverse). This will end up being a local decision on the MR, AFAICT. You should probably explicitly states that the MR requests the number of prefixes it want BUT the final decision is let to the HA. The details of how the delegated prefixes are used on the MR are outside the scope of the specification. More generally, I don't think the solution will be really usable in a multiple interfaces/prefixes case (this is just an opinion). > If such request from the Mobile Router is valid, the Home Agent > includes the MOBILE_NETWORK_PREFIX6 attribute in the CFG_REPLY > payload and sends it back to the Mobile Router in one IKEv2 response > message. The attribute contains the allocated Mobile Network Prefix > and the lifetime authorized by the Home Agent. If the Mobile Router > requests multiple Mobile Network Prefixes in one IKEv2 request > message, the Home Agent should return multiple Mobile Network > Prefixes by using multiple MOBILE_NETWORK_PREFIX6 attributes in one > IKEv2 response message. > > There are different mechanisms for the Home Agent to allocate the > Mobile Network Prefix. For example, the Home Agent may manage a pool > of network prefixes by itself or communicate with a DHCP server > located in the home domain for this task. The details of such > mechanisms are out of scope of this document. If DHCP is used the DUID*, IA_PD, ... from the real peer (the MN) will not be available on the HA. In the end, DHCP will only be used to retrieve a bunch of anonymous prefixes which will then be sent to the IKE daemon on the MN. IMHO, this difference with an end-to-end DHCPv6 solution will matter in environments with multiple prefixes/interfaces. > 4. Mobile Network Prefix Assignment > > When the Mobile Router powers up, based on its configuration or some > mechanisms that are out of scope of this document, the Mobile Router > may choose hosted based mobility protocols, such as DSMIPv6/NEMO, to > set up network connectivity. Figure 2 shows the steps performed by > the Mobile Router during bootstrapping. > > MR Access network HA > | | | > | IP address configuration | | > |<-------------------------->| | > | | | > | Home Agent discovery | | > |<--------------------> | | > | | | > | IKE_SA_INIT{...} | > |<------------------------------------------------------->| > | | > | IKE_AUTH{CFG_REQUEST(HoA/HNP, MNP)} | > |-------------------------------------------------------->| > | | > | IKE_AUTH{CFG_REPLY(HoA/HNP, MNP)} | > |<--------------------------------------------------------| > | | > | BU/BA | > |<------------------------------------------------------->| > | | > > Figure 2: The procedure of the Mobile Network Prefix assignment via > IKEv2 > > o When attaching to a new link, the Mobile Router configures an IP > address on its interface that attaches to this link, for example, > by performing IP address stateless configuration using Router > Solicitation and Router Advertisement messages. > > o The Mobile Router discovers the IP address of the Home Agent, for > example, by using mechanisms defined in [6] [3] and [4]. > > o The Mobile Router starts to establish an IPSec security > association and firstly completes the IKE_SA_INIT exchange with > the discovered Home Agent. I still wonder how that negotiation is *triggered*. I will probably ask on ipsec@ietf at some point.=20 > o If the Mobile Router attaches to its home link (the details of the > home link detection mechanism is out of scope of this document), > the Mobile Router does not perform binding registration with the > Home Agent. Otherwise, the Mobile Router follows the procedure > specified in the NEMO Basic Support Protocol [1] to register the > binding between its Care-of address and its Home Address and the > Mobile Network Prefix with the Home Agent. Additionally, the > Mobile router may negotiate an IPSec child security association > with the Home Agent to protect the data traffic from itself and > the Mobile Network Nodes. Because the MR needs to register its network prefix with the HA, there is a need for the HA to be warned by IKE (or another mean) which prefixeshave been delegated (using IKE or another solution). If it is not defined, this cannot be implemented at all. > 5.2. Releasing the Mobile Network Prefix > > The Mobile Network Prefix release procedure can be initiated by > either the Mobile Router or the Home Agent. > > To release an allocated Mobile Network Prefix, the Mobile Router > initiates the IKEv2 Informational Exchange with the Home Agent. In > the CFG_REQUEST payload carried in the IKEv2 request message, the > Mobile Router includes the Mobile Network Prefix to be released and > the lifetime set as zero in the MOBILE_NETWORK_PREFIX6 attribute. As > > > > Zhao, et al. Expires January 5, 2009 [Page 8] > > Internet-Draft MNP Assigment July 2008 > > > a reply, the Home Agent returns a CFG_REPLY payload indicating the > released Mobile Network Prefix and the lifetime set as zero. > > To release an allocated Mobile Network Prefix, the Home Agent can > also initiate the IKEv2 Informational Exchange with the Mobile > Router. In the IKEv2 Informational Exchange message sent to the > Mobile Router, the Home Agent uses the CFG_REQUEST payload to carry > the MOBILE_NETWORK_PREFIX6 attribute that indicates the Mobile > Network Prefix to be released and the lifetime set as zero. When the > Mobile Router receives such IKEv2 request message, it removes the > corresponding configuration and replies with a CFG_REPLY payload to > carry the MOBILE_NETWORK_PREFIX6 attribute that indicates the > released Mobile Network Prefix and the lifetime set as zero. When > the Home Agent receives this responses, it recycles the released > Mobile Network Prefix. If that happens, what are the impacts WRT MIPv6: even if it is released at the IKE level, what is then done at MIPv6 level? How are both MIPv6 peers warned by their IKE couterparts that the prefix released has happened? > 5.3. Updating the Mobile Network Prefix > > The Mobile Network Prefix update procedure can be initiated by either > the Mobile Router or the Home Agent. > > One way to perform the Mobile Router initiated Mobile Network Prefix > update procedure is that the Home Agent returns a different Mobile > Network Prefix when the Mobile Router requests to renew a Mobile > Network Prefix. Another way is that the Mobile Router indicates the > release of the old Mobile Network Prefix and the request of a new > Mobile Network Prefix by using two separate MOBILE_NETWORK_PREFIX6 > attributes in one CFG_REQUEST payload. The Home Agent should return > a new Mobile Network Prefix and confirm the release of the old Mobile > Network Prefix by using two separate MOBILE_NETWORK_PREFIX6 > attributes in one CFG_REPLY payload. > > To perform the Home Agent initiated Prefix update procedure, the Home > Agent indicates the release of the old Mobile Network Prefix and the > assignment of a new Mobile Network Prefix by using two separate > MOBILE_NETWORK_PREFIX6 attributes in one CFG_REQUEST payload. In > this case, the Mobile Node should confirm the assignment of the new > Mobile Network Prefix and the release of the old Mobile Network > Prefix by using two separate MOBILE_NETWORK_PREFIX6 attributes in one > CFG_REPLY payload. Same questions as for previous section. Another comment: in this block, it is quite obvious that there are no more two separate entities (IKE and MIPv6), which obviously make the associated interface issues disappear: you use IKE exchange payload as if they were sent by the HA. They are not. They are sent by the IKE daemon on the HA. > The NEMO Basic Support protocol [1] requires that the Home Agent > check if a Mobile Network Prefix received in a Binding Update message > is authorized to be used. To do so, the Home Agent can associate the > mobile node identity used in the IKEv2 authentication process with > the Home Network Prefix allocated. Easy for the IKE daemon but how will the HA get the information when the MIPv6 MNP request will come. > In some deployment, the Homme Agent itself manages the allocation of > Mobile Network Prefixes, for example, from a locally managed prefix > pool. it is also possible that additional back-end servers are used > for Mobile Network Prefix assignment. For example, the Home Agent > can act as a DHCP Requesting Router and interact with a DHCP > Delegating Router. In the end, this is the HA which will decide (i.e. ack or nack prefixes in the MIPv6 message). > The security mechanism protecting the interaction > between the Home Agent and such back-end servers could be generic > security mechanisms, such as IPSec, or specific to the protocols used > in between, such as DHCP authentication option. Does not belong here, IMHO. > Once allocated, the > Mobile Network Prefix must not be assigned to a different Mobile > Router until such Mobile Network Prefix is returned to the Home > Agent. In you draft, this requires the prefix to be released both at IKEv2 and MIPv6 level, doesn't it? From=20a global standpoint, i think the solution could work for simple deployments with a single delegated prefix but it lacks the specific details of how MIPv6 and IKE need to work together on both sides. Note that my comments are only technical: I have no opinion WRT the use of IKEv2 to delegate prefixes to a MR. I (still) mainly wonder about the=20= =20 required interface between MIPv6 and IKE to do that ;-) Hope that helps, Cheers, a+ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIc73PAlWVfAR6UCYRAkxAAKCeHyUIQduOBwIp3o/Dxos7lcrUlgCfVkc5 pSEutosg1CPBHyT2Qcd6SwA= =9ooa -----END PGP SIGNATURE----- --=-=-=-- --===============0215480779== 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 --===============0215480779==-- From mext-bounces@ietf.org Tue Jul 8 12:26:33 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A20DD28C276; Tue, 8 Jul 2008 12:26:33 -0700 (PDT) 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 D65A63A6AEB for ; Tue, 8 Jul 2008 12:26:32 -0700 (PDT) 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 bhzNU8+d9UeP for ; Tue, 8 Jul 2008 12:26:31 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id DD61F3A6980 for ; Tue, 8 Jul 2008 12:25:46 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Jul 2008 15:25:53 -0400 Message-ID: In-Reply-To: <4872B8DD.8030104@computer.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [mext] #7: DSMIPv6 BU format and RFC 3775 [Tero Kauppinen ] Thread-Index: AcjglBEoLjDzbSkkQ3OAt23d8VcfuAAm4fXQ References: <063.eee1db399c39efaaf5a50a65984c5bdf@tools.ietf.org> <4869122D.5090701@computer.org> <48696974.2030503@wichorus.com> <4872B8DD.8030104@computer.org> From: "Vijay Devarapalli" To: Cc: mext@ietf.org Subject: Re: [MEXT] [mext] #7: DSMIPv6 BU format and RFC 3775 [Tero Kauppinen ] 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 > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@computer.org] > Sent: Monday, July 07, 2008 5:46 PM > To: Vijay Devarapalli > Cc: mext@ietf.org > Subject: Re: [MEXT] [mext] #7: DSMIPv6 BU format and RFC 3775 > [Tero Kauppinen ] > > > Hello Vijay, > > If this interpretation is removed, then what remains > is an error condition or, worse, unspecified behavior. > I think the simplification amounts a very small amount > of code reduction in one place followed by a potentially > much larger addition of code in another place. Plus > then we'll have to haggle over exactly just how to > resolve the error condition or whatever you want to > call it. Your concern seems to be about the home agent behavior when it receives a binding update with lifetime set to a non-zero value but with care-of address the same as the home address. IMO, this is a mal-formed binding update. There is no care-of address information in the binding update. The home agent could just silently drop it. Home agent implementations typically deal with mal-formed binding updates anyway. > In this case, I don't see that anything is broken > enough to warrant making the suggested change. > On the other hand, since I am all in favor of actual > simplifications, I'm happy to take fully considered > arguments (and text). IMO, it does simplify the de-registration process. For the text change, we just need to delete the sentences that say when the care-of address is equal to home address, the home agent should treat this as a de-registration BU. Vijay > > Regards, > Charlie P. > > > Vijay Devarapalli wrote: > > Hi Charlie, > > > > I think the text in RFC 3775 needs to be fixed. RFC 3775 > assumes that a > > binding update is sent with the home address option and > with the care-of > > address stored either in the source address in the IPv6 > header or in > > alternate care-of address option. So it specifies that if > the care-of > > address matches the home address in the home address > option, it is safe > > for the home agent to assume that the binding update was > sent from the > > home link and can be treated as a de-registration BU. > > > > In practice, I have never seen a Binding Update, where the > lifetime is > > non-zero and the care-of address matches the home address, > from a mobile > > node implementation. Only the TAHI test suite sends such a binding > > update, since they have to test conformance to RFC 3775. :) If the > > mobile node detects that its care-of address matches the > home address, > > it knows it has returned home and sets the lifetime to zero in the > > binding update it sends to the home agent. > > > > I would suggest removing it and treat only the binding update with > > lifetime set to zero as a de-registration. It would help in > simplifying > > the de-registration procedure a little bit. > > > > Vijay > > > > > > Charles E. Perkins wrote: > >> > >> Hello folks, > >> > >> So far, I did not find a persuasive reason to make > >> changes to RFC 3775 related to this issue with > >> DSMIPv6. Unless someone can suggest text that might > >> be needed, I would recommend to close this issue > >> without modification to rfc3775bis. > >> > >> Regards, > >> Charlie P. > >> > >> > >> > >> mext wrote: > >>> Ticket #7: DSMIPv6 BU format and RFC 3775 [Tero Kauppinen > >>> ] > >>> > >>> DSMIPv6 BU format and RFC 3775 > >>> Tero Kauppinen > >>> > >>> While reading the current version of DSMIPv6 > >>> (draft-ietf-mip6-nemo-v4traversal-06) and I came across with one > >>> sentence which strikes me as odd. > >>> > >>> "4.2. NAT detection and traversal > >>> > >>> NAT detection is done when the initial binding update > message is > >>> sent > >>> from the mobile node to the home agent. When located > in an IPv4-only > >>> foreign link, the mobile node sends the binding update message > >>> encapsulated in UDP and IPv4. The source address of > the IPv6 packet > >>> is the mobile node's IPv6 home address. The > destination address is > >>> the IPv6 address of the home agent. The IPv4 header > contains the > >>> IPv4 > >>> care-of address in the source address field and the > IPv4 address of > >>> the home agent in the destination address field. > >>> > >>> When the home agent receives the encapsulated binding > update it > >>> compares the IPv4 address of the source address field > in the IPv4 > >>> header with the IPv4 address in the source address of the IPv6 > >>> header." > >>> > >>> If the IPv6 header contains the mobile node's IPv6 home > address, how > >>> can > >>> it ever match with the IPv4 address of the source > address field in the > >>> IPv4 header? Furthermore, RFC3775 in 9.5.1. says "If > the Lifetime > >>> specified in the Binding Update is zero or the specified care-of > >>> address > >>> matches the home address for the binding, then this is a > request to > >>> delete the cached binding for the home address." > >>> > >>> So, > >>> > >>> (1) Should the IPv6 header actually contain an IPv4 mapped IPv6 > >>> address? > >>> > >>> Or > >>> > >>> (2) Should the IPv4 address of the source address field > in the IPv4 > >>> header be compared with the address specified in the > packet's IPv4 CoA > >>> option? > >>> > >>> > --------------------------------------------------------------------- > >>> > >>> George Tsirtsis > >>> > >>> I would go with (2), as I think this was the intention (i.e., I > >>> consider this a typo). > >>> > >>> It is not, however, clear to me what the relevance of > the quoted text > >>> from 3775 is. > >>> Whether (1) or (2) is used it should not result in the > condition of > >>> CoA==HoA in the BU. > >>> > >>> > --------------------------------------------------------------------- > >>> > >>> Pascal Thubert > >>> > >>> I favor 1) and the text seems to be a leftover from your > original draft > >>> which worked that way. > >>> But I remember that the question was cut against it by the chairs > >>> because there was no proper consensus either way. > >>> > >>> Now I really hate the idea of a BU process that would > have to figure if > >>> a BU is a registration or deregistration just because > the packet was > >>> received over an interface that is an IPv4 tunnel as > opposed to the > >>> Home > >>> Link. That seems plain wrong. I have a tendency to think > that what's > >>> wrong is really RFC 3775 (lifetime 0 should be the way > to deregister) > >>> but unless we revise it, I'd suggest we keep consistent with that > >>> foundation RFC. If we REALLY do not want a mapped > address as source, > >>> then maybe we could use the UNSPECIFIED address instead? > >>> > >>> > --------------------------------------------------------------------- > >>> > >>> Vijay Devarapalli : > >>> > >>> > "4.2. NAT detection and traversal > >>> > > >>> > NAT detection is done when the initial binding > update message > >>> is sent > >>> > from the mobile node to the home agent. When located in an > >>> IPv4-only > >>> > foreign link, the mobile node sends the binding > update message > >>> > encapsulated in UDP and IPv4. The source address of > the IPv6 > >>> packet > >>> > is the mobile node's IPv6 home address. The > destination address is > >>> > the IPv6 address of the home agent. The IPv4 header > contains > >>> the IPv4 > >>> > care-of address in the source address field and the IPv4 > >>> address of > >>> > the home agent in the destination address field. > >>> > > >>> > When the home agent receives the encapsulated > binding update it > >>> > compares the IPv4 address of the source address > field in the IPv4 > >>> > header with the IPv4 address in the source address > of the IPv6 > >>> > header." > >>> > >>> This text is old. The home agent needs to compare it > with the IPv4 > >>> address in the IPv4 CoA option. So this paragraph should actually > >>> say > >>> > >>> When the home agent receives the encapsulated binding > update it > >>> compares the IPv4 address of the source address field > in the IPv4 > >>> header with the IPv4 address in the IPv4 care-of > address option > >>> in the Binding Update. > >>> > >>> > If the IPv6 header contains the mobile node's IPv6 > home address, > >>> how can > >>> > it ever match with the IPv4 address of the source > address field in > >>> the > >>> > IPv4 header? Furthermore, RFC3775 in 9.5.1. says "If > the Lifetime > >>> > specified in the Binding Update is zero or the > specified care-of > >>> address > >>> > matches the home address for the binding, then this is > a request to > >>> > delete the cached binding for the home address." > >>> > >>> This text needs to be clarified in RFC 3775. Regarding the actual > >>> "violation", I don't think there is a conflict. The DS-MIPv6 > >>> binding update has an IPv4 CoA option (similar to the alt CoA > >>> option) which when present dictates a different behavior on the > >>> home agent that implements DS-MIPv6 extensions. It is more like > >>> DS-MIPv6 updates MIPv6 home agent behavior when the IPv4 CoA > >>> option is present. > >>> > >>> > >>> > --------------------------------------------------------------------- > >>> > >>> Basavaraj Patil > >>> > >>> Option 2 is what I believe the intent has been. Option 2 > IMO is a > >>> better > >>> choice even though it does diverge from RFC3775 design. > But given that > >>> this > >>> I-D is extending the base MIP6 RFC, I believe it is okay > to proceed > >>> with > >>> option 2. > >>> > >>> > >>> > --------------------------------------------------------------------- > >>> > >>> Hesham Soliman > >>> > >>> => The relevance of the quote from 3775 is that we're > putting the > >>> HoA in > >>> the > >>> src address of a normal registration. The text says that the > >>> receiver of a > >>> BU with the HoA in the src address field would assume it's a > >>> de-registration, which is obviously not what we want. > Hence my question > >>> about violating 3775. > >>> > >>> > >>> > -----------------------------------+-------------------------- > -------------- > >>> > >>> Reporter: charliep@computer.org | Owner: > charliep@computer.org > >>> Type: enhancement | Status: > >>> new Priority: minor | > >>> Milestone: Component: RFC3775 > changes > >>> | Version: Severity: Active WG > >>> Document | Keywords: > >>> > -----------------------------------+-------------------------- > -------------- > >>> > >> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 8 12:52:49 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52E833A6AEE; Tue, 8 Jul 2008 12:52:49 -0700 (PDT) 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 AC1F93A6962 for ; Tue, 8 Jul 2008 12:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 xC6OmRsgaa53 for ; Tue, 8 Jul 2008 12:52:46 -0700 (PDT) Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id 9FF153A67D4 for ; Tue, 8 Jul 2008 12:52:46 -0700 (PDT) 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 1KGJEz-0000vV-1I; Tue, 08 Jul 2008 21:52:45 +0200 X-Hashcash: 1:20:080708:shinta.sugimoto@ericsson.com::WzLz/KvLrxEMHgEZ:000000000000000000000000000000000Gz5L X-Hashcash: 1:20:080708:denghui02@gmail.com::n3Ac0WhtKh0kFLl0:0000000000000000000000000000000000000000000vgy From: arno@natisbad.org (Arnaud Ebalard) To: mext@ietf.org References: <063.7622031672aced0787b70d358cb06abb@tools.ietf.org> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:080708:charliep@computer.org::eSQ5X0Hk3s1yDRYp:00000000000000000000000000000000000000000s9s X-Hashcash: 1:20:080708:mext@ietf.org::LauC8tpzTDt4g/yu:00002Y1u X-Hashcash: 1:20:080708:julien.ietf@laposte.net::sQ+hWk7xib8HyTsY:000000000000000000000000000000000000005+eV Date: Tue, 08 Jul 2008 21:51:42 +0200 Message-ID: <87iqvgi27l.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: charliep@computer.org, Shinta Sugimoto , julien.IETF@laposte.net Subject: Re: [MEXT] "[mext] #8: Application using the care-of address " 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="===============2074651560==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============2074651560== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Transfer-Encoding: quoted-printable Hi, "mext" writes: > [editorial note by Charles E. Perkins]: > Following this, there was a discussion about how to enable > an IKE daemon to use the care-of address. Since that seems > out of scope for rfc3775bis, I have not included it as part > the discussion for this issue. Ack. I think I started the discussion with Julien on that point, because of the following from section 3 in RFC 5014: Another example is the IKE application, which requires a care-of address as its source address for the initial security association pair with a Home Agent [RFC3775] while the mobile node boots up at the foreign network and wants to do the key exchange before a successful home-registration.=20 I have no specific problems with the changes proposed by Julien but I don't like the idea of having a pointer in RFC 3775 leading developers looking how to use the CoA for IKE implementation with MIPv6 to the previous block of text. Simply because there are open issues (to say the least): I am still waiting to be proven otherwise, but got no response to the last mail of previous thread: Archived-At: As far as I can tell, the only *working* solution (i.e. *implemented*, i.e. not just *expected* to work after paper review) is derived from=20 draft-sugimoto-mip6-pfkey-migrate-04.txt. I'll post more on that before the end of July. Cheers, a+ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIc8VwAlWVfAR6UCYRAgR0AJ9XB46Lp28ZRUNO8SdqYsU2l3jmYQCeOReW g9Rd7Z23CmTvfe3OZKG3INA= =pUC1 -----END PGP SIGNATURE----- --=-=-=-- --===============2074651560== 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 --===============2074651560==-- From mext-bounces@ietf.org Tue Jul 8 13:00:56 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B2F83A67EC; Tue, 8 Jul 2008 13:00:56 -0700 (PDT) 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 408293A695F for ; Tue, 8 Jul 2008 13:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 dbnxLVdex9+P for ; Tue, 8 Jul 2008 13:00:53 -0700 (PDT) Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id 4EE9B3A6780 for ; Tue, 8 Jul 2008 13:00:48 -0700 (PDT) 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 1KGJMr-0000w6-2C; Tue, 08 Jul 2008 22:00:53 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: "Charles E. Perkins" References: <200806050918.05372.julien.IETF@laposte.net> <200806061144.23200.julien.IETF@laposte.net> <20080606100743.GA12803@sd-5945.dedibox.fr> <200806061349.32192.julien.IETF@laposte.net> <878wxgungh.fsf@natisbad.org> <4873A45A.7020106@earthlink.net> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:080708:julien.ietf@laposte.net::SxNVZeSjGk5KKPKh:000000000000000000000000000000000000000NEv X-Hashcash: 1:20:080708:mext@ietf.org::VnTRnRxvCxSZyclD:00005SJr X-Hashcash: 1:20:080708:charles.perkins@earthlink.net::ha1C3Qc/PK3QFsGO:00000000000000000000000000000000KPAZ Date: Tue, 08 Jul 2008 22:00:25 +0200 In-Reply-To: <4873A45A.7020106@earthlink.net> (Charles E. Perkins's message of "Tue, 08 Jul 2008 10:31:06 -0700") Message-ID: <87d4loi1t2.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] [rfc3775] Application using the care-of address 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="===============2050262586==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============2050262586== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Hi, "Charles E. Perkins" writes: > It seems to me that socket handling by IKE versus > availability of the Care-of Address from MIPv6 is > out of scope for rfc3775bis. I've created a new issue > for Julien's original proposed (informational) update. > Up until now, I haven't included the text for the IKE > socket handling question as part of the background > discussion for the new issue, but I can always go back > and add it later if need be. Sorry for replying to your other email, that one would probably have been more appropriate. Thanks for your work, Cheers, a+ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIc8dZAlWVfAR6UCYRArwnAJ9DElpPXJtFmVyrwQ8yYLma7pq+uACggzMR WLmiFnnkj7AWbQvIgxn+wKQ= =aKMg -----END PGP SIGNATURE----- --=-=-=-- --===============2050262586== 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 --===============2050262586==-- From mext-bounces@ietf.org Tue Jul 8 15:00:23 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C65673A695F; Tue, 8 Jul 2008 15:00:23 -0700 (PDT) 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 E0FC73A695F for ; Tue, 8 Jul 2008 15:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7+DuTKFdAuk for ; Tue, 8 Jul 2008 15:00:21 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 3C5A13A684B for ; Tue, 8 Jul 2008 15:00:21 -0700 (PDT) Received: from localhost ([127.0.0.1]:44400 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1KGLER-0003en-8k; Wed, 09 Jul 2008 00:00:19 +0200 MIME-Version: 1.0 From: "mext" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software To: charliep@computer.org X-Trac-Project: mext Date: Tue, 08 Jul 2008 22:00:19 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://www3.tools.ietf.org/wg/mext/trac/ticket/11 Message-ID: <063.5678bdd45e5096c3dfbccfcf1ef43af5@tools.ietf.org> X-Trac-Ticket-ID: 11 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, vijay@wichorus.com, mext@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: mext@ietf.org Subject: [MEXT] [mext] #11: De-registration when returning home [Vijay Devarapalli ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mext@ietf.org 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 Ticket #11: De-registration when returning home [Vijay Devarapalli ] RFC 3775 currently says the mobile node "SHOULD" send a de-registration BU when it returns home. This is kind of odd because, without the de-registration BU, the home agent continues defending the mobile node's home address and keeps tunneling the packets to the last known care-of address. The BCE must be deleted for the mobile node to be able to send/ receive packets from the home link. I am not sure why we went with "SHOULD" in the first place. From the interop events I have attended, I know that all mobile node implementations send a de-registration BU as soon as they detect they are on the home link. The use of "SHOULD" instead of "MUST" caused some confusion during the PMIPv6-MIPv6 interactions discussion. So we need to fix this. Here is the proposed change. OLD: A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.1), when the mobile node detects that its home subnet prefix is again on-link. The mobile node SHOULD then send a Binding Update to its home agent, to instruct its home agent to no longer intercept or tunnel packets for it. NEW: A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.1), when the mobile node detects that its home subnet prefix is again on-link. The mobile node MUST then send a Binding Update to its home agent, to instruct its home agent to no longer intercept or tunnel packets for it. --------------------------------------------------------------------- Gerardo Giaretta This was discussed also in Philadelphia and in general I agree a MUST is more appropriate. However we should make clear that the MN MUST send the deregistration BU only when it wants the HA to stop intercepting packets and forwarding them to the CoA. Let's assume for example the MN has two active interfaces, it is using interface with CoA1 registered at the HA. Then it switches interface2 on and detects interfaces2 is connected to the home link. This should not immediately trigger the MN to send the BU, unless the MN wants all traffic destined to the HoA routed to interface2 (the MN may still want to have the traffic destined to interface1). --------------------------------------------------------------------- Sri Gundavelli We discussed this issue in the last meeting and I thought the conclusion there was, if the mobile node attaches to the home link and *if* it decides to use the home address i.e., defend the home address on the home link, then it MUST send a dereg BU. This will avoid the Proxy ND contention. Note that it is possible the MN is attached to the home, but may choose to send the dereg bit later. So, the wording has to reflect this aspect. --------------------------------------------------------------------- Ahmad Muhanna IMO, the best for RFC3775 and RFC3775bis is to maintain "SHOULD" because my understanding of "SHOULD" is that the MN MUST send de-registration UNLESS there is a condition that makes it impossible on the MN to send de-registration, e.g. MN lost coverage, or lost power, etc. The usefulness of SHOULD in base RFC3775 that it can be become "MUST" in a specific scenario where that is possibly described in a different doc, like the case that Gerardo mentioned. IMO, that "MUST" should be captured in the Multi-CoA doc not in RFC3775bis. On the other hand, the latest change defeats the original purpose of RFC3775, because RFC3775 mandates on the MN to send de-registration, however, the last change, proposed here, makes it based on the MN discretion and that is very dangerous. I disagree with this change and I favor maintaining "SHOULD" in the base document and if "MUST" is needed in a specific scenarios let us capture that in the respected document. --------------------------------------------------------------------- George Tsirtsis ... it does not make sense to require that the MN sends a dereg BU when it connects to its home link. Instead this is a MIPv6 layer decision that has nothing to do with whether the MN has connection only to the home link or to one or more other links at the same time. --------------------------------------------------------------------- Sri Gundavelli ...I'm ok leaving the initial SHOULD wording, however, the technical issue that I see and as I said before is that we should clearly document and state that the MN MUST send a dereg message before it can start using its hoa on the home link and that will avoid any ND contentions between the HA and the MN. This is not implicit and cannot be left to the reader and so must be documented. Generally, it can be stated the MN must send a dereg. But, the issue related to power down ...etc. ..etc are probably valid and there may be valid reasons as why MN may not be able to send a dereg message. So, we can always qualify that requirement and state that the MN must send a dereg before it can start using its home address on the home link and also leave the option for it not to send any dereg message in some situations and when it has no need to use its HoA. Bottom line: - Leave the SHOULD as a strong recommendation for the MN to send dereg, as it is currently written. - Add additional text and state the MN MUST send a dereg before it can use its hoa on the home link. --------------------------------------------------------------------- George Tsirtsis Sri/Ben, IMHO combining SHOULDs/MAYs and MUSTs with "if" statements does not result in good specs. For example, the MUST in Ben's proposal is to be followed only if the MN *intends* to get its traffic to flow on the home link and, not following the MUST does not really break the protocol. In any case, *intentions* are not easy to evaluate during interoperability testing. So, maybe we should simply try to clarify the SHOULD. Here is a proposal: OLD Text: A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.1), when the mobile node detects that its home subnet prefix is again on-link. The mobile node SHOULD then send a Binding Update to its home agent, to instruct its home agent to no longer intercept or tunnel packets for it. NEW Text: A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.1), when the mobile node detects that its home subnet prefix is again on-link. The mobile node SHOULD then send a Binding Update to its home agent, to instruct its home agent to no longer intercept or tunnel packets for it. Until the mobile node sends a de-registration Binding Update, it will not be able to send and receive packets using its home address from the home link. The home agent will continue to intercept all packets sent to the mobile's home address and tunnel to the previously registered care-of address. ----------------------------------------+----------------------------------- Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: minor | Milestone: Component: draft-ietf-mext-rfc3775bis | Version: Severity: Active WG Document | Keywords: ----------------------------------------+----------------------------------- -- Ticket URL: mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 8 15:12:15 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94E863A6B0C; Tue, 8 Jul 2008 15:12:15 -0700 (PDT) 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 234CF3A6B0C for ; Tue, 8 Jul 2008 15:12:14 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAEcZHPqKGFL for ; Tue, 8 Jul 2008 15:12:12 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id A95303A698F for ; Tue, 8 Jul 2008 15:12:12 -0700 (PDT) Received: from [75.26.137.116] (helo=[10.166.255.10]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KGLQ6-0008Qn-CW for mext@ietf.org; Tue, 08 Jul 2008 18:12:22 -0400 Message-ID: <4873E645.2000708@computer.org> Date: Tue, 08 Jul 2008 15:12:21 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: mext@ietf.org References: <063.5678bdd45e5096c3dfbccfcf1ef43af5@tools.ietf.org> In-Reply-To: <063.5678bdd45e5096c3dfbccfcf1ef43af5@tools.ietf.org> X-ELNK-Trace: 5a185a306015b1a28a306fc704168558239a348a220c2609f191936c59161a5f16a07a29831e5820a2d4e88014a4647c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Subject: Re: [MEXT] [mext] #11: De-registration when returning home [Vijay Devarapalli ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: charliep@computer.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello folks, As noted, I have posted issue #11 to the [mext] issue tracker. There were well over 50 messages on this topic, and I plowed through every single one of them. I tried to extract the major thoughts and collect them for the issue background, but if I managed to miss something please let me know. I'm satisfied that the proposal as shown after the other discussion in the issue description is a reasonable consensus resolution for the issue, but I'll wait to see if there is any dissent first. Regards, Charlie P. mext wrote: > Ticket #11: De-registration when returning home [Vijay Devarapalli > ] > > RFC 3775 currently says the mobile node "SHOULD" send a de-registration > BU when it returns home. This is kind of odd because, without the > de-registration BU, the home agent continues defending the mobile node's > home address and keeps tunneling the packets to the last known care-of > address. The BCE must be deleted for the mobile node to be able to send/ > receive packets from the home link. I am not sure why we went with > "SHOULD" in the first place. > > From the interop events I have attended, I know that all mobile node > implementations send a de-registration BU as soon as they detect they > are on the home link. The use of "SHOULD" instead of "MUST" caused some > confusion during the PMIPv6-MIPv6 interactions discussion. So we need to > fix this. > > Here is the proposed change. > > OLD: > > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > The mobile node SHOULD then send a Binding Update to its home agent, > to instruct its home agent to no longer intercept or tunnel packets > for it. > > NEW: > > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > The mobile node MUST then send a Binding Update to its home agent, > to instruct its home agent to no longer intercept or tunnel packets > for it. > > > --------------------------------------------------------------------- > > Gerardo Giaretta > > This was discussed also in Philadelphia and in general I agree a > MUST is more appropriate. > > However we should make clear that the MN MUST send the deregistration > BU only when it wants the HA to stop intercepting packets and > forwarding them to the CoA. > > Let's assume for example the MN has two active interfaces, it is using > interface with CoA1 registered at the HA. Then it switches interface2 > on and detects interfaces2 is connected to the home link. This should > not immediately trigger the MN to send the BU, unless the MN wants all > traffic destined to the HoA routed to interface2 (the MN may still > want to have the traffic destined to interface1). > > --------------------------------------------------------------------- > > Sri Gundavelli > > We discussed this issue in the last meeting and I thought > the conclusion there was, if the mobile node attaches to > the home link and *if* it decides to use the home address > i.e., defend the home address on the home link, then it > MUST send a dereg BU. This will avoid the Proxy ND contention. > Note that it is possible the MN is attached to the home, > but may choose to send the dereg bit later. So, the wording > has to reflect this aspect. > > --------------------------------------------------------------------- > > Ahmad Muhanna > > IMO, the best for RFC3775 and RFC3775bis is to maintain "SHOULD" because > my understanding of "SHOULD" is that the MN MUST send de-registration > UNLESS there is a condition that makes it impossible on the MN to send > de-registration, e.g. MN lost coverage, or lost power, etc. > > The usefulness of SHOULD in base RFC3775 that it can be become "MUST" > in a specific scenario where that is possibly described in a different > doc, like the case that Gerardo mentioned. IMO, that "MUST" should be > captured in the Multi-CoA doc not in RFC3775bis. > > On the other hand, the latest change defeats the original purpose of > RFC3775, because RFC3775 mandates on the MN to send de-registration, > however, the last change, proposed here, makes it based on the MN > discretion and that is very dangerous. > > I disagree with this change and I favor maintaining "SHOULD" in > the base document and if "MUST" is needed in a specific scenarios > let us capture that in the respected document. > > --------------------------------------------------------------------- > > George Tsirtsis > > ... it does not make sense to require > that the MN sends a dereg BU when it connects to its home link. > Instead this is a MIPv6 layer decision that has nothing to do with > whether the MN has connection only to the home link or to one or more > other links at the same time. > > --------------------------------------------------------------------- > > Sri Gundavelli > > ...I'm ok leaving the initial SHOULD > wording, however, the technical issue that I see and as I > said before is that we should clearly document and state > that the MN MUST send a dereg message before it can start > using its hoa on the home link and that will avoid any ND > contentions between the HA and the MN. This is not implicit > and cannot be left to the reader and so must be documented. > > Generally, it can be stated the MN must send a dereg. But, > the issue related to power down ...etc. ..etc are probably > valid and there may be valid reasons as why MN may not be > able to send a dereg message. So, we can always qualify > that requirement and state that the MN must send a dereg > before it can start using its home address on the home link > and also leave the option for it not to send any dereg > message in some situations and when it has no need to use > its HoA. > > Bottom line: > > - Leave the SHOULD as a strong recommendation for the MN > to send dereg, as it is currently written. > > - Add additional text and state the MN MUST send a dereg > before it can use its hoa on the home link. > > --------------------------------------------------------------------- > > George Tsirtsis > > Sri/Ben, IMHO combining SHOULDs/MAYs and MUSTs with "if" statements > does not result in good specs. For example, the MUST in Ben's proposal > is to be followed only if the MN *intends* to get its traffic to flow > on the home link and, not following the MUST does not really break the > protocol. In any case, *intentions* are not easy to evaluate during > interoperability testing. So, maybe we should simply try to clarify > the SHOULD. Here is a proposal: > > OLD Text: > > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > The mobile node SHOULD then send a Binding Update to its home agent, > to instruct its home agent to no longer intercept or tunnel packets > for it. > > NEW Text: > > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > The mobile node SHOULD then send a Binding Update to its home agent, > to instruct its home agent to no longer intercept or tunnel packets > for it. Until the mobile node sends a de-registration Binding Update, > it will not be able to send and receive packets using its home > address from the home link. The home agent will continue to intercept > all packets sent to the mobile's home address and tunnel to the > previously registered care-of address. > > > ----------------------------------------+----------------------------------- > Reporter: charliep@computer.org | Owner: charliep@computer.org > Type: defect | Status: new > Priority: minor | Milestone: > Component: draft-ietf-mext-rfc3775bis | Version: > Severity: Active WG Document | Keywords: > ----------------------------------------+----------------------------------- _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 8 15:39:12 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E32CD3A6B11; Tue, 8 Jul 2008 15:39:11 -0700 (PDT) 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 2A1403A6B11 for ; Tue, 8 Jul 2008 15:39:11 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sZ8v26EGNpI for ; Tue, 8 Jul 2008 15:39:10 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 6BC793A6AF4 for ; Tue, 8 Jul 2008 15:39:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Hqk8h5CFqSizbFQ8+74OsoHLrarSUHb052i+5lx8D4E/MMjlK7aenRjTY6WJfh6W; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [75.26.137.116] (helo=[10.166.255.10]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1KGLqC-00072x-Ju; Tue, 08 Jul 2008 18:39:20 -0400 Message-ID: <4873EC97.6000800@earthlink.net> Date: Tue, 08 Jul 2008 15:39:19 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Ahmad Muhanna X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f523a8857b7dee7c4f0dfa318925ce4efb8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Cc: mext@ietf.org Subject: [MEXT] Mandated behaviors, "whenever possible" 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Ahmad, In one email adding to the discussion about Issue #11 you wrote: > One final note: Any where we mandate that the MN "MUST" send > de-registration, we probably need to have a clause that > "whenever it is > possible for the MN to do so" i.e. if the MN moves to an > area without > coverage, then the MN wont comply anyway. Generally, any physical network medium can lose packets under various circumstances. It would be wrong, I'm sure, to append the "whenever" clause as you suggested to all protocol mandates for all protocols that need to be obeyed by wireless devices. So I'd rather not have to append that clause anywhere, since it is really already implicit. Just to be silly, we could rephrase it as "whenever the laws of physics permit", or "whenever the cost is not prohibitive", or "whenever there is no resulting danger of atomic warfare", or , ... Regards, Charlie P. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 8 18:04:19 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B957228C216; Tue, 8 Jul 2008 18:04:19 -0700 (PDT) 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 AB36628C216 for ; Tue, 8 Jul 2008 18:04:18 -0700 (PDT) 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 xYhS7U0vyJnr for ; Tue, 8 Jul 2008 18:04:17 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id E3E2628C1E3 for ; Tue, 8 Jul 2008 18:04:16 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Jul 2008 21:04:25 -0400 Message-ID: In-Reply-To: <4873E645.2000708@computer.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [mext] #11: De-registration when returning home [Vijay Devarapalli ] Thread-Index: AcjhR7gv2RIhnWx6SnC8ZZPUcCDGjQACuKaA References: <063.5678bdd45e5096c3dfbccfcf1ef43af5@tools.ietf.org> <4873E645.2000708@computer.org> From: "Vijay Devarapalli" To: , Subject: Re: [MEXT] [mext] #11: De-registration when returning home [Vijay Devarapalli ] 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 Charlie, I am going to try addressing this issue once more. First lets look at the requirements. 1. Allow a mobile node with one home address and one care-of address to be able to send/receive packets when it attaches to the home link 2. Allow a mobile node with one home address and multiple care-of addresses to decide whether it wants to send/receive packets from the home or the visited link. IMO, RFC 3775 addresses the first case. The second one is addressed by the multiple CoA draft. The multiple CoA draft infact describes the mobile node and the home agent behavior for three cases when the mobile node is simultaneously attached to the home and visited links. See section 5.6 of draft-ietf-monami6-multiplecoa-08.txt. It allows the mobile node to use the home link, the visited link or both and indicate the same to the home agent. So here is my proposal for the text. OLD: A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.1), when the mobile node detects that its home subnet prefix is again on-link. The mobile node SHOULD then send a Binding Update to its home agent, to instruct its home agent to no longer intercept or tunnel packets for it. NEW: A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.1), when the mobile node detects that its home subnet prefix is again on-link. In case the mobile node has only one care-of address associated with the home address, it MUST send a Binding Update to its home agent, to instruct its home agent to no longer intercept or tunnel packets for it. In case the mobile node has more than one interface and can bind more than one care-of address to the home address, the mobile MAY send a Binding Update to its home agent, to instruct its home agent to no longer intercept or tunnel packets for it. For more information on the mobile node returning home procedure when there are multiple care-of addresses, see [MCOA]. In the Informative references add, [MCOA] Wakikawa, S., Devarapalli, V., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", Work in Progress, May 2008. Hope this acceptable to all. Vijay > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Charles E. Perkins > Sent: Tuesday, July 08, 2008 3:12 PM > To: mext@ietf.org > Subject: Re: [MEXT] [mext] #11: De-registration when > returning home [Vijay Devarapalli ] > > > Hello folks, > > As noted, I have posted issue #11 to the [mext] issue tracker. > > There were well over 50 messages on this topic, and I plowed > through every single one of them. I tried to extract the major > thoughts and collect them for the issue background, but if I > managed to miss something please let me know. > > I'm satisfied that the proposal as shown after the other > discussion in the issue description is a reasonable consensus > resolution for the issue, but I'll wait to see if there is > any dissent first. > > Regards, > Charlie P. > > > mext wrote: > > Ticket #11: De-registration when returning home [Vijay Devarapalli > > ] > > > > RFC 3775 currently says the mobile node "SHOULD" send a > de-registration > > BU when it returns home. This is kind of odd because, without the > > de-registration BU, the home agent continues defending the > mobile node's > > home address and keeps tunneling the packets to the last > known care-of > > address. The BCE must be deleted for the mobile node to be > able to send/ > > receive packets from the home link. I am not sure why we went with > > "SHOULD" in the first place. > > > > From the interop events I have attended, I know that all > mobile node > > implementations send a de-registration BU as soon as they > detect they > > are on the home link. The use of "SHOULD" instead of > "MUST" caused some > > confusion during the PMIPv6-MIPv6 interactions discussion. > So we need to > > fix this. > > > > Here is the proposed change. > > > > OLD: > > > > A mobile node detects that it has returned to its home > link through > > the movement detection algorithm in use (Section > 11.5.1), when the > > mobile node detects that its home subnet prefix is > again on-link. > > The mobile node SHOULD then send a Binding Update to > its home agent, > > to instruct its home agent to no longer intercept or > tunnel packets > > for it. > > > > NEW: > > > > A mobile node detects that it has returned to its home > link through > > the movement detection algorithm in use (Section > 11.5.1), when the > > mobile node detects that its home subnet prefix is > again on-link. > > The mobile node MUST then send a Binding Update to its > home agent, > > to instruct its home agent to no longer intercept or > tunnel packets > > for it. > > > > > > > --------------------------------------------------------------------- > > > > Gerardo Giaretta > > > > This was discussed also in Philadelphia and in general I agree a > > MUST is more appropriate. > > > > However we should make clear that the MN MUST send the > deregistration > > BU only when it wants the HA to stop intercepting packets and > > forwarding them to the CoA. > > > > Let's assume for example the MN has two active interfaces, > it is using > > interface with CoA1 registered at the HA. Then it switches > interface2 > > on and detects interfaces2 is connected to the home link. > This should > > not immediately trigger the MN to send the BU, unless the > MN wants all > > traffic destined to the HoA routed to interface2 (the MN may still > > want to have the traffic destined to interface1). > > > > > --------------------------------------------------------------------- > > > > Sri Gundavelli > > > > We discussed this issue in the last meeting and I thought > > the conclusion there was, if the mobile node attaches to > > the home link and *if* it decides to use the home address > > i.e., defend the home address on the home link, then it > > MUST send a dereg BU. This will avoid the Proxy ND contention. > > Note that it is possible the MN is attached to the home, > > but may choose to send the dereg bit later. So, the wording > > has to reflect this aspect. > > > > > --------------------------------------------------------------------- > > > > Ahmad Muhanna > > > > IMO, the best for RFC3775 and RFC3775bis is to maintain > "SHOULD" because > > my understanding of "SHOULD" is that the MN MUST send > de-registration > > UNLESS there is a condition that makes it impossible on > the MN to send > > de-registration, e.g. MN lost coverage, or lost power, etc. > > > > The usefulness of SHOULD in base RFC3775 that it can be > become "MUST" > > in a specific scenario where that is possibly described in > a different > > doc, like the case that Gerardo mentioned. IMO, that > "MUST" should be > > captured in the Multi-CoA doc not in RFC3775bis. > > > > On the other hand, the latest change defeats the original > purpose of > > RFC3775, because RFC3775 mandates on the MN to send > de-registration, > > however, the last change, proposed here, makes it based on the MN > > discretion and that is very dangerous. > > > > I disagree with this change and I favor maintaining "SHOULD" in > > the base document and if "MUST" is needed in a specific scenarios > > let us capture that in the respected document. > > > > > --------------------------------------------------------------------- > > > > George Tsirtsis > > > > ... it does not make sense to require > > that the MN sends a dereg BU when it connects to its home link. > > Instead this is a MIPv6 layer decision that has nothing to do with > > whether the MN has connection only to the home link or to > one or more > > other links at the same time. > > > > > --------------------------------------------------------------------- > > > > Sri Gundavelli > > > > ...I'm ok leaving the initial SHOULD > > wording, however, the technical issue that I see and as I > > said before is that we should clearly document and state > > that the MN MUST send a dereg message before it can start > > using its hoa on the home link and that will avoid any ND > > contentions between the HA and the MN. This is not implicit > > and cannot be left to the reader and so must be documented. > > > > Generally, it can be stated the MN must send a dereg. But, > > the issue related to power down ...etc. ..etc are probably > > valid and there may be valid reasons as why MN may not be > > able to send a dereg message. So, we can always qualify > > that requirement and state that the MN must send a dereg > > before it can start using its home address on the home link > > and also leave the option for it not to send any dereg > > message in some situations and when it has no need to use > > its HoA. > > > > Bottom line: > > > > - Leave the SHOULD as a strong recommendation for the MN > > to send dereg, as it is currently written. > > > > - Add additional text and state the MN MUST send a dereg > > before it can use its hoa on the home link. > > > > > --------------------------------------------------------------------- > > > > George Tsirtsis > > > > Sri/Ben, IMHO combining SHOULDs/MAYs and MUSTs with "if" statements > > does not result in good specs. For example, the MUST in > Ben's proposal > > is to be followed only if the MN *intends* to get its > traffic to flow > > on the home link and, not following the MUST does not > really break the > > protocol. In any case, *intentions* are not easy to evaluate during > > interoperability testing. So, maybe we should simply try > to clarify > > the SHOULD. Here is a proposal: > > > > OLD Text: > > > > A mobile node detects that it has returned to its home > link through > > the movement detection algorithm in use (Section > 11.5.1), when the > > mobile node detects that its home subnet prefix is > again on-link. > > The mobile node SHOULD then send a Binding Update to > its home agent, > > to instruct its home agent to no longer intercept or > tunnel packets > > for it. > > > > NEW Text: > > > > A mobile node detects that it has returned to its home > link through > > the movement detection algorithm in use (Section > 11.5.1), when the > > mobile node detects that its home subnet prefix is > again on-link. > > The mobile node SHOULD then send a Binding Update to > its home agent, > > to instruct its home agent to no longer intercept or > tunnel packets > > for it. Until the mobile node sends a de-registration > Binding Update, > > it will not be able to send and receive packets using its home > > address from the home link. The home agent will > continue to intercept > > all packets sent to the mobile's home address and tunnel to the > > previously registered care-of address. > > > > > > > ----------------------------------------+--------------------- > -------------- > > Reporter: charliep@computer.org | Owner: > charliep@computer.org > > Type: defect | Status: new > > > Priority: minor | Milestone: > > > Component: draft-ietf-mext-rfc3775bis | Version: > > > Severity: Active WG Document | Keywords: > > > > ----------------------------------------+--------------------- > -------------- > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 8 18:35:21 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAD7C3A681A; Tue, 8 Jul 2008 18:35:20 -0700 (PDT) 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 F1CF43A67F3 for ; Tue, 8 Jul 2008 18:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipFxPTfXbdNb for ; Tue, 8 Jul 2008 18:35:17 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by core3.amsl.com (Postfix) with ESMTP id 8183A3A681A for ; Tue, 8 Jul 2008 18:35:17 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id x19so1336492pyg.24 for ; Tue, 08 Jul 2008 18:35:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=U+KjdgRAo3vssrXUKdyGqqS+AyojiaTIeGdueS6aWRI=; b=C1comzfKAC+LpSb29YJf+xGOZg25TJx0Nod+FFsfvquNpboxXWDR2AE1GtDcCgIEg2 6nZJjgf2+1qe4EEYxEFsEBhXCzE25ownCL0vT+oxfy9JuXjH+708RD0G3gfCVwLM9G9M iWlet/juBrreu4iPJie1jhuJcJ5JLrdB/55SM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=eJvj6mfNLUD1rSWL4iu8tS39uKU+P+B5syj3XP8jzmg5CZFHRmwQKQiNoi9VHOZpEv ZrS1kr9/UudaVHN6WalzP4UUESNNkOFTlAaZyWuwlLaOfV6mJck6gMXV6FKK4p3iHMFJ jPBFSdte4trKc6fE9n93n/8IME42PksuuevbU= Received: by 10.115.16.1 with SMTP id t1mr8750138wai.19.1215567325489; Tue, 08 Jul 2008 18:35:25 -0700 (PDT) Received: by 10.115.17.1 with HTTP; Tue, 8 Jul 2008 18:35:25 -0700 (PDT) Message-ID: <1d38a3350807081835h730886e1w71605ba734035b45@mail.gmail.com> Date: Wed, 9 Jul 2008 09:35:25 +0800 From: "Hui Deng" To: "Charles E. Perkins" In-Reply-To: <4873A45A.7020106@earthlink.net> MIME-Version: 1.0 References: <200806050918.05372.julien.IETF@laposte.net> <200806061144.23200.julien.IETF@laposte.net> <20080606100743.GA12803@sd-5945.dedibox.fr> <200806061349.32192.julien.IETF@laposte.net> <878wxgungh.fsf@natisbad.org> <4873A45A.7020106@earthlink.net> Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] [rfc3775] Application using the care-of address 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="===============1920903335==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1920903335== Content-Type: multipart/alternative; boundary="----=_Part_11878_16609914.1215567325479" ------=_Part_11878_16609914.1215567325479 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, all I agree that socket handling by IKE versus availability of the CoA from MIPv6 is out of scope for RFC3775bis. We'd better start a new seperated work item asap. Thanks. -Hui 2008/7/9 Charles E. Perkins : > > Hello folks, > > It seems to me that socket handling by IKE versus > availability of the Care-of Address from MIPv6 is > out of scope for rfc3775bis. I've created a new issue > for Julien's original proposed (informational) update. > Up until now, I haven't included the text for the IKE > socket handling question as part of the background > discussion for the new issue, but I can always go back > and add it later if need be. > > Regards, > Charlie P. > > > > > Arnaud Ebalard wrote: > >> Hi Julien and sorry for the latency, >> >> Julien Laganier writes: >> >> >> >>> RFC5014 allows a sending process to express to the IP stack its >>>>> preference for a CoA to be selected as source address in outbound >>>>> packets, and then allows the process to verify that the selected >>>>> source address is indeed a CoA: >>>>> >>>>> ... snip ... >>>>> >>>>> >>>> I think you miss the point. >>>> >>> I guess I do... >>> >>> >> >> With 5014, you can manage to get a socket that will use a CoA as source >> address (with the ability to verify it is indeed a CoA). For common >> applications, I imagine that this is just fine because they simply >> do not care about the address itself but simply want to use a CoA and >> delegate the address decision to the system. >> >> For the interaction between MIPv6 and IPsec/IKE, a more direct path is >> needed (IMHO, other developers that have spent time on the code should >> comment) at various moments where the MIPv6 process must influence the >> IPsec stack and the IKE daemon in a very specific way: >> - Bootstrapping (handling of transport mode SA by IKE) >> - Update of in-kernel SP/SA on movement >> - Update of IKE-daemon mirrored SP/SA on movement >> - Update of IKE_SA endpoints on movements >> - ... >> >> I think that in the specific case of bootstrapping, it would be possible >> to specifically mark the SP (or SA information to be negotiated, even if >> it would introduce a daemon/system specific issue in some way) for the >> IKE daemon to use a CoA. From your previous code samples, I think that >> the IKE daemon will manage to get a socket using a CoA as source, >> retrieve this CoA and consider it the expected source address to use for >> the negotiation of the IKE_SA (the socket is directly usable but the @ >> is certainly needed for internal tasks). After scratching my head, I >> think what you propose could take off, but probably won't fly well or at >> all. An IKE daemon differs from a common app regarding handling of >> adresses: it has to be very careful and handle things at a somewhat >> lower level than a common app. >> >> I also have some questions (don't hesitate to reply with pointers if it >> is documented) associated with your expected use of 5014 for MIPv6 >> bootstrapping by IKE: what happens when there are multiple addresses on >> the system (for instance a native, an ULA and a 6to4 address). What is >> their status? all CoA? The MIPv6 process will choose one specific >> address for the binding with its HoA (source of the BU when it leaves >> the MN) based on specific internal policies. What gives the insurance >> that this address will be the one that the IKE daemon will use if it >> implements 5014 for bootstrapping? >> >> To continue on that path, do you see a simple way for the IKE daemon to >> update its IKE_SA endpoints on movement with a new CoA (item 4 in my >> previous list)? How will it be warned to do the change? What are the >> expected actions to be taken? >> Because a decision has already been taken on the interest of some work >> on such a mechanism by the WG, I should probably keep the following >> additional question for me: what about items 2 and 3? >> >> In the end, it is obvious that a MIPv6 process needs to interact with >> IPsec/IKE. I'd like to be proven false by some implementations (MIPv6, >> IKE, IPsec stack) that could use what is currently on the table >> (normalized documents, i.e. RFC) to provide something that works. >> >> Cheers, >> >> a+ >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > ------=_Part_11878_16609914.1215567325479 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hello, all
 
I agree that socket handling by IKE versus availability of the CoA
from MIPv6 is out of scope for RFC3775bis.
 
We'd better start a new seperated work item asap.
 
Thanks.
 
-Hui

2008/7/9 Charles E. Perkins <charles.perkins@earthlink.net>:

Hello folks,

It seems to me that socket handling by IKE versus
availability of the Care-of Address from MIPv6 is
out of scope for rfc3775bis.  I've created a new issue
for Julien's original proposed (informational) update.
Up until now, I haven't included the text for the IKE
socket handling question as part of the background
discussion for the new issue, but I can always go back
and add it later if need be.

Regards,
Charlie P.




Arnaud Ebalard wrote:
Hi Julien and sorry for the latency,

Julien Laganier <julien.IETF@laposte.net> writes:

 
RFC5014 allows a sending process to express to the IP stack its
preference for a CoA to be selected as source address in outbound
packets, and then allows the process to verify that the selected
source address is indeed a CoA:

... snip ...
       
I think you miss the point.      
I guess I do...
   

With 5014, you can manage to get a socket that will use a CoA as source
address (with the ability to verify it is indeed a CoA). For common
applications, I imagine that this is just fine because they simply
do not care about the address itself but simply want to use a CoA and
delegate the address decision to the system.

For the interaction between MIPv6 and IPsec/IKE, a more direct path is
needed (IMHO, other developers that have spent time on the code should
comment) at various moments where the MIPv6 process must influence the
IPsec stack and the IKE daemon in a very specific way:
- Bootstrapping (handling of transport mode SA by IKE)
- Update of in-kernel SP/SA on movement
- Update of IKE-daemon mirrored SP/SA on movement
- Update of IKE_SA endpoints on movements
- ...

I think that in the specific case of bootstrapping, it would be possible
to specifically mark the SP (or SA information to be negotiated, even if
it would introduce a daemon/system specific issue in some way) for the
IKE daemon to use a CoA. From your previous code samples, I think that
the IKE daemon will manage to get a socket using a CoA as source,
retrieve this CoA and consider it the expected source address to use for
the negotiation of the IKE_SA (the socket is directly usable but the @
is certainly needed for internal tasks). After scratching my head, I
think what you propose could take off, but probably won't fly well or at
all. An IKE daemon differs from a common app regarding handling of
adresses: it has to be very careful and handle things at a somewhat
lower level than a common app.

I also have some questions (don't hesitate to reply with pointers if it
is documented) associated with your expected use of 5014 for MIPv6
bootstrapping by IKE: what happens when there are multiple addresses on
the system (for instance a native, an ULA and a 6to4 address). What is
their status? all CoA? The MIPv6 process will choose one specific
address for the binding with its HoA (source of the BU when it leaves
the MN) based on specific internal policies. What gives the insurance
that this address will be the one that the IKE daemon will use if it
implements 5014 for bootstrapping?

To continue on that path, do you see a simple way for the IKE daemon to
update its IKE_SA endpoints on movement with a new CoA (item 4 in my
previous list)? How will it be warned to do the change? What are the
expected actions to be taken?
Because a decision has already been taken on the interest of some work
on such a mechanism by the WG, I should probably keep the following
additional question for me: what about items 2 and 3?

In the end, it is obvious that a MIPv6 process needs to interact with
IPsec/IKE. I'd like to be proven false by some implementations (MIPv6,
IKE, IPsec stack) that could use what is currently on the table
(normalized documents, i.e. RFC) to provide something that works.

Cheers,

a+
 ------------------------------------------------------------------------

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

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

------=_Part_11878_16609914.1215567325479-- --===============1920903335== 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 --===============1920903335==-- From mext-bounces@ietf.org Tue Jul 8 19:29:22 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68D513A689C; Tue, 8 Jul 2008 19:29:22 -0700 (PDT) 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 1C1A73A6908 for ; Tue, 8 Jul 2008 19:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsQ182V6-M-Z for ; Tue, 8 Jul 2008 19:29:20 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 24FED3A67FD for ; Tue, 8 Jul 2008 19:29:20 -0700 (PDT) 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 m692TGFD012872; Wed, 9 Jul 2008 11:29:16 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb1) with ESMTP id m692THD18160; Wed, 9 Jul 2008 11:29:17 +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 m692TEx05412; Wed, 9 Jul 2008 11:29:15 +0900 (JST) Received: from NW-Sephiroth ([10.81.113.116]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Jul 2008 10:27:44 +0800 Received: from NWSephiroth by NW-Sephiroth (PGP Universal service); Wed, 09 Jul 2008 10:27:40 +0800 X-PGP-Universal: processed; by NW-Sephiroth on Wed, 09 Jul 2008 10:27:40 +0800 From: "Benjamin Lim" To: "'Vijay Devarapalli'" References: <063.5678bdd45e5096c3dfbccfcf1ef43af5@tools.ietf.org><4873E645.2000708@computer.org> Date: Wed, 9 Jul 2008 10:27:40 +0800 Message-ID: <010801c8e16b$5c2889d0$7471510a@psl.local> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjhR7gv2RIhnWx6SnC8ZZPUcCDGjQACuKaAAAXrj/A= In-Reply-To: X-OriginalArrivalTime: 09 Jul 2008 02:27:44.0012 (UTC) FILETIME=[5E5024C0:01C8E16B] Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] 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, One comment on the new proposed text. > NEW: > > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > In case the mobile node has only one care-of address > associated with > the home address, it MUST send a Binding Update to its home agent, > to instruct its home agent to no longer intercept or tunnel packets > for it. [Ben] This part I agree. When the MN returns home, MN must send a BU to HA to remove its CoA entry from the HA. > In case the mobile node has more than one interface and > can bind more than one care-of address to the home address, the > mobile MAY send a Binding Update to its home agent, to > instruct its > home agent to no longer intercept or tunnel packets for > it. [Ben] IMHO, this should also be a MUST. Base on the same logic as above. This is irrespective to whether MN is trying to achieve simultaneous home and away or not. Regardless on whether if MN has one CoA or multiple CoAs, when MN returns home, it would need to remove its associated CoA entry from the HA. Hence, I do not see a reason why for one CoA MN MUST send BU, but for multiple CoAs MN MAY send BU. Regards, Benjamin Lim > For more > information on the mobile node returning home procedure when there > are multiple care-of addresses, see [MCOA]. > > In the Informative references add, > > [MCOA] Wakikawa, S., Devarapalli, V., Ernst, T., and K. Nagami, > "Multiple Care-of Addresses Registration", Work in > Progress, May 2008. > > Hope this acceptable to all. > > Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 8 22:53:53 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C35173A6782; Tue, 8 Jul 2008 22:53:53 -0700 (PDT) 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 41A2C3A63D3 for ; Tue, 8 Jul 2008 22:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhEUUSgY412M for ; Tue, 8 Jul 2008 22:53:51 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 62A0E3A6782 for ; Tue, 8 Jul 2008 22:53:51 -0700 (PDT) Received: from 98.207.41.228 ([98.207.41.228]) by mse15be2.mse15.exchange.ms ([172.30.10.130]) via Exchange Front-End Server owa.mse15.exchange.ms ([172.30.10.124]) with Microsoft Exchange Server HTTP-DAV ; Wed, 9 Jul 2008 05:54:01 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Tue, 08 Jul 2008 22:53:58 -0700 From: Vijay Devarapalli To: Benjamin Lim Message-ID: Thread-Topic: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] Thread-Index: AcjhR7gv2RIhnWx6SnC8ZZPUcCDGjQACuKaAAAXrj/AAB3kx+g== In-Reply-To: <010801c8e16b$5c2889d0$7471510a@psl.local> Mime-version: 1.0 Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] 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 7/8/08 7:27 PM, "Benjamin Lim" wrote: >> In case the mobile node has more than one interface and >> can bind more than one care-of address to the home address, the >> mobile MAY send a Binding Update to its home agent, to >> instruct its >> home agent to no longer intercept or tunnel packets for >> it. > [Ben] IMHO, this should also be a MUST. Base on the same logic as above. > This is irrespective to whether MN is trying to achieve simultaneous home > and away or not. Regardless on whether if MN has one CoA or multiple CoAs, > when MN returns home, it would need to remove its associated CoA entry from > the HA. Hence, I do not see a reason why for one CoA MN MUST send BU, but > for multiple CoAs MN MAY send BU. The second part is intended to support the case where the MN may want to continue using the interface with which it is attached to the visited link. The binding stays active, while the MN is attaching to the home link with one of the interfaces. It may decide at a later time if wants to use only the interface with which it is attached to the home link. Any suggestions to improve the text to indicate the above is welcome. Vijay > > Regards, > Benjamin Lim > >> For more >> information on the mobile node returning home procedure when there >> are multiple care-of addresses, see [MCOA]. >> >> In the Informative references add, >> >> [MCOA] Wakikawa, S., Devarapalli, V., Ernst, T., and K. Nagami, >> "Multiple Care-of Addresses Registration", Work in >> Progress, May 2008. >> >> Hope this acceptable to all. >> >> Vijay > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 8 23:53:31 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AA4128C108; Tue, 8 Jul 2008 23:53:31 -0700 (PDT) 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 59D1728C10F for ; Tue, 8 Jul 2008 23:53:30 -0700 (PDT) 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 QJaFMveHnvXi for ; Tue, 8 Jul 2008 23:53:29 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 78F5E28C101 for ; Tue, 8 Jul 2008 23:53:29 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Jul 2008 02:54:02 -0400 Message-ID: In-Reply-To: <010801c8e16b$5c2889d0$7471510a@psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] Thread-Index: AcjhR7gv2RIhnWx6SnC8ZZPUcCDGjQACuKaAAAXrj/AACXe6IA== References: <063.5678bdd45e5096c3dfbccfcf1ef43af5@tools.ietf.org><4873E645.2000708@computer.org> <010801c8e16b$5c2889d0$7471510a@psl.local> From: "Vijay Devarapalli" To: "Benjamin Lim" Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] 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 One more thing... > [Ben] IMHO, this should also be a MUST. Base on the same > logic as above. > This is irrespective to whether MN is trying to achieve > simultaneous home > and away or not. Regardless on whether if MN has one CoA or > multiple CoAs, > when MN returns home, it would need to remove its associated > CoA entry from > the HA. Hence, I do not see a reason why for one CoA MN MUST > send BU, but > for multiple CoAs MN MAY send BU. You also have to address the case where the mobile node might not have had a CoA on the interface with which it attached to the home link. Even if it had an address confitured on that interface, it might have not bound the address to the home address either. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jul 9 00:03:23 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 746233A696A; Wed, 9 Jul 2008 00:03:23 -0700 (PDT) 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 AE36E3A696A for ; Wed, 9 Jul 2008 00:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 icNaheu4u9Hj for ; Wed, 9 Jul 2008 00:03:21 -0700 (PDT) Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id EA8013A683B for ; Wed, 9 Jul 2008 00:03:20 -0700 (PDT) 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 1KGTi1-0000uU-9s; Wed, 09 Jul 2008 09:03:25 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: "Hui Deng" References: <200806050918.05372.julien.IETF@laposte.net> <200806061144.23200.julien.IETF@laposte.net> <20080606100743.GA12803@sd-5945.dedibox.fr> <200806061349.32192.julien.IETF@laposte.net> <878wxgungh.fsf@natisbad.org> <4873A45A.7020106@earthlink.net> <1d38a3350807081835h730886e1w71605ba734035b45@mail.gmail.com> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:080709:denghui02@gmail.com::SkWA6r2qJxi28xPJ:0000000000000000000000000000000000000000000wGd X-Hashcash: 1:20:080709:charles.perkins@earthlink.net::BLFJX0iZvV6DMZV2:000000000000000000000000000000002hO5 X-Hashcash: 1:20:080709:mext@ietf.org::ZX5ovJDq3R9XT21A:00005hR7 X-Hashcash: 1:20:080709:julien.ietf@laposte.net::Wdgg38dp1d7YIJb1:000000000000000000000000000000000000007rjs Date: Wed, 09 Jul 2008 09:02:58 +0200 In-Reply-To: <1d38a3350807081835h730886e1w71605ba734035b45@mail.gmail.com> (Hui Deng's message of "Wed, 9 Jul 2008 09:35:25 +0800") Message-ID: <87d4ln4k0t.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] [rfc3775] Application using the care-of address 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="===============1813578747==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1813578747== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Hi, "Hui Deng" writes: > I agree that socket handling by IKE versus availability of the CoA > from MIPv6 is out of scope for RFC3775bis. me too. > We'd better start a new seperated work item asap. I'll start a thread on that point next week if you are ok. This will incude gathering some feedback from people that implemented IKE+MIPv6. IMHO, the discussion belongs (should start) on both IPsec ML and mext ML. a+ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIdGKiAlWVfAR6UCYRAmE9AKCa0Lke1KX4tgoILQ0sumW/yRLqXgCglLWr hBY3xopev4nhZqcJM2mQQ1k= =rSgb -----END PGP SIGNATURE----- --=-=-=-- --===============1813578747== 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 --===============1813578747==-- From mext-bounces@ietf.org Wed Jul 9 01:16:25 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D1503A691C; Wed, 9 Jul 2008 01:16:25 -0700 (PDT) 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 B26463A691C for ; Wed, 9 Jul 2008 01:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eO2NHrRhm0Yg for ; Wed, 9 Jul 2008 01:16:22 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.184]) by core3.amsl.com (Postfix) with ESMTP id 2186B3A686E for ; Wed, 9 Jul 2008 01:16:21 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so1440712tib.25 for ; Wed, 09 Jul 2008 01:16:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=xurovEfjLlZbNJyd79Ki1vT399efGsGROAIRJDUYRU0=; b=H24Y1PyefcYkb+nYSaBLxpRIQ/l7bvWVZC/03SOqniPa/UZfALD+oXRwxgN8XFFxwu nDiU/JxnbWipEk/VIHo+Bw/WzPdEmdP4tMi58c3zW96NhPtCeoEynZRLvvmdtl4t6tBX N+2tOFIefYJvIjMU1nZKK0BO1cYVwNAcVe5DI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=GmwlEeGuCDzloV+KIWr6K3Jncm8X1NFdVQCwKdW7P7Jt2yWWW0jOYqum9l7PgXfhf7 Kax5d7uZBd6zzT+q5ZoGGKKcmO60L2OBKeRBkrZTF/JMBDomw8TYIT/RiZtkETFIrfMH V+1o1S3wdVG4FKKItO5anMbLXAi3XmmfuPEqI= Received: by 10.110.41.17 with SMTP id o17mr4305128tio.18.1215591388132; Wed, 09 Jul 2008 01:16:28 -0700 (PDT) Received: by 10.110.53.11 with HTTP; Wed, 9 Jul 2008 01:16:28 -0700 (PDT) Message-ID: <1d38a3350807090116x2759eca8i3cd6758fc876b6e6@mail.gmail.com> Date: Wed, 9 Jul 2008 16:16:28 +0800 From: "Hui Deng" To: "Arnaud Ebalard" In-Reply-To: <87d4ln4k0t.fsf@natisbad.org> MIME-Version: 1.0 References: <200806050918.05372.julien.IETF@laposte.net> <200806061144.23200.julien.IETF@laposte.net> <20080606100743.GA12803@sd-5945.dedibox.fr> <200806061349.32192.julien.IETF@laposte.net> <878wxgungh.fsf@natisbad.org> <4873A45A.7020106@earthlink.net> <1d38a3350807081835h730886e1w71605ba734035b45@mail.gmail.com> <87d4ln4k0t.fsf@natisbad.org> Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] [rfc3775] Application using the care-of address 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="===============0256468956==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0256468956== Content-Type: multipart/alternative; boundary="----=_Part_4634_16715510.1215591388137" ------=_Part_4634_16715510.1215591388137 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I am fine with it, http://tools.ietf.org/id/draft-qi-mip6-ikev2-interfacing-01.txt http://tools.ietf.org/id/draft-sugimoto-mip6-pfkey-migrate-04.txt I guess that most of the authors here go to both IPsec and MIP6 ML as well. Thanks -Hui 2008/7/9 Arnaud Ebalard : > Hi, > > "Hui Deng" writes: > > > I agree that socket handling by IKE versus availability of the CoA > > from MIPv6 is out of scope for RFC3775bis. > > me too. > > > We'd better start a new seperated work item asap. > > I'll start a thread on that point next week if you are ok. > > This will incude gathering some feedback from people that implemented > IKE+MIPv6. > > IMHO, the discussion belongs (should start) on both IPsec ML and mext > ML. > > a+ > > ------=_Part_4634_16715510.1215591388137 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi,
 
I am fine with it,
 

I guess that most of the authors here go to both IPsec and
MIP6 ML as well.
 
Thanks
 
-Hui
2008/7/9 Arnaud Ebalard <arno@natisbad.org>:
Hi,

"Hui Deng" <denghui02@gmail.com> writes:

> I agree that socket handling by IKE versus availability of the CoA
> from MIPv6 is out of scope for RFC3775bis.

me too.

> We'd better start a new seperated work item asap.

I'll start a thread on that point next week if you are ok.

This will incude gathering some feedback from people that implemented
IKE+MIPv6.

IMHO, the discussion belongs (should start) on both IPsec ML and mext
ML.

a+


------=_Part_4634_16715510.1215591388137-- --===============0256468956== 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 --===============0256468956==-- From mext-bounces@ietf.org Wed Jul 9 06:05:43 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 377C83A69D2; Wed, 9 Jul 2008 06:05:43 -0700 (PDT) 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 786633A6A6A for ; Wed, 9 Jul 2008 06:05:41 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqHsuDTetya2 for ; Wed, 9 Jul 2008 06:05:40 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 62B613A68E7 for ; Wed, 9 Jul 2008 06:05:40 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m69D5ki18951; Wed, 9 Jul 2008 13:05:46 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Jul 2008 08:05:37 -0500 Message-ID: In-Reply-To: <4873EC97.6000800@earthlink.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mandated behaviors, "whenever possible" Thread-Index: AcjhS3pvf+hL1nyxQ5eWH4xmW27g9AAeFmBg References: <4873EC97.6000800@earthlink.net> From: "Ahmad Muhanna" To: "Charles E. Perkins" Cc: mext@ietf.org Subject: Re: [MEXT] Mandated behaviors, "whenever possible" 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 Charlie, Yep! I actually missed [:)] at the end of the sentence. But you explained exactly what I was trying to convey in details! Best Regards, Ahmad > -----Original Message----- > From: Charles E. Perkins [mailto:charles.perkins@earthlink.net] > Sent: Tuesday, July 08, 2008 5:39 PM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: mext@ietf.org > Subject: Mandated behaviors, "whenever possible" > > > Hello Ahmad, > > In one email adding to the discussion about Issue #11 you wrote: > > > One final note: Any where we mandate that the MN > "MUST" send > > de-registration, we probably need to have a clause that > > "whenever it is > > possible for the MN to do so" i.e. if the MN moves to an > > area without > > coverage, then the MN wont comply anyway. > > Generally, any physical network medium can lose packets under > various circumstances. It would be wrong, I'm sure, to > append the "whenever" clause as you suggested to all protocol > mandates for all protocols that need to be obeyed by wireless > devices. So I'd rather not have to append that clause > anywhere, since it is really already implicit. Just to be > silly, we could rephrase it as "whenever the laws of physics > permit", or "whenever the cost is not prohibitive", or > "whenever there is no resulting danger of atomic warfare", or > , ... > > Regards, > Charlie P. > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jul 9 09:39:06 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 528DC3A6B19; Wed, 9 Jul 2008 09:39:06 -0700 (PDT) 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 A8D263A68A2 for ; Wed, 9 Jul 2008 09:39:04 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJYGRJ2YjMfW for ; Wed, 9 Jul 2008 09:39:02 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by core3.amsl.com (Postfix) with ESMTP id 642193A6AB0 for ; Wed, 9 Jul 2008 09:39:02 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so1452482and.122 for ; Wed, 09 Jul 2008 09:39:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=P8NDY/cWAfmcOUvGEFbfTkEIgjxGR3UWUZgQ4XGtO4w=; b=f30nMrXYzosHwc7Yj29Zj13/QZ7FMylIrNj0dSZsZvUfQJ1CNOY3VXxzrKuNmaldMR HOZ5BWmMggjKTNaaAl2jhnd5Rxnd6r/ibJ3PIYC8bnv+xyeBpk1/N9MqEJKGFz+Cc+ue WywUxIkHjI/OukvMcnrkJEkrwlJ7uoKOhoDKU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=LLpCJnPTbtaXr4Rs9AYXl7IJsni/R9E7ub94GH6bpJ9KwhcsL0bLwGPnq73k4yp9F/ oUPX/SJ5izHyiMHYiofcJXG8CRfRh6ffUa8VJx/lbX+QZIvp6ZKYqzU+VPIWhFw6lkei GqORnR098Tc2Eziqox8mLq4Ih6PTOhVMOBE6M= Received: by 10.100.122.8 with SMTP id u8mr6585008anc.103.1215621544180; Wed, 09 Jul 2008 09:39:04 -0700 (PDT) Received: by 10.100.57.5 with HTTP; Wed, 9 Jul 2008 09:39:04 -0700 (PDT) Message-ID: Date: Wed, 9 Jul 2008 09:39:04 -0700 From: "fan zhao" To: "Arnaud Ebalard" In-Reply-To: <871w24ji9c.fsf@natisbad.org> MIME-Version: 1.0 Content-Disposition: inline References: <20080706174502.6A6393A68F3@core3.amsl.com> <871w24ji9c.fsf@natisbad.org> Cc: mext@ietf.org Subject: Re: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-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 Arnaud, Sorry for the late reply and thank you for all these good comments. Please see my reply below. On Tue, Jul 8, 2008 at 12:19 PM, Arnaud Ebalard wrote: > Hi, > > "fan zhao" writes: > >> We have submitted a draft on using IKEv2 to assign a Mobile Network >> Prefix to the Mobile Router. Comments, questions and suggestions >> are highly appreciated. >> Thanks. > > Comments inline below. > >> 3. New Attribute Format >> >> We propose a new IKEv2 Configuration Attribute, called >> MOBILE_NETWORK_PREFIX6. This attribute is carried in the IKEv2 >> Configuration Payload and is used to convey an IPv6 Mobile Network >> Prefix between the Mobile Router and the Home Agent. Figure 1 shows >> the format of the MOBILE_NETWORK_PREFIX6 Configuration Attribute. >> >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |R| Attribute Type | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Prefix Lifetime | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> | IPv6 Mobile Network Prefix | >> | | >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Prefix Length | >> +-+-+-+-+-+-+-+-+ >> >> Figure 1: The format of the MOBILE_NETWORK_PREFIX6 attribute >> >> Reserved (1 bit) >> >> This bit MUST be set to zero and MUST be ignored on receipt. >> >> Attribute Type (15 bits) >> >> A unique identifier for the MOBILE_NETWORK_PREFIX6 attribute >> (to be determined by IANA). >> >> Length (2 octets) >> >> Length in octets of fields, including IPv6 Mobile Network >> Prefix, Prefix Lifetime and Prefix Length. This can be 0 or >> 21. >> >> Prefix Lifetime (4 octets) >> >> The length of time period during which the Mobile Network >> Prefix remains valid. This should not be longer than the >> lifetime of the IKE security association used when the Mobile >> Network Prefix is assigned to the Mobile Router. > > I have no strong opinion on this specific topic but: Why limiting the > prefix lifetime so that it is smaller than the SA lifetime? For me, the > prefix and prefix lifetime are MIPv6 related information and SA lifetime > are IKE-related information. Fan> I agree that the prefix and prefix lifetime are more related to MIPv6 than IKE. Although the prefix lifetime is equal to or smaller than the IKE SA lifetime, when the IKE SA lifetime expires, the MR can request the same prefix. In reality, I do not see any particular reason that the HA would reject the request of the same prefix from the same MR. Therefore the protocol specified here allows the same prefix to be used for a time period longer than the lifetime of the IKE SA. Fan> Although very rare, the prefix may be changed before the SA expires. We do not want to exclude such possibility and limit the capability of the protocol, because IMO, the protocol is a tool and how to use is up to deployment, configuration and policy. The MR can request any lifetime of the prefix and it is finally decided by the HA. Also in MIPv6, the lifetime of the HoA is also associated with the lifetime of the SA. > >> Prefix Length (1 octet) >> >> The length in bits of the Mobile Network Prefix specified in >> the IPv6 Mobile Network Prefix field. >> >> When the Mobile Router requests a new Mobile Network Prefix, the >> Mobile Router includes the MOBILE_NETWORK_PREFIX6 attribute in the >> CFG_REQUEST payload and the value of the Length field is zero or the >> IPv6 Mobile Network Prefix field is set as zero. The Mobile Router >> may indicate the preferred Mobile Network Prefix in this attribute >> and the Home Agent should return the indicated Mobile Network Prefix, >> if available. The Mobile Router may explicitly request a lifetime by >> specifying a value in the Prefix Lifetime field. Such value must not >> be zero if the Mobile Router specifies a preferred Mobile Network >> Prefix and is set as 2^32-1 if the Mobile Router wants the assigned >> Mobile Network Prefix remains valid for the lifetime of the IKEv2 >> security association. The Mobile Router may request multiple Mobile >> Network Prefixes by using multiple MOBILE_NETWORK_PREFIX6 attributes >> in one IKEv2 request message. > > This leads to a question: who decides how many prefixes will be > configured and on which interfaces? The MR or the HA? How will the MR > decide to assign prefix1 and prefix2 to interface A and interface B (or > the reverse). This will end up being a local decision on the MR, AFAICT. > Fan> The final decision on how many prefixes can be configured on the MR should be made by the HA. I agree that it is the MR's decision on which prefix is configured on which interfaces, i.e. those interfaces connecting to the Mobile Network. > You should probably explicitly states that the MR requests the number of > prefixes it want BUT the final decision is let to the HA. The details > of how the delegated prefixes are used on the MR are outside the scope > of the specification. Fan> I agree. That is a good suggestion. I will revise the draft accordingly. > > More generally, I don't think the solution will be really usable in a > multiple interfaces/prefixes case (this is just an opinion). Fan> Can you please elaborate it? I assume that by the multiple interfaces/prefixes case, you mean that the MR has, for example, two interfaces, A and B, connecting to the Mobile Network and the MR wants to configure one unique prefix on each interface, as you mentioned above. Do I understand correctly or I miss something. There are many scenarios described in the NEMO multihoming analysis draft. > >> If such request from the Mobile Router is valid, the Home Agent >> includes the MOBILE_NETWORK_PREFIX6 attribute in the CFG_REPLY >> payload and sends it back to the Mobile Router in one IKEv2 response >> message. The attribute contains the allocated Mobile Network Prefix >> and the lifetime authorized by the Home Agent. If the Mobile Router >> requests multiple Mobile Network Prefixes in one IKEv2 request >> message, the Home Agent should return multiple Mobile Network >> Prefixes by using multiple MOBILE_NETWORK_PREFIX6 attributes in one >> IKEv2 response message. >> >> There are different mechanisms for the Home Agent to allocate the >> Mobile Network Prefix. For example, the Home Agent may manage a pool >> of network prefixes by itself or communicate with a DHCP server >> located in the home domain for this task. The details of such >> mechanisms are out of scope of this document. > > If DHCP is used the DUID*, IA_PD, ... from the real peer (the MN) will > not be available on the HA. In the end, DHCP will only be used to > retrieve a bunch of anonymous prefixes which will then be sent to the > IKE daemon on the MN. IMHO, this difference with an end-to-end DHCPv6 > solution will matter in environments with multiple prefixes/interfaces. Fan> Firstly, I have a question regarding DUID. I checked RFC 3315, the DUID could be a MAC address. Does this mean that a multi-interface MN can use a different DUID in a separate DHCP session (thus, acts as a different DHCP client)? Fan> If so, when the MR acts a DHCP requesting router and the HA acts as a delegating router as specified in DHCP-PD, the MR can use different MAC addresses of the interfaces connecting to the Mobile Network as DUID, so that the HA can assign a specific MNP to each of such interfaces. Is my understanding correct? Fan> Well, the protocol we proposed can be extended to carry the interface id for the home agent to assign a specific prefix to a specific interface. However, before going into the details of the solution, I would like to understand the scenario and the use case for such requirement? As far as I know, the NEMO basic support protocol only requires the HA to verify whether the _MR_ is authorized to register certain MNPs. There is no requirement that the HA needs to know which MNP is configured on which interface. BTW, how does the HA make decisions based on the interfaces connecting to the mobile network. IMHO, this should be transparent to the HA. Maybe you have a use case in mind, can you please elaborate it? > >> 4. Mobile Network Prefix Assignment >> >> When the Mobile Router powers up, based on its configuration or some >> mechanisms that are out of scope of this document, the Mobile Router >> may choose hosted based mobility protocols, such as DSMIPv6/NEMO, to >> set up network connectivity. Figure 2 shows the steps performed by >> the Mobile Router during bootstrapping. >> >> MR Access network HA >> | | | >> | IP address configuration | | >> |<-------------------------->| | >> | | | >> | Home Agent discovery | | >> |<--------------------> | | >> | | | >> | IKE_SA_INIT{...} | >> |<------------------------------------------------------->| >> | | >> | IKE_AUTH{CFG_REQUEST(HoA/HNP, MNP)} | >> |-------------------------------------------------------->| >> | | >> | IKE_AUTH{CFG_REPLY(HoA/HNP, MNP)} | >> |<--------------------------------------------------------| >> | | >> | BU/BA | >> |<------------------------------------------------------->| >> | | >> >> Figure 2: The procedure of the Mobile Network Prefix assignment via >> IKEv2 >> >> o When attaching to a new link, the Mobile Router configures an IP >> address on its interface that attaches to this link, for example, >> by performing IP address stateless configuration using Router >> Solicitation and Router Advertisement messages. >> >> o The Mobile Router discovers the IP address of the Home Agent, for >> example, by using mechanisms defined in [6] [3] and [4]. >> >> o The Mobile Router starts to establish an IPSec security >> association and firstly completes the IKE_SA_INIT exchange with >> the discovered Home Agent. > > I still wonder how that negotiation is *triggered*. I will probably ask > on ipsec@ietf at some point. Fan> OK. > > >> o If the Mobile Router attaches to its home link (the details of the >> home link detection mechanism is out of scope of this document), >> the Mobile Router does not perform binding registration with the >> Home Agent. Otherwise, the Mobile Router follows the procedure >> specified in the NEMO Basic Support Protocol [1] to register the >> binding between its Care-of address and its Home Address and the >> Mobile Network Prefix with the Home Agent. Additionally, the >> Mobile router may negotiate an IPSec child security association >> with the Home Agent to protect the data traffic from itself and >> the Mobile Network Nodes. > > Because the MR needs to register its network prefix with the HA, there > is a need for the HA to be warned by IKE (or another mean) which > prefixeshave been delegated (using IKE or another solution). If it is > not defined, this cannot be implemented at all. > Fan> I agree. I mentioned this issue in the security consideration section, though the details of out of scope of this document. > >> 5.2. Releasing the Mobile Network Prefix >> >> The Mobile Network Prefix release procedure can be initiated by >> either the Mobile Router or the Home Agent. >> >> To release an allocated Mobile Network Prefix, the Mobile Router >> initiates the IKEv2 Informational Exchange with the Home Agent. In >> the CFG_REQUEST payload carried in the IKEv2 request message, the >> Mobile Router includes the Mobile Network Prefix to be released and >> the lifetime set as zero in the MOBILE_NETWORK_PREFIX6 attribute. As >> >> >> >> Zhao, et al. Expires January 5, 2009 [Page 8] >> >> Internet-Draft MNP Assigment July 2008 >> >> >> a reply, the Home Agent returns a CFG_REPLY payload indicating the >> released Mobile Network Prefix and the lifetime set as zero. >> >> To release an allocated Mobile Network Prefix, the Home Agent can >> also initiate the IKEv2 Informational Exchange with the Mobile >> Router. In the IKEv2 Informational Exchange message sent to the >> Mobile Router, the Home Agent uses the CFG_REQUEST payload to carry >> the MOBILE_NETWORK_PREFIX6 attribute that indicates the Mobile >> Network Prefix to be released and the lifetime set as zero. When the >> Mobile Router receives such IKEv2 request message, it removes the >> corresponding configuration and replies with a CFG_REPLY payload to >> carry the MOBILE_NETWORK_PREFIX6 attribute that indicates the >> released Mobile Network Prefix and the lifetime set as zero. When >> the Home Agent receives this responses, it recycles the released >> Mobile Network Prefix. > > If that happens, what are the impacts WRT MIPv6: even if it is released > at the IKE level, what is then done at MIPv6 level? How are both MIPv6 > peers warned by their IKE couterparts that the prefix released has > happened? > Fan> IMO, mobility signaling messages should take care of mobility states at the MIPv6 level, such as binding cache entries. When the MR attaches to its home link, there is no corresponding binding cache entry created at the home agent, thus the HA and the MR do not need to do anything at the MIPv6 level. When the MR attaches to a foreign link, and when the MR wants to release a MNP, it can send a mobility message, such as the BU message, to de-reg the MNP from the binding cache entry and then use the IKE informational exchange to release the MNP, or vice versa. > >> 5.3. Updating the Mobile Network Prefix >> >> The Mobile Network Prefix update procedure can be initiated by either >> the Mobile Router or the Home Agent. >> >> One way to perform the Mobile Router initiated Mobile Network Prefix >> update procedure is that the Home Agent returns a different Mobile >> Network Prefix when the Mobile Router requests to renew a Mobile >> Network Prefix. Another way is that the Mobile Router indicates the >> release of the old Mobile Network Prefix and the request of a new >> Mobile Network Prefix by using two separate MOBILE_NETWORK_PREFIX6 >> attributes in one CFG_REQUEST payload. The Home Agent should return >> a new Mobile Network Prefix and confirm the release of the old Mobile >> Network Prefix by using two separate MOBILE_NETWORK_PREFIX6 >> attributes in one CFG_REPLY payload. >> >> To perform the Home Agent initiated Prefix update procedure, the Home >> Agent indicates the release of the old Mobile Network Prefix and the >> assignment of a new Mobile Network Prefix by using two separate >> MOBILE_NETWORK_PREFIX6 attributes in one CFG_REQUEST payload. In >> this case, the Mobile Node should confirm the assignment of the new >> Mobile Network Prefix and the release of the old Mobile Network >> Prefix by using two separate MOBILE_NETWORK_PREFIX6 attributes in one >> CFG_REPLY payload. > > Same questions as for previous section. Fan> The MN can use the BU message to de-reg the old MNP and register the new MNP with the HA. > Another comment: in this block, > it is quite obvious that there are no more two separate entities (IKE > and MIPv6), which obviously make the associated interface issues > disappear: you use IKE exchange payload as if they were sent by the > HA. They are not. They are sent by the IKE daemon on the HA. > Fan> I will reword it. My impression is that the interface between the IPSec and the MIP already needs to be defined; however, if we use DHCP-PD, then we also need to specify another interface between DHCP and MIP, which results in more complexity. > >> The NEMO Basic Support protocol [1] requires that the Home Agent >> check if a Mobile Network Prefix received in a Binding Update message >> is authorized to be used. To do so, the Home Agent can associate the >> mobile node identity used in the IKEv2 authentication process with >> the Home Network Prefix allocated. > > Easy for the IKE daemon but how will the HA get the information when the > MIPv6 MNP request will come. Fan> My impression is this could be implementation specific. There are drafts on PF_KEY extension as an interface between Mobile IPv6 and IPsec/IKE. I think this is an important issue, but may be out of scope of this draft. > >> In some deployment, the Homme Agent itself manages the allocation of >> Mobile Network Prefixes, for example, from a locally managed prefix >> pool. it is also possible that additional back-end servers are used >> for Mobile Network Prefix assignment. For example, the Home Agent >> can act as a DHCP Requesting Router and interact with a DHCP >> Delegating Router. > > In the end, this is the HA which will decide (i.e. ack or nack prefixes > in the MIPv6 message). Fan> Yes. > >> The security mechanism protecting the interaction >> between the Home Agent and such back-end servers could be generic >> security mechanisms, such as IPSec, or specific to the protocols used >> in between, such as DHCP authentication option. > > Does not belong here, IMHO. Fan> Yes. > >> Once allocated, the >> Mobile Network Prefix must not be assigned to a different Mobile >> Router until such Mobile Network Prefix is returned to the Home >> Agent. > > In you draft, this requires the prefix to be released both at IKEv2 and > MIPv6 level, doesn't it? Fan> Yes. Actually, to be more precise, the prefix is released at the IKEv2 level and the mobility states related to such prefix is updated at the MIP level if such states exist, e.g. when the MR attaches to a foreign link. > > From a global standpoint, i think the solution could work for simple > deployments with a single delegated prefix but it lacks the specific > details of how MIPv6 and IKE need to work together on both sides. Fan> Thanks for your comments. Your comments are very important and helpful. We still need to discuss about the multiple prefix/interface case and we will update the draft by providing more details on the interaction between MIPv6 and IKE. Thanks a lot. Sincerely, fan > > Note that my comments are only technical: I have no opinion WRT the use > of IKEv2 to delegate prefixes to a MR. I (still) mainly wonder about the > required interface between MIPv6 and IKE to do that ;-) > > Hope that helps, > > Cheers, > > a+ > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jul 9 11:02:53 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F20E73A6A9F; Wed, 9 Jul 2008 11:02:52 -0700 (PDT) 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 209E628C214 for ; Wed, 9 Jul 2008 11:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQ7EYr4G0DVv for ; Wed, 9 Jul 2008 11:02:51 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id BF6043A6A88 for ; Wed, 9 Jul 2008 11:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1215626583; x=1247162583; h=x-mimeole:content-class:mime-version:content-type: content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator: thread-topic:thread-index:references:from:to:cc: x-originalarrivaltime:x-ironport-av; z=X-MimeOLE:=20Produced=20By=20Microsoft=20Exchange=20V6.5 |Content-class:=20urn:content-classes:message |MIME-Version:=201.0|Content-Type:=20text/plain=3B=0D=0A =09charset=3D"us-ascii"|Content-Transfer-Encoding:=20quot ed-printable|Subject:=20RE:=20[MEXT]=20[mext]=20#11:=20De -registration=20when=20returning=20home=20[VijayDevarapal li=20]|Date:=20Wed,=209=20Jul=202008 =2011:03:01=20-0700|Message-ID:=20|In-Reply-To: =20|X-MS-Has-Attach:=20 |X-MS-TNEF-Correlator:=20|Thread-Topic:=20[MEXT]=20[mext] =20#11:=20De-registration=20when=20returning=20home=20[Vi jayDevarapalli=20]|Thread-Index:=20Ac jhR7gv2RIhnWx6SnC8ZZPUcCDGjQACuKaAAAXrj/AAB3kx+gAZNiCQ |References:=20<010801c8e16b$5c2889d0$7471510a@psl.local> =20|From:=20"Giaretta, =20Gerardo"=20|To:=20"Vijay=20Deva rapalli"=20,=0D=0A=20=20=20=20=20=20 =20=20"Benjamin=20Lim"=20|Cc:=20,=20 |X-OriginalArrivalTime:=2009=20Jul=202008=2018:03:01.0841 =20(UTC)=20FILETIME=3D[07254C10:01C8E1EE]|X-IronPort-AV: =20E=3DMcAfee=3Bi=3D"5200,2160,5335"=3B=20a=3D"4401571"; bh=dNVV5EAc1nVqTG6BfwAQdyA/pMdO8KTtig4Rwdf73S0=; b=dr/ajP7mgMGtOTQZ+pIJZXANxnVCnFgw9MvUB9upDZA8f9E3uZG8Jpfe tQHGBy+QF0iusZevezK3b20HRUAvaJsPy6KxKokGndDy5wfhErDuJFag7 FzgEWhTr2m+SvUnsTpmHRSPQSHMHNptrtr+DrjBjxXaAMTpStqAS0tECw s=; X-IronPort-AV: E=McAfee;i="5200,2160,5335"; a="4401571" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Jul 2008 11:03:03 -0700 Received: from msgtransport06.qualcomm.com (msgtransport06.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m69I321Y031074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 Jul 2008 11:03:02 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by msgtransport06.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m69I32vw022013; Wed, 9 Jul 2008 11:03:02 -0700 Received: from NAEX12.na.qualcomm.com ([129.46.51.247]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Jul 2008 11:03:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Jul 2008 11:03:01 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] Thread-Index: AcjhR7gv2RIhnWx6SnC8ZZPUcCDGjQACuKaAAAXrj/AAB3kx+gAZNiCQ References: <010801c8e16b$5c2889d0$7471510a@psl.local> From: "Giaretta, Gerardo" To: "Vijay Devarapalli" , "Benjamin Lim" X-OriginalArrivalTime: 09 Jul 2008 18:03:01.0841 (UTC) FILETIME=[07254C10:01C8E1EE] Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] 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, What do you mean by: "the MN can bind more than one care-of address to the home address"? Is it about MCoAs? If it is so, I think this is not correct. The MN can still be dual-radio, connect to the home link with if1 but keep the CoA of if2 in the binding. Obviously this implies that the if1 cannot be used with the HoA (as the HA is still defending the HoA), but the MN will send the dereg BU as soon as it wants to traffic to be redirected to if1. What is wrong with the following text which was proposed to the list some time ago? A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.1), when the mobile node detects that its home subnet prefix is again on-link. The mobile node SHOULD then send a Binding Update to its home agent, to instruct its home agent to no longer intercept or tunnel packets for it. Until the mobile node sends a de-registration Binding Update, it will not be able to send and receive packets using its home address from the home link. The home agent will continue to intercept all packets sent to the mobile's home address and tunnel to the previously registered care-of address. Gerardo > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Vijay Devarapalli > Sent: Tuesday, July 08, 2008 10:54 PM > To: Benjamin Lim > Cc: charliep@computer.org; mext@ietf.org > Subject: Re: [MEXT] [mext] #11: De-registration when returning home > [VijayDevarapalli ] > > On 7/8/08 7:27 PM, "Benjamin Lim" wrote: > > >> In case the mobile node has more than one interface and > >> can bind more than one care-of address to the home address, the > >> mobile MAY send a Binding Update to its home agent, to > >> instruct its > >> home agent to no longer intercept or tunnel packets for > >> it. > > [Ben] IMHO, this should also be a MUST. Base on the same logic as above. > > This is irrespective to whether MN is trying to achieve simultaneous > home > > and away or not. Regardless on whether if MN has one CoA or multiple > CoAs, > > when MN returns home, it would need to remove its associated CoA entry > from > > the HA. Hence, I do not see a reason why for one CoA MN MUST send BU, > but > > for multiple CoAs MN MAY send BU. > > The second part is intended to support the case where the MN may want to > continue using the interface with which it is attached to the visited link. > The binding stays active, while the MN is attaching to the home link with > one of the interfaces. It may decide at a later time if wants to use only > the interface with which it is attached to the home link. > > Any suggestions to improve the text to indicate the above is welcome. > > Vijay > > > > > Regards, > > Benjamin Lim > > > >> For more > >> information on the mobile node returning home procedure when there > >> are multiple care-of addresses, see [MCOA]. > >> > >> In the Informative references add, > >> > >> [MCOA] Wakikawa, S., Devarapalli, V., Ernst, T., and K. Nagami, > >> "Multiple Care-of Addresses Registration", Work in > >> Progress, May 2008. > >> > >> Hope this acceptable to all. > >> > >> Vijay > > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://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 Jul 9 11:11:42 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3493C3A6AA0; Wed, 9 Jul 2008 11:11:42 -0700 (PDT) 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 2706E3A6AAE for ; Wed, 9 Jul 2008 11:11:41 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYja+60uZXvY for ; Wed, 9 Jul 2008 11:11:39 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 869F93A6AA0 for ; Wed, 9 Jul 2008 11:11:39 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Jul 2008 14:11:50 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] Thread-Index: AcjhR7gv2RIhnWx6SnC8ZZPUcCDGjQACuKaAAAXrj/AAB3kx+gAZNiCQAABOELA= References: <010801c8e16b$5c2889d0$7471510a@psl.local> From: "Vijay Devarapalli" To: "Giaretta, Gerardo" , "Benjamin Lim" Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] 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 Gerardo, > What do you mean by: "the MN can bind more than one care-of address to > the home address"? Is it about MCoAs? If it is so, I think this is not > correct. I clarified later on in an email to Benjamin. It does not have to be about multiple care-of address registration. > The MN can still be dual-radio, connect to the home link with > if1 but keep the CoA of if2 in the binding. Obviously this > implies that > the if1 cannot be used with the HoA (as the HA is still defending the > HoA), but the MN will send the dereg BU as soon as it wants to traffic > to be redirected to if1. I agree with this. > What is wrong with the following text which was proposed to the list > some time ago? The text does not resolve the issue. It just describes what happens if the mobile node does not send a de-registration BU. IMO, that is not sufficient. Consider a mobile node with a single interface or a mobile node that is only capable of "single-radio" handover. This mobile node MUST send a de-registration BU as soon as it attaches to the home link. It does not have an option to delay sending the de-registration BU. I am trying to separate out the two and have two separate sentences. How about the following? A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.1), when the mobile node detects that its home subnet prefix is again on-link. In case the mobile node has only one interface active at any time, it MUST send a Binding Update to its home agent, to instruct its home agent to no longer intercept or tunnel packets for it. In case the mobile node has more than one interface active at a time, it MAY send a Binding Update to its home agent, to instruct its home agent to no longer intercept or tunnel packets for it. For more information on the mobile node returning home procedure when there are multiple care-of addresses, see [MCOA]. Vijay > > A mobile node detects that it has returned to its home > link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > The mobile node SHOULD then send a Binding Update to its > home agent, > to instruct its home agent to no longer intercept or > tunnel packets > for it. Until the mobile node sends a de-registration Binding > Update, > it will not be able to send and receive packets using its home > address from the home link. The home agent will continue to > intercept > all packets sent to the mobile's home address and tunnel to the > previously registered care-of address. > > Gerardo > > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf > Of > > Vijay Devarapalli > > Sent: Tuesday, July 08, 2008 10:54 PM > > To: Benjamin Lim > > Cc: charliep@computer.org; mext@ietf.org > > Subject: Re: [MEXT] [mext] #11: De-registration when returning home > > [VijayDevarapalli ] > > > > On 7/8/08 7:27 PM, "Benjamin Lim" > wrote: > > > > >> In case the mobile node has more than one interface and > > >> can bind more than one care-of address to the home > address, the > > >> mobile MAY send a Binding Update to its home agent, to > > >> instruct its > > >> home agent to no longer intercept or tunnel packets for > > >> it. > > > [Ben] IMHO, this should also be a MUST. Base on the same logic as > above. > > > This is irrespective to whether MN is trying to achieve > simultaneous > > home > > > and away or not. Regardless on whether if MN has one CoA or > multiple > > CoAs, > > > when MN returns home, it would need to remove its associated CoA > entry > > from > > > the HA. Hence, I do not see a reason why for one CoA MN MUST send > BU, > > but > > > for multiple CoAs MN MAY send BU. > > > > The second part is intended to support the case where the > MN may want > to > > continue using the interface with which it is attached to > the visited > link. > > The binding stays active, while the MN is attaching to the home link > with > > one of the interfaces. It may decide at a later time if wants to use > only > > the interface with which it is attached to the home link. > > > > Any suggestions to improve the text to indicate the above > is welcome. > > > > Vijay > > > > > > > > Regards, > > > Benjamin Lim > > > > > >> For more > > >> information on the mobile node returning home procedure when > there > > >> are multiple care-of addresses, see [MCOA]. > > >> > > >> In the Informative references add, > > >> > > >> [MCOA] Wakikawa, S., Devarapalli, V., Ernst, T., and > K. Nagami, > > >> "Multiple Care-of Addresses Registration", Work in > > >> Progress, May 2008. > > >> > > >> Hope this acceptable to all. > > >> > > >> Vijay > > > > > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://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 Jul 9 11:18:15 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C62828C21D; Wed, 9 Jul 2008 11:18:15 -0700 (PDT) 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 ECFD528C21D for ; Wed, 9 Jul 2008 11:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUj0f+DJTLkS for ; Wed, 9 Jul 2008 11:18:12 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 8D39C28C204 for ; Wed, 9 Jul 2008 11:18:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1215627505; x=1247163505; h=x-mimeole:content-class:mime-version:content-type: content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator: thread-topic:thread-index:references:from:to:cc: x-originalarrivaltime:x-ironport-av; z=X-MimeOLE:=20Produced=20By=20Microsoft=20Exchange=20V6.5 |Content-class:=20urn:content-classes:message |MIME-Version:=201.0|Content-Type:=20text/plain=3B=0D=0A =09charset=3D"us-ascii"|Content-Transfer-Encoding:=20quot ed-printable|Subject:=20RE:=20[MEXT]=20[mext]=20#11:=20De -registration=20when=20returning=20home=20[VijayDevarapal li=20]|Date:=20Wed,=209=20Jul=202008 =2011:18:23=20-0700|Message-ID:=20|In-Reply-To: =20|X-MS-Has-Attach:=20|X-MS-TNEF-Correlator: =20|Thread-Topic:=20[MEXT]=20[mext]=20#11:=20De-registrat ion=20when=20returning=20home=20[VijayDevarapalli=20]|Thread-Index:=20AcjhR7gv2RIhnWx6SnC8ZZPU cCDGjQACuKaAAAXrj/AAB3kx+gAZNiCQAABOELAAAF7pIA=3D=3D |References:=20<010801c8e16b$5c2889d0$7471510a@psl.local> =20=20=20|From:=20"Giaretta,=20Gerardo"=20|To:=20"Vijay=20Devarapalli"=20, =0D=0A=20=20=20=20=20=20=20=20"Benjamin=20Lim"=20|Cc:=20, =20|X-OriginalArrivalTime:=2009=20Jul=2020 08=2018:18:24.0173=20(UTC)=20FILETIME=3D[2CE5FDD0:01C8E1F 0]|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5200,2160,5335"=3B =20a=3D"4402131"; bh=5PEgc6aJFeHamVJxWi79ooE6J6/1ogiIX/hD9zj7hMM=; b=jIPb947EEtZIaVioKViRCYWjFnIKCXkGfAfNR3LDsF3FkcwRBrtQAE1E BXx+CV2A47N2qpTBs5GxtVfzWGuwGqncnPgyU/1acrOmOQE+OTaupZMFh rJljhScqAV1ikOSuVWeT2P30z7q72Is8ACtMjAdikxbB/5Kcmzu0n1l4s U=; X-IronPort-AV: E=McAfee;i="5200,2160,5335"; a="4402131" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Jul 2008 11:18:25 -0700 Received: from msgtransport06.qualcomm.com (msgtransport06.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m69IIOHJ014103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 Jul 2008 11:18:25 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by msgtransport06.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m69IIOEn026743; Wed, 9 Jul 2008 11:18:24 -0700 Received: from NAEX12.na.qualcomm.com ([129.46.51.247]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Jul 2008 11:18:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Jul 2008 11:18:23 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] Thread-Index: AcjhR7gv2RIhnWx6SnC8ZZPUcCDGjQACuKaAAAXrj/AAB3kx+gAZNiCQAABOELAAAF7pIA== References: <010801c8e16b$5c2889d0$7471510a@psl.local> From: "Giaretta, Gerardo" To: "Vijay Devarapalli" , "Benjamin Lim" X-OriginalArrivalTime: 09 Jul 2008 18:18:24.0173 (UTC) FILETIME=[2CE5FDD0:01C8E1F0] Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] 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 sounds better to me. I'd like still to clarify what happens when the UE does not send the BU. What about this: A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.1), when the mobile node detects that its home subnet prefix is again on-link. In case the mobile node has only one interface active at any time, it MUST send a Binding Update to its home agent, to instruct its home agent to no longer intercept or tunnel packets for it. In case the mobile node has more than one interface active at a time, it MAY send a Binding Update to its home agent, to instruct its home agent to no longer intercept or tunnel packets for it. Until the mobile node sends a de-registration Binding Update, it will not be able to send and receive packets using its home address from the home link. The home agent will continue to intercept all packets sent to the mobile's home address and tunnel to the previously registered care-of address. Gerardo > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay@wichorus.com] > Sent: Wednesday, July 09, 2008 11:12 AM > To: Giaretta, Gerardo; Benjamin Lim > Cc: charliep@computer.org; mext@ietf.org > Subject: RE: [MEXT] [mext] #11: De-registration when returning home > [VijayDevarapalli ] > > Hi Gerardo, > > > What do you mean by: "the MN can bind more than one care-of address to > > the home address"? Is it about MCoAs? If it is so, I think this is not > > correct. > > I clarified later on in an email to Benjamin. It does not have to be > about multiple care-of address registration. > > > The MN can still be dual-radio, connect to the home link with > > if1 but keep the CoA of if2 in the binding. Obviously this > > implies that > > the if1 cannot be used with the HoA (as the HA is still defending the > > HoA), but the MN will send the dereg BU as soon as it wants to traffic > > to be redirected to if1. > > I agree with this. > > > What is wrong with the following text which was proposed to the list > > some time ago? > > The text does not resolve the issue. It just describes what happens if > the mobile node does not send a de-registration BU. IMO, that is not > sufficient. > > Consider a mobile node with a single interface or a mobile node that is > only capable of "single-radio" handover. This mobile node MUST send a > de-registration BU as soon as it attaches to the home link. It does not > have an option to delay sending the de-registration BU. > > I am trying to separate out the two and have two separate sentences. > > How about the following? > > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > In case the mobile node has only one interface active at any time, > it MUST send a Binding Update to its home agent, to instruct its home > > agent to no longer intercept or tunnel packets for it. In case the > mobile node has more than one interface active at a time, it MAY > send a Binding Update to its home agent, to instruct its home agent > to no longer intercept or tunnel packets for it. For more information > > on the mobile node returning home procedure when there are multiple > care-of addresses, see [MCOA]. > > > Vijay > > > > > A mobile node detects that it has returned to its home > > link through > > the movement detection algorithm in use (Section 11.5.1), when the > > mobile node detects that its home subnet prefix is again on-link. > > The mobile node SHOULD then send a Binding Update to its > > home agent, > > to instruct its home agent to no longer intercept or > > tunnel packets > > for it. Until the mobile node sends a de-registration Binding > > Update, > > it will not be able to send and receive packets using its home > > address from the home link. The home agent will continue to > > intercept > > all packets sent to the mobile's home address and tunnel to the > > previously registered care-of address. > > > > Gerardo > > > > > -----Original Message----- > > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf > > Of > > > Vijay Devarapalli > > > Sent: Tuesday, July 08, 2008 10:54 PM > > > To: Benjamin Lim > > > Cc: charliep@computer.org; mext@ietf.org > > > Subject: Re: [MEXT] [mext] #11: De-registration when returning home > > > [VijayDevarapalli ] > > > > > > On 7/8/08 7:27 PM, "Benjamin Lim" > > wrote: > > > > > > >> In case the mobile node has more than one interface and > > > >> can bind more than one care-of address to the home > > address, the > > > >> mobile MAY send a Binding Update to its home agent, to > > > >> instruct its > > > >> home agent to no longer intercept or tunnel packets for > > > >> it. > > > > [Ben] IMHO, this should also be a MUST. Base on the same logic as > > above. > > > > This is irrespective to whether MN is trying to achieve > > simultaneous > > > home > > > > and away or not. Regardless on whether if MN has one CoA or > > multiple > > > CoAs, > > > > when MN returns home, it would need to remove its associated CoA > > entry > > > from > > > > the HA. Hence, I do not see a reason why for one CoA MN MUST send > > BU, > > > but > > > > for multiple CoAs MN MAY send BU. > > > > > > The second part is intended to support the case where the > > MN may want > > to > > > continue using the interface with which it is attached to > > the visited > > link. > > > The binding stays active, while the MN is attaching to the home link > > with > > > one of the interfaces. It may decide at a later time if wants to use > > only > > > the interface with which it is attached to the home link. > > > > > > Any suggestions to improve the text to indicate the above > > is welcome. > > > > > > Vijay > > > > > > > > > > > Regards, > > > > Benjamin Lim > > > > > > > >> For more > > > >> information on the mobile node returning home procedure when > > there > > > >> are multiple care-of addresses, see [MCOA]. > > > >> > > > >> In the Informative references add, > > > >> > > > >> [MCOA] Wakikawa, S., Devarapalli, V., Ernst, T., and > > K. Nagami, > > > >> "Multiple Care-of Addresses Registration", Work in > > > >> Progress, May 2008. > > > >> > > > >> Hope this acceptable to all. > > > >> > > > >> Vijay > > > > > > > > > > > > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://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 Jul 9 11:24:55 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C76E528C247; Wed, 9 Jul 2008 11:24:55 -0700 (PDT) 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 D6D3028C247 for ; Wed, 9 Jul 2008 11:24:54 -0700 (PDT) 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 BC0JcIs-OYsq for ; Wed, 9 Jul 2008 11:24:53 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 7D79E28C19D for ; Wed, 9 Jul 2008 11:24:53 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Jul 2008 14:25:04 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] Thread-Index: AcjhR7gv2RIhnWx6SnC8ZZPUcCDGjQACuKaAAAXrj/AAB3kx+gAZNiCQAABOELAAAF7pIAAAVTGg References: <010801c8e16b$5c2889d0$7471510a@psl.local> From: "Vijay Devarapalli" To: "Giaretta, Gerardo" , "Benjamin Lim" Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] 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 Fine with me. Vijay > -----Original Message----- > From: Giaretta, Gerardo [mailto:gerardog@qualcomm.com] > Sent: Wednesday, July 09, 2008 11:18 AM > To: Vijay Devarapalli; Benjamin Lim > Cc: charliep@computer.org; mext@ietf.org > Subject: RE: [MEXT] [mext] #11: De-registration when > returning home [VijayDevarapalli ] > > This sounds better to me. I'd like still to clarify what happens when > the UE does not send the BU. What about this: > > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > In case the mobile node has only one interface active at any time, > it MUST send a Binding Update to its home agent, to > instruct its home > agent to no longer intercept or tunnel packets for it. In > case the > mobile node has more than one interface active at a time, it MAY > send a Binding Update to its home agent, to instruct its > home agent > to no longer intercept or tunnel packets for it. Until the mobile > node > sends a de-registration Binding Update, it will not be able to send > and > receive packets using its home address from the home link. The home > agent > will continue to intercept all packets sent to the mobile's home > address > and tunnel to the previously registered care-of address. > > Gerardo > > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijay@wichorus.com] > > Sent: Wednesday, July 09, 2008 11:12 AM > > To: Giaretta, Gerardo; Benjamin Lim > > Cc: charliep@computer.org; mext@ietf.org > > Subject: RE: [MEXT] [mext] #11: De-registration when returning home > > [VijayDevarapalli ] > > > > Hi Gerardo, > > > > > What do you mean by: "the MN can bind more than one > care-of address > to > > > the home address"? Is it about MCoAs? If it is so, I think this is > not > > > correct. > > > > I clarified later on in an email to Benjamin. It does not have to be > > about multiple care-of address registration. > > > > > The MN can still be dual-radio, connect to the home link with > > > if1 but keep the CoA of if2 in the binding. Obviously this > > > implies that > > > the if1 cannot be used with the HoA (as the HA is still defending > the > > > HoA), but the MN will send the dereg BU as soon as it wants to > traffic > > > to be redirected to if1. > > > > I agree with this. > > > > > What is wrong with the following text which was proposed > to the list > > > some time ago? > > > > The text does not resolve the issue. It just describes what > happens if > > the mobile node does not send a de-registration BU. IMO, that is not > > sufficient. > > > > Consider a mobile node with a single interface or a mobile node that > is > > only capable of "single-radio" handover. This mobile node > MUST send a > > de-registration BU as soon as it attaches to the home link. It does > not > > have an option to delay sending the de-registration BU. > > > > I am trying to separate out the two and have two separate sentences. > > > > How about the following? > > > > A mobile node detects that it has returned to its home > link through > > the movement detection algorithm in use (Section > 11.5.1), when the > > mobile node detects that its home subnet prefix is again on-link. > > In case the mobile node has only one interface active at > any time, > > it MUST send a Binding Update to its home agent, to instruct its > home > > > > agent to no longer intercept or tunnel packets for it. > In case the > > mobile node has more than one interface active at a time, it MAY > > send a Binding Update to its home agent, to instruct its > home agent > > to no longer intercept or tunnel packets for it. For more > information > > > > on the mobile node returning home procedure when there > are multiple > > care-of addresses, see [MCOA]. > > > > > > Vijay > > > > > > > > A mobile node detects that it has returned to its home > > > link through > > > the movement detection algorithm in use (Section 11.5.1), when > the > > > mobile node detects that its home subnet prefix is again > on-link. > > > The mobile node SHOULD then send a Binding Update to its > > > home agent, > > > to instruct its home agent to no longer intercept or > > > tunnel packets > > > for it. Until the mobile node sends a de-registration Binding > > > Update, > > > it will not be able to send and receive packets using its home > > > address from the home link. The home agent will continue to > > > intercept > > > all packets sent to the mobile's home address and > tunnel to the > > > previously registered care-of address. > > > > > > Gerardo > > > > > > > -----Original Message----- > > > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf > > > Of > > > > Vijay Devarapalli > > > > Sent: Tuesday, July 08, 2008 10:54 PM > > > > To: Benjamin Lim > > > > Cc: charliep@computer.org; mext@ietf.org > > > > Subject: Re: [MEXT] [mext] #11: De-registration when returning > home > > > > [VijayDevarapalli ] > > > > > > > > On 7/8/08 7:27 PM, "Benjamin Lim" > > > > wrote: > > > > > > > > >> In case the mobile node has more than one interface and > > > > >> can bind more than one care-of address to the home > > > address, the > > > > >> mobile MAY send a Binding Update to its home agent, to > > > > >> instruct its > > > > >> home agent to no longer intercept or tunnel packets for > > > > >> it. > > > > > [Ben] IMHO, this should also be a MUST. Base on the same logic > as > > > above. > > > > > This is irrespective to whether MN is trying to achieve > > > simultaneous > > > > home > > > > > and away or not. Regardless on whether if MN has one CoA or > > > multiple > > > > CoAs, > > > > > when MN returns home, it would need to remove its > associated CoA > > > entry > > > > from > > > > > the HA. Hence, I do not see a reason why for one CoA MN MUST > send > > > BU, > > > > but > > > > > for multiple CoAs MN MAY send BU. > > > > > > > > The second part is intended to support the case where the > > > MN may want > > > to > > > > continue using the interface with which it is attached to > > > the visited > > > link. > > > > The binding stays active, while the MN is attaching to the home > link > > > with > > > > one of the interfaces. It may decide at a later time if wants to > use > > > only > > > > the interface with which it is attached to the home link. > > > > > > > > Any suggestions to improve the text to indicate the above > > > is welcome. > > > > > > > > Vijay > > > > > > > > > > > > > > Regards, > > > > > Benjamin Lim > > > > > > > > > >> For more > > > > >> information on the mobile node returning home > procedure when > > > there > > > > >> are multiple care-of addresses, see [MCOA]. > > > > >> > > > > >> In the Informative references add, > > > > >> > > > > >> [MCOA] Wakikawa, S., Devarapalli, V., Ernst, T., and > > > K. Nagami, > > > > >> "Multiple Care-of Addresses Registration", Work in > > > > >> Progress, May 2008. > > > > >> > > > > >> Hope this acceptable to all. > > > > >> > > > > >> Vijay > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > MEXT mailing list > > > > MEXT@ietf.org > > > > https://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 Jul 9 11:26:35 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4764B28C213; Wed, 9 Jul 2008 11:26:35 -0700 (PDT) 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 854243A6963 for ; Wed, 9 Jul 2008 11:26:34 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zssv9W9ba-H for ; Wed, 9 Jul 2008 11:26:33 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 7175E28C268 for ; Wed, 9 Jul 2008 11:25:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,332,1212364800"; d="scan'208";a="50877425" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 09 Jul 2008 18:26:10 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m69IQAQk016355; Wed, 9 Jul 2008 11:26:10 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m69IQAAl024612; Wed, 9 Jul 2008 18:26:10 GMT Date: Wed, 9 Jul 2008 11:26:09 -0700 (PDT) From: Sri Gundavelli To: "Giaretta, Gerardo" In-Reply-To: Message-ID: References: <010801c8e16b$5c2889d0$7471510a@psl.local> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=490; t=1215627970; x=1216491970; c=relaxed/simple; s=sjdkim1004; 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]=20[mext]=20#11=3A=20De-registrat ion=20when=20returning=20home=0A=20[VijayDevarapalli=20] |Sender:=20; bh=MycoczbDPBjXmDWylEdYLctk2HvFy2QyYmvxkc29ikk=; b=JRRXiB1j88R5HMJk2/FubtIjHY8HZrjrp0sPu4Dv3nYQ9+Haop0dIElK3o Dog+vmFzpxPcvEtzDi/q8CcTJJ7omm004DCexqLNedKOb8nG/PnRr5aZItaU yIffPGfQjTJNQxx3Kk+qir3RJpgYRHM5DiFp3Xp97o76FOSrI2M5Q=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Just one comment. > Until the mobile node sends a de-registration Binding Update, it will > not > be able to send and receive packets using its home address from the home > link. I have a problem with this. As Pascal and Rajiv pointed out, nothing really stops the MN, which is the legitimate address owner to reclaim and start using its home address on the home link and without sending a BU with life=0. This has to confirm to the override flag purpose in ND. Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jul 9 11:32:12 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEF143A6B3E; Wed, 9 Jul 2008 11:32:12 -0700 (PDT) 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 297E028C204 for ; Wed, 9 Jul 2008 11:32:11 -0700 (PDT) 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 tcV2Ek+Gzyuf for ; Wed, 9 Jul 2008 11:32:10 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 23CCA28C203 for ; Wed, 9 Jul 2008 11:32:09 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Jul 2008 14:32:20 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] Thread-Index: Acjh8UOe+wBev0J+TPu/GQWeOzUX4QAAEn+Q References: <010801c8e16b$5c2889d0$7471510a@psl.local> From: "Vijay Devarapalli" To: "Sri Gundavelli" , "Giaretta, Gerardo" Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] 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, We need to have a discussion on whether a neighbor advertisement with the override flag set can convince the home agent to remove the proxy neighbor cache entry for the home address. The proxy neighbor cache entry was created as a result for processing a binding update. I think only another binding update should remove it. But that is a separate discussion. Perhaps, a minor fix will satisfy you. How about the following? A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.1), when the mobile node detects that its home subnet prefix is again on-link. In case the mobile node has only one interface active at any time, it MUST send a Binding Update to its home agent, to instruct its home agent to no longer intercept or tunnel packets for it. In case the mobile node has more than one interface active at a time, it MAY send a Binding Update to its home agent, to instruct its home agent to no longer intercept or tunnel packets for it. Until the mobile node sends a de-registration Binding Update, it may not be able to send and receive packets using its home address from the home link. The home agent will continue to intercept all packets sent to the mobile node's home address, as long as the home agent is proxying for the home address. Two modifications. Replaced "..it will not be able to.." with "..it may not be able to.." and re-wrote the last sentence. Vijay > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com] > Sent: Wednesday, July 09, 2008 11:26 AM > To: Giaretta, Gerardo > Cc: Vijay Devarapalli; Benjamin Lim; charliep@computer.org; > mext@ietf.org > Subject: Re: [MEXT] [mext] #11: De-registration when > returning home [VijayDevarapalli ] > > > Just one comment. > > > > Until the mobile node sends a de-registration Binding > Update, it will > > not > > be able to send and receive packets using its home address > from the home > > link. > > I have a problem with this. As Pascal and Rajiv pointed out, nothing > really stops the MN, which is the legitimate address owner to reclaim > and start using its home address on the home link and without sending > a BU with life=0. This has to confirm to the override flag purpose in > ND. > > Sri > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jul 9 11:52:06 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2521F3A6846; Wed, 9 Jul 2008 11:52:06 -0700 (PDT) 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 18D213A695C for ; Wed, 9 Jul 2008 11:52:05 -0700 (PDT) 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 PjCPbXtCZTv9 for ; Wed, 9 Jul 2008 11:52:04 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id E1E5C3A680C for ; Wed, 9 Jul 2008 11:52:03 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id E28A0C8046 for ; Wed, 9 Jul 2008 14:52:12 -0400 (EDT) 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 20074-11 for ; Wed, 9 Jul 2008 14:52:10 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 9 Jul 2008 14:52:10 -0400 (EDT) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jul 2008 14:52:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Jul 2008 14:53:55 -0400 Message-ID: <4D35478224365146822AE9E3AD4A2666031F612B@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [mext] #11: De-registration when returning home[VijayDevarapalli ] Thread-Index: Acjh8UOe+wBev0J+TPu/GQWeOzUX4QAAEn+QAAB8HaA= From: "Koodli, Rajeev" To: "Vijay Devarapalli" , "Sri Gundavelli" , "Giaretta, Gerardo" X-OriginalArrivalTime: 09 Jul 2008 18:52:10.0288 (UTC) FILETIME=[E48E9B00:01C8E1F4] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home[VijayDevarapalli ] 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 see more than one issue here :) 1. HA to stop proxying. Of course the Dereg-BU is supposed to do this. However, other nodes on the link will still have their NCE pointing to the HA. This leads me to suggest that the MN MUST send an NA (with 'O'=1) on the _home link only_ to stop the HA from proxying. ND has link scope only and does not affect other links with which the MN may be connected to different visited networks (at the same time that it is connected to the home link using a different interface). 2. The MN SHOULD send a Dereg-BU, again on that home link where it does not wish to have the HA forward packets to the CoA anymore. This should allow it to maintain CoA bindings on other links. 3. When the MN returns home, we should have a consistent semantics about de-registration regardless of other networks the MN may be connected to. Limiting the actions to a) NA ('O'=1), followed by, b) Dereg-BU on the particular home link, I believe we can achieve that. -Rajeev > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Vijay Devarapalli > Sent: Wednesday, July 09, 2008 11:32 AM > To: Sri Gundavelli; Giaretta, Gerardo > Cc: charliep@computer.org; mext@ietf.org > Subject: Re: [MEXT] [mext] #11: De-registration when returning > home[VijayDevarapalli ] > > Hi Sri, > > We need to have a discussion on whether a neighbor advertisement with > the override flag set can convince the home agent to remove the proxy > neighbor cache entry for the home address. The proxy neighbor cache > entry was created as a result for processing a binding update. I think > only another binding update should remove it. But that is a separate > discussion. > > Perhaps, a minor fix will satisfy you. How about the following? > > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > In case the mobile node has only one interface active at any time, > it MUST send a Binding Update to its home agent, to instruct its home > agent to no longer intercept or tunnel packets for it. In case the > mobile node has more than one interface active at a time, it MAY > send a Binding Update to its home agent, to instruct its home agent > to no longer intercept or tunnel packets for it. Until the mobile > node sends a de-registration Binding Update, it may not be able to > send and receive packets using its home address from the home link. > The home agent will continue to intercept all packets sent to the > mobile node's home address, as long as the home agent is proxying > for the home address. > > Two modifications. Replaced "..it will not be able to.." with "..it may > not be able to.." and re-wrote the last sentence. > > Vijay > > > > -----Original Message----- > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > Sent: Wednesday, July 09, 2008 11:26 AM > > To: Giaretta, Gerardo > > Cc: Vijay Devarapalli; Benjamin Lim; charliep@computer.org; > > mext@ietf.org > > Subject: Re: [MEXT] [mext] #11: De-registration when > > returning home [VijayDevarapalli ] > > > > > > Just one comment. > > > > > > > Until the mobile node sends a de-registration Binding > > Update, it will > > > not > > > be able to send and receive packets using its home address > > from the home > > > link. > > > > I have a problem with this. As Pascal and Rajiv pointed out, nothing > > really stops the MN, which is the legitimate address owner to reclaim > > and start using its home address on the home link and without sending > > a BU with life=0. This has to confirm to the override flag purpose in > > ND. > > > > Sri > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://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 Jul 9 11:54:16 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D74428C268; Wed, 9 Jul 2008 11:54:16 -0700 (PDT) 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 484B028C26B for ; Wed, 9 Jul 2008 11:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTySgcFGZeC6 for ; Wed, 9 Jul 2008 11:54:14 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 2D9E328C268 for ; Wed, 9 Jul 2008 11:54:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1215629667; x=1247165667; h=x-mimeole:content-class:mime-version:content-type: content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator: thread-topic:thread-index:references:from:to:cc: x-originalarrivaltime:x-ironport-av; z=X-MimeOLE:=20Produced=20By=20Microsoft=20Exchange=20V6.5 |Content-class:=20urn:content-classes:message |MIME-Version:=201.0|Content-Type:=20text/plain=3B=0D=0A =09charset=3D"us-ascii"|Content-Transfer-Encoding:=20quot ed-printable|Subject:=20RE:=20[MEXT]=20[mext]=20#11:=20De -registration=20when=20returning=20home=20[VijayDevarapal li=20]|Date:=20Wed,=209=20Jul=202008 =2011:54:24=20-0700|Message-ID:=20|In-Reply-To: =20|X-MS-Has-Attach:=20|X-MS-TNEF-Correlator: =20|Thread-Topic:=20[MEXT]=20[mext]=20#11:=20De-registrat ion=20when=20returning=20home=20[VijayDevarapalli=20]|Thread-Index:=20Acjh8UOe+wBev0J+TPu/GQWe OzUX4QAAEn+QAADZimA=3D|References:=20<010801c8e16b$5c2889 d0$7471510a@psl.local>=20=20=20=20=20=20 |From:=20"Giaretta,=20Gerardo"=20 |To:=20"Vijay=20Devarapalli"=20,=0D =0A=20=20=20=20=20=20=20=20"Sri=20Gundavelli"=20|Cc:=20"Benjamin=20Lim"=20,=20,=0D=0A=20=20=20 =20=20=20=20=20|X-OriginalArrivalTime:=200 9=20Jul=202008=2018:54:25.0773=20(UTC)=20FILETIME=3D[354F F9D0:01C8E1F5]|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5200,21 60,5335"=3B=20a=3D"4403394"; bh=GFKXoDaEh0sJThr9P343eaeP7FGYr7UwvvpkFNdqs1o=; b=pjaC+u8lNMY9BtMGrTiNYPup2cbVx16dHpvK0SBJtuouwAhrM0jgI8xX 6SuUne25hAL7XXxWU30HSYO52vQid4/9h8w0qirv8mDjtCTeGbIb9rdLX 7whmmXpMQAPZjzJj0UHWwSP2TsY4gR/R1BeEJypXxs8ON/Q5YpR/hMJqN A=; X-IronPort-AV: E=McAfee;i="5200,2160,5335"; a="4403394" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Jul 2008 11:54:26 -0700 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m69IsQdM019553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 Jul 2008 11:54:26 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m69IsPln007472; Wed, 9 Jul 2008 11:54:26 -0700 Received: from NAEX12.na.qualcomm.com ([129.46.51.247]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Jul 2008 11:54:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Jul 2008 11:54:24 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] Thread-Index: Acjh8UOe+wBev0J+TPu/GQWeOzUX4QAAEn+QAADZimA= References: <010801c8e16b$5c2889d0$7471510a@psl.local> From: "Giaretta, Gerardo" To: "Vijay Devarapalli" , "Sri Gundavelli" X-OriginalArrivalTime: 09 Jul 2008 18:54:25.0773 (UTC) FILETIME=[354FF9D0:01C8E1F5] Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] 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 is also fine with me. I also agree with Vijay that only another binding update should remove the state at the HA about intercepting packets. But this may be another issue For me we can close this issue Thanks Gerardo > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay@wichorus.com] > Sent: Wednesday, July 09, 2008 11:32 AM > To: Sri Gundavelli; Giaretta, Gerardo > Cc: Benjamin Lim; charliep@computer.org; mext@ietf.org > Subject: RE: [MEXT] [mext] #11: De-registration when returning home > [VijayDevarapalli ] > > Hi Sri, > > We need to have a discussion on whether a neighbor advertisement with > the override flag set can convince the home agent to remove the proxy > neighbor cache entry for the home address. The proxy neighbor cache > entry was created as a result for processing a binding update. I think > only another binding update should remove it. But that is a separate > discussion. > > Perhaps, a minor fix will satisfy you. How about the following? > > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > In case the mobile node has only one interface active at any time, > it MUST send a Binding Update to its home agent, to instruct its home > agent to no longer intercept or tunnel packets for it. In case the > mobile node has more than one interface active at a time, it MAY > send a Binding Update to its home agent, to instruct its home agent > to no longer intercept or tunnel packets for it. Until the mobile > node sends a de-registration Binding Update, it may not be able to > send and receive packets using its home address from the home link. > The home agent will continue to intercept all packets sent to the > mobile node's home address, as long as the home agent is proxying > for the home address. > > Two modifications. Replaced "..it will not be able to.." with "..it may > not be able to.." and re-wrote the last sentence. > > Vijay > > > > -----Original Message----- > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > Sent: Wednesday, July 09, 2008 11:26 AM > > To: Giaretta, Gerardo > > Cc: Vijay Devarapalli; Benjamin Lim; charliep@computer.org; > > mext@ietf.org > > Subject: Re: [MEXT] [mext] #11: De-registration when > > returning home [VijayDevarapalli ] > > > > > > Just one comment. > > > > > > > Until the mobile node sends a de-registration Binding > > Update, it will > > > not > > > be able to send and receive packets using its home address > > from the home > > > link. > > > > I have a problem with this. As Pascal and Rajiv pointed out, nothing > > really stops the MN, which is the legitimate address owner to reclaim > > and start using its home address on the home link and without sending > > a BU with life=0. This has to confirm to the override flag purpose in > > ND. > > > > Sri > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jul 9 11:58:44 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E532828C26D; Wed, 9 Jul 2008 11:58:43 -0700 (PDT) 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 4463828C26D for ; Wed, 9 Jul 2008 11:58:42 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAs9anb9c6iC for ; Wed, 9 Jul 2008 11:58:41 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 4DA1428C267 for ; Wed, 9 Jul 2008 11:58:41 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Jul 2008 14:58:52 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-00.txt Thread-Index: AcjhJ8uxe90831gaTNy4c+L6f3TUhQAzYoHg References: <20080706174502.6A6393A68F3@core3.amsl.com> From: "Vijay Devarapalli" To: "fan zhao" Cc: mext@ietf.org Subject: Re: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-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 Fan, I prefer using the Binding Update/Binding Ack exchange for assigning a mobile network prefix to the mobile router instead of defining an IKEv2 configuration payload for this, unless there are some significant advantages to use IKEv2. Are there any? draft-zhao-mext-mnp-ikev2-00.txt does not talk about the advantages of using IKEv2 configuration payloads over BU/BAck exchange. Vijay > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of fan zhao > Sent: Tuesday, July 08, 2008 11:24 AM > To: mext@ietf.org > Subject: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-00.txt > > Hi, > > We have submitted a draft on using IKEv2 to assign a Mobile Network > Prefix to the Mobile Router. Comments, questions and suggestions > are highly appreciated. > Thanks. > > BR, > Fan > > > ---------- Forwarded message ---------- > From: > Date: 2008/7/6 > Subject: I-D Action:draft-zhao-mext-mnp-ikev2-00.txt > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > Title : IKEv2 based Mobile Network Prefix Assignment > Author(s) : F. Zhao, et al. > Filename : draft-zhao-mext-mnp-ikev2-00.txt > Pages : 13 > Date : 2008-07-06 > > This document proposes a mechanism for the Mobile Router to > dynamically obtain the Mobile Network Prefix through IKEv2. The > mechanisms to renew, release and update the allocated Mobile Network > Prefixes are also described. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-zhao-mext-mnp-ikev2-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://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 Jul 9 12:05:49 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAE643A697A; Wed, 9 Jul 2008 12:05:48 -0700 (PDT) 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 3BD083A67B0 for ; Wed, 9 Jul 2008 12:05:47 -0700 (PDT) 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 KqXpvcBVyRhZ for ; Wed, 9 Jul 2008 12:05:46 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 1DC043A6B44 for ; Wed, 9 Jul 2008 12:05:44 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Jul 2008 15:05:54 -0400 Message-ID: In-Reply-To: <4D35478224365146822AE9E3AD4A2666031F612B$0001@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [mext] #11: De-registration when returning home[VijayDevarapalli ] Thread-Index: Acjh8UOe+wBev0J+TPu/GQWeOzUX4QAAEn+QAAB8HaAAAMC20A== References: <4D35478224365146822AE9E3AD4A2666031F612B$0001@exchtewks3.starentnetworks.com> From: "Vijay Devarapalli" To: "Koodli, Rajeev" , "Sri Gundavelli" , "Giaretta, Gerardo" Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home[VijayDevarapalli ] 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 Rajeev, > 1. HA to stop proxying. Of course the Dereg-BU is supposed to do this. > However, other nodes on the link will still have their NCE pointing to > the HA. This leads me to suggest that the MN MUST send an NA (with > 'O'=1) on the _home link only_ to stop the HA from proxying. > ND has link > scope only and does not affect other links with which the MN may be > connected to different visited networks (at the same time that it is > connected to the home link using a different interface). RFC 3775 already says that the mobile node should sent a Neighbor Advertisement with the 'O' flag set after it receives the binding ack from the home agent. After receiving the Binding Acknowledgement for its Binding Update to its home agent, the mobile node MUST multicast onto the home link (to the all-nodes multicast address) a Neighbor Advertisement [12], to advertise the mobile node's own link-layer address for its own home address. The Target Address in this Neighbor Advertisement MUST be set to the mobile node's home address, and the Advertisement MUST include a Target Link-layer Address option specifying the mobile node's link-layer address. The mobile node MUST multicast such a Neighbor Advertisement for each of its home addresses, as defined by the current on-link prefixes, including its link-local address and site-local address. The Solicited Flag (S) in these Advertisements MUST NOT be set, since they were not solicited by any Neighbor Solicitation. The Override Flag (O) in these Advertisements MUST be set, indicating that the Advertisements SHOULD override any existing Neighbor Cache entries at any node receiving them. > 3. When the MN returns home, we should have a consistent > semantics about > de-registration regardless of other networks the MN may be > connected to. > Limiting the actions to a) NA ('O'=1), followed by, b) Dereg-BU on the > particular home link, I believe we can achieve that. Currently, RFC 3775 specifies b) followed by a). For changing the order, we might need a separate discussion. Not on this thread. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jul 9 12:11:49 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D37493A6921; Wed, 9 Jul 2008 12:11:49 -0700 (PDT) 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 3B1B43A6929 for ; Wed, 9 Jul 2008 12:11:49 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDBtmMp5C4Fn for ; Wed, 9 Jul 2008 12:11:48 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id EB49D3A6921 for ; Wed, 9 Jul 2008 12:11:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,332,1212364800"; d="scan'208";a="50901688" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 09 Jul 2008 19:11:48 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m69JBmLA009080; Wed, 9 Jul 2008 12:11:48 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m69JBmqr005622; Wed, 9 Jul 2008 19:11:48 GMT Date: Wed, 9 Jul 2008 12:11:47 -0700 (PDT) From: Sri Gundavelli To: Vijay Devarapalli In-Reply-To: Message-ID: References: <010801c8e16b$5c2889d0$7471510a@psl.local> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3315; t=1215630708; x=1216494708; c=relaxed/simple; s=sjdkim1004; 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]=20[mext]=20#11=3A=20De-registrat ion=20when=20returning=20home=0A=20[VijayDevarapalli=20] |Sender:=20; bh=0lDB3AZFixqPzyJdIbFDHO8Io2E10E49n+chgVylNCY=; b=jFpT8JVrRTsWLx6/DTgMWMjryMv6i7BEo/C3YAnzOtWoKaeW1zYbVJMr6s NGkinvgW8Ojux5LpwquGnTuC1K0sgHqjxFIAMH8umbWlxbOoEDueh4yNEvml RmA3k34wgDlOm2dHjkV8OupD06Nwbz9WJSPAGFogQ7D/KsvZKfhso=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Wed, 9 Jul 2008, Vijay Devarapalli wrote: > Hi Sri, > > We need to have a discussion on whether a neighbor advertisement with > the override flag set can convince the home agent to remove the proxy > neighbor cache entry for the home address. The proxy neighbor cache > entry was created as a result for processing a binding update. I think > only another binding update should remove it. But that is a separate > discussion. I generally agree to the point that a state that was created by a BU, should be again removed using the same BU. I agree in principle. But, if the HA cannot defend the address any more, the BU should be removed. If ND is allowing the MN to reclaim the address, the state that is left on the HA is an inconsistent state and it needs to be cleaned up. Yes, this requires more discussion. Below text seems ok to me, except the new concept of multiple interface MN in the context of 3775. I'd simply state, "if the MN wants to use the HoA on the home link, it MUST send a dereg" ...., from the MIP perspective we can require that. From HA perspective in the context of ND, what HA should do if the address is taken over, we need to discuss further, as say above. Sri > > Perhaps, a minor fix will satisfy you. How about the following? > > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > In case the mobile node has only one interface active at any time, > it MUST send a Binding Update to its home agent, to instruct its home > agent to no longer intercept or tunnel packets for it. In case the > mobile node has more than one interface active at a time, it MAY > send a Binding Update to its home agent, to instruct its home agent > to no longer intercept or tunnel packets for it. Until the mobile > node sends a de-registration Binding Update, it may not be able to > send and receive packets using its home address from the home link. > The home agent will continue to intercept all packets sent to the > mobile node's home address, as long as the home agent is proxying > for the home address. > > Two modifications. Replaced "..it will not be able to.." with "..it may > not be able to.." and re-wrote the last sentence. > > Vijay > > >> -----Original Message----- >> From: Sri Gundavelli [mailto:sgundave@cisco.com] >> Sent: Wednesday, July 09, 2008 11:26 AM >> To: Giaretta, Gerardo >> Cc: Vijay Devarapalli; Benjamin Lim; charliep@computer.org; >> mext@ietf.org >> Subject: Re: [MEXT] [mext] #11: De-registration when >> returning home [VijayDevarapalli ] >> >> >> Just one comment. >> >> >>> Until the mobile node sends a de-registration Binding >> Update, it will >>> not >>> be able to send and receive packets using its home address >> from the home >>> link. >> >> I have a problem with this. As Pascal and Rajiv pointed out, nothing >> really stops the MN, which is the legitimate address owner to reclaim >> and start using its home address on the home link and without sending >> a BU with life=0. This has to confirm to the override flag purpose in >> ND. >> >> Sri >> >> > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jul 9 12:27:48 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E5A93A6A88; Wed, 9 Jul 2008 12:27:48 -0700 (PDT) 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 EA3823A6B45 for ; Wed, 9 Jul 2008 12:27:46 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlofWFimKocA for ; Wed, 9 Jul 2008 12:27:46 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id DBF553A6A08 for ; Wed, 9 Jul 2008 12:27:45 -0700 (PDT) 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 m69JRo0j024128; Wed, 9 Jul 2008 14:27:50 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jul 2008 14:28:39 -0500 Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jul 2008 14:28:40 -0500 Message-ID: <487511B6.8010803@ericsson.com> Date: Wed, 09 Jul 2008 15:29:58 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: "Koodli, Rajeev" References: <4D35478224365146822AE9E3AD4A2666031F612B@exchtewks3.starentnetworks.com> In-Reply-To: <4D35478224365146822AE9E3AD4A2666031F612B@exchtewks3.starentnetworks.com> X-OriginalArrivalTime: 09 Jul 2008 19:28:40.0126 (UTC) FILETIME=[FDCD5DE0:01C8E1F9] Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home[VijayDevarapalli ] 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Rajeev, Agree with you in principle with the steps, but I don't think we should mandate (MUST) the use of O(verride)=1 since it makes no difference at all to the receiving node. case a) S(olicited)=0 and O(verride)=0 in the NA Node sets the NCE to STALE but does not update the LL address. When it needs to send packets it starts to perform NUD and detects the MN coming back. case b) S(olicited)=0 and O(verride)=1 in the NA Node sets the NCE to STALE but and updates the LL address. When it needs to send packets it still performs NUD and detects the MN coming back. Hence setting the O bit does not make a difference. Cheers Suresh Koodli, Rajeev wrote: > I see more than one issue here :) > > 1. HA to stop proxying. Of course the Dereg-BU is supposed to do this. > However, other nodes on the link will still have their NCE pointing to > the HA. This leads me to suggest that the MN MUST send an NA (with > 'O'=1) on the _home link only_ to stop the HA from proxying. ND has link > scope only and does not affect other links with which the MN may be > connected to different visited networks (at the same time that it is > connected to the home link using a different interface). > > 2. The MN SHOULD send a Dereg-BU, again on that home link where it does > not wish to have the HA forward packets to the CoA anymore. This should > allow it to maintain CoA bindings on other links. > > 3. When the MN returns home, we should have a consistent semantics about > de-registration regardless of other networks the MN may be connected to. > Limiting the actions to a) NA ('O'=1), followed by, b) Dereg-BU on the > particular home link, I believe we can achieve that. > > -Rajeev > > > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf > Of >> Vijay Devarapalli >> Sent: Wednesday, July 09, 2008 11:32 AM >> To: Sri Gundavelli; Giaretta, Gerardo >> Cc: charliep@computer.org; mext@ietf.org >> Subject: Re: [MEXT] [mext] #11: De-registration when returning >> home[VijayDevarapalli ] >> >> Hi Sri, >> >> We need to have a discussion on whether a neighbor advertisement with >> the override flag set can convince the home agent to remove the proxy >> neighbor cache entry for the home address. The proxy neighbor cache >> entry was created as a result for processing a binding update. I think >> only another binding update should remove it. But that is a separate >> discussion. >> >> Perhaps, a minor fix will satisfy you. How about the following? >> >> A mobile node detects that it has returned to its home link through >> the movement detection algorithm in use (Section 11.5.1), when the >> mobile node detects that its home subnet prefix is again on-link. >> In case the mobile node has only one interface active at any time, >> it MUST send a Binding Update to its home agent, to instruct its > home >> agent to no longer intercept or tunnel packets for it. In case the >> mobile node has more than one interface active at a time, it MAY >> send a Binding Update to its home agent, to instruct its home agent >> to no longer intercept or tunnel packets for it. Until the mobile >> node sends a de-registration Binding Update, it may not be able to >> send and receive packets using its home address from the home link. >> The home agent will continue to intercept all packets sent to the >> mobile node's home address, as long as the home agent is proxying >> for the home address. >> >> Two modifications. Replaced "..it will not be able to.." with "..it > may >> not be able to.." and re-wrote the last sentence. >> >> Vijay >> >> >>> -----Original Message----- >>> From: Sri Gundavelli [mailto:sgundave@cisco.com] >>> Sent: Wednesday, July 09, 2008 11:26 AM >>> To: Giaretta, Gerardo >>> Cc: Vijay Devarapalli; Benjamin Lim; charliep@computer.org; >>> mext@ietf.org >>> Subject: Re: [MEXT] [mext] #11: De-registration when >>> returning home [VijayDevarapalli ] >>> >>> >>> Just one comment. >>> >>> >>>> Until the mobile node sends a de-registration Binding >>> Update, it will >>>> not >>>> be able to send and receive packets using its home address >>> from the home >>>> link. >>> I have a problem with this. As Pascal and Rajiv pointed out, nothing >>> really stops the MN, which is the legitimate address owner to > reclaim >>> and start using its home address on the home link and without > sending >>> a BU with life=0. This has to confirm to the override flag purpose > in >>> ND. >>> >>> Sri >>> >>> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://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 Jul 9 12:30:42 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D578B28C279; Wed, 9 Jul 2008 12:30:42 -0700 (PDT) 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 8135428C279 for ; Wed, 9 Jul 2008 12:30:42 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oF+VE92hn9ig for ; Wed, 9 Jul 2008 12:30:41 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by core3.amsl.com (Postfix) with ESMTP id A437A28C278 for ; Wed, 9 Jul 2008 12:30:41 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so2805250rvf.49 for ; Wed, 09 Jul 2008 12:30:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=QDdJNjxXllSN2p+7a68JxunCKvAQiv65j/+Xysx3rFo=; b=bbgcWfbQDzIs/FMf9RklHi8UTONqtFALyxN1kKBy5s/UexwvyCcNtt5jOs0msgvy2O 1NOdLPIWcrqRKnUSt/zH6Kq4/9hjy9VvgbdDdIVQ3R6P4t7UzhxbFw8p6RHHvnK7OpyO ZLLhxMMGSrDLmgTIAX3VhU06K6+zWmu/2cAwQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=qLrt1WtGfauJiI0XndHnozwIxnWcayeRpsaGvEovqAnWtEjWhaLyQnx4urHldtwnb9 Uj1M1ZXUzFl6MuQLMYbu+dfFxu6KFTD4cDdk9W9aj6rKP1pv3UCB+r/+Ye+g3A7j/s1t xOjHsv6qVtcA0gGRu96k/o2oBRUFFg+luNFR8= Received: by 10.141.198.2 with SMTP id a2mr4220247rvq.219.1215631854186; Wed, 09 Jul 2008 12:30:54 -0700 (PDT) Received: by 10.140.164.11 with HTTP; Wed, 9 Jul 2008 12:30:54 -0700 (PDT) Message-ID: Date: Wed, 9 Jul 2008 12:30:54 -0700 From: "fan zhao" To: "Vijay Devarapalli" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <20080706174502.6A6393A68F3@core3.amsl.com> Cc: mext@ietf.org Subject: Re: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-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 Vijay, My understanding is that the MR does not perform the BU/BA exchange with the HA over the home link. Sincerely, fan On Wed, Jul 9, 2008 at 11:58 AM, Vijay Devarapalli wrote: > Hello Fan, > > I prefer using the Binding Update/Binding Ack exchange for assigning a > mobile network prefix to the mobile router instead of defining an IKEv2 > configuration payload for this, unless there are some significant > advantages to use IKEv2. Are there any? > > draft-zhao-mext-mnp-ikev2-00.txt does not talk about the advantages of > using IKEv2 configuration payloads over BU/BAck exchange. > > Vijay > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> Behalf Of fan zhao >> Sent: Tuesday, July 08, 2008 11:24 AM >> To: mext@ietf.org >> Subject: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-00.txt >> >> Hi, >> >> We have submitted a draft on using IKEv2 to assign a Mobile Network >> Prefix to the Mobile Router. Comments, questions and suggestions >> are highly appreciated. >> Thanks. >> >> BR, >> Fan >> >> >> ---------- Forwarded message ---------- >> From: >> Date: 2008/7/6 >> Subject: I-D Action:draft-zhao-mext-mnp-ikev2-00.txt >> To: i-d-announce@ietf.org >> >> >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. >> >> Title : IKEv2 based Mobile Network Prefix Assignment >> Author(s) : F. Zhao, et al. >> Filename : draft-zhao-mext-mnp-ikev2-00.txt >> Pages : 13 >> Date : 2008-07-06 >> >> This document proposes a mechanism for the Mobile Router to >> dynamically obtain the Mobile Network Prefix through IKEv2. The >> mechanisms to renew, release and update the allocated Mobile Network >> Prefixes are also described. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-zhao-mext-mnp-ikev2-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://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 Jul 9 12:42:34 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 119C73A680D; Wed, 9 Jul 2008 12:42:34 -0700 (PDT) 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 50EF53A680D for ; Wed, 9 Jul 2008 12:42:33 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cdaFfAy+sXb for ; Wed, 9 Jul 2008 12:42:32 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 613AD3A67B0 for ; Wed, 9 Jul 2008 12:42:32 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m69JgBuU016349; Wed, 9 Jul 2008 14:42:11 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jul 2008 14:43:00 -0500 Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jul 2008 14:43:00 -0500 Message-ID: <48751514.2080402@ericsson.com> Date: Wed, 09 Jul 2008 15:44:20 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Vijay Devarapalli References: <4D35478224365146822AE9E3AD4A2666031F612B$0001@exchtewks3.starentnetworks.com> In-Reply-To: X-OriginalArrivalTime: 09 Jul 2008 19:43:00.0693 (UTC) FILETIME=[FEBD7850:01C8E1FB] Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home[VijayDevarapalli ] 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Vijay, Vijay Devarapalli wrote: > RFC 3775 already says that the mobile node should sent a Neighbor > Advertisement with the 'O' flag set after it receives the binding ack > from the home agent. > > After receiving the Binding Acknowledgement for its Binding Update to > its home agent, the mobile node MUST multicast onto the home link (to > the all-nodes multicast address) a Neighbor Advertisement [12], to > advertise the mobile node's own link-layer address for its own home > address. The Target Address in this Neighbor Advertisement MUST be > set to the mobile node's home address, and the Advertisement MUST > include a Target Link-layer Address option specifying the mobile > node's link-layer address. The mobile node MUST multicast such a > Neighbor Advertisement for each of its home addresses, as defined by > the current on-link prefixes, including its link-local address and > site-local address. The Solicited Flag (S) in these Advertisements > MUST NOT be set, since they were not solicited by any Neighbor > Solicitation. The Override Flag (O) in these Advertisements MUST be > set, indicating that the Advertisements SHOULD override any existing > Neighbor Cache entries at any node receiving them. Yes. This is the case. But what "override" means is defined by RFC4861 and not by RFC3775. Let's say the MN has a home address HoA_X and and the HA is defending this address. Another node A on the same link has been communicating with the MN through the HA and has a neighbor cache entry that looks like this HoA_X : LLaddr_of_HA : REACHABLE Receipt of the NA from the MN with a different LL addr will set it to HoA_X : LLaddr_of_HA : STALE (if O=0 in the NA) or HoA_X : LLaddr_of_MN : STALE (if O=1 in the NA) In either case the receiving node A has to perform NUD before communicating to the MN. So there will be a disruption of service. Cheers Suresh _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jul 9 14:31:35 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53EA228C318; Wed, 9 Jul 2008 14:31:35 -0700 (PDT) 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 C2AE128C318 for ; Wed, 9 Jul 2008 14:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RErrHd98Po74 for ; Wed, 9 Jul 2008 14:31:32 -0700 (PDT) Received: from web84314.mail.re1.yahoo.com (web84314.mail.re1.yahoo.com [69.147.74.193]) by core3.amsl.com (Postfix) with SMTP id 7612528C294 for ; Wed, 9 Jul 2008 14:31:32 -0700 (PDT) Received: (qmail 78908 invoked by uid 60001); 9 Jul 2008 21:31:41 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=qlH68vThdF/p3JvQv4yb0gU3h5odRi+g4KCSjt0WW0fIxHXqspaslYxvNvv5zD8+Lu4I1TrwmIa2/gFLoWsChox+zNF5bDazrLymdvE6Bug3zuG1bo3tqQ9m1gIJpP8JHdSqEwfc5YAKqx56ycy57PSe6Ik22RqtGlveIiMJXrg=; Received: from [206.16.17.212] by web84314.mail.re1.yahoo.com via HTTP; Wed, 09 Jul 2008 14:31:41 PDT X-Mailer: YahooMailRC/975.45 YahooMailWebService/0.7.199 Date: Wed, 9 Jul 2008 14:31:41 -0700 (PDT) From: Behcet Sarikaya To: Vijay Devarapalli MIME-Version: 1.0 Message-ID: <438586.75899.qm@web84314.mail.re1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-00.txt 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="===============1430238263==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1430238263== Content-Type: multipart/alternative; boundary="0-1504835561-1215639101=:75899" --0-1504835561-1215639101=:75899 Content-Type: text/plain; charset=us-ascii Hi Vijay, I also think that BU/BA exchange is a better solution as the second solution Pascal mentioned. There are a few problems like the one below to be resolved. We are going to work out an I-D on this soon. Regards, Behcet ----- Original Message ---- From: fan zhao To: Vijay Devarapalli Cc: mext@ietf.org Sent: Wednesday, July 9, 2008 2:30:54 PM Subject: Re: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-00.txt Hi Vijay, My understanding is that the MR does not perform the BU/BA exchange with the HA over the home link. Sincerely, fan On Wed, Jul 9, 2008 at 11:58 AM, Vijay Devarapalli wrote: > Hello Fan, > > I prefer using the Binding Update/Binding Ack exchange for assigning a > mobile network prefix to the mobile router instead of defining an IKEv2 > configuration payload for this, unless there are some significant > advantages to use IKEv2. Are there any? > > draft-zhao-mext-mnp-ikev2-00.txt does not talk about the advantages of > using IKEv2 configuration payloads over BU/BAck exchange. > > Vijay > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> Behalf Of fan zhao >> Sent: Tuesday, July 08, 2008 11:24 AM >> To: mext@ietf.org >> Subject: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-00.txt >> >> Hi, >> >> We have submitted a draft on using IKEv2 to assign a Mobile Network >> Prefix to the Mobile Router. Comments, questions and suggestions >> are highly appreciated. >> Thanks. >> >> BR, >> Fan >> >> >> ---------- Forwarded message ---------- >> From: >> Date: 2008/7/6 >> Subject: I-D Action:draft-zhao-mext-mnp-ikev2-00.txt >> To: i-d-announce@ietf.org >> >> >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. >> >> Title : IKEv2 based Mobile Network Prefix Assignment >> Author(s) : F. Zhao, et al. >> Filename : draft-zhao-mext-mnp-ikev2-00.txt >> Pages : 13 >> Date : 2008-07-06 >> >> This document proposes a mechanism for the Mobile Router to >> dynamically obtain the Mobile Network Prefix through IKEv2. The >> mechanisms to renew, release and update the allocated Mobile Network >> Prefixes are also described. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-zhao-mext-mnp-ikev2-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --0-1504835561-1215639101=:75899 Content-Type: text/html; charset=us-ascii
Hi Vijay,
   I also think that BU/BA exchange is a better solution as the second solution Pascal mentioned. There are a few problems like the one below to be resolved. We are going to work out an I-D on this soon.

Regards,

Behcet




----- Original Message ----
From: fan zhao <fanzhao828@gmail.com>
To: Vijay Devarapalli <vijay@wichorus.com>
Cc: mext@ietf.org
Sent: Wednesday, July 9, 2008 2:30:54 PM
Subject: Re: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-00.txt

Hi Vijay,

My understanding is that the MR does not perform the BU/BA
exchange with the HA over the home link.

Sincerely,
fan

On Wed, Jul 9, 2008 at 11:58 AM, Vijay Devarapalli <vijay@wichorus.com> wrote:
> Hello Fan,
>
> I prefer using the Binding Update/Binding Ack exchange for assigning a
> mobile network prefix to the mobile router instead of defining an IKEv2
> configuration payload for this, unless there are some significant
> advantages to use IKEv2. Are there any?
>
> draft-zhao-mext-mnp-ikev2-00.txt does not talk about the advantages of
> using IKEv2 configuration payloads over BU/BAck exchange.
>
> Vijay
>
>> -----Original Message-----
>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On
>> Behalf Of fan zhao
>> Sent: Tuesday, July 08, 2008 11:24 AM
>> To: mext@ietf.org
>> Subject: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-00.txt
>>
>> Hi,
>>
>> We have submitted a draft on using IKEv2 to assign a Mobile Network
>> Prefix to the Mobile Router. Comments, questions and suggestions
>> are highly appreciated.
>> Thanks.
>>
>> BR,
>> Fan
>>
>>
>> ---------- Forwarded message ----------
>> From:  <Internet-Drafts@ietf.org>
>> Date: 2008/7/6
>> Subject: I-D Action:draft-zhao-mext-mnp-ikev2-00.txt
>> To: i-d-announce@ietf.org
>>
>>
>> A New Internet-Draft is available from the on-line
>> Internet-Drafts directories.
>>
>>        Title          : IKEv2 based Mobile Network Prefix Assignment
>>        Author(s)      : F. Zhao, et al.
>>        Filename        : draft-zhao-mext-mnp-ikev2-00.txt
>>        Pages          : 13
>>        Date            : 2008-07-06
>>
>> This document proposes a mechanism for the Mobile Router to
>> dynamically obtain the Mobile Network Prefix through IKEv2.  The
>> mechanisms to renew, release and update the allocated Mobile Network
>> Prefixes are also described.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-zhao-mext-mnp-ikev2-00.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>>
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> _______________________________________________
>> MEXT mailing list
>> MEXT@ietf.org
>> https://www.ietf.org/mailman/listinfo/mext
>>
>
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext
--0-1504835561-1215639101=:75899-- --===============1430238263== 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 --===============1430238263==-- From mext-bounces@ietf.org Wed Jul 9 14:48:44 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC8753A6B8A; Wed, 9 Jul 2008 14:48:44 -0700 (PDT) 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 4E6003A6BA1 for ; Wed, 9 Jul 2008 14:48:43 -0700 (PDT) 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 BSzYvBCEzFCN for ; Wed, 9 Jul 2008 14:48:42 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 0FD983A6B67 for ; Wed, 9 Jul 2008 14:48:42 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id CC1EBC802E for ; Wed, 9 Jul 2008 17:48:51 -0400 (EDT) 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 24321-12 for ; Wed, 9 Jul 2008 17:48:51 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 9 Jul 2008 17:48:51 -0400 (EDT) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jul 2008 17:48:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Jul 2008 17:50:37 -0400 Message-ID: <4D35478224365146822AE9E3AD4A2666031F6295@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [mext] #11: De-registration when returning home[VijayDevarapalli ] Thread-Index: Acjh8UOe+wBev0J+TPu/GQWeOzUX4QAAEn+QAAB8HaAAAMC20AAFljLQ From: "Koodli, Rajeev" To: "Vijay Devarapalli" , "Sri Gundavelli" , "Giaretta, Gerardo" X-OriginalArrivalTime: 09 Jul 2008 21:48:51.0289 (UTC) FILETIME=[933EFC90:01C8E20D] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home[VijayDevarapalli ] 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 My point is that there are two different things here: 1) HA to stop proxying, 2) HA to stop forwarding packets to CoA. Going with the current semantics, both are tied together, which is perhaps unnecessary. (something to note: ND does not have a way to request proxying, MIP BU does. But, ND does have a way to unproxy (NA, 'O'=1), and we should let the MN do this) We could have the Unsolicited NA sent just to stop the proxying first and let every node know that the actual owner of the address is on-link. I do realize that the on-link nodes still resolve the address (even after processing the UNA), but without it, they will be sending packets to the HA. The following BU can delete the BCE. -Rajeev > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay@wichorus.com] > Sent: Wednesday, July 09, 2008 12:06 PM > To: Koodli, Rajeev; Sri Gundavelli; Giaretta, Gerardo > Cc: charliep@computer.org; mext@ietf.org > Subject: RE: [MEXT] [mext] #11: De-registration when returning > home[VijayDevarapalli ] > > Rajeev, > > > 1. HA to stop proxying. Of course the Dereg-BU is supposed to do this. > > However, other nodes on the link will still have their NCE pointing to > > the HA. This leads me to suggest that the MN MUST send an NA (with > > 'O'=1) on the _home link only_ to stop the HA from proxying. > > ND has link > > scope only and does not affect other links with which the MN may be > > connected to different visited networks (at the same time that it is > > connected to the home link using a different interface). > > RFC 3775 already says that the mobile node should sent a Neighbor > Advertisement with the 'O' flag set after it receives the binding ack > from the home agent. > > After receiving the Binding Acknowledgement for its Binding Update to > its home agent, the mobile node MUST multicast onto the home link (to > the all-nodes multicast address) a Neighbor Advertisement [12], to > advertise the mobile node's own link-layer address for its own home > address. The Target Address in this Neighbor Advertisement MUST be > set to the mobile node's home address, and the Advertisement MUST > include a Target Link-layer Address option specifying the mobile > node's link-layer address. The mobile node MUST multicast such a > Neighbor Advertisement for each of its home addresses, as defined by > the current on-link prefixes, including its link-local address and > site-local address. The Solicited Flag (S) in these Advertisements > MUST NOT be set, since they were not solicited by any Neighbor > Solicitation. The Override Flag (O) in these Advertisements MUST be > set, indicating that the Advertisements SHOULD override any existing > Neighbor Cache entries at any node receiving them. > > > 3. When the MN returns home, we should have a consistent > > semantics about > > de-registration regardless of other networks the MN may be > > connected to. > > Limiting the actions to a) NA ('O'=1), followed by, b) Dereg-BU on the > > particular home link, I believe we can achieve that. > > Currently, RFC 3775 specifies b) followed by a). For changing the order, > we might need a separate discussion. Not on this thread. > > Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jul 9 14:50:52 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E858028C0E8; Wed, 9 Jul 2008 14:50:51 -0700 (PDT) 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 DD52228C0E8 for ; Wed, 9 Jul 2008 14:50:50 -0700 (PDT) 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 3sLWS2QcS4sT for ; Wed, 9 Jul 2008 14:50:49 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 981913A6BA9 for ; Wed, 9 Jul 2008 14:50:49 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 7E0D4C802E for ; Wed, 9 Jul 2008 17:50:59 -0400 (EDT) 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 24148-02 for ; Wed, 9 Jul 2008 17:50:56 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 9 Jul 2008 17:50:56 -0400 (EDT) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jul 2008 17:50:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Jul 2008 17:52:42 -0400 Message-ID: <4D35478224365146822AE9E3AD4A2666031F6298@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [mext] #11: De-registration when returning home[VijayDevarapalli ] Thread-Index: Acjh+et3cuebOsbVQWaq8jn+57szKwAE/OFQ From: "Koodli, Rajeev" To: "Suresh Krishnan" X-OriginalArrivalTime: 09 Jul 2008 21:50:56.0415 (UTC) FILETIME=[DDD3B2F0:01C8E20D] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home[VijayDevarapalli ] 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, I understand the nodes still probe after processing NA ('O'=1), because bidirectional reachability is not confirmed. However, if you don't send the NA('O'=1), they will continue to send packets to the HA, which you can avoid. -Rajeev > -----Original Message----- > From: Suresh Krishnan [mailto:suresh.krishnan@ericsson.com] > Sent: Wednesday, July 09, 2008 12:30 PM > To: Koodli, Rajeev > Cc: Vijay Devarapalli; Sri Gundavelli; Giaretta, Gerardo; > charliep@computer.org; mext@ietf.org > Subject: Re: [MEXT] [mext] #11: De-registration when returning > home[VijayDevarapalli ] > > Hi Rajeev, > Agree with you in principle with the steps, but I don't think we > should mandate (MUST) the use of O(verride)=1 since it makes no > difference at all to the receiving node. > > case a) S(olicited)=0 and O(verride)=0 in the NA > Node sets the NCE to STALE but does not update the LL address. When it > needs to send packets it starts to perform NUD and detects the MN coming > back. > > case b) S(olicited)=0 and O(verride)=1 in the NA > Node sets the NCE to STALE but and updates the LL address. When it needs > to send packets it still performs NUD and detects the MN coming back. > > Hence setting the O bit does not make a difference. > > Cheers > Suresh > > Koodli, Rajeev wrote: > > I see more than one issue here :) > > > > 1. HA to stop proxying. Of course the Dereg-BU is supposed to do this. > > However, other nodes on the link will still have their NCE pointing to > > the HA. This leads me to suggest that the MN MUST send an NA (with > > 'O'=1) on the _home link only_ to stop the HA from proxying. ND has link > > scope only and does not affect other links with which the MN may be > > connected to different visited networks (at the same time that it is > > connected to the home link using a different interface). > > > > 2. The MN SHOULD send a Dereg-BU, again on that home link where it does > > not wish to have the HA forward packets to the CoA anymore. This should > > allow it to maintain CoA bindings on other links. > > > > 3. When the MN returns home, we should have a consistent semantics about > > de-registration regardless of other networks the MN may be connected to. > > Limiting the actions to a) NA ('O'=1), followed by, b) Dereg-BU on the > > particular home link, I believe we can achieve that. > > > > -Rajeev > > > > > > > >> -----Original Message----- > >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf > > Of > >> Vijay Devarapalli > >> Sent: Wednesday, July 09, 2008 11:32 AM > >> To: Sri Gundavelli; Giaretta, Gerardo > >> Cc: charliep@computer.org; mext@ietf.org > >> Subject: Re: [MEXT] [mext] #11: De-registration when returning > >> home[VijayDevarapalli ] > >> > >> Hi Sri, > >> > >> We need to have a discussion on whether a neighbor advertisement with > >> the override flag set can convince the home agent to remove the proxy > >> neighbor cache entry for the home address. The proxy neighbor cache > >> entry was created as a result for processing a binding update. I think > >> only another binding update should remove it. But that is a separate > >> discussion. > >> > >> Perhaps, a minor fix will satisfy you. How about the following? > >> > >> A mobile node detects that it has returned to its home link through > >> the movement detection algorithm in use (Section 11.5.1), when the > >> mobile node detects that its home subnet prefix is again on-link. > >> In case the mobile node has only one interface active at any time, > >> it MUST send a Binding Update to its home agent, to instruct its > > home > >> agent to no longer intercept or tunnel packets for it. In case the > >> mobile node has more than one interface active at a time, it MAY > >> send a Binding Update to its home agent, to instruct its home agent > >> to no longer intercept or tunnel packets for it. Until the mobile > >> node sends a de-registration Binding Update, it may not be able to > >> send and receive packets using its home address from the home link. > >> The home agent will continue to intercept all packets sent to the > >> mobile node's home address, as long as the home agent is proxying > >> for the home address. > >> > >> Two modifications. Replaced "..it will not be able to.." with "..it > > may > >> not be able to.." and re-wrote the last sentence. > >> > >> Vijay > >> > >> > >>> -----Original Message----- > >>> From: Sri Gundavelli [mailto:sgundave@cisco.com] > >>> Sent: Wednesday, July 09, 2008 11:26 AM > >>> To: Giaretta, Gerardo > >>> Cc: Vijay Devarapalli; Benjamin Lim; charliep@computer.org; > >>> mext@ietf.org > >>> Subject: Re: [MEXT] [mext] #11: De-registration when > >>> returning home [VijayDevarapalli ] > >>> > >>> > >>> Just one comment. > >>> > >>> > >>>> Until the mobile node sends a de-registration Binding > >>> Update, it will > >>>> not > >>>> be able to send and receive packets using its home address > >>> from the home > >>>> link. > >>> I have a problem with this. As Pascal and Rajiv pointed out, nothing > >>> really stops the MN, which is the legitimate address owner to > > reclaim > >>> and start using its home address on the home link and without > > sending > >>> a BU with life=0. This has to confirm to the override flag purpose > > in > >>> ND. > >>> > >>> Sri > >>> > >>> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://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 Jul 9 16:02:18 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 570AF3A689E; Wed, 9 Jul 2008 16:02:18 -0700 (PDT) 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 255833A67FE for ; Wed, 9 Jul 2008 16:02:17 -0700 (PDT) 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 FFKYCTMwjMkO for ; Wed, 9 Jul 2008 16:02:15 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id A9DF83A67B0 for ; Wed, 9 Jul 2008 16:02:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=PhotlbZ+vYmZQ+JS8i+6pnn70cvsKRIITw2q9oN2nnNt7F6He04SlN5nOAaWhwEV; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [75.26.137.116] (helo=[10.166.255.10]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1KGig8-0006W0-39; Wed, 09 Jul 2008 19:02:28 -0400 Message-ID: <48754383.6050608@earthlink.net> Date: Wed, 09 Jul 2008 16:02:27 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: mohamed.kassilahlou@orange-ftgroup.com References: <486B8EDD.4070807@ericsson.com> <486BC5C4.8000900@ericsson.com> In-Reply-To: X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52e23fff292341705a01e0a08717d13035350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Cc: mext@ietf.org Subject: Re: [MEXT] New Text for home link detection in RFC3775bis 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-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Kassi, I have gone through your proposal. It seems to be a valid summary of many actions taken by the mobile node when encountering a new link. However, I think it amounts to an abbreviation of material that is found elsewhere within RFC3775 (e.g., section 4.1) and RFC 5026. As such, I do not think it is focussed on the specific issues that have been raised with home link detection, but instead is much more generalized and thus harder for me to pinpoint the need. Perhaps you could consider whether the text proposed by Suresh is sufficient for the particular issue under discussion. If not, and you can suggest some revised wording, that would be appreciated. Regards, Charlie P. mohamed.kassilahlou@orange-ftgroup.com wrote: > > Hi all, > > I hope that the following can hepl: > > If the MN has no configuration then A otherwise B. > > A: Bootstrap > > o The MN has neither IP address, nor the HA IP address, nor home IP = > prefix, > > o The MN connects to a network, obtains a link IP prefix and acquires = > or forms an IP address (MN@) > > o The MN discovers the HA IP address and its home IP prefixes > > o The MN compares the prefix of its IP address (MN@) with the home IP = > prefixes > > - If those prefixes match then the MN is in its home > network, HoA=3DMN@, and the HA is the HA for this HoA. The > MN initiates IP sessions with classical routing. > > - If not then the MN is in a foreign network, CoA=3DMN@, the > HA is a HA for the MN. The MN will form a HoA from home > prefixes or will request a HoA from the HA and will > exchange a BU/BA with the HA. The MN initiates IP sessions > using MIP. > > B. Handover > > o The MN has a HoA, the HA IP address and its home IP prefixes > > o The MN connects to the network and obtains a link IP prefix > > o The MN compares the link IP prefix with the HoA IP prefix > > - If those prefixes match then the MN is in its home network > > + If the MN has no CoA: It means > that the MN is always on its home > network. It has made no IP > handover therefore it does not > need to send a BU. The MN > continues its IP sessions with > classical routing. > > + If the MN already has a CoA: It > means that the MN returns at its > home network then it has to sends > a BU to deregister. The MN > continues its IP sessions with > classical routing. > > - If the prefixes do not match then the MN is in a foreign > network > > + if the MN has no CoA: It means > that the MN comes from its home > network then it forms (or > acquires) a CoA with the link > prefix on which it has just > connected and sends a BU to its > HA. The MN continues its IP > sessions using MIP. > > + If the MN already has a CoA: > > * If the link prefixes > and the CoA prefix > match: It means that > the MN is always on > the same foreign > network. It has made > no IP handover > therefore it does not > need to send a BU. The > MN continues its IP > sessions using MIP. > > * If the link prefixes > and the CoA prefix do > not match: it means > that the MN has made > IP handover towards > another foreign > network therefore it > has to form (or > acquire) a CoA with > the link prefix on > which it has just > connected and to send > a BU to its HA to > update its > registration. The MN > continues its IP > sessions using MIP. > > o Note that when the mobile node connects on a new visited network it = > may need to discover the HA of this network if available. The mobile = > node may have to use this HA for next IP sessions. > > Sincerly, > > Kassi > > > -----Message d'origine----- > De : mext-bounces@ietf.org [_mailto:mext-bounces@ietf.org_] De la part = > de Suresh Krishnan > Envoy=E9 : mercredi 2 juillet 2008 20:16 > =C0 : fan zhao > Cc : mext@ietf.org > Objet : Re: [MEXT] New Text for home link detection in RFC3775bis > > Hi Fan, > Sounds like a good idea. > > Cheers > Suresh > > fan zhao wrote: > > Hi Suresh, > > > > I have a quick comment: > > the Home Link Detection is not only performed during handover, but > > also during initial attach. The new text is proposed into section > > 11.5.4. "Returning Home", which seems to me that the new text only > > applies to the handover case. > > > > Therefore, my oponion is to have a new (sub)section called "Home Link > > Detection" somewhere, and refer to this new section in section 11.5.4. > > What do you think? > > > > Sincerely, > > fan > > > > On Wed, Jul 2, 2008 at 7:21 AM, Suresh Krishnan > > wrote: > >> The WG had consensus to fold in text from draft-krishnan-mext-hld > >> into RFC3775bis. Here is the proposed text for doing so. Feel free = > to edit. > >> > >> > >> > >> This change is made in Section 11.5.4 > >> > >> OLD TEXT > >> =3D=3D=3D=3D=3D=3D=3D=3D > >> A mobile node detects that it has returned to its home link through > >> the movement detection algorithm in use (Section 11.5.1), when the > >> mobile node detects that its home subnet prefix is again on-link. > >> > >> NEW TEXT > >> =3D=3D=3D=3D=3D=3D=3D=3D > >> When an MN detects that it has arrived on a new link using the > >> movement detection algorithm in use (Section 11.5.1) it performs the > >> following steps to determine if it is on the home link. > >> > >> o The MN performs the procedure described in Section 11.5.2 and > >> configures an address referred to as the Current MN Address (CMA). > >> It also stores all the on-link prefix(es) received in the RA along > >> with their prefix lengths in a conceptual list called the Current > >> Link Prefix List (CLPL). > >> > >> o If the home prefix has been statically pre-configured on the MN > >> it checks if the home prefix matches one of the prefixes in the > >> CLPL. If it does, the MN concludes that it has returned home. > >> > >> o If the home prefix has not been statically configured the MN uses > >> some form of bootstrapping procedure (e.g. RFC5026) to determine > >> the home prefix. It then checks if the home prefix matches one of > >> the prefixes in the CLPL. If it does, the MN concludes that it has > >> returned home. > >> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> _https://www.ietf.org/mailman/listinfo/mext_ > >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > _https://www.ietf.org/mailman/listinfo/mext_ > > ------------------------------------------------------------------------ > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://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 Jul 9 17:01:49 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4CA13A6885; Wed, 9 Jul 2008 17:01:49 -0700 (PDT) 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 D11C03A6860 for ; Wed, 9 Jul 2008 17:01:48 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8ut4hRn0cMJ for ; Wed, 9 Jul 2008 17:01:48 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id E07013A6822 for ; Wed, 9 Jul 2008 17:01:47 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Jul 2008 20:01:55 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-00.txt Thread-Index: Acjh+k51xHzvirCST56BoCyizZPNAAAJbYmQ References: <20080706174502.6A6393A68F3@core3.amsl.com> From: "Vijay Devarapalli" To: "fan zhao" Cc: mext@ietf.org Subject: Re: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-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 > My understanding is that the MR does not perform the BU/BA > exchange with the HA over the home link. Is that the only reason why you would want to use IKEv2 exchange instead of a BU/BAck exchange? Vijay > > Sincerely, > fan > > On Wed, Jul 9, 2008 at 11:58 AM, Vijay Devarapalli > wrote: > > Hello Fan, > > > > I prefer using the Binding Update/Binding Ack exchange for > assigning a > > mobile network prefix to the mobile router instead of > defining an IKEv2 > > configuration payload for this, unless there are some significant > > advantages to use IKEv2. Are there any? > > > > draft-zhao-mext-mnp-ikev2-00.txt does not talk about the > advantages of > > using IKEv2 configuration payloads over BU/BAck exchange. > > > > Vijay > > > >> -----Original Message----- > >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > >> Behalf Of fan zhao > >> Sent: Tuesday, July 08, 2008 11:24 AM > >> To: mext@ietf.org > >> Subject: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-00.txt > >> > >> Hi, > >> > >> We have submitted a draft on using IKEv2 to assign a Mobile Network > >> Prefix to the Mobile Router. Comments, questions and suggestions > >> are highly appreciated. > >> Thanks. > >> > >> BR, > >> Fan > >> > >> > >> ---------- Forwarded message ---------- > >> From: > >> Date: 2008/7/6 > >> Subject: I-D Action:draft-zhao-mext-mnp-ikev2-00.txt > >> To: i-d-announce@ietf.org > >> > >> > >> A New Internet-Draft is available from the on-line > >> Internet-Drafts directories. > >> > >> Title : IKEv2 based Mobile Network Prefix > Assignment > >> Author(s) : F. Zhao, et al. > >> Filename : draft-zhao-mext-mnp-ikev2-00.txt > >> Pages : 13 > >> Date : 2008-07-06 > >> > >> This document proposes a mechanism for the Mobile Router to > >> dynamically obtain the Mobile Network Prefix through IKEv2. The > >> mechanisms to renew, release and update the allocated > Mobile Network > >> Prefixes are also described. > >> > >> A URL for this Internet-Draft is: > >> > http://www.ietf.org/internet-drafts/draft-zhao-mext-mnp-ikev2-00.txt > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> Below is the data which will enable a MIME compliant mail reader > >> implementation to automatically retrieve the ASCII version of the > >> Internet-Draft. > >> > >> > >> _______________________________________________ > >> I-D-Announce mailing list > >> I-D-Announce@ietf.org > >> https://www.ietf.org/mailman/listinfo/i-d-announce > >> Internet-Draft directories: http://www.ietf.org/shadow.html > >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://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 Jul 9 17:04:04 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5119A3A6822; Wed, 9 Jul 2008 17:04:04 -0700 (PDT) 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 672AC3A6822 for ; Wed, 9 Jul 2008 17:04:02 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gks8ZikwA9I6 for ; Wed, 9 Jul 2008 17:04:01 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 9E97C3A67FE for ; Wed, 9 Jul 2008 17:04:01 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Jul 2008 20:04:13 -0400 Message-ID: In-Reply-To: <438586.75899.qm@web84314.mail.re1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-00.txt Thread-Index: AcjiCy454+FVew6VSUuXSnpkb2wNrgAFQ5Yg References: <438586.75899.qm@web84314.mail.re1.yahoo.com> From: "Vijay Devarapalli" To: "Behcet Sarikaya" Cc: mext@ietf.org Subject: Re: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-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 Behcet, > Hi Vijay, > I also think that BU/BA exchange is a better solution as > the second solution Pascal mentioned. There are a few > problems like the one below to be resolved. We are going to > work out an I-D on this soon. The document already exists. http://tools.ietf.org/id/draft-ietf-nemo-prefix-delegation-02.txt I guess we don't need yet another draft on this. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jul 9 17:05:19 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6035E3A6860; Wed, 9 Jul 2008 17:05:19 -0700 (PDT) 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 598E23A6860 for ; Wed, 9 Jul 2008 17:05:18 -0700 (PDT) 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 jt6kI4ocGFjh for ; Wed, 9 Jul 2008 17:05:17 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by core3.amsl.com (Postfix) with ESMTP id 4AC543A67FE for ; Wed, 9 Jul 2008 17:05:16 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so1523782and.122 for ; Wed, 09 Jul 2008 17:05:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=tZwam0/MLYG4fELnFpaHQS57vFGmyH3NHUolxbJcu+Q=; b=mjL9v6ZYw+xhmgFtXZD4z6g4JuMbRdcpWmieqBYWP9WVSx6kTM11vHr85L+iYGloTD RPthKXdhOU7QwwOaxcTobz9ZZOfciqg9+4DzqUbKrhpaG6DUmkwiyKPM/n1r5pgJgbLc +9ViBNNiP9vTGwYmb4FaLlL2QbmJlmK2pDkSY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=BIJ+y0XrrOCKnLG6BoFXtjlkIYHQDa2SZy/zSu/vYpC6628t2EQQHzQiYbbEaPqb30 Dky8Deo8MQBayvYcp47vBcSsEpCrid9239wWf9chG3gEs8XtGh7YdVjjtJCsDu2VxoGH WmkPFWrUUKmB92KlHVhjuHnmnXzTfyT7ZyHr8= Received: by 10.100.41.9 with SMTP id o9mr7183092ano.42.1215648329737; Wed, 09 Jul 2008 17:05:29 -0700 (PDT) Received: by 10.100.57.5 with HTTP; Wed, 9 Jul 2008 17:05:29 -0700 (PDT) Message-ID: Date: Wed, 9 Jul 2008 17:05:29 -0700 From: "fan zhao" To: "Vijay Devarapalli" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <20080706174502.6A6393A68F3@core3.amsl.com> Cc: mext@ietf.org Subject: Re: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-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 Vijay, Also RFC 5026 specifies that the home address is assigned during IKE signaling. Sincerely, fan On Wed, Jul 9, 2008 at 5:01 PM, Vijay Devarapalli wrote: >> My understanding is that the MR does not perform the BU/BA >> exchange with the HA over the home link. > > Is that the only reason why you would want to use IKEv2 exchange instead > of a BU/BAck exchange? > > Vijay > >> >> Sincerely, >> fan >> >> On Wed, Jul 9, 2008 at 11:58 AM, Vijay Devarapalli >> wrote: >> > Hello Fan, >> > >> > I prefer using the Binding Update/Binding Ack exchange for >> assigning a >> > mobile network prefix to the mobile router instead of >> defining an IKEv2 >> > configuration payload for this, unless there are some significant >> > advantages to use IKEv2. Are there any? >> > >> > draft-zhao-mext-mnp-ikev2-00.txt does not talk about the >> advantages of >> > using IKEv2 configuration payloads over BU/BAck exchange. >> > >> > Vijay >> > >> >> -----Original Message----- >> >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> >> Behalf Of fan zhao >> >> Sent: Tuesday, July 08, 2008 11:24 AM >> >> To: mext@ietf.org >> >> Subject: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-00.txt >> >> >> >> Hi, >> >> >> >> We have submitted a draft on using IKEv2 to assign a Mobile Network >> >> Prefix to the Mobile Router. Comments, questions and suggestions >> >> are highly appreciated. >> >> Thanks. >> >> >> >> BR, >> >> Fan >> >> >> >> >> >> ---------- Forwarded message ---------- >> >> From: >> >> Date: 2008/7/6 >> >> Subject: I-D Action:draft-zhao-mext-mnp-ikev2-00.txt >> >> To: i-d-announce@ietf.org >> >> >> >> >> >> A New Internet-Draft is available from the on-line >> >> Internet-Drafts directories. >> >> >> >> Title : IKEv2 based Mobile Network Prefix >> Assignment >> >> Author(s) : F. Zhao, et al. >> >> Filename : draft-zhao-mext-mnp-ikev2-00.txt >> >> Pages : 13 >> >> Date : 2008-07-06 >> >> >> >> This document proposes a mechanism for the Mobile Router to >> >> dynamically obtain the Mobile Network Prefix through IKEv2. The >> >> mechanisms to renew, release and update the allocated >> Mobile Network >> >> Prefixes are also described. >> >> >> >> A URL for this Internet-Draft is: >> >> >> http://www.ietf.org/internet-drafts/draft-zhao-mext-mnp-ikev2-00.txt >> >> >> >> Internet-Drafts are also available by anonymous FTP at: >> >> ftp://ftp.ietf.org/internet-drafts/ >> >> >> >> Below is the data which will enable a MIME compliant mail reader >> >> implementation to automatically retrieve the ASCII version of the >> >> Internet-Draft. >> >> >> >> >> >> _______________________________________________ >> >> I-D-Announce mailing list >> >> I-D-Announce@ietf.org >> >> https://www.ietf.org/mailman/listinfo/i-d-announce >> >> Internet-Draft directories: http://www.ietf.org/shadow.html >> >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> _______________________________________________ >> >> MEXT mailing list >> >> MEXT@ietf.org >> >> https://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 Jul 9 17:09:54 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45BF53A67E7; Wed, 9 Jul 2008 17:09:54 -0700 (PDT) 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 AA3023A67E7 for ; Wed, 9 Jul 2008 17:09:53 -0700 (PDT) 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 5pE1r-G2-sDP for ; Wed, 9 Jul 2008 17:09:52 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id A56B93A67E2 for ; Wed, 9 Jul 2008 17:09:52 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Jul 2008 20:10:04 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-00.txt Thread-Index: AcjiIKqeTh50t/mBQ+6GiE69NiBgKAAAF9VQ References: <20080706174502.6A6393A68F3@core3.amsl.com> From: "Vijay Devarapalli" To: "fan zhao" Cc: mext@ietf.org Subject: Re: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-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 > Also RFC 5026 specifies that the home address is assigned during IKE > signaling. That's because you need to setup IPsec SAs based on the home address. The home address needs to be known before the IPsec SAs are setup. Even the binding update cannot be sent if the required SA is not in place. There is no such dependency on configuring the mobile network prefixes. Vijay > > Sincerely, > fan > > On Wed, Jul 9, 2008 at 5:01 PM, Vijay Devarapalli > wrote: > >> My understanding is that the MR does not perform the BU/BA > >> exchange with the HA over the home link. > > > > Is that the only reason why you would want to use IKEv2 > exchange instead > > of a BU/BAck exchange? > > > > Vijay > > > >> > >> Sincerely, > >> fan > >> > >> On Wed, Jul 9, 2008 at 11:58 AM, Vijay Devarapalli > >> wrote: > >> > Hello Fan, > >> > > >> > I prefer using the Binding Update/Binding Ack exchange for > >> assigning a > >> > mobile network prefix to the mobile router instead of > >> defining an IKEv2 > >> > configuration payload for this, unless there are some significant > >> > advantages to use IKEv2. Are there any? > >> > > >> > draft-zhao-mext-mnp-ikev2-00.txt does not talk about the > >> advantages of > >> > using IKEv2 configuration payloads over BU/BAck exchange. > >> > > >> > Vijay > >> > > >> >> -----Original Message----- > >> >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > >> >> Behalf Of fan zhao > >> >> Sent: Tuesday, July 08, 2008 11:24 AM > >> >> To: mext@ietf.org > >> >> Subject: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-00.txt > >> >> > >> >> Hi, > >> >> > >> >> We have submitted a draft on using IKEv2 to assign a > Mobile Network > >> >> Prefix to the Mobile Router. Comments, questions and suggestions > >> >> are highly appreciated. > >> >> Thanks. > >> >> > >> >> BR, > >> >> Fan > >> >> > >> >> > >> >> ---------- Forwarded message ---------- > >> >> From: > >> >> Date: 2008/7/6 > >> >> Subject: I-D Action:draft-zhao-mext-mnp-ikev2-00.txt > >> >> To: i-d-announce@ietf.org > >> >> > >> >> > >> >> A New Internet-Draft is available from the on-line > >> >> Internet-Drafts directories. > >> >> > >> >> Title : IKEv2 based Mobile Network Prefix > >> Assignment > >> >> Author(s) : F. Zhao, et al. > >> >> Filename : draft-zhao-mext-mnp-ikev2-00.txt > >> >> Pages : 13 > >> >> Date : 2008-07-06 > >> >> > >> >> This document proposes a mechanism for the Mobile Router to > >> >> dynamically obtain the Mobile Network Prefix through IKEv2. The > >> >> mechanisms to renew, release and update the allocated > >> Mobile Network > >> >> Prefixes are also described. > >> >> > >> >> A URL for this Internet-Draft is: > >> >> > >> > http://www.ietf.org/internet-drafts/draft-zhao-mext-mnp-ikev2-00.txt > >> >> > >> >> Internet-Drafts are also available by anonymous FTP at: > >> >> ftp://ftp.ietf.org/internet-drafts/ > >> >> > >> >> Below is the data which will enable a MIME compliant mail reader > >> >> implementation to automatically retrieve the ASCII > version of the > >> >> Internet-Draft. > >> >> > >> >> > >> >> _______________________________________________ > >> >> I-D-Announce mailing list > >> >> I-D-Announce@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/i-d-announce > >> >> Internet-Draft directories: http://www.ietf.org/shadow.html > >> >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> >> _______________________________________________ > >> >> MEXT mailing list > >> >> MEXT@ietf.org > >> >> https://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 Jul 9 17:22:10 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60E223A6885; Wed, 9 Jul 2008 17:22:10 -0700 (PDT) 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 CAE723A6885 for ; Wed, 9 Jul 2008 17:22:09 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqzbPSdUlTml for ; Wed, 9 Jul 2008 17:22:08 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.250]) by core3.amsl.com (Postfix) with ESMTP id A1D323A679F for ; Wed, 9 Jul 2008 17:22:08 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so1525864and.122 for ; Wed, 09 Jul 2008 17:22:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=AoAZlGcDLqmMNiemcHOwdDEaLXoNaEPcW8mfbPCXiqM=; b=tTROSIVTfYryN4KqXvzGvIZDyqPIwEKh9QYPS76NPRj56Xo6u5oWX/8EGho/4Wlq95 IgNDSqwU+AdmsivN9kAlUpw3TPB0+ZJ+uAHWeolwRQ7M4EVWg1a0iB48ZOvBLrJBJBoA g9pWhlm1WRMB/dBYZUjQx6aFPaLdD1vJp+o3E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Jc5xGByOe8444+QvjKVfH05Ry1+PciRZSKf7vtiU6cbzwOhks/xQZkAJ26uQgiAkyF tV78RTHmCjpat0fAIFwTnc9e4ZxO7yieEBiS8dNs5fpW3tyn50MiP0cqetppOWUPGkYm NyF58AtvVXIQFhVHZDIYjv/rRflt2XIHP0KYM= Received: by 10.100.37.18 with SMTP id k18mr7185503ank.157.1215649339507; Wed, 09 Jul 2008 17:22:19 -0700 (PDT) Received: by 10.100.57.5 with HTTP; Wed, 9 Jul 2008 17:22:19 -0700 (PDT) Message-ID: Date: Wed, 9 Jul 2008 17:22:19 -0700 From: "fan zhao" To: "Vijay Devarapalli" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <20080706174502.6A6393A68F3@core3.amsl.com> Cc: mext@ietf.org Subject: Re: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-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 Vijay, Requesting the HoA/HNP during IKE_AUTH is also for home link detection. Having said that, I agree with what you said when the MN is on the foreign link. The MNP is required for the MR to operate, in addtion to the HoA/HNP. It is the most efficient way for the MR to be configured via the IKEv2. I am curious how the BU/BA based PD works on the home link? Sincerely, fan On Wed, Jul 9, 2008 at 5:10 PM, Vijay Devarapalli wrote: >> Also RFC 5026 specifies that the home address is assigned during IKE >> signaling. > > That's because you need to setup IPsec SAs based on the home address. > The home address needs to be known before the IPsec SAs are setup. Even > the binding update cannot be sent if the required SA is not in place. > > There is no such dependency on configuring the mobile network prefixes. > > Vijay > >> >> Sincerely, >> fan >> >> On Wed, Jul 9, 2008 at 5:01 PM, Vijay Devarapalli >> wrote: >> >> My understanding is that the MR does not perform the BU/BA >> >> exchange with the HA over the home link. >> > >> > Is that the only reason why you would want to use IKEv2 >> exchange instead >> > of a BU/BAck exchange? >> > >> > Vijay >> > >> >> >> >> Sincerely, >> >> fan >> >> >> >> On Wed, Jul 9, 2008 at 11:58 AM, Vijay Devarapalli >> >> wrote: >> >> > Hello Fan, >> >> > >> >> > I prefer using the Binding Update/Binding Ack exchange for >> >> assigning a >> >> > mobile network prefix to the mobile router instead of >> >> defining an IKEv2 >> >> > configuration payload for this, unless there are some significant >> >> > advantages to use IKEv2. Are there any? >> >> > >> >> > draft-zhao-mext-mnp-ikev2-00.txt does not talk about the >> >> advantages of >> >> > using IKEv2 configuration payloads over BU/BAck exchange. >> >> > >> >> > Vijay >> >> > >> >> >> -----Original Message----- >> >> >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> >> >> Behalf Of fan zhao >> >> >> Sent: Tuesday, July 08, 2008 11:24 AM >> >> >> To: mext@ietf.org >> >> >> Subject: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-00.txt >> >> >> >> >> >> Hi, >> >> >> >> >> >> We have submitted a draft on using IKEv2 to assign a >> Mobile Network >> >> >> Prefix to the Mobile Router. Comments, questions and suggestions >> >> >> are highly appreciated. >> >> >> Thanks. >> >> >> >> >> >> BR, >> >> >> Fan >> >> >> >> >> >> >> >> >> ---------- Forwarded message ---------- >> >> >> From: >> >> >> Date: 2008/7/6 >> >> >> Subject: I-D Action:draft-zhao-mext-mnp-ikev2-00.txt >> >> >> To: i-d-announce@ietf.org >> >> >> >> >> >> >> >> >> A New Internet-Draft is available from the on-line >> >> >> Internet-Drafts directories. >> >> >> >> >> >> Title : IKEv2 based Mobile Network Prefix >> >> Assignment >> >> >> Author(s) : F. Zhao, et al. >> >> >> Filename : draft-zhao-mext-mnp-ikev2-00.txt >> >> >> Pages : 13 >> >> >> Date : 2008-07-06 >> >> >> >> >> >> This document proposes a mechanism for the Mobile Router to >> >> >> dynamically obtain the Mobile Network Prefix through IKEv2. The >> >> >> mechanisms to renew, release and update the allocated >> >> Mobile Network >> >> >> Prefixes are also described. >> >> >> >> >> >> A URL for this Internet-Draft is: >> >> >> >> >> >> http://www.ietf.org/internet-drafts/draft-zhao-mext-mnp-ikev2-00.txt >> >> >> >> >> >> Internet-Drafts are also available by anonymous FTP at: >> >> >> ftp://ftp.ietf.org/internet-drafts/ >> >> >> >> >> >> Below is the data which will enable a MIME compliant mail reader >> >> >> implementation to automatically retrieve the ASCII >> version of the >> >> >> Internet-Draft. >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> I-D-Announce mailing list >> >> >> I-D-Announce@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/i-d-announce >> >> >> Internet-Draft directories: http://www.ietf.org/shadow.html >> >> >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> _______________________________________________ >> >> >> MEXT mailing list >> >> >> MEXT@ietf.org >> >> >> https://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 Jul 9 18:57:22 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAE533A6936; Wed, 9 Jul 2008 18:57:22 -0700 (PDT) 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 D26A73A6936 for ; Wed, 9 Jul 2008 18:57:20 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvZVCQr5ggt7 for ; Wed, 9 Jul 2008 18:57:20 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id AD9BB3A686D for ; Wed, 9 Jul 2008 18:57:19 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Jul 2008 21:57:30 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-00.txt Thread-Index: AcjiIwSUkEUaVwAKTi+LTBejMi8piwADOS0A References: <20080706174502.6A6393A68F3@core3.amsl.com> From: "Vijay Devarapalli" To: "fan zhao" Cc: mext@ietf.org Subject: Re: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-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 MNP is required for the MR to operate, in addtion > to the HoA/HNP. It is the most efficient way for the MR > to be configured via the IKEv2. Don't agree on the efficiency part. The mobile router does not advertise the mobile network prefixes in its mobile network until the BU/BAck exchange complete. > I am curious how the BU/BA based PD works on the home link? It doesn't. This is one of the reasons I wrote draft-devarapalli-mext-mipv6-home-link-01.txt, which allows the mobile router to send a binding update from the home link. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jul 9 23:41:48 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAB9A3A6970; Wed, 9 Jul 2008 23:41:47 -0700 (PDT) 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 4D2463A6962 for ; Wed, 9 Jul 2008 23:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 2olkeLtwKqx8 for ; Wed, 9 Jul 2008 23:41:46 -0700 (PDT) Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id 605A73A695B for ; Wed, 9 Jul 2008 23:41:46 -0700 (PDT) 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 1KGpqd-0000ux-6B; Thu, 10 Jul 2008 08:41:47 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: "Vijay Devarapalli" References: <20080706174502.6A6393A68F3@core3.amsl.com> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:080710:fanzhao828@gmail.com::QxiKbJk9Oe5a74gQ:000000000000000000000000000000000000000000Qfd X-Hashcash: 1:20:080710:vijay@wichorus.com::SF9in0yrwX/+pFnv:00000000000000000000000000000000000000000002WXq X-Hashcash: 1:20:080710:mext@ietf.org::M7oqlvKVxZRr6HTx:00003KWl Date: Thu, 10 Jul 2008 08:41:10 +0200 In-Reply-To: (Vijay Devarapalli's message of "Wed, 9 Jul 2008 20:10:04 -0400") Message-ID: <877ibudywp.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-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="===============2069761494==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============2069761494== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Hi Vijay, "Vijay Devarapalli" writes: >> Also RFC 5026 specifies that the home address is assigned during IKE >> signaling. > > That's because you need to setup IPsec SAs based on the home address. > The home address needs to be known before the IPsec SAs are setup. Even > the binding update cannot be sent if the required SA is not in place. No relation with the thread: are you aware of any implementation of that mechanism? Cheers, a+ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIda8OAlWVfAR6UCYRAsx2AJwOuwGegyY3ExKKi1dKbSj43/DTBACePhxP 892YAKfL3r3YYAuBd3sdBaE= =n4cD -----END PGP SIGNATURE----- --=-=-=-- --===============2069761494== 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 --===============2069761494==-- From mext-bounces@ietf.org Thu Jul 10 09:25:25 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8281D3A6844; Thu, 10 Jul 2008 09:25:25 -0700 (PDT) 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 2F6293A67A3 for ; Thu, 10 Jul 2008 09:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[AWL=-0.773, BAYES_00=-2.599, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNP+V3LaP1Tv for ; Thu, 10 Jul 2008 09:25:23 -0700 (PDT) Received: from web84314.mail.re1.yahoo.com (web84314.mail.re1.yahoo.com [69.147.74.193]) by core3.amsl.com (Postfix) with SMTP id 1479F3A67EA for ; Thu, 10 Jul 2008 09:25:22 -0700 (PDT) Received: (qmail 27656 invoked by uid 60001); 10 Jul 2008 16:25:34 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=rf5DcqPeJDnyfvlQe+8iJV/KPcVTmET7YTDE9zE0IAEPvMn4c8/FmUinjpg4lQsec6IkdHrfGe7D9cLXdL4akSRiITcLvkK/CxJTaOf6MMXUI0Pj7cnO/7FNDpBUyg8rW/E/NGmxEPF+40m/tSJYpFuRWRbyUNlO3ILaiPON4uI=; Received: from [206.16.17.212] by web84314.mail.re1.yahoo.com via HTTP; Thu, 10 Jul 2008 09:25:33 PDT X-Mailer: YahooMailRC/975.45 YahooMailWebService/0.7.199 Date: Thu, 10 Jul 2008 09:25:33 -0700 (PDT) From: Behcet Sarikaya To: Vijay Devarapalli MIME-Version: 1.0 Message-ID: <86867.27588.qm@web84314.mail.re1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-00.txt 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="===============1509970881==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1509970881== Content-Type: multipart/alternative; boundary="0-91714043-1215707133=:27588" --0-91714043-1215707133=:27588 Content-Type: text/plain; charset=us-ascii Hi Vijay, There is also this draft: http://tools.ietf.org/id/draft-sarikaya-mext-prefix-delegation-00.txt which adds DHCPv6 PD into Prefix Request/Confirm signaling in Pascal's draft. You mentioned another draft on homelink BUs. I was talking about an amalgamation of all these wonderful works . Regards, behcet ----- Original Message ---- From: Vijay Devarapalli To: Behcet Sarikaya Cc: mext@ietf.org; fan zhao Sent: Wednesday, July 9, 2008 7:04:13 PM Subject: RE: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-00.txt Hi Behcet, > Hi Vijay, > I also think that BU/BA exchange is a better solution as > the second solution Pascal mentioned. There are a few > problems like the one below to be resolved. We are going to > work out an I-D on this soon. The document already exists. http://tools.ietf.org/id/draft-ietf-nemo-prefix-delegation-02.txt I guess we don't need yet another draft on this. Vijay --0-91714043-1215707133=:27588 Content-Type: text/html; charset=us-ascii
Hi Vijay,
  There is also this draft:
http://tools.ietf.org/id/draft-sarikaya-mext-prefix-delegation-00.txt
which adds DHCPv6 PD into Prefix Request/Confirm signaling in Pascal's draft. You mentioned another draft on homelink BUs. I was talking about an amalgamation of all these wonderful works .

Regards,

behcet

----- Original Message ----
From: Vijay Devarapalli <vijay@wichorus.com>
To: Behcet Sarikaya <sarikaya@ieee.org>
Cc: mext@ietf.org; fan zhao <fanzhao828@gmail.com>
Sent: Wednesday, July 9, 2008 7:04:13 PM
Subject: RE: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-00.txt

Hi Behcet,

> Hi Vijay,
>    I also think that BU/BA exchange is a better solution as
> the second solution Pascal mentioned. There are a few
> problems like the one below to be resolved. We are going to
> work out an I-D on this soon.

The document already exists.
http://tools.ietf.org/id/draft-ietf-nemo-prefix-delegation-02.txt

I guess we don't need yet another draft on this.

Vijay
--0-91714043-1215707133=:27588-- --===============1509970881== 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 --===============1509970881==-- From mext-bounces@ietf.org Thu Jul 10 11:08:23 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25E803A69AA; Thu, 10 Jul 2008 11:08:23 -0700 (PDT) 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 6E55E3A692A for ; Thu, 10 Jul 2008 11:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EzehVxFHgNp for ; Thu, 10 Jul 2008 11:08:21 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 5C4AA3A69AA for ; Thu, 10 Jul 2008 11:08:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=iqSyH11f54/OnNdUdHkK/5U8N/w6L7MknyE61JY4xmewIi8LWIKX8BurIFrT7rJN; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [75.26.137.116] (helo=[10.166.255.89]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1KH0ZE-0004ki-71; Thu, 10 Jul 2008 14:08:32 -0400 Message-ID: <4876501E.4060908@earthlink.net> Date: Thu, 10 Jul 2008 11:08:30 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Suresh Krishnan References: <486B8EDD.4070807@ericsson.com> In-Reply-To: <486B8EDD.4070807@ericsson.com> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5271dc38cf8100765df1bace963089f5c5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Cc: mext@ietf.org Subject: Re: [MEXT] New Text for home link detection in RFC3775bis 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Suresh, I'm creating a new issue for "home link detection" to go into the issue tracker. Your suggested text seems to have found consensus for resolving the issue, as long as it is located in a new section (as suggested in later messages). However, I would like to suggest a textual revision and simplification. Most of the revision relies on pointing out that one has to get a home network prefix before using it to compare against the list of prefixes received in the RA. The other revision, which I hope is O.K., is to dispense with creating the new acronyms CMA and CLPL. I am biased against having acronyms that are not used elsewhere in the document. Here is my result: NEW TEXT ======== Section 11.5.X Home Link Detection When an MN detects that it has arrived on a new link using the movement detection algorithm in use (Section 11.5.1x) it performs the following steps to determine if it is on the home link. o The MN performs the procedure described in Section 11.5.2x and configures an address. It also keeps track of all the on-link prefix(es) received in the RA along with their prefix lengths. o If the home prefix has not been statically configured the MN uses some form of bootstrapping procedure (e.g. RFC5026) to determine the home prefix. o Given the availability of the home prefix, the MN checks whether or not the home prefix matches one of the prefixes received in the RA. If it does, the MN concludes that it has returned home. ================================================ It is also a bit tricky to determine where to locate this new section. The current organization of section 11.5 is as follows: 11.5. Movement . . . . . . . . . . . . . . . . . . . . . . . . 123 11.5.1. Movement Detection . . . . . . . . . . . . . . . . . 123 11.5.2. Forming New Care-of Addresses . . . . . . . . . . . . 125 11.5.3. Using Multiple Care-of Addresses . . . . . . . . . . 126 11.5.4. Returning Home . . . . . . . . . . . . . . . . . . . 127 After reading through the text, I think the new subsection would fit best after the current 11.5.1, making it a new subsection 11.5.2. ================================================ By the way, given the new subsection, the first sentence of the _current_ subsection 11.5.2 (to become subsection 11.5.3) needs to be changed: OLD: After detecting that it has moved a mobile node SHOULD generate a new primary care-of address using normal IPv6 mechanisms. NEW: After detecting that it has moved to a link away from home, a mobile node SHOULD generate a new primary care-of address using normal IPv6 mechanisms. ================================================= Strictly speaking, the names of section 11.5{,.1} are probably wrong. Perhaps they should be something more like "New Link{s, Detection}". This is because a node can require establishment of a new link without any movement. For instance, as we all know, sometimes wireless access points become unreachable even if we are standing still, and then we have to search for another access point in range. I haven't decided yet whether to actually go ahead and rename the sections. Comments are welcome! Regards, Charlie P. Suresh Krishnan wrote: > The WG had consensus to fold in text from draft-krishnan-mext-hld into > RFC3775bis. Here is the proposed text for doing so. Feel free to edit. > > > > This change is made in Section 11.5.4 > > OLD TEXT > ======== > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > > NEW TEXT > ======== > When an MN detects that it has arrived on a new link using the > movement detection algorithm in use (Section 11.5.1) it performs the > following steps to determine if it is on the home link. > > o The MN performs the procedure described in Section 11.5.2 and > configures an address referred to as the Current MN Address (CMA). > It also stores all the on-link prefix(es) received in the RA along > with their prefix lengths in a conceptual list called the Current > Link Prefix List (CLPL). > > o If the home prefix has been statically pre-configured on the MN > it checks if the home prefix matches one of the prefixes in the > CLPL. If it does, the MN concludes that it has returned home. > > o If the home prefix has not been statically configured the MN uses > some form of bootstrapping procedure (e.g. RFC5026) to determine > the home prefix. It then checks if the home prefix matches one of > the prefixes in the CLPL. If it does, the MN concludes that it has > returned home. > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://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 Jul 10 11:46:50 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A30E53A69AA; Thu, 10 Jul 2008 11:46:50 -0700 (PDT) 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 90D723A6816 for ; Thu, 10 Jul 2008 11:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gavqla89Z4do for ; Thu, 10 Jul 2008 11:46:48 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id E62BE3A6A10 for ; Thu, 10 Jul 2008 11:46:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1215715611; x=1247251611; h=x-mimeole:content-class:mime-version:content-type: content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator: thread-topic:thread-index:references:from:to:cc: x-originalarrivaltime:x-ironport-av; z=X-MimeOLE:=20Produced=20By=20Microsoft=20Exchange=20V6.5 |Content-class:=20urn:content-classes:message |MIME-Version:=201.0|Content-Type:=20text/plain=3B=0D=0A =09charset=3D"us-ascii"|Content-Transfer-Encoding:=20quot ed-printable|Subject:=20RE:=20[MEXT]=20[mext]=20#11:=20De -registration=20when=20returning=20home=20[VijayDevarapal li=20]|Date:=20Thu,=2010=20Jul=202008 =2011:45:56=20-0700|Message-ID:=20|In-Reply-To: =20|X-MS-Has-Attach:=20|X-MS-TNEF-Correlator: =20|Thread-Topic:=20[MEXT]=20[mext]=20#11:=20De-registrat ion=20when=20returning=20home=20[VijayDevarapalli=20]|Thread-Index:=20Acjh96r/rFIBubkDS0+S4gL1 W6Yv2AAxHPwQAAAwv6A=3D|References:=20<010801c8e16b$5c2889 d0$7471510a@psl.local>=20=20=20=20=20=20 =20=20|From:=20"Giaretta,=20Gerardo"=20|To:=20"Vijay=20Devarapalli"=20,=0D=0A=20=20=20=20=20=20=20=20"Sri=20Gundavell i"=20|Cc:=20"Benjamin=20Lim"=20,=20, =0D=0A=20=20=20=20=20=20=20=20 |X-OriginalArrivalTime:=2010=20Jul=202008=2018:45:57.0254 =20(UTC)=20FILETIME=3D[309FE260:01C8E2BD]|X-IronPort-AV: =20E=3DMcAfee=3Bi=3D"5200,2160,5335"=3B=20a=3D"4437946"; bh=DQ3mJVlNlTXbwUxncAezhJhojm/iK7xT8k5KL9p8qE4=; b=emrHDvSvASQyWVcShqdZ1K5Z17N4U64pr+W+kqv016WeRLI0SSm6THL6 fAd/hUDE/v1WM9IMd5ieCknUg9oGSPHvOK4hHcJgc08NE/SCCNc46y+v5 KzQVjWDOMKB2SrAOxAxOohG3wvazhbZlJWQwRdgOOrl47no6Ev7GhPlqY 8=; X-IronPort-AV: E=McAfee;i="5200,2160,5335"; a="4437946" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Jul 2008 11:46:38 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m6AIkcgE032122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 10 Jul 2008 11:46:38 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m6AIkbM9003495; Thu, 10 Jul 2008 11:46:37 -0700 Received: from NAEX12.na.qualcomm.com ([129.46.51.247]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Jul 2008 11:45:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Jul 2008 11:45:56 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] Thread-Index: Acjh96r/rFIBubkDS0+S4gL1W6Yv2AAxHPwQAAAwv6A= References: <010801c8e16b$5c2889d0$7471510a@psl.local> From: "Giaretta, Gerardo" To: "Vijay Devarapalli" , "Sri Gundavelli" X-OriginalArrivalTime: 10 Jul 2008 18:45:57.0254 (UTC) FILETIME=[309FE260:01C8E2BD] Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] 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 would add the following sentence for the sake of clarity at the end of your text: Until the mobile node sends a de-registration Binding Update, it will not be able to send and receive packets using its home address from the home link. The home agent will continue to intercept all packets sent to the mobile's home address and tunnel to the previously registered care-of address. Note that this text does not contain any normative text, just clarifies what happens. Gerardo > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay@wichorus.com] > Sent: Thursday, July 10, 2008 11:42 AM > To: Sri Gundavelli > Cc: Giaretta, Gerardo; Benjamin Lim; charliep@computer.org; mext@ietf.org > Subject: RE: [MEXT] [mext] #11: De-registration when returning home > [VijayDevarapalli ] > > Hi Sri, > > > Below text seems ok to me, except the new concept of multiple > > interface > > MN in the context of 3775. I'd simply state, "if the MN wants to use > > the HoA on the home link, it MUST send a dereg" ...., from the > > MIP perspective we can require that. From HA perspective in > > the context > > of ND, what HA should do if the address is taken over, we need to > > discuss further, as say above. > > Is this what you are looking for? > > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > To be able to send and receive packets using its home address from > the home link, the mobile node MUST send a Binding Update to its > home agent to instruct its home agent to no longer intercept or > tunnel packets for it. > > I am fine with this as well, since it avoids talking about multiple > interfaces. Gerardo? > > Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jul 10 11:49:36 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C9523A69F5; Thu, 10 Jul 2008 11:49:36 -0700 (PDT) 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 DF10A3A69F5 for ; Thu, 10 Jul 2008 11:49:34 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ugLHuR0zxYw for ; Thu, 10 Jul 2008 11:49:33 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id D39E43A6816 for ; Thu, 10 Jul 2008 11:49:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,339,1212364800"; d="scan'208";a="51459584" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 10 Jul 2008 18:49:49 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m6AInnpG025911; Thu, 10 Jul 2008 11:49:49 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m6AInnaT014166; Thu, 10 Jul 2008 18:49:49 GMT Date: Thu, 10 Jul 2008 11:49:49 -0700 (PDT) From: Sri Gundavelli To: Vijay Devarapalli In-Reply-To: Message-ID: References: <010801c8e16b$5c2889d0$7471510a@psl.local> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=691; t=1215715789; x=1216579789; c=relaxed/simple; s=sjdkim3002; 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]=20[mext]=20#11=3A=20De-registrat ion=20when=20returning=20home=0A=20[VijayDevarapalli=20] |Sender:=20; bh=JN5PLZPeHwkoDFy3OEE2gmT8JSq2vVdt9v51T1IrH1Y=; b=J8vMMM/yAVZ9dzJHiOHlfn8evXjGr9W8w+dKrsNTjnw1JoHSC3mt0FxUcc a9fl/SXjwDPptvGUW1IW+AHHpGYYiIa39vPfk6BHIEsWZiX7m64E8SIips2/ T2Jibm65fM; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I'm Ok with this text. Sri On Thu, 10 Jul 2008, Vijay Devarapalli wrote: > Is this what you are looking for? > > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > To be able to send and receive packets using its home address from > the home link, the mobile node MUST send a Binding Update to its > home agent to instruct its home agent to no longer intercept or > tunnel packets for it. > > I am fine with this as well, since it avoids talking about multiple > interfaces. Gerardo? > > Vijay > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jul 10 11:53:35 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE09F3A67D7; Thu, 10 Jul 2008 11:53:35 -0700 (PDT) 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 990663A67D7 for ; Thu, 10 Jul 2008 11:53:34 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4oRu3JIGcD1 for ; Thu, 10 Jul 2008 11:53:33 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 554D03A67A7 for ; Thu, 10 Jul 2008 11:53:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,339,1212364800"; d="scan'208";a="64534265" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 10 Jul 2008 18:53:46 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m6AIrjL5002865; Thu, 10 Jul 2008 11:53:45 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m6AIrj8q016722; Thu, 10 Jul 2008 18:53:45 GMT Date: Thu, 10 Jul 2008 11:53:44 -0700 (PDT) From: Sri Gundavelli To: "Giaretta, Gerardo" In-Reply-To: Message-ID: References: <010801c8e16b$5c2889d0$7471510a@psl.local> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2451; t=1215716025; x=1216580025; c=relaxed/simple; s=sjdkim3002; 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]=20[mext]=20#11=3A=20De-registrat ion=20when=20returning=20home=0A=20[VijayDevarapalli=20] |Sender:=20; bh=uBYZiKHLy4Fvq+MX+3JD0/i+mxFfcSqh337gM4mifzg=; b=o/xvXh2JEQdc8+ToG+qp8GfIjKf9ZChz5ZrcIFeoAyzsz2XSHVKnmx63Ug lvc9snJPOderbg/HpJyBGkvpdO9I5s9N/mnjO8PgCKz8FXunMLjtsxA0gW+7 tW+iwEYM/B; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Gerardo, On Thu, 10 Jul 2008, Giaretta, Gerardo wrote: > I would add the following sentence for the sake of clarity at the end of > your text: > > Until the mobile node sends a de-registration Binding Update, > it will not be able to send and receive packets using its home > address from the home link. The home agent will continue to > intercept > all packets sent to the mobile's home address and tunnel to the > previously registered care-of address. > > Note that this text does not contain any normative text, just clarifies > what happens. > But, nothing stops the mobile node from reclaiming that address and start using it. HA cannot stop it. From MIP perspective, we can madate the DeReg and if it does not do that, its a violation, but, we cannot say MN wont be able to use that address without sending a dereg, that modifies 4861. Also, we need to discuss what the HA should do, if the mobile reclaims its address, but does not send a dereg. Sri > Gerardo > >> -----Original Message----- >> From: Vijay Devarapalli [mailto:vijay@wichorus.com] >> Sent: Thursday, July 10, 2008 11:42 AM >> To: Sri Gundavelli >> Cc: Giaretta, Gerardo; Benjamin Lim; charliep@computer.org; > mext@ietf.org >> Subject: RE: [MEXT] [mext] #11: De-registration when returning home >> [VijayDevarapalli ] >> >> Hi Sri, >> >>> Below text seems ok to me, except the new concept of multiple >>> interface >>> MN in the context of 3775. I'd simply state, "if the MN wants to use >>> the HoA on the home link, it MUST send a dereg" ...., from the >>> MIP perspective we can require that. From HA perspective in >>> the context >>> of ND, what HA should do if the address is taken over, we need to >>> discuss further, as say above. >> >> Is this what you are looking for? >> >> A mobile node detects that it has returned to its home link through >> the movement detection algorithm in use (Section 11.5.1), when the >> mobile node detects that its home subnet prefix is again on-link. >> To be able to send and receive packets using its home address from >> the home link, the mobile node MUST send a Binding Update to its >> home agent to instruct its home agent to no longer intercept or >> tunnel packets for it. >> >> I am fine with this as well, since it avoids talking about multiple >> interfaces. Gerardo? >> >> Vijay > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jul 10 11:55:38 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 119833A69F5; Thu, 10 Jul 2008 11:55:38 -0700 (PDT) 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 C299E3A69AA for ; Thu, 10 Jul 2008 11:55:36 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93sOWSDTcOlj for ; Thu, 10 Jul 2008 11:55:35 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 4AD793A69F5 for ; Thu, 10 Jul 2008 11:55:35 -0700 (PDT) Received: from [75.26.137.116] (helo=[10.166.255.89]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KH1Iw-00087u-7m; Thu, 10 Jul 2008 14:55:46 -0400 Message-ID: <48765B30.3030308@computer.org> Date: Thu, 10 Jul 2008 11:55:44 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Vijay Devarapalli References: <010801c8e16b$5c2889d0$7471510a@psl.local> In-Reply-To: X-ELNK-Trace: 5a185a306015b1a28a306fc704168558239a348a220c2609133907ffe587763a4ebfd5f3f8e3288e2601a10902912494350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Cc: mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: charliep@computer.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Vijay, Looks good to me! Regards, Charlie P. Vijay Devarapalli wrote: > Fine with me. So the new text is > > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > To be able to send and receive packets using its home address from > the home link, the mobile node MUST send a Binding Update to its > home agent to instruct its home agent to no longer intercept or > tunnel packets for it. Until the mobile node sends a de-registration > Binding Update, it will not be able to send and receive packets > using its home address from the home link. The home agent will > continue to intercept all packets sent to the mobile's home address > and tunnel to the previously registered care-of address. > > Is everyone ok with this? > > Vijay > > >> -----Original Message----- >> From: Giaretta, Gerardo [mailto:gerardog@qualcomm.com] >> Sent: Thursday, July 10, 2008 11:46 AM >> To: Vijay Devarapalli; Sri Gundavelli >> Cc: Benjamin Lim; charliep@computer.org; mext@ietf.org >> Subject: RE: [MEXT] [mext] #11: De-registration when >> returning home [VijayDevarapalli ] >> >> I would add the following sentence for the sake of clarity at >> the end of >> your text: >> >> Until the mobile node sends a de-registration Binding Update, >> it will not be able to send and receive packets using its home >> address from the home link. The home agent will continue to >> intercept >> all packets sent to the mobile's home address and tunnel to the >> previously registered care-of address. >> >> Note that this text does not contain any normative text, just >> clarifies >> what happens. >> >> Gerardo >> >>> -----Original Message----- >>> From: Vijay Devarapalli [mailto:vijay@wichorus.com] >>> Sent: Thursday, July 10, 2008 11:42 AM >>> To: Sri Gundavelli >>> Cc: Giaretta, Gerardo; Benjamin Lim; charliep@computer.org; >> mext@ietf.org >>> Subject: RE: [MEXT] [mext] #11: De-registration when returning home >>> [VijayDevarapalli ] >>> >>> Hi Sri, >>> >>>> Below text seems ok to me, except the new concept of multiple >>>> interface >>>> MN in the context of 3775. I'd simply state, "if the MN >> wants to use >>>> the HoA on the home link, it MUST send a dereg" ...., from the >>>> MIP perspective we can require that. From HA perspective in >>>> the context >>>> of ND, what HA should do if the address is taken over, we need to >>>> discuss further, as say above. >>> Is this what you are looking for? >>> >>> A mobile node detects that it has returned to its home >> link through >>> the movement detection algorithm in use (Section >> 11.5.1), when the >>> mobile node detects that its home subnet prefix is again on-link. >>> To be able to send and receive packets using its home >> address from >>> the home link, the mobile node MUST send a Binding Update to its >>> home agent to instruct its home agent to no longer intercept or >>> tunnel packets for it. >>> >>> I am fine with this as well, since it avoids talking about multiple >>> interfaces. Gerardo? >>> >>> Vijay > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jul 10 12:05:12 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B25023A6A84; Thu, 10 Jul 2008 12:05:12 -0700 (PDT) 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 1F2E328C17B for ; Thu, 10 Jul 2008 12:05:11 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2sOetrRpnBb for ; Thu, 10 Jul 2008 12:05:10 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 3EEAF3A6A80 for ; Thu, 10 Jul 2008 12:04:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,339,1212364800"; d="scan'208";a="51468682" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 10 Jul 2008 19:04:47 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m6AJ4lDY030153; Thu, 10 Jul 2008 12:04:47 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m6AJ4kE0029153; Thu, 10 Jul 2008 19:04:47 GMT Date: Thu, 10 Jul 2008 12:04:46 -0700 (PDT) From: Sri Gundavelli To: Vijay Devarapalli In-Reply-To: Message-ID: References: <010801c8e16b$5c2889d0$7471510a@psl.local> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=326; t=1215716687; x=1216580687; c=relaxed/simple; s=sjdkim4002; 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]=20[mext]=20#11=3A=20De-registrat ion=20when=20returning=20home=0A=20[VijayDevarapalli=20] |Sender:=20; bh=wAKKhX58QPgH8GcXI3jpuJv8qYydj/+EK61md/rVSMs=; b=tXp5ilAqiWJHD75jTFJglUHCgzt0TIP3aHbdexuTyJxjfXjMHtQrO8Gg3B 76QrnuDTbFFgTyrrjdA7E4gaCUi5et4CyIrZiSpD19GtK0Xh3SNB8Ljaz9bB OsFQ7A/8z3; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Thu, 10 Jul 2008, Vijay Devarapalli wrote: >> But, nothing stops the mobile node from reclaiming that address and >> start using it. HA cannot stop it. > Sorry, do not mean to beat this thread to death ... So, who gets the packets, if HA does not stop proxying and MN starts defending its address ? Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jul 10 12:18:33 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 199873A6A77; Thu, 10 Jul 2008 12:18:33 -0700 (PDT) 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 AAAC73A6A77 for ; Thu, 10 Jul 2008 12:18:32 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7EH6J3FfHdt for ; Thu, 10 Jul 2008 12:18:31 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id BE7403A6A01 for ; Thu, 10 Jul 2008 12:18:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,339,1212364800"; d="scan'208";a="36391802" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 10 Jul 2008 19:18:47 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6AJIlu2004849; Thu, 10 Jul 2008 12:18:47 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m6AJIlJ5005640; Thu, 10 Jul 2008 19:18:47 GMT Date: Thu, 10 Jul 2008 12:18:47 -0700 (PDT) From: Sri Gundavelli To: Vijay Devarapalli In-Reply-To: Message-ID: References: <010801c8e16b$5c2889d0$7471510a@psl.local> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1414; t=1215717527; x=1216581527; 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]=20[mext]=20#11=3A=20De-registrat ion=20when=20returning=20home=0A=20[VijayDevarapalli=20] |Sender:=20; bh=+DKafgByv77ncXVZl9JkR5+t3WFALOxleADGHL30aAI=; b=veiD1xXtV0byhbTjgXdW6goMri6LNtSlZXX+dXDjQ8yaDrs2rR91SZ7SPd LuQXNA5wEIOfY+1LbsKxN3A1mnBG/igJ8ncVsXf0BP2QFbAqybUTX5ymP8sF TdIp41YLO+; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Vijay, On Thu, 10 Jul 2008, Vijay Devarapalli wrote: >> Sorry, do not mean to beat this thread to death ... >> >> So, who gets the packets, if HA does not stop proxying and MN >> starts defending its address ? > > This shouldn't happen. According to RFC 3775, a Mobile IPv6 mobile node > should not claim the address (send a neighbor advertisement for it), > until it gets a Binding Ack from the home agent in response to its > de-registration Binding Update. This is clearly specified in RFC 3775. > There are three things here: 1.) MIP requirement of what the MN should do when is back home - which is send a dereg before it uses its hoA. I'm fine with this, lets mandate that and ok with this. 2.) Second part: can the MN use its HoA with out sending the BU. - This may be a MIP violation - But, a MN can very well do so and nothing can stop it, its the legitimate owner, who owns that address and I'm not even talking about SEND assertion on that address. 3.) What the HA should do in such error case, to be discussed. I'm saying, #2 and #3 needs discussion. Lets simply state the requirement from MIP persective on "returning home". Now the error case, lets discuss further. I think, MN will be able to use its HoA with out sending a dereg. If you can stick to you original text, that will be fine, assuming Gerardo is ok with it. Thanks Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jul 10 13:16:06 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C04023A6A84; Thu, 10 Jul 2008 13:16:06 -0700 (PDT) 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 091A13A6A84 for ; Thu, 10 Jul 2008 13:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhJ+3hQIlZWy for ; Thu, 10 Jul 2008 13:16:05 -0700 (PDT) Received: from web84308.mail.re1.yahoo.com (web84308.mail.re1.yahoo.com [69.147.74.187]) by core3.amsl.com (Postfix) with SMTP id DACE93A69EB for ; Thu, 10 Jul 2008 13:16:04 -0700 (PDT) Received: (qmail 63843 invoked by uid 60001); 10 Jul 2008 20:16:20 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=M6Vojif+492Vd1SZVunp2GDGdx+tn5CwpbWvZQ1b0MkYfrnFoWfE0qYKFHPtAdq3yTe397Uus01tRJqlVuUT4WnCeVKmN5TVOo0pcyPvFh3zTgKDQllfoyVqt2Vk7pcljUq1SSJ4T8JJgZsoscyy1IIykhi2hti6v4Y+sq1AHok=; Received: from [206.16.17.212] by web84308.mail.re1.yahoo.com via HTTP; Thu, 10 Jul 2008 13:16:20 PDT X-Mailer: YahooMailRC/975.45 YahooMailWebService/0.7.199 Date: Thu, 10 Jul 2008 13:16:20 -0700 (PDT) From: Behcet Sarikaya To: Vijay Devarapalli , fan zhao MIME-Version: 1.0 Message-ID: <206782.62863.qm@web84308.mail.re1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-00.txt 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="===============0800184653==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0800184653== Content-Type: multipart/alternative; boundary="0-1873806748-1215720980=:62863" --0-1873806748-1215720980=:62863 Content-Type: text/plain; charset=us-ascii ----- Original Message ---- From: Vijay Devarapalli To: fan zhao Cc: mext@ietf.org Sent: Wednesday, July 9, 2008 8:57:30 PM Subject: Re: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-00.txt > The MNP is required for the MR to operate, in addtion > to the HoA/HNP. It is the most efficient way for the MR > to be configured via the IKEv2. Don't agree on the efficiency part. The mobile router does not advertise the mobile network prefixes in its mobile network until the BU/BAck exchange complete. [behcet] Can we then say that even in draft-ietf-mext-nemo-pd it is better to encapsulate native DHCP PD messages in BU/BA? This also guarantees that there is a binding. Regards, Behcet --0-1873806748-1215720980=:62863 Content-Type: text/html; charset=us-ascii


----- Original Message ----
From: Vijay Devarapalli <vijay@wichorus.com>
To: fan zhao <fanzhao828@gmail.com>
Cc: mext@ietf.org
Sent: Wednesday, July 9, 2008 8:57:30 PM
Subject: Re: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-00.txt

> The MNP is required for the MR to operate, in addtion
> to the HoA/HNP. It is the most efficient way for the MR
> to be configured via the IKEv2.

Don't agree on the efficiency part. The mobile router does not advertise
the mobile network prefixes in its mobile network until the BU/BAck
exchange complete.

[behcet] Can we then say that even in draft-ietf-mext-nemo-pd

it is better to encapsulate native DHCP PD messages in BU/BA? This also guarantees that there is a binding.

Regards,

Behcet
--0-1873806748-1215720980=:62863-- --===============0800184653== 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 --===============0800184653==-- From mext-bounces@ietf.org Thu Jul 10 13:17:35 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89BA53A69EB; Thu, 10 Jul 2008 13:17:35 -0700 (PDT) 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 833633A6A8A for ; Thu, 10 Jul 2008 13:17:34 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdIuLzVt4tCp for ; Thu, 10 Jul 2008 13:17:33 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id A46EB3A6824 for ; Thu, 10 Jul 2008 13:17:33 -0700 (PDT) Received: from [66.245.12.28] (helo=[192.168.1.4]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KH2aH-00049f-65; Thu, 10 Jul 2008 16:17:47 -0400 Message-ID: <48766E60.8000502@computer.org> Date: Thu, 10 Jul 2008 13:17:36 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Sri Gundavelli References: <010801c8e16b$5c2889d0$7471510a@psl.local> In-Reply-To: X-ELNK-Trace: 5a185a306015b1a28a306fc704168558239a348a220c260941e73d703c16b26cf2006fc419d6624ca8438e0f32a48e08350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.245.12.28 Cc: mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: charliep@computer.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Sri, Sri Gundavelli wrote: > 2.) Second part: can the MN use its HoA with out sending the BU. > > - This may be a MIP violation > - But, a MN can very well do so and nothing can stop it, its > the legitimate owner, who owns that address and I'm not > even talking about SEND assertion on that address. A "disobedient" mobile node can do a lot of things to screw up the protocol. It would take a long (err... I mean, "a lot longer") document to include all cases. > 3.) What the HA should do in such error case, to be discussed. It is not clear to me that this has to be discussed, especially in the absence of any evidence that there exists a problem that needs to be solved. So, I would somehow expect that discussion on this point should not impede consensus on the rest of the issue. However, if there is a simple way to reword the text to take your concerns into account without losing the consensus, I'd be happy to go along. Regards, Charlie P. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jul 10 13:48:21 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18AD43A6921; Thu, 10 Jul 2008 13:48:21 -0700 (PDT) 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 E98BF3A69F5 for ; Thu, 10 Jul 2008 13:48:19 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMZZUFTP9Vvw for ; Thu, 10 Jul 2008 13:48:19 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id F07373A6929 for ; Thu, 10 Jul 2008 13:48:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,340,1212364800"; d="scan'208";a="36411850" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 10 Jul 2008 20:48:33 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6AKmXjU010337; Thu, 10 Jul 2008 13:48:33 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m6AKmXct016313; Thu, 10 Jul 2008 20:48:33 GMT Date: Thu, 10 Jul 2008 13:48:33 -0700 (PDT) From: Sri Gundavelli To: "Charles E. Perkins" In-Reply-To: <48766E60.8000502@computer.org> Message-ID: References: <010801c8e16b$5c2889d0$7471510a@psl.local> <48766E60.8000502@computer.org> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1228; t=1215722913; x=1216586913; c=relaxed/simple; s=sjdkim1004; 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]=20[mext]=20#11=3A=20De-registrat ion=20when=20returning=20home=0A=20[VijayDevarapalli=20] |Sender:=20; bh=Bw2rICKadTphK7Kc0+ZwvcdHd16G0pqBHGTm001uEis=; b=tvABpyNwVFQ6wCJk2v0m6gWOhYxrEBFDEW1rxsQ+nkuH9FSH0qPksAtJws RZ7J+2zHxU2umjVhTTMNCOMoNztKV3TlH4OpOZ4O6pjO+rXVxpJPH971OdEh YxOe9ixzOnmRdhHeQ3twDJhnq3/XEO8RmD8Wne3trLcqfr6rozVek=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Charlie, On Thu, 10 Jul 2008, Charles E. Perkins wrote: > It is not clear to me that this has to be discussed, > especially in the absence of any evidence that there > exists a problem that needs to be solved. So, I would > somehow expect that discussion on this point should not > impede consensus on the rest of the issue. > There were some discussions on this error case and the text where it might require some minor corrections. But, ignoring this error scenario, I'm ok with the text proposed by Vijay earlier today. Its better if we dont speculate on if the MN will be able to use its home address without sending the BU or not. That is a general ND issue and offcourse has some bearing on the HA, for that error case. The key point of this issue on MN's operation on the home-link, we can just state that the "MN MUST send a dereg if its intends to use its HoA on the home-link" and leave it there. That should close this specific issue and without loosing the consensus. Regards Sri > However, if there is a simple way to reword the text > to take your concerns into account without losing the > consensus, I'd be happy to go along. > > Regards, > Charlie P. > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jul 10 14:02:48 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0E133A68BD; Thu, 10 Jul 2008 14:02:48 -0700 (PDT) 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 2C8163A68BD for ; Thu, 10 Jul 2008 14:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OC6+OXZnUs2h for ; Thu, 10 Jul 2008 14:02:46 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 537773A680F for ; Thu, 10 Jul 2008 14:02:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1215723782; x=1247259782; h=x-mimeole:content-class:mime-version:content-type: content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator: thread-topic:thread-index:references:from:to:cc: x-originalarrivaltime:x-ironport-av; z=X-MimeOLE:=20Produced=20By=20Microsoft=20Exchange=20V6.5 |Content-class:=20urn:content-classes:message |MIME-Version:=201.0|Content-Type:=20text/plain=3B=0D=0A =09charset=3D"us-ascii"|Content-Transfer-Encoding:=20quot ed-printable|Subject:=20RE:=20[MEXT]=20[mext]=20#11:=20De -registration=20when=20returning=20home=20[VijayDevarapal li=20]|Date:=20Thu,=2010=20Jul=202008 =2014:03:00=20-0700|Message-ID:=20|In-Reply-To: =20|X-MS-Has-Attach:=20|X-MS-TNEF-Correlator:=20 |Thread-Topic:=20[MEXT]=20[mext]=20#11:=20De-registration =20when=20returning=20home=20[VijayDevarapalli=20]|Thread-Index:=20Acjiv9qrVgXDMlwVT0KjHXeDWXH fzwAEDnzw|References:=20<010801c8e16b$5c2889d0$7471510a@p sl.local>=20=20 =20=20=20=20=20=20=20=20=20=20|From:=20"Giaretta,=20Ge rardo"=20|To:=20"Sri=20Gundavelli" =20,=0D=0A=20=20=20=20=20=20=20=20"Vi jay=20Devarapalli"=20|Cc:=20"Benjamin =20Lim"=20,=20,=0D=0A=20=20=20=20=20=20=20=20|X-OriginalArrivalTime:=2010=20Jul=202008=2021:03:00.09 36=20(UTC)=20FILETIME=3D[56522C80:01C8E2D0] |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5200,2160,5336"=3B=20 a=3D"4443653"; bh=1L7jyc9A70v9mEBQI8JwI1N1bfHyDn0ftZvQsd7GzyU=; b=H4LDc8GmNkyHbegoAjjSELADYS5OJIJ71fxldJHd0hJb26sJgL1yebaS 0oE28n1iZJzMkOaBAqv6rqKmmd5hg406rmK6SPXbmu7GZwon04TVQA8VQ OeBKtFfEnjLsT1zQNqvuYZ5HH0ynDdBV+GUlcI1n+BnVX70uSOgPQ34Vc M=; X-IronPort-AV: E=McAfee;i="5200,2160,5336"; a="4443653" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Jul 2008 14:03:01 -0700 Received: from msgtransport06.qualcomm.com (msgtransport06.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m6AL31FV020258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 10 Jul 2008 14:03:01 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by msgtransport06.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m6AL31t8012425; Thu, 10 Jul 2008 14:03:01 -0700 Received: from NAEX12.na.qualcomm.com ([129.46.51.247]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Jul 2008 14:03:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Jul 2008 14:03:00 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] Thread-Index: Acjiv9qrVgXDMlwVT0KjHXeDWXHfzwAEDnzw References: <010801c8e16b$5c2889d0$7471510a@psl.local> From: "Giaretta, Gerardo" To: "Sri Gundavelli" , "Vijay Devarapalli" X-OriginalArrivalTime: 10 Jul 2008 21:03:00.0936 (UTC) FILETIME=[56522C80:01C8E2D0] Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] 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 Sri, This MN would violate RFC3775. A dereg BU must be sent and a BA received before claiming the address. Therefore I am not sure we should document this in RFC3775bis Gerardo > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com] > Sent: Thursday, July 10, 2008 12:05 PM > To: Vijay Devarapalli > Cc: Giaretta, Gerardo; Benjamin Lim; charliep@computer.org; mext@ietf.org > Subject: RE: [MEXT] [mext] #11: De-registration when returning home > [VijayDevarapalli ] > > > > On Thu, 10 Jul 2008, Vijay Devarapalli wrote: > > >> But, nothing stops the mobile node from reclaiming that address and > >> start using it. HA cannot stop it. > > > > Sorry, do not mean to beat this thread to death ... > > So, who gets the packets, if HA does not stop proxying and MN > starts defending its address ? > > Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jul 10 15:07:44 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A31CE3A6AB5; Thu, 10 Jul 2008 15:07:44 -0700 (PDT) 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 93A813A6AB3 for ; Thu, 10 Jul 2008 15:07:43 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pq8YJkqa78ZV for ; Thu, 10 Jul 2008 15:07:42 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id E67303A6AAE for ; Thu, 10 Jul 2008 15:07:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,340,1212364800"; d="scan'208";a="64589262" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 10 Jul 2008 21:37:39 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6ALbda7022217; Thu, 10 Jul 2008 14:37:39 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m6ALbdW7003940; Thu, 10 Jul 2008 21:37:39 GMT Date: Thu, 10 Jul 2008 14:37:39 -0700 (PDT) From: Sri Gundavelli To: "Giaretta, Gerardo" In-Reply-To: Message-ID: References: <010801c8e16b$5c2889d0$7471510a@psl.local> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1570; t=1215725859; x=1216589859; 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]=20[mext]=20#11=3A=20De-registrat ion=20when=20returning=20home=0A=20[VijayDevarapalli=20] |Sender:=20; bh=azYr++LqXToHY2zYol9etFILlH5N9Low6IAI6yAnvmk=; b=WCrtBmM68eWHWQ4B/e/CFYTEPHhHG9N19odi0SsBud5t2v8u80Hc6J21H8 EEGNSqv5COKmKpyDsfZdSWTL5DvCTH6FVyLyYqjvA70vngmYJY9+kOe3Xzj5 lCkG51t7hI; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Gerardo, I agree its a violation of 3775. But, it is incorrect to state that the mobile node will not be able to reclaim the address without the consent from the home agent, when there is clearly no support from ND for controlling that aspect. Its my home home address and in the presence of SEND and in all other cases, I can assert ownership on that address and the link model will allow me to use that address. The requirement that HA should approve the MN to take over its address on the home link and if it does not recv a BA, it cannot reclaim the address is debatable. Sri On Thu, 10 Jul 2008, Giaretta, Gerardo wrote: > Sri, > > This MN would violate RFC3775. A dereg BU must be sent and a BA received > before claiming the address. Therefore I am not sure we should document > this in RFC3775bis > > Gerardo > >> -----Original Message----- >> From: Sri Gundavelli [mailto:sgundave@cisco.com] >> Sent: Thursday, July 10, 2008 12:05 PM >> To: Vijay Devarapalli >> Cc: Giaretta, Gerardo; Benjamin Lim; charliep@computer.org; > mext@ietf.org >> Subject: RE: [MEXT] [mext] #11: De-registration when returning home >> [VijayDevarapalli ] >> >> >> >> On Thu, 10 Jul 2008, Vijay Devarapalli wrote: >> >>>> But, nothing stops the mobile node from reclaiming that address and >>>> start using it. HA cannot stop it. >>> >> >> Sorry, do not mean to beat this thread to death ... >> >> So, who gets the packets, if HA does not stop proxying and MN >> starts defending its address ? >> >> Sri > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jul 10 15:09:41 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E6A63A6AB6; Thu, 10 Jul 2008 15:09:41 -0700 (PDT) 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 52B4A3A6AB6 for ; Thu, 10 Jul 2008 15:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 xDdSQlnuFkWU for ; Thu, 10 Jul 2008 15:09:39 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 809B03A6AB3 for ; Thu, 10 Jul 2008 15:09:39 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 2695E9000F for ; Thu, 10 Jul 2008 18:09:52 -0400 (EDT) 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 12497-08 for ; Thu, 10 Jul 2008 18:09:51 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Thu, 10 Jul 2008 18:09:51 -0400 (EDT) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jul 2008 18:09:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Jul 2008 18:04:52 -0400 Message-ID: <4D35478224365146822AE9E3AD4A2666031F6A7D@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] Thread-Index: AcjivsH2XJpivm/2RaeyYW76/y+NUgAGazRg From: "Koodli, Rajeev" To: , "Vijay Devarapalli" X-OriginalArrivalTime: 10 Jul 2008 22:09:42.0593 (UTC) FILETIME=[A77E9310:01C8E2D9] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Cc: mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] 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 Charlie, Vijay, The text is mostly fine with me. Please see below: > > A mobile node detects that it has returned to its home link through > > the movement detection algorithm in use (Section 11.5.1), when the > > mobile node detects that its home subnet prefix is again on-link. > > To be able to send and receive packets using its home address from > > the home link, the mobile node MUST send a Binding Update to its > > home agent to instruct its home agent to no longer intercept or > > tunnel packets for it. Until the mobile node sends a de-registration > > Binding Update, it will not be able to send and receive packets ^^^^^^^^^^^^^^^^^^^^ [RKo:>] I am not sure why the MN will not be able send packets until de-registration completes. If there is no reason, we should re-word it ".. will not be able to receive packets.." -Rajeev _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jul 10 15:45:44 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E62E928C12D; Thu, 10 Jul 2008 15:45:43 -0700 (PDT) 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 1D67628C12D for ; Thu, 10 Jul 2008 15:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yHdCMYqTQA9 for ; Thu, 10 Jul 2008 15:45:36 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id C41AF3A6AB0 for ; Thu, 10 Jul 2008 15:45:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1215729952; x=1247265952; h=x-mimeole:content-class:mime-version:content-type: content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator: thread-topic:thread-index:references:from:to:cc: x-originalarrivaltime:x-ironport-av; z=X-MimeOLE:=20Produced=20By=20Microsoft=20Exchange=20V6.5 |Content-class:=20urn:content-classes:message |MIME-Version:=201.0|Content-Type:=20text/plain=3B=0D=0A =09charset=3D"us-ascii"|Content-Transfer-Encoding:=20quot ed-printable|Subject:=20RE:=20[MEXT]=20[mext]=20#11:=20De -registration=20when=20returning=20home=20[VijayDevarapal li=20]|Date:=20Thu,=2010=20Jul=202008 =2015:45:45=20-0700|Message-ID:=20|In-Reply-To: =20|X-MS-Has-Attach:=20|X-MS-TNEF-Correlator:=20 |Thread-Topic:=20[MEXT]=20[mext]=20#11:=20De-registration =20when=20returning=20home=20[VijayDevarapalli=20]|Thread-Index:=20Acji2W7OsUNswIEBSgKqApcj/h/ crQABO2aw|References:=20<010801c8e16b$5c2889d0$7471510a@p sl.local>=20=20 =20=20=20=20=20=20=20=20=20=20=20=20|From:=20"G iaretta,=20Gerardo"=20|To:=20"Sri =20Gundavelli"=20|Cc:=20"Vijay=20Deva rapalli"=20,=0D=0A=20=20=20=20=20=20 =20=20"Benjamin=20Lim"=20,=0D=0A=20=20=20=20=20=20=20=20, =20|X-OriginalArrivalTime:=2010=20Jul=2020 08=2022:45:46.0367=20(UTC)=20FILETIME=3D[B13448F0:01C8E2D E]|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5200,2160,5336"=3B =20a=3D"4447044"; bh=DMz0L3YYQ/NyaQSE5fs8a47ryt06nsm3AWw+jSt9J40=; b=Ny/spO9u9BClHLHOm7P6hGAFsSff3RatYAQ93oxjv0uxGSj+bx5QEAnp itA636WtskRGWw0/plFz30mPicyre/2ZVHqO1hiZV00jmZx6RO6rAIU78 kjENrmJAKA1UDSnDWHoaGSS7ubajYSokk9KekZgSzYzEVSvT2W4ZN5BdC M=; X-IronPort-AV: E=McAfee;i="5200,2160,5336"; a="4447044" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Jul 2008 15:45:49 -0700 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m6AMjnph024347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 10 Jul 2008 15:45:49 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m6AMjmf7020312; Thu, 10 Jul 2008 15:45:48 -0700 Received: from NAEX12.na.qualcomm.com ([129.46.51.247]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Jul 2008 15:45:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Jul 2008 15:45:45 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] Thread-Index: Acji2W7OsUNswIEBSgKqApcj/h/crQABO2aw References: <010801c8e16b$5c2889d0$7471510a@psl.local> From: "Giaretta, Gerardo" To: "Sri Gundavelli" X-OriginalArrivalTime: 10 Jul 2008 22:45:46.0367 (UTC) FILETIME=[B13448F0:01C8E2DE] Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] 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, I'm trying to address the issue less philosophically :-) The MN will be a MIPv6 MN and knows that to claim the address it will need to send a deregistration BU and a NA instead of only sending a NA. This should be part of the MIPv6 stack in the MN. Does it make sense? Gerardo > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com] > Sent: Thursday, July 10, 2008 2:38 PM > To: Giaretta, Gerardo > Cc: Vijay Devarapalli; Benjamin Lim; charliep@computer.org; mext@ietf.org > Subject: RE: [MEXT] [mext] #11: De-registration when returning home > [VijayDevarapalli ] > > > Hi Gerardo, > > I agree its a violation of 3775. But, it is incorrect to state that > the mobile node will not be able to reclaim the address without the > consent from the home agent, when there is clearly no support from ND > for controlling that aspect. Its my home home address and in the > presence of SEND and in all other cases, I can assert ownership on > that address and the link model will allow me to use that address. The > requirement that HA should approve the MN to take over its address on > the home link and if it does not recv a BA, it cannot reclaim the > address is debatable. > > Sri > > > On Thu, 10 Jul 2008, Giaretta, Gerardo wrote: > > > Sri, > > > > This MN would violate RFC3775. A dereg BU must be sent and a BA received > > before claiming the address. Therefore I am not sure we should document > > this in RFC3775bis > > > > Gerardo > > > >> -----Original Message----- > >> From: Sri Gundavelli [mailto:sgundave@cisco.com] > >> Sent: Thursday, July 10, 2008 12:05 PM > >> To: Vijay Devarapalli > >> Cc: Giaretta, Gerardo; Benjamin Lim; charliep@computer.org; > > mext@ietf.org > >> Subject: RE: [MEXT] [mext] #11: De-registration when returning home > >> [VijayDevarapalli ] > >> > >> > >> > >> On Thu, 10 Jul 2008, Vijay Devarapalli wrote: > >> > >>>> But, nothing stops the mobile node from reclaiming that address and > >>>> start using it. HA cannot stop it. > >>> > >> > >> Sorry, do not mean to beat this thread to death ... > >> > >> So, who gets the packets, if HA does not stop proxying and MN > >> starts defending its address ? > >> > >> Sri > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jul 10 16:00:04 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E93883A68D7; Thu, 10 Jul 2008 16:00:03 -0700 (PDT) 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 939493A685E for ; Thu, 10 Jul 2008 16:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ig5GX1XAFval for ; Thu, 10 Jul 2008 16:00:02 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id CDA373A6781 for ; Thu, 10 Jul 2008 16:00:01 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Jul 2008 14:30:09 -0400 Message-ID: In-Reply-To: <877ibudywp.fsf@natisbad.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-00.txt Thread-Index: AcjiWA2HeVVR5EDGSGGrrQzHmtwizgAWld2w References: <20080706174502.6A6393A68F3@core3.amsl.com> <877ibudywp.fsf@natisbad.org> From: "Vijay Devarapalli" To: "Arnaud Ebalard" Cc: mext@ietf.org Subject: Re: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-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 > > That's because you need to setup IPsec SAs based on the > home address. > > The home address needs to be known before the IPsec SAs are > setup. Even > > the binding update cannot be sent if the required SA is not > in place. > > No relation with the thread: are you aware of any > implementation of that > mechanism? Open source or product implementations? The USAGI implementation might be supporting this. Check with them. The last time I worked on a MIPv6 implementation was back in 2005. There was no IKEv2 spec for MIPv6 back then. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jul 10 16:00:04 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C6803A69AF; Thu, 10 Jul 2008 16:00:04 -0700 (PDT) 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 1B3073A685E for ; Thu, 10 Jul 2008 16:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDcLxusOZisb for ; Thu, 10 Jul 2008 16:00:02 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 4F2603A6828 for ; Thu, 10 Jul 2008 16:00:02 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Jul 2008 14:41:37 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] Thread-Index: Acjh96r/rFIBubkDS0+S4gL1W6Yv2AAxHPwQ References: <010801c8e16b$5c2889d0$7471510a@psl.local> From: "Vijay Devarapalli" To: "Sri Gundavelli" Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] 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, > Below text seems ok to me, except the new concept of multiple > interface > MN in the context of 3775. I'd simply state, "if the MN wants to use > the HoA on the home link, it MUST send a dereg" ...., from the > MIP perspective we can require that. From HA perspective in > the context > of ND, what HA should do if the address is taken over, we need to > discuss further, as say above. Is this what you are looking for? A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.1), when the mobile node detects that its home subnet prefix is again on-link. To be able to send and receive packets using its home address from the home link, the mobile node MUST send a Binding Update to its home agent to instruct its home agent to no longer intercept or tunnel packets for it. I am fine with this as well, since it avoids talking about multiple interfaces. Gerardo? Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jul 10 16:00:05 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00E8E3A6A49; Thu, 10 Jul 2008 16:00:05 -0700 (PDT) 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 B53983A685E for ; Thu, 10 Jul 2008 16:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fARzC9YKXeGn for ; Thu, 10 Jul 2008 16:00:03 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id C5B0B3A6781 for ; Thu, 10 Jul 2008 16:00:02 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Jul 2008 14:53:28 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] Thread-Index: Acjh96r/rFIBubkDS0+S4gL1W6Yv2AAxHPwQAAAwv6AAAEgzQA== References: <010801c8e16b$5c2889d0$7471510a@psl.local> From: "Vijay Devarapalli" To: "Giaretta, Gerardo" , "Sri Gundavelli" Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] 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 Fine with me. So the new text is A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.1), when the mobile node detects that its home subnet prefix is again on-link. To be able to send and receive packets using its home address from the home link, the mobile node MUST send a Binding Update to its home agent to instruct its home agent to no longer intercept or tunnel packets for it. Until the mobile node sends a de-registration Binding Update, it will not be able to send and receive packets using its home address from the home link. The home agent will continue to intercept all packets sent to the mobile's home address and tunnel to the previously registered care-of address. Is everyone ok with this? Vijay > -----Original Message----- > From: Giaretta, Gerardo [mailto:gerardog@qualcomm.com] > Sent: Thursday, July 10, 2008 11:46 AM > To: Vijay Devarapalli; Sri Gundavelli > Cc: Benjamin Lim; charliep@computer.org; mext@ietf.org > Subject: RE: [MEXT] [mext] #11: De-registration when > returning home [VijayDevarapalli ] > > I would add the following sentence for the sake of clarity at > the end of > your text: > > Until the mobile node sends a de-registration Binding Update, > it will not be able to send and receive packets using its home > address from the home link. The home agent will continue to > intercept > all packets sent to the mobile's home address and tunnel to the > previously registered care-of address. > > Note that this text does not contain any normative text, just > clarifies > what happens. > > Gerardo > > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijay@wichorus.com] > > Sent: Thursday, July 10, 2008 11:42 AM > > To: Sri Gundavelli > > Cc: Giaretta, Gerardo; Benjamin Lim; charliep@computer.org; > mext@ietf.org > > Subject: RE: [MEXT] [mext] #11: De-registration when returning home > > [VijayDevarapalli ] > > > > Hi Sri, > > > > > Below text seems ok to me, except the new concept of multiple > > > interface > > > MN in the context of 3775. I'd simply state, "if the MN > wants to use > > > the HoA on the home link, it MUST send a dereg" ...., from the > > > MIP perspective we can require that. From HA perspective in > > > the context > > > of ND, what HA should do if the address is taken over, we need to > > > discuss further, as say above. > > > > Is this what you are looking for? > > > > A mobile node detects that it has returned to its home > link through > > the movement detection algorithm in use (Section > 11.5.1), when the > > mobile node detects that its home subnet prefix is again on-link. > > To be able to send and receive packets using its home > address from > > the home link, the mobile node MUST send a Binding Update to its > > home agent to instruct its home agent to no longer intercept or > > tunnel packets for it. > > > > I am fine with this as well, since it avoids talking about multiple > > interfaces. Gerardo? > > > > Vijay > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jul 10 16:00:05 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87FE328C0FF; Thu, 10 Jul 2008 16:00:05 -0700 (PDT) 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 51CB23A69AF for ; Thu, 10 Jul 2008 16:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wF+1mQu8KDJq for ; Thu, 10 Jul 2008 16:00:03 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 479BD3A6828 for ; Thu, 10 Jul 2008 16:00:03 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Jul 2008 14:58:33 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] Thread-Index: Acjivkwdbe//j0j3TqG5B5mjXkIKKAAAHAfA References: <010801c8e16b$5c2889d0$7471510a@psl.local> From: "Vijay Devarapalli" To: "Sri Gundavelli" , "Giaretta, Gerardo" Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] 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 would add the following sentence for the sake of clarity > at the end of > > your text: > > > > Until the mobile node sends a de-registration Binding Update, > > it will not be able to send and receive packets using its home > > address from the home link. The home agent will continue to > > intercept > > all packets sent to the mobile's home address and tunnel to the > > previously registered care-of address. > > > > Note that this text does not contain any normative text, > just clarifies > > what happens. > > > > But, nothing stops the mobile node from reclaiming that address and > start using it. HA cannot stop it. The HA does not stop proxying for the home address, until the de-registration happens. So according the current procedure in RFC3775, the mobile node MUST send a de-registration BU before it can start using the home address. > From MIP perspective, we can > madate the DeReg and if it does not do that, its a violation, but, we > cannot say MN wont be able to use that address without > sending a dereg, > that modifies 4861. > > Also, we need to discuss what the HA should do, if the mobile reclaims > its address, but does not send a dereg. This is not allowed today. Vijay > > Sri > > > > > > Gerardo > > > >> -----Original Message----- > >> From: Vijay Devarapalli [mailto:vijay@wichorus.com] > >> Sent: Thursday, July 10, 2008 11:42 AM > >> To: Sri Gundavelli > >> Cc: Giaretta, Gerardo; Benjamin Lim; charliep@computer.org; > > mext@ietf.org > >> Subject: RE: [MEXT] [mext] #11: De-registration when returning home > >> [VijayDevarapalli ] > >> > >> Hi Sri, > >> > >>> Below text seems ok to me, except the new concept of multiple > >>> interface > >>> MN in the context of 3775. I'd simply state, "if the MN > wants to use > >>> the HoA on the home link, it MUST send a dereg" ...., from the > >>> MIP perspective we can require that. From HA perspective in > >>> the context > >>> of ND, what HA should do if the address is taken over, we need to > >>> discuss further, as say above. > >> > >> Is this what you are looking for? > >> > >> A mobile node detects that it has returned to its home > link through > >> the movement detection algorithm in use (Section > 11.5.1), when the > >> mobile node detects that its home subnet prefix is > again on-link. > >> To be able to send and receive packets using its home > address from > >> the home link, the mobile node MUST send a Binding Update to its > >> home agent to instruct its home agent to no longer intercept or > >> tunnel packets for it. > >> > >> I am fine with this as well, since it avoids talking about multiple > >> interfaces. Gerardo? > >> > >> Vijay > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jul 10 16:00:06 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F22F28C130; Thu, 10 Jul 2008 16:00:06 -0700 (PDT) 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 8C2553A6A13 for ; Thu, 10 Jul 2008 16:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObI5F1oiaMIj for ; Thu, 10 Jul 2008 16:00:03 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id C19C33A6781 for ; Thu, 10 Jul 2008 16:00:03 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Jul 2008 15:07:53 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] Thread-Index: Acjiv9SiCKUjj56gSuW5LPMXMNnF+gAAD3NA References: <010801c8e16b$5c2889d0$7471510a@psl.local> From: "Vijay Devarapalli" To: "Sri Gundavelli" Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] 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 > Sorry, do not mean to beat this thread to death ... > > So, who gets the packets, if HA does not stop proxying and MN > starts defending its address ? This shouldn't happen. According to RFC 3775, a Mobile IPv6 mobile node should not claim the address (send a neighbor advertisement for it), until it gets a Binding Ack from the home agent in response to its de-registration Binding Update. This is clearly specified in RFC 3775. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jul 10 16:01:37 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE34628C14B; Thu, 10 Jul 2008 16:01:37 -0700 (PDT) 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 734193A6998 for ; Thu, 10 Jul 2008 16:01:36 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMIyiLVF2LbE for ; Thu, 10 Jul 2008 16:01:35 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 3BFE728C151 for ; Thu, 10 Jul 2008 16:01:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,341,1212364800"; d="scan'208";a="86506131" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 10 Jul 2008 23:01:24 +0000 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 m6AN1Nl5013771; Thu, 10 Jul 2008 16:01:23 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6AN1NKY009433; Thu, 10 Jul 2008 23:01:23 GMT Date: Thu, 10 Jul 2008 16:01:23 -0700 (PDT) From: Sri Gundavelli To: "Giaretta, Gerardo" In-Reply-To: Message-ID: References: <010801c8e16b$5c2889d0$7471510a@psl.local> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2728; t=1215730883; x=1216594883; 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]=20[mext]=20#11=3A=20De-registrat ion=20when=20returning=20home=0A=20[VijayDevarapalli=20] |Sender:=20; bh=YeD6wdwB7ZICdAI8daD5oQE5opaXiTmGv057N09vZuI=; b=mgIN1R7tSifbd8m/dOHBACzGxbVoWvauM1JNN9+SQrCiWkKCkizrNvwPVL eopo+zVvwrD7Mz6mwY0nscmrN0IBNmwTQWmqS7W+QPOJKDkpX7Fk3OYeiYce 1Kg8b9HwB/; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Gerardo, I'm ok with the text proposed by Vijay. We require the mobile to send a dereg message to the HA, if it intends to use its HoA on its home link, lets leave it there and not add that additional text related to the error case. Lets leave that additional text, as it is not correct. Sri On Thu, 10 Jul 2008, Giaretta, Gerardo wrote: > Hi Sri, > > I'm trying to address the issue less philosophically :-) > > The MN will be a MIPv6 MN and knows that to claim the address it will > need to send a deregistration BU and a NA instead of only sending a NA. > This should be part of the MIPv6 stack in the MN. > > Does it make sense? > > Gerardo > >> -----Original Message----- >> From: Sri Gundavelli [mailto:sgundave@cisco.com] >> Sent: Thursday, July 10, 2008 2:38 PM >> To: Giaretta, Gerardo >> Cc: Vijay Devarapalli; Benjamin Lim; charliep@computer.org; > mext@ietf.org >> Subject: RE: [MEXT] [mext] #11: De-registration when returning home >> [VijayDevarapalli ] >> >> >> Hi Gerardo, >> >> I agree its a violation of 3775. But, it is incorrect to state that >> the mobile node will not be able to reclaim the address without the >> consent from the home agent, when there is clearly no support from ND >> for controlling that aspect. Its my home home address and in the >> presence of SEND and in all other cases, I can assert ownership on >> that address and the link model will allow me to use that address. The >> requirement that HA should approve the MN to take over its address on >> the home link and if it does not recv a BA, it cannot reclaim the >> address is debatable. >> >> Sri >> >> >> On Thu, 10 Jul 2008, Giaretta, Gerardo wrote: >> >>> Sri, >>> >>> This MN would violate RFC3775. A dereg BU must be sent and a BA > received >>> before claiming the address. Therefore I am not sure we should > document >>> this in RFC3775bis >>> >>> Gerardo >>> >>>> -----Original Message----- >>>> From: Sri Gundavelli [mailto:sgundave@cisco.com] >>>> Sent: Thursday, July 10, 2008 12:05 PM >>>> To: Vijay Devarapalli >>>> Cc: Giaretta, Gerardo; Benjamin Lim; charliep@computer.org; >>> mext@ietf.org >>>> Subject: RE: [MEXT] [mext] #11: De-registration when returning home >>>> [VijayDevarapalli ] >>>> >>>> >>>> >>>> On Thu, 10 Jul 2008, Vijay Devarapalli wrote: >>>> >>>>>> But, nothing stops the mobile node from reclaiming that address > and >>>>>> start using it. HA cannot stop it. >>>>> >>>> >>>> Sorry, do not mean to beat this thread to death ... >>>> >>>> So, who gets the packets, if HA does not stop proxying and MN >>>> starts defending its address ? >>>> >>>> Sri >>> > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jul 10 16:24:41 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90FE73A6ABB; Thu, 10 Jul 2008 16:24:41 -0700 (PDT) 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 556513A6ABE for ; Thu, 10 Jul 2008 16:24:40 -0700 (PDT) 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 aZk219efF31g for ; Thu, 10 Jul 2008 16:24:39 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by core3.amsl.com (Postfix) with ESMTP id 3C5123A6ABB for ; Thu, 10 Jul 2008 16:24:39 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so1713302and.122 for ; Thu, 10 Jul 2008 16:24:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=1OqTcfgnEbFKdW6aOGmc3EN4g20BqtB//VeRn7KJ2vs=; b=t7KbVvUQ0XXaWRlKsAewdePe5iRIj6Ir9lpDllkNqvLox2K6z3bIxeaNqjznxXlkW4 HoWgTzw7rdBXtTinpwVn7aiLjRXyENt7DwqNkFiyR0YqOHHsYLC6RJA2KEgvP6sxBaLY VdkAzRhQLFTQfjZkdNwwm6fP3Su5esixkuxog= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=m2ExWy9MRDvoAF0pLuxb6xlITfxF5NMFKv/LwGRYp8xuU9bfzARxlZgyZfc4DcDTZa dv8MQ+CNEOXemSak2JgCaw4Mc1wzsYKb+M1pXb6iPDFNRmvVFdHL7pLgzB+VpiI5YPXo 8AoM7pKVm7OjC6d5wmxG5p2gEDVUYKzQX2pOY= Received: by 10.100.173.9 with SMTP id v9mr7727531ane.39.1215732292697; Thu, 10 Jul 2008 16:24:52 -0700 (PDT) Received: by 10.100.57.5 with HTTP; Thu, 10 Jul 2008 16:24:52 -0700 (PDT) Message-ID: Date: Thu, 10 Jul 2008 16:24:52 -0700 From: "fan zhao" To: "Vijay Devarapalli" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <20080706174502.6A6393A68F3@core3.amsl.com> Cc: mext@ietf.org Subject: Re: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-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 Vijay, Sorry for my late reply. Please see below. On Wed, Jul 9, 2008 at 6:57 PM, Vijay Devarapalli wrote: >> The MNP is required for the MR to operate, in addtion >> to the HoA/HNP. It is the most efficient way for the MR >> to be configured via the IKEv2. > > Don't agree on the efficiency part. The mobile router does not advertise > the mobile network prefixes in its mobile network until the BU/BAck > exchange complete. You may be right, though it seems you are introducing this arbitrary assumption. Can you please help us understand where it is stated in RFC 3963 that the mobile router does not advertise the prefix before the BU/BAck exchange is completed? To my best knowledge, advertising a prefix is for IP configuration and local network access, while completing the BU/BA exchange is for establishing a bi-directional tunnel and obtaining access to the Internet. Without such assumption, even if the efficiency may be minimal, there would still be efficiency in allowing the MNNs to configure addresses as soon as the MR has the prefix available. > >> I am curious how the BU/BA based PD works on the home link? > > It doesn't. This is one of the reasons I wrote > draft-devarapalli-mext-mipv6-home-link-01.txt, which allows the mobile > router to send a binding update from the home link. IMO, to use the BU/Back for MNP assignment, you must modify Mobile IP to ensure the mobile router exchanges BU/Back also on the home link. This seems an artificial and unnecessary complication, since the mobile router anyway would perform IKEv2 even on the home link, e.g. for home link detection. And therefore, with a minor enhancement it would be possible to deliver the delegated prefix to the mobile router. Instead, with your proposal, the mobile router needs to perform additional steps currently not performed by a Mobile IP mobile node. Therefore, we argue that using IKEv2 has much less impact and does not require modifications to the Mobile IP behavior. Sincerely, fan > > Vijay > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jul 10 18:47:51 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A34ED3A6A6A; Thu, 10 Jul 2008 18:47:51 -0700 (PDT) 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 199F83A690C for ; Thu, 10 Jul 2008 18:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQcI5jrrGBnn for ; Thu, 10 Jul 2008 18:47:49 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id BF2AD3A6A6A for ; Thu, 10 Jul 2008 18:47:48 -0700 (PDT) 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 m6B1l66x029775; Fri, 11 Jul 2008 10:47:06 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb2) with ESMTP id m6B1l6j08017; Fri, 11 Jul 2008 10:47:06 +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 m6B1l5R17781; Fri, 11 Jul 2008 10:47:05 +0900 (JST) Received: from NW-Sephiroth ([10.81.113.116]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Jul 2008 09:45:35 +0800 Received: from NWSephiroth by NW-Sephiroth (PGP Universal service); Fri, 11 Jul 2008 09:45:32 +0800 X-PGP-Universal: processed; by NW-Sephiroth on Fri, 11 Jul 2008 09:45:32 +0800 From: "Benjamin Lim" To: "'Vijay Devarapalli'" , "'Giaretta, Gerardo'" , "'Sri Gundavelli'" References: <010801c8e16b$5c2889d0$7471510a@psl.local> Date: Fri, 11 Jul 2008 09:45:32 +0800 Message-ID: <012001c8e2f7$ce45a790$7471510a@psl.local> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: Acjh96r/rFIBubkDS0+S4gL1W6Yv2AAxHPwQAAAwv6AAAEgzQAAOZ+zw In-Reply-To: X-OriginalArrivalTime: 11 Jul 2008 01:45:35.0155 (UTC) FILETIME=[CFD2B030:01C8E2F7] Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] 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, No objection from me on the below text. Regards, Benjamin Lim > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay@wichorus.com] > Sent: Friday, July 11, 2008 2:53 AM > To: Giaretta, Gerardo; Sri Gundavelli > Cc: Benjamin Lim; charliep@computer.org; mext@ietf.org > Subject: RE: [MEXT] [mext] #11: De-registration when > returning home [VijayDevarapalli ] > > Fine with me. So the new text is > > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > To be able to send and receive packets using its home address from > the home link, the mobile node MUST send a Binding Update to its > home agent to instruct its home agent to no longer intercept or > tunnel packets for it. Until the mobile node sends a > de-registration > Binding Update, it will not be able to send and receive packets > using its home address from the home link. The home agent will > continue to intercept all packets sent to the mobile's > home address > and tunnel to the previously registered care-of address. > > Is everyone ok with this? > > Vijay > > > > -----Original Message----- > > From: Giaretta, Gerardo [mailto:gerardog@qualcomm.com] > > Sent: Thursday, July 10, 2008 11:46 AM > > To: Vijay Devarapalli; Sri Gundavelli > > Cc: Benjamin Lim; charliep@computer.org; mext@ietf.org > > Subject: RE: [MEXT] [mext] #11: De-registration when returning home > > [VijayDevarapalli ] > > > > I would add the following sentence for the sake of clarity > at the end > > of your text: > > > > Until the mobile node sends a de-registration Binding Update, > > it will not be able to send and receive packets using its home > > address from the home link. The home agent will continue to > > intercept > > all packets sent to the mobile's home address and tunnel to the > > previously registered care-of address. > > > > Note that this text does not contain any normative text, just > > clarifies what happens. > > > > Gerardo > > > > > -----Original Message----- > > > From: Vijay Devarapalli [mailto:vijay@wichorus.com] > > > Sent: Thursday, July 10, 2008 11:42 AM > > > To: Sri Gundavelli > > > Cc: Giaretta, Gerardo; Benjamin Lim; charliep@computer.org; > > mext@ietf.org > > > Subject: RE: [MEXT] [mext] #11: De-registration when > returning home > > > [VijayDevarapalli ] > > > > > > Hi Sri, > > > > > > > Below text seems ok to me, except the new concept of multiple > > > > interface MN in the context of 3775. I'd simply state, > "if the MN > > wants to use > > > > the HoA on the home link, it MUST send a dereg" ...., > from the MIP > > > > perspective we can require that. From HA perspective in the > > > > context of ND, what HA should do if the address is > taken over, we > > > > need to discuss further, as say above. > > > > > > Is this what you are looking for? > > > > > > A mobile node detects that it has returned to its home > > link through > > > the movement detection algorithm in use (Section > > 11.5.1), when the > > > mobile node detects that its home subnet prefix is > again on-link. > > > To be able to send and receive packets using its home > > address from > > > the home link, the mobile node MUST send a Binding > Update to its > > > home agent to instruct its home agent to no longer intercept or > > > tunnel packets for it. > > > > > > I am fine with this as well, since it avoids talking > about multiple > > > interfaces. Gerardo? > > > > > > Vijay > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jul 10 18:53:35 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 415CF3A69BF; Thu, 10 Jul 2008 18:53:35 -0700 (PDT) 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 657DD3A690C for ; Thu, 10 Jul 2008 18:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gh-5qKmUcXIG for ; Thu, 10 Jul 2008 18:53:32 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 4909F3A67CC for ; Thu, 10 Jul 2008 18:53:32 -0700 (PDT) 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 m6B1rScG025080; Fri, 11 Jul 2008 10:53:28 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb1) with ESMTP id m6B1rSU14909; Fri, 11 Jul 2008 10:53:28 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili02) with ESMTP id m6B1rRs11742; Fri, 11 Jul 2008 10:53:27 +0900 (JST) Received: from NW-Sephiroth ([10.81.113.116]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Jul 2008 09:51:57 +0800 Received: from NWSephiroth by NW-Sephiroth (PGP Universal service); Fri, 11 Jul 2008 09:51:54 +0800 X-PGP-Universal: processed; by NW-Sephiroth on Fri, 11 Jul 2008 09:51:54 +0800 From: "Benjamin Lim" To: "'Koodli, Rajeev'" References: <4D35478224365146822AE9E3AD4A2666031F6A7D@exchtewks3.starentnetworks.com> Date: Fri, 11 Jul 2008 09:51:54 +0800 Message-ID: <012101c8e2f8$b1faa760$7471510a@psl.local> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AcjivsH2XJpivm/2RaeyYW76/y+NUgAGazRgAAfZcfA= In-Reply-To: <4D35478224365146822AE9E3AD4A2666031F6A7D@exchtewks3.starentnetworks.com> X-OriginalArrivalTime: 11 Jul 2008 01:51:57.0202 (UTC) FILETIME=[B38A6F20:01C8E2F8] Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home[VijayDevarapalli ] 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 Rajeev, I not so sure about MN sending packet before de-reg completes. I understand MN should be able to forward the packet out via HA to its destination (assuming HA is the deafut gateway), but I am unlcear on how the HA would handle this packet. I.e Soruce address of the packet would be HoA. So HA recevies this packet, checks ingress filtering (assuming) and pass it. Now this is the part it gets fuzzy. In the BCE, HA would have an entry for HoA. This lets HA know to defend HoA. Yet, HA see a packet coming from home link with source address as HoA. Since HA did not send such a packet and HA should only be the one defending this address (other than MN), I am not sure if this would confuse the hell out of HA. What would HA do with this packet? Forward? Drop? Regards, Benjamin Lim > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Koodli, Rajeev > Sent: Friday, July 11, 2008 6:05 AM > To: charliep@computer.org; Vijay Devarapalli > Cc: mext@ietf.org > Subject: Re: [MEXT] [mext] #11: De-registration when > returning home[VijayDevarapalli ] > > > Hi Charlie, Vijay, > > The text is mostly fine with me. Please see below: > > > > > A mobile node detects that it has returned to its home link > through > > > the movement detection algorithm in use (Section 11.5.1), when > the > > > mobile node detects that its home subnet prefix is > again on-link. > > > To be able to send and receive packets using its home address > from > > > the home link, the mobile node MUST send a Binding > Update to its > > > home agent to instruct its home agent to no longer intercept or > > > tunnel packets for it. Until the mobile node sends a > de-registration > > > Binding Update, it will not be able to send and receive packets > ^^^^^^^^^^^^^^^^^^^^ > > [RKo:>] I am not sure why the MN will not be able send > packets until de-registration completes. If there is no > reason, we should re-word it ".. will not be able to receive > packets.." > > -Rajeev > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://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 Jul 10 21:09:44 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56B323A6A9F; Thu, 10 Jul 2008 21:09:44 -0700 (PDT) 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 BEDE53A693C for ; Thu, 10 Jul 2008 21:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 lPXrzyK-V9WM for ; Thu, 10 Jul 2008 21:09:43 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id C83883A69D9 for ; Thu, 10 Jul 2008 21:09:42 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 0C494C801E for ; Fri, 11 Jul 2008 00:09:56 -0400 (EDT) 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 19607-18 for ; Fri, 11 Jul 2008 00:09:53 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Fri, 11 Jul 2008 00:09:53 -0400 (EDT) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jul 2008 00:09:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 11 Jul 2008 00:04:02 -0400 Message-ID: <4D35478224365146822AE9E3AD4A2666031F6B27@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [mext] #11: De-registration when returning home[VijayDevarapalli ] Thread-Index: AcjivsH2XJpivm/2RaeyYW76/y+NUgAGazRgAAfZcfAABJh5UA== From: "Koodli, Rajeev" To: "Benjamin Lim" X-OriginalArrivalTime: 11 Jul 2008 04:09:41.0982 (UTC) FILETIME=[F1BBC7E0:01C8E30B] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home[VijayDevarapalli ] 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 Benjamin, > > Now this is the part it gets fuzzy. In the BCE, HA would have an entry > for > HoA. This lets HA know to defend HoA. Yet, HA see a packet coming from > home link with source address as HoA. Since HA did not send such a packet > and HA should only be the one defending this address (other than MN), I am > not sure if this would confuse the hell out of HA. What would HA do with > this packet? Forward? Drop? > [RKo:>] It should be similar to what the HA would do once it would remove the outer tunnel header had the packet arrived from a visited network. That is, forward the packet to the CN. -Rajeev > Regards, > Benjamin Lim > > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > Behalf Of Koodli, Rajeev > > Sent: Friday, July 11, 2008 6:05 AM > > To: charliep@computer.org; Vijay Devarapalli > > Cc: mext@ietf.org > > Subject: Re: [MEXT] [mext] #11: De-registration when > > returning home[VijayDevarapalli ] > > > > > > Hi Charlie, Vijay, > > > > The text is mostly fine with me. Please see below: > > > > > > > > A mobile node detects that it has returned to its home link > > through > > > > the movement detection algorithm in use (Section 11.5.1), when > > the > > > > mobile node detects that its home subnet prefix is > > again on-link. > > > > To be able to send and receive packets using its home address > > from > > > > the home link, the mobile node MUST send a Binding > > Update to its > > > > home agent to instruct its home agent to no longer intercept or > > > > tunnel packets for it. Until the mobile node sends a > > de-registration > > > > Binding Update, it will not be able to send and receive packets > > ^^^^^^^^^^^^^^^^^^^^ > > > > [RKo:>] I am not sure why the MN will not be able send > > packets until de-registration completes. If there is no > > reason, we should re-word it ".. will not be able to receive > > packets.." > > > > -Rajeev > > > > > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://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 Jul 10 22:33:38 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72D2C28C0F4; Thu, 10 Jul 2008 22:33:38 -0700 (PDT) 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 06CAF3A695E for ; Thu, 10 Jul 2008 22:33:37 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: couldn't parse head; error near:; [InternetShortcut]; URL=ftp://ftp.ietf.org/internet-drafts/draft-lim-mext-multiple-coa-verify-02.txt X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yj4SN9M0Q0Mt for ; Thu, 10 Jul 2008 22:33:36 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id EE8FC3A6405 for ; Thu, 10 Jul 2008 22:33:35 -0700 (PDT) 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 m6B5Xq7m023548 for ; Fri, 11 Jul 2008 14:33:52 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb1) with ESMTP id m6B5XpU18233 for ; Fri, 11 Jul 2008 14:33:51 +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 m6B5Xpx26292 for ; Fri, 11 Jul 2008 14:33:51 +0900 (JST) Received: from NW-Sephiroth ([10.81.113.116]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Jul 2008 13:32:19 +0800 Received: from NWSephiroth by NW-Sephiroth (PGP Universal service); Fri, 11 Jul 2008 13:32:04 +0800 X-PGP-Universal: processed; by NW-Sephiroth on Fri, 11 Jul 2008 13:32:04 +0800 From: "Benjamin Lim" To: Date: Fri, 11 Jul 2008 13:32:04 +0800 Message-ID: <013301c8e317$73d4fbb0$7471510a@psl.local> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0134_01C8E35A.81F83BB0" X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AcjjFPd4hbfugiJAS8GQjRNlmzSUDAAANZHA X-OriginalArrivalTime: 11 Jul 2008 05:32:19.0732 (UTC) FILETIME=[7CC86540:01C8E317] Subject: [MEXT] FW: I-D Action:draft-lim-mext-multiple-coa-verify-02.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_0134_01C8E35A.81F83BB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi all, We have submitted the revise version for this ID that analyzes solutions to the fake CoA binding threat described in the MCoA ID & the residual threats ID. The bulk of the revision is in the solution analysis section where we highlight the pros and cons for each solution approach. Also, recommendations are given to try and optimize each solution approach to reduce their cons. Comments are welcomed and appreciated. 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, July 11, 2008 1:15 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-lim-mext-multiple-coa-verify-02.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-02.txt Pages : 21 Date : 2008-07-10 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 few possible verification mechanisms 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-02.tx t Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_0134_01C8E35A.81F83BB0 Content-Type: Message/External-body; name="draft-lim-mext-multiple-coa-verify-02.URL" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-lim-mext-multiple-coa-verify-02.URL" [InternetShortcut] URL=ftp://ftp.ietf.org/internet-drafts/draft-lim-mext-multiple-coa-verify-02.txt ------=_NextPart_000_0134_01C8E35A.81F83BB0 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 ------=_NextPart_000_0134_01C8E35A.81F83BB0-- From mext-bounces@ietf.org Thu Jul 10 23:16:14 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C64753A69E2; Thu, 10 Jul 2008 23:16:14 -0700 (PDT) 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 95D033A69D4 for ; Thu, 10 Jul 2008 23:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 owwBhe0ZxL3i for ; Thu, 10 Jul 2008 23:16:11 -0700 (PDT) Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id B29273A69DD for ; Thu, 10 Jul 2008 23:16:11 -0700 (PDT) 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 1KHBvZ-0000vv-Oe; Fri, 11 Jul 2008 08:16:21 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: "Vijay Devarapalli" References: <20080706174502.6A6393A68F3@core3.amsl.com> <877ibudywp.fsf@natisbad.org> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:080711:vijay@wichorus.com::MF8ROqc6FYBlxuVU:00000000000000000000000000000000000000000001/V1 X-Hashcash: 1:20:080711:mext@ietf.org::eUwMAPDUWdgtyiot:00007kxV X-Hashcash: 1:20:080711:fanzhao828@gmail.com::ZgmqM1jp5QubtaSf:000000000000000000000000000000000000000009p+O Date: Fri, 11 Jul 2008 08:15:37 +0200 Message-ID: <87bq157xpy.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-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="===============1276229837==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1276229837== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Transfer-Encoding: quoted-printable Hi Vijay, "Vijay Devarapalli" writes: >> No relation with the thread: are you aware of any implementation of >> that mechanism?=20 > > Open source or product implementations?=20 both (but I think I already known the status for open source implementations). One small note: i was asking about Home Address assignment as described in 5026. > The USAGI implementation might be supporting this. Check with them. I know the status of USAGI implementation: it does support (with patches) setup of IPsec SA with IKE based on the Home Address, as expected by MIPv6 main reference documents. =2D UMIP w/ patches (maintained) =2D racoon w/patches (maintained) =2D racoon2 w/ patches (not maintained) For 5026, none of previous elements supports it. > The last time I worked on a MIPv6 implementation was back in > 2005. There was no IKEv2 spec for MIPv6 back then.=20 ack. Thanks for your reply, a+ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIdvqYAlWVfAR6UCYRAg9GAJ9oWY2KnaoYyfEjYaGqFkxAkMwXYACeLY7q I33NuxrQmd8Ci8/zGaioMyo= =H4rr -----END PGP SIGNATURE----- --=-=-=-- --===============1276229837== 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 --===============1276229837==-- From mext-bounces@ietf.org Fri Jul 11 06:53:31 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 285423A6953; Fri, 11 Jul 2008 06:53:31 -0700 (PDT) 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 389133A6845 for ; Fri, 11 Jul 2008 06:53:30 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDJs7b9W64Av for ; Fri, 11 Jul 2008 06:53:29 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 23E193A6953 for ; Fri, 11 Jul 2008 06:53:28 -0700 (PDT) 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 m6BDrhl03130; Fri, 11 Jul 2008 13:53:43 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C8E35D.80803820" Date: Fri, 11 Jul 2008 08:53:28 -0500 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-muhanna-mext-binding-revocation-02.txt Thread-Index: AcjjXPe1Yo0l7EuJQ/O/kNawGkRHOQAAAOxQ From: "Ahmad Muhanna" To: Subject: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-02.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_001_01C8E35D.80803820 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Hello Folks, We updated the Binding Revocation draft according to the mext wg ml consensus by using the Mobile IPv6 Generic Signaling Message (MGSM) framework. Since the MGSM draft is still being revised, we referenced the MGSM draft in all related sections of the Binding Revocation draft. We probably will be able to optimize the draft a little more in order to eliminate any duplication in some sections as soon as the new MGSM draft revision becomes available. The only other change introduced in this revision is that we referenced the DSMIP6 draft and made it optional for the HA to include the IPv4 home address in the BRI. With the aggressive schedule and 3GPP dependency on this draft, we appreciate your review, comment, and feedback. Thanks in advance! Regards, Ahmad -----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, July 11, 2008 8:45 AM To: i-d-announce@ietf.org Subject: I-D Action:draft-muhanna-mext-binding-revocation-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Binding Revocation for IPv6 Mobility Author(s) : A. Muhanna, et al. Filename : draft-muhanna-mext-binding-revocation-02.txt Pages : 32 Date : 2008-07-11 This document defines the revocation semantics for terminating a mobile node's mobility session and associated resources. These semantics are generic enough and can be used by mobility entities in the case of Client Mobile IPv6 and its extensions. This mechanism allows the mobility entity which initiates the revocation procedure to request its corresponding one to terminate either one, multiple or all specified binding cache entries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding-revocatio n-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C8E35D.80803820 Content-Type: application/octet-stream; name="draft-muhanna-mext-binding-revocation-02.URL" Content-Transfer-Encoding: base64 Content-Description: draft-muhanna-mext-binding-revocation-02.URL Content-Disposition: attachment; filename="draft-muhanna-mext-binding-revocation-02.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1tdWhhbm5hLW1leHQtYmluZGluZy1yZXZvY2F0aW9uLTAyLnR4dA0K ------_=_NextPart_001_01C8E35D.80803820 Content-Type: text/plain; name="ATT6527486.txt" Content-Transfer-Encoding: base64 Content-Description: ATT6527486.txt Content-Disposition: attachment; filename="ATT6527486.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K ------_=_NextPart_001_01C8E35D.80803820 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 ------_=_NextPart_001_01C8E35D.80803820-- From mext-bounces@ietf.org Fri Jul 11 07:23:05 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67CB93A6B35; Fri, 11 Jul 2008 07:23:05 -0700 (PDT) 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 1B5163A6B42 for ; Fri, 11 Jul 2008 07:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.546 X-Spam-Level: X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJ68wz7jj7Ze for ; Fri, 11 Jul 2008 07:23:03 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 3453E3A6B35 for ; Fri, 11 Jul 2008 07:23:03 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K3U00IQ0IMVF1@usaga04-in.huawei.com> for mext@ietf.org; Fri, 11 Jul 2008 09:23:20 -0500 (CDT) Received: from X24512z ([10.124.12.92]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K3U00BGWIMU0N@usaga04-in.huawei.com> for mext@ietf.org; Fri, 11 Jul 2008 09:23:19 -0500 (CDT) Date: Fri, 11 Jul 2008 09:23:16 -0500 From: Frank Xia To: Ahmad Muhanna , mext@ietf.org Message-id: <00be01c8e361$a995d180$5c0c7c0a@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: Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-02.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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ahmad IMHO, this document can't be directly used by WiMAX and 3GPP2 in which IPsec SA is not mandatory. 3GPP2/WiMAX adopted RFC4285, and corresponding documents, such as Diameter, RADIUS, now are explicitely supporting RFC4285. We discussed before. BR Frank ----- Original Message ----- From: "Ahmad Muhanna" To: Sent: Friday, July 11, 2008 8:53 AM Subject: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-02.txt Hello Folks, We updated the Binding Revocation draft according to the mext wg ml consensus by using the Mobile IPv6 Generic Signaling Message (MGSM) framework. Since the MGSM draft is still being revised, we referenced the MGSM draft in all related sections of the Binding Revocation draft. We probably will be able to optimize the draft a little more in order to eliminate any duplication in some sections as soon as the new MGSM draft revision becomes available. The only other change introduced in this revision is that we referenced the DSMIP6 draft and made it optional for the HA to include the IPv4 home address in the BRI. With the aggressive schedule and 3GPP dependency on this draft, we appreciate your review, comment, and feedback. Thanks in advance! Regards, Ahmad -----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, July 11, 2008 8:45 AM To: i-d-announce@ietf.org Subject: I-D Action:draft-muhanna-mext-binding-revocation-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Binding Revocation for IPv6 Mobility Author(s) : A. Muhanna, et al. Filename : draft-muhanna-mext-binding-revocation-02.txt Pages : 32 Date : 2008-07-11 This document defines the revocation semantics for terminating a mobile node's mobility session and associated resources. These semantics are generic enough and can be used by mobility entities in the case of Client Mobile IPv6 and its extensions. This mechanism allows the mobility entity which initiates the revocation procedure to request its corresponding one to terminate either one, multiple or all specified binding cache entries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding-revocatio n-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------------------------------------------------------------------------- > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 08:12:31 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF9E028C191; Fri, 11 Jul 2008 08:12:31 -0700 (PDT) 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 130F228C191 for ; Fri, 11 Jul 2008 08:12:31 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1T05NFrptqk for ; Fri, 11 Jul 2008 08:12:30 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id BCAAD28C18D for ; Fri, 11 Jul 2008 08:12:29 -0700 (PDT) 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 m6BFCil19092; Fri, 11 Jul 2008 15:12:44 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 11 Jul 2008 10:12:32 -0500 Message-ID: In-Reply-To: <00be01c8e361$a995d180$5c0c7c0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-02.txt Thread-Index: AcjjYbJvo73pYnhBTqaXrlWO85wf8QABjbtA References: <00be01c8e361$a995d180$5c0c7c0a@china.huawei.com> From: "Ahmad Muhanna" To: "Frank Xia" , Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-02.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 Frank, I do not think there is a conflict here. In the case of WiMAX and 3GPP2, I assume that there will be no IPsec SA between the HA and the MN, for example. Therefore, there will be no SPD to worry about. Although the BRI/BRA uses the MGSM which has a MH type that support IPsec (if IPsec is used), but that is not applicable to the case you mentioned then there is no problem. Does that make sense? Regards, Ahmad > -----Original Message----- > From: Frank Xia [mailto:xiayangsong@huawei.com] > Sent: Friday, July 11, 2008 9:23 AM > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > Subject: Re: [MEXT] FW: I-D > Action:draft-muhanna-mext-binding-revocation-02.txt > > Hi Ahmad > > IMHO, this document can't be directly used by WiMAX and 3GPP2 > in which IPsec SA is not mandatory. > > 3GPP2/WiMAX adopted RFC4285, and corresponding documents, > such as Diameter, RADIUS, now are explicitely supporting RFC4285. > > We discussed before. > > BR > Frank > > > ----- Original Message ----- > From: "Ahmad Muhanna" > To: > Sent: Friday, July 11, 2008 8:53 AM > Subject: [MEXT] FW: I-D > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > Hello Folks, > > We updated the Binding Revocation draft according to the mext wg ml > consensus by using the Mobile IPv6 Generic Signaling Message (MGSM) > framework. Since the MGSM draft is still being revised, we referenced > the MGSM draft in all related sections of the Binding > Revocation draft. > We probably will be able to optimize the draft a little more > in order to > eliminate any duplication in some sections as soon as the new > MGSM draft > revision becomes available. > > The only other change introduced in this revision is that we > referenced > the DSMIP6 draft and made it optional for the HA to include the IPv4 > home address in the BRI. > > With the aggressive schedule and 3GPP dependency on this draft, we > appreciate your review, comment, and feedback. > > Thanks in advance! > > Regards, > Ahmad > > -----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, July 11, 2008 8:45 AM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-muhanna-mext-binding-revocation-02.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Binding Revocation for IPv6 Mobility > Author(s) : A. Muhanna, et al. > Filename : draft-muhanna-mext-binding-revocation-02.txt > Pages : 32 > Date : 2008-07-11 > > This document defines the revocation semantics for > terminating a mobile > node's mobility session and associated resources. These semantics are > generic enough and can be used by mobility entities in the case of > Client Mobile IPv6 and its extensions. This mechanism allows the > mobility entity which initiates the revocation procedure to > request its > corresponding one to terminate either one, multiple or all specified > binding cache entries. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding -revocatio > n-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > -------------------------------------------------------------- > ------------------ > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 08:17:53 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41F0D3A68F5; Fri, 11 Jul 2008 08:17:53 -0700 (PDT) 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 BA2683A6876 for ; Fri, 11 Jul 2008 08:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.072 X-Spam-Level: X-Spam-Status: No, score=-2.072 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phxOSG744ynH for ; Fri, 11 Jul 2008 08:17:51 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id C30683A67E3 for ; Fri, 11 Jul 2008 08:17:51 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K3U00I1UL69F1@usaga04-in.huawei.com> for mext@ietf.org; Fri, 11 Jul 2008 10:18:09 -0500 (CDT) Received: from X24512z ([10.124.12.92]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K3U007ZLL67S1@usaga04-in.huawei.com> for mext@ietf.org; Fri, 11 Jul 2008 10:18:09 -0500 (CDT) Date: Fri, 11 Jul 2008 10:18:07 -0500 From: Frank Xia To: Ahmad Muhanna , mext@ietf.org Message-id: <000601c8e369$530b9b80$5c0c7c0a@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: <00be01c8e361$a995d180$5c0c7c0a@china.huawei.com> Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-02.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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ahmad How to secure the signaling between HA and MN if there is no IPsec? BR Frank ----- Original Message ----- From: "Ahmad Muhanna" To: "Frank Xia" ; Sent: Friday, July 11, 2008 10:12 AM Subject: RE: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-02.txt Hi Frank, I do not think there is a conflict here. In the case of WiMAX and 3GPP2, I assume that there will be no IPsec SA between the HA and the MN, for example. Therefore, there will be no SPD to worry about. Although the BRI/BRA uses the MGSM which has a MH type that support IPsec (if IPsec is used), but that is not applicable to the case you mentioned then there is no problem. Does that make sense? Regards, Ahmad > -----Original Message----- > From: Frank Xia [mailto:xiayangsong@huawei.com] > Sent: Friday, July 11, 2008 9:23 AM > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > Subject: Re: [MEXT] FW: I-D > Action:draft-muhanna-mext-binding-revocation-02.txt > > Hi Ahmad > > IMHO, this document can't be directly used by WiMAX and 3GPP2 > in which IPsec SA is not mandatory. > > 3GPP2/WiMAX adopted RFC4285, and corresponding documents, > such as Diameter, RADIUS, now are explicitely supporting RFC4285. > > We discussed before. > > BR > Frank > > > ----- Original Message ----- > From: "Ahmad Muhanna" > To: > Sent: Friday, July 11, 2008 8:53 AM > Subject: [MEXT] FW: I-D > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > Hello Folks, > > We updated the Binding Revocation draft according to the mext wg ml > consensus by using the Mobile IPv6 Generic Signaling Message (MGSM) > framework. Since the MGSM draft is still being revised, we referenced > the MGSM draft in all related sections of the Binding > Revocation draft. > We probably will be able to optimize the draft a little more > in order to > eliminate any duplication in some sections as soon as the new > MGSM draft > revision becomes available. > > The only other change introduced in this revision is that we > referenced > the DSMIP6 draft and made it optional for the HA to include the IPv4 > home address in the BRI. > > With the aggressive schedule and 3GPP dependency on this draft, we > appreciate your review, comment, and feedback. > > Thanks in advance! > > Regards, > Ahmad > > -----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, July 11, 2008 8:45 AM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-muhanna-mext-binding-revocation-02.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Binding Revocation for IPv6 Mobility > Author(s) : A. Muhanna, et al. > Filename : draft-muhanna-mext-binding-revocation-02.txt > Pages : 32 > Date : 2008-07-11 > > This document defines the revocation semantics for > terminating a mobile > node's mobility session and associated resources. These semantics are > generic enough and can be used by mobility entities in the case of > Client Mobile IPv6 and its extensions. This mechanism allows the > mobility entity which initiates the revocation procedure to > request its > corresponding one to terminate either one, multiple or all specified > binding cache entries. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding -revocatio > n-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > -------------------------------------------------------------- > ------------------ > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 08:20:42 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 487DB28C1CF; Fri, 11 Jul 2008 08:20:42 -0700 (PDT) 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 DAECA28C1CF for ; Fri, 11 Jul 2008 08:20:40 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-cFXoTRsGFb for ; Fri, 11 Jul 2008 08:20:39 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 9EBE528C1BC for ; Fri, 11 Jul 2008 08:20:39 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6BFKsF02869; Fri, 11 Jul 2008 15:20:54 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 11 Jul 2008 10:20:52 -0500 Message-ID: In-Reply-To: <000601c8e369$530b9b80$5c0c7c0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-02.txt Thread-Index: AcjjaVjN7zFPeikMSjmo53HwbKaCuAAAAVZQ References: <00be01c8e361$a995d180$5c0c7c0a@china.huawei.com> <000601c8e369$530b9b80$5c0c7c0a@china.huawei.com> From: "Ahmad Muhanna" To: "Frank Xia" , Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-02.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 Frank, I guess you need to answer that question. Right? I assume that what you mentioned about 3GPP2 and WiMAX is accurate. i.e., "by WiMAX and 3GPP2 in which IPsec SA is not mandatory." Regards, Ahmad > -----Original Message----- > From: Frank Xia [mailto:xiayangsong@huawei.com] > Sent: Friday, July 11, 2008 10:18 AM > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > Subject: Re: [MEXT] FW: I-D > Action:draft-muhanna-mext-binding-revocation-02.txt > > Hi Ahmad > > How to secure the signaling between HA and MN if there is no IPsec? > > BR > Frank > > ----- Original Message ----- > From: "Ahmad Muhanna" > To: "Frank Xia" ; > Sent: Friday, July 11, 2008 10:12 AM > Subject: RE: [MEXT] FW: I-D > Action:draft-muhanna-mext-binding-revocation-02.txt > > > Hi Frank, > > I do not think there is a conflict here. > > In the case of WiMAX and 3GPP2, I assume that there will be > no IPsec SA between the HA and the MN, for example. > Therefore, there will be no SPD to worry about. Although the > BRI/BRA uses the MGSM which has a MH type that support IPsec > (if IPsec is used), but that is not applicable to the case > you mentioned then there is no problem. > > Does that make sense? > > Regards, > Ahmad > > > > -----Original Message----- > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > Sent: Friday, July 11, 2008 9:23 AM > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > Subject: Re: [MEXT] FW: I-D > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > Hi Ahmad > > > > IMHO, this document can't be directly used by WiMAX and > 3GPP2 in which > > IPsec SA is not mandatory. > > > > 3GPP2/WiMAX adopted RFC4285, and corresponding documents, such as > > Diameter, RADIUS, now are explicitely supporting RFC4285. > > > > We discussed before. > > > > BR > > Frank > > > > > > ----- Original Message ----- > > From: "Ahmad Muhanna" > > To: > > Sent: Friday, July 11, 2008 8:53 AM > > Subject: [MEXT] FW: I-D > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > Hello Folks, > > > > We updated the Binding Revocation draft according to the mext wg ml > > consensus by using the Mobile IPv6 Generic Signaling Message (MGSM) > > framework. Since the MGSM draft is still being revised, we > referenced > > the MGSM draft in all related sections of the Binding Revocation > > draft. > > We probably will be able to optimize the draft a little > more in order > > to eliminate any duplication in some sections as soon as > the new MGSM > > draft revision becomes available. > > > > The only other change introduced in this revision is that we > > referenced the DSMIP6 draft and made it optional for the HA > to include > > the IPv4 home address in the BRI. > > > > With the aggressive schedule and 3GPP dependency on this draft, we > > appreciate your review, comment, and feedback. > > > > Thanks in advance! > > > > Regards, > > Ahmad > > > > -----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, July 11, 2008 8:45 AM > > To: i-d-announce@ietf.org > > Subject: I-D Action:draft-muhanna-mext-binding-revocation-02.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > Title : Binding Revocation for IPv6 Mobility > > Author(s) : A. Muhanna, et al. > > Filename : draft-muhanna-mext-binding-revocation-02.txt > > Pages : 32 > > Date : 2008-07-11 > > > > This document defines the revocation semantics for terminating a > > mobile node's mobility session and associated resources. These > > semantics are generic enough and can be used by mobility > entities in > > the case of Client Mobile IPv6 and its extensions. This mechanism > > allows the mobility entity which initiates the revocation > procedure to > > request its corresponding one to terminate either one, > multiple or all > > specified binding cache entries. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding > -revocatio > > n-02.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > > > > -------------------------------------------------------------- > > ------------------ > > > > > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 08:25:59 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 777F43A68C7; Fri, 11 Jul 2008 08:25:59 -0700 (PDT) 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 9AC513A68C7 for ; Fri, 11 Jul 2008 08:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxcvgJIAc4vJ for ; Fri, 11 Jul 2008 08:25:57 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 86CCA3A67E3 for ; Fri, 11 Jul 2008 08:25:57 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K3U00IOPLJRF1@usaga04-in.huawei.com> for mext@ietf.org; Fri, 11 Jul 2008 10:26:15 -0500 (CDT) Received: from X24512z ([10.124.12.92]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K3U007PILJQS1@usaga04-in.huawei.com> for mext@ietf.org; Fri, 11 Jul 2008 10:26:15 -0500 (CDT) Date: Fri, 11 Jul 2008 10:26:13 -0500 From: Frank Xia To: Ahmad Muhanna , mext@ietf.org Message-id: <001201c8e36a$746e18b0$5c0c7c0a@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: <00be01c8e361$a995d180$5c0c7c0a@china.huawei.com> <000601c8e369$530b9b80$5c0c7c0a@china.huawei.com> Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-02.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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ahmad I copy the security consideration from you draft. It says "The protocol described here uses the same security association between the MN and the HA or the MAG and the LMA that has been used to exchange the corresponding MIPv6 or Proxy MIPv6 BU and BA when the session was established. This SPD of this IPsec SA MUST allow the MH type for the MGSM." How to secure signalling if there is no IPsec? I can't find the answer. BR Frank ----- Original Message ----- From: "Ahmad Muhanna" To: "Frank Xia" ; Sent: Friday, July 11, 2008 10:20 AM Subject: RE: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-02.txt Hi Frank, I guess you need to answer that question. Right? I assume that what you mentioned about 3GPP2 and WiMAX is accurate. i.e., "by WiMAX and 3GPP2 in which IPsec SA is not mandatory." Regards, Ahmad > -----Original Message----- > From: Frank Xia [mailto:xiayangsong@huawei.com] > Sent: Friday, July 11, 2008 10:18 AM > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > Subject: Re: [MEXT] FW: I-D > Action:draft-muhanna-mext-binding-revocation-02.txt > > Hi Ahmad > > How to secure the signaling between HA and MN if there is no IPsec? > > BR > Frank > > ----- Original Message ----- > From: "Ahmad Muhanna" > To: "Frank Xia" ; > Sent: Friday, July 11, 2008 10:12 AM > Subject: RE: [MEXT] FW: I-D > Action:draft-muhanna-mext-binding-revocation-02.txt > > > Hi Frank, > > I do not think there is a conflict here. > > In the case of WiMAX and 3GPP2, I assume that there will be > no IPsec SA between the HA and the MN, for example. > Therefore, there will be no SPD to worry about. Although the > BRI/BRA uses the MGSM which has a MH type that support IPsec > (if IPsec is used), but that is not applicable to the case > you mentioned then there is no problem. > > Does that make sense? > > Regards, > Ahmad > > > > -----Original Message----- > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > Sent: Friday, July 11, 2008 9:23 AM > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > Subject: Re: [MEXT] FW: I-D > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > Hi Ahmad > > > > IMHO, this document can't be directly used by WiMAX and > 3GPP2 in which > > IPsec SA is not mandatory. > > > > 3GPP2/WiMAX adopted RFC4285, and corresponding documents, such as > > Diameter, RADIUS, now are explicitely supporting RFC4285. > > > > We discussed before. > > > > BR > > Frank > > > > > > ----- Original Message ----- > > From: "Ahmad Muhanna" > > To: > > Sent: Friday, July 11, 2008 8:53 AM > > Subject: [MEXT] FW: I-D > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > Hello Folks, > > > > We updated the Binding Revocation draft according to the mext wg ml > > consensus by using the Mobile IPv6 Generic Signaling Message (MGSM) > > framework. Since the MGSM draft is still being revised, we > referenced > > the MGSM draft in all related sections of the Binding Revocation > > draft. > > We probably will be able to optimize the draft a little > more in order > > to eliminate any duplication in some sections as soon as > the new MGSM > > draft revision becomes available. > > > > The only other change introduced in this revision is that we > > referenced the DSMIP6 draft and made it optional for the HA > to include > > the IPv4 home address in the BRI. > > > > With the aggressive schedule and 3GPP dependency on this draft, we > > appreciate your review, comment, and feedback. > > > > Thanks in advance! > > > > Regards, > > Ahmad > > > > -----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, July 11, 2008 8:45 AM > > To: i-d-announce@ietf.org > > Subject: I-D Action:draft-muhanna-mext-binding-revocation-02.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > Title : Binding Revocation for IPv6 Mobility > > Author(s) : A. Muhanna, et al. > > Filename : draft-muhanna-mext-binding-revocation-02.txt > > Pages : 32 > > Date : 2008-07-11 > > > > This document defines the revocation semantics for terminating a > > mobile node's mobility session and associated resources. These > > semantics are generic enough and can be used by mobility > entities in > > the case of Client Mobile IPv6 and its extensions. This mechanism > > allows the mobility entity which initiates the revocation > procedure to > > request its corresponding one to terminate either one, > multiple or all > > specified binding cache entries. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding > -revocatio > > n-02.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > > > > -------------------------------------------------------------- > > ------------------ > > > > > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 08:32:32 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E37833A6B51; Fri, 11 Jul 2008 08:32:32 -0700 (PDT) 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 2C7163A6B50 for ; Fri, 11 Jul 2008 08:32:32 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcTblf7XH+Hx for ; Fri, 11 Jul 2008 08:32:31 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id BF6FC3A6B3A for ; Fri, 11 Jul 2008 08:32:30 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6BFWjh26999; Fri, 11 Jul 2008 15:32:45 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 11 Jul 2008 10:32:41 -0500 Message-ID: In-Reply-To: <001201c8e36a$746e18b0$5c0c7c0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-02.txt Thread-Index: AcjjanvXqpJshcaWSjq9OnEFTtG85QAAAFmA References: <00be01c8e361$a995d180$5c0c7c0a@china.huawei.com> <000601c8e369$530b9b80$5c0c7c0a@china.huawei.com> <001201c8e36a$746e18b0$5c0c7c0a@china.huawei.com> From: "Ahmad Muhanna" To: "Frank Xia" , Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-02.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 Thanks Frank for pointing that, I believe the text should have been as follows: "The protocol described here uses the same security association between the MN and the HA or the MAG and the LMA that has been used to exchange the corresponding MIPv6 or Proxy MIPv6 BU and BA when the session was established. If IPsec is used, the SPD of this IPsec SA MUST allow the MH type for the MGSM." We will fix it and if there is other nits like this will, we will take care of it. Does that address your concern? Basically, the Binding Revocation messages should use the same security association that was used during the establishment of the session that being revoked. Regards, Ahmad > -----Original Message----- > From: Frank Xia [mailto:xiayangsong@huawei.com] > Sent: Friday, July 11, 2008 10:26 AM > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > Subject: Re: [MEXT] FW: I-D > Action:draft-muhanna-mext-binding-revocation-02.txt > > Hi Ahmad > > I copy the security consideration from you draft. > > It says "The protocol described here uses the same security > association > between the MN and the HA or the MAG and the LMA that has been used > to exchange the corresponding MIPv6 or Proxy MIPv6 BU and > BA when the > session was established. This SPD of this IPsec SA MUST > allow the MH > type for the MGSM." > > How to secure signalling if there is no IPsec? > > I can't find the answer. > > BR > Frank > > > ----- Original Message ----- > From: "Ahmad Muhanna" > To: "Frank Xia" ; > Sent: Friday, July 11, 2008 10:20 AM > Subject: RE: [MEXT] FW: I-D > Action:draft-muhanna-mext-binding-revocation-02.txt > > > Hi Frank, > > I guess you need to answer that question. Right? > I assume that what you mentioned about 3GPP2 and WiMAX is accurate. > i.e., > "by WiMAX and 3GPP2 in which IPsec SA is not mandatory." > > Regards, > Ahmad > > > > -----Original Message----- > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > Sent: Friday, July 11, 2008 10:18 AM > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > Subject: Re: [MEXT] FW: I-D > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > Hi Ahmad > > > > How to secure the signaling between HA and MN if there is no IPsec? > > > > BR > > Frank > > > > ----- Original Message ----- > > From: "Ahmad Muhanna" > > To: "Frank Xia" ; > > Sent: Friday, July 11, 2008 10:12 AM > > Subject: RE: [MEXT] FW: I-D > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > Hi Frank, > > > > I do not think there is a conflict here. > > > > In the case of WiMAX and 3GPP2, I assume that there will be > no IPsec > > SA between the HA and the MN, for example. > > Therefore, there will be no SPD to worry about. Although > the BRI/BRA > > uses the MGSM which has a MH type that support IPsec (if IPsec is > > used), but that is not applicable to the case you mentioned > then there > > is no problem. > > > > Does that make sense? > > > > Regards, > > Ahmad > > > > > > > -----Original Message----- > > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > > Sent: Friday, July 11, 2008 9:23 AM > > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > > Subject: Re: [MEXT] FW: I-D > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > Hi Ahmad > > > > > > IMHO, this document can't be directly used by WiMAX and > > 3GPP2 in which > > > IPsec SA is not mandatory. > > > > > > 3GPP2/WiMAX adopted RFC4285, and corresponding documents, such as > > > Diameter, RADIUS, now are explicitely supporting RFC4285. > > > > > > We discussed before. > > > > > > BR > > > Frank > > > > > > > > > ----- Original Message ----- > > > From: "Ahmad Muhanna" > > > To: > > > Sent: Friday, July 11, 2008 8:53 AM > > > Subject: [MEXT] FW: I-D > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > > > Hello Folks, > > > > > > We updated the Binding Revocation draft according to the > mext wg ml > > > consensus by using the Mobile IPv6 Generic Signaling > Message (MGSM) > > > framework. Since the MGSM draft is still being revised, we > > referenced > > > the MGSM draft in all related sections of the Binding Revocation > > > draft. > > > We probably will be able to optimize the draft a little > > more in order > > > to eliminate any duplication in some sections as soon as > > the new MGSM > > > draft revision becomes available. > > > > > > The only other change introduced in this revision is that we > > > referenced the DSMIP6 draft and made it optional for the HA > > to include > > > the IPv4 home address in the BRI. > > > > > > With the aggressive schedule and 3GPP dependency on this > draft, we > > > appreciate your review, comment, and feedback. > > > > > > Thanks in advance! > > > > > > Regards, > > > Ahmad > > > > > > -----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, July 11, 2008 8:45 AM > > > To: i-d-announce@ietf.org > > > Subject: I-D Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > A New Internet-Draft is available from the on-line > Internet-Drafts > > > directories. > > > > > > Title : Binding Revocation for IPv6 Mobility > > > Author(s) : A. Muhanna, et al. > > > Filename : draft-muhanna-mext-binding-revocation-02.txt > > > Pages : 32 > > > Date : 2008-07-11 > > > > > > This document defines the revocation semantics for terminating a > > > mobile node's mobility session and associated resources. These > > > semantics are generic enough and can be used by mobility > > entities in > > > the case of Client Mobile IPv6 and its extensions. This > mechanism > > > allows the mobility entity which initiates the revocation > > procedure to > > > request its corresponding one to terminate either one, > > multiple or all > > > specified binding cache entries. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding > > -revocatio > > > n-02.txt > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > Below is the data which will enable a MIME compliant mail reader > > > implementation to automatically retrieve the ASCII version of the > > > Internet-Draft. > > > > > > > > > > > > -------------------------------------------------------------- > > > ------------------ > > > > > > > > > > _______________________________________________ > > > > MEXT mailing list > > > > MEXT@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 08:37:07 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDC213A6B33; Fri, 11 Jul 2008 08:37:07 -0700 (PDT) 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 0C2E33A6B33 for ; Fri, 11 Jul 2008 08:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.335 X-Spam-Level: X-Spam-Status: No, score=-2.335 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGYlXSTXxycS for ; Fri, 11 Jul 2008 08:37:05 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id D68EC3A68C8 for ; Fri, 11 Jul 2008 08:37:05 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K3U00IW7M2BF1@usaga04-in.huawei.com> for mext@ietf.org; Fri, 11 Jul 2008 10:37:23 -0500 (CDT) Received: from X24512z ([10.124.12.92]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K3U007J5M29S1@usaga04-in.huawei.com> for mext@ietf.org; Fri, 11 Jul 2008 10:37:23 -0500 (CDT) Date: Fri, 11 Jul 2008 10:37:21 -0500 From: Frank Xia To: Ahmad Muhanna , mext@ietf.org Message-id: <003901c8e36c$02c6b850$5c0c7c0a@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: <00be01c8e361$a995d180$5c0c7c0a@china.huawei.com> <000601c8e369$530b9b80$5c0c7c0a@china.huawei.com> <001201c8e36a$746e18b0$5c0c7c0a@china.huawei.com> Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-02.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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ahmad Please add more information about "If IPsec is not used ...", IMO, it is not necessary limited to "If IPsec is used". BR Frank ----- Original Message ----- From: "Ahmad Muhanna" To: "Frank Xia" ; Sent: Friday, July 11, 2008 10:32 AM Subject: RE: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-02.txt Thanks Frank for pointing that, I believe the text should have been as follows: "The protocol described here uses the same security association between the MN and the HA or the MAG and the LMA that has been used to exchange the corresponding MIPv6 or Proxy MIPv6 BU and BA when the session was established. If IPsec is used, the SPD of this IPsec SA MUST allow the MH type for the MGSM." We will fix it and if there is other nits like this will, we will take care of it. Does that address your concern? Basically, the Binding Revocation messages should use the same security association that was used during the establishment of the session that being revoked. Regards, Ahmad > -----Original Message----- > From: Frank Xia [mailto:xiayangsong@huawei.com] > Sent: Friday, July 11, 2008 10:26 AM > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > Subject: Re: [MEXT] FW: I-D > Action:draft-muhanna-mext-binding-revocation-02.txt > > Hi Ahmad > > I copy the security consideration from you draft. > > It says "The protocol described here uses the same security > association > between the MN and the HA or the MAG and the LMA that has been used > to exchange the corresponding MIPv6 or Proxy MIPv6 BU and > BA when the > session was established. This SPD of this IPsec SA MUST > allow the MH > type for the MGSM." > > How to secure signalling if there is no IPsec? > > I can't find the answer. > > BR > Frank > > > ----- Original Message ----- > From: "Ahmad Muhanna" > To: "Frank Xia" ; > Sent: Friday, July 11, 2008 10:20 AM > Subject: RE: [MEXT] FW: I-D > Action:draft-muhanna-mext-binding-revocation-02.txt > > > Hi Frank, > > I guess you need to answer that question. Right? > I assume that what you mentioned about 3GPP2 and WiMAX is accurate. > i.e., > "by WiMAX and 3GPP2 in which IPsec SA is not mandatory." > > Regards, > Ahmad > > > > -----Original Message----- > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > Sent: Friday, July 11, 2008 10:18 AM > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > Subject: Re: [MEXT] FW: I-D > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > Hi Ahmad > > > > How to secure the signaling between HA and MN if there is no IPsec? > > > > BR > > Frank > > > > ----- Original Message ----- > > From: "Ahmad Muhanna" > > To: "Frank Xia" ; > > Sent: Friday, July 11, 2008 10:12 AM > > Subject: RE: [MEXT] FW: I-D > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > Hi Frank, > > > > I do not think there is a conflict here. > > > > In the case of WiMAX and 3GPP2, I assume that there will be > no IPsec > > SA between the HA and the MN, for example. > > Therefore, there will be no SPD to worry about. Although > the BRI/BRA > > uses the MGSM which has a MH type that support IPsec (if IPsec is > > used), but that is not applicable to the case you mentioned > then there > > is no problem. > > > > Does that make sense? > > > > Regards, > > Ahmad > > > > > > > -----Original Message----- > > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > > Sent: Friday, July 11, 2008 9:23 AM > > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > > Subject: Re: [MEXT] FW: I-D > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > Hi Ahmad > > > > > > IMHO, this document can't be directly used by WiMAX and > > 3GPP2 in which > > > IPsec SA is not mandatory. > > > > > > 3GPP2/WiMAX adopted RFC4285, and corresponding documents, such as > > > Diameter, RADIUS, now are explicitely supporting RFC4285. > > > > > > We discussed before. > > > > > > BR > > > Frank > > > > > > > > > ----- Original Message ----- > > > From: "Ahmad Muhanna" > > > To: > > > Sent: Friday, July 11, 2008 8:53 AM > > > Subject: [MEXT] FW: I-D > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > > > Hello Folks, > > > > > > We updated the Binding Revocation draft according to the > mext wg ml > > > consensus by using the Mobile IPv6 Generic Signaling > Message (MGSM) > > > framework. Since the MGSM draft is still being revised, we > > referenced > > > the MGSM draft in all related sections of the Binding Revocation > > > draft. > > > We probably will be able to optimize the draft a little > > more in order > > > to eliminate any duplication in some sections as soon as > > the new MGSM > > > draft revision becomes available. > > > > > > The only other change introduced in this revision is that we > > > referenced the DSMIP6 draft and made it optional for the HA > > to include > > > the IPv4 home address in the BRI. > > > > > > With the aggressive schedule and 3GPP dependency on this > draft, we > > > appreciate your review, comment, and feedback. > > > > > > Thanks in advance! > > > > > > Regards, > > > Ahmad > > > > > > -----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, July 11, 2008 8:45 AM > > > To: i-d-announce@ietf.org > > > Subject: I-D Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > A New Internet-Draft is available from the on-line > Internet-Drafts > > > directories. > > > > > > Title : Binding Revocation for IPv6 Mobility > > > Author(s) : A. Muhanna, et al. > > > Filename : draft-muhanna-mext-binding-revocation-02.txt > > > Pages : 32 > > > Date : 2008-07-11 > > > > > > This document defines the revocation semantics for terminating a > > > mobile node's mobility session and associated resources. These > > > semantics are generic enough and can be used by mobility > > entities in > > > the case of Client Mobile IPv6 and its extensions. This > mechanism > > > allows the mobility entity which initiates the revocation > > procedure to > > > request its corresponding one to terminate either one, > > multiple or all > > > specified binding cache entries. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding > > -revocatio > > > n-02.txt > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > Below is the data which will enable a MIME compliant mail reader > > > implementation to automatically retrieve the ASCII version of the > > > Internet-Draft. > > > > > > > > > > > > -------------------------------------------------------------- > > > ------------------ > > > > > > > > > > _______________________________________________ > > > > MEXT mailing list > > > > MEXT@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 08:47:05 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C943528C212; Fri, 11 Jul 2008 08:47:05 -0700 (PDT) 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 F280D28C210 for ; Fri, 11 Jul 2008 08:47:04 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uoG-UlNeOFLw for ; Fri, 11 Jul 2008 08:47:03 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 29D3228C215 for ; Fri, 11 Jul 2008 08:46:17 -0700 (PDT) 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 m6BFilu10897; Fri, 11 Jul 2008 15:44:48 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 11 Jul 2008 10:46:30 -0500 Message-ID: In-Reply-To: <003901c8e36c$02c6b850$5c0c7c0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-02.txt Thread-Index: AcjjbBW3v+U3KF9URK+t1SqRcq4M0AAAFcfw References: <00be01c8e361$a995d180$5c0c7c0a@china.huawei.com> <000601c8e369$530b9b80$5c0c7c0a@china.huawei.com> <001201c8e36a$746e18b0$5c0c7c0a@china.huawei.com> <003901c8e36c$02c6b850$5c0c7c0a@china.huawei.com> From: "Ahmad Muhanna" To: "Frank Xia" , Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-02.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 Frank, The following text captures all different mechanisms that are used or can be used to establish a security association between the MN and the HA or the MAG and the LMA. "The protocol described here uses the same security association between the MN and the HA or the MAG and the LMA that has been used to exchange the corresponding MIPv6 or Proxy MIPv6 BU and BA when the session was established." I personally believe that it captures and cover all cases including the case you mentioned. Regards, Ahmad > -----Original Message----- > From: Frank Xia [mailto:xiayangsong@huawei.com] > Sent: Friday, July 11, 2008 10:37 AM > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > Subject: Re: [MEXT] FW: I-D > Action:draft-muhanna-mext-binding-revocation-02.txt > > Hi Ahmad > > Please add more information about "If IPsec is not used ...", > IMO, it is not necessary limited to "If IPsec is used". > > BR > Frank > > ----- Original Message ----- > From: "Ahmad Muhanna" > To: "Frank Xia" ; > Sent: Friday, July 11, 2008 10:32 AM > Subject: RE: [MEXT] FW: I-D > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > Thanks Frank for pointing that, I believe the text should have been as > follows: > > "The protocol described here uses the same security association > between the MN and the HA or the MAG and the LMA that has been used > to exchange the corresponding MIPv6 or Proxy MIPv6 BU and > BA when the > session was established. If IPsec is used, the SPD of > this IPsec SA > MUST allow the MH type for the MGSM." > > We will fix it and if there is other nits like this will, we > will take care of it. Does that address your concern? > > Basically, the Binding Revocation messages should use the > same security association that was used during the > establishment of the session that being revoked. > > Regards, > Ahmad > > > > -----Original Message----- > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > Sent: Friday, July 11, 2008 10:26 AM > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > Subject: Re: [MEXT] FW: I-D > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > Hi Ahmad > > > > I copy the security consideration from you draft. > > > > It says "The protocol described here uses the same security > > association > > between the MN and the HA or the MAG and the LMA that > has been used > > to exchange the corresponding MIPv6 or Proxy MIPv6 BU > and BA when > > the > > session was established. This SPD of this IPsec SA MUST > allow the > > MH > > type for the MGSM." > > > > How to secure signalling if there is no IPsec? > > > > I can't find the answer. > > > > BR > > Frank > > > > > > ----- Original Message ----- > > From: "Ahmad Muhanna" > > To: "Frank Xia" ; > > Sent: Friday, July 11, 2008 10:20 AM > > Subject: RE: [MEXT] FW: I-D > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > Hi Frank, > > > > I guess you need to answer that question. Right? > > I assume that what you mentioned about 3GPP2 and WiMAX is accurate. > > i.e., > > "by WiMAX and 3GPP2 in which IPsec SA is not mandatory." > > > > Regards, > > Ahmad > > > > > > > -----Original Message----- > > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > > Sent: Friday, July 11, 2008 10:18 AM > > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > > Subject: Re: [MEXT] FW: I-D > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > Hi Ahmad > > > > > > How to secure the signaling between HA and MN if there is > no IPsec? > > > > > > BR > > > Frank > > > > > > ----- Original Message ----- > > > From: "Ahmad Muhanna" > > > To: "Frank Xia" ; > > > Sent: Friday, July 11, 2008 10:12 AM > > > Subject: RE: [MEXT] FW: I-D > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > Hi Frank, > > > > > > I do not think there is a conflict here. > > > > > > In the case of WiMAX and 3GPP2, I assume that there will be > > no IPsec > > > SA between the HA and the MN, for example. > > > Therefore, there will be no SPD to worry about. Although > > the BRI/BRA > > > uses the MGSM which has a MH type that support IPsec (if IPsec is > > > used), but that is not applicable to the case you mentioned > > then there > > > is no problem. > > > > > > Does that make sense? > > > > > > Regards, > > > Ahmad > > > > > > > > > > -----Original Message----- > > > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > > > Sent: Friday, July 11, 2008 9:23 AM > > > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > > > Subject: Re: [MEXT] FW: I-D > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > Hi Ahmad > > > > > > > > IMHO, this document can't be directly used by WiMAX and > > > 3GPP2 in which > > > > IPsec SA is not mandatory. > > > > > > > > 3GPP2/WiMAX adopted RFC4285, and corresponding > documents, such as > > > > Diameter, RADIUS, now are explicitely supporting RFC4285. > > > > > > > > We discussed before. > > > > > > > > BR > > > > Frank > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Ahmad Muhanna" > > > > To: > > > > Sent: Friday, July 11, 2008 8:53 AM > > > > Subject: [MEXT] FW: I-D > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > > > > > > > Hello Folks, > > > > > > > > We updated the Binding Revocation draft according to the > > mext wg ml > > > > consensus by using the Mobile IPv6 Generic Signaling > > Message (MGSM) > > > > framework. Since the MGSM draft is still being revised, we > > > referenced > > > > the MGSM draft in all related sections of the Binding > Revocation > > > > draft. > > > > We probably will be able to optimize the draft a little > > > more in order > > > > to eliminate any duplication in some sections as soon as > > > the new MGSM > > > > draft revision becomes available. > > > > > > > > The only other change introduced in this revision is that we > > > > referenced the DSMIP6 draft and made it optional for the HA > > > to include > > > > the IPv4 home address in the BRI. > > > > > > > > With the aggressive schedule and 3GPP dependency on this > > draft, we > > > > appreciate your review, comment, and feedback. > > > > > > > > Thanks in advance! > > > > > > > > Regards, > > > > Ahmad > > > > > > > > -----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, July 11, 2008 8:45 AM > > > > To: i-d-announce@ietf.org > > > > Subject: I-D Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts > > > > directories. > > > > > > > > Title : Binding Revocation for IPv6 Mobility > > > > Author(s) : A. Muhanna, et al. > > > > Filename : draft-muhanna-mext-binding-revocation-02.txt > > > > Pages : 32 > > > > Date : 2008-07-11 > > > > > > > > This document defines the revocation semantics for > terminating a > > > > mobile node's mobility session and associated resources. These > > > > semantics are generic enough and can be used by mobility > > > entities in > > > > the case of Client Mobile IPv6 and its extensions. This > > mechanism > > > > allows the mobility entity which initiates the revocation > > > procedure to > > > > request its corresponding one to terminate either one, > > > multiple or all > > > > specified binding cache entries. > > > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding > > > -revocatio > > > > n-02.txt > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > Below is the data which will enable a MIME compliant > mail reader > > > > implementation to automatically retrieve the ASCII > version of the > > > > Internet-Draft. > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > ------------------ > > > > > > > > > > > > > _______________________________________________ > > > > > MEXT mailing list > > > > > MEXT@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 09:07:30 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9A5628C123; Fri, 11 Jul 2008 09:07:30 -0700 (PDT) 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 6F1C628C16B for ; Fri, 11 Jul 2008 09:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhPZfjGzxgYw for ; Fri, 11 Jul 2008 09:07:28 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 235053A6768 for ; Fri, 11 Jul 2008 09:07:28 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K3U00IF1NGVF1@usaga04-in.huawei.com> for mext@ietf.org; Fri, 11 Jul 2008 11:07:46 -0500 (CDT) Received: from X24512z ([10.124.12.92]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K3U0073RNGUS1@usaga04-in.huawei.com> for mext@ietf.org; Fri, 11 Jul 2008 11:07:43 -0500 (CDT) Date: Fri, 11 Jul 2008 11:06:16 -0500 From: Frank Xia To: Ahmad Muhanna , mext@ietf.org Message-id: <000e01c8e370$3f9f83c0$5c0c7c0a@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: <00be01c8e361$a995d180$5c0c7c0a@china.huawei.com> <000601c8e369$530b9b80$5c0c7c0a@china.huawei.com> <001201c8e36a$746e18b0$5c0c7c0a@china.huawei.com> <003901c8e36c$02c6b850$5c0c7c0a@china.huawei.com> Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-02.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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ahmad Firstly, why do you only mention "If IPsec is used" ? Secondly, there are different security mechanism between RFC3776/4877 and RFC4285. As to the latter, there is not separated SA establishment and maitanance machanism (such as IKE), and each packet should authenticate itselft. IMO, your original text is only about IPsec case, and your later text only highlights IPsec case. Could you give me an explicit answer? How to secure the signaling between HA and MN if there is no IPsec? Please don't ask me because I am not the author of draft. Of course, I am willing to answer the question if you add me as an co-author :-) BR Frank ----- Original Message ----- From: "Ahmad Muhanna" To: "Frank Xia" ; Sent: Friday, July 11, 2008 10:46 AM Subject: RE: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-02.txt Hi Frank, The following text captures all different mechanisms that are used or can be used to establish a security association between the MN and the HA or the MAG and the LMA. "The protocol described here uses the same security association between the MN and the HA or the MAG and the LMA that has been used to exchange the corresponding MIPv6 or Proxy MIPv6 BU and BA when the session was established." I personally believe that it captures and cover all cases including the case you mentioned. Regards, Ahmad > -----Original Message----- > From: Frank Xia [mailto:xiayangsong@huawei.com] > Sent: Friday, July 11, 2008 10:37 AM > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > Subject: Re: [MEXT] FW: I-D > Action:draft-muhanna-mext-binding-revocation-02.txt > > Hi Ahmad > > Please add more information about "If IPsec is not used ...", > IMO, it is not necessary limited to "If IPsec is used". > > BR > Frank > > ----- Original Message ----- > From: "Ahmad Muhanna" > To: "Frank Xia" ; > Sent: Friday, July 11, 2008 10:32 AM > Subject: RE: [MEXT] FW: I-D > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > Thanks Frank for pointing that, I believe the text should have been as > follows: > > "The protocol described here uses the same security association > between the MN and the HA or the MAG and the LMA that has been used > to exchange the corresponding MIPv6 or Proxy MIPv6 BU and > BA when the > session was established. If IPsec is used, the SPD of > this IPsec SA > MUST allow the MH type for the MGSM." > > We will fix it and if there is other nits like this will, we > will take care of it. Does that address your concern? > > Basically, the Binding Revocation messages should use the > same security association that was used during the > establishment of the session that being revoked. > > Regards, > Ahmad > > > > -----Original Message----- > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > Sent: Friday, July 11, 2008 10:26 AM > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > Subject: Re: [MEXT] FW: I-D > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > Hi Ahmad > > > > I copy the security consideration from you draft. > > > > It says "The protocol described here uses the same security > > association > > between the MN and the HA or the MAG and the LMA that > has been used > > to exchange the corresponding MIPv6 or Proxy MIPv6 BU > and BA when > > the > > session was established. This SPD of this IPsec SA MUST > allow the > > MH > > type for the MGSM." > > > > How to secure signalling if there is no IPsec? > > > > I can't find the answer. > > > > BR > > Frank > > > > > > ----- Original Message ----- > > From: "Ahmad Muhanna" > > To: "Frank Xia" ; > > Sent: Friday, July 11, 2008 10:20 AM > > Subject: RE: [MEXT] FW: I-D > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > Hi Frank, > > > > I guess you need to answer that question. Right? > > I assume that what you mentioned about 3GPP2 and WiMAX is accurate. > > i.e., > > "by WiMAX and 3GPP2 in which IPsec SA is not mandatory." > > > > Regards, > > Ahmad > > > > > > > -----Original Message----- > > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > > Sent: Friday, July 11, 2008 10:18 AM > > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > > Subject: Re: [MEXT] FW: I-D > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > Hi Ahmad > > > > > > How to secure the signaling between HA and MN if there is > no IPsec? > > > > > > BR > > > Frank > > > > > > ----- Original Message ----- > > > From: "Ahmad Muhanna" > > > To: "Frank Xia" ; > > > Sent: Friday, July 11, 2008 10:12 AM > > > Subject: RE: [MEXT] FW: I-D > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > Hi Frank, > > > > > > I do not think there is a conflict here. > > > > > > In the case of WiMAX and 3GPP2, I assume that there will be > > no IPsec > > > SA between the HA and the MN, for example. > > > Therefore, there will be no SPD to worry about. Although > > the BRI/BRA > > > uses the MGSM which has a MH type that support IPsec (if IPsec is > > > used), but that is not applicable to the case you mentioned > > then there > > > is no problem. > > > > > > Does that make sense? > > > > > > Regards, > > > Ahmad > > > > > > > > > > -----Original Message----- > > > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > > > Sent: Friday, July 11, 2008 9:23 AM > > > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > > > Subject: Re: [MEXT] FW: I-D > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > Hi Ahmad > > > > > > > > IMHO, this document can't be directly used by WiMAX and > > > 3GPP2 in which > > > > IPsec SA is not mandatory. > > > > > > > > 3GPP2/WiMAX adopted RFC4285, and corresponding > documents, such as > > > > Diameter, RADIUS, now are explicitely supporting RFC4285. > > > > > > > > We discussed before. > > > > > > > > BR > > > > Frank > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Ahmad Muhanna" > > > > To: > > > > Sent: Friday, July 11, 2008 8:53 AM > > > > Subject: [MEXT] FW: I-D > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > > > > > > > Hello Folks, > > > > > > > > We updated the Binding Revocation draft according to the > > mext wg ml > > > > consensus by using the Mobile IPv6 Generic Signaling > > Message (MGSM) > > > > framework. Since the MGSM draft is still being revised, we > > > referenced > > > > the MGSM draft in all related sections of the Binding > Revocation > > > > draft. > > > > We probably will be able to optimize the draft a little > > > more in order > > > > to eliminate any duplication in some sections as soon as > > > the new MGSM > > > > draft revision becomes available. > > > > > > > > The only other change introduced in this revision is that we > > > > referenced the DSMIP6 draft and made it optional for the HA > > > to include > > > > the IPv4 home address in the BRI. > > > > > > > > With the aggressive schedule and 3GPP dependency on this > > draft, we > > > > appreciate your review, comment, and feedback. > > > > > > > > Thanks in advance! > > > > > > > > Regards, > > > > Ahmad > > > > > > > > -----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, July 11, 2008 8:45 AM > > > > To: i-d-announce@ietf.org > > > > Subject: I-D Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts > > > > directories. > > > > > > > > Title : Binding Revocation for IPv6 Mobility > > > > Author(s) : A. Muhanna, et al. > > > > Filename : draft-muhanna-mext-binding-revocation-02.txt > > > > Pages : 32 > > > > Date : 2008-07-11 > > > > > > > > This document defines the revocation semantics for > terminating a > > > > mobile node's mobility session and associated resources. These > > > > semantics are generic enough and can be used by mobility > > > entities in > > > > the case of Client Mobile IPv6 and its extensions. This > > mechanism > > > > allows the mobility entity which initiates the revocation > > > procedure to > > > > request its corresponding one to terminate either one, > > > multiple or all > > > > specified binding cache entries. > > > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding > > > -revocatio > > > > n-02.txt > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > Below is the data which will enable a MIME compliant > mail reader > > > > implementation to automatically retrieve the ASCII > version of the > > > > Internet-Draft. > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > ------------------ > > > > > > > > > > > > > _______________________________________________ > > > > > MEXT mailing list > > > > > MEXT@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 09:39:22 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65A003A6B67; Fri, 11 Jul 2008 09:39:22 -0700 (PDT) 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 28CAA28C209 for ; Fri, 11 Jul 2008 09:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sp9Moz6dooLD for ; Fri, 11 Jul 2008 09:39:21 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id D09783A6867 for ; Fri, 11 Jul 2008 09:39:20 -0700 (PDT) Received: from localhost ([127.0.0.1]:42731 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1KHLef-0000so-Cz; Fri, 11 Jul 2008 18:39:33 +0200 MIME-Version: 1.0 From: "mext" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software To: charliep@computer.org X-Trac-Project: mext Date: Fri, 11 Jul 2008 16:39:33 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/mext/trac/ticket/12 Message-ID: <063.d3e980d28cd819f0dd4dda19a3d0a981@tools.ietf.org> X-Trac-Ticket-ID: 12 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, alexandru.petrescu@gmail.com, mext@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: mext@ietf.org Subject: [MEXT] [mext] #12: BErr sent by HA too, not only by CN [Alexandru Petrescu ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mext@ietf.org 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 Ticket #12: BErr sent by HA too, not only by CN [Alexandru Petrescu ] [see also previous discussion as part of issue #3] Vijay Devarapalli : ... This email is about the HA sending binding error messages. RFC 3775 already supports the HA sending Binding Error with status '2'. Section 9.2 (CN considerations 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). Section 10.2 (HA considerations section) says All IPv6 home agents MUST observe the rules described in Section 9.2 when processing Mobility Headers. So I think we should make the change Alex has suggested for the Binding Error message at http://www.ietf.org/mail-archive/web/mext/current/msg00374.html There is still an issue about whether the home agent is also allowed to send the Binding Error message with status '1'. This is not clear in RFC 3775. From what I remember, this was designed mainly for the CN to tell the MN that there is no binding cache entry if the MN sends a packet with the home address option to the CN thinking it already has a binding at the CN. IMO, the home agent has no use for this. In fact RFC 3775 already says packets received with home address option without a corresponding binding cache entry should be silently dropped unless the packet contains a binding update. This was pointed out by Ahmad in http://www.ietf.org/mail-archive/web/mext/current/msg00495.html --------------------------------------------------------------------- Brian Haley I would change last sentence to say: Binding Error The Binding Error is used by the correspondent node or the home agent to signal an error related to mobility, such as an inappropriate attempt to use the Home Address destination option without an existing binding, or when an unrecognized Mobility Header is received. --------------------------------------------------------------------- Alexandru Petrescu I agree, at least one goal for HA to send the BErr is when the HA received and MH which it doesn't understand. Like "when an unrecognized Mobility Header Type is received (section 9.2 second bullet)". This is what I implemented. As for HA sending BErr when there's no BC entry for the HoA in a DO, it may be worth implementing at HA (in addition to CN), or I can live without. --------------------------------------------------------------------- Julien Laganier ... As of now it seems we have consensus on modifying the description of Binding **Error** as below ... OLD TEXT: Binding Error The Binding Error is used by the correspondent node to signal an error related to mobility, such as an inappropriate attempt to use the Home Address destination option without an existing binding. NEW TEXT: Binding Error The Binding Error is used by the correspondent node or the home agent to signal an error related to mobility, such as an inappropriate attempt to use the Home Address destination option without an existing binding, or when an unrecognized Mobility Header is received. --------------------------------------------------------------------- ----------------------------------------+----------------------------------- Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: minor | Milestone: Component: draft-ietf-mext-rfc3775bis | Version: Severity: Active WG Document | Keywords: Binding Error ----------------------------------------+----------------------------------- -- Ticket URL: mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 09:41:16 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54E9A3A6B69; Fri, 11 Jul 2008 09:41:16 -0700 (PDT) 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 9B3AD3A6B6C for ; Fri, 11 Jul 2008 09:41:14 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id makONN4QtXVJ for ; Fri, 11 Jul 2008 09:41:13 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 45B4A28C1A0 for ; Fri, 11 Jul 2008 09:40:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,346,1212364800"; d="scan'208";a="14158218" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 11 Jul 2008 16:41:09 +0000 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 m6BGf9U5003895; Fri, 11 Jul 2008 18:41:09 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6BGf9s8023779; Fri, 11 Jul 2008 16:41:09 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); Fri, 11 Jul 2008 18:41:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 11 Jul 2008 18:40:20 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05F1D85F@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] Thread-Index: Acjh8V+MjNkSZIeVRpqs1hq3iTkwfwBgC3SQ References: <010801c8e16b$5c2889d0$7471510a@psl.local> From: "Pascal Thubert (pthubert)" To: "Sri Gundavelli (sgundave)" X-OriginalArrivalTime: 11 Jul 2008 16:41:08.0780 (UTC) FILETIME=[EB8F2EC0:01C8E374] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2869; t=1215794469; x=1216658469; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[MEXT]=20[mext]=20#11=3A=20De-registrat ion=20when=20returning=20home=20[VijayDevarapalli=20] |Sender:=20; bh=bo2nYEllJPw/7XUlHRvuf4I5zhxuNam9ga646xIPnBg=; b=jeYRl2TSL4J9Guv8sm2j4E6YaCKfW8StZ55flvj6zmBoogOw757bub7ioh iHcCyCa3hgPIZMAqGkVb19FYAZTtuhlLBG8o9UPasNF9WRoxhBJ1NyhcQHhJ bN1LTIVy19; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli ] 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, I won't reply to all your mails but I'm 100 % with you all the way through. In particular, you're very right that it would just be nonsense for a HA to try and reclaim SeND based addresses when a MN proves ownership on link. We need to prepare for the coming changes and adapt the spec. In short the HA is a proxy and it should behave as such. RFC3775bis might live in its bubble and expect that all MN will act proper. But there are a number of scenarios, including reboot with loss of state, where the MN might not. And the real attacks against the MN home address might not come from nodes that behave proper, whether that's voluntary or not. When the MN comes back home and does not have the right states to unbind, - if the MN is a good citizen, it should DAD its address and the HA should defend it. I'm asking that upon DAD, the HA do not set the Override bit; that change to the spec would allow the MN to differentiate a real collision from a proxy collision. I would call that a proxy-success for the DAD flow. - but to avoid trouble when coming home, I'd expect that implementations that do not wish to get angry customer calls in the middle of the night would send RA (Override) right away. I know, that's bad. But that's damn quick and efficent. That's how we do hot standby... What happens next? - A node should get its address back if only proxies are defending it. In MIP case, whether the MN can clean up the binding properly or fails for some reason, it should NA(override) its address. At least that should be rightful if DAD proxy-succeeds. - Upon NA override, a proxy should yield silently. The HA should remove its binding. This flow would also enables a HA that gets a new BU to take over the binding from the old HA. Proxy or not proxy? That is the question... Pascal >-----Original Message----- >From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Sri Gundavelli (sgundave) >Sent: mercredi 9 juillet 2008 20:26 >To: Giaretta, Gerardo >Cc: charliep@computer.org; mext@ietf.org >Subject: Re: [MEXT] [mext] #11: De-registration when returning home [VijayDevarapalli >] > > >Just one comment. > > >> Until the mobile node sends a de-registration Binding Update, it will >> not >> be able to send and receive packets using its home address from the home >> link. > >I have a problem with this. As Pascal and Rajiv pointed out, nothing >really stops the MN, which is the legitimate address owner to reclaim >and start using its home address on the home link and without sending >a BU with life=0. This has to confirm to the override flag purpose in >ND. > >Sri > >_______________________________________________ >MEXT mailing list >MEXT@ietf.org >https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 10:49:27 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB09D3A692B; Fri, 11 Jul 2008 10:49:26 -0700 (PDT) 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 6BBC73A692B for ; Fri, 11 Jul 2008 10:49:25 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10Apie9sxVwP for ; Fri, 11 Jul 2008 10:49:23 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 8DADC3A6768 for ; Fri, 11 Jul 2008 10:49:23 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6BHnch16956; Fri, 11 Jul 2008 17:49:38 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 11 Jul 2008 12:49:22 -0500 Message-ID: In-Reply-To: <000e01c8e370$3f9f83c0$5c0c7c0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-02.txt Thread-Index: AcjjcEhjlCQoI6vjSZG7AVu0QjXppQABpzOA References: <00be01c8e361$a995d180$5c0c7c0a@china.huawei.com> <000601c8e369$530b9b80$5c0c7c0a@china.huawei.com> <001201c8e36a$746e18b0$5c0c7c0a@china.huawei.com> <003901c8e36c$02c6b850$5c0c7c0a@china.huawei.com> <000e01c8e370$3f9f83c0$5c0c7c0a@china.huawei.com> From: "Ahmad Muhanna" To: "Frank Xia" , Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-02.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 Thanks Frank! This is becoming a very interesting discussion:-) Let me try one more time. Please see inline. Regards, Ahmad > Action:draft-muhanna-mext-binding-revocation-02.txt > > Hi Ahmad > > Firstly, why do you only mention "If IPsec is used" ? Ok, since as per the consensus of the mext ml, the BRI and BRA use the Mobile IPv6 Generic Signaling Message (MGSM) framework, I believe what we need to do here: is to reference that draft and only document the exceptions. What about the following:? " The protocol described here uses the same security architecture and requirement of the Mobile IPv6 Generic Signaling Message framework as defined in [ID-MGSM]. However, in the case when the MAG sends a BRI message with the G bit is set, the LMA must verify that the MAG is authorized to use Per-Peer Global Revocation. " Therefore, there is no exception and IPsec is not treated differently than any other security mechanisms. > > Secondly, there are different security mechanism between RFC3776/4877 > and RFC4285. > As to the latter, there is not separated SA establishment > and maitanance machanism (such as IKE), and each packet should > authenticate itselft. [Ahmad] With the proposed text above, I guess this becomes a different discussion. We actually can take that offline. But I am just curious, what do you mean by the following:? 1. there is not separated SA establishment and maitanance machanism (such as IKE), and 2. each packet should authenticate itselft. > > IMO, your original text is only about IPsec case, and your later > text only highlights IPsec case. > > Could you give me an explicit answer? > How to secure the signaling between HA and MN if there is no IPsec? [Ahmad] I hope that this has been addressed, please see above. > > Please don't ask me because I am not the author of draft. > Of course, I am willing to answer the question if you add me > as an co-author > :-) > > BR > Frank > > ----- Original Message ----- > From: "Ahmad Muhanna" > To: "Frank Xia" ; > Sent: Friday, July 11, 2008 10:46 AM > Subject: RE: [MEXT] FW: I-D > Action:draft-muhanna-mext-binding-revocation-02.txt > > > Hi Frank, > > The following text captures all different mechanisms that are used or > can be used to establish a security association between the MN and the > HA or the MAG and the LMA. > > "The protocol described here uses the same security association > between the MN and the HA or the MAG and the LMA that has been used > to exchange the corresponding MIPv6 or Proxy MIPv6 BU and > BA when the > session was established." > > I personally believe that it captures and cover all cases > including the > case you mentioned. > > > Regards, > Ahmad > > > > -----Original Message----- > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > Sent: Friday, July 11, 2008 10:37 AM > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > Subject: Re: [MEXT] FW: I-D > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > Hi Ahmad > > > > Please add more information about "If IPsec is not used ...", > > IMO, it is not necessary limited to "If IPsec is used". > > > > BR > > Frank > > > > ----- Original Message ----- > > From: "Ahmad Muhanna" > > To: "Frank Xia" ; > > Sent: Friday, July 11, 2008 10:32 AM > > Subject: RE: [MEXT] FW: I-D > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > Thanks Frank for pointing that, I believe the text should > have been as > > follows: > > > > "The protocol described here uses the same security association > > between the MN and the HA or the MAG and the LMA that > has been used > > to exchange the corresponding MIPv6 or Proxy MIPv6 BU and > > BA when the > > session was established. If IPsec is used, the SPD of > > this IPsec SA > > MUST allow the MH type for the MGSM." > > > > We will fix it and if there is other nits like this will, we > > will take care of it. Does that address your concern? > > > > Basically, the Binding Revocation messages should use the > > same security association that was used during the > > establishment of the session that being revoked. > > > > Regards, > > Ahmad > > > > > > > -----Original Message----- > > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > > Sent: Friday, July 11, 2008 10:26 AM > > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > > Subject: Re: [MEXT] FW: I-D > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > Hi Ahmad > > > > > > I copy the security consideration from you draft. > > > > > > It says "The protocol described here uses the same security > > > association > > > between the MN and the HA or the MAG and the LMA that > > has been used > > > to exchange the corresponding MIPv6 or Proxy MIPv6 BU > > and BA when > > > the > > > session was established. This SPD of this IPsec SA MUST > > allow the > > > MH > > > type for the MGSM." > > > > > > How to secure signalling if there is no IPsec? > > > > > > I can't find the answer. > > > > > > BR > > > Frank > > > > > > > > > ----- Original Message ----- > > > From: "Ahmad Muhanna" > > > To: "Frank Xia" ; > > > Sent: Friday, July 11, 2008 10:20 AM > > > Subject: RE: [MEXT] FW: I-D > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > Hi Frank, > > > > > > I guess you need to answer that question. Right? > > > I assume that what you mentioned about 3GPP2 and WiMAX is > accurate. > > > i.e., > > > "by WiMAX and 3GPP2 in which IPsec SA is not mandatory." > > > > > > Regards, > > > Ahmad > > > > > > > > > > -----Original Message----- > > > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > > > Sent: Friday, July 11, 2008 10:18 AM > > > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > > > Subject: Re: [MEXT] FW: I-D > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > Hi Ahmad > > > > > > > > How to secure the signaling between HA and MN if there is > > no IPsec? > > > > > > > > BR > > > > Frank > > > > > > > > ----- Original Message ----- > > > > From: "Ahmad Muhanna" > > > > To: "Frank Xia" ; > > > > Sent: Friday, July 11, 2008 10:12 AM > > > > Subject: RE: [MEXT] FW: I-D > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > > > Hi Frank, > > > > > > > > I do not think there is a conflict here. > > > > > > > > In the case of WiMAX and 3GPP2, I assume that there will be > > > no IPsec > > > > SA between the HA and the MN, for example. > > > > Therefore, there will be no SPD to worry about. Although > > > the BRI/BRA > > > > uses the MGSM which has a MH type that support IPsec > (if IPsec is > > > > used), but that is not applicable to the case you mentioned > > > then there > > > > is no problem. > > > > > > > > Does that make sense? > > > > > > > > Regards, > > > > Ahmad > > > > > > > > > > > > > -----Original Message----- > > > > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > > > > Sent: Friday, July 11, 2008 9:23 AM > > > > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > > > > Subject: Re: [MEXT] FW: I-D > > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > Hi Ahmad > > > > > > > > > > IMHO, this document can't be directly used by WiMAX and > > > > 3GPP2 in which > > > > > IPsec SA is not mandatory. > > > > > > > > > > 3GPP2/WiMAX adopted RFC4285, and corresponding > > documents, such as > > > > > Diameter, RADIUS, now are explicitely supporting RFC4285. > > > > > > > > > > We discussed before. > > > > > > > > > > BR > > > > > Frank > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Ahmad Muhanna" > > > > > To: > > > > > Sent: Friday, July 11, 2008 8:53 AM > > > > > Subject: [MEXT] FW: I-D > > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > > > > > > > > > > > Hello Folks, > > > > > > > > > > We updated the Binding Revocation draft according to the > > > mext wg ml > > > > > consensus by using the Mobile IPv6 Generic Signaling > > > Message (MGSM) > > > > > framework. Since the MGSM draft is still being revised, we > > > > referenced > > > > > the MGSM draft in all related sections of the Binding > > Revocation > > > > > draft. > > > > > We probably will be able to optimize the draft a little > > > > more in order > > > > > to eliminate any duplication in some sections as soon as > > > > the new MGSM > > > > > draft revision becomes available. > > > > > > > > > > The only other change introduced in this revision is that we > > > > > referenced the DSMIP6 draft and made it optional for the HA > > > > to include > > > > > the IPv4 home address in the BRI. > > > > > > > > > > With the aggressive schedule and 3GPP dependency on this > > > draft, we > > > > > appreciate your review, comment, and feedback. > > > > > > > > > > Thanks in advance! > > > > > > > > > > Regards, > > > > > Ahmad > > > > > > > > > > -----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, July 11, 2008 8:45 AM > > > > > To: i-d-announce@ietf.org > > > > > Subject: I-D > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > A New Internet-Draft is available from the on-line > > > Internet-Drafts > > > > > directories. > > > > > > > > > > Title : Binding Revocation for IPv6 Mobility > > > > > Author(s) : A. Muhanna, et al. > > > > > Filename : draft-muhanna-mext-binding-revocation-02.txt > > > > > Pages : 32 > > > > > Date : 2008-07-11 > > > > > > > > > > This document defines the revocation semantics for > > terminating a > > > > > mobile node's mobility session and associated > resources. These > > > > > semantics are generic enough and can be used by mobility > > > > entities in > > > > > the case of Client Mobile IPv6 and its extensions. This > > > mechanism > > > > > allows the mobility entity which initiates the revocation > > > > procedure to > > > > > request its corresponding one to terminate either one, > > > > multiple or all > > > > > specified binding cache entries. > > > > > > > > > > A URL for this Internet-Draft is: > > > > > http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding > > > > -revocatio > > > > > n-02.txt > > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > > Below is the data which will enable a MIME compliant > > mail reader > > > > > implementation to automatically retrieve the ASCII > > version of the > > > > > Internet-Draft. > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > ------------------ > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > MEXT mailing list > > > > > > MEXT@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 10:52:16 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C011C3A6A87; Fri, 11 Jul 2008 10:52:16 -0700 (PDT) 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 C13C53A6A87 for ; Fri, 11 Jul 2008 10:52:15 -0700 (PDT) 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 yHDg+tvhL17Q for ; Fri, 11 Jul 2008 10:52:14 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 8C0FD3A68E4 for ; Fri, 11 Jul 2008 10:52:14 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 11 Jul 2008 13:52:25 -0400 Message-ID: In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05F1D85F@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [MEXT] [mext] #11: De-registration when returning home[VijayDevarapalli ] Thread-Index: Acjh8V+MjNkSZIeVRpqs1hq3iTkwfwBgC3SQAAMZZiA= References: <010801c8e16b$5c2889d0$7471510a@psl.local> <7892795E1A87F04CADFCCF41FADD00FC05F1D85F@xmb-ams-337.emea.cisco.com> From: "Vijay Devarapalli" To: "Pascal Thubert (pthubert)" , "Sri Gundavelli (sgundave)" , "Koodli, Rajeev" Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home[VijayDevarapalli ] 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 Sri, Pascal, Rajeev, I suggest you guys open a separate issue on whether a mobile node can claim its address without first sending a de-registration BU when it returns to the home link. RFC 3775 does not allow this. It is clearly a violation of RFC 3775. An RFC 3775-compliant mobile node is supposed to behave as described in RFC 3775 when it returns home. Not according to what RFC 4861 might allow an IPv6 host to do. For the issue we were discussing, lets go with the following text. A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.1), when the mobile node detects that its home subnet prefix is again on-link. To be able to send and receive packets using its home address from the home link, the mobile node MUST send a Binding Update to its home agent to instruct its home agent to no longer intercept or tunnel packets for it. Until the mobile node sends a de-registration Binding Update, it will not be able to send and receive packets using its home address from the home link. The home agent will continue to intercept all packets sent to the mobile's home address and tunnel to the previously registered care-of address. We need to close this issue. Based on what we decide later on whether the mobile node can claim its address without first sending a de-registration BU, we can revisit the above text. Vijay > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Pascal Thubert (pthubert) > Sent: Friday, July 11, 2008 9:40 AM > To: Sri Gundavelli (sgundave) > Cc: charliep@computer.org; mext@ietf.org > Subject: Re: [MEXT] [mext] #11: De-registration when > returning home[VijayDevarapalli ] > > Hi Sri, > > I won't reply to all your mails but I'm 100 % with you all the way > through. > > In particular, you're very right that it would just be > nonsense for a HA > to try and reclaim SeND based addresses when a MN proves ownership on > link. We need to prepare for the coming changes and adapt the spec. In > short the HA is a proxy and it should behave as such. > > RFC3775bis might live in its bubble and expect that all MN will act > proper. But there are a number of scenarios, including reboot > with loss > of state, where the MN might not. And the real attacks against the MN > home address might not come from nodes that behave proper, whether > that's voluntary or not. > > When the MN comes back home and does not have the right states to > unbind, > > - if the MN is a good citizen, it should DAD its address and the HA > should defend it. I'm asking that upon DAD, the HA do not set the > Override bit; that change to the spec would allow the MN to > differentiate a real collision from a proxy collision. I > would call that > a proxy-success for the DAD flow. > > - but to avoid trouble when coming home, I'd expect that > implementations > that do not wish to get angry customer calls in the middle of > the night > would send RA (Override) right away. I know, that's bad. But > that's damn > quick and efficent. That's how we do hot standby... > > What happens next? > > - A node should get its address back if only proxies are > defending it. > In MIP case, whether the MN can clean up the binding properly or fails > for some reason, it should NA(override) its address. At least that > should be rightful if DAD proxy-succeeds. > > - Upon NA override, a proxy should yield silently. > The HA should remove its binding. This flow would also > enables a HA that > gets a new BU to take over the binding from the old HA. > > Proxy or not proxy? That is the question... > > Pascal > > >-----Original Message----- > >From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] > On Behalf Of > Sri Gundavelli (sgundave) > >Sent: mercredi 9 juillet 2008 20:26 > >To: Giaretta, Gerardo > >Cc: charliep@computer.org; mext@ietf.org > >Subject: Re: [MEXT] [mext] #11: De-registration when returning home > [VijayDevarapalli > >] > > > > > >Just one comment. > > > > > >> Until the mobile node sends a de-registration Binding > Update, it will > >> not > >> be able to send and receive packets using its home address from the > home > >> link. > > > >I have a problem with this. As Pascal and Rajiv pointed out, nothing > >really stops the MN, which is the legitimate address owner to reclaim > >and start using its home address on the home link and without sending > >a BU with life=0. This has to confirm to the override flag purpose in > >ND. > > > >Sri > > > >_______________________________________________ > >MEXT mailing list > >MEXT@ietf.org > >https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 10:57:07 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A52728C16D; Fri, 11 Jul 2008 10:57:07 -0700 (PDT) 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 8B69128C16D for ; Fri, 11 Jul 2008 10:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vi351dfcMgzu for ; Fri, 11 Jul 2008 10:57:04 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 097ED3A6997 for ; Fri, 11 Jul 2008 10:57:04 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K3U0060ZSJL4T@usaga04-in.huawei.com> for mext@ietf.org; Fri, 11 Jul 2008 12:57:22 -0500 (CDT) Received: from X24512z ([10.124.12.92]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K3U00714SJKWY@usaga04-in.huawei.com> for mext@ietf.org; Fri, 11 Jul 2008 12:57:21 -0500 (CDT) Date: Fri, 11 Jul 2008 12:57:20 -0500 From: Frank Xia To: Ahmad Muhanna , mext@ietf.org Message-id: <005601c8e37f$90fc3a60$5c0c7c0a@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: <00be01c8e361$a995d180$5c0c7c0a@china.huawei.com> <000601c8e369$530b9b80$5c0c7c0a@china.huawei.com> <001201c8e36a$746e18b0$5c0c7c0a@china.huawei.com> <003901c8e36c$02c6b850$5c0c7c0a@china.huawei.com> <000e01c8e370$3f9f83c0$5c0c7c0a@china.huawei.com> Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-02.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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ahmad My question is very simple, why could you answer this directly? OK, I would like to reword my question. How to secure BRI/BRA messages when there is not IPsec SA between HA and MN? BR Frank ----- Original Message ----- From: "Ahmad Muhanna" To: "Frank Xia" ; Sent: Friday, July 11, 2008 12:49 PM Subject: RE: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-02.txt Thanks Frank! This is becoming a very interesting discussion:-) Let me try one more time. Please see inline. Regards, Ahmad > Action:draft-muhanna-mext-binding-revocation-02.txt > > Hi Ahmad > > Firstly, why do you only mention "If IPsec is used" ? Ok, since as per the consensus of the mext ml, the BRI and BRA use the Mobile IPv6 Generic Signaling Message (MGSM) framework, I believe what we need to do here: is to reference that draft and only document the exceptions. What about the following:? " The protocol described here uses the same security architecture and requirement of the Mobile IPv6 Generic Signaling Message framework as defined in [ID-MGSM]. However, in the case when the MAG sends a BRI message with the G bit is set, the LMA must verify that the MAG is authorized to use Per-Peer Global Revocation. " Therefore, there is no exception and IPsec is not treated differently than any other security mechanisms. > > Secondly, there are different security mechanism between RFC3776/4877 > and RFC4285. > As to the latter, there is not separated SA establishment > and maitanance machanism (such as IKE), and each packet should > authenticate itselft. [Ahmad] With the proposed text above, I guess this becomes a different discussion. We actually can take that offline. But I am just curious, what do you mean by the following:? 1. there is not separated SA establishment and maitanance machanism (such as IKE), and 2. each packet should authenticate itselft. > > IMO, your original text is only about IPsec case, and your later > text only highlights IPsec case. > > Could you give me an explicit answer? > How to secure the signaling between HA and MN if there is no IPsec? [Ahmad] I hope that this has been addressed, please see above. > > Please don't ask me because I am not the author of draft. > Of course, I am willing to answer the question if you add me > as an co-author > :-) > > BR > Frank > > ----- Original Message ----- > From: "Ahmad Muhanna" > To: "Frank Xia" ; > Sent: Friday, July 11, 2008 10:46 AM > Subject: RE: [MEXT] FW: I-D > Action:draft-muhanna-mext-binding-revocation-02.txt > > > Hi Frank, > > The following text captures all different mechanisms that are used or > can be used to establish a security association between the MN and the > HA or the MAG and the LMA. > > "The protocol described here uses the same security association > between the MN and the HA or the MAG and the LMA that has been used > to exchange the corresponding MIPv6 or Proxy MIPv6 BU and > BA when the > session was established." > > I personally believe that it captures and cover all cases > including the > case you mentioned. > > > Regards, > Ahmad > > > > -----Original Message----- > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > Sent: Friday, July 11, 2008 10:37 AM > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > Subject: Re: [MEXT] FW: I-D > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > Hi Ahmad > > > > Please add more information about "If IPsec is not used ...", > > IMO, it is not necessary limited to "If IPsec is used". > > > > BR > > Frank > > > > ----- Original Message ----- > > From: "Ahmad Muhanna" > > To: "Frank Xia" ; > > Sent: Friday, July 11, 2008 10:32 AM > > Subject: RE: [MEXT] FW: I-D > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > Thanks Frank for pointing that, I believe the text should > have been as > > follows: > > > > "The protocol described here uses the same security association > > between the MN and the HA or the MAG and the LMA that > has been used > > to exchange the corresponding MIPv6 or Proxy MIPv6 BU and > > BA when the > > session was established. If IPsec is used, the SPD of > > this IPsec SA > > MUST allow the MH type for the MGSM." > > > > We will fix it and if there is other nits like this will, we > > will take care of it. Does that address your concern? > > > > Basically, the Binding Revocation messages should use the > > same security association that was used during the > > establishment of the session that being revoked. > > > > Regards, > > Ahmad > > > > > > > -----Original Message----- > > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > > Sent: Friday, July 11, 2008 10:26 AM > > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > > Subject: Re: [MEXT] FW: I-D > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > Hi Ahmad > > > > > > I copy the security consideration from you draft. > > > > > > It says "The protocol described here uses the same security > > > association > > > between the MN and the HA or the MAG and the LMA that > > has been used > > > to exchange the corresponding MIPv6 or Proxy MIPv6 BU > > and BA when > > > the > > > session was established. This SPD of this IPsec SA MUST > > allow the > > > MH > > > type for the MGSM." > > > > > > How to secure signalling if there is no IPsec? > > > > > > I can't find the answer. > > > > > > BR > > > Frank > > > > > > > > > ----- Original Message ----- > > > From: "Ahmad Muhanna" > > > To: "Frank Xia" ; > > > Sent: Friday, July 11, 2008 10:20 AM > > > Subject: RE: [MEXT] FW: I-D > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > Hi Frank, > > > > > > I guess you need to answer that question. Right? > > > I assume that what you mentioned about 3GPP2 and WiMAX is > accurate. > > > i.e., > > > "by WiMAX and 3GPP2 in which IPsec SA is not mandatory." > > > > > > Regards, > > > Ahmad > > > > > > > > > > -----Original Message----- > > > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > > > Sent: Friday, July 11, 2008 10:18 AM > > > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > > > Subject: Re: [MEXT] FW: I-D > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > Hi Ahmad > > > > > > > > How to secure the signaling between HA and MN if there is > > no IPsec? > > > > > > > > BR > > > > Frank > > > > > > > > ----- Original Message ----- > > > > From: "Ahmad Muhanna" > > > > To: "Frank Xia" ; > > > > Sent: Friday, July 11, 2008 10:12 AM > > > > Subject: RE: [MEXT] FW: I-D > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > > > Hi Frank, > > > > > > > > I do not think there is a conflict here. > > > > > > > > In the case of WiMAX and 3GPP2, I assume that there will be > > > no IPsec > > > > SA between the HA and the MN, for example. > > > > Therefore, there will be no SPD to worry about. Although > > > the BRI/BRA > > > > uses the MGSM which has a MH type that support IPsec > (if IPsec is > > > > used), but that is not applicable to the case you mentioned > > > then there > > > > is no problem. > > > > > > > > Does that make sense? > > > > > > > > Regards, > > > > Ahmad > > > > > > > > > > > > > -----Original Message----- > > > > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > > > > Sent: Friday, July 11, 2008 9:23 AM > > > > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > > > > Subject: Re: [MEXT] FW: I-D > > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > Hi Ahmad > > > > > > > > > > IMHO, this document can't be directly used by WiMAX and > > > > 3GPP2 in which > > > > > IPsec SA is not mandatory. > > > > > > > > > > 3GPP2/WiMAX adopted RFC4285, and corresponding > > documents, such as > > > > > Diameter, RADIUS, now are explicitely supporting RFC4285. > > > > > > > > > > We discussed before. > > > > > > > > > > BR > > > > > Frank > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Ahmad Muhanna" > > > > > To: > > > > > Sent: Friday, July 11, 2008 8:53 AM > > > > > Subject: [MEXT] FW: I-D > > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > > > > > > > > > > > Hello Folks, > > > > > > > > > > We updated the Binding Revocation draft according to the > > > mext wg ml > > > > > consensus by using the Mobile IPv6 Generic Signaling > > > Message (MGSM) > > > > > framework. Since the MGSM draft is still being revised, we > > > > referenced > > > > > the MGSM draft in all related sections of the Binding > > Revocation > > > > > draft. > > > > > We probably will be able to optimize the draft a little > > > > more in order > > > > > to eliminate any duplication in some sections as soon as > > > > the new MGSM > > > > > draft revision becomes available. > > > > > > > > > > The only other change introduced in this revision is that we > > > > > referenced the DSMIP6 draft and made it optional for the HA > > > > to include > > > > > the IPv4 home address in the BRI. > > > > > > > > > > With the aggressive schedule and 3GPP dependency on this > > > draft, we > > > > > appreciate your review, comment, and feedback. > > > > > > > > > > Thanks in advance! > > > > > > > > > > Regards, > > > > > Ahmad > > > > > > > > > > -----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, July 11, 2008 8:45 AM > > > > > To: i-d-announce@ietf.org > > > > > Subject: I-D > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > A New Internet-Draft is available from the on-line > > > Internet-Drafts > > > > > directories. > > > > > > > > > > Title : Binding Revocation for IPv6 Mobility > > > > > Author(s) : A. Muhanna, et al. > > > > > Filename : draft-muhanna-mext-binding-revocation-02.txt > > > > > Pages : 32 > > > > > Date : 2008-07-11 > > > > > > > > > > This document defines the revocation semantics for > > terminating a > > > > > mobile node's mobility session and associated > resources. These > > > > > semantics are generic enough and can be used by mobility > > > > entities in > > > > > the case of Client Mobile IPv6 and its extensions. This > > > mechanism > > > > > allows the mobility entity which initiates the revocation > > > > procedure to > > > > > request its corresponding one to terminate either one, > > > > multiple or all > > > > > specified binding cache entries. > > > > > > > > > > A URL for this Internet-Draft is: > > > > > http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding > > > > -revocatio > > > > > n-02.txt > > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > > Below is the data which will enable a MIME compliant > > mail reader > > > > > implementation to automatically retrieve the ASCII > > version of the > > > > > Internet-Draft. > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > ------------------ > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > MEXT mailing list > > > > > > MEXT@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 11:00:48 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 953FB28C26B; Fri, 11 Jul 2008 11:00:48 -0700 (PDT) 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 B1D8728C26B for ; Fri, 11 Jul 2008 11:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MttG0KCFBvyr for ; Fri, 11 Jul 2008 11:00:46 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 4098F28C26A for ; Fri, 11 Jul 2008 11:00:46 -0700 (PDT) Received: from localhost ([127.0.0.1]:45020 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1KHMvT-0001Y3-2a; Fri, 11 Jul 2008 20:00:59 +0200 MIME-Version: 1.0 From: "mext" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software To: charliep@computer.org X-Trac-Project: mext Date: Fri, 11 Jul 2008 18:00:58 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/mext/trac/ticket/13 Message-ID: <063.44d72bbd38b42b8497376e892521c1fd@tools.ietf.org> X-Trac-Ticket-ID: 13 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, suresh.krishnan@ericsson.com, mext@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: mext@ietf.org Subject: [MEXT] [mext] #13: Home Link Detection [Suresh Krishnan ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mext@ietf.org 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 Ticket #13: Home Link Detection [Suresh Krishnan ] Suresh Krishnan [edited by CEP] The WG had consensus to fold in text from draft-krishnan-mext-hld into rfc3775bis. Here is the proposed text for doing so. [This change to be made in a new (sub)section called "Home Link Detection"] OLD TEXT ======== A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.1), when the mobile node detects that its home subnet prefix is again on-link. NEW TEXT ======== When an MN detects that it has arrived on a new link using the movement detection algorithm in use (Section 11.5.1) it performs the following steps to determine if it is on the home link. {{{ #!html
  • The MN performs the procedure described in Section 11.5.2 and configures an address referred to as the Current MN Address (CMA). It also stores all the on-link prefix(es) received in the RA along with their prefix lengths in a conceptual list called the Current Link Prefix List (CLPL).
}}} {{{ #!html
  • If the home prefix has been statically pre-configured on the MN it checks if the home prefix matches one of the prefixes in the CLPL. If it does, the MN concludes that it has returned home.
}}} {{{ #!html
  • If the home prefix has not been statically configured the MN uses some form of bootstrapping procedure (e.g. RFC5026) to determine the home prefix. It then checks if the home prefix matches one of the prefixes in the CLPL. If it does, the MN concludes that it has returned home.
}}} --------------------------------------------------------------------- "Charles E. Perkins" I would like to suggest a textual revision and simplification. Most of the revision relies on pointing out that one has to get a home network prefix before using it to compare against the list of prefixes received in the RA. The other revision, which I hope is O.K., is to dispense with creating the new acronyms CMA and CLPL. I am biased against having acronyms that are not used elsewhere in the document. Here is my result: NEW TEXT ======== Section 11.5.X Home Link Detection When an MN detects that it has arrived on a new link using the movement detection algorithm in use (Section 11.5.1x) it performs the following steps to determine if it is on the home link. {{{ #!html
  • The MN performs the procedure described in Section 11.5.2x and configures an address. It also keeps track of all the on-link prefix(es) received in the RA along with their prefix lengths.
}}} {{{ #!html
  • If the home prefix has not been statically configured the MN uses some form of bootstrapping procedure (e.g. RFC5026) to determine the home prefix.
}}} {{{ #!html
  • Given the availability of the home prefix, the MN checks whether or not the home prefix matches one of the prefixes received in the RA. If it does, the MN concludes that it has returned home.
}}} ================================================ It is also a bit tricky to determine where to locate this new section. The current organization of section 11.5 is as follows: {{{ 11.5. Movement . . . . . . . . . . . . . . . . . . . . . 123 11.5.1. Movement Detection . . . . . . . . . . . . . . 123 11.5.2. Forming New Care-of Addresses . . . . . . . . . 125 11.5.3. Using Multiple Care-of Addresses . . . . . . . 126 11.5.4. Returning Home . . . . . . . . . . . . . . . . 127 }}} After reading through the text, I think the new subsection would fit best after the current 11.5.1, making it a new subsection 11.5.2. ----------------------------------------+----------------------------------- Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: major | Milestone: Component: draft-ietf-mext-rfc3775bis | Version: Severity: Active WG Document | Keywords: Home Link Detection ----------------------------------------+----------------------------------- -- Ticket URL: mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 11:00:55 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2719628C272; Fri, 11 Jul 2008 11:00:55 -0700 (PDT) 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 1CEEC28C267 for ; Fri, 11 Jul 2008 11:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKwc7wjmLStF for ; Fri, 11 Jul 2008 11:00:52 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id E3E0228C272 for ; Fri, 11 Jul 2008 11:00:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,346,1212364800"; d="scan'208,217";a="51958007" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 11 Jul 2008 18:01:10 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m6BI1AMF015085; Fri, 11 Jul 2008 11:01:10 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6BI1AW5011089; Fri, 11 Jul 2008 18:01:10 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jul 2008 11:01:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 11 Jul 2008 10:57:21 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [MEXT] [mext] #11: De-registration when returning home[VijayDevarapalli ] Thread-Index: Acjh8V+MjNkSZIeVRpqs1hq3iTkwfwBgC3SQAAMZZiAAAGeZAg== References: <010801c8e16b$5c2889d0$7471510a@psl.local> <7892795E1A87F04CADFCCF41FADD00FC05F1D85F@xmb-ams-337.emea.cisco.com> From: "Sri Gundavelli (sgundave)" To: "Vijay Devarapalli" , "Pascal Thubert (pthubert)" , "Koodli, Rajeev" X-OriginalArrivalTime: 11 Jul 2008 18:01:09.0855 (UTC) FILETIME=[193916F0:01C8E380] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=14788; t=1215799270; x=1216663270; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=20(sgundave)=22=20 |Subject:=20RE=3A=20=20RE=3A=20[MEXT]=20[mext]=20#11=3A=20D e-registration=20when=20returning=20home[VijayDevarapalli=20 ] |Sender:=20; bh=3wvqcKuKdfC/qBD28NqRWm/SMv+gbNRR1OpPu6iK5oI=; b=hOfxfpzKiJUCOAHRvcQUaa+a19zeMRfUt2jElsxcxVmiCrcNSy9TrmTRLL P3wUsaOnKLoSMPbZD1hX/nK+XJcrQir+pftKfzgvtLhEMgrKLYGgZjlV9MjL 4fEnEPzlsr; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home[VijayDevarapalli ] 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="===============0508703502==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============0508703502== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8E380.1904396C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8E380.1904396C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Vijay, =20 But the below text makes the assumption that the MN will not be able to = reclaim the address and that has the implication on the new issue to be discussed. The root of this = issue, was the change from SHOULD to MUST on requiring the MN to send a BU. Lets resolve the issue = with clearly stating the requirement from MIP perspective, "if the MN wants to use HoA on the = home-link, it MUST send the dereg message". The other text implying that the MN will not able to use = the HoA on its home link is not required and this issue is not about that. =20 Thanks Sri =20 ________________________________ From: Vijay Devarapalli [mailto:vijay@wichorus.com] Sent: Fri 7/11/2008 10:52 AM To: Pascal Thubert (pthubert); Sri Gundavelli (sgundave); Koodli, Rajeev Cc: charliep@computer.org; mext@ietf.org Subject: RE: [MEXT] [mext] #11: De-registration when returning = home[VijayDevarapalli ] Sri, Pascal, Rajeev, I suggest you guys open a separate issue on whether a mobile node can claim its address without first sending a de-registration BU when it returns to the home link. RFC 3775 does not allow this. It is clearly a violation of RFC 3775. An RFC 3775-compliant mobile node is supposed to behave as described in RFC 3775 when it returns home. Not according to what RFC 4861 might allow an IPv6 host to do. For the issue we were discussing, lets go with the following text. A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.1), when the mobile node detects that its home subnet prefix is again on-link. To be able to send and receive packets using its home address from the home link, the mobile node MUST send a Binding Update to its home agent to instruct its home agent to no longer intercept or tunnel packets for it. Until the mobile node sends a de-registration Binding Update, it will not be able to send and receive packets using its home address from the home link. The home agent will continue to intercept all packets sent to the mobile's home address and tunnel to the previously registered care-of address. We need to close this issue. Based on what we decide later on whether the mobile node can claim its address without first sending a de-registration BU, we can revisit the above text. Vijay > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Pascal Thubert (pthubert) > Sent: Friday, July 11, 2008 9:40 AM > To: Sri Gundavelli (sgundave) > Cc: charliep@computer.org; mext@ietf.org > Subject: Re: [MEXT] [mext] #11: De-registration when > returning home[VijayDevarapalli ] > > Hi Sri, > > I won't reply to all your mails but I'm 100 % with you all the way > through. > > In particular, you're very right that it would just be > nonsense for a HA > to try and reclaim SeND based addresses when a MN proves ownership on > link. We need to prepare for the coming changes and adapt the spec. In > short the HA is a proxy and it should behave as such. > > RFC3775bis might live in its bubble and expect that all MN will act > proper. But there are a number of scenarios, including reboot > with loss > of state, where the MN might not. And the real attacks against the MN > home address might not come from nodes that behave proper, whether > that's voluntary or not. > > When the MN comes back home and does not have the right states to > unbind, > > - if the MN is a good citizen, it should DAD its address and the HA > should defend it. I'm asking that upon DAD, the HA do not set the > Override bit; that change to the spec would allow the MN to > differentiate a real collision from a proxy collision. I > would call that > a proxy-success for the DAD flow. > > - but to avoid trouble when coming home, I'd expect that > implementations > that do not wish to get angry customer calls in the middle of > the night > would send RA (Override) right away. I know, that's bad. But > that's damn > quick and efficent. That's how we do hot standby... > > What happens next? > > - A node should get its address back if only proxies are > defending it. > In MIP case, whether the MN can clean up the binding properly or fails > for some reason, it should NA(override) its address. At least that > should be rightful if DAD proxy-succeeds. > > - Upon NA override, a proxy should yield silently. > The HA should remove its binding. This flow would also > enables a HA that > gets a new BU to take over the binding from the old HA. > > Proxy or not proxy? That is the question... > > Pascal > > >-----Original Message----- > >From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] > On Behalf Of > Sri Gundavelli (sgundave) > >Sent: mercredi 9 juillet 2008 20:26 > >To: Giaretta, Gerardo > >Cc: charliep@computer.org; mext@ietf.org > >Subject: Re: [MEXT] [mext] #11: De-registration when returning home > [VijayDevarapalli > >] > > > > > >Just one comment. > > > > > >> Until the mobile node sends a de-registration Binding > Update, it will > >> not > >> be able to send and receive packets using its home address from the > home > >> link. > > > >I have a problem with this. As Pascal and Rajiv pointed out, nothing > >really stops the MN, which is the legitimate address owner to reclaim > >and start using its home address on the home link and without sending > >a BU with life=3D0. This has to confirm to the override flag purpose = in > >ND. > > > >Sri > > > >_______________________________________________ > >MEXT mailing list > >MEXT@ietf.org > >https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > ------_=_NextPart_001_01C8E380.1904396C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [MEXT] [mext] #11: De-registration when = returning home[VijayDevarapalli <vijay@wichorus.com>]=0A= =0A= =0A= =0A=
=0A=
Vijay,
=0A=
 
=0A=
But the below text makes the = assumption that the MN will not be able to reclaim the address and = that
=0A=
has the implication on the = new issue to be discussed. The root of this issue, was the change = from
=0A=
SHOULD to MUST on requiring = the MN to send a BU. Lets resolve the issue with clearly stating = the
=0A=
requirement from MIP = perspective, "if the MN wants to use HoA on the home-link, it MUST send = the
=0A=
dereg message". The = other text implying that the MN will not able to use the HoA on its home = link is
=0A=
not required and this issue = is not about that.
=0A=
 
=0A=
Thanks
=0A=
Sri
=0A=
 
=0A=

=0A=
=0A= From: Vijay Devarapalli = [mailto:vijay@wichorus.com]
Sent: Fri 7/11/2008 10:52 = AM
To: Pascal Thubert (pthubert); Sri Gundavelli (sgundave); = Koodli, Rajeev
Cc: charliep@computer.org; = mext@ietf.org
Subject: RE: [MEXT] [mext] #11: De-registration = when returning home[VijayDevarapalli = <vijay@wichorus.com>]

=0A=
=0A=

Sri, Pascal, Rajeev,

I suggest you guys open a = separate issue on whether a mobile node can
claim its address without = first sending a de-registration BU when it
returns to the home = link.

RFC 3775 does not allow this. It is clearly a violation of = RFC 3775. An
RFC 3775-compliant mobile node is supposed to behave as = described in RFC
3775 when it returns home. Not according to what RFC = 4861 might allow an
IPv6 host to do.

For the issue we were = discussing, lets go with the following text.

   A = mobile node detects that it has returned to its home link = through
   the movement detection algorithm in use (Section = 11.5.1), when the
   mobile node detects that its home = subnet prefix is again on-link.
   To be able to send and = receive packets using its home address from
   the home = link, the mobile node MUST send a Binding Update to its
   = home agent to instruct its home agent to no longer intercept = or
   tunnel packets for it. Until the mobile node sends a = de-registration
   Binding Update, it will not be able to = send and receive packets
   using its home address from the = home link. The home agent will
   continue to intercept all = packets sent to the mobile's home address
   and tunnel to = the previously registered care-of address.

We need to close this = issue.

Based on what we decide later on whether the mobile node = can claim its
address without first sending a de-registration BU, we = can revisit the
above text.

Vijay


> = -----Original Message-----
> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] = On
> Behalf Of Pascal Thubert (pthubert)
> Sent: Friday, = July 11, 2008 9:40 AM
> To: Sri Gundavelli (sgundave)
> Cc: = charliep@computer.org; mext@ietf.org
> Subject: Re: [MEXT] [mext] = #11: De-registration when
> returning home[VijayDevarapalli = <vijay@wichorus.com>]
>
> Hi Sri,
>
> I = won't reply to all your mails but I'm 100 % with you all the way
> = through.
>
> In particular, you're very right that it would = just be
> nonsense for a HA
> to try and reclaim SeND based = addresses when a MN proves ownership on
> link. We need to prepare = for the coming changes and adapt the spec. In
> short the HA is a = proxy and it should behave as such.
>
> RFC3775bis might = live in its bubble and expect that all MN will act
> proper. But = there are a number of scenarios, including reboot
> with = loss
> of state, where the MN might not. And the real attacks = against the MN
> home address might not come from nodes that = behave proper, whether
> that's voluntary or not.
>
> = When the MN comes back home and does not have the right states = to
> unbind,
>
> - if the MN is a good citizen, it = should DAD its address and the HA
> should defend it. I'm asking = that upon DAD, the HA do not set the
> Override bit; that change = to the spec would allow the MN to
> differentiate a real collision = from a proxy collision. I
> would call that
> a = proxy-success for the DAD flow.
>
> - but to avoid trouble = when coming home, I'd expect that
> implementations
> that = do not wish to get angry customer calls in the middle of
> the = night
> would send RA (Override) right away. I know, that's bad. = But
> that's damn
> quick and efficent. That's how we do hot = standby...
>
> What happens next?
>
> - A node = should get its address back if only proxies are
> defending = it.
> In MIP case, whether the MN can clean up the binding = properly or fails
> for some reason, it should NA(override) its = address. At least that
> should be rightful if DAD = proxy-succeeds.
>
> - Upon NA override, a proxy should yield = silently.
> The HA should remove its binding. This flow would = also
> enables a HA that
> gets a new BU to take over the = binding from the old HA.
>
> Proxy or not proxy? That is the = question...
>
> Pascal
>
> >-----Original = Message-----
> >From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org]> On Behalf Of
> Sri Gundavelli (sgundave)
> >Sent: = mercredi 9 juillet 2008 20:26
> >To: Giaretta, Gerardo
> = >Cc: charliep@computer.org; mext@ietf.org
> >Subject: Re: = [MEXT] [mext] #11: De-registration when returning home
> = [VijayDevarapalli
> ><vijay@wichorus.com>]
> = >
> >
> >Just one comment.
> >
> = >
> >> Until the mobile node sends a de-registration = Binding
> Update, it will
> >> not
> >> be = able to send and receive packets using its home address from the
> = home
> >> link.
> >
> >I have a problem = with this. As Pascal and Rajiv pointed out, nothing
> >really = stops the MN, which is the legitimate address owner to reclaim
> = >and start using its home address on the home link and without = sending
> >a BU with life=3D0. This has to confirm to the = override flag purpose in
> >ND.
> >
> = >Sri
> >
> = >_______________________________________________
> >MEXT = mailing list
> >MEXT@ietf.org
> >https://www.ietf.org/= mailman/listinfo/mext
> = _______________________________________________
> MEXT mailing = list
> MEXT@ietf.org
> https://www.ietf.org/= mailman/listinfo/mext
>

------_=_NextPart_001_01C8E380.1904396C-- --===============0508703502== 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 --===============0508703502==-- From mext-bounces@ietf.org Fri Jul 11 11:07:44 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C9D33A68E4; Fri, 11 Jul 2008 11:07:44 -0700 (PDT) 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 C6CFD28C1F0 for ; Fri, 11 Jul 2008 11:07:43 -0700 (PDT) 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 iYNCTr3BCXQT for ; Fri, 11 Jul 2008 11:07:42 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 813533A68E4 for ; Fri, 11 Jul 2008 11:07:42 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 11 Jul 2008 14:07:57 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [MEXT] [mext] #11: De-registration when returning home[VijayDevarapalli ] Thread-Index: Acjh8V+MjNkSZIeVRpqs1hq3iTkwfwBgC3SQAAMZZiAAAGeZAgAAS1OA References: <010801c8e16b$5c2889d0$7471510a@psl.local> <7892795E1A87F04CADFCCF41FADD00FC05F1D85F@xmb-ams-337.emea.cisco.com> From: "Vijay Devarapalli" To: "Sri Gundavelli (sgundave)" , "Pascal Thubert (pthubert)" , "Koodli, Rajeev" Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home[VijayDevarapalli ] 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, > But the below text makes the assumption that the MN will not > be able to reclaim the address and that > has the implication on the new issue to be discussed. The > root of this issue, was the change from > SHOULD to MUST on requiring the MN to send a BU. The change from 'SHOULD' to 'MUST' is irrelevant. RFC 3775 already says that the mobile node sends a neighbor advertisement *only after* receiving the Binding Ack from the home agent. Whether we use 'SHOULD' or 'MUST' for the de-registration BU, the fact is that the mobile node still cannot send a neighbor advertisement before receiving the binding ack. Vijay Lets resolve > the issue with clearly stating the > requirement from MIP perspective, "if the MN wants to use HoA > on the home-link, it MUST send the > dereg message". The other text implying that the MN will not > able to use the HoA on its home link is > not required and this issue is not about that. > > Thanks > Sri > > > ________________________________ > > From: Vijay Devarapalli [mailto:vijay@wichorus.com] > Sent: Fri 7/11/2008 10:52 AM > To: Pascal Thubert (pthubert); Sri Gundavelli (sgundave); > Koodli, Rajeev > Cc: charliep@computer.org; mext@ietf.org > Subject: RE: [MEXT] [mext] #11: De-registration when > returning home[VijayDevarapalli ] > > > > Sri, Pascal, Rajeev, > > I suggest you guys open a separate issue on whether a mobile node can > claim its address without first sending a de-registration BU when it > returns to the home link. > > RFC 3775 does not allow this. It is clearly a violation of > RFC 3775. An > RFC 3775-compliant mobile node is supposed to behave as > described in RFC > 3775 when it returns home. Not according to what RFC 4861 > might allow an > IPv6 host to do. > > For the issue we were discussing, lets go with the following text. > > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > To be able to send and receive packets using its home address from > the home link, the mobile node MUST send a Binding Update to its > home agent to instruct its home agent to no longer intercept or > tunnel packets for it. Until the mobile node sends a > de-registration > Binding Update, it will not be able to send and receive packets > using its home address from the home link. The home agent will > continue to intercept all packets sent to the mobile's home address > and tunnel to the previously registered care-of address. > > We need to close this issue. > > Based on what we decide later on whether the mobile node can claim its > address without first sending a de-registration BU, we can revisit the > above text. > > Vijay > > > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > Behalf Of Pascal Thubert (pthubert) > > Sent: Friday, July 11, 2008 9:40 AM > > To: Sri Gundavelli (sgundave) > > Cc: charliep@computer.org; mext@ietf.org > > Subject: Re: [MEXT] [mext] #11: De-registration when > > returning home[VijayDevarapalli ] > > > > Hi Sri, > > > > I won't reply to all your mails but I'm 100 % with you all the way > > through. > > > > In particular, you're very right that it would just be > > nonsense for a HA > > to try and reclaim SeND based addresses when a MN proves > ownership on > > link. We need to prepare for the coming changes and adapt > the spec. In > > short the HA is a proxy and it should behave as such. > > > > RFC3775bis might live in its bubble and expect that all MN will act > > proper. But there are a number of scenarios, including reboot > > with loss > > of state, where the MN might not. And the real attacks > against the MN > > home address might not come from nodes that behave proper, whether > > that's voluntary or not. > > > > When the MN comes back home and does not have the right states to > > unbind, > > > > - if the MN is a good citizen, it should DAD its address and the HA > > should defend it. I'm asking that upon DAD, the HA do not set the > > Override bit; that change to the spec would allow the MN to > > differentiate a real collision from a proxy collision. I > > would call that > > a proxy-success for the DAD flow. > > > > - but to avoid trouble when coming home, I'd expect that > > implementations > > that do not wish to get angry customer calls in the middle of > > the night > > would send RA (Override) right away. I know, that's bad. But > > that's damn > > quick and efficent. That's how we do hot standby... > > > > What happens next? > > > > - A node should get its address back if only proxies are > > defending it. > > In MIP case, whether the MN can clean up the binding > properly or fails > > for some reason, it should NA(override) its address. At least that > > should be rightful if DAD proxy-succeeds. > > > > - Upon NA override, a proxy should yield silently. > > The HA should remove its binding. This flow would also > > enables a HA that > > gets a new BU to take over the binding from the old HA. > > > > Proxy or not proxy? That is the question... > > > > Pascal > > > > >-----Original Message----- > > >From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] > > On Behalf Of > > Sri Gundavelli (sgundave) > > >Sent: mercredi 9 juillet 2008 20:26 > > >To: Giaretta, Gerardo > > >Cc: charliep@computer.org; mext@ietf.org > > >Subject: Re: [MEXT] [mext] #11: De-registration when returning home > > [VijayDevarapalli > > >] > > > > > > > > >Just one comment. > > > > > > > > >> Until the mobile node sends a de-registration Binding > > Update, it will > > >> not > > >> be able to send and receive packets using its home > address from the > > home > > >> link. > > > > > >I have a problem with this. As Pascal and Rajiv pointed > out, nothing > > >really stops the MN, which is the legitimate address owner > to reclaim > > >and start using its home address on the home link and > without sending > > >a BU with life=0. This has to confirm to the override flag > purpose in > > >ND. > > > > > >Sri > > > > > >_______________________________________________ > > >MEXT mailing list > > >MEXT@ietf.org > > >https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 11:09:22 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91EC228C28B; Fri, 11 Jul 2008 11:09:22 -0700 (PDT) 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 17FEA28C27F for ; Fri, 11 Jul 2008 11:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.864 X-Spam-Level: X-Spam-Status: No, score=-5.864 tagged_above=-999 required=5 tests=[AWL=-0.662, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEufCwLNX07l for ; Fri, 11 Jul 2008 11:09:19 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id AC50228C27E for ; Fri, 11 Jul 2008 11:09:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,346,1212364800"; d="scan'208,217";a="64878147" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 11 Jul 2008 18:09:37 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6BI9b8B017296; Fri, 11 Jul 2008 11:09:37 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m6BI9arX017580; Fri, 11 Jul 2008 18:09:36 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jul 2008 11:09:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 11 Jul 2008 11:08:54 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [MEXT] [mext] #11: De-registration when returning home[VijayDevarapalli ] Thread-Index: Acjh8V+MjNkSZIeVRpqs1hq3iTkwfwBgC3SQAAMZZiAAAGeZAgAAS1OAAAAb8ho= References: <010801c8e16b$5c2889d0$7471510a@psl.local> <7892795E1A87F04CADFCCF41FADD00FC05F1D85F@xmb-ams-337.emea.cisco.com> From: "Sri Gundavelli (sgundave)" To: "Vijay Devarapalli" , "Pascal Thubert (pthubert)" , "Koodli, Rajeev" X-OriginalArrivalTime: 11 Jul 2008 18:09:36.0764 (UTC) FILETIME=[475D43C0:01C8E381] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=17641; t=1215799777; x=1216663777; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=20(sgundave)=22=20 |Subject:=20RE=3A=20RE=3A=20[MEXT]=20[mext]=20#11=3A=20De-r egistration=20when=20returning=20home[VijayDevarapalli=20] |Sender:=20; bh=5sK2kbuXarW7hNi5o6dt48TBNGTnW82fVR883erd8nU=; b=LxqfnkhPmdRhu8zGtZXZWHImrOVQcY25YCEJDHLc032D3rPZR6kYOZ7WYI WZk/j5sATMRKFWfnrmnjPxvlbJHs7Kxl6HdO5u88nzt+8scImAnlFhcKbWaF z1zREiP3kAjuYiIN7jPYrQv6GuvLMVPOD8OJRPEXumM7EPRSOF02A=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home[VijayDevarapalli ] 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="===============1503562126==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============1503562126== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8E381.472EBA74" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8E381.472EBA74 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable HI Vijay, =20 How are the two issues different then ? This issue and the new issue = that you suggested we open. =20 Sri ________________________________ From: Vijay Devarapalli [mailto:vijay@wichorus.com] Sent: Fri 7/11/2008 11:07 AM To: Sri Gundavelli (sgundave); Pascal Thubert (pthubert); Koodli, Rajeev Cc: charliep@computer.org; mext@ietf.org Subject: RE: RE: [MEXT] [mext] #11: De-registration when returning = home[VijayDevarapalli ] Hi Sri, > But the below text makes the assumption that the MN will not > be able to reclaim the address and that > has the implication on the new issue to be discussed. The > root of this issue, was the change from > SHOULD to MUST on requiring the MN to send a BU. The change from 'SHOULD' to 'MUST' is irrelevant. RFC 3775 already says that the mobile node sends a neighbor advertisement *only after* receiving the Binding Ack from the home agent. Whether we use 'SHOULD' or 'MUST' for the de-registration BU, the fact is that the mobile node still cannot send a neighbor advertisement before receiving the binding ack. Vijay Lets resolve > the issue with clearly stating the > requirement from MIP perspective, "if the MN wants to use HoA > on the home-link, it MUST send the > dereg message". The other text implying that the MN will not > able to use the HoA on its home link is > not required and this issue is not about that. >=20 > Thanks > Sri >=20 > > ________________________________ > > From: Vijay Devarapalli [mailto:vijay@wichorus.com] > Sent: Fri 7/11/2008 10:52 AM > To: Pascal Thubert (pthubert); Sri Gundavelli (sgundave); > Koodli, Rajeev > Cc: charliep@computer.org; mext@ietf.org > Subject: RE: [MEXT] [mext] #11: De-registration when > returning home[VijayDevarapalli ] > > > > Sri, Pascal, Rajeev, > > I suggest you guys open a separate issue on whether a mobile node can > claim its address without first sending a de-registration BU when it > returns to the home link. > > RFC 3775 does not allow this. It is clearly a violation of > RFC 3775. An > RFC 3775-compliant mobile node is supposed to behave as > described in RFC > 3775 when it returns home. Not according to what RFC 4861 > might allow an > IPv6 host to do. > > For the issue we were discussing, lets go with the following text. > > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > To be able to send and receive packets using its home address from > the home link, the mobile node MUST send a Binding Update to its > home agent to instruct its home agent to no longer intercept or > tunnel packets for it. Until the mobile node sends a > de-registration > Binding Update, it will not be able to send and receive packets > using its home address from the home link. The home agent will > continue to intercept all packets sent to the mobile's home address > and tunnel to the previously registered care-of address. > > We need to close this issue. > > Based on what we decide later on whether the mobile node can claim its > address without first sending a de-registration BU, we can revisit the > above text. > > Vijay > > > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > Behalf Of Pascal Thubert (pthubert) > > Sent: Friday, July 11, 2008 9:40 AM > > To: Sri Gundavelli (sgundave) > > Cc: charliep@computer.org; mext@ietf.org > > Subject: Re: [MEXT] [mext] #11: De-registration when > > returning home[VijayDevarapalli ] > > > > Hi Sri, > > > > I won't reply to all your mails but I'm 100 % with you all the way > > through. > > > > In particular, you're very right that it would just be > > nonsense for a HA > > to try and reclaim SeND based addresses when a MN proves > ownership on > > link. We need to prepare for the coming changes and adapt > the spec. In > > short the HA is a proxy and it should behave as such. > > > > RFC3775bis might live in its bubble and expect that all MN will act > > proper. But there are a number of scenarios, including reboot > > with loss > > of state, where the MN might not. And the real attacks > against the MN > > home address might not come from nodes that behave proper, whether > > that's voluntary or not. > > > > When the MN comes back home and does not have the right states to > > unbind, > > > > - if the MN is a good citizen, it should DAD its address and the HA > > should defend it. I'm asking that upon DAD, the HA do not set the > > Override bit; that change to the spec would allow the MN to > > differentiate a real collision from a proxy collision. I > > would call that > > a proxy-success for the DAD flow. > > > > - but to avoid trouble when coming home, I'd expect that > > implementations > > that do not wish to get angry customer calls in the middle of > > the night > > would send RA (Override) right away. I know, that's bad. But > > that's damn > > quick and efficent. That's how we do hot standby... > > > > What happens next? > > > > - A node should get its address back if only proxies are > > defending it. > > In MIP case, whether the MN can clean up the binding > properly or fails > > for some reason, it should NA(override) its address. At least that > > should be rightful if DAD proxy-succeeds. > > > > - Upon NA override, a proxy should yield silently. > > The HA should remove its binding. This flow would also > > enables a HA that > > gets a new BU to take over the binding from the old HA. > > > > Proxy or not proxy? That is the question... > > > > Pascal > > > > >-----Original Message----- > > >From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] > > On Behalf Of > > Sri Gundavelli (sgundave) > > >Sent: mercredi 9 juillet 2008 20:26 > > >To: Giaretta, Gerardo > > >Cc: charliep@computer.org; mext@ietf.org > > >Subject: Re: [MEXT] [mext] #11: De-registration when returning home > > [VijayDevarapalli > > >] > > > > > > > > >Just one comment. > > > > > > > > >> Until the mobile node sends a de-registration Binding > > Update, it will > > >> not > > >> be able to send and receive packets using its home > address from the > > home > > >> link. > > > > > >I have a problem with this. As Pascal and Rajiv pointed > out, nothing > > >really stops the MN, which is the legitimate address owner > to reclaim > > >and start using its home address on the home link and > without sending > > >a BU with life=3D0. This has to confirm to the override flag > purpose in > > >ND. > > > > > >Sri > > > > > >_______________________________________________ > > >MEXT mailing list > > >MEXT@ietf.org > > >https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > > > ------_=_NextPart_001_01C8E381.472EBA74 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: RE: [MEXT] [mext] #11: De-registration = when returning home[VijayDevarapalli <vijay@wichorus.com>]=0A= =0A= =0A= =0A=
=0A=
HI = Vijay,
=0A=
 
=0A=
How are the two issues = different then ? This issue and the new issue that you suggested we = open.
=0A=
 
=0A=
Sri
=0A=

=0A=
=0A= From: Vijay Devarapalli = [mailto:vijay@wichorus.com]
Sent: Fri 7/11/2008 11:07 = AM
To: Sri Gundavelli (sgundave); Pascal Thubert (pthubert); = Koodli, Rajeev
Cc: charliep@computer.org; = mext@ietf.org
Subject: RE: RE: [MEXT] [mext] #11: = De-registration when returning home[VijayDevarapalli = <vijay@wichorus.com>]

=0A=
=0A=

Hi Sri,

> But the below text makes the = assumption that the MN will not
> be able to reclaim the address = and that
> has the implication on the new issue to be discussed. = The
> root of this issue, was the change from
> SHOULD to = MUST on requiring the MN to send a BU.

The change from 'SHOULD' = to 'MUST' is irrelevant. RFC 3775 already says
that the mobile node = sends a neighbor advertisement *only after*
receiving the Binding Ack = from the home agent. Whether we use 'SHOULD'
or 'MUST' for the = de-registration BU, the fact is that the mobile node
still cannot = send a neighbor advertisement before receiving the = binding
ack.

Vijay


Lets resolve
> the issue = with clearly stating the
> requirement from MIP perspective, "if = the MN wants to use HoA
> on the home-link, it MUST send = the
> dereg message". The other text implying that the MN will = not
> able to use the HoA on its home link is
> not required = and this issue is not about that.
> 
> Thanks
> = Sri
> 
>
> = ________________________________
>
> From: Vijay Devarapalli = [mailto:vijay@wichorus.com]
>= Sent: Fri 7/11/2008 10:52 AM
> To: Pascal Thubert (pthubert); Sri = Gundavelli (sgundave);
> Koodli, Rajeev
> Cc: = charliep@computer.org; mext@ietf.org
> Subject: RE: [MEXT] [mext] = #11: De-registration when
> returning home[VijayDevarapalli = <vijay@wichorus.com>]
>
>
>
> Sri, Pascal, = Rajeev,
>
> I suggest you guys open a separate issue on = whether a mobile node can
> claim its address without first = sending a de-registration BU when it
> returns to the home = link.
>
> RFC 3775 does not allow this. It is clearly a = violation of
> RFC 3775. An
> RFC 3775-compliant mobile node = is supposed to behave as
> described in RFC
> 3775 when it = returns home. Not according to what RFC 4861
> might allow = an
> IPv6 host to do.
>
> For the issue we were = discussing, lets go with the following = text.
>
>    A mobile node detects that it = has returned to its home link through
>    the = movement detection algorithm in use (Section 11.5.1), when = the
>    mobile node detects that its home subnet = prefix is again on-link.
>    To be able to send = and receive packets using its home address = from
>    the home link, the mobile node MUST send = a Binding Update to its
>    home agent to instruct = its home agent to no longer intercept or
>    = tunnel packets for it. Until the mobile node sends a
> = de-registration
>    Binding Update, it will not be = able to send and receive packets
>    using its = home address from the home link. The home agent = will
>    continue to intercept all packets sent to = the mobile's home address
>    and tunnel to the = previously registered care-of address.
>
> We need to close = this issue.
>
> Based on what we decide later on whether the = mobile node can claim its
> address without first sending a = de-registration BU, we can revisit the
> above = text.
>
> Vijay
>
>
> > -----Original = Message-----
> > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] = On
> > Behalf Of Pascal Thubert (pthubert)
> > Sent: = Friday, July 11, 2008 9:40 AM
> > To: Sri Gundavelli = (sgundave)
> > Cc: charliep@computer.org; mext@ietf.org
> = > Subject: Re: [MEXT] [mext] #11: De-registration when
> > = returning home[VijayDevarapalli <vijay@wichorus.com>]
> = >
> > Hi Sri,
> >
> > I won't reply to all = your mails but I'm 100 % with you all the way
> > = through.
> >
> > In particular, you're very right that = it would just be
> > nonsense for a HA
> > to try and = reclaim SeND based addresses when a MN proves
> ownership = on
> > link. We need to prepare for the coming changes and = adapt
> the spec. In
> > short the HA is a proxy and it = should behave as such.
> >
> > RFC3775bis might live = in its bubble and expect that all MN will act
> > proper. But = there are a number of scenarios, including reboot
> > with = loss
> > of state, where the MN might not. And the real = attacks
> against the MN
> > home address might not come = from nodes that behave proper, whether
> > that's voluntary or = not.
> >
> > When the MN comes back home and does not = have the right states to
> > unbind,
> >
> > = - if the MN is a good citizen, it should DAD its address and the = HA
> > should defend it. I'm asking that upon DAD, the HA do = not set the
> > Override bit; that change to the spec would = allow the MN to
> > differentiate a real collision from a proxy = collision. I
> > would call that
> > a proxy-success = for the DAD flow.
> >
> > - but to avoid trouble when = coming home, I'd expect that
> > implementations
> > = that do not wish to get angry customer calls in the middle of
> = > the night
> > would send RA (Override) right away. I know, = that's bad. But
> > that's damn
> > quick and = efficent. That's how we do hot standby...
> >
> > What = happens next?
> >
> > - A node should get its address = back if only proxies are
> > defending it.
> > In MIP = case, whether the MN can clean up the binding
> properly or = fails
> > for some reason, it should NA(override) its address. = At least that
> > should be rightful if DAD = proxy-succeeds.
> >
> > - Upon NA override, a proxy = should yield silently.
> > The HA should remove its binding. = This flow would also
> > enables a HA that
> > gets a = new BU to take over the binding from the old HA.
> >
> = > Proxy or not proxy? That is the question...
> >
> = > Pascal
> >
> > >-----Original = Message-----
> > >From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org]> > On Behalf Of
> > Sri Gundavelli (sgundave)
> = > >Sent: mercredi 9 juillet 2008 20:26
> > >To: = Giaretta, Gerardo
> > >Cc: charliep@computer.org; = mext@ietf.org
> > >Subject: Re: [MEXT] [mext] #11: = De-registration when returning home
> > = [VijayDevarapalli
> > ><vijay@wichorus.com>]
> = > >
> > >
> > >Just one comment.
> = > >
> > >
> > >> Until the mobile node = sends a de-registration Binding
> > Update, it will
> = > >> not
> > >> be able to send and receive = packets using its home
> address from the
> > = home
> > >> link.
> > >
> > >I = have a problem with this. As Pascal and Rajiv pointed
> out, = nothing
> > >really stops the MN, which is the legitimate = address owner
> to reclaim
> > >and start using its = home address on the home link and
> without sending
> > = >a BU with life=3D0. This has to confirm to the override flag
> = purpose in
> > >ND.
> > >
> > = >Sri
> > >
> > = >_______________________________________________
> > = >MEXT mailing list
> > >MEXT@ietf.org
> > >https://www.ietf.org/= mailman/listinfo/mext
> > = _______________________________________________
> > MEXT = mailing list
> > MEXT@ietf.org
> > https://www.ietf.org/= mailman/listinfo/mext
> = >
>
>
>

------_=_NextPart_001_01C8E381.472EBA74-- --===============1503562126== 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 --===============1503562126==-- From mext-bounces@ietf.org Fri Jul 11 11:12:12 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9383028C20C; Fri, 11 Jul 2008 11:12:12 -0700 (PDT) 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 DC7F628C20C for ; Fri, 11 Jul 2008 11:12:11 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KYb-1EJQQrL for ; Fri, 11 Jul 2008 11:12:10 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id A52C328C1A5 for ; Fri, 11 Jul 2008 11:12:07 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6BICMF23131; Fri, 11 Jul 2008 18:12:22 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 11 Jul 2008 13:12:20 -0500 Message-ID: In-Reply-To: <005601c8e37f$90fc3a60$5c0c7c0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-02.txt Thread-Index: Acjjf5aOyzpHU+98ROG93Fp5chwf3wAAFlZQ References: <00be01c8e361$a995d180$5c0c7c0a@china.huawei.com> <000601c8e369$530b9b80$5c0c7c0a@china.huawei.com> <001201c8e36a$746e18b0$5c0c7c0a@china.huawei.com> <003901c8e36c$02c6b850$5c0c7c0a@china.huawei.com> <000e01c8e370$3f9f83c0$5c0c7c0a@china.huawei.com> <005601c8e37f$90fc3a60$5c0c7c0a@china.huawei.com> From: "Ahmad Muhanna" To: "Frank Xia" , Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-02.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 Frank, The Binding Revocation draft does not define any new security mechanism, I am not trying to escape from answering your question. What I am saying here is that the Binding Revocation does not specify a new security mechanism. It only defines a generic Revocation mechanism that can be used by different mobility entities as captured in the draft. What else you want me to say? If you have a security mechanism that can be used for securing BU/BA exchange, it should be good enough to secure BRI/BRA. If you want me to spell out the word "RFC4285", that is fine, you should be able to use that security association too. On top of all of this, as I said earlier and based on the mext ml consensus, BRI and BRA use the MGSM framework and the security mechanism that is defined there. Regards, Ahmad > -----Original Message----- > From: Frank Xia [mailto:xiayangsong@huawei.com] > Sent: Friday, July 11, 2008 12:57 PM > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > Subject: Re: [MEXT] FW: I-D > Action:draft-muhanna-mext-binding-revocation-02.txt > > Hi Ahmad > > My question is very simple, why could you answer this directly? > > OK, I would like to reword my question. > > How to secure BRI/BRA messages when there is not IPsec SA > between HA and MN? > > BR > Frank > > ----- Original Message ----- > From: "Ahmad Muhanna" > To: "Frank Xia" ; > Sent: Friday, July 11, 2008 12:49 PM > Subject: RE: [MEXT] FW: I-D > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > Thanks Frank! > > This is becoming a very interesting discussion:-) Let me try > one more time. Please see inline. > > Regards, > Ahmad > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > Hi Ahmad > > > > Firstly, why do you only mention "If IPsec is used" ? > > Ok, since as per the consensus of the mext ml, the BRI and > BRA use the Mobile IPv6 Generic Signaling Message (MGSM) > framework, I believe what we need to do here: is to reference > that draft and only document the exceptions. > > What about the following:? > > " > The protocol described here uses the same security architecture and > requirement of the Mobile IPv6 Generic Signaling Message > framework as > defined in [ID-MGSM]. > > However, in the case when the MAG sends a BRI message with > the G bit > is set, the LMA must verify that the MAG is authorized to > use Per-Peer > Global Revocation. > " > > Therefore, there is no exception and IPsec is not treated > differently than any other security mechanisms. > > > > > Secondly, there are different security mechanism between > RFC3776/4877 > > and RFC4285. > > > As to the latter, there is not separated SA establishment and > > maitanance machanism (such as IKE), and each packet should > > authenticate itselft. > > [Ahmad] > With the proposed text above, I guess this becomes a > different discussion. We actually can take that offline. > But I am just curious, what do you mean by the following:? > > 1. there is not separated SA establishment and maitanance > machanism (such as IKE), and 2. each packet should > authenticate itselft. > > > > > IMO, your original text is only about IPsec case, and your > later text > > only highlights IPsec case. > > > > Could you give me an explicit answer? > > How to secure the signaling between HA and MN if there is no IPsec? > > [Ahmad] > I hope that this has been addressed, please see above. > > > > > Please don't ask me because I am not the author of draft. > > Of course, I am willing to answer the question if you add me as an > > co-author > > :-) > > > > BR > > Frank > > > > ----- Original Message ----- > > From: "Ahmad Muhanna" > > To: "Frank Xia" ; > > Sent: Friday, July 11, 2008 10:46 AM > > Subject: RE: [MEXT] FW: I-D > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > Hi Frank, > > > > The following text captures all different mechanisms that > are used or > > can be used to establish a security association between the > MN and the > > HA or the MAG and the LMA. > > > > "The protocol described here uses the same security association > > between the MN and the HA or the MAG and the LMA that > has been used > > to exchange the corresponding MIPv6 or Proxy MIPv6 BU > and BA when > > the > > session was established." > > > > I personally believe that it captures and cover all cases including > > the case you mentioned. > > > > > > Regards, > > Ahmad > > > > > > > -----Original Message----- > > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > > Sent: Friday, July 11, 2008 10:37 AM > > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > > Subject: Re: [MEXT] FW: I-D > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > Hi Ahmad > > > > > > Please add more information about "If IPsec is not used > ...", IMO, > > > it is not necessary limited to "If IPsec is used". > > > > > > BR > > > Frank > > > > > > ----- Original Message ----- > > > From: "Ahmad Muhanna" > > > To: "Frank Xia" ; > > > Sent: Friday, July 11, 2008 10:32 AM > > > Subject: RE: [MEXT] FW: I-D > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > > > Thanks Frank for pointing that, I believe the text should > > have been as > > > follows: > > > > > > "The protocol described here uses the same security association > > > between the MN and the HA or the MAG and the LMA that > > has been used > > > to exchange the corresponding MIPv6 or Proxy MIPv6 BU > and BA when > > > the > > > session was established. If IPsec is used, the SPD of > this IPsec > > > SA > > > MUST allow the MH type for the MGSM." > > > > > > We will fix it and if there is other nits like this will, we will > > > take care of it. Does that address your concern? > > > > > > Basically, the Binding Revocation messages should use the same > > > security association that was used during the > establishment of the > > > session that being revoked. > > > > > > Regards, > > > Ahmad > > > > > > > > > > -----Original Message----- > > > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > > > Sent: Friday, July 11, 2008 10:26 AM > > > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > > > Subject: Re: [MEXT] FW: I-D > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > Hi Ahmad > > > > > > > > I copy the security consideration from you draft. > > > > > > > > It says "The protocol described here uses the same security > > > > association > > > > between the MN and the HA or the MAG and the LMA that > > > has been used > > > > to exchange the corresponding MIPv6 or Proxy MIPv6 BU > > > and BA when > > > > the > > > > session was established. This SPD of this IPsec SA MUST > > > allow the > > > > MH > > > > type for the MGSM." > > > > > > > > How to secure signalling if there is no IPsec? > > > > > > > > I can't find the answer. > > > > > > > > BR > > > > Frank > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Ahmad Muhanna" > > > > To: "Frank Xia" ; > > > > Sent: Friday, July 11, 2008 10:20 AM > > > > Subject: RE: [MEXT] FW: I-D > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > > > Hi Frank, > > > > > > > > I guess you need to answer that question. Right? > > > > I assume that what you mentioned about 3GPP2 and WiMAX is > > accurate. > > > > i.e., > > > > "by WiMAX and 3GPP2 in which IPsec SA is not mandatory." > > > > > > > > Regards, > > > > Ahmad > > > > > > > > > > > > > -----Original Message----- > > > > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > > > > Sent: Friday, July 11, 2008 10:18 AM > > > > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > > > > Subject: Re: [MEXT] FW: I-D > > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > Hi Ahmad > > > > > > > > > > How to secure the signaling between HA and MN if there is > > > no IPsec? > > > > > > > > > > BR > > > > > Frank > > > > > > > > > > ----- Original Message ----- > > > > > From: "Ahmad Muhanna" > > > > > To: "Frank Xia" ; > > > > > Sent: Friday, July 11, 2008 10:12 AM > > > > > Subject: RE: [MEXT] FW: I-D > > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > > > > > > Hi Frank, > > > > > > > > > > I do not think there is a conflict here. > > > > > > > > > > In the case of WiMAX and 3GPP2, I assume that there will be > > > > no IPsec > > > > > SA between the HA and the MN, for example. > > > > > Therefore, there will be no SPD to worry about. Although > > > > the BRI/BRA > > > > > uses the MGSM which has a MH type that support IPsec > > (if IPsec is > > > > > used), but that is not applicable to the case you mentioned > > > > then there > > > > > is no problem. > > > > > > > > > > Does that make sense? > > > > > > > > > > Regards, > > > > > Ahmad > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > > > > > Sent: Friday, July 11, 2008 9:23 AM > > > > > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > > > > > Subject: Re: [MEXT] FW: I-D > > > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > > > Hi Ahmad > > > > > > > > > > > > IMHO, this document can't be directly used by WiMAX and > > > > > 3GPP2 in which > > > > > > IPsec SA is not mandatory. > > > > > > > > > > > > 3GPP2/WiMAX adopted RFC4285, and corresponding > > > documents, such as > > > > > > Diameter, RADIUS, now are explicitely supporting RFC4285. > > > > > > > > > > > > We discussed before. > > > > > > > > > > > > BR > > > > > > Frank > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Ahmad Muhanna" > > > > > > To: > > > > > > Sent: Friday, July 11, 2008 8:53 AM > > > > > > Subject: [MEXT] FW: I-D > > > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > > > > > > > > > > > > > > > Hello Folks, > > > > > > > > > > > > We updated the Binding Revocation draft according to the > > > > mext wg ml > > > > > > consensus by using the Mobile IPv6 Generic Signaling > > > > Message (MGSM) > > > > > > framework. Since the MGSM draft is still being revised, we > > > > > referenced > > > > > > the MGSM draft in all related sections of the Binding > > > Revocation > > > > > > draft. > > > > > > We probably will be able to optimize the draft a little > > > > > more in order > > > > > > to eliminate any duplication in some sections as soon as > > > > > the new MGSM > > > > > > draft revision becomes available. > > > > > > > > > > > > The only other change introduced in this revision > is that we > > > > > > referenced the DSMIP6 draft and made it optional for the HA > > > > > to include > > > > > > the IPv4 home address in the BRI. > > > > > > > > > > > > With the aggressive schedule and 3GPP dependency on this > > > > draft, we > > > > > > appreciate your review, comment, and feedback. > > > > > > > > > > > > Thanks in advance! > > > > > > > > > > > > Regards, > > > > > > Ahmad > > > > > > > > > > > > -----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, July 11, 2008 8:45 AM > > > > > > To: i-d-announce@ietf.org > > > > > > Subject: I-D > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > > Internet-Drafts > > > > > > directories. > > > > > > > > > > > > Title : Binding Revocation for IPv6 Mobility > > > > > > Author(s) : A. Muhanna, et al. > > > > > > Filename : > draft-muhanna-mext-binding-revocation-02.txt > > > > > > Pages : 32 > > > > > > Date : 2008-07-11 > > > > > > > > > > > > This document defines the revocation semantics for > > > terminating a > > > > > > mobile node's mobility session and associated > > resources. These > > > > > > semantics are generic enough and can be used by mobility > > > > > entities in > > > > > > the case of Client Mobile IPv6 and its extensions. This > > > > mechanism > > > > > > allows the mobility entity which initiates the revocation > > > > > procedure to > > > > > > request its corresponding one to terminate either one, > > > > > multiple or all > > > > > > specified binding cache entries. > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > > > http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding > > > > > -revocatio > > > > > > n-02.txt > > > > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > > > > Below is the data which will enable a MIME compliant > > > mail reader > > > > > > implementation to automatically retrieve the ASCII > > > version of the > > > > > > Internet-Draft. > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > > ------------------ > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > MEXT mailing list > > > > > > > MEXT@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 11:18:05 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 259BF28C26A; Fri, 11 Jul 2008 11:18:05 -0700 (PDT) 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 284F328C26D for ; Fri, 11 Jul 2008 11:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzR3jZBrZetW for ; Fri, 11 Jul 2008 11:18:03 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 1DAA028C267 for ; Fri, 11 Jul 2008 11:18:03 -0700 (PDT) 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 m6BIIJ2m018857; Fri, 11 Jul 2008 13:18:20 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jul 2008 13:18:19 -0500 Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jul 2008 13:18:19 -0500 Message-ID: <4877A473.6050109@ericsson.com> Date: Fri, 11 Jul 2008 14:20:35 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: "Charles E. Perkins" References: <486B8EDD.4070807@ericsson.com> <4876501E.4060908@earthlink.net> In-Reply-To: <4876501E.4060908@earthlink.net> X-OriginalArrivalTime: 11 Jul 2008 18:18:19.0575 (UTC) FILETIME=[7EFBE470:01C8E382] Cc: mext@ietf.org Subject: Re: [MEXT] New Text for home link detection in RFC3775bis 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Charlie, Your suggested text sounds good. If you are looking for a new name for these sections may I suggest "Attachment to a new link" :-) Cheers Suresh Charles E. Perkins wrote: > > Hello Suresh, > > I'm creating a new issue for "home link detection" to > go into the issue tracker. Your suggested text seems > to have found consensus for resolving the issue, as > long as it is located in a new section (as suggested in > later messages). However, I would like to suggest a > textual revision and simplification. Most of the revision > relies on pointing out that one has to get a home network > prefix before using it to compare against the list of > prefixes received in the RA. The other revision, which > I hope is O.K., is to dispense with creating the new > acronyms CMA and CLPL. I am biased against having > acronyms that are not used elsewhere in the document. > > Here is my result: > > NEW TEXT > ======== > > Section 11.5.X Home Link Detection > > When an MN detects that it has arrived on a new link using the > movement detection algorithm in use (Section 11.5.1x) it performs the > following steps to determine if it is on the home link. > > o The MN performs the procedure described in Section 11.5.2x and > configures an address. It also keeps track of all the on-link > prefix(es) > received in the RA along with their prefix lengths. > > o If the home prefix has not been statically configured the MN uses > some form of bootstrapping procedure (e.g. RFC5026) to determine > the home prefix. > > o Given the availability of the home prefix, the MN checks whether or > not the home prefix matches one of the prefixes received in the RA. > If it does, the MN concludes that it has returned home. > > ================================================ > > It is also a bit tricky to determine where to locate this new section. > The current organization of section 11.5 is as follows: > > 11.5. Movement . . . . . . . . . . . . . . . . . . . . . . . . 123 > 11.5.1. Movement Detection . . . . . . . . . . . . . . . . . 123 > 11.5.2. Forming New Care-of Addresses . . . . . . . . . . . . 125 > 11.5.3. Using Multiple Care-of Addresses . . . . . . . . . . 126 > 11.5.4. Returning Home . . . . . . . . . . . . . . . . . . . 127 > > After reading through the text, I think the new subsection would > fit best after the current 11.5.1, making it a new subsection 11.5.2. > > ================================================ > > By the way, given the new subsection, the first sentence of the > _current_ subsection 11.5.2 (to become subsection 11.5.3) needs > to be changed: > > OLD: > After detecting that it has moved a mobile node SHOULD generate a new > primary care-of address using normal IPv6 mechanisms. > > NEW: > After detecting that it has moved to a link away from home, a mobile node > SHOULD generate a new primary care-of address using normal IPv6 > mechanisms. > > ================================================= > > Strictly speaking, the names of section 11.5{,.1} are probably wrong. > Perhaps they should be something more like "New Link{s, Detection}". > This is because a node can require establishment of a new link > without any movement. For instance, as we all know, sometimes > wireless access points become unreachable even if we are standing > still, and then we have to search for another access point in range. > > I haven't decided yet whether to actually go ahead and rename the > sections. Comments are welcome! > > Regards, > Charlie P. > > > > > > > > > Suresh Krishnan wrote: >> The WG had consensus to fold in text from draft-krishnan-mext-hld into >> RFC3775bis. Here is the proposed text for doing so. Feel free to edit. >> >> >> >> This change is made in Section 11.5.4 >> >> OLD TEXT >> ======== >> A mobile node detects that it has returned to its home link through >> the movement detection algorithm in use (Section 11.5.1), when the >> mobile node detects that its home subnet prefix is again on-link. >> >> NEW TEXT >> ======== >> When an MN detects that it has arrived on a new link using the >> movement detection algorithm in use (Section 11.5.1) it performs the >> following steps to determine if it is on the home link. >> >> o The MN performs the procedure described in Section 11.5.2 and >> configures an address referred to as the Current MN Address (CMA). >> It also stores all the on-link prefix(es) received in the RA along >> with their prefix lengths in a conceptual list called the Current >> Link Prefix List (CLPL). >> >> o If the home prefix has been statically pre-configured on the MN >> it checks if the home prefix matches one of the prefixes in the >> CLPL. If it does, the MN concludes that it has returned home. >> >> o If the home prefix has not been statically configured the MN uses >> some form of bootstrapping procedure (e.g. RFC5026) to determine >> the home prefix. It then checks if the home prefix matches one of >> the prefixes in the CLPL. If it does, the MN concludes that it has >> returned home. >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 11:20:47 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B896C3A695E; Fri, 11 Jul 2008 11:20:47 -0700 (PDT) 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 564E53A695E for ; Fri, 11 Jul 2008 11:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 gKTBad87UwKx for ; Fri, 11 Jul 2008 11:20:46 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 473D83A685C for ; Fri, 11 Jul 2008 11:20:45 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id D839FC8030 for ; Fri, 11 Jul 2008 14:20:59 -0400 (EDT) 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 11197-05 for ; Fri, 11 Jul 2008 14:20:58 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Fri, 11 Jul 2008 14:20:58 -0400 (EDT) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jul 2008 14:19:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 11 Jul 2008 14:20:50 -0400 Message-ID: <4D35478224365146822AE9E3AD4A266603281174@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [MEXT] [mext] #11: De-registration when returning home[VijayDevarapalli ] Thread-Index: Acjh8V+MjNkSZIeVRpqs1hq3iTkwfwBgC3SQAAMZZiAAAQ0P0A== From: "Koodli, Rajeev" To: "Vijay Devarapalli" , "Pascal Thubert (pthubert)" , "Sri Gundavelli (sgundave)" X-OriginalArrivalTime: 11 Jul 2008 18:19:01.0630 (UTC) FILETIME=[980CF9E0:01C8E382] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home[VijayDevarapalli ] 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, > > I suggest you guys open a separate issue on whether a mobile node can > claim its address without first sending a de-registration BU when it > returns to the home link. [RKo:>] I assume you mean sending an Unsolicited NA prior to sending Dereg-BU. > > RFC 3775 does not allow this. It is clearly a violation of RFC 3775. An > RFC 3775-compliant mobile node is supposed to behave as described in RFC > 3775 when it returns home. Not according to what RFC 4861 might allow an > IPv6 host to do. > [RKo:>] Well, "violation of RFC 3775" is interesting, since anything we might do (e.g., changing a SHOULD to MUST) can also be interpreted as "violation". More to the point below. > For the issue we were discussing, lets go with the following text. > > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > To be able to send and receive packets using its home address from > the home link, the mobile node MUST send a Binding Update to its > home agent to instruct its home agent to no longer intercept or > tunnel packets for it. Until the mobile node sends a de-registration > Binding Update, it will not be able to send and receive packets > using its home address from the home link. The home agent will > continue to intercept all packets sent to the mobile's home address > and tunnel to the previously registered care-of address. > [RKo:>] I still did not hear what goes wrong if the MN sends packets using HoA as source IP address. If something does go wrong, we need to fix it. If not, I don't see why we need the above statement ".. it will not be able to send and receive packets .." Otherwise, the text is okay with me. -Rajeev > We need to close this issue. > > Based on what we decide later on whether the mobile node can claim its > address without first sending a de-registration BU, we can revisit the > above text. > > Vijay > > > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > Behalf Of Pascal Thubert (pthubert) > > Sent: Friday, July 11, 2008 9:40 AM > > To: Sri Gundavelli (sgundave) > > Cc: charliep@computer.org; mext@ietf.org > > Subject: Re: [MEXT] [mext] #11: De-registration when > > returning home[VijayDevarapalli ] > > > > Hi Sri, > > > > I won't reply to all your mails but I'm 100 % with you all the way > > through. > > > > In particular, you're very right that it would just be > > nonsense for a HA > > to try and reclaim SeND based addresses when a MN proves ownership on > > link. We need to prepare for the coming changes and adapt the spec. In > > short the HA is a proxy and it should behave as such. > > > > RFC3775bis might live in its bubble and expect that all MN will act > > proper. But there are a number of scenarios, including reboot > > with loss > > of state, where the MN might not. And the real attacks against the MN > > home address might not come from nodes that behave proper, whether > > that's voluntary or not. > > > > When the MN comes back home and does not have the right states to > > unbind, > > > > - if the MN is a good citizen, it should DAD its address and the HA > > should defend it. I'm asking that upon DAD, the HA do not set the > > Override bit; that change to the spec would allow the MN to > > differentiate a real collision from a proxy collision. I > > would call that > > a proxy-success for the DAD flow. > > > > - but to avoid trouble when coming home, I'd expect that > > implementations > > that do not wish to get angry customer calls in the middle of > > the night > > would send RA (Override) right away. I know, that's bad. But > > that's damn > > quick and efficent. That's how we do hot standby... > > > > What happens next? > > > > - A node should get its address back if only proxies are > > defending it. > > In MIP case, whether the MN can clean up the binding properly or fails > > for some reason, it should NA(override) its address. At least that > > should be rightful if DAD proxy-succeeds. > > > > - Upon NA override, a proxy should yield silently. > > The HA should remove its binding. This flow would also > > enables a HA that > > gets a new BU to take over the binding from the old HA. > > > > Proxy or not proxy? That is the question... > > > > Pascal > > > > >-----Original Message----- > > >From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] > > On Behalf Of > > Sri Gundavelli (sgundave) > > >Sent: mercredi 9 juillet 2008 20:26 > > >To: Giaretta, Gerardo > > >Cc: charliep@computer.org; mext@ietf.org > > >Subject: Re: [MEXT] [mext] #11: De-registration when returning home > > [VijayDevarapalli > > >] > > > > > > > > >Just one comment. > > > > > > > > >> Until the mobile node sends a de-registration Binding > > Update, it will > > >> not > > >> be able to send and receive packets using its home address from the > > home > > >> link. > > > > > >I have a problem with this. As Pascal and Rajiv pointed out, nothing > > >really stops the MN, which is the legitimate address owner to reclaim > > >and start using its home address on the home link and without sending > > >a BU with life=0. This has to confirm to the override flag purpose in > > >ND. > > > > > >Sri > > > > > >_______________________________________________ > > >MEXT mailing list > > >MEXT@ietf.org > > >https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 11:40:03 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05E5B28C229; Fri, 11 Jul 2008 11:40:03 -0700 (PDT) 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 5597B28C20B for ; Fri, 11 Jul 2008 11:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.831 X-Spam-Level: X-Spam-Status: No, score=-5.831 tagged_above=-999 required=5 tests=[AWL=-0.629, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dZ3u743AZty for ; Fri, 11 Jul 2008 11:39:58 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 05B7E28C229 for ; Fri, 11 Jul 2008 11:39:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,346,1212364800"; d="scan'208,217";a="86722612" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 11 Jul 2008 18:40:16 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m6BIeG53021528; Fri, 11 Jul 2008 11:40:16 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6BIeGID023396; Fri, 11 Jul 2008 18:40:16 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jul 2008 11:40:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 11 Jul 2008 11:35:42 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] FW: I-DAction:draft-muhanna-mext-binding-revocation-02.txt Thread-Index: Acjjf5aOyzpHU+98ROG93Fp5chwf3wAAFlZQAAE/MeM= References: <00be01c8e361$a995d180$5c0c7c0a@china.huawei.com><000601c8e369$530b9b80$5c0c7c0a@china.huawei.com><001201c8e36a$746e18b0$5c0c7c0a@china.huawei.com><003901c8e36c$02c6b850$5c0c7c0a@china.huawei.com><000e01c8e370$3f9f83c0$5c0c7c0a@china.huawei.com><005601c8e37f$90fc3a60$5c0c7c0a@china.huawei.com> From: "Sri Gundavelli (sgundave)" To: "Ahmad Muhanna" , "Frank Xia" , X-OriginalArrivalTime: 11 Jul 2008 18:40:16.0201 (UTC) FILETIME=[8FC11390:01C8E385] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=39326; t=1215801616; x=1216665616; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=20(sgundave)=22=20 |Subject:=20RE=3A=20[MEXT]=20FW=3A=20I-DAction=3Adraft-muha nna-mext-binding-revocation-02.txt |Sender:=20; bh=NurtiXRtxzF3xO09sfdb+umEsDdQOdIN1ofU0IcC1rw=; b=JdwFY9pGq3I7tYHDanyeuFtiAiSJL+2zNQbhxPfGscPp42WaqdWcnn91d2 caWNHw2gg+f2OnfD16JTCU0Qtx1CYdzJZrnhWc4EYeAiOjS5UEqbYZThObN6 mZrJ2Y+BEJ; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [MEXT] FW: I-DAction:draft-muhanna-mext-binding-revocation-02.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="===============0933798457==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============0933798457== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8E385.8F8CF1CC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8E385.8F8CF1CC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Frank, =20 This drafts focus is on the revocation semantics. Your comments on = transport or security has to be on the generic notification draft. Brian updated the = draft and any comments on that will help and can be fixed there.=20 =20 If you have specific comments on the revocation mechanism, on those = details, it can be fixed in this draft. How the message is delivered or the = transport semantics are all provided by the other other draft. This is another notification = message. We can discuss 4285 applicability on that draft as well. =20 =20 Thanks Sri ________________________________ From: mext-bounces@ietf.org on behalf of Ahmad Muhanna Sent: Fri 7/11/2008 11:12 AM To: Frank Xia; mext@ietf.org Subject: Re: [MEXT] FW: = I-DAction:draft-muhanna-mext-binding-revocation-02.txt Hi Frank, The Binding Revocation draft does not define any new security mechanism, I am not trying to escape from answering your question. What I am saying here is that the Binding Revocation does not specify a new security mechanism. It only defines a generic Revocation mechanism that can be used by different mobility entities as captured in the draft. What else you want me to say? If you have a security mechanism that can be used for securing BU/BA exchange, it should be good enough to secure BRI/BRA. If you want me to spell out the word "RFC4285", that is fine, you should be able to use that security association too. On top of all of this, as I said earlier and based on the mext ml consensus, BRI and BRA use the MGSM framework and the security mechanism that is defined there. Regards, Ahmad > -----Original Message----- > From: Frank Xia [mailto:xiayangsong@huawei.com] > Sent: Friday, July 11, 2008 12:57 PM > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > Subject: Re: [MEXT] FW: I-D > Action:draft-muhanna-mext-binding-revocation-02.txt > > Hi Ahmad > > My question is very simple, why could you answer this directly? > > OK, I would like to reword my question. > > How to secure BRI/BRA messages when there is not IPsec SA > between HA and MN? > > BR > Frank > > ----- Original Message ----- > From: "Ahmad Muhanna" > To: "Frank Xia" ; > Sent: Friday, July 11, 2008 12:49 PM > Subject: RE: [MEXT] FW: I-D > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > Thanks Frank! > > This is becoming a very interesting discussion:-) Let me try > one more time. Please see inline. > > Regards, > Ahmad > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > Hi Ahmad > > > > Firstly, why do you only mention "If IPsec is used" ? > > Ok, since as per the consensus of the mext ml, the BRI and > BRA use the Mobile IPv6 Generic Signaling Message (MGSM) > framework, I believe what we need to do here: is to reference > that draft and only document the exceptions. > > What about the following:? > > " > The protocol described here uses the same security architecture and > requirement of the Mobile IPv6 Generic Signaling Message > framework as > defined in [ID-MGSM]. > > However, in the case when the MAG sends a BRI message with > the G bit > is set, the LMA must verify that the MAG is authorized to > use Per-Peer > Global Revocation. > " > > Therefore, there is no exception and IPsec is not treated > differently than any other security mechanisms. > > > > > Secondly, there are different security mechanism between > RFC3776/4877 > > and RFC4285. > > > As to the latter, there is not separated SA establishment and > > maitanance machanism (such as IKE), and each packet should > > authenticate itselft. > > [Ahmad] > With the proposed text above, I guess this becomes a > different discussion. We actually can take that offline. > But I am just curious, what do you mean by the following:? > > 1. there is not separated SA establishment and maitanance > machanism (such as IKE), and 2. each packet should > authenticate itselft. > > > > > IMO, your original text is only about IPsec case, and your > later text > > only highlights IPsec case. > > > > Could you give me an explicit answer? > > How to secure the signaling between HA and MN if there is no IPsec? > > [Ahmad] > I hope that this has been addressed, please see above. > > > > > Please don't ask me because I am not the author of draft. > > Of course, I am willing to answer the question if you add me as an > > co-author > > :-) > > > > BR > > Frank > > > > ----- Original Message ----- > > From: "Ahmad Muhanna" > > To: "Frank Xia" ; > > Sent: Friday, July 11, 2008 10:46 AM > > Subject: RE: [MEXT] FW: I-D > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > Hi Frank, > > > > The following text captures all different mechanisms that > are used or > > can be used to establish a security association between the > MN and the > > HA or the MAG and the LMA. > > > > "The protocol described here uses the same security association > > between the MN and the HA or the MAG and the LMA that > has been used > > to exchange the corresponding MIPv6 or Proxy MIPv6 BU > and BA when > > the > > session was established." > > > > I personally believe that it captures and cover all cases including > > the case you mentioned. > > > > > > Regards, > > Ahmad > > > > > > > -----Original Message----- > > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > > Sent: Friday, July 11, 2008 10:37 AM > > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > > Subject: Re: [MEXT] FW: I-D > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > Hi Ahmad > > > > > > Please add more information about "If IPsec is not used > ...", IMO, > > > it is not necessary limited to "If IPsec is used". > > > > > > BR > > > Frank > > > > > > ----- Original Message ----- > > > From: "Ahmad Muhanna" > > > To: "Frank Xia" ; > > > Sent: Friday, July 11, 2008 10:32 AM > > > Subject: RE: [MEXT] FW: I-D > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > > > Thanks Frank for pointing that, I believe the text should > > have been as > > > follows: > > > > > > "The protocol described here uses the same security association > > > between the MN and the HA or the MAG and the LMA that > > has been used > > > to exchange the corresponding MIPv6 or Proxy MIPv6 BU > and BA when > > > the > > > session was established. If IPsec is used, the SPD of > this IPsec > > > SA > > > MUST allow the MH type for the MGSM." > > > > > > We will fix it and if there is other nits like this will, we will > > > take care of it. Does that address your concern? > > > > > > Basically, the Binding Revocation messages should use the same > > > security association that was used during the > establishment of the > > > session that being revoked. > > > > > > Regards, > > > Ahmad > > > > > > > > > > -----Original Message----- > > > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > > > Sent: Friday, July 11, 2008 10:26 AM > > > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > > > Subject: Re: [MEXT] FW: I-D > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > Hi Ahmad > > > > > > > > I copy the security consideration from you draft. > > > > > > > > It says "The protocol described here uses the same security > > > > association > > > > between the MN and the HA or the MAG and the LMA that > > > has been used > > > > to exchange the corresponding MIPv6 or Proxy MIPv6 BU > > > and BA when > > > > the > > > > session was established. This SPD of this IPsec SA MUST > > > allow the > > > > MH > > > > type for the MGSM." > > > > > > > > How to secure signalling if there is no IPsec? > > > > > > > > I can't find the answer. > > > > > > > > BR > > > > Frank > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Ahmad Muhanna" > > > > To: "Frank Xia" ; > > > > Sent: Friday, July 11, 2008 10:20 AM > > > > Subject: RE: [MEXT] FW: I-D > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > > > Hi Frank, > > > > > > > > I guess you need to answer that question. Right? > > > > I assume that what you mentioned about 3GPP2 and WiMAX is > > accurate. > > > > i.e., > > > > "by WiMAX and 3GPP2 in which IPsec SA is not mandatory." > > > > > > > > Regards, > > > > Ahmad > > > > > > > > > > > > > -----Original Message----- > > > > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > > > > Sent: Friday, July 11, 2008 10:18 AM > > > > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > > > > Subject: Re: [MEXT] FW: I-D > > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > Hi Ahmad > > > > > > > > > > How to secure the signaling between HA and MN if there is > > > no IPsec? > > > > > > > > > > BR > > > > > Frank > > > > > > > > > > ----- Original Message ----- > > > > > From: "Ahmad Muhanna" > > > > > To: "Frank Xia" ; > > > > > Sent: Friday, July 11, 2008 10:12 AM > > > > > Subject: RE: [MEXT] FW: I-D > > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > > > > > > Hi Frank, > > > > > > > > > > I do not think there is a conflict here. > > > > > > > > > > In the case of WiMAX and 3GPP2, I assume that there will be > > > > no IPsec > > > > > SA between the HA and the MN, for example. > > > > > Therefore, there will be no SPD to worry about. Although > > > > the BRI/BRA > > > > > uses the MGSM which has a MH type that support IPsec > > (if IPsec is > > > > > used), but that is not applicable to the case you mentioned > > > > then there > > > > > is no problem. > > > > > > > > > > Does that make sense? > > > > > > > > > > Regards, > > > > > Ahmad > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > > > > > Sent: Friday, July 11, 2008 9:23 AM > > > > > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > > > > > Subject: Re: [MEXT] FW: I-D > > > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > > > Hi Ahmad > > > > > > > > > > > > IMHO, this document can't be directly used by WiMAX and > > > > > 3GPP2 in which > > > > > > IPsec SA is not mandatory. > > > > > > > > > > > > 3GPP2/WiMAX adopted RFC4285, and corresponding > > > documents, such as > > > > > > Diameter, RADIUS, now are explicitely supporting RFC4285. > > > > > > > > > > > > We discussed before. > > > > > > > > > > > > BR > > > > > > Frank > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Ahmad Muhanna" > > > > > > To: > > > > > > Sent: Friday, July 11, 2008 8:53 AM > > > > > > Subject: [MEXT] FW: I-D > > > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > > > > > > > > > > > > > > > Hello Folks, > > > > > > > > > > > > We updated the Binding Revocation draft according to the > > > > mext wg ml > > > > > > consensus by using the Mobile IPv6 Generic Signaling > > > > Message (MGSM) > > > > > > framework. Since the MGSM draft is still being revised, we > > > > > referenced > > > > > > the MGSM draft in all related sections of the Binding > > > Revocation > > > > > > draft. > > > > > > We probably will be able to optimize the draft a little > > > > > more in order > > > > > > to eliminate any duplication in some sections as soon as > > > > > the new MGSM > > > > > > draft revision becomes available. > > > > > > > > > > > > The only other change introduced in this revision > is that we > > > > > > referenced the DSMIP6 draft and made it optional for the HA > > > > > to include > > > > > > the IPv4 home address in the BRI. > > > > > > > > > > > > With the aggressive schedule and 3GPP dependency on this > > > > draft, we > > > > > > appreciate your review, comment, and feedback. > > > > > > > > > > > > Thanks in advance! > > > > > > > > > > > > Regards, > > > > > > Ahmad > > > > > > > > > > > > -----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, July 11, 2008 8:45 AM > > > > > > To: i-d-announce@ietf.org > > > > > > Subject: I-D > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > > Internet-Drafts > > > > > > directories. > > > > > > > > > > > > Title : Binding Revocation for IPv6 Mobility > > > > > > Author(s) : A. Muhanna, et al. > > > > > > Filename : > draft-muhanna-mext-binding-revocation-02.txt > > > > > > Pages : 32 > > > > > > Date : 2008-07-11 > > > > > > > > > > > > This document defines the revocation semantics for > > > terminating a > > > > > > mobile node's mobility session and associated > > resources. These > > > > > > semantics are generic enough and can be used by mobility > > > > > entities in > > > > > > the case of Client Mobile IPv6 and its extensions. This > > > > mechanism > > > > > > allows the mobility entity which initiates the revocation > > > > > procedure to > > > > > > request its corresponding one to terminate either one, > > > > > multiple or all > > > > > > specified binding cache entries. > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > > > http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding > > > > > -revocatio > > > > > > n-02.txt > > > > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > > > > Below is the data which will enable a MIME compliant > > > mail reader > > > > > > implementation to automatically retrieve the ASCII > > > version of the > > > > > > Internet-Draft. > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > > ------------------ > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > MEXT mailing list > > > > > > > MEXT@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext ------_=_NextPart_001_01C8E385.8F8CF1CC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [MEXT] FW: = I-DAction:draft-muhanna-mext-binding-revocation-02.txt=0A= =0A= =0A= =0A=
=0A=
Frank,
=0A=
 
=0A=
This drafts focus is on the = revocation semantics. Your comments on transport or
=0A=
security has to be on the = generic notification draft. Brian updated the draft and = any
=0A=
comments on that will help = and can be fixed there.
=0A=
 
=0A=
If you have specific comments = on the revocation mechanism, on those details,
=0A=
it can be fixed in this = draft. How the message is delivered or the transport = semantics
=0A=
are all provided by the other = other draft. This is another notification message. We can
=0A=
discuss 4285 applicability on = that draft as well.  =
=0A=
 
=0A=
Thanks
=0A=
Sri
=0A=

=0A=
=0A= From: mext-bounces@ietf.org on = behalf of Ahmad Muhanna
Sent: Fri 7/11/2008 11:12 = AM
To: Frank Xia; mext@ietf.org
Subject: Re: [MEXT] = FW: = I-DAction:draft-muhanna-mext-binding-revocation-02.txt

=0A=
=0A=

Hi Frank,

The Binding Revocation draft does not = define any new security mechanism,

I am not trying to escape from = answering your question. What I am saying
here is that the Binding = Revocation does not specify a new security
mechanism. It only defines = a generic Revocation mechanism that can be
used by different mobility = entities as captured in the draft.

What else you want me to = say?

If you have a security mechanism that can be used for = securing BU/BA
exchange, it should be good enough to secure BRI/BRA. = If you want me to
spell out the word "RFC4285", that is fine, you = should be able to use
that security association too. On top of all of = this, as I said earlier
and based on the mext ml consensus, BRI and = BRA use the MGSM framework
and the security mechanism that is defined = there.


Regards,
Ahmad


> -----Original = Message-----
> From: Frank Xia [mailto:xiayangsong@huawei.com]=
> Sent: Friday, July 11, 2008 12:57 PM
> To: Muhanna, Ahmad = (RICH1:2H10); mext@ietf.org
> Subject: Re: [MEXT] FW: I-D
> = Action:draft-muhanna-mext-binding-revocation-02.txt
>
> Hi = Ahmad
>
> My question is very simple, why could you answer = this directly?
>
> OK, I would like to reword my = question.
>
> How to secure BRI/BRA messages when there is = not IPsec SA
> between HA and MN?
>
> BR
> = Frank
>
> ----- Original Message -----
> From: "Ahmad = Muhanna" <amuhanna@nortel.com>
> To: "Frank Xia" = <xiayangsong@huawei.com>; <mext@ietf.org>
> Sent: = Friday, July 11, 2008 12:49 PM
> Subject: RE: [MEXT] FW: = I-D
> = Action:draft-muhanna-mext-binding-revocation-02.txt
>
>
&g= t;
> Thanks Frank!
>
> This is becoming a very = interesting discussion:-) Let me try
> one more time. Please see = inline.
>
> Regards,
> Ahmad
>
>
> = > Action:draft-muhanna-mext-binding-revocation-02.txt
> = >
> > Hi Ahmad
> >
> > Firstly, why do you = only mention "If IPsec is used" ?
>
> Ok, since as per the = consensus of the mext ml, the BRI and
> BRA use the Mobile IPv6 = Generic Signaling Message (MGSM)
> framework, I believe what we = need to do here: is to reference
> that draft and only document = the exceptions.
>
> What about the = following:?
>
> "
>    The protocol = described here uses the same security architecture = and
>    requirement of the Mobile IPv6 Generic = Signaling Message
> framework as
>    defined = in [ID-MGSM].
>
>    However, in the case = when the MAG sends a BRI message with
> the G = bit
>    is set, the LMA must verify that the MAG = is authorized to
> use Per-Peer
>    Global = Revocation.
> "
>
> Therefore, there is no exception = and IPsec is not treated
> differently than any other security = mechanisms.
>
> >
> > Secondly, there are = different security mechanism between
> RFC3776/4877
> > = and RFC4285.
>
> > As to the latter, there is not = separated SA establishment and
> > maitanance machanism (such = as IKE), and each packet should
> > authenticate = itselft.
>
> [Ahmad]
> With the proposed text above, I = guess this becomes a
> different discussion. We actually can take = that offline.
> But I am just curious, what do you mean by the = following:?
>
> 1. there is not separated SA establishment = and maitanance
> machanism (such as IKE), and 2. each packet = should
> authenticate itselft.
>
> >
> > = IMO, your original text is only about IPsec case,  and your
> = later text
> > only highlights IPsec case.
> >
> = > Could you give me an explicit answer?
> > How to secure = the signaling between HA and MN if there is no IPsec?
>
> = [Ahmad]
> I hope that this has been addressed, please see = above.
>
> >
> > Please don't ask me because I = am not the author of draft.
> > Of course, I am willing to = answer the question if you add me as an
> > co-author
> = > :-)
> >
> > BR
> > Frank
> = >
> > ----- Original Message -----
> > From: "Ahmad = Muhanna" <amuhanna@nortel.com>
> > To: "Frank Xia" = <xiayangsong@huawei.com>; <mext@ietf.org>
> > Sent: = Friday, July 11, 2008 10:46 AM
> > Subject: RE: [MEXT] FW: = I-D
> > = Action:draft-muhanna-mext-binding-revocation-02.txt
> >
> = >
> > Hi Frank,
> >
> > The following text = captures all different mechanisms that
> are used or
> > = can be used to establish a security association between the
> MN = and the
> > HA or the MAG and the LMA.
> >
> = >   "The protocol described here uses the same security = association
> >    between the MN and the HA or = the MAG and the LMA that
> has been used
> = >    to exchange the corresponding MIPv6 or Proxy = MIPv6 BU
> and BA when
> > the
> = >    session was established."
> >
> = > I personally believe that it captures and cover all cases = including
> > the case you mentioned.
> >
> = >
> > Regards,
> > Ahmad
> >
> = >
> > > -----Original Message-----
> > > = From: Frank Xia [mailto:xiayangsong@huawei.com]=
> > > Sent: Friday, July 11, 2008 10:37 AM
> > = > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org
> > > = Subject: Re: [MEXT] FW: I-D
> > > = Action:draft-muhanna-mext-binding-revocation-02.txt
> > = >
> > > Hi Ahmad
> > >
> > > = Please add more information about "If IPsec is not used
> ...", = IMO,
> > > it is not necessary limited to "If IPsec is = used".
> > >
> > > BR
> > > = Frank
> > >
> > > ----- Original Message = -----
> > > From: "Ahmad Muhanna" = <amuhanna@nortel.com>
> > > To: "Frank Xia" = <xiayangsong@huawei.com>; <mext@ietf.org>
> > > = Sent: Friday, July 11, 2008 10:32 AM
> > > Subject: RE: = [MEXT] FW: I-D
> > > = Action:draft-muhanna-mext-binding-revocation-02.txt
> > = >
> > >
> > >
> > > Thanks Frank = for pointing that, I believe the text should
> > have been = as
> > > follows:
> > >
> > = >   "The protocol described here uses the same security = association
> > >    between the MN and the = HA or the MAG and the LMA that
> > has been used
> > = >    to exchange the corresponding MIPv6 or Proxy = MIPv6 BU
> and BA when
> > > the
> > = >    session was established.  If IPsec is used, = the SPD of
> this IPsec
> > > SA
> > = >    MUST allow the MH type for the MGSM."
> = > >
> > > We will fix it and if there is other nits = like this will, we will
> > > take care of it. Does that = address your concern?
> > >
> > > Basically, the = Binding Revocation messages should use the same
> > > = security association that was used during the
> establishment of = the
> > > session that being revoked.
> > = >
> > > Regards,
> > > Ahmad
> > = >
> > >
> > > > -----Original = Message-----
> > > > From: Frank Xia [mailto:xiayangsong@huawei.com]=
> > > > Sent: Friday, July 11, 2008 10:26 AM
> = > > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org
> = > > > Subject: Re: [MEXT] FW: I-D
> > > > = Action:draft-muhanna-mext-binding-revocation-02.txt
> > > = >
> > > > Hi Ahmad
> > > >
> > = > > I copy the security consideration from you draft.
> > = > >
> > > > It says "The protocol described here = uses the same security
> > > > association
> > = > >    between the MN and the HA or the MAG and the = LMA that
> > > has been used
> > > = >    to exchange the corresponding MIPv6 or Proxy = MIPv6 BU
> > > and BA when
> > > > = the
> > > >    session was = established.  This SPD of this IPsec SA MUST
> > > = allow the
> > > > MH
> > > = >    type for the MGSM."
> > > = >
> > > > How to secure signalling if there is no = IPsec?
> > > >
> > > > I can't find the = answer.
> > > >
> > > > BR
> > = > > Frank
> > > >
> > > >
> = > > > ----- Original Message -----
> > > > From: = "Ahmad Muhanna" <amuhanna@nortel.com>
> > > > To: = "Frank Xia" <xiayangsong@huawei.com>; = <mext@ietf.org>
> > > > Sent: Friday, July 11, 2008 = 10:20 AM
> > > > Subject: RE: [MEXT] FW: I-D
> > = > > Action:draft-muhanna-mext-binding-revocation-02.txt
> = > > >
> > > >
> > > > Hi = Frank,
> > > >
> > > > I guess you need to = answer that question. Right?
> > > > I assume that what = you mentioned about 3GPP2 and WiMAX is
> > accurate.
> = > > > i.e.,
> > > > "by WiMAX and 3GPP2 in which = IPsec SA is not mandatory."
> > > >
> > > = > Regards,
> > > > Ahmad
> > > = >
> > > >
> > > > > -----Original = Message-----
> > > > > From: Frank Xia [mailto:xiayangsong@huawei.com]=
> > > > > Sent: Friday, July 11, 2008 10:18 = AM
> > > > > To: Muhanna, Ahmad (RICH1:2H10); = mext@ietf.org
> > > > > Subject: Re: [MEXT] FW: = I-D
> > > > > = Action:draft-muhanna-mext-binding-revocation-02.txt
> > > = > >
> > > > > Hi Ahmad
> > > > = >
> > > > > How to secure the signaling between HA = and MN if there is
> > > no IPsec?
> > > > = >
> > > > > BR
> > > > > = Frank
> > > > >
> > > > > ----- = Original Message -----
> > > > > From: "Ahmad Muhanna" = <amuhanna@nortel.com>
> > > > > To: "Frank Xia" = <xiayangsong@huawei.com>; <mext@ietf.org>
> > > = > > Sent: Friday, July 11, 2008 10:12 AM
> > > > = > Subject: RE: [MEXT] FW: I-D
> > > > > = Action:draft-muhanna-mext-binding-revocation-02.txt
> > > = > >
> > > > >
> > > > > Hi = Frank,
> > > > >
> > > > > I do not = think there is a conflict here.
> > > > >
> > = > > > In the case of WiMAX and 3GPP2, I assume that there will = be
> > > > no IPsec
> > > > > SA = between the HA and the MN, for example.
> > > > > = Therefore, there will be no SPD to worry about. Although
> > = > > the BRI/BRA
> > > > > uses the MGSM which = has a MH type that support IPsec
> > (if IPsec is
> > = > > > used), but that is not applicable to the case you = mentioned
> > > > then there
> > > > > = is no problem.
> > > > >
> > > > > = Does that make sense?
> > > > >
> > > > = > Regards,
> > > > > Ahmad
> > > > = >
> > > > >
> > > > > > = -----Original Message-----
> > > > > > From: Frank = Xia [mailto:xiayangsong@huawei.com]=
> > > > > > Sent: Friday, July 11, 2008 9:23 = AM
> > > > > > To: Muhanna, Ahmad (RICH1:2H10); = mext@ietf.org
> > > > > > Subject: Re: [MEXT] FW: = I-D
> > > > > > = Action:draft-muhanna-mext-binding-revocation-02.txt
> > > = > > >
> > > > > > Hi Ahmad
> > = > > > >
> > > > > > IMHO, this document = can't be directly used by WiMAX and
> > > > > 3GPP2 in = which
> > > > > > IPsec SA is not = mandatory.
> > > > > >
> > > > > = > 3GPP2/WiMAX adopted RFC4285, and corresponding
> > > = documents, such as
> > > > > > Diameter, RADIUS, = now are explicitely supporting RFC4285.
> > > > > = >
> > > > > > We discussed before.
> > = > > > >
> > > > > > BR
> > = > > > > Frank
> > > > > >
> > = > > > >
> > > > > > ----- Original = Message -----
> > > > > > From: "Ahmad Muhanna" = <amuhanna@nortel.com>
> > > > > > To: = <mext@ietf.org>
> > > > > > Sent: Friday, = July 11, 2008 8:53 AM
> > > > > > Subject: [MEXT] = FW: I-D
> > > > > > = Action:draft-muhanna-mext-binding-revocation-02.txt
> > > = > > >
> > > > > >
> > > > = > >
> > > > > > Hello Folks,
> > = > > > >
> > > > > > We updated the = Binding Revocation draft according to the
> > > > mext wg = ml
> > > > > > consensus by using the Mobile IPv6 = Generic Signaling
> > > > Message (MGSM)
> > = > > > > framework. Since the MGSM draft is still being = revised, we
> > > > > referenced
> > > = > > > the MGSM draft in all related sections of the = Binding
> > > Revocation
> > > > > > = draft.
> > > > > > We probably will be able to = optimize the draft a little
> > > > > more in = order
> > > > > > to eliminate any duplication in = some sections as soon as
> > > > > the new = MGSM
> > > > > > draft revision becomes = available.
> > > > > >
> > > > > = > The only other change introduced in this revision
> is that = we
> > > > > > referenced the DSMIP6 draft and made = it optional for the HA
> > > > > to include
> = > > > > > the IPv4 home address in the BRI.
> > = > > > >
> > > > > > With the aggressive = schedule and 3GPP dependency on this
> > > > draft, = we
> > > > > > appreciate your review, comment, and = feedback.
> > > > > >
> > > > > = > Thanks in advance!
> > > > > >
> > = > > > > Regards,
> > > > > > = Ahmad
> > > > > >
> > > > > > = -----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, = July 11, 2008 8:45 AM
> > > > > > To: = i-d-announce@ietf.org
> > > > > > Subject: = I-D
> > = Action:draft-muhanna-mext-binding-revocation-02.txt
> > > = > > >
> > > > > > A New Internet-Draft is = available from the on-line
> > > > = Internet-Drafts
> > > > > > directories.
> = > > > > >
> > > > > > = Title           : = Binding Revocation for IPv6 Mobility
> > > > > > = Author(s)       : A. Muhanna, et = al.
> > > > > > = Filename        :
> = draft-muhanna-mext-binding-revocation-02.txt
> > > > > = > Pages           : = 32
> > > > > > = Date            : = 2008-07-11
> > > > > >
> > > > > = > This document defines the revocation semantics for
> > = > terminating a
> > > > > > mobile node's = mobility session and associated
> > resources.  = These
> > > > > > semantics are generic enough and = can be used by mobility
> > > > > entities in
> = > > > > > the case of Client Mobile IPv6 and its = extensions.  This
> > > > mechanism
> > = > > > > allows the mobility entity which initiates the = revocation
> > > > > procedure to
> > > = > > > request its corresponding one to terminate either = one,
> > > > > multiple or all
> > > > = > > specified binding cache entries.
> > > > > = >
> > > > > > A URL for this Internet-Draft = is:
> > > > > >
> h= ttp://www.ietf.org/internet-drafts/draft-muhanna-mext-binding
>= > > > > -revocatio
> > > > > > = n-02.txt
> > > > > >
> > > > > = > Internet-Drafts are also available by anonymous FTP at:
> = > > > > > ftp://ftp.ietf.org/internet-= drafts/
> > > > > >
> > > > > = > Below is the data which will enable a MIME compliant
> > = > mail reader
> > > > > > implementation to = automatically retrieve the ASCII
> > > version of = the
> > > > > > Internet-Draft.
> > > = > > >
> > > > > >
> > > > = > >
> > > > > >
> = --------------------------------------------------------------
> = > > > > > ------------------
> > > > > = >
> > > > > >
> > > > > > = > _______________________________________________
> > > = > > > > MEXT mailing list
> > > > > > = > MEXT@ietf.org
> > > > > > > https://www.ietf.org/= mailman/listinfo/mext
> > > > > > >
> = > > > > >
> > > > > >
> > = > > > >
> > > > >
> > > > = >
> > > > >
> > > >
> > = > >
> > > >
> > >
> > = >
> > >
> >
> >
> = >
>
>
>
_________________________________________= ______
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/= mailman/listinfo/mext

------_=_NextPart_001_01C8E385.8F8CF1CC-- --===============0933798457== 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 --===============0933798457==-- From mext-bounces@ietf.org Fri Jul 11 11:59:14 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A5D528C2BF; Fri, 11 Jul 2008 11:59:14 -0700 (PDT) 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 3191328C2BF for ; Fri, 11 Jul 2008 11:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 Kauj3Rnwg7-7 for ; Fri, 11 Jul 2008 11:59:12 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 4333928C2BC for ; Fri, 11 Jul 2008 11:59:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=o7pP1WgIxHmDuzdwD6iXSdl+wl2q2Aat/nSPru/P2ZGzAPwAvwqY1DQnlXVhHwFB; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [75.26.137.116] (helo=[10.166.255.10]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1KHNq5-0004Ri-RH for mext@ietf.org; Fri, 11 Jul 2008 14:59:30 -0400 Message-ID: <4877AD8F.4050204@earthlink.net> Date: Fri, 11 Jul 2008 11:59:27 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: mext@ietf.org X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f521576468df147ccf83c93de52e9441b1b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Subject: [MEXT] Emails from when new issues are created 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello folks, The issue tracker sends out notifications to the mailing list when new tickets are created to track the issues. That's good, but the text of the message includes all of the formatting characters, and that makes it less than useful for reading through the actual text of the issue. At the bottom of the email there is a URL for the actual issue as displayed by the issue tracker, and that displayed version looks pretty good. So, for instance, to see that intended text for issue #13, take a look at: http://wiki.tools.ietf.org/wg/mext/trac/ticket/13 Also, as an aside, I am on a mission of discovery to figure out how to do a better job of formatting the text of the issue in "wiki" formatting as well as HTML formatting. I've solved several problems compared to earlier efforts, but still the indentations are wrong. Besides, the indicated texts do not exactly conform to the email messages of the authors to which the texts are ascribed. Putting everything in _verbatim_ is, I feel certain, also not the answer. So if anyone has suggestions for improvements please let me know. Regards, Charlie P. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 12:02:51 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BD0328C2EF; Fri, 11 Jul 2008 12:02:51 -0700 (PDT) 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 3953E28C2DF for ; Fri, 11 Jul 2008 12:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntMhV-moxfa1 for ; Fri, 11 Jul 2008 12:02:48 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id B711D28C2F4 for ; Fri, 11 Jul 2008 12:01:41 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K3U006COVJB4T@usaga04-in.huawei.com> for mext@ietf.org; Fri, 11 Jul 2008 14:02:00 -0500 (CDT) Received: from X24512z ([10.124.12.92]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K3U00LYWVJAQ9@usaga04-in.huawei.com> for mext@ietf.org; Fri, 11 Jul 2008 14:01:59 -0500 (CDT) Date: Fri, 11 Jul 2008 14:01:58 -0500 From: Frank Xia To: Ahmad Muhanna , mext@ietf.org Message-id: <008201c8e388$984a4240$5c0c7c0a@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: <00be01c8e361$a995d180$5c0c7c0a@china.huawei.com> <000601c8e369$530b9b80$5c0c7c0a@china.huawei.com> <001201c8e36a$746e18b0$5c0c7c0a@china.huawei.com> <003901c8e36c$02c6b850$5c0c7c0a@china.huawei.com> <000e01c8e370$3f9f83c0$5c0c7c0a@china.huawei.com> <005601c8e37f$90fc3a60$5c0c7c0a@china.huawei.com> Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-02.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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ahmad IMHO, you are trying to escape from answering my very simple question. :-) If you want to offload your security consideration to the MGSM draft, you should contact the authors of the draft, and make sure that they will deal with the issue. Here are some specific question. 1)which authentication options should be include in BRI/BRA? MN-HA or MN-AAA? 2) If authentication fails, is any new status to be defined in BRA ? 0 success. 1 partial success. 2 Binding Does NOT Exist. 3 Global Revocation NOT Authorized. 4 CAN NOT Identify Binding. BR Frank ----- Original Message ----- From: "Ahmad Muhanna" To: "Frank Xia" ; Sent: Friday, July 11, 2008 1:12 PM Subject: RE: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-02.txt Hi Frank, The Binding Revocation draft does not define any new security mechanism, I am not trying to escape from answering your question. What I am saying here is that the Binding Revocation does not specify a new security mechanism. It only defines a generic Revocation mechanism that can be used by different mobility entities as captured in the draft. What else you want me to say? If you have a security mechanism that can be used for securing BU/BA exchange, it should be good enough to secure BRI/BRA. If you want me to spell out the word "RFC4285", that is fine, you should be able to use that security association too. On top of all of this, as I said earlier and based on the mext ml consensus, BRI and BRA use the MGSM framework and the security mechanism that is defined there. Regards, Ahmad > -----Original Message----- > From: Frank Xia [mailto:xiayangsong@huawei.com] > Sent: Friday, July 11, 2008 12:57 PM > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > Subject: Re: [MEXT] FW: I-D > Action:draft-muhanna-mext-binding-revocation-02.txt > > Hi Ahmad > > My question is very simple, why could you answer this directly? > > OK, I would like to reword my question. > > How to secure BRI/BRA messages when there is not IPsec SA > between HA and MN? > > BR > Frank > > ----- Original Message ----- > From: "Ahmad Muhanna" > To: "Frank Xia" ; > Sent: Friday, July 11, 2008 12:49 PM > Subject: RE: [MEXT] FW: I-D > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > Thanks Frank! > > This is becoming a very interesting discussion:-) Let me try > one more time. Please see inline. > > Regards, > Ahmad > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > Hi Ahmad > > > > Firstly, why do you only mention "If IPsec is used" ? > > Ok, since as per the consensus of the mext ml, the BRI and > BRA use the Mobile IPv6 Generic Signaling Message (MGSM) > framework, I believe what we need to do here: is to reference > that draft and only document the exceptions. > > What about the following:? > > " > The protocol described here uses the same security architecture and > requirement of the Mobile IPv6 Generic Signaling Message > framework as > defined in [ID-MGSM]. > > However, in the case when the MAG sends a BRI message with > the G bit > is set, the LMA must verify that the MAG is authorized to > use Per-Peer > Global Revocation. > " > > Therefore, there is no exception and IPsec is not treated > differently than any other security mechanisms. > > > > > Secondly, there are different security mechanism between > RFC3776/4877 > > and RFC4285. > > > As to the latter, there is not separated SA establishment and > > maitanance machanism (such as IKE), and each packet should > > authenticate itselft. > > [Ahmad] > With the proposed text above, I guess this becomes a > different discussion. We actually can take that offline. > But I am just curious, what do you mean by the following:? > > 1. there is not separated SA establishment and maitanance > machanism (such as IKE), and 2. each packet should > authenticate itselft. > > > > > IMO, your original text is only about IPsec case, and your > later text > > only highlights IPsec case. > > > > Could you give me an explicit answer? > > How to secure the signaling between HA and MN if there is no IPsec? > > [Ahmad] > I hope that this has been addressed, please see above. > > > > > Please don't ask me because I am not the author of draft. > > Of course, I am willing to answer the question if you add me as an > > co-author > > :-) > > > > BR > > Frank > > > > ----- Original Message ----- > > From: "Ahmad Muhanna" > > To: "Frank Xia" ; > > Sent: Friday, July 11, 2008 10:46 AM > > Subject: RE: [MEXT] FW: I-D > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > Hi Frank, > > > > The following text captures all different mechanisms that > are used or > > can be used to establish a security association between the > MN and the > > HA or the MAG and the LMA. > > > > "The protocol described here uses the same security association > > between the MN and the HA or the MAG and the LMA that > has been used > > to exchange the corresponding MIPv6 or Proxy MIPv6 BU > and BA when > > the > > session was established." > > > > I personally believe that it captures and cover all cases including > > the case you mentioned. > > > > > > Regards, > > Ahmad > > > > > > > -----Original Message----- > > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > > Sent: Friday, July 11, 2008 10:37 AM > > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > > Subject: Re: [MEXT] FW: I-D > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > Hi Ahmad > > > > > > Please add more information about "If IPsec is not used > ...", IMO, > > > it is not necessary limited to "If IPsec is used". > > > > > > BR > > > Frank > > > > > > ----- Original Message ----- > > > From: "Ahmad Muhanna" > > > To: "Frank Xia" ; > > > Sent: Friday, July 11, 2008 10:32 AM > > > Subject: RE: [MEXT] FW: I-D > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > > > Thanks Frank for pointing that, I believe the text should > > have been as > > > follows: > > > > > > "The protocol described here uses the same security association > > > between the MN and the HA or the MAG and the LMA that > > has been used > > > to exchange the corresponding MIPv6 or Proxy MIPv6 BU > and BA when > > > the > > > session was established. If IPsec is used, the SPD of > this IPsec > > > SA > > > MUST allow the MH type for the MGSM." > > > > > > We will fix it and if there is other nits like this will, we will > > > take care of it. Does that address your concern? > > > > > > Basically, the Binding Revocation messages should use the same > > > security association that was used during the > establishment of the > > > session that being revoked. > > > > > > Regards, > > > Ahmad > > > > > > > > > > -----Original Message----- > > > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > > > Sent: Friday, July 11, 2008 10:26 AM > > > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > > > Subject: Re: [MEXT] FW: I-D > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > Hi Ahmad > > > > > > > > I copy the security consideration from you draft. > > > > > > > > It says "The protocol described here uses the same security > > > > association > > > > between the MN and the HA or the MAG and the LMA that > > > has been used > > > > to exchange the corresponding MIPv6 or Proxy MIPv6 BU > > > and BA when > > > > the > > > > session was established. This SPD of this IPsec SA MUST > > > allow the > > > > MH > > > > type for the MGSM." > > > > > > > > How to secure signalling if there is no IPsec? > > > > > > > > I can't find the answer. > > > > > > > > BR > > > > Frank > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Ahmad Muhanna" > > > > To: "Frank Xia" ; > > > > Sent: Friday, July 11, 2008 10:20 AM > > > > Subject: RE: [MEXT] FW: I-D > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > > > Hi Frank, > > > > > > > > I guess you need to answer that question. Right? > > > > I assume that what you mentioned about 3GPP2 and WiMAX is > > accurate. > > > > i.e., > > > > "by WiMAX and 3GPP2 in which IPsec SA is not mandatory." > > > > > > > > Regards, > > > > Ahmad > > > > > > > > > > > > > -----Original Message----- > > > > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > > > > Sent: Friday, July 11, 2008 10:18 AM > > > > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > > > > Subject: Re: [MEXT] FW: I-D > > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > Hi Ahmad > > > > > > > > > > How to secure the signaling between HA and MN if there is > > > no IPsec? > > > > > > > > > > BR > > > > > Frank > > > > > > > > > > ----- Original Message ----- > > > > > From: "Ahmad Muhanna" > > > > > To: "Frank Xia" ; > > > > > Sent: Friday, July 11, 2008 10:12 AM > > > > > Subject: RE: [MEXT] FW: I-D > > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > > > > > > Hi Frank, > > > > > > > > > > I do not think there is a conflict here. > > > > > > > > > > In the case of WiMAX and 3GPP2, I assume that there will be > > > > no IPsec > > > > > SA between the HA and the MN, for example. > > > > > Therefore, there will be no SPD to worry about. Although > > > > the BRI/BRA > > > > > uses the MGSM which has a MH type that support IPsec > > (if IPsec is > > > > > used), but that is not applicable to the case you mentioned > > > > then there > > > > > is no problem. > > > > > > > > > > Does that make sense? > > > > > > > > > > Regards, > > > > > Ahmad > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > > > > > Sent: Friday, July 11, 2008 9:23 AM > > > > > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > > > > > Subject: Re: [MEXT] FW: I-D > > > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > > > Hi Ahmad > > > > > > > > > > > > IMHO, this document can't be directly used by WiMAX and > > > > > 3GPP2 in which > > > > > > IPsec SA is not mandatory. > > > > > > > > > > > > 3GPP2/WiMAX adopted RFC4285, and corresponding > > > documents, such as > > > > > > Diameter, RADIUS, now are explicitely supporting RFC4285. > > > > > > > > > > > > We discussed before. > > > > > > > > > > > > BR > > > > > > Frank > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Ahmad Muhanna" > > > > > > To: > > > > > > Sent: Friday, July 11, 2008 8:53 AM > > > > > > Subject: [MEXT] FW: I-D > > > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > > > > > > > > > > > > > > > Hello Folks, > > > > > > > > > > > > We updated the Binding Revocation draft according to the > > > > mext wg ml > > > > > > consensus by using the Mobile IPv6 Generic Signaling > > > > Message (MGSM) > > > > > > framework. Since the MGSM draft is still being revised, we > > > > > referenced > > > > > > the MGSM draft in all related sections of the Binding > > > Revocation > > > > > > draft. > > > > > > We probably will be able to optimize the draft a little > > > > > more in order > > > > > > to eliminate any duplication in some sections as soon as > > > > > the new MGSM > > > > > > draft revision becomes available. > > > > > > > > > > > > The only other change introduced in this revision > is that we > > > > > > referenced the DSMIP6 draft and made it optional for the HA > > > > > to include > > > > > > the IPv4 home address in the BRI. > > > > > > > > > > > > With the aggressive schedule and 3GPP dependency on this > > > > draft, we > > > > > > appreciate your review, comment, and feedback. > > > > > > > > > > > > Thanks in advance! > > > > > > > > > > > > Regards, > > > > > > Ahmad > > > > > > > > > > > > -----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, July 11, 2008 8:45 AM > > > > > > To: i-d-announce@ietf.org > > > > > > Subject: I-D > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > > Internet-Drafts > > > > > > directories. > > > > > > > > > > > > Title : Binding Revocation for IPv6 Mobility > > > > > > Author(s) : A. Muhanna, et al. > > > > > > Filename : > draft-muhanna-mext-binding-revocation-02.txt > > > > > > Pages : 32 > > > > > > Date : 2008-07-11 > > > > > > > > > > > > This document defines the revocation semantics for > > > terminating a > > > > > > mobile node's mobility session and associated > > resources. These > > > > > > semantics are generic enough and can be used by mobility > > > > > entities in > > > > > > the case of Client Mobile IPv6 and its extensions. This > > > > mechanism > > > > > > allows the mobility entity which initiates the revocation > > > > > procedure to > > > > > > request its corresponding one to terminate either one, > > > > > multiple or all > > > > > > specified binding cache entries. > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > > > http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding > > > > > -revocatio > > > > > > n-02.txt > > > > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > > > > Below is the data which will enable a MIME compliant > > > mail reader > > > > > > implementation to automatically retrieve the ASCII > > > version of the > > > > > > Internet-Draft. > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > > ------------------ > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > MEXT mailing list > > > > > > > MEXT@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 12:09:42 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CDD728C27D; Fri, 11 Jul 2008 12:09:42 -0700 (PDT) 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 6809C28C27D for ; Fri, 11 Jul 2008 12:09:40 -0700 (PDT) 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 WRzOk97lx0Dg for ; Fri, 11 Jul 2008 12:09:39 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 97F2628C259 for ; Fri, 11 Jul 2008 12:09:39 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 11 Jul 2008 15:09:55 -0400 Message-ID: In-Reply-To: <4D35478224365146822AE9E3AD4A266603281174$0001@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [MEXT] [mext] #11: De-registration when returning home[VijayDevarapalli ] Thread-Index: Acjh8V+MjNkSZIeVRpqs1hq3iTkwfwBgC3SQAAMZZiAAAQ0P0AABuQlg References: <4D35478224365146822AE9E3AD4A266603281174$0001@exchtewks3.starentnetworks.com> From: "Vijay Devarapalli" To: "Koodli, Rajeev" , "Pascal Thubert (pthubert)" , "Sri Gundavelli (sgundave)" Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home[VijayDevarapalli ] 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 Rajeev, > [RKo:>] I still did not hear what goes wrong if the MN sends packets > using HoA as source IP address. If something does go wrong, we need to > fix it. If not, I don't see why we need the above statement > ".. it will > not be able to send and receive packets .." Lets say a home agent has a binding cache entry for a particular home address and is defending the address. It starts seeing packets from the home link with the home address as the source address. Lets further assume that the home agent is the default router for the home link. Now does the home agent consider this as some other mobile node using the home address? Or does it consider it as the real mobile node using its home address from the home link? In the first case, the home agent would be dropping the packets. In the second case, it may forward the packets. The behavior is undefined. So I don't think we can claim that the mobile node will be able to send packets before de-registering with the home agent. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 12:26:27 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9532928C2DB; Fri, 11 Jul 2008 12:26:27 -0700 (PDT) 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 8E11928C2DB for ; Fri, 11 Jul 2008 12:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWHb3Ua6Bc6n for ; Fri, 11 Jul 2008 12:26:25 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 7EC6F28C2C8 for ; Fri, 11 Jul 2008 12:26:25 -0700 (PDT) Received: from localhost ([127.0.0.1]:49170 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1KHOGN-0002Ru-77; Fri, 11 Jul 2008 21:26:39 +0200 MIME-Version: 1.0 From: "mext" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software To: charliep@computer.org X-Trac-Project: mext Date: Fri, 11 Jul 2008 19:26:39 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/mext/trac/ticket/5#comment:1 Message-ID: <072.b003c87dcf07c6503592c1015ecdfb39@tools.ietf.org> References: <063.2216c156b8d01873f711182105b99860@tools.ietf.org> X-Trac-Ticket-ID: 5 In-Reply-To: <063.2216c156b8d01873f711182105b99860@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, mext@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: mext@ietf.org Subject: Re: [MEXT] [mext] #5: Wrong protocol number used in discussion about checksum pseudo-header: X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mext@ietf.org 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 Ticket #5: Wrong protocol number used in discussion about checksum pseudo-header: >From charliep@computer.org): * status: new => assigned ----------------------------------------+----------------------------------- Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: assigned Priority: major | Milestone: Component: draft-ietf-mext-rfc3775bis | Version: Severity: Active WG Document | Resolution: Keywords: | ----------------------------------------+----------------------------------- -- Ticket URL: mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 12:27:38 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F60928C2E3; Fri, 11 Jul 2008 12:27:38 -0700 (PDT) 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 4E2AF28C2E3 for ; Fri, 11 Jul 2008 12:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZp1ntktBoE9 for ; Fri, 11 Jul 2008 12:27:35 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 7845128C2F6 for ; Fri, 11 Jul 2008 12:27:35 -0700 (PDT) Received: from localhost ([127.0.0.1]:49188 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1KHOHW-00060U-2l; Fri, 11 Jul 2008 21:27:50 +0200 MIME-Version: 1.0 From: "mext" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software To: charliep@computer.org X-Trac-Project: mext Date: Fri, 11 Jul 2008 19:27:50 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/mext/trac/ticket/5#comment:2 Message-ID: <072.b5edc6d30a95d482c6778d744c2a7b51@tools.ietf.org> References: <063.2216c156b8d01873f711182105b99860@tools.ietf.org> X-Trac-Ticket-ID: 5 In-Reply-To: <063.2216c156b8d01873f711182105b99860@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, jari.arkko@piuha.net, mext@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: mext@ietf.org Subject: Re: [MEXT] [mext] #5: Wrong protocol number used in discussion about checksum pseudo-header: X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mext@ietf.org 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 Ticket #5: Wrong protocol number used in discussion about checksum pseudo-header: >From charliep@computer.org): * cc: jari.arkko@piuha.net (added) * keywords: => protocol number, checksum ----------------------------------------+----------------------------------- Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: assigned Priority: major | Milestone: Component: draft-ietf-mext-rfc3775bis | Version: Severity: Active WG Document | Resolution: Keywords: protocol number, checksum | ----------------------------------------+----------------------------------- -- Ticket URL: mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 14:05:36 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BED73A67AC; Fri, 11 Jul 2008 14:05:36 -0700 (PDT) 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 1F6333A6961 for ; Fri, 11 Jul 2008 14:05:35 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uxnFBm-az7y for ; Fri, 11 Jul 2008 14:05:33 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 2B1443A6778 for ; Fri, 11 Jul 2008 14:05:33 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6BL5mh12924; Fri, 11 Jul 2008 21:05:48 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 11 Jul 2008 16:05:34 -0500 Message-ID: In-Reply-To: <008201c8e388$984a4240$5c0c7c0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-02.txt Thread-Index: AcjjiJ+NPf/1l6akToyrjHQ/DgB6fgAB3U6A References: <00be01c8e361$a995d180$5c0c7c0a@china.huawei.com> <000601c8e369$530b9b80$5c0c7c0a@china.huawei.com> <001201c8e36a$746e18b0$5c0c7c0a@china.huawei.com> <003901c8e36c$02c6b850$5c0c7c0a@china.huawei.com> <000e01c8e370$3f9f83c0$5c0c7c0a@china.huawei.com> <005601c8e37f$90fc3a60$5c0c7c0a@china.huawei.com> <008201c8e388$984a4240$5c0c7c0a@china.huawei.com> From: "Ahmad Muhanna" To: "Frank Xia" , Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-02.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 Frank, Please see inline. Regards, Ahmad > -----Original Message----- > From: Frank Xia [mailto:xiayangsong@huawei.com] > Sent: Friday, July 11, 2008 2:02 PM > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > Subject: Re: [MEXT] FW: I-D > Action:draft-muhanna-mext-binding-revocation-02.txt > > Hi Ahmad > > IMHO, you are trying to escape from answering my very simple > question. :-) [Ahmad] Okay; I am not sure what to say here. Please see more below. > > If you want to offload your security consideration to the > MGSM draft, you should contact the authors of the draft, and > make sure that they will deal with the issue. [Ahmad] There is nothing to offload to the Mobile IPv6 Generic Signaling Message (MGSM) framework draft. That draft does not specify any new security mechanism either. It is nothing other than saying that the new MH needs to be added to the SPD in case of IPsec and the same security association used for the mobility binding establishment signaling (BU/BA) will be used to secure the MGSM messages. > > Here are some specific question. > 1)which authentication options should be include in BRI/BRA? > MN-HA or MN-AAA? [Ahmad] This needs to be addressed separately. Or probably you can start a separate thread for that and get feedback from the list. > 2) If authentication fails, is any new status to be defined in BRA ? > 0 success. > 1 partial success. > 2 Binding Does NOT Exist. > 3 Global Revocation NOT Authorized. > 4 CAN NOT Identify Binding. [Ahmad] The problem is not in a new status code, it is to have No. 1 resolved. IMO. > BR > Frank > > ----- Original Message ----- > From: "Ahmad Muhanna" > To: "Frank Xia" ; > Sent: Friday, July 11, 2008 1:12 PM > Subject: RE: [MEXT] FW: I-D > Action:draft-muhanna-mext-binding-revocation-02.txt > > > Hi Frank, > > The Binding Revocation draft does not define any new security > mechanism, > > I am not trying to escape from answering your question. What > I am saying here is that the Binding Revocation does not > specify a new security mechanism. It only defines a generic > Revocation mechanism that can be used by different mobility > entities as captured in the draft. > > What else you want me to say? > > If you have a security mechanism that can be used for > securing BU/BA exchange, it should be good enough to secure > BRI/BRA. If you want me to spell out the word "RFC4285", that > is fine, you should be able to use that security association > too. On top of all of this, as I said earlier and based on > the mext ml consensus, BRI and BRA use the MGSM framework and > the security mechanism that is defined there. > > > Regards, > Ahmad > > > > -----Original Message----- > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > Sent: Friday, July 11, 2008 12:57 PM > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > Subject: Re: [MEXT] FW: I-D > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > Hi Ahmad > > > > My question is very simple, why could you answer this directly? > > > > OK, I would like to reword my question. > > > > How to secure BRI/BRA messages when there is not IPsec SA > between HA > > and MN? > > > > BR > > Frank > > > > ----- Original Message ----- > > From: "Ahmad Muhanna" > > To: "Frank Xia" ; > > Sent: Friday, July 11, 2008 12:49 PM > > Subject: RE: [MEXT] FW: I-D > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > Thanks Frank! > > > > This is becoming a very interesting discussion:-) Let me > try one more > > time. Please see inline. > > > > Regards, > > Ahmad > > > > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > Hi Ahmad > > > > > > Firstly, why do you only mention "If IPsec is used" ? > > > > Ok, since as per the consensus of the mext ml, the BRI and > BRA use the > > Mobile IPv6 Generic Signaling Message (MGSM) framework, I > believe what > > we need to do here: is to reference that draft and only > document the > > exceptions. > > > > What about the following:? > > > > " > > The protocol described here uses the same security > architecture and > > requirement of the Mobile IPv6 Generic Signaling Message > framework > > as > > defined in [ID-MGSM]. > > > > However, in the case when the MAG sends a BRI message with the G > > bit > > is set, the LMA must verify that the MAG is authorized to use > > Per-Peer > > Global Revocation. > > " > > > > Therefore, there is no exception and IPsec is not treated > differently > > than any other security mechanisms. > > > > > > > > Secondly, there are different security mechanism between > > RFC3776/4877 > > > and RFC4285. > > > > > As to the latter, there is not separated SA establishment and > > > maitanance machanism (such as IKE), and each packet should > > > authenticate itselft. > > > > [Ahmad] > > With the proposed text above, I guess this becomes a different > > discussion. We actually can take that offline. > > But I am just curious, what do you mean by the following:? > > > > 1. there is not separated SA establishment and maitanance machanism > > (such as IKE), and 2. each packet should authenticate itselft. > > > > > > > > IMO, your original text is only about IPsec case, and your > > later text > > > only highlights IPsec case. > > > > > > Could you give me an explicit answer? > > > How to secure the signaling between HA and MN if there is > no IPsec? > > > > [Ahmad] > > I hope that this has been addressed, please see above. > > > > > > > > Please don't ask me because I am not the author of draft. > > > Of course, I am willing to answer the question if you add > me as an > > > co-author > > > :-) > > > > > > BR > > > Frank > > > > > > ----- Original Message ----- > > > From: "Ahmad Muhanna" > > > To: "Frank Xia" ; > > > Sent: Friday, July 11, 2008 10:46 AM > > > Subject: RE: [MEXT] FW: I-D > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > Hi Frank, > > > > > > The following text captures all different mechanisms that > > are used or > > > can be used to establish a security association between the > > MN and the > > > HA or the MAG and the LMA. > > > > > > "The protocol described here uses the same security association > > > between the MN and the HA or the MAG and the LMA that > > has been used > > > to exchange the corresponding MIPv6 or Proxy MIPv6 BU > > and BA when > > > the > > > session was established." > > > > > > I personally believe that it captures and cover all cases > including > > > the case you mentioned. > > > > > > > > > Regards, > > > Ahmad > > > > > > > > > > -----Original Message----- > > > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > > > Sent: Friday, July 11, 2008 10:37 AM > > > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > > > Subject: Re: [MEXT] FW: I-D > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > Hi Ahmad > > > > > > > > Please add more information about "If IPsec is not used > > ...", IMO, > > > > it is not necessary limited to "If IPsec is used". > > > > > > > > BR > > > > Frank > > > > > > > > ----- Original Message ----- > > > > From: "Ahmad Muhanna" > > > > To: "Frank Xia" ; > > > > Sent: Friday, July 11, 2008 10:32 AM > > > > Subject: RE: [MEXT] FW: I-D > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > > > > > > > Thanks Frank for pointing that, I believe the text should > > > have been as > > > > follows: > > > > > > > > "The protocol described here uses the same security > association > > > > between the MN and the HA or the MAG and the LMA that > > > has been used > > > > to exchange the corresponding MIPv6 or Proxy MIPv6 BU > > and BA when > > > > the > > > > session was established. If IPsec is used, the SPD of > > this IPsec > > > > SA > > > > MUST allow the MH type for the MGSM." > > > > > > > > We will fix it and if there is other nits like this > will, we will > > > > take care of it. Does that address your concern? > > > > > > > > Basically, the Binding Revocation messages should use the same > > > > security association that was used during the > > establishment of the > > > > session that being revoked. > > > > > > > > Regards, > > > > Ahmad > > > > > > > > > > > > > -----Original Message----- > > > > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > > > > Sent: Friday, July 11, 2008 10:26 AM > > > > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > > > > Subject: Re: [MEXT] FW: I-D > > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > Hi Ahmad > > > > > > > > > > I copy the security consideration from you draft. > > > > > > > > > > It says "The protocol described here uses the same security > > > > > association > > > > > between the MN and the HA or the MAG and the LMA that > > > > has been used > > > > > to exchange the corresponding MIPv6 or Proxy MIPv6 BU > > > > and BA when > > > > > the > > > > > session was established. This SPD of this IPsec SA MUST > > > > allow the > > > > > MH > > > > > type for the MGSM." > > > > > > > > > > How to secure signalling if there is no IPsec? > > > > > > > > > > I can't find the answer. > > > > > > > > > > BR > > > > > Frank > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Ahmad Muhanna" > > > > > To: "Frank Xia" ; > > > > > Sent: Friday, July 11, 2008 10:20 AM > > > > > Subject: RE: [MEXT] FW: I-D > > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > > > > > > Hi Frank, > > > > > > > > > > I guess you need to answer that question. Right? > > > > > I assume that what you mentioned about 3GPP2 and WiMAX is > > > accurate. > > > > > i.e., > > > > > "by WiMAX and 3GPP2 in which IPsec SA is not mandatory." > > > > > > > > > > Regards, > > > > > Ahmad > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > > > > > Sent: Friday, July 11, 2008 10:18 AM > > > > > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > > > > > Subject: Re: [MEXT] FW: I-D > > > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > > > Hi Ahmad > > > > > > > > > > > > How to secure the signaling between HA and MN if there is > > > > no IPsec? > > > > > > > > > > > > BR > > > > > > Frank > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Ahmad Muhanna" > > > > > > To: "Frank Xia" ; > > > > > > Sent: Friday, July 11, 2008 10:12 AM > > > > > > Subject: RE: [MEXT] FW: I-D > > > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > > > > > > > > > Hi Frank, > > > > > > > > > > > > I do not think there is a conflict here. > > > > > > > > > > > > In the case of WiMAX and 3GPP2, I assume that there will be > > > > > no IPsec > > > > > > SA between the HA and the MN, for example. > > > > > > Therefore, there will be no SPD to worry about. Although > > > > > the BRI/BRA > > > > > > uses the MGSM which has a MH type that support IPsec > > > (if IPsec is > > > > > > used), but that is not applicable to the case you mentioned > > > > > then there > > > > > > is no problem. > > > > > > > > > > > > Does that make sense? > > > > > > > > > > > > Regards, > > > > > > Ahmad > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > > > > > > Sent: Friday, July 11, 2008 9:23 AM > > > > > > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > > > > > > Subject: Re: [MEXT] FW: I-D > > > > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > > > > > Hi Ahmad > > > > > > > > > > > > > > IMHO, this document can't be directly used by WiMAX and > > > > > > 3GPP2 in which > > > > > > > IPsec SA is not mandatory. > > > > > > > > > > > > > > 3GPP2/WiMAX adopted RFC4285, and corresponding > > > > documents, such as > > > > > > > Diameter, RADIUS, now are explicitely supporting RFC4285. > > > > > > > > > > > > > > We discussed before. > > > > > > > > > > > > > > BR > > > > > > > Frank > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Ahmad Muhanna" > > > > > > > To: > > > > > > > Sent: Friday, July 11, 2008 8:53 AM > > > > > > > Subject: [MEXT] FW: I-D > > > > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello Folks, > > > > > > > > > > > > > > We updated the Binding Revocation draft according to the > > > > > mext wg ml > > > > > > > consensus by using the Mobile IPv6 Generic Signaling > > > > > Message (MGSM) > > > > > > > framework. Since the MGSM draft is still being revised, we > > > > > > referenced > > > > > > > the MGSM draft in all related sections of the Binding > > > > Revocation > > > > > > > draft. > > > > > > > We probably will be able to optimize the draft a little > > > > > > more in order > > > > > > > to eliminate any duplication in some sections as soon as > > > > > > the new MGSM > > > > > > > draft revision becomes available. > > > > > > > > > > > > > > The only other change introduced in this revision > > is that we > > > > > > > referenced the DSMIP6 draft and made it optional > for the HA > > > > > > to include > > > > > > > the IPv4 home address in the BRI. > > > > > > > > > > > > > > With the aggressive schedule and 3GPP dependency on this > > > > > draft, we > > > > > > > appreciate your review, comment, and feedback. > > > > > > > > > > > > > > Thanks in advance! > > > > > > > > > > > > > > Regards, > > > > > > > Ahmad > > > > > > > > > > > > > > -----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, July 11, 2008 8:45 AM > > > > > > > To: i-d-announce@ietf.org > > > > > > > Subject: I-D > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > > > Internet-Drafts > > > > > > > directories. > > > > > > > > > > > > > > Title : Binding Revocation for IPv6 Mobility > > > > > > > Author(s) : A. Muhanna, et al. > > > > > > > Filename : > > draft-muhanna-mext-binding-revocation-02.txt > > > > > > > Pages : 32 > > > > > > > Date : 2008-07-11 > > > > > > > > > > > > > > This document defines the revocation semantics for > > > > terminating a > > > > > > > mobile node's mobility session and associated > > > resources. These > > > > > > > semantics are generic enough and can be used by mobility > > > > > > entities in > > > > > > > the case of Client Mobile IPv6 and its extensions. This > > > > > mechanism > > > > > > > allows the mobility entity which initiates the revocation > > > > > > procedure to > > > > > > > request its corresponding one to terminate either one, > > > > > > multiple or all > > > > > > > specified binding cache entries. > > > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > > > > > http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding > > > > > > -revocatio > > > > > > > n-02.txt > > > > > > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > > > > > > Below is the data which will enable a MIME compliant > > > > mail reader > > > > > > > implementation to automatically retrieve the ASCII > > > > version of the > > > > > > > Internet-Draft. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > > > ------------------ > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > MEXT mailing list > > > > > > > > MEXT@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 14:40:03 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3D023A68D1; Fri, 11 Jul 2008 14:40:03 -0700 (PDT) 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 9831A3A6961 for ; Fri, 11 Jul 2008 14:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yo7Q12df1WFD for ; Fri, 11 Jul 2008 14:40:00 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id E054F3A68D1 for ; Fri, 11 Jul 2008 14:40:00 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K3V00HB72V6A2@usaga04-in.huawei.com> for mext@ietf.org; Fri, 11 Jul 2008 16:40:19 -0500 (CDT) Received: from X24512z ([10.124.12.92]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K3V007WV2V5WY@usaga04-in.huawei.com> for mext@ietf.org; Fri, 11 Jul 2008 16:40:18 -0500 (CDT) Date: Fri, 11 Jul 2008 16:40:17 -0500 From: Frank Xia To: Ahmad Muhanna , mext@ietf.org Message-id: <00bc01c8e39e$b644f6d0$5c0c7c0a@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: <00be01c8e361$a995d180$5c0c7c0a@china.huawei.com> <000601c8e369$530b9b80$5c0c7c0a@china.huawei.com> <001201c8e36a$746e18b0$5c0c7c0a@china.huawei.com> <003901c8e36c$02c6b850$5c0c7c0a@china.huawei.com> <000e01c8e370$3f9f83c0$5c0c7c0a@china.huawei.com> <005601c8e37f$90fc3a60$5c0c7c0a@china.huawei.com> <008201c8e388$984a4240$5c0c7c0a@china.huawei.com> Subject: [MEXT] Authentication option support in Binding Revocation 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ahmad Upon your request, I initials this thread. 1) How are BRI/BRA messages secured when there is not IPsec SA between HA and MN? 2)If authentication options defined in RFC4285 are used, which option should be used? MN-HA or MN-AAA? 3)If BRI processing failure is because of failed authentication, how does the MN inform HA? BR Frank _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 14:53:14 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F4C43A68A0; Fri, 11 Jul 2008 14:53:14 -0700 (PDT) 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 C5E693A686C for ; Fri, 11 Jul 2008 14:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+HeDon3NxNu for ; Fri, 11 Jul 2008 14:53:12 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id EC8DB3A684E for ; Fri, 11 Jul 2008 14:53:11 -0700 (PDT) Received: from localhost ([127.0.0.1]:36752 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1KHQYP-0007e8-Dz; Fri, 11 Jul 2008 23:53:25 +0200 MIME-Version: 1.0 From: "mext" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software To: charliep@computer.org X-Trac-Project: mext Date: Fri, 11 Jul 2008 21:53:25 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/mext/trac/ticket/5#comment:3 Message-ID: <072.63ba69fafb1ecae217844af3726ac6a4@tools.ietf.org> References: <063.2216c156b8d01873f711182105b99860@tools.ietf.org> X-Trac-Ticket-ID: 5 In-Reply-To: <063.2216c156b8d01873f711182105b99860@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, jari.arkko@piuha.net, mext@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: mext@ietf.org Subject: Re: [MEXT] [mext] #5: Wrong protocol number used in discussion about checksum pseudo-header: X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mext@ietf.org 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 Ticket #5: Wrong protocol number used in discussion about checksum pseudo-header: >From charliep@computer.org): * status: assigned => closed * version: => 1.0 * resolution: => fixed * milestone: => milestone1 Suggested text revision made in draft-ietf-mext-rfc3775bis-01.txt ----------------------------------------+----------------------------------- Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: draft-ietf-mext-rfc3775bis | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: protocol number, checksum | ----------------------------------------+----------------------------------- -- Ticket URL: mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 15:20:01 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9C1B3A68E4; Fri, 11 Jul 2008 15:20:00 -0700 (PDT) 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 67C733A68E4 for ; Fri, 11 Jul 2008 15:19:59 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGTWiOXCQEfH for ; Fri, 11 Jul 2008 15:19:58 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 5BED03A686C for ; Fri, 11 Jul 2008 15:19:58 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6BMKDh22187; Fri, 11 Jul 2008 22:20:13 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 11 Jul 2008 17:19:57 -0500 Message-ID: In-Reply-To: <00bc01c8e39e$b644f6d0$5c0c7c0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Authentication option support in Binding Revocation Thread-Index: AcjjnrhqN8ZkTW8FSwSCRI+jRH6sSQAA3UUA References: <00be01c8e361$a995d180$5c0c7c0a@china.huawei.com> <000601c8e369$530b9b80$5c0c7c0a@china.huawei.com> <001201c8e36a$746e18b0$5c0c7c0a@china.huawei.com> <003901c8e36c$02c6b850$5c0c7c0a@china.huawei.com> <000e01c8e370$3f9f83c0$5c0c7c0a@china.huawei.com> <005601c8e37f$90fc3a60$5c0c7c0a@china.huawei.com> <008201c8e388$984a4240$5c0c7c0a@china.huawei.com> <00bc01c8e39e$b644f6d0$5c0c7c0a@china.huawei.com> From: "Ahmad Muhanna" To: "Frank Xia" , Subject: [MEXT] Authentication option support in Binding Revocation 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 Frank, It was a comment on that topic rather than a request, but that is fine:) Please note that I changed the subject by removing the word "draft" because this discussion is supposed to be generic on the applicability of Auth protocol to secure Binding Revocation signaling not the current Binding Revocation draft. The reason as I said before, the mext wg consensus was to use MGSM framework for BRI and BRA. Therefore, if the discussion is on the draft, then the discussion should be focused on the need to secure MGSM signaling using the authentication protocol. Regards, Ahmad > -----Original Message----- > From: Frank Xia [mailto:xiayangsong@huawei.com] > Sent: Friday, July 11, 2008 4:40 PM > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > Subject: Authentication option support in Binding Revocation draft > > Hi Ahmad > > Upon your request, I initials this thread. > > 1) How are BRI/BRA messages secured when there is not IPsec > SA between HA and MN? > > 2)If authentication options defined in RFC4285 are used, > which option should be used? > MN-HA or MN-AAA? > > 3)If BRI processing failure is because of failed > authentication, how does the MN inform HA? > > BR > Frank > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 15:32:36 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FD5F3A6AA5; Fri, 11 Jul 2008 15:32:36 -0700 (PDT) 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 4CA983A6A87 for ; Fri, 11 Jul 2008 15:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qALyhXGg9HJc for ; Fri, 11 Jul 2008 15:32:34 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 820A43A6A40 for ; Fri, 11 Jul 2008 15:32:34 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K3V00HLG5ASA2@usaga04-in.huawei.com> for mext@ietf.org; Fri, 11 Jul 2008 17:32:53 -0500 (CDT) Received: from X24512z ([10.124.12.92]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K3V00LRX5ARXZ@usaga04-in.huawei.com> for mext@ietf.org; Fri, 11 Jul 2008 17:32:52 -0500 (CDT) Date: Fri, 11 Jul 2008 17:32:51 -0500 From: Frank Xia To: Ahmad Muhanna , mext@ietf.org Message-id: <000a01c8e3a6$0e3cc8c0$5c0c7c0a@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: <000601c8e369$530b9b80$5c0c7c0a@china.huawei.com> <001201c8e36a$746e18b0$5c0c7c0a@china.huawei.com> <003901c8e36c$02c6b850$5c0c7c0a@china.huawei.com> <000e01c8e370$3f9f83c0$5c0c7c0a@china.huawei.com> <005601c8e37f$90fc3a60$5c0c7c0a@china.huawei.com> <008201c8e388$984a4240$5c0c7c0a@china.huawei.com> <00bc01c8e39e$b644f6d0$5c0c7c0a@china.huawei.com> Subject: Re: [MEXT] Authentication option support in Binding Revocation 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ahmad All the questions are explicit to the draft. I encourage you to face the questions directly. If authentication options are required to add in the BRI/BRA message, IMO, this is not related to MGSM draft. I will feel confortable only after I have an satisfactory answer. BR Frank ----- Original Message ----- From: "Ahmad Muhanna" To: "Frank Xia" ; Sent: Friday, July 11, 2008 5:19 PM Subject: Authentication option support in Binding Revocation Hi Frank, It was a comment on that topic rather than a request, but that is fine:) Please note that I changed the subject by removing the word "draft" because this discussion is supposed to be generic on the applicability of Auth protocol to secure Binding Revocation signaling not the current Binding Revocation draft. The reason as I said before, the mext wg consensus was to use MGSM framework for BRI and BRA. Therefore, if the discussion is on the draft, then the discussion should be focused on the need to secure MGSM signaling using the authentication protocol. Regards, Ahmad > -----Original Message----- > From: Frank Xia [mailto:xiayangsong@huawei.com] > Sent: Friday, July 11, 2008 4:40 PM > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > Subject: Authentication option support in Binding Revocation draft > > Hi Ahmad > > Upon your request, I initials this thread. > > 1) How are BRI/BRA messages secured when there is not IPsec > SA between HA and MN? > > 2)If authentication options defined in RFC4285 are used, > which option should be used? > MN-HA or MN-AAA? > > 3)If BRI processing failure is because of failed > authentication, how does the MN inform HA? > > BR > Frank > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 15:36:17 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3371D3A6ADA; Fri, 11 Jul 2008 15:36:17 -0700 (PDT) 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 A2A2C3A69F4 for ; Fri, 11 Jul 2008 15:36:15 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8yxpW3HEuM6 for ; Fri, 11 Jul 2008 15:36:14 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 8F3223A6AA5 for ; Fri, 11 Jul 2008 15:36:14 -0700 (PDT) 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 m6BMYgu12560; Fri, 11 Jul 2008 22:34:42 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 11 Jul 2008 17:36:24 -0500 Message-ID: In-Reply-To: <000a01c8e3a6$0e3cc8c0$5c0c7c0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Authentication option support in Binding Revocation Thread-Index: AcjjphDit2JM2NfLRfOaKYW5sEQthQAAB5dg References: <000601c8e369$530b9b80$5c0c7c0a@china.huawei.com> <001201c8e36a$746e18b0$5c0c7c0a@china.huawei.com> <003901c8e36c$02c6b850$5c0c7c0a@china.huawei.com> <000e01c8e370$3f9f83c0$5c0c7c0a@china.huawei.com> <005601c8e37f$90fc3a60$5c0c7c0a@china.huawei.com> <008201c8e388$984a4240$5c0c7c0a@china.huawei.com> <00bc01c8e39e$b644f6d0$5c0c7c0a@china.huawei.com> <000a01c8e3a6$0! e3cc8c0$5 c0c7c0a@china.huawei.com> From: "Ahmad Muhanna" To: "Frank Xia" , Cc: Julien Laganier Subject: Re: [MEXT] Authentication option support in Binding Revocation 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 Frank, I usually do not like to yield issues to the chairs that quickly, but it seems that the chairs need to take care of this. It is not me who decides on this, it is the consensus of the group. Cheers! Regards, Ahmad > -----Original Message----- > From: Frank Xia [mailto:xiayangsong@huawei.com] > Sent: Friday, July 11, 2008 5:33 PM > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > Subject: Re: Authentication option support in Binding Revocation > > Hi Ahmad > > All the questions are explicit to the draft. > I encourage you to face the questions directly. > > If authentication options are required to add in the BRI/BRA > message, IMO, this is not related to MGSM draft. > > I will feel confortable only after I have an satisfactory answer. > > BR > Frank > > > ----- Original Message ----- > From: "Ahmad Muhanna" > To: "Frank Xia" ; > Sent: Friday, July 11, 2008 5:19 PM > Subject: Authentication option support in Binding Revocation > > > > Hi Frank, > > It was a comment on that topic rather than a request, but > that is fine:) > > Please note that I changed the subject by removing the word "draft" > because this discussion is supposed to be generic on the applicability > of Auth protocol to secure Binding Revocation signaling not > the current > Binding Revocation draft. The reason as I said before, the mext wg > consensus was to use MGSM framework for BRI and BRA. > > Therefore, if the discussion is on the draft, then the > discussion should > be focused on the need to secure MGSM signaling using the > authentication > protocol. > > Regards, > Ahmad > > > > -----Original Message----- > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > Sent: Friday, July 11, 2008 4:40 PM > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > Subject: Authentication option support in Binding Revocation draft > > > > Hi Ahmad > > > > Upon your request, I initials this thread. > > > > 1) How are BRI/BRA messages secured when there is not IPsec > > SA between HA and MN? > > > > 2)If authentication options defined in RFC4285 are used, > > which option should be used? > > MN-HA or MN-AAA? > > > > 3)If BRI processing failure is because of failed > > authentication, how does the MN inform HA? > > > > BR > > Frank > > > > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 16:03:54 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC8B23A68E4; Fri, 11 Jul 2008 16:03:54 -0700 (PDT) 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 99A9E3A67D9 for ; Fri, 11 Jul 2008 16:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xO+ucpFXDjA2 for ; Fri, 11 Jul 2008 16:03:52 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id BC4B43A67D4 for ; Fri, 11 Jul 2008 16:03:52 -0700 (PDT) Received: from localhost ([127.0.0.1]:41534 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1KHRem-0008KO-U5; Sat, 12 Jul 2008 01:04:04 +0200 MIME-Version: 1.0 From: "mext" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software To: charliep@computer.org X-Trac-Project: mext Date: Fri, 11 Jul 2008 23:04:04 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/mext/trac/ticket/6#comment:1 Message-ID: <072.686b95b0cf99646c7808306c5f3838f9@tools.ietf.org> References: <063.6cdbee963dc30703959f827d9a9543eb@tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <063.6cdbee963dc30703959f827d9a9543eb@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, jari.arkko@piuha.net, mext@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: mext@ietf.org Subject: Re: [MEXT] [mext] #6: Minor editorial corrections and updates X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mext@ietf.org 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 Ticket #6: Minor editorial corrections and updates >From charliep@computer.org): * status: new => closed * cc: jari.arkko@piuha.net (added) * version: => 1.0 * milestone: => milestone1 * keywords: => editorial * resolution: => fixed Suggested text revisions made in draft-ietf-mext-rfc3775bis-01.txt. Note that in the text of the proposed revision, "RFC 2424" should have been "RFC 2434". ----------------------------------------+----------------------------------- Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: draft-ietf-mext-rfc3775bis | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: editorial | ----------------------------------------+----------------------------------- -- Ticket URL: mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 16:29:07 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3E0D3A67EF; Fri, 11 Jul 2008 16:29:06 -0700 (PDT) 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 DA9BC3A6845 for ; Fri, 11 Jul 2008 16:29:05 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foY7Uptb9S+H for ; Fri, 11 Jul 2008 16:29:04 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by core3.amsl.com (Postfix) with ESMTP id 421B83A67D9 for ; Fri, 11 Jul 2008 16:29:04 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so3566543rvf.49 for ; Fri, 11 Jul 2008 16:29:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=nRZ7dSXsZ03MZ12EJfBOyC6lRhw6qiYKL5REXhU4e1A=; b=RA3l3sBrAPmDjSW/pprA0ZbJy11eCfUHeTbylFB5L1OeVdFHDbqIJgZWnAooWzFAhb IrhLnrHaQV+xlAa8y7koRuHQnIhztzhkzIuTpdQeKUFo7sQgNs/IagcKWqVmA6k1XGsl +kvhjTddB/3DZyqGsi1g/MJ6ISuziSCIJY1sA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=rsyY861tdUj+tVVDXPqs4fR7vX4YL7LqnDVvEXoZ3cAF//JBvgAiGSZOoE9YAh5hWb 46OR0zAoErOM5Hm1pXE68K0ax2C6PhrYGRnSrrK5ez+0sCEERbGnM2EnzjpWexDLwBms QzcVitUVEga73VaaKvFFrE0uatkT0kmEEbkws= Received: by 10.115.46.10 with SMTP id y10mr14868742waj.137.1215818962784; Fri, 11 Jul 2008 16:29:22 -0700 (PDT) Received: by 10.141.76.15 with HTTP; Fri, 11 Jul 2008 16:29:22 -0700 (PDT) Message-ID: Date: Fri, 11 Jul 2008 16:29:22 -0700 From: "Vijay Devarapalli" To: "Arnaud Ebalard" In-Reply-To: <87r6c2r3bu.fsf@natisbad.org> MIME-Version: 1.0 Content-Disposition: inline References: <87r6c2r3bu.fsf@natisbad.org> Cc: ipsec@ietf.org, mext@ietf.org Subject: Re: [MEXT] [IPsec] Redirect mechanism for IKEv2 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 Arnaud, I apologize for the delay in responding to your email. On Fri, May 16, 2008 at 2:44 AM, Arnaud Ebalard wrote: > Hi Vijay, > > "Vijay Devarapallli" writes: > >> The draft at the URL below describes a mechanism for re-directing an >> IKEv2 initiator to another gateway during the IKE_SA_INIT exchange. >> This could be used for Mobile IPv6 also for a home agent to re-direct >> a mobile node to another home agent. >> >> Comments/reviews are welcome. > > Some comments below, with quoted parts from the draft. Sorry for > cross-posting but the discussion probably belongs to both ML. > > Mostly, the idea of the mechanim and the coverage looks ok to me but the > relationships with MIPv6 does not. > > To summarize most of my comments, the draft makes the redirect mechanism > happen at the IKE level and expects that it has no impact on the work of > the MIPv6 part. In practice, the address of the Home Agent being also > the address of the IKE GW and the IPsec SA (even if the negotiation > could be modified to be for different addresses regarding the IPsec SA > and the IKE GW), there is a need for synchronization between IKE and > MIPv6. IMHO, this is missing in the draft and should be stated. I am not sure if this document should talk about the interactions between the MIPv6 and IKEv2 processes in a particular implementation. > Note that this summary and some of my comments/questions below can also > be applied to Section 9 of RFC 4877, which describes Dynamic Home > Address configuration using IKEv2. > > For me, the redirect mechanism described in the draft is in some way the > dual of the Dynamic HoA configuration using IKE described in section 9 > of RFC 4877. > > Basically: > > - triggering event: IKE seems to initiate connections just like that, > without real triggering events, i.e. some packets being sent that > require protection and match some selector of a SPD entry. > - communications/synchronization: IKE is used (addresses here and in > 4877) for configuring/negotiating MIPv6 parameters but the > synchronization of those elements is not covered. I would also include > the IPsec in the picture. In practice, the MIPv6 modules, the IKE > daemon and the IPsec stack must work *together*. At the moment, some > draft and RFC on those elements have expectation but do not cover the > interactions between those elements. I have seen other emails from you on this subject, especially the interactions between IKEv2 and MIPv6 as described in RFC 4877 and RFC 5026. Perhaps, as you suggest, it might be a good idea to write a separate document that describes how these two protocols can interact with each other. Personally, it is not clear to me on what sort of details you are looking for. I think many of the details you are looking for is implementation specific. >> Mobile IPv6 [3] uses IKEv2 for mutual authentication between the >> mobile node and the home agent. IKEv2 is also used for home address >> configuration and setting up IPsec security associations for >> protecting Mobile IPv6 signaling messages [4]." > > uses -> may/can use. The mechanism is not required. IKEv1 is also > usable, so using IKE without any version might be better here. Fixed. >> The IKEv2 exchange precedes the exchange of Mobile IPv6 signaling >> messages. > > In practice, AFAICT, the IKE exchange is *triggered* by the emission of > the BU. It seems that RFC 4877 has started to take a different direction > where IKE is used to configure MIPv6, but the details are missing. When the mobile node boots up and figures that it needs to configure a home address, it can trigger an IKEv2 exchange with the home agent. Nothing needs to be said. This would be implementation specific on the mobile node. >> Therefore the mechanism described in this document can be also be >> used by a Mobile IPv6 home agent to re-direct a mobile node to >> another home agent. > > Collusion between Key Manager and HA operation. Yes. So? >> There is a Home Agent Switch mechanism available for re-directing a >> mobile node to another home agent, described in [5]. The Home Agent >> Switch mechanism can only be used after the binding cache had been >> created at the home agent for the mobile node. The disadvantage with >> this is that quite a bit of state is created on the home agent before >> the mobile node can be re-directed to another home agent. The >> mechanism described in this document can be used for re-directing a >> mobile node before any state is created on the home agent. > > IMHO, there is a difference between IKE and MIPv6 operations: > > 1) A Home Agent is overloaded and start redirecting MN to another HA: > for instance, it is already using all its available upload bandwidth > for registered MN (which is unrelated to IPsec/IKE). > 2) There are too many IKE peers connecting at the same time on an IKE > daemon (for the setup of IPsec SA between MN and HA or common > clients) and the IKE daemon starts redirecting clients to another IKE > daemon. > > What I mean is that, AFAICT, the two mechanism solve different problems, > through different channels. Do you see the need for any changes in the draft for this? > In section 3 > >> When the VPN client receives the IKE_SA_INIT response with the >> REDIRECT payload, it initiates a new IKE_SA_INIT exchange with the >> VPN gateway listed in the REDIRECT payload. The VPN client includes >> the IP address of the original VPN gateway that re-directed the >> client. The IKEv2 exchange then proceeds as normal with the selected >> VPN gateway. > > IMHO, the last sentence simply does not cover the possible associated > issues and how things should be done, *how* the associated users (IPsec > stack, MIPv6 module) are notified (on both sides). I am considering that > MIPv6 is used to cover all cases. > > - address of the IKE GW on the remote side > - the address of the HA used by the client > - the remote address of currently negotiated transport mode SA > protecting MIPv6 signaling > - endpoints of negotiated tunnel mode SA protecting data traffic if any > > I imagine that they will be set to the new IP. AFAICT, if the > negotiation was triggered by a BU, there will be a mismatch between the > triggering packet and the new destination. It does not have to be triggered by the Binding Update. The bootstrapping procedure on a Mobile IPv6 mobile node could be triggered for some other reason. >> When this mechanism is used with Mobile IPv6, a mobile node's >> security associations with its home agent may expire while it still >> has a valid binding cache entry at the home agent. In this case, the >> mobile node MUST NOT use an anycast address as the destination >> address in the IKE_SA_INIT exchange to setup new security >> associations. It MUST try to setup security associations with its >> existing home agent. > > How does the MN knows the address is anycast? The MIPv6 home agents anycast address is well known. See http://www.iana.org/assignments/ipv6-anycast-addresses. But I understand what you mean. I modified the paragraph as follows. When this mechanism is used with Mobile IPv6, a mobile node's security associations with its home agent may expire while it still has a valid binding cache entry at the home agent. In this case, the mobile node MUST NOT use the original home agent address as the destination address in the IKE_SA_INIT exchange to setup new security associations. It MUST try to setup security associations with its existing home agent. >> Section 4. > > Perhaps the previous point regarding interactions of MIPv6 clients with > IKE daemons that are part of an anycast domain belong here. You should > probably add some clear statements regarding the use of anycast > addresses for IKE daemon for MIPv6 clients. More precisely, what are the > conditions for a MIPv6 client to be configured with an anycast address > (or a name resolving to an anycast address) for the IKE daemon of its > HA. > > Can you tell me if I am wrong on this summary: you expect that a MIPv6 > client can be configured with an anycast address (or a name resolving > to an anycast address) for the IKE daemon of its HA if: > > - its local IKE Daemon support the Redirect > - it is redirected to a non-anycast unicast address when it connects the > first time > - it uses the address for all future connections to the remote IKE > daemon while it is registered with its HA. The re-direct should work irrespective of whether an anycast address is used. If anycast addresses are used, you don't have to necessarily configure the mobile node with the anycast address. The DNS lookup for the home agent can return an anycast address too. Vijay > > >> 5. > > I skipped it at the moment but will review in a future version of the > draft. > > >> 6. Security Considerations > > ok. > > > Cheers, > > a+ > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 17:55:34 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE2013A6956; Fri, 11 Jul 2008 17:55:34 -0700 (PDT) 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 61DC13A6956 for ; Fri, 11 Jul 2008 17:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 LeiRU5mTofz6 for ; Fri, 11 Jul 2008 17:55:32 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 72D943A6927 for ; Fri, 11 Jul 2008 17:55:32 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 3E46190018 for ; Fri, 11 Jul 2008 20:55:45 -0400 (EDT) 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 18002-14 for ; Fri, 11 Jul 2008 20:55:44 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Fri, 11 Jul 2008 20:55:44 -0400 (EDT) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jul 2008 20:55:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 11 Jul 2008 20:56:53 -0400 Message-ID: <4D35478224365146822AE9E3AD4A266603281342@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [MEXT] [mext] #11: De-registration when returning home[VijayDevarapalli ] Thread-Index: Acjh8V+MjNkSZIeVRpqs1hq3iTkwfwBgC3SQAAMZZiAAAQ0P0AABuQlgAAwKu7A= From: "Koodli, Rajeev" To: "Vijay Devarapalli" , "Pascal Thubert (pthubert)" , "Sri Gundavelli (sgundave)" X-OriginalArrivalTime: 12 Jul 2008 00:55:04.0033 (UTC) FILETIME=[EB8BED10:01C8E3B9] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home[VijayDevarapalli ] 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 > Lets say a home agent has a binding cache entry for a particular home > address and is defending the address. It starts seeing packets from the > home link with the home address as the source address. Lets further > assume that the home agent is the default router for the home link. Now > does the home agent consider this as some other mobile node using the > home address? Or does it consider it as the real mobile node using its > home address from the home link? [RKo:>] I don't know if there is text anywhere in 3775 to drop the packets if it sees packets with HoA as source IP address; I could be wrong. > > In the first case, the home agent would be dropping the packets. In the > second case, it may forward the packets. The behavior is undefined. So I > don't think we can claim that the mobile node will be able to send > packets before de-registering with the home agent. [RKo:>] This needs to be fixed I think. -Rajeev > > Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 18:02:51 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B99C3A6991; Fri, 11 Jul 2008 18:02:51 -0700 (PDT) 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 7A4123A6961 for ; Fri, 11 Jul 2008 18:02:50 -0700 (PDT) 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 TI1Jcad8F8fe for ; Fri, 11 Jul 2008 18:02:49 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 0C1913A6956 for ; Fri, 11 Jul 2008 18:02:48 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 11 Jul 2008 21:03:04 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] FW: I-DAction:draft-muhanna-mext-binding-revocation-02.txt Thread-Index: AcjjanvXqpJshcaWSjq9OnEFTtG85QAAAFmAABQcryA= References: <00be01c8e361$a995d180$5c0c7c0a@china.huawei.com><000601c8e369$530b9b80$5c0c7c0a@china.huawei.com><001201c8e36a$746e18b0$5c0c7c0a@china.huawei.com> From: "Vijay Devarapalli" To: "Ahmad Muhanna" , "Frank Xia" , Subject: Re: [MEXT] FW: I-DAction:draft-muhanna-mext-binding-revocation-02.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 Frank, Ahmad, > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Ahmad Muhanna > Sent: Friday, July 11, 2008 8:33 AM > To: Frank Xia; mext@ietf.org > Subject: Re: [MEXT] FW: > I-DAction:draft-muhanna-mext-binding-revocation-02.txt > > > Thanks Frank for pointing that, I believe the text should have been as > follows: > > "The protocol described here uses the same security association > between the MN and the HA or the MAG and the LMA that has been used > to exchange the corresponding MIPv6 or Proxy MIPv6 BU and > BA when the > session was established. If IPsec is used, the SPD of > this IPsec SA > MUST allow the MH type for the MGSM." I think this text is sufficient. There is nothing that needs to be said about RFC 4285 in the binding revocation document. Vijay > > We will fix it and if there is other nits like this will, we will take > care of it. Does that address your concern? > > Basically, the Binding Revocation messages should use the > same security > association that was used during the establishment of the session that > being revoked. > > Regards, > Ahmad > > > > -----Original Message----- > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > Sent: Friday, July 11, 2008 10:26 AM > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > Subject: Re: [MEXT] FW: I-D > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > Hi Ahmad > > > > I copy the security consideration from you draft. > > > > It says "The protocol described here uses the same security > > association > > between the MN and the HA or the MAG and the LMA that > has been used > > to exchange the corresponding MIPv6 or Proxy MIPv6 BU and > > BA when the > > session was established. This SPD of this IPsec SA MUST > > allow the MH > > type for the MGSM." > > > > How to secure signalling if there is no IPsec? > > > > I can't find the answer. > > > > BR > > Frank > > > > > > ----- Original Message ----- > > From: "Ahmad Muhanna" > > To: "Frank Xia" ; > > Sent: Friday, July 11, 2008 10:20 AM > > Subject: RE: [MEXT] FW: I-D > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > Hi Frank, > > > > I guess you need to answer that question. Right? > > I assume that what you mentioned about 3GPP2 and WiMAX is accurate. > > i.e., > > "by WiMAX and 3GPP2 in which IPsec SA is not mandatory." > > > > Regards, > > Ahmad > > > > > > > -----Original Message----- > > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > > Sent: Friday, July 11, 2008 10:18 AM > > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > > Subject: Re: [MEXT] FW: I-D > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > Hi Ahmad > > > > > > How to secure the signaling between HA and MN if there is > no IPsec? > > > > > > BR > > > Frank > > > > > > ----- Original Message ----- > > > From: "Ahmad Muhanna" > > > To: "Frank Xia" ; > > > Sent: Friday, July 11, 2008 10:12 AM > > > Subject: RE: [MEXT] FW: I-D > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > Hi Frank, > > > > > > I do not think there is a conflict here. > > > > > > In the case of WiMAX and 3GPP2, I assume that there will be > > no IPsec > > > SA between the HA and the MN, for example. > > > Therefore, there will be no SPD to worry about. Although > > the BRI/BRA > > > uses the MGSM which has a MH type that support IPsec (if IPsec is > > > used), but that is not applicable to the case you mentioned > > then there > > > is no problem. > > > > > > Does that make sense? > > > > > > Regards, > > > Ahmad > > > > > > > > > > -----Original Message----- > > > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > > > Sent: Friday, July 11, 2008 9:23 AM > > > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > > > Subject: Re: [MEXT] FW: I-D > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > Hi Ahmad > > > > > > > > IMHO, this document can't be directly used by WiMAX and > > > 3GPP2 in which > > > > IPsec SA is not mandatory. > > > > > > > > 3GPP2/WiMAX adopted RFC4285, and corresponding > documents, such as > > > > Diameter, RADIUS, now are explicitely supporting RFC4285. > > > > > > > > We discussed before. > > > > > > > > BR > > > > Frank > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Ahmad Muhanna" > > > > To: > > > > Sent: Friday, July 11, 2008 8:53 AM > > > > Subject: [MEXT] FW: I-D > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > > > > > > > Hello Folks, > > > > > > > > We updated the Binding Revocation draft according to the > > mext wg ml > > > > consensus by using the Mobile IPv6 Generic Signaling > > Message (MGSM) > > > > framework. Since the MGSM draft is still being revised, we > > > referenced > > > > the MGSM draft in all related sections of the Binding > Revocation > > > > draft. > > > > We probably will be able to optimize the draft a little > > > more in order > > > > to eliminate any duplication in some sections as soon as > > > the new MGSM > > > > draft revision becomes available. > > > > > > > > The only other change introduced in this revision is that we > > > > referenced the DSMIP6 draft and made it optional for the HA > > > to include > > > > the IPv4 home address in the BRI. > > > > > > > > With the aggressive schedule and 3GPP dependency on this > > draft, we > > > > appreciate your review, comment, and feedback. > > > > > > > > Thanks in advance! > > > > > > > > Regards, > > > > Ahmad > > > > > > > > -----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, July 11, 2008 8:45 AM > > > > To: i-d-announce@ietf.org > > > > Subject: I-D Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts > > > > directories. > > > > > > > > Title : Binding Revocation for IPv6 Mobility > > > > Author(s) : A. Muhanna, et al. > > > > Filename : draft-muhanna-mext-binding-revocation-02.txt > > > > Pages : 32 > > > > Date : 2008-07-11 > > > > > > > > This document defines the revocation semantics for > terminating a > > > > mobile node's mobility session and associated resources. These > > > > semantics are generic enough and can be used by mobility > > > entities in > > > > the case of Client Mobile IPv6 and its extensions. This > > mechanism > > > > allows the mobility entity which initiates the revocation > > > procedure to > > > > request its corresponding one to terminate either one, > > > multiple or all > > > > specified binding cache entries. > > > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding > > > -revocatio > > > > n-02.txt > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > Below is the data which will enable a MIME compliant > mail reader > > > > implementation to automatically retrieve the ASCII > version of the > > > > Internet-Draft. > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > ------------------ > > > > > > > > > > > > > _______________________________________________ > > > > > MEXT mailing list > > > > > MEXT@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 19:28:46 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EC4E3A6961; Fri, 11 Jul 2008 19:28:46 -0700 (PDT) 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 07C4B3A6961 for ; Fri, 11 Jul 2008 19:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umkNszqSyNxo for ; Fri, 11 Jul 2008 19:28:43 -0700 (PDT) Received: from nlpi087.prodigy.net (nlpi087.prodigy.net [207.115.36.103]) by core3.amsl.com (Postfix) with ESMTP id 9AB0A3A690D for ; Fri, 11 Jul 2008 19:28:43 -0700 (PDT) X-ORBL: [70.244.80.108] Received: from X24512z (ppp-70-244-80-108.dsl.rcsntx.swbell.net [70.244.80.108]) by nlpi087.prodigy.net (8.13.8 out.dk.spool/8.13.8) with ESMTP id m6C2Su3X004560; Fri, 11 Jul 2008 21:28:59 -0500 Message-ID: <002c01c8e3c7$0a73fdf0$0501a8c0@china.huawei.com> From: "Frank Xia" To: "Vijay Devarapalli" , "Ahmad Muhanna" , References: <00be01c8e361$a995d180$5c0c7c0a@china.huawei.com> <000601c8e369$530b9b80$5c0c7c0a@china.huawei.com> <001201c8e36a$746e18b0$5c0c7c0a@china.huawei.com> Date: Fri, 11 Jul 2008 21:28:56 -0500 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 Subject: Re: [MEXT] FW: I-DAction:draft-muhanna-mext-binding-revocation-02.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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Vijay We have jumped to the thread "Authentication option support in Binding Revocation". Anyway, this is not about how to word the text, but how to enable secured BRI/BRA in 3GPP2/WiMAX environment. If you like, you can try to answer my listed question in that thread. BR Frank ----- Original Message ----- From: "Vijay Devarapalli" To: "Ahmad Muhanna" ; "Frank Xia" ; Sent: Friday, July 11, 2008 8:03 PM Subject: RE: [MEXT] FW: I-DAction:draft-muhanna-mext-binding-revocation-02.txt Hello Frank, Ahmad, > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Ahmad Muhanna > Sent: Friday, July 11, 2008 8:33 AM > To: Frank Xia; mext@ietf.org > Subject: Re: [MEXT] FW: > I-DAction:draft-muhanna-mext-binding-revocation-02.txt > > > Thanks Frank for pointing that, I believe the text should have been as > follows: > > "The protocol described here uses the same security association > between the MN and the HA or the MAG and the LMA that has been used > to exchange the corresponding MIPv6 or Proxy MIPv6 BU and > BA when the > session was established. If IPsec is used, the SPD of > this IPsec SA > MUST allow the MH type for the MGSM." I think this text is sufficient. There is nothing that needs to be said about RFC 4285 in the binding revocation document. Vijay > > We will fix it and if there is other nits like this will, we will take > care of it. Does that address your concern? > > Basically, the Binding Revocation messages should use the > same security > association that was used during the establishment of the session that > being revoked. > > Regards, > Ahmad > > > > -----Original Message----- > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > Sent: Friday, July 11, 2008 10:26 AM > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > Subject: Re: [MEXT] FW: I-D > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > Hi Ahmad > > > > I copy the security consideration from you draft. > > > > It says "The protocol described here uses the same security > > association > > between the MN and the HA or the MAG and the LMA that > has been used > > to exchange the corresponding MIPv6 or Proxy MIPv6 BU and > > BA when the > > session was established. This SPD of this IPsec SA MUST > > allow the MH > > type for the MGSM." > > > > How to secure signalling if there is no IPsec? > > > > I can't find the answer. > > > > BR > > Frank > > > > > > ----- Original Message ----- > > From: "Ahmad Muhanna" > > To: "Frank Xia" ; > > Sent: Friday, July 11, 2008 10:20 AM > > Subject: RE: [MEXT] FW: I-D > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > Hi Frank, > > > > I guess you need to answer that question. Right? > > I assume that what you mentioned about 3GPP2 and WiMAX is accurate. > > i.e., > > "by WiMAX and 3GPP2 in which IPsec SA is not mandatory." > > > > Regards, > > Ahmad > > > > > > > -----Original Message----- > > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > > Sent: Friday, July 11, 2008 10:18 AM > > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > > Subject: Re: [MEXT] FW: I-D > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > Hi Ahmad > > > > > > How to secure the signaling between HA and MN if there is > no IPsec? > > > > > > BR > > > Frank > > > > > > ----- Original Message ----- > > > From: "Ahmad Muhanna" > > > To: "Frank Xia" ; > > > Sent: Friday, July 11, 2008 10:12 AM > > > Subject: RE: [MEXT] FW: I-D > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > Hi Frank, > > > > > > I do not think there is a conflict here. > > > > > > In the case of WiMAX and 3GPP2, I assume that there will be > > no IPsec > > > SA between the HA and the MN, for example. > > > Therefore, there will be no SPD to worry about. Although > > the BRI/BRA > > > uses the MGSM which has a MH type that support IPsec (if IPsec is > > > used), but that is not applicable to the case you mentioned > > then there > > > is no problem. > > > > > > Does that make sense? > > > > > > Regards, > > > Ahmad > > > > > > > > > > -----Original Message----- > > > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > > > Sent: Friday, July 11, 2008 9:23 AM > > > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > > > Subject: Re: [MEXT] FW: I-D > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > Hi Ahmad > > > > > > > > IMHO, this document can't be directly used by WiMAX and > > > 3GPP2 in which > > > > IPsec SA is not mandatory. > > > > > > > > 3GPP2/WiMAX adopted RFC4285, and corresponding > documents, such as > > > > Diameter, RADIUS, now are explicitely supporting RFC4285. > > > > > > > > We discussed before. > > > > > > > > BR > > > > Frank > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Ahmad Muhanna" > > > > To: > > > > Sent: Friday, July 11, 2008 8:53 AM > > > > Subject: [MEXT] FW: I-D > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > > > > > > > Hello Folks, > > > > > > > > We updated the Binding Revocation draft according to the > > mext wg ml > > > > consensus by using the Mobile IPv6 Generic Signaling > > Message (MGSM) > > > > framework. Since the MGSM draft is still being revised, we > > > referenced > > > > the MGSM draft in all related sections of the Binding > Revocation > > > > draft. > > > > We probably will be able to optimize the draft a little > > > more in order > > > > to eliminate any duplication in some sections as soon as > > > the new MGSM > > > > draft revision becomes available. > > > > > > > > The only other change introduced in this revision is that we > > > > referenced the DSMIP6 draft and made it optional for the HA > > > to include > > > > the IPv4 home address in the BRI. > > > > > > > > With the aggressive schedule and 3GPP dependency on this > > draft, we > > > > appreciate your review, comment, and feedback. > > > > > > > > Thanks in advance! > > > > > > > > Regards, > > > > Ahmad > > > > > > > > -----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, July 11, 2008 8:45 AM > > > > To: i-d-announce@ietf.org > > > > Subject: I-D Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts > > > > directories. > > > > > > > > Title : Binding Revocation for IPv6 Mobility > > > > Author(s) : A. Muhanna, et al. > > > > Filename : draft-muhanna-mext-binding-revocation-02.txt > > > > Pages : 32 > > > > Date : 2008-07-11 > > > > > > > > This document defines the revocation semantics for > terminating a > > > > mobile node's mobility session and associated resources. These > > > > semantics are generic enough and can be used by mobility > > > entities in > > > > the case of Client Mobile IPv6 and its extensions. This > > mechanism > > > > allows the mobility entity which initiates the revocation > > > procedure to > > > > request its corresponding one to terminate either one, > > > multiple or all > > > > specified binding cache entries. > > > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding > > > -revocatio > > > > n-02.txt > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > Below is the data which will enable a MIME compliant > mail reader > > > > implementation to automatically retrieve the ASCII > version of the > > > > Internet-Draft. > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > ------------------ > > > > > > > > > > > > > _______________________________________________ > > > > > MEXT mailing list > > > > > MEXT@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 20:00:28 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 525963A6B23; Fri, 11 Jul 2008 20:00:28 -0700 (PDT) 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 0FCAF3A6B23 for ; Fri, 11 Jul 2008 20:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hz2bs-FtJh5l for ; Fri, 11 Jul 2008 20:00:25 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id D845B3A6AFB for ; Fri, 11 Jul 2008 20:00:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,348,1212364800"; d="scan'208";a="65000477" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 12 Jul 2008 03:00:41 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6C30fKU030119; Fri, 11 Jul 2008 20:00:41 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m6C30fUd029347; Sat, 12 Jul 2008 03:00:41 GMT Date: Fri, 11 Jul 2008 20:00:40 -0700 (PDT) From: Sri Gundavelli To: Frank Xia In-Reply-To: <000a01c8e3a6$0e3cc8c0$5c0c7c0a@china.huawei.com> Message-ID: References: <000601c8e369$530b9b80$5c0c7c0a@china.huawei.com> <001201c8e36a$746e18b0$5c0c7c0a@china.huawei.com> <003901c8e36c$02c6b850$5c0c7c0a@china.huawei.com> <000e01c8e370$3f9f83c0$5c0c7c0a@china.huawei.com> <005601c8e37f$90fc3a60$5c0c7c0a@china.huawei.com> <008201c8e388$984a4240$5c0c7c0a@china.huawei.com> <00bc01c8e39e$b644f6d0$5c0c7c0a@china.huawei.com> <000a01c8e3a6$0e3cc8c0$5c0c7c0a@china.huawei.com> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3471; t=1215831641; x=1216695641; c=relaxed/simple; s=sjdkim1004; 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]=20Authentication=20option=20supp ort=20in=20Binding=20Revocation |Sender:=20; bh=9RyqKqJkCPkzID2lYgkkvJ0CHRkhpxWSp3JnnOA6snA=; b=oraFWtOBmuF0RRxkBOvAe3GdxmVokNPbe2b3FnhmOZ58cniNye8fxOuBq4 w5bMuRgfPwFxqWZo0T6iK1LOU3J5IaYBX7c1GL08p2aS/OY2HUJzeBvD/tlI VH0fJPOg/gepEF3rS+ilBIlgH6DK02VsFgTGs4+8xJSkBIqvAkOCI=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] Authentication option support in Binding Revocation 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Frank, Comments inline .. > 1) How are BRI/BRA messages secured when there is not IPsec SA between HA > and MN? > If its CMIP, the messages can be protected using 4285. If its PMIP, currently 4285 is not defined for PMIP. But, I assume some one will extend this to be used in PMIP, if required. Alper ? > 2)If authentication options defined in RFC4285 are used, which option > should be used? MN-HA or MN-AAA? > If there is a shared key between the mobile node and the home agent, MN-HA Authentication option can be used. If there is a shared key between the mobile node and the AAA, MN-AAA authentication option can be used. But you bring a good point, these options are defined to be carried in BU/BA. We need to allow these options to be carried in Generic Notification messages. > 3)If BRI processing failure is because of failed authentication, how > does the MN inform HA? > Revocation message is a particular type of event carried in a GNM message. If the message fails authentication, the draft should deal with it properly. We need to address this issue in GNM. This is not specific to revocation. Lastly, you are challenging both the drafts and this is good. We will fix this and ensure the Generic Notification message can properly address these issues. Lets discuss in Dublin IETF. Regards Sri On Fri, 11 Jul 2008, Frank Xia wrote: > Hi Ahmad > > All the questions are explicit to the draft. > I encourage you to face the questions directly. > > If authentication options are required to add > in the BRI/BRA message, IMO, this is not related to > MGSM draft. > > I will feel confortable only after I have an satisfactory answer. > BR > Frank > > > ----- Original Message ----- From: "Ahmad Muhanna" > To: "Frank Xia" ; > Sent: Friday, July 11, 2008 5:19 PM > Subject: Authentication option support in Binding Revocation > > > > Hi Frank, > > It was a comment on that topic rather than a request, but that is fine:) > > Please note that I changed the subject by removing the word "draft" > because this discussion is supposed to be generic on the applicability > of Auth protocol to secure Binding Revocation signaling not the current > Binding Revocation draft. The reason as I said before, the mext wg > consensus was to use MGSM framework for BRI and BRA. > > Therefore, if the discussion is on the draft, then the discussion should > be focused on the need to secure MGSM signaling using the authentication > protocol. > > Regards, > Ahmad > > >> -----Original Message----- >> From: Frank Xia [mailto:xiayangsong@huawei.com] Sent: Friday, July 11, >> 2008 4:40 PM >> To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org >> Subject: Authentication option support in Binding Revocation draft >> >> Hi Ahmad >> >> Upon your request, I initials this thread. >> >> 1) How are BRI/BRA messages secured when there is not IPsec SA between HA >> and MN? >> >> 2)If authentication options defined in RFC4285 are used, which option >> should be used? MN-HA or MN-AAA? >> >> 3)If BRI processing failure is because of failed authentication, how >> does the MN inform HA? >> >> BR >> Frank >> >> >> > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 20:25:26 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E55E28C10B; Fri, 11 Jul 2008 20:25:26 -0700 (PDT) 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 29D7B28C107 for ; Fri, 11 Jul 2008 20:25:25 -0700 (PDT) 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.001, 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 cwU4R-f0r169 for ; Fri, 11 Jul 2008 20:25:24 -0700 (PDT) Received: from nlpi087.prodigy.net (nlpi087.prodigy.net [207.115.36.103]) by core3.amsl.com (Postfix) with ESMTP id 1F4A728C0F3 for ; Fri, 11 Jul 2008 20:25:24 -0700 (PDT) X-ORBL: [70.244.80.108] Received: from X24512z (ppp-70-244-80-108.dsl.rcsntx.swbell.net [70.244.80.108]) by nlpi087.prodigy.net (8.13.8 out.dk.spool/8.13.8) with ESMTP id m6C3PfY0015813; Fri, 11 Jul 2008 22:25:42 -0500 Message-ID: <004601c8e3ce$f6935d00$0501a8c0@china.huawei.com> From: "Frank Xia" To: "Sri Gundavelli" References: <000601c8e369$530b9b80$5c0c7c0a@china.huawei.com> <001201c8e36a$746e18b0$5c0c7c0a@china.huawei.com> <003901c8e36c$02c6b850$5c0c7c0a@china.huawei.com> <000e01c8e370$3f9f83c0$5c0c7c0a@china.huawei.com> <005601c8e37f$90fc3a60$5c0c7c0a@china.huawei.com> <008201c8e388$984a4240$5c0c7c0a@china.huawei.com> <00bc01c8e39e$b644f6d0$5c0c7c0a@china.huawei.com> <000a01c8e3a6$0e3cc8c0$5c0c7c0a@china.huawei.com> Date: Fri, 11 Jul 2008 22:25:41 -0500 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 Cc: mext@ietf.org Subject: Re: [MEXT] Authentication option support in Binding Revocation 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Sri I like the straight reply, and it is fine with me. Please see some other inline comments. BR Frank ----- Original Message ----- From: "Sri Gundavelli" To: "Frank Xia" Cc: "Ahmad Muhanna" ; Sent: Friday, July 11, 2008 10:00 PM Subject: Re: [MEXT] Authentication option support in Binding Revocation > > Hi Frank, > > Comments inline .. > > > >> 1) How are BRI/BRA messages secured when there is not IPsec SA between > HA >> and MN? >> > > If its CMIP, the messages can be protected using 4285. > > If its PMIP, currently 4285 is not defined for PMIP. But, I assume > some one will extend this to be used in PMIP, if required. Alper ? > > > >> 2)If authentication options defined in RFC4285 are used, which option >> should be used? MN-HA or MN-AAA? >> > > If there is a shared key between the mobile node and the home agent, > MN-HA Authentication option can be used. > > If there is a shared key between the mobile node and the AAA, > MN-AAA authentication option can be used. > > But you bring a good point, these options are defined to be carried > in BU/BA. We need to allow these options to be carried in Generic > Notification messages. Frank=>Yes. We should extend the semantics of these options, and let it be used in these cases. > > >> 3)If BRI processing failure is because of failed authentication, how >> does the MN inform HA? >> > > Revocation message is a particular type of event carried in a GNM message. > If the message fails authentication, the draft should deal with it > properly. We need to address this issue in GNM. This is not specific > to revocation. Frank=>Sure . Just I said before, some new status codes should be defined except the following in Revocation draft: 0 success. 1 partial success. 2 Binding Does NOT Exist. 3 Global Revocation NOT Authorized. 4 CAN NOT Identify Binding. > > Lastly, you are challenging both the drafts and this is good. We will > fix this and ensure the Generic Notification message can properly > address these issues. Lets discuss in Dublin IETF. Frank=>Thank you! > > Regards > Sri > > > > On Fri, 11 Jul 2008, Frank Xia wrote: > >> Hi Ahmad >> >> All the questions are explicit to the draft. >> I encourage you to face the questions directly. >> >> If authentication options are required to add >> in the BRI/BRA message, IMO, this is not related to >> MGSM draft. >> >> I will feel confortable only after I have an satisfactory answer. BR >> Frank >> >> >> ----- Original Message ----- From: "Ahmad Muhanna" >> To: "Frank Xia" ; >> Sent: Friday, July 11, 2008 5:19 PM >> Subject: Authentication option support in Binding Revocation >> >> >> >> Hi Frank, >> >> It was a comment on that topic rather than a request, but that is fine:) >> >> Please note that I changed the subject by removing the word "draft" >> because this discussion is supposed to be generic on the applicability >> of Auth protocol to secure Binding Revocation signaling not the current >> Binding Revocation draft. The reason as I said before, the mext wg >> consensus was to use MGSM framework for BRI and BRA. >> >> Therefore, if the discussion is on the draft, then the discussion should >> be focused on the need to secure MGSM signaling using the authentication >> protocol. >> >> Regards, >> Ahmad >> >>> -----Original Message----- >>> From: Frank Xia [mailto:xiayangsong@huawei.com] Sent: Friday, July 11, >>> 2008 4:40 PM >>> To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org >>> Subject: Authentication option support in Binding Revocation draft >>> >>> Hi Ahmad >>> >>> Upon your request, I initials this thread. >>> >>> 1) How are BRI/BRA messages secured when there is not IPsec SA between >>> HA >>> and MN? >>> >>> 2)If authentication options defined in RFC4285 are used, which option >>> should be used? MN-HA or MN-AAA? >>> >>> 3)If BRI processing failure is because of failed authentication, how >>> does the MN inform HA? >>> >>> BR >>> Frank >>> >>> >>> >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 21:16:53 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C840A3A6B3A; Fri, 11 Jul 2008 21:16:53 -0700 (PDT) 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 2DF053A6B3A for ; Fri, 11 Jul 2008 21:16:53 -0700 (PDT) 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 QH+CZqT-qdfI for ; Fri, 11 Jul 2008 21:16:51 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id A11BD3A6B37 for ; Fri, 11 Jul 2008 21:16:51 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 12 Jul 2008 00:17:08 -0400 Message-ID: In-Reply-To: <002c01c8e3c7$0a73fdf0$0501a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] FW: I-DAction:draft-muhanna-mext-binding-revocation-02.txt Thread-Index: AcjjxxB8lDnrdFVySl+a9thuCR2mYgADkkGw References: <00be01c8e361$a995d180$5c0c7c0a@china.huawei.com> <000601c8e369$530b9b80$5c0c7c0a@china.huawei.com> <001201c8e36a$746e18b0$5c0c7c0a@china.huawei.com> <002c01c8e3c7$0a73fdf0$0501a8c0@china.huawei.com> From: "Vijay Devarapalli" To: "Frank Xia" , "Ahmad Muhanna" , Subject: Re: [MEXT] FW: I-DAction:draft-muhanna-mext-binding-revocation-02.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 > We have jumped to the thread > "Authentication option support in Binding Revocation". > > Anyway, this is not about how to word the text, but > how to enable secured BRI/BRA in 3GPP2/WiMAX > environment. Just use the MN-HA authentication option. However, WiMAX or 3GPP2 would have to specify how to calculate the "Authentication Data" in the MN-HA authentication option for the Generic Signaling Message. RFC 4285 only specifies how the MN-HA authentication option is used for the Binding Update and Binding Ack messages. Note that this is still not relevant to the Binding Revocation messages. Vijay > > If you like, you can try to answer my listed question > in that thread. > > BR > Frank > > > ----- Original Message ----- > From: "Vijay Devarapalli" > To: "Ahmad Muhanna" ; "Frank Xia" > ; > Sent: Friday, July 11, 2008 8:03 PM > Subject: RE: [MEXT] FW: > I-DAction:draft-muhanna-mext-binding-revocation-02.txt > > > Hello Frank, Ahmad, > > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > Behalf Of Ahmad Muhanna > > Sent: Friday, July 11, 2008 8:33 AM > > To: Frank Xia; mext@ietf.org > > Subject: Re: [MEXT] FW: > > I-DAction:draft-muhanna-mext-binding-revocation-02.txt > > > > > > Thanks Frank for pointing that, I believe the text should > have been as > > follows: > > > > "The protocol described here uses the same security association > > between the MN and the HA or the MAG and the LMA that > has been used > > to exchange the corresponding MIPv6 or Proxy MIPv6 BU and > > BA when the > > session was established. If IPsec is used, the SPD of > > this IPsec SA > > MUST allow the MH type for the MGSM." > > I think this text is sufficient. There is nothing that needs > to be said > about RFC 4285 in the binding revocation document. > > Vijay > > > > > We will fix it and if there is other nits like this will, > we will take > > care of it. Does that address your concern? > > > > Basically, the Binding Revocation messages should use the > > same security > > association that was used during the establishment of the > session that > > being revoked. > > > > Regards, > > Ahmad > > > > > > > -----Original Message----- > > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > > Sent: Friday, July 11, 2008 10:26 AM > > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > > Subject: Re: [MEXT] FW: I-D > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > Hi Ahmad > > > > > > I copy the security consideration from you draft. > > > > > > It says "The protocol described here uses the same security > > > association > > > between the MN and the HA or the MAG and the LMA that > > has been used > > > to exchange the corresponding MIPv6 or Proxy MIPv6 BU and > > > BA when the > > > session was established. This SPD of this IPsec SA MUST > > > allow the MH > > > type for the MGSM." > > > > > > How to secure signalling if there is no IPsec? > > > > > > I can't find the answer. > > > > > > BR > > > Frank > > > > > > > > > ----- Original Message ----- > > > From: "Ahmad Muhanna" > > > To: "Frank Xia" ; > > > Sent: Friday, July 11, 2008 10:20 AM > > > Subject: RE: [MEXT] FW: I-D > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > Hi Frank, > > > > > > I guess you need to answer that question. Right? > > > I assume that what you mentioned about 3GPP2 and WiMAX is > accurate. > > > i.e., > > > "by WiMAX and 3GPP2 in which IPsec SA is not mandatory." > > > > > > Regards, > > > Ahmad > > > > > > > > > > -----Original Message----- > > > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > > > Sent: Friday, July 11, 2008 10:18 AM > > > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > > > Subject: Re: [MEXT] FW: I-D > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > Hi Ahmad > > > > > > > > How to secure the signaling between HA and MN if there is > > no IPsec? > > > > > > > > BR > > > > Frank > > > > > > > > ----- Original Message ----- > > > > From: "Ahmad Muhanna" > > > > To: "Frank Xia" ; > > > > Sent: Friday, July 11, 2008 10:12 AM > > > > Subject: RE: [MEXT] FW: I-D > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > > > Hi Frank, > > > > > > > > I do not think there is a conflict here. > > > > > > > > In the case of WiMAX and 3GPP2, I assume that there will be > > > no IPsec > > > > SA between the HA and the MN, for example. > > > > Therefore, there will be no SPD to worry about. Although > > > the BRI/BRA > > > > uses the MGSM which has a MH type that support IPsec > (if IPsec is > > > > used), but that is not applicable to the case you mentioned > > > then there > > > > is no problem. > > > > > > > > Does that make sense? > > > > > > > > Regards, > > > > Ahmad > > > > > > > > > > > > > -----Original Message----- > > > > > From: Frank Xia [mailto:xiayangsong@huawei.com] > > > > > Sent: Friday, July 11, 2008 9:23 AM > > > > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > > > > > Subject: Re: [MEXT] FW: I-D > > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > Hi Ahmad > > > > > > > > > > IMHO, this document can't be directly used by WiMAX and > > > > 3GPP2 in which > > > > > IPsec SA is not mandatory. > > > > > > > > > > 3GPP2/WiMAX adopted RFC4285, and corresponding > > documents, such as > > > > > Diameter, RADIUS, now are explicitely supporting RFC4285. > > > > > > > > > > We discussed before. > > > > > > > > > > BR > > > > > Frank > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Ahmad Muhanna" > > > > > To: > > > > > Sent: Friday, July 11, 2008 8:53 AM > > > > > Subject: [MEXT] FW: I-D > > > > > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > > > > > > > > > > > Hello Folks, > > > > > > > > > > We updated the Binding Revocation draft according to the > > > mext wg ml > > > > > consensus by using the Mobile IPv6 Generic Signaling > > > Message (MGSM) > > > > > framework. Since the MGSM draft is still being revised, we > > > > referenced > > > > > the MGSM draft in all related sections of the Binding > > Revocation > > > > > draft. > > > > > We probably will be able to optimize the draft a little > > > > more in order > > > > > to eliminate any duplication in some sections as soon as > > > > the new MGSM > > > > > draft revision becomes available. > > > > > > > > > > The only other change introduced in this revision is that we > > > > > referenced the DSMIP6 draft and made it optional for the HA > > > > to include > > > > > the IPv4 home address in the BRI. > > > > > > > > > > With the aggressive schedule and 3GPP dependency on this > > > draft, we > > > > > appreciate your review, comment, and feedback. > > > > > > > > > > Thanks in advance! > > > > > > > > > > Regards, > > > > > Ahmad > > > > > > > > > > -----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, July 11, 2008 8:45 AM > > > > > To: i-d-announce@ietf.org > > > > > Subject: I-D > Action:draft-muhanna-mext-binding-revocation-02.txt > > > > > > > > > > A New Internet-Draft is available from the on-line > > > Internet-Drafts > > > > > directories. > > > > > > > > > > Title : Binding Revocation for IPv6 Mobility > > > > > Author(s) : A. Muhanna, et al. > > > > > Filename : draft-muhanna-mext-binding-revocation-02.txt > > > > > Pages : 32 > > > > > Date : 2008-07-11 > > > > > > > > > > This document defines the revocation semantics for > > terminating a > > > > > mobile node's mobility session and associated > resources. These > > > > > semantics are generic enough and can be used by mobility > > > > entities in > > > > > the case of Client Mobile IPv6 and its extensions. This > > > mechanism > > > > > allows the mobility entity which initiates the revocation > > > > procedure to > > > > > request its corresponding one to terminate either one, > > > > multiple or all > > > > > specified binding cache entries. > > > > > > > > > > A URL for this Internet-Draft is: > > > > > http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding > > > > -revocatio > > > > > n-02.txt > > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > > Below is the data which will enable a MIME compliant > > mail reader > > > > > implementation to automatically retrieve the ASCII > > version of the > > > > > Internet-Draft. > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > ------------------ > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > MEXT mailing list > > > > > > MEXT@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 21:23:48 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 094C33A6B31; Fri, 11 Jul 2008 21:23:48 -0700 (PDT) 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 5F2FB3A6B31 for ; Fri, 11 Jul 2008 21:23:46 -0700 (PDT) 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 QpV-Di7BgKCu for ; Fri, 11 Jul 2008 21:23:45 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 7AFA43A67D6 for ; Fri, 11 Jul 2008 21:23:45 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 12 Jul 2008 00:24:03 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Authentication option support in Binding Revocation Thread-Index: Acjjy4AUqtD1A+yKQ5qO5PriyNmT6AAC0PuA References: <000601c8e369$530b9b80$5c0c7c0a@china.huawei.com><001201c8e36a$746e18b0$5c0c7c0a@china.huawei.com><003901c8e36c$02c6b850$5c0c7c0a@china.huawei.com><000e01c8e370$3f9f83c0$5c0c7c0a@china.huawei.com><005601c8e37f$90fc3a60$5c0c7c0a@china.huawei.com><008201c8e388$984a4240$5c0c7c0a@china.huawei.com><00bc01c8e39e$b644f6d0$5c0c7c0a@china.huawei.com><000a01c8e3a6$0e3cc8c0$5c0c7c0a@china.huawei.com> From: "Vijay Devarapalli" To: "Sri Gundavelli" , "Frank Xia" Cc: mext@ietf.org Subject: Re: [MEXT] Authentication option support in Binding Revocation 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 hadn't seen Sri's response.... > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Sri Gundavelli > Sent: Friday, July 11, 2008 8:01 PM > To: Frank Xia > Cc: mext@ietf.org > Subject: Re: [MEXT] Authentication option support in Binding > Revocation > If there is a shared key between the mobile node and the home agent, > MN-HA Authentication option can be used. > > If there is a shared key between the mobile node and the AAA, > MN-AAA authentication option can be used. > > But you bring a good point, these options are defined to be carried > in BU/BA. We need to allow these options to be carried in Generic > Notification messages. Specifying the use of MN-HA authentication option with the Generic Signaling Message sounds good to me. I doubt if the MN-AAA authentication option will ever be used with the Generic Signaling Message, though. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 11 21:28:59 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 083BF3A6B31; Fri, 11 Jul 2008 21:28:59 -0700 (PDT) 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 44F9F3A6B33 for ; Fri, 11 Jul 2008 21:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.504 X-Spam-Level: X-Spam-Status: No, score=-6.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0zszy8mE3kl for ; Fri, 11 Jul 2008 21:28:56 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 855CC3A6983 for ; Fri, 11 Jul 2008 21:28:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,348,1212364800"; d="scan'208";a="125682484" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 12 Jul 2008 04:29:14 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m6C4TD58004382; Fri, 11 Jul 2008 21:29:13 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6C4TDWd026126; Sat, 12 Jul 2008 04:29:13 GMT Date: Fri, 11 Jul 2008 21:29:13 -0700 (PDT) From: Sri Gundavelli To: Vijay Devarapalli In-Reply-To: Message-ID: References: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=527; t=1215836953; x=1216700953; c=relaxed/simple; s=sjdkim4002; 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]=20Authentication=20option=20supp ort=20in=20Binding=20Revocation |Sender:=20; bh=QrS4wMrdm+AXE8uFqbolH2NHYJVyfY2hlEFsspyM7ak=; b=ByT6ZhptwZ8JtGbYxS6Lcmd45BnjndvmQnddtYMwIGBDxXO6Ygzve2Q3VC EHeQAyCPbIha8F0EsbJCW/c1QUjeBSf9fowuvyHl8Byr/6OHXyt1hqxXSlLz ovWpxWXcaQ; 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] Authentication option support in Binding Revocation 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > > Specifying the use of MN-HA authentication option with the Generic > Signaling Message sounds good to me. I doubt if the MN-AAA > authentication option will ever be used with the Generic Signaling > Message, though. > Vijay, I think we can redefine these options (one or both) as valid options to be carried in Generic Notification messages. We can add few lines on this validity. Brian ? We can address Frank's issues in this draft and revocation or other clients dont have to deal with this. Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Jul 12 03:22:17 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B7873A6B88; Sat, 12 Jul 2008 03:22:17 -0700 (PDT) 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 4A4543A68B2; Sat, 12 Jul 2008 03:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 nwRtcQzoSiTF; Sat, 12 Jul 2008 03:22:15 -0700 (PDT) Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id BBBA93A68A6; Sat, 12 Jul 2008 03:22:14 -0700 (PDT) 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 1KHcFF-0000Nc-Do; Sat, 12 Jul 2008 12:22:25 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: "Vijay Devarapalli" References: <87r6c2r3bu.fsf@natisbad.org> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:080712:dvijay@gmail.com::RoGN7nN3vk0ntLYA:009lJ X-Hashcash: 1:20:080712:mext@ietf.org::gH98/IrUqET2G+6P:00003gtX X-Hashcash: 1:20:080712:ipsec@ietf.org::mr4jWbda/ykmogwe:0006t6d Date: Sat, 12 Jul 2008 12:21:47 +0200 In-Reply-To: (Vijay Devarapalli's message of "Fri, 11 Jul 2008 16:29:22 -0700") Message-ID: <87tzevbdxg.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: ipsec@ietf.org, mext@ietf.org Subject: Re: [MEXT] [IPsec] Redirect mechanism for IKEv2 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="===============1808747132==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1808747132== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Transfer-Encoding: quoted-printable Hi Vijay, "Vijay Devarapalli" writes: > I apologize for the delay in responding to your email. no problem. Some responses below. >> To summarize most of my comments, the draft makes the redirect mechanism >> happen at the IKE level and expects that it has no impact on the work of >> the MIPv6 part. In practice, the address of the Home Agent being also >> the address of the IKE GW and the IPsec SA (even if the negotiation >> could be modified to be for different addresses regarding the IPsec SA >> and the IKE GW), there is a need for synchronization between IKE and >> MIPv6. IMHO, this is missing in the draft and should be stated. > > I am not sure if this document should talk about the interactions > between the MIPv6 and IKEv2 processes in a particular implementation. If it does not, everything is left as an implementation issue, which prevents IKE deamon from vendor "A" to be used out of the box with MIPv6 daemon from vendor "B" on a given platform. My question would be: if someone implements the mechanism proposed by the draft in an IKE daemon, will that work out of the box when the IKE daemon is used on a MN. AFAICT, no.=20 IMHO, if it is time consuming to understand the precise associated needs for interaction or to address them in the draft, it should be stated in the document so noone thinks it will work without more work. > I have seen other emails from you on this subject, especially the > interactions between IKEv2 and MIPv6 as described in RFC 4877 and RFC > 5026. Perhaps, as you suggest, it might be a good idea to write a > separate document that describes how these two protocols can interact > with each other.=20 Yes, now that there is some implementation feedback on the topic, it would be good to: 1) consider them 2) address them The difficulties are that the subject is both IPsec/IKE and MIPv6-related which makes it a less obvious item on ipsec or mext ML than a new functionality for one of the protocol. > Personally, it is not clear to me on what sort of > details you are looking for. I think many of the details you are > looking for is implementation specific. The ones described and addressed in draft-sugimoto-mip6-pfkey-migrate and draft-qi-mip6-ikev2-interfacing, to start with. Simply put: don't expect MIPv6+IKE to work (bootstrapping, movement) without what is in the drafts. >>> The IKEv2 exchange precedes the exchange of Mobile IPv6 signaling >>> messages. >> >> In practice, AFAICT, the IKE exchange is *triggered* by the emission of >> the BU. It seems that RFC 4877 has started to take a different direction >> where IKE is used to configure MIPv6, but the details are missing. > > When the mobile node boots up and figures that it needs to configure a > home address, it can trigger an IKEv2 exchange with the home agent. > Nothing needs to be said. This would be implementation specific on the > mobile node. Precisely and in the order of the sentence: =2D I agree that a MN will manage to know that it needs a Home Addres =2D I don't see *how* it will trigger an IKEv2 exchange =2D I don't see *how* it will retrieve the address gathered during the IKEv2 exchange Again, at the end of the day, if 'A' develops a MIPv6 Daemon, and 'B' develops an IKEv2 daemon, there is no way you can even start to make them interoperate WRT HoA assignement *IF* they have not work together to define a *custom* interface. What do you think? >>> Therefore the mechanism described in this document can be also be >>> used by a Mobile IPv6 home agent to re-direct a mobile node to >>> another home agent. >> >> Collusion between Key Manager and HA operation. > > Yes. So? I don't follow you: are you considering that MIPv6 and IKEv2 operations must be implemented in a single application in all cases? Hence, the lack of interface because you consider that as internal plumbering?=20 >>> There is a Home Agent Switch mechanism available for re-directing a >>> mobile node to another home agent, described in [5]. The Home Agent >>> Switch mechanism can only be used after the binding cache had been >>> created at the home agent for the mobile node. The disadvantage with >>> this is that quite a bit of state is created on the home agent before >>> the mobile node can be re-directed to another home agent. The >>> mechanism described in this document can be used for re-directing a >>> mobile node before any state is created on the home agent. >> >> IMHO, there is a difference between IKE and MIPv6 operations: >> >> 1) A Home Agent is overloaded and start redirecting MN to another HA: >> for instance, it is already using all its available upload bandwidth >> for registered MN (which is unrelated to IPsec/IKE). >> 2) There are too many IKE peers connecting at the same time on an IKE >> daemon (for the setup of IPsec SA between MN and HA or common >> clients) and the IKE daemon starts redirecting clients to another IKE >> daemon. >> >> What I mean is that, AFAICT, the two mechanism solve different problems, >> through different channels. > > Do you see the need for any changes in the draft for this? perhaps adding some use cases by discussing how the IKE could monitor some values (number of IKE peer, upload bandwidth consumed by MN, ...) or how you expect an administrator would use the proposed solution: what specific need does the solution address? >> IMHO, the last sentence simply does not cover the possible associated >> issues and how things should be done, *how* the associated users (IPsec >> stack, MIPv6 module) are notified (on both sides). I am considering that >> MIPv6 is used to cover all cases. >> >> - address of the IKE GW on the remote side >> - the address of the HA used by the client >> - the remote address of currently negotiated transport mode SA >> protecting MIPv6 signaling >> - endpoints of negotiated tunnel mode SA protecting data traffic if any >> >> I imagine that they will be set to the new IP. AFAICT, if the >> negotiation was triggered by a BU, there will be a mismatch between the >> triggering packet and the new destination. > > It does not have to be triggered by the Binding Update. The > bootstrapping procedure on a Mobile IPv6 mobile node could be > triggered for some other reason. Can you elaborate on that ? >> How does the MN knows the address is anycast? > > The MIPv6 home agents anycast address is well known. See > http://www.iana.org/assignments/ipv6-anycast-addresses. But I > understand what you mean. I modified the paragraph as follows. > > When this mechanism is used with Mobile IPv6, a mobile node's > security associations with its home agent may expire while it still > has a valid binding cache entry at the home agent. In this case, the > mobile node MUST NOT use the original home agent address as the > destination address in the IKE_SA_INIT exchange to setup new security > associations. It MUST try to setup security associations with its > existing home agent. ack. Thanks. Cheers, a+ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIeIXBAlWVfAR6UCYRAtOPAKCI3rGJ9+Grw+U7CtWcMRDo9Qg4QQCcCU7a l6wTOyt30Rlhdtvnl2u9vIM= =KJ9q -----END PGP SIGNATURE----- --=-=-=-- --===============1808747132== 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 --===============1808747132==-- From mext-bounces@ietf.org Sat Jul 12 05:05:16 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 484E43A6B63; Sat, 12 Jul 2008 05:05:16 -0700 (PDT) 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 70C9A3A6B63 for ; Sat, 12 Jul 2008 05:05:15 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQ-3bD4CXqXs for ; Sat, 12 Jul 2008 05:05:14 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 651FA3A6A07 for ; Sat, 12 Jul 2008 05:05:14 -0700 (PDT) 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 m6CC3Nj06414; Sat, 12 Jul 2008 12:03:23 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 12 Jul 2008 07:05:05 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Authentication option support in Binding Revocation Thread-Index: Acjjy4AUqtD1A+yKQ5qO5PriyNmT6AAC0PuAAA/2l3A= References: <000601c8e369$530b9b80$5c0c7c0a@china.huawei.com><001201c8e36a$746e18b0$5c0c7c0a@china.huawei.com><003901c8e36c$02c6b850$5c0c7c0a@china.huawei.com><000e01c8e370$3f9f83c0$5c0c7c0a@china.huawei.com><005601c8e37f$90fc3a60$5c0c7c0a@china.huawei.com><008201c8e388$984a4240$5c0c7c0a@china.huawei.com><00bc01c8e39e$b644f6d0$5c0c7c0a@china.huawei.com><000a01c8e3a6$0e3cc8c0$5c0c7c0a@china.huawei.com> From: "Ahmad Muhanna" To: "Vijay Devarapalli" , "Sri Gundavelli" , "Frank Xia" Cc: mext@ietf.org Subject: Re: [MEXT] Authentication option support in Binding Revocation 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, > > Subject: Re: [MEXT] Authentication option support in Binding > > Revocation > > > If there is a shared key between the mobile node and the > home agent, > > MN-HA Authentication option can be used. > > > > If there is a shared key between the mobile node and the > AAA, MN-AAA > > authentication option can be used. > > > > But you bring a good point, these options are defined to be > carried in > > BU/BA. We need to allow these options to be carried in Generic > > Notification messages. > > Specifying the use of MN-HA authentication option with the > Generic Signaling Message sounds good to me. I doubt if the > MN-AAA authentication option will ever be used with the > Generic Signaling Message, though. [Ahmad] I agree. If auth protocol to be used to authenticate the MIP6 Generic Signaling Message, then it has to be the MN-HA AE in the case of Client MIP6. MN-AAA AE is used during the initial registration to help in bootstrapping MN-HA SA if it is needed. After the MIP6 session is established, it is assumed that MN-HA SA has been established. Therefore, MN-AAA AE has no value in this scenario. Not only that, but it does not make sense either. > > Vijay > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Jul 12 05:19:42 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EE113A68AC; Sat, 12 Jul 2008 05:19:42 -0700 (PDT) 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 EAA963A6A07 for ; Sat, 12 Jul 2008 05:19:40 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjRhQSM6Cx7R for ; Sat, 12 Jul 2008 05:19:40 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id DEE623A67A6 for ; Sat, 12 Jul 2008 05:19:39 -0700 (PDT) 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 m6CCJnw12474; Sat, 12 Jul 2008 12:19:49 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 12 Jul 2008 07:19:47 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Authentication option support in Binding Revocation Thread-Index: Acjjy4AUqtD1A+yKQ5qO5PriyNmT6AAC0PuAAA/2l3AAAFNH4A== References: <000601c8e369$530b9b80$5c0c7c0a@china.huawei.com><001201c8e36a$746e18b0$5c0c7c0a@china.huawei.com><003901c8e36c$02c6b850$5c0c7c0a@china.huawei.com><000e01c8e370$3f9f83c0$5c0c7c0a@china.huawei.com><005601c8e37f$90fc3a60$5c0c7c0a@china.huawei.com><008201c8e388$984a4240$5c0c7c0a@china.huawei.com><00bc01c8e39e$b644f6d0$5c0c7c0a@china.huawei.com><000a01c8e3a6$0e3cc8c0$5c0c7c0a@china.huawei.com> From: "Ahmad Muhanna" To: "Ahmad Muhanna" , "Vijay Devarapalli" , "Sri Gundavelli" , "Frank Xia" Cc: Basavaraj Patil , mext@ietf.org Subject: Re: [MEXT] Authentication option support in Binding Revocation 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 to add one point to my earlier reply. My understanding that Mobile IPv6 Generic Signaling Message (MGSM) and Binding Revocation are proposed as standard track document. Therefore, before we start talking about adding Auth protocol support to MGSM and consequently Binding Revocation, we need to do something about RFC4285. This RFC is still an Informational one and my understanding a standard track doc can not reference an Informational one. Any one knows what is the latest on RFC4285? Raj or Kuntal? Regards, Ahmad > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Muhanna, Ahmad (RICH1:2H10) > Sent: Saturday, July 12, 2008 7:05 AM > To: Vijay Devarapalli; Sri Gundavelli; Frank Xia > Cc: mext@ietf.org > Subject: Re: [MEXT] Authentication option support in Binding > Revocation > > Hi Vijay, > > > > Subject: Re: [MEXT] Authentication option support in Binding > > > Revocation > > > > > If there is a shared key between the mobile node and the > > home agent, > > > MN-HA Authentication option can be used. > > > > > > If there is a shared key between the mobile node and the > > AAA, MN-AAA > > > authentication option can be used. > > > > > > But you bring a good point, these options are defined to be > > carried in > > > BU/BA. We need to allow these options to be carried in Generic > > > Notification messages. > > > > Specifying the use of MN-HA authentication option with the Generic > > Signaling Message sounds good to me. I doubt if the MN-AAA > > authentication option will ever be used with the Generic Signaling > > Message, though. > > [Ahmad] > I agree. > If auth protocol to be used to authenticate the MIP6 Generic > Signaling Message, then it has to be the MN-HA AE in the case > of Client MIP6. > MN-AAA AE is used during the initial registration to help in > bootstrapping MN-HA SA if it is needed. After the MIP6 > session is established, it is assumed that MN-HA SA has been > established. > Therefore, MN-AAA AE has no value in this scenario. Not only > that, but it does not make sense either. > > > > > > Vijay > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Jul 12 09:58:21 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 307443A6ABC; Sat, 12 Jul 2008 09:58:21 -0700 (PDT) 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 AAB413A6ABC for ; Sat, 12 Jul 2008 09:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, 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 YHIBeDCK7sES for ; Sat, 12 Jul 2008 09:58:18 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 9AFD23A6A85 for ; Sat, 12 Jul 2008 09:58:18 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 12 Jul 2008 12:59:10 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Authentication option support in Binding Revocation Thread-Index: Acjjy4AUqtD1A+yKQ5qO5PriyNmT6AAC0PuAAA/2l3AAAFNH4AAKHHUg References: <000601c8e369$530b9b80$5c0c7c0a@china.huawei.com><001201c8e36a$746e18b0$5c0c7c0a@china.huawei.com><003901c8e36c$02c6b850$5c0c7c0a@china.huawei.com><000e01c8e370$3f9f83c0$5c0c7c0a@china.huawei.com><005601c8e37f$90fc3a60$5c0c7c0a@china.huawei.com><008201c8e388$984a4240$5c0c7c0a@china.huawei.com><00bc01c8e39e$b644f6d0$5c0c7c0a@china.huawei.com><000a01c8e3a6$0e3cc8c0$5c0c7c0a@china.huawei.com> From: "Vijay Devarapalli" To: "Ahmad Muhanna" , "Sri Gundavelli" , "Frank Xia" Cc: Basavaraj Patil , mext@ietf.org Subject: Re: [MEXT] Authentication option support in Binding Revocation 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 > My understanding that Mobile IPv6 Generic Signaling Message (MGSM) and > Binding Revocation are proposed as standard track document. Therefore, > before we start talking about adding Auth protocol support to MGSM and > consequently Binding Revocation, we need to do something > about RFC4285. > This RFC is still an Informational one and my understanding a standard > track doc can not reference an Informational one. It doesn't matter. The Generic Signaling Message just needs to describe how to calculate the authentication data if the MN-HA authentication option is used. RFC 4285 would be an Informational reference, since it is not required for someone to use the Generic Signaling Message. Vijay > Any one knows what is the latest on RFC4285? Raj or Kuntal? > > Regards, > Ahmad > > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > Behalf Of Muhanna, Ahmad (RICH1:2H10) > > Sent: Saturday, July 12, 2008 7:05 AM > > To: Vijay Devarapalli; Sri Gundavelli; Frank Xia > > Cc: mext@ietf.org > > Subject: Re: [MEXT] Authentication option support in Binding > > Revocation > > > > Hi Vijay, > > > > > > Subject: Re: [MEXT] Authentication option support in Binding > > > > Revocation > > > > > > > If there is a shared key between the mobile node and the > > > home agent, > > > > MN-HA Authentication option can be used. > > > > > > > > If there is a shared key between the mobile node and the > > > AAA, MN-AAA > > > > authentication option can be used. > > > > > > > > But you bring a good point, these options are defined to be > > > carried in > > > > BU/BA. We need to allow these options to be carried in Generic > > > > Notification messages. > > > > > > Specifying the use of MN-HA authentication option with > the Generic > > > Signaling Message sounds good to me. I doubt if the MN-AAA > > > authentication option will ever be used with the Generic > Signaling > > > Message, though. > > > > [Ahmad] > > I agree. > > If auth protocol to be used to authenticate the MIP6 Generic > > Signaling Message, then it has to be the MN-HA AE in the case > > of Client MIP6. > > MN-AAA AE is used during the initial registration to help in > > bootstrapping MN-HA SA if it is needed. After the MIP6 > > session is established, it is assumed that MN-HA SA has been > > established. > > Therefore, MN-AAA AE has no value in this scenario. Not only > > that, but it does not make sense either. > > > > > > > > > > Vijay > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www.ietf.org/mailman/listinfo/mext > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Jul 12 16:52:40 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 246FC28C160; Sat, 12 Jul 2008 16:52:40 -0700 (PDT) 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 0EB0A28C160 for ; Sat, 12 Jul 2008 16:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yv1zkw+zL17p for ; Sat, 12 Jul 2008 16:52:38 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.188]) by core3.amsl.com (Postfix) with ESMTP id CBFE73A67B4 for ; Sat, 12 Jul 2008 16:52:37 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so2740395tib.25 for ; Sat, 12 Jul 2008 16:52:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=RAeKZE0aG14IN0aPB1ASSkxdJFyT6PssEZwiRrQQ24k=; b=QKOsVGp/JZ8XYnaJzTk7NG2kRWGf/nTFI62Av7Fo2rN2p/WPzuHJgzyd3dz7XRqQri J+jgt52rqyXyCiNfwastLf/zoSaOrgLnuBSSKhea5sO0xh7s0FJslKYO5X+YI4W7Vmwm tAzzxslcFnTR9io1LATKjZdI3nkxfs0a83Hjc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=SWwKXZOG04ssyDDXaBG2omVhStxb6Fdp5/CifWsN5Wu7ulDpnGiZuToF0jnfW47fw5 Z00Xb0R0AzwIzM0gOoiuNjIcHoRx/nSrN9eOBFVLTXZAJ+ajnL6iROWWeyM8lqfPVmk+ MgWcK3KIj24pFzgz4j1SHQ92sLFg3VmSyHQnE= Received: by 10.110.26.20 with SMTP id 20mr7528246tiz.20.1215906778646; Sat, 12 Jul 2008 16:52:58 -0700 (PDT) Received: by 10.110.53.11 with HTTP; Sat, 12 Jul 2008 16:52:58 -0700 (PDT) Message-ID: <1d38a3350807121652s13946624hbe98cfd78443b229@mail.gmail.com> Date: Sun, 13 Jul 2008 07:52:58 +0800 From: "Hui Deng" To: "Sri Gundavelli" In-Reply-To: MIME-Version: 1.0 References: <005601c8e37f$90fc3a60$5c0c7c0a@china.huawei.com> <008201c8e388$984a4240$5c0c7c0a@china.huawei.com> <00bc01c8e39e$b644f6d0$5c0c7c0a@china.huawei.com> <000a01c8e3a6$0e3cc8c0$5c0c7c0a@china.huawei.com> Cc: mext@ietf.org Subject: Re: [MEXT] Authentication option support in Binding Revocation 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="===============0478880884==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0478880884== Content-Type: multipart/alternative; boundary="----=_Part_26743_3126462.1215906778651" ------=_Part_26743_3126462.1215906778651 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello all I saw lots of options and SA may be used, anybody can help to let me know how does mobile node know how it should work in CMIP or PMIP? Secondly, I also don't know how to prevent anti-replay happen, Lastly, how could IKEv1 or IKEv2 work for this. Many thanks -Hui ------=_Part_26743_3126462.1215906778651 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hello all
 
I saw lots of options and SA may be used, anybody can help to let me
know how does mobile node know how it should work in CMIP or PMIP?
 
Secondly, I also don't know how to prevent anti-replay happen,
 
Lastly, how could IKEv1 or IKEv2 work for this.
 
Many thanks
 
-Hui
------=_Part_26743_3126462.1215906778651-- --===============0478880884== 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 --===============0478880884==-- From mext-bounces@ietf.org Sun Jul 13 08:26:18 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E00AD3A6809; Sun, 13 Jul 2008 08:26:18 -0700 (PDT) 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 4EAD83A6809 for ; Sun, 13 Jul 2008 08:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 Oa6S36stJjsJ for ; Sun, 13 Jul 2008 08:26:17 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 7E91D3A67EB for ; Sun, 13 Jul 2008 08:26:17 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 3A69A198710; Sun, 13 Jul 2008 18:26:40 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 771931986A4; Sun, 13 Jul 2008 18:26:39 +0300 (EEST) Message-ID: <487A1EB0.5090105@piuha.net> Date: Sun, 13 Jul 2008 11:26:40 -0400 From: Jari Arkko User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: "Charles E. Perkins" References: <486561DA.8090609@earthlink.net> In-Reply-To: <486561DA.8090609@earthlink.net> X-Virus-Scanned: ClamAV using ClamSMTP Cc: mext@ietf.org Subject: Re: [MEXT] Issue #4 Remove references to site-local addresses [George Tsirtsis ] 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I have reviewed this issue and the proposed changes look fine. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 01:22:32 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 509BB3A6886; Mon, 14 Jul 2008 01:22:32 -0700 (PDT) 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 139263A6867 for ; Mon, 14 Jul 2008 01:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08LXJxKKQX5W for ; Mon, 14 Jul 2008 01:22:28 -0700 (PDT) Received: from cluster-b.mailcontrol.com (cluster-b.mailcontrol.com [217.68.146.190]) by core3.amsl.com (Postfix) with ESMTP id 697CC3A6AD2 for ; Mon, 14 Jul 2008 01:22:24 -0700 (PDT) Received: from rly39b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly39b.srv.mailcontrol.com (MailControl) with ESMTP id m6E8MZaJ009952 for ; Mon, 14 Jul 2008 09:22:46 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly39b.srv.mailcontrol.com (MailControl) id m6E8Lkrd008714 for mext@ietf.org; Mon, 14 Jul 2008 09:21:46 +0100 Received: from eundsmtpout02.pan.eu ([168.87.60.204]) by rly39b-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id m6E8LLAv007761; Mon, 14 Jul 2008 09:21:45 +0100 (BST) Received: from eundadmi02.pan.eu ([10.109.33.23]) by eundsmtpout02.pan.eu (Lotus Domino Release 7.0.2) with ESMTP id 2008071410212605-85840 ; Mon, 14 Jul 2008 10:21:26 +0200 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 2008071410212457-268470 ; Mon, 14 Jul 2008 10:21:24 +0200 Received: from localhost ([127.0.0.1]) by VPN-MRelay-02.PRDCG.Panasonic.de; Mon, 14 Jul 2008 10:25:00 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [mext] #11: De-registration when returning home[VijayDevarapalli ] Thread-Index: Acjh96r/rFIBubkDS0+S4gL1W6Yv2AAxHPwQAAAwv6AAAEgzQACzDYQg References: <010801c8e16b$5c2889d0$7471510a@psl.local> To: "Vijay Devarapalli" , "Giaretta, Gerardo" , "Sri Gundavelli" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACBB18E03@lan-ex-02.panasonic.de> Date: Mon, 14 Jul 2008 10:20:48 +0200 From: "Kilian Weniger" X-MIMETrack: Itemize by SMTP Server on EUNDADMI02/EUR/Matsushita(Release 7.0.3|September 26, 2007) at 14.07.2008 10:21:25, Serialize by Router on EUNDADMI02/EUR/Matsushita(Release 7.0.3|September 26, 2007) at 14.07.2008 10:21:26, Serialize complete at 14.07.2008 10:21:26, Itemize by SMTP Server on EUNDSMTPOUT02/EUR/PANEXTOUT(Release 7.0.2|September 26, 2006) at 07/14/2008 10:21:26 AM, Serialize by Router on EUNDSMTPOUT02/EUR/PANEXTOUT(Release 7.0.2|September 26, 2006) at 07/14/2008 10:21:43 AM, Serialize complete at 07/14/2008 10:21:43 AM Content-class: urn:content-classes:message X-Scanned-By: MailControl A-08-50-03 (www.mailcontrol.com) on 10.66.1.149 Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home[VijayDevarapalli ] 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, I'm ok with this text proposal. Kilian > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Vijay Devarapalli > Sent: Donnerstag, 10. Juli 2008 20:53 > To: Giaretta, Gerardo; Sri Gundavelli > Cc: charliep@computer.org; mext@ietf.org > Subject: Re: [MEXT] [mext] #11: De-registration when > returning home[VijayDevarapalli ] > > Fine with me. So the new text is > > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > To be able to send and receive packets using its home address from > the home link, the mobile node MUST send a Binding Update to its > home agent to instruct its home agent to no longer intercept or > tunnel packets for it. Until the mobile node sends a > de-registration > Binding Update, it will not be able to send and receive packets > using its home address from the home link. The home agent will > continue to intercept all packets sent to the mobile's > home address > and tunnel to the previously registered care-of address. > > Is everyone ok with this? > > Vijay > > > > -----Original Message----- > > From: Giaretta, Gerardo [mailto:gerardog@qualcomm.com] > > Sent: Thursday, July 10, 2008 11:46 AM > > To: Vijay Devarapalli; Sri Gundavelli > > Cc: Benjamin Lim; charliep@computer.org; mext@ietf.org > > Subject: RE: [MEXT] [mext] #11: De-registration when > > returning home [VijayDevarapalli ] > > > > I would add the following sentence for the sake of clarity at > > the end of > > your text: > > > > Until the mobile node sends a de-registration Binding Update, > > it will not be able to send and receive packets using its home > > address from the home link. The home agent will continue to > > intercept > > all packets sent to the mobile's home address and tunnel to the > > previously registered care-of address. > > > > Note that this text does not contain any normative text, just > > clarifies > > what happens. > > > > Gerardo > > > > > -----Original Message----- > > > From: Vijay Devarapalli [mailto:vijay@wichorus.com] > > > Sent: Thursday, July 10, 2008 11:42 AM > > > To: Sri Gundavelli > > > Cc: Giaretta, Gerardo; Benjamin Lim; charliep@computer.org; > > mext@ietf.org > > > Subject: RE: [MEXT] [mext] #11: De-registration when > returning home > > > [VijayDevarapalli ] > > > > > > Hi Sri, > > > > > > > Below text seems ok to me, except the new concept of multiple > > > > interface > > > > MN in the context of 3775. I'd simply state, "if the MN > > wants to use > > > > the HoA on the home link, it MUST send a dereg" ...., from the > > > > MIP perspective we can require that. From HA perspective in > > > > the context > > > > of ND, what HA should do if the address is taken over, > we need to > > > > discuss further, as say above. > > > > > > Is this what you are looking for? > > > > > > A mobile node detects that it has returned to its home > > link through > > > the movement detection algorithm in use (Section > > 11.5.1), when the > > > mobile node detects that its home subnet prefix is > again on-link. > > > To be able to send and receive packets using its home > > address from > > > the home link, the mobile node MUST send a Binding > Update to its > > > home agent to instruct its home agent to no longer intercept or > > > tunnel packets for it. > > > > > > I am fine with this as well, since it avoids talking > about multiple > > > interfaces. Gerardo? > > > > > > Vijay > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://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 https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 05:15:04 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD11328C1C6; Mon, 14 Jul 2008 05:15:04 -0700 (PDT) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8A42B3A69D9; Mon, 14 Jul 2008 05:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080714121501.8A42B3A69D9@core3.amsl.com> Date: Mon, 14 Jul 2008 05:15:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-nemo-v4traversal-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 --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 : Mobile IPv6 Support for Dual Stack Hosts and Routers Author(s) : H. Soliman Filename : draft-ietf-mext-nemo-v4traversal-05.txt Pages : 48 Date : 2008-07-14 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-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mext-nemo-v4traversal-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-14051313.I-D@ietf.org> --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 https://www.ietf.org/mailman/listinfo/mext --NextPart-- From mext-bounces@ietf.org Mon Jul 14 05:20:18 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 355933A69D9; Mon, 14 Jul 2008 05:20:18 -0700 (PDT) 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 3C8873A68FF for ; Mon, 14 Jul 2008 05:20:17 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuUXBLPqHGbr for ; Mon, 14 Jul 2008 05:20:16 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 584F428C0E9 for ; Mon, 14 Jul 2008 05:20:15 -0700 (PDT) Received: from [124.190.105.201] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1KIN2l-0004bc-Mm; Mon, 14 Jul 2008 22:20:39 +1000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Mon, 14 Jul 2008 22:20:36 +1000 From: Hesham Soliman To: "mext@ietf.org" , Message-ID: Thread-Topic: New Version Notification for draft-ietf-mext-nemo-v4traversal-05 Thread-Index: AcjlrATvxVfjFjCKvEWdShakSo10Og== In-Reply-To: <20080714121313.B98AB3A6932@core3.amsl.com> Mime-version: 1.0 Subject: [MEXT] FW: New Version Notification for draft-ietf-mext-nemo-v4traversal-05 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, One thing I forgot to add was Alfred Hines name in the acknowledgement section. I'll add that during IESG update or to the RFC editor notes if we don't do another update. Hesham ------ Forwarded Message > From: IETF I-D Submission Tool > Date: Mon, 14 Jul 2008 05:13:13 -0700 (PDT) > To: Hesham Soliman > Cc: Hesham Soliman > Subject: New Version Notification for draft-ietf-mext-nemo-v4traversal-05 > > > A new version of I-D, draft-ietf-mext-nemo-v4traversal-05.txt has been > successfuly submitted by Hesham Soliman and posted to the IETF repository. > > Filename: draft-ietf-mext-nemo-v4traversal > Revision: 05 > Title: Mobile IPv6 Support for Dual Stack Hosts and Routers > Creation_date: 2008-07-14 > WG ID: mext > Number_of_pages: 48 > > Abstract: > 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. > > > > The IETF Secretariat. > > ------ End of Forwarded Message _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 05:45:35 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E0443A69B9; Mon, 14 Jul 2008 05:45:35 -0700 (PDT) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3464D28C0CE; Mon, 14 Jul 2008 05:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080714124502.3464D28C0CE@core3.amsl.com> Date: Mon, 14 Jul 2008 05:45:02 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mip6-radius-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 --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 : RADIUS Mobile IPv6 Support Author(s) : A. Lior, et al. Filename : draft-ietf-mip6-radius-05.txt Pages : 50 Date : 2008-07-14 This document defines new attributes to facilitate Mobile IPv6 operations using RADIUS infrastructure. The operations include bootstrapping of information required by the Mobile Node and the interface between the Network Access Server, Home Agent and the RADIUS server used to assist MIP6 operations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-radius-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mip6-radius-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-14053730.I-D@ietf.org> --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 https://www.ietf.org/mailman/listinfo/mext --NextPart-- From mext-bounces@ietf.org Mon Jul 14 05:46:45 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 131C728C0F2; Mon, 14 Jul 2008 05:46:45 -0700 (PDT) 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 CED6C3A6914 for ; Mon, 14 Jul 2008 05:42:15 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1C685s5uM3m for ; Mon, 14 Jul 2008 05:42:14 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 7905D3A68F3 for ; Mon, 14 Jul 2008 05:42:14 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6ECgOxu013785; Mon, 14 Jul 2008 15:42:28 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jul 2008 15:42:03 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jul 2008 07:41:14 -0500 Received: from 10.241.59.188 ([10.241.59.188]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Mon, 14 Jul 2008 12:41:14 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Mon, 14 Jul 2008 07:41:13 -0500 From: Basavaraj Patil To: ext Ahmad Muhanna , Vijay Devarapalli , Sri Gundavelli , Frank Xia Message-ID: Thread-Topic: [MEXT] Authentication option support in Binding Revocation Thread-Index: Acjjy4AUqtD1A+yKQ5qO5PriyNmT6AAC0PuAAA/2l3AAAFNH4ABlvrEx In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 14 Jul 2008 12:41:14.0374 (UTC) FILETIME=[E7106260:01C8E5AE] X-Nokia-AV: Clean X-Mailman-Approved-At: Mon, 14 Jul 2008 05:46:44 -0700 Cc: mext@ietf.org Subject: Re: [MEXT] Authentication option support in Binding Revocation 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 Ahmad, RFC4285bis status currently shows as expired. The authors need to resubmit a revised version of the I-D. This I-D will be progressed as part of the MIP6 charter. -Raj On 7/12/08 7:19 AM, "ext Ahmad Muhanna" wrote: > > Just to add one point to my earlier reply. > > My understanding that Mobile IPv6 Generic Signaling Message (MGSM) and > Binding Revocation are proposed as standard track document. Therefore, > before we start talking about adding Auth protocol support to MGSM and > consequently Binding Revocation, we need to do something about RFC4285. > This RFC is still an Informational one and my understanding a standard > track doc can not reference an Informational one. > > Any one knows what is the latest on RFC4285? Raj or Kuntal? > > Regards, > Ahmad > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> Behalf Of Muhanna, Ahmad (RICH1:2H10) >> Sent: Saturday, July 12, 2008 7:05 AM >> To: Vijay Devarapalli; Sri Gundavelli; Frank Xia >> Cc: mext@ietf.org >> Subject: Re: [MEXT] Authentication option support in Binding >> Revocation >> >> Hi Vijay, >> >>>> Subject: Re: [MEXT] Authentication option support in Binding >>>> Revocation >>> >>>> If there is a shared key between the mobile node and the >>> home agent, >>>> MN-HA Authentication option can be used. >>>> >>>> If there is a shared key between the mobile node and the >>> AAA, MN-AAA >>>> authentication option can be used. >>>> >>>> But you bring a good point, these options are defined to be >>> carried in >>>> BU/BA. We need to allow these options to be carried in Generic >>>> Notification messages. >>> >>> Specifying the use of MN-HA authentication option with the Generic >>> Signaling Message sounds good to me. I doubt if the MN-AAA >>> authentication option will ever be used with the Generic Signaling >>> Message, though. >> >> [Ahmad] >> I agree. >> If auth protocol to be used to authenticate the MIP6 Generic >> Signaling Message, then it has to be the MN-HA AE in the case >> of Client MIP6. >> MN-AAA AE is used during the initial registration to help in >> bootstrapping MN-HA SA if it is needed. After the MIP6 >> session is established, it is assumed that MN-HA SA has been >> established. >> Therefore, MN-AAA AE has no value in this scenario. Not only >> that, but it does not make sense either. >> >> >>> >>> Vijay >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 07:43:04 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B9733A6887; Mon, 14 Jul 2008 07:43:04 -0700 (PDT) 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 C6A6E3A6887 for ; Mon, 14 Jul 2008 07:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MC-+xF8tQE1 for ; Mon, 14 Jul 2008 07:43:02 -0700 (PDT) Received: from g4t0015.houston.hp.com (g4t0015.houston.hp.com [15.201.24.18]) by core3.amsl.com (Postfix) with ESMTP id E3C533A67A4 for ; Mon, 14 Jul 2008 07:43:01 -0700 (PDT) Received: from smtp1.fc.hp.com (smtp.cnd.hp.com [15.15.136.127]) by g4t0015.houston.hp.com (Postfix) with ESMTP id 3B6D48674; Mon, 14 Jul 2008 14:43:27 +0000 (UTC) Received: from wrx.zko.hp.com (wrx.zko.hp.com [16.116.96.52]) by smtp1.fc.hp.com (Postfix) with ESMTP id 77FDD1FD8B4; Mon, 14 Jul 2008 14:34:16 +0000 (UTC) Message-ID: <487B65FE.6070400@hp.com> Date: Mon, 14 Jul 2008 10:43:10 -0400 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Sri Gundavelli References: In-Reply-To: X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE Cc: mext@ietf.org Subject: Re: [MEXT] Authentication option support in Binding Revocation 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Sri, Sri Gundavelli wrote: >> >> Specifying the use of MN-HA authentication option with the Generic >> Signaling Message sounds good to me. I doubt if the MN-AAA >> authentication option will ever be used with the Generic Signaling >> Message, though. >> > > Vijay, > > I think we can redefine these options (one or both) as valid options > to be carried in Generic Notification messages. We can add few lines > on this validity. Brian ? > > We can address Frank's issues in this draft and revocation or other > clients dont have to deal with this. This seems fine with me. Maybe someone can propose some text? :) -Brian _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 08:00:04 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8415F28C25E; Mon, 14 Jul 2008 08:00:04 -0700 (PDT) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8224E28C1A7; Mon, 14 Jul 2008 08:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080714150001.8224E28C1A7@core3.amsl.com> Date: Mon, 14 Jul 2008 08:00:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mip6-hareliability-04.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 : Home Agent Reliability Protocol Author(s) : R. Wakikawa Filename : draft-ietf-mip6-hareliability-04.txt Pages : 47 Date : 2008-07-14 The home agent can be a single point of failure when Mobile IPv6 is operated in a system. It is critical to provide home agent reliability in the event of a home agent crashing or becoming unavailable. This would allow another home agent to take over and continue providing service to the mobile nodes. This document describes the problem scope briefly and provides a mechanism of home agent failure detection, home agent state transfer, and home agent switching for home agent redundancy and reliability. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-hareliability-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mip6-hareliability-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-14075329.I-D@ietf.org> --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 https://www.ietf.org/mailman/listinfo/mext --NextPart-- From mext-bounces@ietf.org Mon Jul 14 09:11:07 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3259E3A6876; Mon, 14 Jul 2008 09:11:07 -0700 (PDT) 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 A31AF3A6AC4 for ; Mon, 14 Jul 2008 09:11:05 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOcOkvFnW++h for ; Mon, 14 Jul 2008 09:11:04 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 3D7BE3A67DD for ; Mon, 14 Jul 2008 09:11:04 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6EGBME04452; Mon, 14 Jul 2008 16:11:22 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Jul 2008 11:11:20 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Authentication option support in Binding Revocation thread-index: Acjjy4AUqtD1A+yKQ5qO5PriyNmT6AAC0PuAAA/2l3AAAFNH4AAKHHUgAGGL8wA= References: <000601c8e369$530b9b80$5c0c7c0a@china.huawei.com><001201c8e36a$746e18b0$5c0c7c0a@china.huawei.com><003901c8e36c$02c6b850$5c0c7c0a@china.huawei.com><000e01c8e370$3f9f83c0$5c0c7c0a@china.huawei.com><005601c8e37f$90fc3a60$5c0c7c0a@china.huawei.com><008201c8e388$984a4240$5c0c7c0a@china.huawei.com><00bc01c8e39e$b644f6d0$5c0c7c0a@china.huawei.com><000a01c8e3a6$0e3cc8c0$5c0c7c0a@china.huawei.com> From: "Ahmad Muhanna" To: "Vijay Devarapalli" , "Sri Gundavelli" , "Frank Xia" Cc: Basavaraj Patil , mext@ietf.org Subject: Re: [MEXT] Authentication option support in Binding Revocation 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, I guess, It is not that simple:) One more thing to add here is that the whole discussion here is concentrated on supporting the Auth protocol for Client MIP6 BCE. Otherwise, IMO, things is more complicated. MGSM is based on the security architecture of RFC3775. In the case of PMIPv6 it is based on PMIPv6 base draft. On the other hand, let us not forget that RFC4285 also, defines a replay protection mechanism for Client MIP6 BU/BA. IMO, the options here are as follows: 1. Either MGSM need to have a normative reference to RFC4285, or 2. MGSM need to define all the details of a new security architecture which cover all security threats including replay protection, etc. Looking at the current options, I believe that any attempt to have MGSM support auth protocol in the current timeframe is nothing but more delay to the completion of Binding Revocation. Additionally, the mext wg consensus call on Binding Revocation to use MGSM was based on the fact that MGSM and Binding Revocation use the same security architecture as in RFC3775 and PMIPv6 base draft which in itself is based on RFC3775. IMO, We need to specify the MGSM based on RFC3775 and PMIPv6 base draft without excluding the support for Auth protocol which can be added in the future based on the consensus of the wg. Regards, Ahmad > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay@wichorus.com] > Sent: Saturday, July 12, 2008 11:59 AM > To: Muhanna, Ahmad (RICH1:2H10); Sri Gundavelli; Frank Xia > Cc: mext@ietf.org; Basavaraj Patil; Chowdhury, Kuntal > Subject: RE: [MEXT] Authentication option support in Binding > Revocation > > > My understanding that Mobile IPv6 Generic Signaling Message > (MGSM) and > > Binding Revocation are proposed as standard track document. > Therefore, > > before we start talking about adding Auth protocol support > to MGSM and > > consequently Binding Revocation, we need to do something about > > RFC4285. > > This RFC is still an Informational one and my understanding > a standard > > track doc can not reference an Informational one. > > It doesn't matter. The Generic Signaling Message just needs > to describe how to calculate the authentication data if the > MN-HA authentication option is used. RFC 4285 would be an > Informational reference, since it is not required for someone > to use the Generic Signaling Message. > > Vijay > > > Any one knows what is the latest on RFC4285? Raj or Kuntal? > > > > Regards, > > Ahmad > > > > > -----Original Message----- > > > From: mext-bounces@ietf.org > [mailto:mext-bounces@ietf.org] On Behalf > > > Of Muhanna, Ahmad (RICH1:2H10) > > > Sent: Saturday, July 12, 2008 7:05 AM > > > To: Vijay Devarapalli; Sri Gundavelli; Frank Xia > > > Cc: mext@ietf.org > > > Subject: Re: [MEXT] Authentication option support in Binding > > > Revocation > > > > > > Hi Vijay, > > > > > > > > Subject: Re: [MEXT] Authentication option support in Binding > > > > > Revocation > > > > > > > > > If there is a shared key between the mobile node and the > > > > home agent, > > > > > MN-HA Authentication option can be used. > > > > > > > > > > If there is a shared key between the mobile node and the > > > > AAA, MN-AAA > > > > > authentication option can be used. > > > > > > > > > > But you bring a good point, these options are defined to be > > > > carried in > > > > > BU/BA. We need to allow these options to be carried > in Generic > > > > > Notification messages. > > > > > > > > Specifying the use of MN-HA authentication option with > > the Generic > > > > Signaling Message sounds good to me. I doubt if the MN-AAA > > > > authentication option will ever be used with the Generic > > Signaling > > > > Message, though. > > > > > > [Ahmad] > > > I agree. > > > If auth protocol to be used to authenticate the MIP6 Generic > > > Signaling Message, then it has to be the MN-HA AE in the case of > > > Client MIP6. > > > MN-AAA AE is used during the initial registration to help in > > > bootstrapping MN-HA SA if it is needed. After the MIP6 session is > > > established, it is assumed that MN-HA SA has been established. > > > Therefore, MN-AAA AE has no value in this scenario. Not > only that, > > > but it does not make sense either. > > > > > > > > > > > > > > Vijay > > > > _______________________________________________ > > > > MEXT mailing list > > > > MEXT@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 09:15:03 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD2C13A6B52; Mon, 14 Jul 2008 09:15:03 -0700 (PDT) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6F13228C1B2; Mon, 14 Jul 2008 09:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080714161501.6F13228C1B2@core3.amsl.com> Date: Mon, 14 Jul 2008 09:15:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-nemo-ro-automotive-req-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 : Automotive Industry Requirements for NEMO Route Optimization Author(s) : R. Baldessari, et al. Filename : draft-ietf-mext-nemo-ro-automotive-req-01.txt Pages : 25 Date : 2008-07-14 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-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mext-nemo-ro-automotive-req-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-14090238.I-D@ietf.org> --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 https://www.ietf.org/mailman/listinfo/mext --NextPart-- From mext-bounces@ietf.org Mon Jul 14 09:25:35 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC6E13A6BDE; Mon, 14 Jul 2008 09:25:35 -0700 (PDT) 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 E6E383A6BE0 for ; Mon, 14 Jul 2008 09:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.342 X-Spam-Level: X-Spam-Status: No, score=-1.342 tagged_above=-999 required=5 tests=[AWL=-1.157, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brsOAqlb-mMx for ; Mon, 14 Jul 2008 09:25:33 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 0599D3A6BD2 for ; Mon, 14 Jul 2008 09:25:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=VyUSjgqzRJv3r8EflBWht1q83D4mGpkGI8Ud3DBZhvjf2a3RO71bk68FxWsvajIV; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [75.26.137.116] (helo=[10.166.255.10]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1KIQs6-0002Ws-LF for mext@ietf.org; Mon, 14 Jul 2008 12:25:54 -0400 Message-ID: <487B7E10.1060906@earthlink.net> Date: Mon, 14 Jul 2008 09:25:52 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: mext@ietf.org X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5222117a3491cca44dbf68cdfe1f024e3f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Subject: [MEXT] An unanswered question about "MIPv6 Generic Signaling Message" (MGSM) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello folks, A while back, I asked the following question: > Could you provide some examples of messages that > would NOT fit as subtypes of the proposed generic > signaling message? Does anyone have an answer to this question? I feel like I must be missing some basic point here. Thanks in advance, Charlie P. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 09:48:25 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21F9A3A6B56; Mon, 14 Jul 2008 09:48:25 -0700 (PDT) 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 72D203A6809 for ; Mon, 14 Jul 2008 09:48:24 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgnLcaMHipkq for ; Mon, 14 Jul 2008 09:48:23 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 6DA713A6AC9 for ; Mon, 14 Jul 2008 09:48:23 -0700 (PDT) Received: from dummyhost0.it.uc3m.es (dummyhost0.it.uc3m.es [163.117.139.66])by smtp02.uc3m.es (Postfix) with ESMTP id 9FBF63FAA3F; Mon, 14 Jul 2008 18:48:47 +0200 (CEST) Message-ID: <487B836F.5010005@it.uc3m.es> Date: Mon, 14 Jul 2008 18:48:47 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: mext X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-1.5155 TC:1F TRN:7 TV:5.5.1026(16032.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] reminder: 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, we are about to close the draft agenda, so if you have slot requests, please send them in. regards, marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 09:56:16 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D07C73A6B24; Mon, 14 Jul 2008 09:56:16 -0700 (PDT) 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 7B86D3A6B11 for ; Mon, 14 Jul 2008 09:56:15 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsmZhZNNraPb for ; Mon, 14 Jul 2008 09:56:14 -0700 (PDT) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.179]) by core3.amsl.com (Postfix) with ESMTP id 4978C3A6A3B for ; Mon, 14 Jul 2008 09:56:14 -0700 (PDT) Received: by ik-out-1112.google.com with SMTP id c28so2260246ika.5 for ; Mon, 14 Jul 2008 09:56:39 -0700 (PDT) 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-disposition:content-type:content-transfer-encoding :message-id:sender; bh=RFEch3P5bxChb2f2B2caPYlZiGP2916IcTJ4/ILBAM0=; b=o1oaz7Ph3HDFF9mRubKs3/wroJKDl+H52GXvAk0djuOZ2RrbCWKkQu8S8dYqEBmaed zzWV09kjguhyP5+uMmxdLhdMB85rF9XnpUOV+lH25CdqR6TldPq0Vz1Rq2nJLFbifxGQ GvhhVSYvFNlii3dYQfQRrzL7BGfwA+CMwOJps= 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-disposition:content-type :content-transfer-encoding:message-id:sender; b=qC3jgxJG6SP36sjrAwCQdq0MgMqd+qGvYc/OjuiensvxiukG7/6mSr8HyjcUsUZ+Ln ytPh3ds+aXInUgzfIgJ2GarSkzJVucjJPvmLd6z1SxMF02GmZqkYHRtQBMo8YVZcBjQz DkOiw20W58uFYsD9E6pw+KXUx27eu7e/ObkWU= Received: by 10.210.62.12 with SMTP id k12mr9070393eba.174.1216054599137; Mon, 14 Jul 2008 09:56:39 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id t12sm722689gvd.10.2008.07.14.09.56.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 14 Jul 2008 09:56:38 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Mon, 14 Jul 2008 18:56:36 +0200 User-Agent: KMail/1.9.9 References: <00bc01c8e39e$b644f6d0$5c0c7c0a@china.huawei.com> In-Reply-To: <00bc01c8e39e$b644f6d0$5c0c7c0a@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200807141856.36985.julien.IETF@laposte.net> Subject: Re: [MEXT] Authentication option support in Binding Revocation 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 Hello Frank, and other interesting parties, On Friday 11 July 2008, Frank Xia wrote: > Hi Ahmad > > Upon your request, I initials this thread. > > 1) How are BRI/BRA messages secured when > there is not IPsec SA between HA and MN? MIPv6 uses IPsec and IKE as a security mechanism, thus how the BRI/BRA messages are secured when there is no IPsec SA between HA and MN is out-of scope for this WG. > 2)If authentication options defined in RFC4285 > are used, which option should be used? > MN-HA or MN-AAA? This is out-of scope for this WG as well. > 3)If BRI processing failure is because of > failed authentication, how does the MN inform HA? When standard security mechanisms are used to protect MIPv6 signalling traffic it is my understanding that failed authentication is appropriately handled by IKE and IPsec. --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 10:05:11 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEFDD28C1CB; Mon, 14 Jul 2008 10:05:11 -0700 (PDT) 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 17BFC28C1AE for ; Mon, 14 Jul 2008 10:05:10 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yuEhxJvId11 for ; Mon, 14 Jul 2008 10:05:09 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by core3.amsl.com (Postfix) with ESMTP id E819728C1F1 for ; Mon, 14 Jul 2008 10:01:27 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id b11so1383475nfh.39 for ; Mon, 14 Jul 2008 10:01:53 -0700 (PDT) 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:cc:content-type:message-id:sender; bh=jnlOyjcavUAw71x37zGhYvAVrsQJEqwCaOmqZYc++/g=; b=TgETz6hyhjrYTXmk5/VL0ZKUOR+WLJTRsAL0AhqIU+BX5oZkTiFOh8Ft4Q9rshYbU4 tSvoP7ZVZzqQ2WLekX2XnOlJvSwplLzEyIT68XvuLoJV182/Jl4L8ndTMzZD/C6Omxk1 SWE55bfYW2/LeZyJMaQzBSkh2fw6XKorhi0h8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:mime-version:cc:content-type :message-id:sender; b=AmQfgEEbJVB35SZj2mi/7TENBvLvIgxx90w1XneaF8Djh7xwkxjOCzbSc0G/f1CI41 xCmSqKAN4PGms3f7HFjbWCk/7mOyX+ZUkQstS1Ic6xt8aYKoaiKtxjhpJL+kARgua07G y321DZpoGuDGRYnoQMQJdKNjK7NmuhL1YgJpw= Received: by 10.210.114.15 with SMTP id m15mr9056522ebc.82.1216054913193; Mon, 14 Jul 2008 10:01:53 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id j8sm731754gvb.1.2008.07.14.10.01.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 14 Jul 2008 10:01:52 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Mon, 14 Jul 2008 19:01:50 +0200 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_+Z4eIEetF9Qrfh0" Message-Id: <200807141901.50950.julien.IETF@laposte.net> Subject: [MEXT] Fwd: I-D Action:draft-muhanna-mext-binding-revocation-02.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=_+Z4eIEetF9Qrfh0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello Folks, The MEXT WG has a deliverable for Binding Revocation for IP Mobility. Hereby we'd like to ask WG participants whether or not they think this individual submission should be adopted as the corresponding MEXT work item. Please answer to this note to state your opinion by Monday July 28th. Thank you for your support, -- julien & marcelo, MEXT chairs --Boundary-00=_+Z4eIEetF9Qrfh0 Content-Type: message/rfc822; name="forwarded message" Content-Transfer-Encoding: 7bit Content-Description: Internet-Drafts@ietf.org: I-D Action:draft-muhanna-mext-binding-revocation-02.txt Content-Disposition: inline Return-Path: Received: from mwinf8213.laposte.net (mwinf8213.laposte.net) by mwinb8204 (SMTP Server) with LMTP; Fri, 11 Jul 2008 15:49:02 +0200 X-Sieve: Server Sieve 2.2 Received: from meplus.info (localhost [127.0.0.1]) by mwinf8213.laposte.net (SMTP Server) with ESMTP id 914FE240008B; Fri, 11 Jul 2008 15:49:02 +0200 (CEST) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mwinf8213.laposte.net (SMTP Server) with ESMTP id 2F42C2400083; Fri, 11 Jul 2008 15:49:02 +0200 (CEST) X-ME-UUID: 20080711134902193.2F42C2400083@mwinf8213.laposte.net Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE0A428C1A0; Fri, 11 Jul 2008 06:45:21 -0700 (PDT) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7C93B3A69D6; Fri, 11 Jul 2008 06:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-muhanna-mext-binding-revocation-02.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080711134501.7C93B3A69D6@core3.amsl.com> Date: Fri, 11 Jul 2008 06:45:01 -0700 (PDT) X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-me-spamlevel: not-spam X-me-spamrating: 40.000000 X-me-spamcause: OK, (-80)(0000)fghrlhcuvffnffculddvtddmneforghilhhinhhgnfhishhtucdlqddutddtmd X-me-spamwebmail: HAM X-UID: 71190 X-Length: 3927 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Binding Revocation for IPv6 Mobility Author(s) : A. Muhanna, et al. Filename : draft-muhanna-mext-binding-revocation-02.txt Pages : 32 Date : 2008-07-11 This document defines the revocation semantics for terminating a mobile node's mobility session and associated resources. These semantics are generic enough and can be used by mobility entities in the case of Client Mobile IPv6 and its extensions. This mechanism allows the mobility entity which initiates the revocation procedure to request its corresponding one to terminate either one, multiple or all specified binding cache entries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding-revocation-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-muhanna-mext-binding-revocation-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-11064400.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- --Boundary-00=_+Z4eIEetF9Qrfh0 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 --Boundary-00=_+Z4eIEetF9Qrfh0-- From mext-bounces@ietf.org Mon Jul 14 10:05:25 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A4BE28C2B6; Mon, 14 Jul 2008 10:05:25 -0700 (PDT) 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 4863A28C1B4 for ; Mon, 14 Jul 2008 10:05:24 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rakZT00RyeY for ; Mon, 14 Jul 2008 10:05:23 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by core3.amsl.com (Postfix) with ESMTP id E842928C2EF for ; Mon, 14 Jul 2008 10:02:36 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id b11so1383605nfh.39 for ; Mon, 14 Jul 2008 10:03:02 -0700 (PDT) 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:cc:content-type:message-id:sender; bh=jfeiZTgliV0fGn1QAn2njUcQUK5VzwQ/Lie05ZKdJMo=; b=BFTDatD2XxEsI6JSYNyChdK5GteAwBHoJIdxbjiHTK1q3ksJuMI2xXaqxJ/zeSahLx mvtPrpQAHIXyMY2eDHWRaiuY3bSUq+YzfVExJ/tpaE92WZuwkSsBe6EAk0NgiEMh8XhU v8ZCOPP70+Hvc3snKVAYgpUscV2DYHUdkyL18= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:mime-version:cc:content-type :message-id:sender; b=md7HNXD73qqyGxMpfxffYQPa1b5bRtfxAKK7PNqPyaqKy9fHxSGqFcbkdm5C96H+FL UTknG/U/wZ3JNM+PDeZ5zCFXr0hT7ZPTlR0I3RtgqoWJwUwpl8MbPwb5QFnUIL8ScrM8 qMhjxmLZETHDVP1LBIgUCrybN+txbzaPShgIo= Received: by 10.210.129.10 with SMTP id b10mr9066769ebd.78.1216054982202; Mon, 14 Jul 2008 10:03:02 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id p10sm732940gvf.7.2008.07.14.10.03.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 14 Jul 2008 10:03:01 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Mon, 14 Jul 2008 19:03:00 +0200 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_Eb4eIx2dXeGIk8K" Message-Id: <200807141903.00610.julien.IETF@laposte.net> Subject: [MEXT] Adoption of draft-haley-mext-generic-signaling-message-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 --Boundary-00=_Eb4eIx2dXeGIk8K Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello Folks, The MEXT WG has a deliverable for a Generic Signaling Message for MIPv6. Hereby we'd like to ask WG participants whether or not they think this individual submission should be adopted as the corresponding MEXT work item. Please answer to this note to state your opinion by Monday July 28th. Thank you for your support, -- julien & marcelo, MEXT chairs --Boundary-00=_Eb4eIx2dXeGIk8K Content-Type: message/rfc822; name="forwarded message" Content-Transfer-Encoding: 7bit Content-Description: Internet-Drafts@ietf.org: I-D Action:draft-haley-mext-generic-signaling-message-01.txt Content-Disposition: inline Return-Path: Received: from mwinf8406.laposte.net (mwinf8406.laposte.net) by mwinb8204 (SMTP Server) with LMTP; Fri, 11 Jul 2008 17:15:26 +0200 X-Sieve: Server Sieve 2.2 Received: from meplus.info (localhost [127.0.0.1]) by mwinf8406.laposte.net (SMTP Server) with ESMTP id 7056C240008E; Fri, 11 Jul 2008 17:15:26 +0200 (CEST) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mwinf8406.laposte.net (SMTP Server) with ESMTP id 108E3240008A; Fri, 11 Jul 2008 17:15:26 +0200 (CEST) X-ME-UUID: 20080711151526679.108E3240008A@mwinf8406.laposte.net Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C53593A68D1; Fri, 11 Jul 2008 08:15:02 -0700 (PDT) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8BAC828C1AD; Fri, 11 Jul 2008 08:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-haley-mext-generic-signaling-message-01.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080711151501.8BAC828C1AD@core3.amsl.com> Date: Fri, 11 Jul 2008 08:15:01 -0700 (PDT) X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-me-spamlevel: not-spam X-me-spamrating: 40.000000 X-me-spamcause: OK, (-80)(0000)fghrlhcuvffnffculddvtddmneforghilhhinhhgnfhishhtucdlqddutddtmd X-me-spamwebmail: HAM X-UID: 71204 X-Length: 3795 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mobile IPv6 Generic Signaling Message Author(s) : B. Haley, S. Gundavelli Filename : draft-haley-mext-generic-signaling-message-01.txt Pages : 14 Date : 2008-07-11 This document specifies two new Mobility Header message types that allow Mobile IPv6 entities to send and receive generic signaling messages. Haley Expires - December 2008 [page 1] Mobile IPv6 Generic Signaling Message July 2008 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-haley-mext-generic-signaling-message-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-haley-mext-generic-signaling-message-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-11080607.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- --Boundary-00=_Eb4eIx2dXeGIk8K 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 --Boundary-00=_Eb4eIx2dXeGIk8K-- From mext-bounces@ietf.org Mon Jul 14 10:05:31 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34C3528C2CC; Mon, 14 Jul 2008 10:05:31 -0700 (PDT) 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 3CEC528C2CC for ; Mon, 14 Jul 2008 10:05:30 -0700 (PDT) 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 JuY4v-xtOzg4 for ; Mon, 14 Jul 2008 10:05:29 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by core3.amsl.com (Postfix) with ESMTP id 7825828C302 for ; Mon, 14 Jul 2008 10:03:02 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id b11so1383605nfh.39 for ; Mon, 14 Jul 2008 10:03:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:subject:from:date :mime-version:content-type:message-id:sender; bh=C7FgOtq5KI/Jh6+3eoYSn/vSrIHttivB3g27dZ+2kKw=; b=F+BNI76/9FatIRpt9X9zhcwqFnOGFIOEWKon7xNshRyhbnqSWKwMj+8FLRFIFUfTEu 1e27n/JdGL8GaV1whkVp1SVPYOZwRF6pRAL0/Kp1JCQ60NJiqLH7Xfij9d9Gi6d2FKsw /49DBxdsAcJBna20oG2Bxkjwn2YIE0AXfNoyU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:subject:from:date:mime-version:content-type:message-id:sender; b=Kqh9BIWdkYYzoCJ3T+j+WgFUew9IJ3/XSKl6iqJea8f79WPMSauPXX0P0wHyeJBMOz MOnXpzwQ0/H5EbvdOhszKXU9aidpUP+JEsqApGtSZ82vMGhN7vgSJJ2sMpEaAtipZnZc EoN/WNyP5QU6Pi3mhSMqdMl1hKiQURG79Ykps= Received: by 10.210.25.19 with SMTP id 19mr9073452eby.27.1216055008411; Mon, 14 Jul 2008 10:03:28 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id m5sm732960gve.3.2008.07.14.10.03.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 14 Jul 2008 10:03:27 -0700 (PDT) To: mext@ietf.org From: Julien Laganier Date: Mon, 14 Jul 2008 19:03:26 +0200 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_eb4eITGR8UKBUfd" Message-Id: <200807141903.26551.julien.IETF@laposte.net> Subject: [MEXT] Adoption of draft-muhanna-mext-binding-revocation-02.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=_eb4eITGR8UKBUfd Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello Folks, The MEXT WG has a deliverable for Binding Revocation for IP Mobility. Hereby we'd like to ask WG participants whether or not they think this individual submission should be adopted as the corresponding MEXT work item. Please answer to this note to state your opinion by Monday July 28th. Thank you for your support, -- julien & marcelo, MEXT chairs A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Binding Revocation for IPv6 Mobility Author(s) : A. Muhanna, et al. Filename : draft-muhanna-mext-binding-revocation-02.txt Pages : 32 Date : 2008-07-11 This document defines the revocation semantics for terminating a mobile node's mobility session and associated resources. These semantics are generic enough and can be used by mobility entities in the case of Client Mobile IPv6 and its extensions. This mechanism allows the mobility entity which initiates the revocation procedure to request its corresponding one to terminate either one, multiple or all specified binding cache entries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding-revocation-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --Boundary-00=_eb4eITGR8UKBUfd Content-Type: message/rfc822; name="forwarded message" Content-Transfer-Encoding: 7bit Content-Description: Internet-Drafts@ietf.org: I-D Action:draft-muhanna-mext-binding-revocation-02.txt Content-Disposition: inline Return-Path: Received: from mwinf8213.laposte.net (mwinf8213.laposte.net) by mwinb8204 (SMTP Server) with LMTP; Fri, 11 Jul 2008 15:49:02 +0200 X-Sieve: Server Sieve 2.2 Received: from meplus.info (localhost [127.0.0.1]) by mwinf8213.laposte.net (SMTP Server) with ESMTP id 914FE240008B; Fri, 11 Jul 2008 15:49:02 +0200 (CEST) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mwinf8213.laposte.net (SMTP Server) with ESMTP id 2F42C2400083; Fri, 11 Jul 2008 15:49:02 +0200 (CEST) X-ME-UUID: 20080711134902193.2F42C2400083@mwinf8213.laposte.net Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE0A428C1A0; Fri, 11 Jul 2008 06:45:21 -0700 (PDT) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7C93B3A69D6; Fri, 11 Jul 2008 06:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-muhanna-mext-binding-revocation-02.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080711134501.7C93B3A69D6@core3.amsl.com> Date: Fri, 11 Jul 2008 06:45:01 -0700 (PDT) X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-me-spamlevel: not-spam X-me-spamrating: 40.000000 X-me-spamcause: OK, (-80)(0000)fghrlhcuvffnffculddvtddmneforghilhhinhhgnfhishhtucdlqddutddtmd X-me-spamwebmail: HAM X-UID: 71190 X-Length: 3927 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Binding Revocation for IPv6 Mobility Author(s) : A. Muhanna, et al. Filename : draft-muhanna-mext-binding-revocation-02.txt Pages : 32 Date : 2008-07-11 This document defines the revocation semantics for terminating a mobile node's mobility session and associated resources. These semantics are generic enough and can be used by mobility entities in the case of Client Mobile IPv6 and its extensions. This mechanism allows the mobility entity which initiates the revocation procedure to request its corresponding one to terminate either one, multiple or all specified binding cache entries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding-revocation-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-muhanna-mext-binding-revocation-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-11064400.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- --Boundary-00=_eb4eITGR8UKBUfd 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 --Boundary-00=_eb4eITGR8UKBUfd-- From mext-bounces@ietf.org Mon Jul 14 10:13:35 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F35E3A69AF; Mon, 14 Jul 2008 10:13:35 -0700 (PDT) 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 0D2BF3A6809 for ; Mon, 14 Jul 2008 10:13:34 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYAeJ8aXgJI0 for ; Mon, 14 Jul 2008 10:13:33 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 203BA3A69AF for ; Mon, 14 Jul 2008 10:13:33 -0700 (PDT) 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 m6EHC6Q03020; Mon, 14 Jul 2008 17:12:06 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Jul 2008 12:13:51 -0500 Message-ID: In-Reply-To: <200807141903.00610.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Adoption of draft-haley-mext-generic-signaling-message-01.txt thread-index: Acjl1B3mVcpNTaU1RC+EFH+ALDRxiAAAK03w References: <200807141903.00610.julien.IETF@laposte.net> From: "Ahmad Muhanna" To: "Julien Laganier" , Subject: Re: [MEXT] Adoption of draft-haley-mext-generic-signaling-message-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 Julien, I support the adoption of this draft as WG items. Regards, Ahmad > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Julien Laganier > Sent: Monday, July 14, 2008 12:03 PM > To: mext@ietf.org > Subject: [MEXT] Adoption of > draft-haley-mext-generic-signaling-message-01.txt > > Hello Folks, > > The MEXT WG has a deliverable for a Generic Signaling Message > for MIPv6. > > Hereby we'd like to ask WG participants whether or not they > think this individual submission should be adopted as the > corresponding MEXT work item. Please answer to this note to > state your opinion by Monday July 28th. > > Thank you for your support, > > -- julien & marcelo, MEXT chairs > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 10:24:00 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35CEB28C155; Mon, 14 Jul 2008 10:24:00 -0700 (PDT) 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 96EE828C1E0 for ; Mon, 14 Jul 2008 10:23:59 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Htpfs3BpYSyh for ; Mon, 14 Jul 2008 10:23:58 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 6FA133A6B11 for ; Mon, 14 Jul 2008 10:23:58 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6EHOJE16172; Mon, 14 Jul 2008 17:24:19 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Jul 2008 12:24:17 -0500 Message-ID: In-Reply-To: <200807141903.26551.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Adoption of draft-muhanna-mext-binding-revocation-02.txt thread-index: Acjl1DzXl9DraIS7S5G52acyTYxvCAAAOU1A References: <200807141903.26551.julien.IETF@laposte.net> From: "Ahmad Muhanna" To: "Julien Laganier" , Subject: Re: [MEXT] Adoption of draft-muhanna-mext-binding-revocation-02.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 Julien, I support the adoption of this draft as WG item. Regards, Ahmad > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Julien Laganier > Sent: Monday, July 14, 2008 12:03 PM > To: mext@ietf.org > Subject: [MEXT] Adoption of > draft-muhanna-mext-binding-revocation-02.txt > > Hello Folks, > > The MEXT WG has a deliverable for Binding Revocation for IP Mobility. > > Hereby we'd like to ask WG participants whether or not they > think this individual submission should be adopted as the > corresponding MEXT work item. Please answer to this note to > state your opinion by Monday July 28th. > > Thank you for your support, > > -- julien & marcelo, MEXT chairs > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > Title : Binding Revocation for IPv6 Mobility > Author(s) : A. Muhanna, et al. > Filename : draft-muhanna-mext-binding-revocation-02.txt > Pages : 32 > Date : 2008-07-11 > > This document defines the revocation semantics for > terminating a mobile node's mobility session and associated > resources. These semantics are generic enough and can be > used by mobility entities in the case of Client Mobile IPv6 > and its extensions. This mechanism allows the mobility > entity which initiates the revocation procedure to request > its corresponding one to terminate either one, multiple or > all specified binding cache entries. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding -revocation-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail > reader implementation to automatically retrieve the ASCII > version of the Internet-Draft. > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 10:46:15 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CBF83A6BF9; Mon, 14 Jul 2008 10:46:15 -0700 (PDT) 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 B5B253A68FA for ; Mon, 14 Jul 2008 10:46:14 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-TpMw3dCMVC for ; Mon, 14 Jul 2008 10:46:11 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id ADD073A6C12 for ; Mon, 14 Jul 2008 10:46:03 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6EHkPE21277; Mon, 14 Jul 2008 17:46:25 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Jul 2008 12:46:19 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Adoption of draft-haley-mext-generic-signaling-message-01.txt thread-index: Acjl1B3mVcpNTaU1RC+EFH+ALDRxiAAAK03wAAEjGCA= From: "Mohamed Khalil" To: "Julien Laganier" , Subject: Re: [MEXT] Adoption of draft-haley-mext-generic-signaling-message-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 I support adoption of the draft. > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Julien Laganier > Sent: Monday, July 14, 2008 12:03 PM > To: mext@ietf.org > Subject: [MEXT] Adoption of > draft-haley-mext-generic-signaling-message-01.txt > > Hello Folks, > > The MEXT WG has a deliverable for a Generic Signaling Message > for MIPv6. > > Hereby we'd like to ask WG participants whether or not they > think this individual submission should be adopted as the > corresponding MEXT work item. Please answer to this note to > state your opinion by Monday July 28th. > > Thank you for your support, > > -- julien & marcelo, MEXT chairs > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 10:55:39 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 908AD3A6C16; Mon, 14 Jul 2008 10:55:39 -0700 (PDT) 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 7A7A03A6C16 for ; Mon, 14 Jul 2008 10:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, 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 hCHMEuempEif for ; Mon, 14 Jul 2008 10:55:37 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 09AE73A6BFE for ; Mon, 14 Jul 2008 10:55:32 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Jul 2008 13:55:53 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Authentication option support in Binding Revocation Thread-Index: Acjjy4AUqtD1A+yKQ5qO5PriyNmT6AAC0PuAAA/2l3AAAFNH4AAKHHUgAGGL8wAABMimYA== References: <000601c8e369$530b9b80$5c0c7c0a@china.huawei.com><001201c8e36a$746e18b0$5c0c7c0a@china.huawei.com><003901c8e36c$02c6b850$5c0c7c0a@china.huawei.com><000e01c8e370$3f9f83c0$5c0c7c0a@china.huawei.com><005601c8e37f$90fc3a60$5c0c7c0a@china.huawei.com><008201c8e388$984a4240$5c0c7c0a@china.huawei.com><00bc01c8e39e$b644f6d0$5c0c7c0a@china.huawei.com><000a01c8e3a6$0e3cc8c0$5c0c7c0a@china.huawei.com> From: "Vijay Devarapalli" To: "Ahmad Muhanna" , "Sri Gundavelli" , "Frank Xia" Cc: Basavaraj Patil , mext@ietf.org Subject: Re: [MEXT] Authentication option support in Binding Revocation 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 Ahmad, You are unnecessarily complicating things. Let me try to clarify again. > -----Original Message----- > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > Sent: Monday, July 14, 2008 9:11 AM > To: Vijay Devarapalli; Sri Gundavelli; Frank Xia > Cc: mext@ietf.org; Basavaraj Patil; Chowdhury, Kuntal > Subject: RE: [MEXT] Authentication option support in Binding > Revocation > > Hi Vijay, > > I guess, It is not that simple:) One more thing to add here > is that the > whole discussion here is concentrated on supporting the Auth protocol > for Client MIP6 BCE. Otherwise, IMO, things is more complicated. > > MGSM is based on the security architecture of RFC3775. Generic signaling message just defines a new mobility header message (or two in fact) for signaling between mobility entities. The mobility entities include, the mobile node, MAG or the LMA. There is no such thing as "based on the security architecture of RFC 3775". > In the case of > PMIPv6 it is based on PMIPv6 base draft. On the other hand, let us not > forget that RFC4285 also, defines a replay protection mechanism for > Client MIP6 BU/BA. The same timestamp-based replay protection can be used here too. Nothing new needs to be specified. > IMO, the options here are as follows: > 1. Either MGSM need to have a normative reference to RFC4285, or I don't think you understand what a normative reference means. A normative reference is used when the mechanism described in a particular document cannot be implemented or understood without first understanding or implementing another mechanism in another draft. The Generic Signaling Message does not require RFC 4285 to be used. So 4285 would not be a normative reference. > 2. MGSM need to define all the details of a new security architecture > which cover all security threats including replay protection, etc. > > Looking at the current options, I believe that any attempt to > have MGSM > support auth protocol in the current timeframe is nothing but > more delay > to the completion of Binding Revocation. Of course not. You only need to specify how to calculate the MAG. I don't think anything more is needed. > Additionally, the mext wg > consensus call on Binding Revocation to use MGSM was based on the fact > that MGSM and Binding Revocation use the same security architecture as > in RFC3775 and PMIPv6 base draft which in itself is based on RFC3775. Can you point me to that? You are assuming a lot of stuff in the above sentence. > IMO, We need to specify the MGSM based on RFC3775 and PMIPv6 > base draft > without excluding the support for Auth protocol which can be added in > the future based on the consensus of the wg. The fact is there are systems that use RFC 4285. If these networks want to use the generic signaling messages, it obviously makes no sense saying IPsec/IKEv2 must be used. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 10:57:45 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2D283A6B81; Mon, 14 Jul 2008 10:57:45 -0700 (PDT) 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 2E5523A6B81 for ; Mon, 14 Jul 2008 10:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, 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 NJCZl22uvz5u for ; Mon, 14 Jul 2008 10:57:43 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 9FDB03A6A4E for ; Mon, 14 Jul 2008 10:57:41 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Jul 2008 13:58:02 -0400 Message-ID: In-Reply-To: <200807141903.00610.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Adoption of draft-haley-mext-generic-signaling-message-01.txt Thread-Index: Acjl1B8g8gvbNFkCTdKgoSitod8KkAABv3uQ References: <200807141903.00610.julien.IETF@laposte.net> From: "Vijay Devarapalli" To: "Julien Laganier" , Subject: Re: [MEXT] Adoption of draft-haley-mext-generic-signaling-message-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 Julien Laganier wrote: > Hello Folks, > > The MEXT WG has a deliverable for a Generic Signaling Message > for MIPv6. > > Hereby we'd like to ask WG participants whether or not they > think this > individual submission should be adopted as the corresponding > MEXT work > item. Please answer to this note to state your opinion by Monday July > 28th. I support adopting this document as a WG document. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 10:58:06 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41E6128C13B; Mon, 14 Jul 2008 10:58:06 -0700 (PDT) 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 D8C2228C0F4 for ; Mon, 14 Jul 2008 10:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, 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 lKpkLRNygaPx for ; Mon, 14 Jul 2008 10:58:05 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 114B828C13B for ; Mon, 14 Jul 2008 10:58:04 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Jul 2008 13:58:29 -0400 Message-ID: In-Reply-To: <200807141903.26551.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Adoption of draft-muhanna-mext-binding-revocation-02.txt Thread-Index: Acjl1DsJTCMRoRX6SheoClcN4fTqewABvG2w References: <200807141903.26551.julien.IETF@laposte.net> From: "Vijay Devarapalli" To: "Julien Laganier" , Subject: Re: [MEXT] Adoption of draft-muhanna-mext-binding-revocation-02.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 Julien Laganier wrote: > Hello Folks, > > The MEXT WG has a deliverable for Binding Revocation for IP Mobility. > > Hereby we'd like to ask WG participants whether or not they > think this > individual submission should be adopted as the corresponding > MEXT work > item. Please answer to this note to state your opinion by Monday July > 28th. I support adopting this document as a WG document. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 11:03:42 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 883693A6A4E; Mon, 14 Jul 2008 11:03:42 -0700 (PDT) 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 A28CD28C148 for ; Mon, 14 Jul 2008 11:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, 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 dVm1GrLkNAQF for ; Mon, 14 Jul 2008 11:03:39 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 78C893A6A4E for ; Mon, 14 Jul 2008 11:03:27 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Jul 2008 14:03:51 -0400 Message-ID: In-Reply-To: <200807141856.36985.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Authentication option support in Binding Revocation draft Thread-Index: Acjl0p4mOKXP4XBNQtaX+c3CkRk93QACJ45A References: <00bc01c8e39e$b644f6d0$5c0c7c0a@china.huawei.com> <200807141856.36985.julien.IETF@laposte.net> From: "Vijay Devarapalli" To: "Julien Laganier" , Subject: Re: [MEXT] Authentication option support in Binding Revocation 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 Julien, Julien Laganier wrote: > Hello Frank, and other interesting parties, > > I wish you had left the WG chair hat off for this email. > On Friday 11 July 2008, Frank Xia wrote: >> Hi Ahmad >> >> Upon your request, I initials this thread. >> >> 1) How are BRI/BRA messages secured when >> there is not IPsec SA between HA and MN? > > MIPv6 uses IPsec and IKE as a security mechanism, thus how > the BRI/BRA > messages are secured when there is no IPsec SA between HA and MN is > out-of scope for this WG. > >> 2)If authentication options defined in RFC4285 >> are used, which option should be used? >> MN-HA or MN-AAA? > > This is out-of scope for this WG as well. I disagree. RFC 4285 is a valid alternative to the use of IKE/IPsec for securing Binding Update and Binding Ack messages. Some of the SDOs have adopted this over the use of IKE/IPsec. If the systems that belong to these SDOs want to use the Generic Signaling Message, we should not require them to use IKEv2/IPsec. They obviously would want to use the same MN-HA key and the MN-HA authentication option for the Generic Signaling Messages too. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 11:23:49 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CCA228C0F4; Mon, 14 Jul 2008 11:23:49 -0700 (PDT) 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 D5B0B3A6994 for ; Mon, 14 Jul 2008 11:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, 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 p2VWvnFRhBPP for ; Mon, 14 Jul 2008 11:23:47 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 0D9F13A694C for ; Mon, 14 Jul 2008 11:23:46 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Jul 2008 14:24:11 -0400 Message-ID: In-Reply-To: <87bq157xpy.fsf@natisbad.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-00.txt Thread-Index: AcjjHafwX+zdfxJrSV+fGoLZTXF61QCwLVCQ References: <20080706174502.6A6393A68F3@core3.amsl.com><877ibudywp.fsf@natisbad.org> <87bq157xpy.fsf@natisbad.org> From: "Vijay Devarapalli" To: "Arnaud Ebalard" Cc: mext@ietf.org Subject: Re: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-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 Arnaud, Arnaud Ebalard wrote: > Hi Vijay, > > "Vijay Devarapalli" writes: > >>> No relation with the thread: are you aware of any implementation of >>> that mechanism? >> >> Open source or product implementations? > > both (but I think I already known the status for open source > implementations). One small note: i was asking about Home Address > assignment as described in 5026. I guess, I misunderstood your earlier email. I am not aware of any MIPv6 implementation that implements the RFC 5026 mechanism to assign a home address. I don't see any issues, though. Yes, you would need some interaction between the IKEv2 and MIPv6 modules to assign the address obtained via the configuration payload as the home address. >> The USAGI implementation might be supporting this. Check with them. > > I know the status of USAGI implementation: it does support (with > patches) setup of IPsec SA with IKE based on the Home Address, as > expected by MIPv6 main reference documents. > > - UMIP w/ patches (maintained) > - racoon w/patches (maintained) > - racoon2 w/ patches (not maintained) > > For 5026, none of previous elements supports it. Maybe, it just a matter of time. (?) Vijay > >> The last time I worked on a MIPv6 implementation was back in >> 2005. There was no IKEv2 spec for MIPv6 back then. > > ack. > > Thanks for your reply, > > a+ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 11:30:19 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 752DC28C2E4; Mon, 14 Jul 2008 11:30:19 -0700 (PDT) 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 E12FC28C2E4 for ; Mon, 14 Jul 2008 11:30:18 -0700 (PDT) X-Quarantine-ID: <5nPj9HbGt22p> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: illegal encoding [quoted-printable] for MIME type message/external-body X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nPj9HbGt22p for ; Mon, 14 Jul 2008 11:30:17 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 7696428C2DF for ; Mon, 14 Jul 2008 11:30:17 -0700 (PDT) Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 5C6807A4D7E for ; Mon, 14 Jul 2008 20:30:42 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: mext@ietf.org Organization: Universidad Carlos III de Madrid Date: Mon, 14 Jul 2008 20:30:41 +0200 Message-Id: <1216060241.4566.82.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Subject: [MEXT] [Fwd: I-D Action:draft-bernardos-mext-nemo-ro-cr-00.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1280325723==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1280325723== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-VDsydoeWdewutaCOARbl" --=-VDsydoeWdewutaCOARbl Content-Type: multipart/mixed; boundary="=-OfUSiH4MRJ+yNTf22vPO" --=-OfUSiH4MRJ+yNTf22vPO Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi, We've submitted a draft revisiting the Correspondent Router based NEMO RO approach. Comments are welcome. Thanks, Carlos --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-OfUSiH4MRJ+yNTf22vPO Content-Disposition: inline Content-Description: Mensaje reenviado: I-D Action:draft-bernardos-mext-nemo-ro-cr-00.txt Content-Type: message/rfc822 Return-Path: Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by shem.uc3m.es (Postfix) with ESMTP id F293E16336; Mon, 7 Jul 2008 21:48:51 +0200 (CEST) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32])by smtp02.uc3m.es (Postfix) with ESMTP id 518FD3E20A8;Mon, 7 Jul 2008 21:48:51 +0200 (CEST) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0)id 6B7113A6B0B; Mon, 7 Jul 2008 12:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-bernardos-mext-nemo-ro-cr-00.txt Content-Type: Multipart/Mixed; Boundary=NextPart Mime-Version: 1.0 Message-Id: <20080707194502.6B7113A6B0B@core3.amsl.com> Date: Mon, 7 Jul 2008 12:45:02 -0700 (PDT) X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:N SM:2 X-imss-tmaseResult: TT:1 TS:-2.5064 TC:1F TRN:47 TV:5.5.1026(16018.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) --NextPart Content-Transfer-Encoding: quoted-printable A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Correspondent Router based Route Optimisation for NEMO (= CRON) Author(s) : C. Bernardos, et al. Filename : draft-bernardos-mext-nemo-ro-cr-00.txt Pages : 23 Date : 2008-07-07 The Network Mobility Basic Support protocol enables networks to roam and attach to different access networks without disrupting the ongoing sessions that nodes of the network may have. By extending the Mobile IPv6 support to Mobile Routers, nodes of the network are not required to support any kind of mobility, since packets must go through the Mobile Router-Home Agent (MRHA) bi-directional tunnel. Communications from/to a mobile network have to traverse the Home Agent, and therefore better paths may be available. Additionally, this solution adds packet overhead, due to the encapsulation. This document describes an approach to the Route Optimisation for NEMO, based on the well-known concept of Correspondent Router. The solution aims at meeting the currently identified NEMO Route Optimisation requirements for Operational Use in Aeronautics and Space Exploration. Based on the ideas that have been proposed in the past, as well as some other extensions, this document describes a Correspondent Router based solution, trying to identify the most important open issues. The main goal of this first version of the document is to describe an initial NEMO RO solution based on the deployment of Correspondent Routers and trigger the discussion within the MEXT WG about this kind of solution. This document (in an appendix) also analyses how a Correspondent Router based solution fits each of the currently identified NEMO Route Optimisation requirements for Operational Use in Aeronautics and Space Exploration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bernardos-mext-nemo-ro-cr-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-bernardos-mext-nemo-ro-cr-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Content-ID: <2008-07-07123139.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- --=-OfUSiH4MRJ+yNTf22vPO-- --=-VDsydoeWdewutaCOARbl Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIe5tRNdy6TdFwT2cRAm/SAJ9enUy+xtrdn19kOv/zcpVeylwNLACbBEp+ gWQXbxN5N45A9i2NQzYCLYU= =HPDt -----END PGP SIGNATURE----- --=-VDsydoeWdewutaCOARbl-- --===============1280325723== 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 --===============1280325723==-- From mext-bounces@ietf.org Mon Jul 14 12:03:00 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E78B528C38D; Mon, 14 Jul 2008 12:03:00 -0700 (PDT) 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 8124028C38D for ; Mon, 14 Jul 2008 12:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.847 X-Spam-Level: X-Spam-Status: No, score=-3.847 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xw9acYaWjukL for ; Mon, 14 Jul 2008 12:02:58 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 4104E28C291 for ; Mon, 14 Jul 2008 12:02:16 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (14.pool85-53-137.dynamic.orange.es [85.53.137.14])by smtp03.uc3m.es (Postfix) with ESMTP id C6977487BF4; Mon, 14 Jul 2008 21:02:40 +0200 (CEST) Message-ID: <487BA2CF.9090908@it.uc3m.es> Date: Mon, 14 Jul 2008 21:02:39 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Vijay Devarapalli References: <00b c 01c8e39e$b644f6d0$5c0c7c0a@china.huawei.com><200807141856.36985.julien.IE TF@laposte.net> In-Reply-To: X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-22.2875 TC:1F TRN:53 TV:5.5.1026(16032.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: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Authentication option support in Binding Revocation 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-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Vijay, speaking as a chair as well below... Vijay Devarapalli escribi=F3: > Hi Julien, > > Julien Laganier wrote: > = >> Hello Frank, and other interesting parties, >> >> >> = > > I wish you had left the WG chair hat off for this email. = > > = >> On Friday 11 July 2008, Frank Xia wrote: >> = >>> Hi Ahmad >>> >>> Upon your request, I initials this thread. >>> >>> 1) How are BRI/BRA messages secured when >>> there is not IPsec SA between HA and MN? >>> = >> MIPv6 uses IPsec and IKE as a security mechanism, thus how >> the BRI/BRA >> messages are secured when there is no IPsec SA between HA and MN is >> out-of scope for this WG. = >> >> = >>> 2)If authentication options defined in RFC4285 >>> are used, which option should be used? >>> MN-HA or MN-AAA? >>> = >> This is out-of scope for this WG as well. >> = > > I disagree. RFC 4285 is a valid alternative to the use of IKE/IPsec for > securing Binding Update and Binding Ack messages. Some of the SDOs have > adopted this over the use of IKE/IPsec. If the systems that belong to > these SDOs want to use the Generic Signaling Message, we should not > require them to use IKEv2/IPsec. They obviously would want to use the > same MN-HA key and the MN-HA authentication option for the Generic > Signaling Messages too. = > > = we have very clear guidance on this see the MEXT charter: The group employs IPsec and IKE as a security mechanism. The group shall refrain, however, from making generic extensions to these protocols. Any proposed extension must be reviewed by the INT and SEC ADs before it can be accepted as a part of a work item. any work in using other security mechanisms need to be approved by SEC = and INT ADs Regards, marcelo > Vijay > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 12:07:08 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 400B63A6875; Mon, 14 Jul 2008 12:07:08 -0700 (PDT) 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 106793A6A18 for ; Mon, 14 Jul 2008 12:07:08 -0700 (PDT) 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.105, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jq++GTkjDGgl for ; Mon, 14 Jul 2008 12:07:07 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 4EF8A3A6875 for ; Mon, 14 Jul 2008 12:06:26 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K40005NEFRFT5@usaga04-in.huawei.com> for mext@ietf.org; Mon, 14 Jul 2008 14:06:52 -0500 (CDT) Received: from X24512z ([10.124.12.92]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K4000A6QFREFD@usaga04-in.huawei.com> for mext@ietf.org; Mon, 14 Jul 2008 14:06:51 -0500 (CDT) Date: Mon, 14 Jul 2008 14:06:50 -0500 From: Frank Xia To: Julien Laganier , mext@ietf.org Message-id: <006d01c8e5e4$c5988370$5c0c7c0a@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: <200807141903.00610.julien.IETF@laposte.net> Subject: Re: [MEXT] Adoption of draft-haley-mext-generic-signaling-message-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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org +1 Support ----- Original Message ----- From: "Julien Laganier" To: Sent: Monday, July 14, 2008 12:03 PM Subject: [MEXT] Adoption of draft-haley-mext-generic-signaling-message-01.txt > Hello Folks, > > The MEXT WG has a deliverable for a Generic Signaling Message for MIPv6. > > Hereby we'd like to ask WG participants whether or not they think this > individual submission should be adopted as the corresponding MEXT work > item. Please answer to this note to state your opinion by Monday July > 28th. > > Thank you for your support, > > -- julien & marcelo, MEXT chairs > -------------------------------------------------------------------------------- > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 12:07:10 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C35A128C213; Mon, 14 Jul 2008 12:07:10 -0700 (PDT) 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 89EE23A68D9 for ; Mon, 14 Jul 2008 12:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KxAVkX0kREj for ; Mon, 14 Jul 2008 12:07:08 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id D4BF63A6A7D for ; Mon, 14 Jul 2008 12:06:31 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K40005PPFRLT5@usaga04-in.huawei.com> for mext@ietf.org; Mon, 14 Jul 2008 14:06:58 -0500 (CDT) Received: from X24512z ([10.124.12.92]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K40008XJFRLA3@usaga04-in.huawei.com> for mext@ietf.org; Mon, 14 Jul 2008 14:06:57 -0500 (CDT) Date: Mon, 14 Jul 2008 14:06:57 -0500 From: Frank Xia To: Julien Laganier , mext@ietf.org Message-id: <007f01c8e5e4$c97f81a0$5c0c7c0a@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: <200807141903.26551.julien.IETF@laposte.net> Subject: Re: [MEXT] Adoption of draft-muhanna-mext-binding-revocation-02.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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org +1 Support ----- Original Message ----- From: "Julien Laganier" To: Sent: Monday, July 14, 2008 12:03 PM Subject: [MEXT] Adoption of draft-muhanna-mext-binding-revocation-02.txt > Hello Folks, > > The MEXT WG has a deliverable for Binding Revocation for IP Mobility. > > Hereby we'd like to ask WG participants whether or not they think this > individual submission should be adopted as the corresponding MEXT work > item. Please answer to this note to state your opinion by Monday July > 28th. > > Thank you for your support, > > -- julien & marcelo, MEXT chairs > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Binding Revocation for IPv6 Mobility > Author(s) : A. Muhanna, et al. > Filename : draft-muhanna-mext-binding-revocation-02.txt > Pages : 32 > Date : 2008-07-11 > > This document defines the revocation semantics for terminating a > mobile node's mobility session and associated resources. These > semantics are generic enough and can be used by mobility entities in > the case of Client Mobile IPv6 and its extensions. This mechanism > allows the mobility entity which initiates the revocation procedure > to request its corresponding one to terminate either one, multiple or > all specified binding cache entries. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding-revocation-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 12:11:18 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 158FE3A6B03; Mon, 14 Jul 2008 12:11:18 -0700 (PDT) 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 2DF3028C0D9 for ; Mon, 14 Jul 2008 12:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.215, 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 d8w-cV7mcspZ for ; Mon, 14 Jul 2008 12:11:16 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id C728028C28E for ; Mon, 14 Jul 2008 12:10:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=M/lw6Z96FK5vj31fmS6re3+/0kJ+B64VO5McKrzm4bevvgyaasziFAUnHe89Ucx+; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [75.26.137.116] (helo=[10.166.255.89]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1KITSE-0004YH-Nk; Mon, 14 Jul 2008 15:11:22 -0400 Message-ID: <487BA4D8.5040504@earthlink.net> Date: Mon, 14 Jul 2008 12:11:20 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Vijay Devarapalli X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52aba4567c6f8ec27b2a1e8c2e52a1f342350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Cc: mext@ietf.org Subject: [MEXT] Ticket for "References to Bootstrapping" in [mext] issue tracker 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Vijay, This is the text you proposed for inclusion in rfc3775bis: > This document assumes that the mobile node is configured with the home > prefix for the mobile node to be able to discover a home agent and > configure a home address. This might be limiting in deployments where > the home agent and the home address for the mobile node needs to be > assigned dynamically. Additional mechanisms have been specified for > the mobile node to dynamically configure a home agent, a home address > and the home prefix. These mechanisms are described in [38] and [39]. > > [38] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 > Bootstrapping in Split Scenario", RFC 5026, October 2007. > > [39] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the > Integrated Scenario", > draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in > progress), July 2007. This seems to be agreeable with the people on the mailing list, so I would propose to adopt this update into the next revision of rfc3775bis. I would like to slightly reword the first sentence as follows: This document has been written under the assumption that the mobile node has knowledge of the home prefix, so that the mobile node can discover a home agent and configure a home address. I will go ahead and create the issue, and look for any comments on the proposed adoption. Regards, Charlie P. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 12:12:42 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CBF428C26B; Mon, 14 Jul 2008 12:12:42 -0700 (PDT) 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 C61E228C26B for ; Mon, 14 Jul 2008 12:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, 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 ZUUt3DDkkgXf for ; Mon, 14 Jul 2008 12:12:40 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 6709A28C29B for ; Mon, 14 Jul 2008 12:12:34 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Jul 2008 15:12:58 -0400 Message-ID: In-Reply-To: <487BA2CF.9090908@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Authentication option support in Binding Revocation draft Thread-Index: Acjl5EgHpQdbuziHTLGE0bwL+xNwuQAAKIDA References: <00bc 01c8e39e$b644f6d0$5c0c7c0a@china.huawei.com><200807141856.36985.julien.IETF@laposte.net> <487BA2CF.9090908@it.uc3m.es> From: "Vijay Devarapalli" To: "marcelo bagnulo braun" Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Authentication option support in Binding Revocation 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 Marcelo, marcelo bagnulo braun wrote: > we have very clear guidance on this > > see the MEXT charter: > > The group employs IPsec and IKE as a security mechanism. The group > shall refrain, however, from making generic extensions to these > protocols. Any proposed extension must be reviewed by the INT and SEC > ADs before it can be accepted as a part of a work item. The last sentence says any extensions to IKEv2 and IPsec should be reviewed by the INT and SEC ADs before being adopted as WG items. > any work in using other security mechanisms need to be > approved by SEC > and INT Ads The charter does not say this. Perhaps I am missing something. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 12:13:29 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1FD128C2B8; Mon, 14 Jul 2008 12:13:28 -0700 (PDT) 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 84DD428C2B8 for ; Mon, 14 Jul 2008 12:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, 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 eblME4LkHXdm for ; Mon, 14 Jul 2008 12:13:26 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 2518A28C2A9 for ; Mon, 14 Jul 2008 12:13:25 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Jul 2008 15:13:48 -0400 Message-ID: In-Reply-To: <487BA4D8.5040504@earthlink.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ticket for "References to Bootstrapping" in [mext] issue tracker Thread-Index: Acjl5Wg05T1Q8IgcSvaU90kTLtOBUQAAExoA References: <487BA4D8.5040504@earthlink.net> From: "Vijay Devarapalli" To: "Charles E. Perkins" Cc: mext@ietf.org Subject: Re: [MEXT] Ticket for "References to Bootstrapping" in [mext] issue tracker 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 Charles E. Perkins wrote: > Hello Vijay, > > This is the text you proposed for inclusion in rfc3775bis: > >> This document assumes that the mobile node is configured with the >> home prefix for the mobile node to be able to discover a home >> agent and configure a home address. This might be limiting in >> deployments where the home agent and the home address for the >> mobile node needs to be assigned dynamically. Additional >> mechanisms have been specified for the mobile node to dynamically >> configure a home agent, a home address and the home prefix. These >> mechanisms are described in [38] and [39]. >> >> [38] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 >> Bootstrapping in Split Scenario", RFC 5026, October 2007. >> >> [39] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the >> Integrated Scenario", >> draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in >> progress), July 2007. > > This seems to be agreeable with the people on the mailing list, > so I would propose to adopt this update into the next revision > of rfc3775bis. I would like to slightly reword the first sentence as > follows: > > This document has been written under the assumption that the > mobile node has knowledge of the home prefix, so that the mobile > node can discover a home agent and configure a home address. Fine with me. Vijay > > I will go ahead and create the issue, and look for any comments > on the proposed adoption. > > Regards, > Charlie P. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 12:20:55 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F14773A6A18; Mon, 14 Jul 2008 12:20:54 -0700 (PDT) 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 EE7E53A68D2 for ; Mon, 14 Jul 2008 12:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.826 X-Spam-Level: X-Spam-Status: No, score=-3.826 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6RBx0GyofH5 for ; Mon, 14 Jul 2008 12:20:53 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 935443A69E1 for ; Mon, 14 Jul 2008 12:20:50 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (14.pool85-53-137.dynamic.orange.es [85.53.137.14])by smtp03.uc3m.es (Postfix) with ESMTP id 06E1B487BEE; Mon, 14 Jul 2008 21:21:14 +0200 (CEST) Message-ID: <487BA72A.5070902@it.uc3m.es> Date: Mon, 14 Jul 2008 21:21:14 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Vijay Devarapalli References: <00 b c 01c8e39e$b644f6d0$5c0c7c0a@china.huawei.com><200807141856.36985.julien. IE TF@laposte.net> <487BA2CF.9090908@it.uc3m.es> In-Reply-To: X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-12.3045 TC:1F TRN:35 TV:5.5.1026(16032.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: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Authentication option support in Binding Revocation 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-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Vijay Devarapalli escribi=F3: > Hi Marcelo, > > marcelo bagnulo braun wrote: > > = >> we have very clear guidance on this >> >> see the MEXT charter: >> >> The group employs IPsec and IKE as a security mechanism. The group >> shall refrain, however, from making generic extensions to these >> protocols. Any proposed extension must be reviewed by the INT and SEC >> ADs before it can be accepted as a part of a work item. >> = > > The last sentence says any extensions to IKEv2 and IPsec should be > reviewed by the INT and SEC ADs before being adopted as WG items. > > = >> any work in using other security mechanisms need to be >> approved by SEC >> and INT Ads >> = > > The charter does not say this. Perhaps I am missing something. > = The very first sentence reads: The group employs IPsec and IKE as a security mechanism. To me that means that whatever mechanism we define must work with IPSec IKE= security and that it is out of the scope to do work on security based on o= ther mechanism. This means to me, that if we define an extension, we need to secure it usin= g IPSec/IKE and that security based on other approaches is out of the scope= and needs to be explicitly reviewed by INT and SEC ADs. That is our reading of the charter. We may ask for guidance from INT and SE= C ADs if people think that we are reading it wrong, no problem with that. = regards, marcelo > Vijay > > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 12:25:08 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55B6428C325; Mon, 14 Jul 2008 12:25:08 -0700 (PDT) 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 CDAB828C36A for ; Mon, 14 Jul 2008 12:25:07 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtiYjs2uOgMp for ; Mon, 14 Jul 2008 12:25:06 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 6051128C27D for ; Mon, 14 Jul 2008 12:21:53 -0700 (PDT) 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 m6EJLpd02229; Mon, 14 Jul 2008 19:21:51 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Jul 2008 14:21:50 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Authentication option support in Binding Revocation thread-index: Acjjy4AUqtD1A+yKQ5qO5PriyNmT6AAC0PuAAA/2l3AAAFNH4AAKHHUgAGGL8wAABMimYAAAe+WA References: <000601c8e369$530b9b80$5c0c7c0a@china.huawei.com><001201c8e36a$746e18b0$5c0c7c0a@china.huawei.com><003901c8e36c$02c6b850$5c0c7c0a@china.huawei.com><000e01c8e370$3f9f83c0$5c0c7c0a@china.huawei.com><005601c8e37f$90fc3a60$5c0c7c0a@china.huawei.com><008201c8e388$984a4240$5c0c7c0a@china.huawei.com><00bc01c8e39e$b644f6d0$5c0c7c0a@china.huawei.com><000a01c8e3a6$0e3cc8c0$5c0c7c0a@china.huawei.com> From: "Ahmad Muhanna" To: "Vijay Devarapalli" , "Sri Gundavelli" , "Frank Xia" Cc: Basavaraj Patil , mext@ietf.org Subject: Re: [MEXT] Authentication option support in Binding Revocation 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, Please see inline. Regards, Ahmad > Subject: RE: [MEXT] Authentication option support in Binding > Revocation > > Hello Ahmad, > > You are unnecessarily complicating things. Let me try to > clarify again. [Ahmad] I hope you are right:) > > > Subject: RE: [MEXT] Authentication option support in Binding > > Revocation > > > > Hi Vijay, > > > > I guess, It is not that simple:) One more thing to add here is that > > the whole discussion here is concentrated on supporting the Auth > > protocol for Client MIP6 BCE. Otherwise, IMO, things is more > > complicated. > > > > MGSM is based on the security architecture of RFC3775. > > Generic signaling message just defines a new mobility header > message (or two in fact) for signaling between mobility > entities. The mobility entities include, the mobile node, MAG > or the LMA. There is no such thing as "based on the security > architecture of RFC 3775". [Ahmad] What do you mean by there is not such thing? What I meant to say here is "the choice of IPsec based on IKE is a security architecture decision". Because, it addresses all the security concerns that are needed to secure the MIP6 signaling between the MN and the HA, for example: 1. IPsec with IKE is known to address replay protection. 2. IPsec is known to provide confidentiality. 3. IPsec is known to provide integrity protection. 4. IKE is used to dynamically derive the IPsec SA that is needed to secure the MIP6 signaling. 5. IKE has a mechanism to update the IPsec SA dynamically based on the SA lifetime, 6. etc. Not only that but there are two RFCs (3776 & 4877) that have been developed to allow/explain IPsec/IKE address the specific need of MIP6 signaling. If that is not an architectural decision, I am not sure what it is? However, we can continue discussing this offlist, if needed. > > > In the case of > > PMIPv6 it is based on PMIPv6 base draft. On the other hand, > let us not > > forget that RFC4285 also, defines a replay protection mechanism for > > Client MIP6 BU/BA. > > The same timestamp-based replay protection can be used here > too. Nothing new needs to be specified. > > > IMO, the options here are as follows: > > 1. Either MGSM need to have a normative reference to RFC4285, or > > I don't think you understand what a normative reference > means. A normative reference is used when the mechanism > described in a particular document cannot be implemented or > understood without first understanding or implementing > another mechanism in another draft. The Generic Signaling > Message does not require RFC 4285 to be used. So 4285 would > not be a normative reference. [Ahmad] Okay, Thanks!:) May be I am missing something here, but does not your definition contradict your above comment about the time-stamp based replay protection, where you said it can be used.? Also, In order to support IPsec, either a proper IPsec reference is made or a short cut to RFC3775. Therefore, if Auth protocol is to be used, we either reference a document which introduced this protocol or redefine it, which what I was trying to say. > > > 2. MGSM need to define all the details of a new security > architecture > > which cover all security threats including replay protection, etc. > > > > Looking at the current options, I believe that any attempt to have > > MGSM support auth protocol in the current timeframe is nothing but > > more delay to the completion of Binding Revocation. > > Of course not. You only need to specify how to calculate the > MAG. I don't think anything more is needed. [Ahmad] I assume you meant to say the MAC. Okay, but what is needed is a secure mechanism that address all security concerns and threats. We can call it whatever appropriate. IMO, that is not a trivial thing. > > > Additionally, the mext wg > > consensus call on Binding Revocation to use MGSM was based > on the fact > > that MGSM and Binding Revocation use the same security > architecture as > > in RFC3775 and PMIPv6 base draft which in itself is based > on RFC3775. > > Can you point me to that? You are assuming a lot of stuff in > the above sentence. [Ahmad] No I did not assume anything, but the consensus call was based on all the discussion that took place on the mailing list and based on the content of these drafts. What I meant, we never talked about the support of Auth protocol before now. Also, neither one of the documents ever referenced in any normative or informative manner RFC4285 or Auth protocol. > > > IMO, We need to specify the MGSM based on RFC3775 and PMIPv6 base > > draft without excluding the support for Auth protocol which can be > > added in the future based on the consensus of the wg. > > The fact is there are systems that use RFC 4285. If these > networks want to use the generic signaling messages, it > obviously makes no sense saying IPsec/IKEv2 must be used. [Ahmad] That is why I said the following: "without excluding the support for Auth protocol which can be added in the future based on the consensus of the wg." > > Vijay > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 12:30:05 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A2C228C38B; Mon, 14 Jul 2008 12:30:05 -0700 (PDT) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id CB9B328C20B; Mon, 14 Jul 2008 12:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080714193001.CB9B328C20B@core3.amsl.com> Date: Mon, 14 Jul 2008 12:30:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D ACTION:draft-ietf-mext-rfc3775bis-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 : Mobility Support in IPv6 Author(s) : D. Johnson, C. Perkins, J. Arkko Filename : draft-ietf-mext-rfc3775bis-01.txt Pages : 172 Date : 2008-7-14 This document specifies a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-rfc3775bis-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mext-rfc3775bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-7-14121618.I-D@ietf.org> --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 https://www.ietf.org/mailman/listinfo/mext --NextPart-- From mext-bounces@ietf.org Mon Jul 14 12:31:46 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C36D228C291; Mon, 14 Jul 2008 12:31:46 -0700 (PDT) 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 3113128C213 for ; Mon, 14 Jul 2008 12:31:45 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeAcusfTmFq6 for ; Mon, 14 Jul 2008 12:31:44 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id B190728C353 for ; Mon, 14 Jul 2008 12:31:16 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6EJVSfZ003419; Mon, 14 Jul 2008 22:31:40 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jul 2008 22:31:32 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jul 2008 14:31:12 -0500 Received: from 172.19.60.172 ([172.19.60.172]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Mon, 14 Jul 2008 19:31:12 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Mon, 14 Jul 2008 14:31:12 -0500 From: Basavaraj Patil To: ext Vijay Devarapalli , Julien Laganier , Message-ID: Thread-Topic: [MEXT] Authentication option support in Binding Revocation draft Thread-Index: Acjl0p4mOKXP4XBNQtaX+c3CkRk93QACJ45AAAM8AVg= In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 14 Jul 2008 19:31:12.0484 (UTC) FILETIME=[2CAE1A40:01C8E5E8] X-Nokia-AV: Clean Subject: Re: [MEXT] Authentication option support in Binding Revocation 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 On 7/14/08 1:03 PM, "ext Vijay Devarapalli" wrote: >> >>> 2)If authentication options defined in RFC4285 >>> are used, which option should be used? >>> MN-HA or MN-AAA? >> >> This is out-of scope for this WG as well. > > I disagree. RFC 4285 is a valid alternative to the use of IKE/IPsec for > securing Binding Update and Binding Ack messages. Some of the SDOs have > adopted this over the use of IKE/IPsec. If the systems that belong to > these SDOs want to use the Generic Signaling Message, we should not > require them to use IKEv2/IPsec. They obviously would want to use the > same MN-HA key and the MN-HA authentication option for the Generic > Signaling Messages too. I agree with Vijay here. RFC4285 (or the bis version) is a valid option for securing the signaling. -Raj > > Vijay > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 12:59:59 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AF7F3A6C13; Mon, 14 Jul 2008 12:59:59 -0700 (PDT) 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 99F443A6C0E for ; Mon, 14 Jul 2008 12:59:57 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpd6ZuX-MfCe for ; Mon, 14 Jul 2008 12:59:56 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id E334728C1AD for ; Mon, 14 Jul 2008 12:57:17 -0700 (PDT) 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 m6EJvCWO026611; Mon, 14 Jul 2008 22:57:40 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jul 2008 22:57:21 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jul 2008 14:57:12 -0500 Received: from 172.19.60.172 ([172.19.60.172]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Mon, 14 Jul 2008 19:57:12 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Mon, 14 Jul 2008 14:57:12 -0500 From: Basavaraj Patil To: Marcelo Bagnulo , Vijay Devarapalli Message-ID: Thread-Topic: [MEXT] Authentication option support in Binding Revocation draft Thread-Index: Acjl6845Ft7UKuxcQUW2/kLNNlSzsw== In-Reply-To: <487BA72A.5070902@it.uc3m.es> Mime-version: 1.0 X-OriginalArrivalTime: 14 Jul 2008 19:57:12.0624 (UTC) FILETIME=[CE989300:01C8E5EB] X-Nokia-AV: Clean Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Authentication option support in Binding Revocation 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Marcelo, IPsec/IKEv2 is the default mechanism for securing MIP6 signaling. However the use of RF4285 based security is allowed within certain boundaries. So it is a valid method within the scope of the MIP6 protocol and one that is actually specified as the default mode for MIP6 operation (eg. 3GPP2 and WiMAX). = Any extensions to IPsec/IKEv2 itself would need consideration by the Security AD. Or changing the default security model for MIP6 would require the SEC and INT AD views. But in the current thread I do not see that as an issue. -Raj On 7/14/08 2:21 PM, "Marcelo Bagnulo" wrote: > Vijay Devarapalli escribi=F3: >> Hi Marcelo, >> = >> marcelo bagnulo braun wrote: >> = >> = >>> we have very clear guidance on this >>> = >>> see the MEXT charter: >>> = >>> The group employs IPsec and IKE as a security mechanism. The group >>> shall refrain, however, from making generic extensions to these >>> protocols. Any proposed extension must be reviewed by the INT and SEC >>> ADs before it can be accepted as a part of a work item. >>> = >> = >> The last sentence says any extensions to IKEv2 and IPsec should be >> reviewed by the INT and SEC ADs before being adopted as WG items. >> = >> = >>> any work in using other security mechanisms need to be >>> approved by SEC >>> and INT Ads >>> = >> = >> The charter does not say this. Perhaps I am missing something. >> = > = > The very first sentence reads: > = > The group employs IPsec and IKE as a security mechanism. > = > To me that means that whatever mechanism we define must work with IPSec I= KE > security and that it is out of the scope to do work on security based on = other > mechanism. > = > This means to me, that if we define an extension, we need to secure it us= ing > IPSec/IKE and that security based on other approaches is out of the scope= and > needs to be explicitly reviewed by INT and SEC ADs. > = > = > That is our reading of the charter. We may ask for guidance from INT and = SEC > ADs if people think that we are reading it wrong, no problem with that. > = > = > regards, marcelo > = >> Vijay >> = >> = > = > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 13:03:51 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E5D03A6B03; Mon, 14 Jul 2008 13:03:51 -0700 (PDT) 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 60F5D3A6ADF for ; Mon, 14 Jul 2008 13:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxAZVmBD8AhH for ; Mon, 14 Jul 2008 13:03:49 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 2BCED3A680A for ; Mon, 14 Jul 2008 13:03:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1216065845; x=1247601845; h=x-mimeole:content-class:mime-version:content-type: content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator: thread-topic:thread-index:references:from:to:cc: x-originalarrivaltime:x-ironport-av; z=X-MimeOLE:=20Produced=20By=20Microsoft=20Exchange=20V6.5 |Content-class:=20urn:content-classes:message |MIME-Version:=201.0|Content-Type:=20text/plain=3B=0D=0A =09charset=3D"us-ascii"|Content-Transfer-Encoding:=20quot ed-printable|Subject:=20RE:=20[MEXT]=20Authentication=20o ption=20support=20in=20Binding=20Revocation|Date:=20Mon, =2014=20Jul=202008=2013:04:07=20-0700|Message-ID:=20|In-Reply-To:=20|X-MS-Has-Attach:=20 |X-MS-TNEF-Correlator:=20|Thread-Topic:=20[MEXT]=20Authen tication=20option=20support=20in=20Binding=20Revocation |Thread-Index:=20Acjjy4AUqtD1A+yKQ5qO5PriyNmT6AAC0PuAAA/2 l3AAAFNH4AAKHHUgAGsDB5A=3D|References:=20<00060 1c8e369$530b9b80$5c0c7c0a@china.huawei.com><001 201c8e36a$746e18b0$5c0c7c0a@china.huawei.com><0 03901c8e36c$02c6b850$5c0c7c0a@china.huawei.com> <000e01c8e370$3f9f83c0$5c0c7c0a@china.huawei.com><005601c8e37f$90fc3a60$5c0c7c0a@china.huawei.com><008201c8e388$984a4240$5c0c7c0a@china.huawei.com><00bc01c8e39e$b644f6d0$5c0c7c0a@china.huawei.com><000a01c8e3a6$0e3cc8c0$5c0c7c0a@china.huawei.com> =20=20|From:=20"Giaretta,=20Gerardo"=20|To:=20"Vijay=20Devarapalli"=20,=0D=0A=20=20=20=20=20=20=20=20"Ahmad=20Muh anna"=20,=0D=0A=20=20=20=20=20=20=20 =20"Sri=20Gundavelli"=20,=0D=0A=20=20 =20=20=20=20=20=20"Frank=20Xia"=20|Cc:=20"Basavaraj=20Patil"=20 ,=20|X-OriginalArrivalTime:=2014=20Jul=202 008=2020:04:04.0158=20(UTC)=20FILETIME=3D[C3E3ADE0:01C8E5 EC]|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5200,2160,5338"=3B =20a=3D"4699238"; bh=bhNa3y6N4rlcUIcUkEr0AEeEGB7vsrPNMeZmUtnJyX0=; b=XCeJZLItmNKqbDdszri/snoN1NxA4OfQEFdkPq1TVY7/jPNa39O78V0F 8bU6eCr1BSwe5PHn7Zi9O+S6BCpenmycqDWcsM8PmFCf2gh30VCzLpbrm 3HRfyCoQWtki432jQPyYsji0oK0W75Fu0oWdAiGyAXh3pPUQZGtspKvf9 8=; X-IronPort-AV: E=McAfee;i="5200,2160,5338"; a="4699238" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Jul 2008 13:04:05 -0700 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m6EK45F4023444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 14 Jul 2008 13:04:05 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m6EK44oG004731; Mon, 14 Jul 2008 13:04:04 -0700 Received: from NAEX12.na.qualcomm.com ([129.46.51.246]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jul 2008 13:04:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Jul 2008 13:04:07 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Authentication option support in Binding Revocation Thread-Index: Acjjy4AUqtD1A+yKQ5qO5PriyNmT6AAC0PuAAA/2l3AAAFNH4AAKHHUgAGsDB5A= References: <000601c8e369$530b9b80$5c0c7c0a@china.huawei.com><001201c8e36a$746e18b0$5c0c7c0a@china.huawei.com><003901c8e36c$02c6b850$5c0c7c0a@china.huawei.com><000e01c8e370$3f9f83c0$5c0c7c0a@china.huawei.com><005601c8e37f$90fc3a60$5c0c7c0a@china.huawei.com><008201c8e388$984a4240$5c0c7c0a@china.huawei.com><00bc01c8e39e$b644f6d0$5c0c7c0a@china.huawei.com><000a01c8e3a6$0e3cc8c0$5c0c7c0a@china.huawei.com> From: "Giaretta, Gerardo" To: "Vijay Devarapalli" , "Ahmad Muhanna" , "Sri Gundavelli" , "Frank Xia" X-OriginalArrivalTime: 14 Jul 2008 20:04:04.0158 (UTC) FILETIME=[C3E3ADE0:01C8E5EC] Cc: mext@ietf.org, Basavaraj Patil Subject: Re: [MEXT] Authentication option support in Binding Revocation 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 think the question is: do we really need to support RFC4285 for this? Where is that requirement coming from? I think there is a lot of time pressure for these drafts and it would be good to complete them without extending the support for rfc4285 which is still an Informational RFC as mentioned by Ahmad. Assuming there is some interest, I think a separate draft for the usage of authentication protocol with MGSM and BRI should be written. Gerardo > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Vijay Devarapalli > Sent: Saturday, July 12, 2008 9:59 AM > To: Ahmad Muhanna; Sri Gundavelli; Frank Xia > Cc: Basavaraj Patil; mext@ietf.org > Subject: Re: [MEXT] Authentication option support in Binding Revocation > > > My understanding that Mobile IPv6 Generic Signaling Message (MGSM) and > > Binding Revocation are proposed as standard track document. Therefore, > > before we start talking about adding Auth protocol support to MGSM and > > consequently Binding Revocation, we need to do something > > about RFC4285. > > This RFC is still an Informational one and my understanding a standard > > track doc can not reference an Informational one. > > It doesn't matter. The Generic Signaling Message just needs to describe > how to calculate the authentication data if the MN-HA authentication > option is used. RFC 4285 would be an Informational reference, since it > is not required for someone to use the Generic Signaling Message. > > Vijay > > > Any one knows what is the latest on RFC4285? Raj or Kuntal? > > > > Regards, > > Ahmad > > > > > -----Original Message----- > > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > > Behalf Of Muhanna, Ahmad (RICH1:2H10) > > > Sent: Saturday, July 12, 2008 7:05 AM > > > To: Vijay Devarapalli; Sri Gundavelli; Frank Xia > > > Cc: mext@ietf.org > > > Subject: Re: [MEXT] Authentication option support in Binding > > > Revocation > > > > > > Hi Vijay, > > > > > > > > Subject: Re: [MEXT] Authentication option support in Binding > > > > > Revocation > > > > > > > > > If there is a shared key between the mobile node and the > > > > home agent, > > > > > MN-HA Authentication option can be used. > > > > > > > > > > If there is a shared key between the mobile node and the > > > > AAA, MN-AAA > > > > > authentication option can be used. > > > > > > > > > > But you bring a good point, these options are defined to be > > > > carried in > > > > > BU/BA. We need to allow these options to be carried in Generic > > > > > Notification messages. > > > > > > > > Specifying the use of MN-HA authentication option with > > the Generic > > > > Signaling Message sounds good to me. I doubt if the MN-AAA > > > > authentication option will ever be used with the Generic > > Signaling > > > > Message, though. > > > > > > [Ahmad] > > > I agree. > > > If auth protocol to be used to authenticate the MIP6 Generic > > > Signaling Message, then it has to be the MN-HA AE in the case > > > of Client MIP6. > > > MN-AAA AE is used during the initial registration to help in > > > bootstrapping MN-HA SA if it is needed. After the MIP6 > > > session is established, it is assumed that MN-HA SA has been > > > established. > > > Therefore, MN-AAA AE has no value in this scenario. Not only > > > that, but it does not make sense either. > > > > > > > > > > > > > > Vijay > > > > _______________________________________________ > > > > MEXT mailing list > > > > MEXT@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 13:09:04 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA14B28C100; Mon, 14 Jul 2008 13:09:04 -0700 (PDT) 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 D49C828C100 for ; Mon, 14 Jul 2008 13:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CM46aWpYKyJp for ; Mon, 14 Jul 2008 13:09:03 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id ED3453A680A for ; Mon, 14 Jul 2008 13:09:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1216066169; x=1247602169; h=x-mimeole:content-class:mime-version:content-type: content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator: thread-topic:thread-index:references:from:to: x-originalarrivaltime:x-ironport-av; z=X-MimeOLE:=20Produced=20By=20Microsoft=20Exchange=20V6.5 |Content-class:=20urn:content-classes:message |MIME-Version:=201.0|Content-Type:=20text/plain=3B=0D=0A =09charset=3D"us-ascii"|Content-Transfer-Encoding:=20quot ed-printable|Subject:=20RE:=20[MEXT]=20Adoption=20of=20dr aft-muhanna-mext-binding-revocation-02.txt|Date:=20Mon, =2014=20Jul=202008=2013:09:28=20-0700|Message-ID:=20|In-Reply-To:=20<200807141903.26551.julien.IETF@lapost e.net>|X-MS-Has-Attach:=20|X-MS-TNEF-Correlator:=20 |Thread-Topic:=20[MEXT]=20Adoption=20of=20draft-muhanna-m ext-binding-revocation-02.txt|Thread-Index:=20Acjl1ENOB4c +X2MdSOKO6Sf8KVDOfAAGTlJw|References:=20<200807141903.265 51.julien.IETF@laposte.net>|From:=20"Giaretta,=20Gerardo" =20|To:=20"Julien=20Laganier"=20,=20 |X-OriginalArrivalTime:=2014=20Jul=202008=2020:09:26.0230 =20(UTC)=20FILETIME=3D[83DBF760:01C8E5ED]|X-IronPort-AV: =20E=3DMcAfee=3Bi=3D"5200,2160,5338"=3B=20a=3D"4529386"; bh=HC8YibGHBjWw0EsCDo8fv5h1AD0lYB3Iq6ewmZQjAFc=; b=Ko2emoHQyBI0pGm+JAAUxqqnGLunKLc/hjTtQ/fM/+7XRJoq9+yScdIF x0wCTJGmsHNmF8GLDDcSika8DEoOIL3DHkc1vCrqzusAl/gF6PWvVZL8u M7BEDOTFhVmz4Zl1oIc9QiJdPTxh4xsWrxgC7jRkUlbJTBhvbzmfUzzWt U=; X-IronPort-AV: E=McAfee;i="5200,2160,5338"; a="4529386" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Jul 2008 13:09:29 -0700 Received: from msgtransport06.qualcomm.com (msgtransport06.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m6EK9Slo024983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 14 Jul 2008 13:09:29 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by msgtransport06.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m6EK9OK5003665; Mon, 14 Jul 2008 13:09:28 -0700 Received: from NAEX12.na.qualcomm.com ([129.46.51.246]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jul 2008 13:09:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Jul 2008 13:09:28 -0700 Message-ID: In-Reply-To: <200807141903.26551.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Adoption of draft-muhanna-mext-binding-revocation-02.txt Thread-Index: Acjl1ENOB4c+X2MdSOKO6Sf8KVDOfAAGTlJw References: <200807141903.26551.julien.IETF@laposte.net> From: "Giaretta, Gerardo" To: "Julien Laganier" , X-OriginalArrivalTime: 14 Jul 2008 20:09:26.0230 (UTC) FILETIME=[83DBF760:01C8E5ED] Subject: Re: [MEXT] Adoption of draft-muhanna-mext-binding-revocation-02.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 Julien, I support this draft Gerardo > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Julien Laganier > Sent: Monday, July 14, 2008 10:03 AM > To: mext@ietf.org > Subject: [MEXT] Adoption of draft-muhanna-mext-binding-revocation-02.txt > > Hello Folks, > > The MEXT WG has a deliverable for Binding Revocation for IP Mobility. > > Hereby we'd like to ask WG participants whether or not they think this > individual submission should be adopted as the corresponding MEXT work > item. Please answer to this note to state your opinion by Monday July > 28th. > > Thank you for your support, > > -- julien & marcelo, MEXT chairs > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Binding Revocation for IPv6 Mobility > Author(s) : A. Muhanna, et al. > Filename : draft-muhanna-mext-binding-revocation-02.txt > Pages : 32 > Date : 2008-07-11 > > This document defines the revocation semantics for terminating a > mobile node's mobility session and associated resources. These > semantics are generic enough and can be used by mobility entities in > the case of Client Mobile IPv6 and its extensions. This mechanism > allows the mobility entity which initiates the revocation procedure > to request its corresponding one to terminate either one, multiple or > all specified binding cache entries. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding-revocatio n- > 02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 13:09:41 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8073928C0F7; Mon, 14 Jul 2008 13:09:41 -0700 (PDT) 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 4586F28C0F7 for ; Mon, 14 Jul 2008 13:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pT1rTdyTfZpk for ; Mon, 14 Jul 2008 13:09:39 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 068373A680A for ; Mon, 14 Jul 2008 13:09:39 -0700 (PDT) Received: from localhost ([127.0.0.1]:59266 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1KIUMt-0005PT-US; Mon, 14 Jul 2008 22:09:56 +0200 MIME-Version: 1.0 From: "mext" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software To: charliep@computer.org X-Trac-Project: mext Date: Mon, 14 Jul 2008 20:09:55 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/mext/trac/ticket/14 Message-ID: <063.855a73e684e87d802316d9c50d015af5@tools.ietf.org> X-Trac-Ticket-ID: 14 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, vijay@wichorus.com, mext@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: mext@ietf.org Subject: [MEXT] [mext] #14: References to Bootstrapping [Vijay Devarapalli ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mext@ietf.org 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 Ticket #14: References to Bootstrapping [Vijay Devarapalli ] References to Bootstrapping [Vijay Devarapalli ] RFC 3775 currently assumes that the mobile node is at least pre-configured with the home prefix it needs to be using. Now that we have developed bootstrapping mechanisms that allow a mobile to dynamically configure a home agent and the home address we have to refer to them in 3775bis. Here is the proposed text. OLD: NEW: (to be added at the end of section 4.1) This document assumes that the mobile node is configured with the home prefix for the mobile node to be able to discover a home agent and configure a home address. This might be limiting in deployments where the home agent and the home address for the mobile node needs to be assigned dynamically. Additional mechanisms have been specified for the mobile node to dynamically configure a home agent, a home address and the home prefix. These mechanisms are described in [38] and [39]. {{{ #!html
[38] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007.
[39] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the Integrated Scenario", draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in progress), July 2007.
}}} The intention is to still allow the mobile node to be pre-configured with the home prefix or even with a home address. There might be other places in RFC 3775 that might require more changes. I can scan for those, once we agree to make the change. --------------------------------------------------------------------- George Tsirtsis I am ok with the text you propose below as long as the integrated draft proceeds in time. We will have to check this again when RFC3775bis goes through last call process. --------------------------------------------------------------------- Vijay Devarapalli : It shouldn't matter. Both bootstrapping documents are listed as Informative references. The RFC editor goes ahead with a publication unless there is a normative dependency which is still pending publication. --------------------------------------------------------------------- Charles E. Perkins wrote: I would like to slightly reword the first sentence as follows: This document has been written under the assumption that the mobile node has knowledge of the home prefix, so that the mobile node can discover a home agent and configure a home address. ----------------------------------------+----------------------------------- Reporter: charliep@computer.org | Owner: charliep@computer.org Type: enhancement | Status: new Priority: minor | Milestone: milestone1 Component: draft-ietf-mext-rfc3775bis | Version: 2.0 Severity: Active WG Document | Keywords: bootstrapping ----------------------------------------+----------------------------------- -- Ticket URL: mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 13:14:45 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 418C33A68D9; Mon, 14 Jul 2008 13:14:45 -0700 (PDT) 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 E457F3A68D9 for ; Mon, 14 Jul 2008 13:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, 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 P9IHw0CZCQ5s for ; Mon, 14 Jul 2008 13:14:43 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 09E7F3A6830 for ; Mon, 14 Jul 2008 13:14:42 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Jul 2008 16:15:06 -0400 Message-ID: In-Reply-To: <487BA72A.5070902@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Authentication option support in Binding Revocation draft Thread-Index: Acjl5srPOuXT1Pi9To+TX/8BpJjvvQABvD6Q References: <00b c 01c8e39e$b644f6d0$5c0c7c0a@china.huawei.com><200807141856.36985.julien.IE TF@laposte.net> <487BA2CF.9090908@it.uc3m.es> <487BA72A.5070902@it.uc3m.es> From: "Vijay Devarapalli" To: "marcelo bagnulo braun" Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Authentication option support in Binding Revocation 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org marcelo bagnulo braun wrote: > Vijay Devarapalli escribi=F3: >> Hi Marcelo, >> = >> marcelo bagnulo braun wrote: >> = >> = >>> we have very clear guidance on this >>> = >>> see the MEXT charter: >>> = >>> The group employs IPsec and IKE as a security mechanism. The group >>> shall refrain, however, from making generic extensions to these >>> protocols. Any proposed extension must be reviewed by the INT and >>> SEC ADs before it can be accepted as a part of a work item. >>> = >> = >> The last sentence says any extensions to IKEv2 and IPsec should be >> reviewed by the INT and SEC ADs before being adopted as WG items. >> = >> = >>> any work in using other security mechanisms need to be >>> approved by SEC >>> and INT Ads >>> = >> = >> The charter does not say this. Perhaps I am missing something. >> = > = > The very first sentence reads: > = > The group employs IPsec and IKE as a security mechanism. > = > To me that means that whatever mechanism we define must work > with IPSec IKE security and that it is out of the scope to do > work on security based on other mechanism. I completely disagree. I wish I had paid more attention to that text when w= e were re-chartering. 4285bis was supposed to be in-scope. > This means to me, that if we define an extension, we need to > secure it using IPSec/IKE and that security based on other > approaches is out of the scope and needs to be explicitly reviewed by > INT and SEC ADs. = The way the text is written currently, it does not say that. I read it as -= any extensions to IKEv2 and IPsec must be referred to the SEC and INT Ads = before getting adopted. = > That is our reading of the charter. We may ask for guidance > from INT and SEC ADs if people think that we are reading it wrong, no > problem with that. = I think we should ask them then. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 13:17:50 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BCE13A6AD3; Mon, 14 Jul 2008 13:17:50 -0700 (PDT) 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 A8CCA3A6A0F for ; Mon, 14 Jul 2008 13:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.813 X-Spam-Level: X-Spam-Status: No, score=-3.813 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77qFEbfi02E1 for ; Mon, 14 Jul 2008 13:17:48 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id CE8043A6B06 for ; Mon, 14 Jul 2008 13:17:43 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (14.pool85-53-137.dynamic.orange.es [85.53.137.14])by smtp01.uc3m.es (Postfix) with ESMTP id 4FAAE7A4FEC; Mon, 14 Jul 2008 22:18:08 +0200 (CEST) Message-ID: <487BB47F.7060105@it.uc3m.es> Date: Mon, 14 Jul 2008 22:18:07 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Basavaraj Patil References: In-Reply-To: X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-20.8275 TC:1F TRN:57 TV:5.5.1026(16032.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 , mext@ietf.org Subject: Re: [MEXT] Authentication option support in Binding Revocation 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-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Raj, My understanding is that any extension we define in mext will be secured = using IPSec IKE unless explicilty chartered to do otherwise. Moreover, = RFC4285 is an informational document, which makes thing complex if we = want that a std track extension depend on it. finally, i guess that when = we are chartered to work on a particular exentsion this does not = includes defining how it should work with any other informational extension. Regards, marcelo Basavaraj Patil escribi=F3: > Marcelo, > > IPsec/IKEv2 is the default mechanism for securing MIP6 signaling. However > the use of RF4285 based security is allowed within certain boundaries. So= it > is a valid method within the scope of the MIP6 protocol and one that is > actually specified as the default mode for MIP6 operation (eg. 3GPP2 and > WiMAX). = > Any extensions to IPsec/IKEv2 itself would need consideration by the > Security AD. Or changing the default security model for MIP6 would require > the SEC and INT AD views. > But in the current thread I do not see that as an issue. > > -Raj > > On 7/14/08 2:21 PM, "Marcelo Bagnulo" wrote: > > = >> Vijay Devarapalli escribi=F3: >> = >>> Hi Marcelo, >>> >>> marcelo bagnulo braun wrote: >>> >>> = >>> = >>>> we have very clear guidance on this >>>> >>>> see the MEXT charter: >>>> >>>> The group employs IPsec and IKE as a security mechanism. The group >>>> shall refrain, however, from making generic extensions to these >>>> protocols. Any proposed extension must be reviewed by the INT and SEC >>>> ADs before it can be accepted as a part of a work item. >>>> = >>>> = >>> The last sentence says any extensions to IKEv2 and IPsec should be >>> reviewed by the INT and SEC ADs before being adopted as WG items. >>> >>> = >>> = >>>> any work in using other security mechanisms need to be >>>> approved by SEC >>>> and INT Ads >>>> = >>>> = >>> The charter does not say this. Perhaps I am missing something. >>> = >>> = >> The very first sentence reads: >> >> The group employs IPsec and IKE as a security mechanism. >> >> To me that means that whatever mechanism we define must work with IPSec = IKE >> security and that it is out of the scope to do work on security based on= other >> mechanism. >> >> This means to me, that if we define an extension, we need to secure it u= sing >> IPSec/IKE and that security based on other approaches is out of the scop= e and >> needs to be explicitly reviewed by INT and SEC ADs. >> >> >> That is our reading of the charter. We may ask for guidance from INT and= SEC >> ADs if people think that we are reading it wrong, no problem with that. >> >> >> regards, marcelo >> >> = >>> Vijay >>> >>> = >>> = >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> = > > > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 13:18:52 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10A503A6AD9; Mon, 14 Jul 2008 13:18:52 -0700 (PDT) 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 2024C3A67E1 for ; Mon, 14 Jul 2008 13:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, 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 3aAbecc4qIat for ; Mon, 14 Jul 2008 13:18:50 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 9C42B3A6B72 for ; Mon, 14 Jul 2008 13:18:42 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Jul 2008 16:19:05 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Authentication option support in Binding Revocation Thread-Index: Acjjy4AUqtD1A+yKQ5qO5PriyNmT6AAC0PuAAA/2l3AAAFNH4AAKHHUgAGsDB5AAAHpG0A== References: <000601c8e369$530b9b80$5c0c7c0a@china.huawei.com><001201c8e36a$746e18b0$5c0c7c0a@china.huawei.com><003901c8e36c$02c6b850$5c0c7c0a@china.huawei.com><000e01c8e370$3f9f83c0$5c0c7c0a@china.huawei.com><005601c8e37f$90fc3a60$5c0c7c0a@china.huawei.com><008201c8e388$984a4240$5c0c7c0a@china.huawei.com><00bc01c8e39e$b644f6d0$5c0c7c0a@china.huawei.com><000a01c8e3a6$0e3cc8c0$5c0c7c0a@china.huawei.com> From: "Vijay Devarapalli" To: "Giaretta, Gerardo" , "Ahmad Muhanna" , "Sri Gundavelli" , "Frank Xia" Cc: mext@ietf.org, Basavaraj Patil Subject: Re: [MEXT] Authentication option support in Binding Revocation 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 Giaretta, Gerardo wrote: > Hi all, > > I think the question is: do we really need to support RFC4285 for > this? Where is that requirement coming from? RFC 4285 would not be a requirement for the generic signaling message. That is clear. If 4285 is being used for protecting BU/Back messages, then what we do? That was the question Frank had asked. So we need to answer that question in the draft. > I think there is a lot of time pressure for these drafts and it would > be good to complete them without extending the support for rfc4285 > which is still an Informational RFC as mentioned by Ahmad. I am sure we can get these two documents completed pretty soon, even with the description of the use of the MN-HA authentication option. Don't worry. :) > Assuming there is some interest, I think a separate draft for the > usage of authentication protocol with MGSM and BRI should be written. I don't think a separate draft is necessary for this. Vijay > > Gerardo > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf >> Of Vijay Devarapalli Sent: Saturday, July 12, 2008 9:59 AM >> To: Ahmad Muhanna; Sri Gundavelli; Frank Xia >> Cc: Basavaraj Patil; mext@ietf.org >> Subject: Re: [MEXT] Authentication option support in Binding >> Revocation >> >>> My understanding that Mobile IPv6 Generic Signaling Message (MGSM) >>> and Binding Revocation are proposed as standard track document. >>> Therefore, before we start talking about adding Auth protocol >>> support to MGSM and consequently Binding Revocation, we need to do >>> something >>> about RFC4285. >>> This RFC is still an Informational one and my understanding a >>> standard track doc can not reference an Informational one. >> >> It doesn't matter. The Generic Signaling Message just needs to >> describe how to calculate the authentication data if the MN-HA >> authentication option is used. RFC 4285 would be an Informational >> reference, since it is not required for someone to use the Generic >> Signaling Message. >> >> Vijay >> >>> Any one knows what is the latest on RFC4285? Raj or Kuntal? >>> >>> Regards, >>> Ahmad >>> >>>> -----Original Message----- >>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >>>> Behalf Of Muhanna, Ahmad (RICH1:2H10) >>>> Sent: Saturday, July 12, 2008 7:05 AM >>>> To: Vijay Devarapalli; Sri Gundavelli; Frank Xia >>>> Cc: mext@ietf.org >>>> Subject: Re: [MEXT] Authentication option support in Binding >>>> Revocation >>>> >>>> Hi Vijay, >>>> >>>>>> Subject: Re: [MEXT] Authentication option support in Binding >>>>>> Revocation >>>>> >>>>>> If there is a shared key between the mobile node and the home >>>>>> agent, MN-HA Authentication option can be used. >>>>>> >>>>>> If there is a shared key between the mobile node and the AAA, >>>>>> MN-AAA authentication option can be used. >>>>>> >>>>>> But you bring a good point, these options are defined to be >>>>>> carried in BU/BA. We need to allow these options to be carried >>>>>> in Generic Notification messages. >>>>> >>>>> Specifying the use of MN-HA authentication option with the Generic >>>>> Signaling Message sounds good to me. I doubt if the MN-AAA >>>>> authentication option will ever be used with the Generic Signaling >>>>> Message, though. >>>> >>>> [Ahmad] >>>> I agree. >>>> If auth protocol to be used to authenticate the MIP6 Generic >>>> Signaling Message, then it has to be the MN-HA AE in the case of >>>> Client MIP6. MN-AAA AE is used during the initial registration to >>>> help in bootstrapping MN-HA SA if it is needed. After the MIP6 >>>> session is established, it is assumed that MN-HA SA has been >>>> established. Therefore, MN-AAA AE has no value in this scenario. >>>> Not only that, but it does not make sense either. >>>> >>>> >>>>> >>>>> Vijay >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 13:25:53 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F4573A6997; Mon, 14 Jul 2008 13:25:53 -0700 (PDT) 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 46F9A3A680A for ; Mon, 14 Jul 2008 13:25:52 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okXVYNbmezkQ for ; Mon, 14 Jul 2008 13:25:51 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id BE0393A6997 for ; Mon, 14 Jul 2008 13:25:50 -0700 (PDT) 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 m6EKQBbS023821; Mon, 14 Jul 2008 23:26:13 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jul 2008 23:26:05 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jul 2008 15:26:01 -0500 Received: from 172.19.60.172 ([172.19.60.172]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Mon, 14 Jul 2008 20:26:01 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Mon, 14 Jul 2008 15:26:01 -0500 From: Basavaraj Patil To: Marcelo Bagnulo Message-ID: Thread-Topic: [MEXT] Authentication option support in Binding Revocation draft Thread-Index: Acjl79TJCLvYVGsJoUa0N8SIqY1ehQ== In-Reply-To: <487BB47F.7060105@it.uc3m.es> Mime-version: 1.0 X-OriginalArrivalTime: 14 Jul 2008 20:26:01.0540 (UTC) FILETIME=[D51C3840:01C8E5EF] X-Nokia-AV: Clean Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Authentication option support in Binding Revocation 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Marcelo, Agree with your view... And as I said, IPSec/IKE(v2) is the default security protocol for MIP6. = RFC4285 was published originally as an Informational RFC. However I think that was a mistake (IMO) and hopefully 4285bis would be progressed as a standards track RFC. The MIP6 protocol has been incorporated in the 3GPP2 and WiMAX networks architectures with RFC4285 as the default security mechanism. Hence it makese sense to address how the new extension would be utilized in such deployment scenarios. -Raj = On 7/14/08 3:18 PM, "Marcelo Bagnulo" wrote: > Hi Raj, > = > My understanding is that any extension we define in mext will be secured > using IPSec IKE unless explicilty chartered to do otherwise. Moreover, > RFC4285 is an informational document, which makes thing complex if we > want that a std track extension depend on it. finally, i guess that when > we are chartered to work on a particular exentsion this does not > includes defining how it should work with any other informational extensi= on. > = > Regards, marcelo > = > Basavaraj Patil escribi=F3: >> Marcelo, >> = >> IPsec/IKEv2 is the default mechanism for securing MIP6 signaling. However >> the use of RF4285 based security is allowed within certain boundaries. S= o it >> is a valid method within the scope of the MIP6 protocol and one that is >> actually specified as the default mode for MIP6 operation (eg. 3GPP2 and >> WiMAX). = >> Any extensions to IPsec/IKEv2 itself would need consideration by the >> Security AD. Or changing the default security model for MIP6 would requi= re >> the SEC and INT AD views. >> But in the current thread I do not see that as an issue. >> = >> -Raj >> = >> On 7/14/08 2:21 PM, "Marcelo Bagnulo" wrote: >> = >> = >>> Vijay Devarapalli escribi=F3: >>> = >>>> Hi Marcelo, >>>> = >>>> marcelo bagnulo braun wrote: >>>> = >>>> = >>>> = >>>>> we have very clear guidance on this >>>>> = >>>>> see the MEXT charter: >>>>> = >>>>> The group employs IPsec and IKE as a security mechanism. The group >>>>> shall refrain, however, from making generic extensions to these >>>>> protocols. Any proposed extension must be reviewed by the INT and SEC >>>>> ADs before it can be accepted as a part of a work item. >>>>> = >>>>> = >>>> The last sentence says any extensions to IKEv2 and IPsec should be >>>> reviewed by the INT and SEC ADs before being adopted as WG items. >>>> = >>>> = >>>> = >>>>> any work in using other security mechanisms need to be >>>>> approved by SEC >>>>> and INT Ads >>>>> = >>>>> = >>>> The charter does not say this. Perhaps I am missing something. >>>> = >>>> = >>> The very first sentence reads: >>> = >>> The group employs IPsec and IKE as a security mechanism. >>> = >>> To me that means that whatever mechanism we define must work with IPSec= IKE >>> security and that it is out of the scope to do work on security based on >>> other >>> mechanism. >>> = >>> This means to me, that if we define an extension, we need to secure it = using >>> IPSec/IKE and that security based on other approaches is out of the sco= pe >>> and >>> needs to be explicitly reviewed by INT and SEC ADs. >>> = >>> = >>> That is our reading of the charter. We may ask for guidance from INT an= d SEC >>> ADs if people think that we are reading it wrong, no problem with that. >>> = >>> = >>> regards, marcelo >>> = >>> = >>>> Vijay >>>> = >>>> = >>>> = >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> = >> = >> = >> = > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 13:27:14 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A1153A6C34; Mon, 14 Jul 2008 13:27:14 -0700 (PDT) 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 DD2303A6BFF for ; Mon, 14 Jul 2008 13:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pThzAh89cNl4 for ; Mon, 14 Jul 2008 13:27:11 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 16FA33A6B03 for ; Mon, 14 Jul 2008 13:26:55 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K4000DU1JHKSL@usaga04-in.huawei.com> for mext@ietf.org; Mon, 14 Jul 2008 15:27:20 -0500 (CDT) Received: from X24512z ([10.124.12.92]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K40008CYJHHA3@usaga04-in.huawei.com> for mext@ietf.org; Mon, 14 Jul 2008 15:27:20 -0500 (CDT) Date: Mon, 14 Jul 2008 15:27:17 -0500 From: Frank Xia To: "Giaretta, Gerardo" Message-id: <005b01c8e5f0$036b6220$5c0c7c0a@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: <000e01c8e370$3f9f83c0$5c0c7c0a@china.huawei.com> <005601c8e37f$90fc3a60$5c0c7c0a@china.huawei.com> <008201c8e388$984a4240$5c0c7c0a@china.huawei.com> <00bc01c8e39e$b644f6d0$5c0c7c0a@china.huawei.com> <000a01c8e3a6$0e3cc8c0$5c0c7c0a@china.huawei.com> <"DE33046 582DF324092F2A982824D6B0303A69118"@mse15be2.mse15.exchange.ms> Cc: mext@ietf.org, Basavaraj Patil Subject: Re: [MEXT] Authentication option support in Binding Revocation 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Gerardo Please see my inline comments. BR Frank ----- Original Message ----- From: "Giaretta, Gerardo" To: "Vijay Devarapalli" ; "Ahmad Muhanna" ; "Sri Gundavelli" ; "Frank Xia" Cc: "Basavaraj Patil" ; Sent: Monday, July 14, 2008 3:04 PM Subject: RE: [MEXT] Authentication option support in Binding Revocation Hi all, I think the question is: do we really need to support RFC4285 for this? Where is that requirement coming from? Frank=>You can refer to http://tools.ietf.org/id/draft-ietf-mip6-whyauthdataoption-06.txt. I think there is a lot of time pressure for these drafts and it would be good to complete them without extending the support for rfc4285 which is still an Informational RFC as mentioned by Ahmad. Frank=>I don't know what is the really problem when referring to rfc4285. However, I do know some practices that intended standard tracks refering to the informational document, RFC4285. http://tools.ietf.org/id/draft-korhonen-dime-pmip6-03.txt http://tools.ietf.org/id/draft-korhonen-dime-pmip6-03.txt Assuming there is some interest, I think a separate draft for the usage of authentication protocol with MGSM and BRI should be written. Frank=>Sounds good. Gerardo > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Vijay Devarapalli > Sent: Saturday, July 12, 2008 9:59 AM > To: Ahmad Muhanna; Sri Gundavelli; Frank Xia > Cc: Basavaraj Patil; mext@ietf.org > Subject: Re: [MEXT] Authentication option support in Binding Revocation > > > My understanding that Mobile IPv6 Generic Signaling Message (MGSM) and > > Binding Revocation are proposed as standard track document. Therefore, > > before we start talking about adding Auth protocol support to MGSM and > > consequently Binding Revocation, we need to do something > > about RFC4285. > > This RFC is still an Informational one and my understanding a standard > > track doc can not reference an Informational one. > > It doesn't matter. The Generic Signaling Message just needs to describe > how to calculate the authentication data if the MN-HA authentication > option is used. RFC 4285 would be an Informational reference, since it > is not required for someone to use the Generic Signaling Message. > > Vijay > > > Any one knows what is the latest on RFC4285? Raj or Kuntal? > > > > Regards, > > Ahmad > > > > > -----Original Message----- > > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > > Behalf Of Muhanna, Ahmad (RICH1:2H10) > > > Sent: Saturday, July 12, 2008 7:05 AM > > > To: Vijay Devarapalli; Sri Gundavelli; Frank Xia > > > Cc: mext@ietf.org > > > Subject: Re: [MEXT] Authentication option support in Binding > > > Revocation > > > > > > Hi Vijay, > > > > > > > > Subject: Re: [MEXT] Authentication option support in Binding > > > > > Revocation > > > > > > > > > If there is a shared key between the mobile node and the > > > > home agent, > > > > > MN-HA Authentication option can be used. > > > > > > > > > > If there is a shared key between the mobile node and the > > > > AAA, MN-AAA > > > > > authentication option can be used. > > > > > > > > > > But you bring a good point, these options are defined to be > > > > carried in > > > > > BU/BA. We need to allow these options to be carried in Generic > > > > > Notification messages. > > > > > > > > Specifying the use of MN-HA authentication option with > > the Generic > > > > Signaling Message sounds good to me. I doubt if the MN-AAA > > > > authentication option will ever be used with the Generic > > Signaling > > > > Message, though. > > > > > > [Ahmad] > > > I agree. > > > If auth protocol to be used to authenticate the MIP6 Generic > > > Signaling Message, then it has to be the MN-HA AE in the case > > > of Client MIP6. > > > MN-AAA AE is used during the initial registration to help in > > > bootstrapping MN-HA SA if it is needed. After the MIP6 > > > session is established, it is assumed that MN-HA SA has been > > > established. > > > Therefore, MN-AAA AE has no value in this scenario. Not only > > > that, but it does not make sense either. > > > > > > > > > > > > > > Vijay > > > > _______________________________________________ > > > > MEXT mailing list > > > > MEXT@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 13:35:13 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41CA528C2A9; Mon, 14 Jul 2008 13:35:13 -0700 (PDT) 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 90CBE28C1C9 for ; Mon, 14 Jul 2008 13:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.805 X-Spam-Level: X-Spam-Status: No, score=-3.805 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXrcgRGGrNhh for ; Mon, 14 Jul 2008 13:35:11 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 7DBD028C325 for ; Mon, 14 Jul 2008 13:32:16 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (14.pool85-53-137.dynamic.orange.es [85.53.137.14])by smtp03.uc3m.es (Postfix) with ESMTP id 11DD84836DC; Mon, 14 Jul 2008 22:32:41 +0200 (CEST) Message-ID: <487BB7E8.1030709@it.uc3m.es> Date: Mon, 14 Jul 2008 22:32:40 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Vijay Devarapalli References: <0 0 b c 01c8e39e$b644f6d0$5c0c7c0a@china.huawei.com><200807141856.36985.julie n. IE TF@laposte.net> <487BA2CF.9090908@it.uc3m.es> <487BA72A.5070902@it.uc3m.es> In-Reply-To: X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-7.6745 TC:1F TRN:13 TV:5.5.1026(16032.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: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Authentication option support in Binding Revocation 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-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Vijay Devarapalli escribi=F3: > >> That is our reading of the charter. We may ask for guidance >> from INT and SEC ADs if people think that we are reading it wrong, no >> problem with that. = >> = > > I think we should ask them then. > > = we will do that regards, marcelo > Vijay > > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 13:49:51 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF08328C307; Mon, 14 Jul 2008 13:49:51 -0700 (PDT) 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 19C1B3A6A0F for ; Mon, 14 Jul 2008 13:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.798 X-Spam-Level: X-Spam-Status: No, score=-3.798 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoFiwTkFBapb for ; Mon, 14 Jul 2008 13:49:49 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id A4CAC3A6C5B for ; Mon, 14 Jul 2008 13:49:46 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (14.pool85-53-137.dynamic.orange.es [85.53.137.14])by smtp02.uc3m.es (Postfix) with ESMTP id 06A454015BB; Mon, 14 Jul 2008 22:50:10 +0200 (CEST) Message-ID: <487BBC02.9090508@it.uc3m.es> Date: Mon, 14 Jul 2008 22:50:10 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Vijay Devarapalli References: <005601c8e37f$90fc3a60$5c0c7c0a@china.huawei.com><008201c8e388$984 a4240$5c0c7 c0a@china.huawei.com><00bc01c8e39e$b644f6d0$5c0c7c0a@china.huawei.com><000a01c8e 3a6$0e3c c8c0$5c0c7c0a@china.huawei.com> In-Reply-To: X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-19.7435 TC:1F TRN:57 TV:5.5.1026(16032.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: Basavaraj Patil , mext@ietf.org Subject: Re: [MEXT] Authentication option support in Binding Revocation 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-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Vijay Devarapalli escribi=F3: > > I don't think a separate draft is necessary for this. > > = probably it is cause 4285 is an informational rfc and we probably want = that the binding revocation to a std track. If this is so, we need to = avoid the downward ref So either we do the binding revocation an informational document, or = either we do some trick to deal with the downard ref or we split the = binding revocation in two, one for IPSec (std track) and another for = 4285 (informational) I think the last one would be best Regards, marcelo > Vijay > > = >> Gerardo >> >> = >>> -----Original Message----- >>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf >>> Of Vijay Devarapalli Sent: Saturday, July 12, 2008 9:59 AM >>> To: Ahmad Muhanna; Sri Gundavelli; Frank Xia >>> Cc: Basavaraj Patil; mext@ietf.org >>> Subject: Re: [MEXT] Authentication option support in Binding >>> Revocation = >>> >>> = >>>> My understanding that Mobile IPv6 Generic Signaling Message (MGSM) >>>> and Binding Revocation are proposed as standard track document. >>>> Therefore, before we start talking about adding Auth protocol >>>> support to MGSM and consequently Binding Revocation, we need to do >>>> something = >>>> about RFC4285. >>>> This RFC is still an Informational one and my understanding a >>>> standard track doc can not reference an Informational one. >>>> = >>> It doesn't matter. The Generic Signaling Message just needs to >>> describe how to calculate the authentication data if the MN-HA >>> authentication option is used. RFC 4285 would be an Informational >>> reference, since it is not required for someone to use the Generic >>> Signaling Message. = >>> >>> Vijay >>> >>> = >>>> Any one knows what is the latest on RFC4285? Raj or Kuntal? >>>> >>>> Regards, >>>> Ahmad >>>> >>>> = >>>>> -----Original Message----- >>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >>>>> Behalf Of Muhanna, Ahmad (RICH1:2H10) >>>>> Sent: Saturday, July 12, 2008 7:05 AM >>>>> To: Vijay Devarapalli; Sri Gundavelli; Frank Xia >>>>> Cc: mext@ietf.org >>>>> Subject: Re: [MEXT] Authentication option support in Binding >>>>> Revocation = >>>>> >>>>> Hi Vijay, >>>>> >>>>> = >>>>>>> Subject: Re: [MEXT] Authentication option support in Binding >>>>>>> Revocation >>>>>>> = >>>>>>> If there is a shared key between the mobile node and the home >>>>>>> agent, MN-HA Authentication option can be used. >>>>>>> >>>>>>> If there is a shared key between the mobile node and the AAA, >>>>>>> MN-AAA authentication option can be used. >>>>>>> >>>>>>> But you bring a good point, these options are defined to be >>>>>>> carried in BU/BA. We need to allow these options to be carried >>>>>>> in Generic Notification messages. >>>>>>> = >>>>>> Specifying the use of MN-HA authentication option with the Generic >>>>>> Signaling Message sounds good to me. I doubt if the MN-AAA >>>>>> authentication option will ever be used with the Generic Signaling >>>>>> Message, though. >>>>>> = >>>>> [Ahmad] >>>>> I agree. >>>>> If auth protocol to be used to authenticate the MIP6 Generic >>>>> Signaling Message, then it has to be the MN-HA AE in the case of >>>>> Client MIP6. MN-AAA AE is used during the initial registration to >>>>> help in bootstrapping MN-HA SA if it is needed. After the MIP6 >>>>> session is established, it is assumed that MN-HA SA has been >>>>> established. Therefore, MN-AAA AE has no value in this scenario. >>>>> Not only that, but it does not make sense either. >>>>> >>>>> >>>>> = >>>>>> Vijay >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>> >>>>>> = >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> >>>>> = >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> = > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 13:54:34 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03ADE3A6A7D; Mon, 14 Jul 2008 13:54:34 -0700 (PDT) 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 58DB13A68D9 for ; Mon, 14 Jul 2008 13:54:32 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgefcbOYQ4OR for ; Mon, 14 Jul 2008 13:54:31 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id DA99E3A6A7D for ; Mon, 14 Jul 2008 13:54:30 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6EKsea22119; Mon, 14 Jul 2008 20:54:40 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Jul 2008 15:54:28 -0500 Message-ID: In-Reply-To: <487BBC02.9090508@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Authentication option support in Binding Revocation thread-index: Acjl8zqm4wv7+tiHSj+XuMlAkLdvqwAAC9uA References: <005601c8e37f$90fc3a60$5c0c7c0a@china.huawei.com><008201c8e388$984 a4240$5c0c7 c0a@china.huawei.com><00bc01c8e39e$b644f6d0$5c0c7c0a@china.huawei.com><000a01c8e 3a6$0e3c c8c0$5c0c7c0a@china.huawei.com> <487BBC02.9090508@it.uc! 3m.es> From: "Ahmad Muhanna" To: "marcelo bagnulo braun" , "Vijay Devarapalli" Cc: Basavaraj Patil , mext@ietf.org Subject: Re: [MEXT] Authentication option support in Binding Revocation 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, > Subject: Re: [MEXT] Authentication option support in Binding > Revocation > > or we split the binding revocation in two, one for IPSec > (std track) and another for > 4285 (informational) > > I think the last one would be best [Ahmad] I agree. That should work. > > Regards, marcelo > > > Vijay > > > > > >> Gerardo > >> > >> > >>> -----Original Message----- > >>> From: mext-bounces@ietf.org > [mailto:mext-bounces@ietf.org] On Behalf > >>> Of Vijay Devarapalli Sent: Saturday, July 12, 2008 9:59 AM > >>> To: Ahmad Muhanna; Sri Gundavelli; Frank Xia > >>> Cc: Basavaraj Patil; mext@ietf.org > >>> Subject: Re: [MEXT] Authentication option support in Binding > >>> Revocation > >>> > >>> > >>>> My understanding that Mobile IPv6 Generic Signaling > Message (MGSM) > >>>> and Binding Revocation are proposed as standard track document. > >>>> Therefore, before we start talking about adding Auth protocol > >>>> support to MGSM and consequently Binding Revocation, we > need to do > >>>> something about RFC4285. > >>>> This RFC is still an Informational one and my understanding a > >>>> standard track doc can not reference an Informational one. > >>>> > >>> It doesn't matter. The Generic Signaling Message just needs to > >>> describe how to calculate the authentication data if the MN-HA > >>> authentication option is used. RFC 4285 would be an Informational > >>> reference, since it is not required for someone to use > the Generic > >>> Signaling Message. > >>> > >>> Vijay > >>> > >>> > >>>> Any one knows what is the latest on RFC4285? Raj or Kuntal? > >>>> > >>>> Regards, > >>>> Ahmad > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > >>>>> Behalf Of Muhanna, Ahmad (RICH1:2H10) > >>>>> Sent: Saturday, July 12, 2008 7:05 AM > >>>>> To: Vijay Devarapalli; Sri Gundavelli; Frank Xia > >>>>> Cc: mext@ietf.org > >>>>> Subject: Re: [MEXT] Authentication option support in Binding > >>>>> Revocation > >>>>> > >>>>> Hi Vijay, > >>>>> > >>>>> > >>>>>>> Subject: Re: [MEXT] Authentication option support in Binding > >>>>>>> Revocation > >>>>>>> > >>>>>>> If there is a shared key between the mobile node and the home > >>>>>>> agent, MN-HA Authentication option can be used. > >>>>>>> > >>>>>>> If there is a shared key between the mobile node and the AAA, > >>>>>>> MN-AAA authentication option can be used. > >>>>>>> > >>>>>>> But you bring a good point, these options are defined to be > >>>>>>> carried in BU/BA. We need to allow these options to > be carried > >>>>>>> in Generic Notification messages. > >>>>>>> > >>>>>> Specifying the use of MN-HA authentication option with the > >>>>>> Generic Signaling Message sounds good to me. I doubt if the > >>>>>> MN-AAA authentication option will ever be used with > the Generic > >>>>>> Signaling Message, though. > >>>>>> > >>>>> [Ahmad] > >>>>> I agree. > >>>>> If auth protocol to be used to authenticate the MIP6 Generic > >>>>> Signaling Message, then it has to be the MN-HA AE in > the case of > >>>>> Client MIP6. MN-AAA AE is used during the initial > registration to > >>>>> help in bootstrapping MN-HA SA if it is needed. After the MIP6 > >>>>> session is established, it is assumed that MN-HA SA has been > >>>>> established. Therefore, MN-AAA AE has no value in this scenario. > >>>>> Not only that, but it does not make sense either. > >>>>> > >>>>> > >>>>> > >>>>>> Vijay > >>>>>> _______________________________________________ > >>>>>> MEXT mailing list > >>>>>> MEXT@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/mext > >>>>>> > >>>>>> > >>>>> _______________________________________________ > >>>>> MEXT mailing list > >>>>> MEXT@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/mext > >>>>> > >>>>> > >>> _______________________________________________ > >>> MEXT mailing list > >>> MEXT@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mext > >>> > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 13:56:34 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5BAA3A68D9; Mon, 14 Jul 2008 13:56:34 -0700 (PDT) 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 74D9B3A68DF for ; Mon, 14 Jul 2008 13:56:33 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZAF6ZUBdpPF for ; Mon, 14 Jul 2008 13:56:32 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 52B0A3A6768 for ; Mon, 14 Jul 2008 13:56:27 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6EKuaKT019689; Mon, 14 Jul 2008 23:56:51 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jul 2008 23:56:50 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jul 2008 15:56:09 -0500 Received: from 172.19.60.172 ([172.19.60.172]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Mon, 14 Jul 2008 20:56:09 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Mon, 14 Jul 2008 15:56:10 -0500 From: Basavaraj Patil To: Julien Laganier , Message-ID: Thread-Topic: [MEXT] Adoption of draft-muhanna-mext-binding-revocation-02.txt Thread-Index: Acjl9AsJ1FHCpS+K2UOhbuCeh/JUQA== In-Reply-To: <200807141903.26551.julien.IETF@laposte.net> Mime-version: 1.0 X-OriginalArrivalTime: 14 Jul 2008 20:56:09.0985 (UTC) FILETIME=[0B070710:01C8E5F4] X-Nokia-AV: Clean Subject: Re: [MEXT] Adoption of draft-muhanna-mext-binding-revocation-02.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 support this I-D being adopted as a WG item. -Basavaraj On 7/14/08 12:03 PM, "Julien Laganier" wrote: > Hello Folks, > > The MEXT WG has a deliverable for Binding Revocation for IP Mobility. > > Hereby we'd like to ask WG participants whether or not they think this > individual submission should be adopted as the corresponding MEXT work > item. Please answer to this note to state your opinion by Monday July > 28th. > > Thank you for your support, > > -- julien & marcelo, MEXT chairs > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Binding Revocation for IPv6 Mobility > Author(s) : A. Muhanna, et al. > Filename : draft-muhanna-mext-binding-revocation-02.txt > Pages : 32 > Date : 2008-07-11 > > This document defines the revocation semantics for terminating a > mobile node's mobility session and associated resources. These > semantics are generic enough and can be used by mobility entities in > the case of Client Mobile IPv6 and its extensions. This mechanism > allows the mobility entity which initiates the revocation procedure > to request its corresponding one to terminate either one, multiple or > all specified binding cache entries. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding-revocation-02.t > xt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 13:57:33 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EC7F3A6C61; Mon, 14 Jul 2008 13:57:33 -0700 (PDT) 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 4F1FD3A6C40 for ; Mon, 14 Jul 2008 13:57:32 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvB26NGOChcN for ; Mon, 14 Jul 2008 13:57:27 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 0E4AB3A680A for ; Mon, 14 Jul 2008 13:57:22 -0700 (PDT) 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 m6EKvTWM020242; Mon, 14 Jul 2008 23:57:46 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jul 2008 23:57:32 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jul 2008 15:57:31 -0500 Received: from 172.19.60.172 ([172.19.60.172]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Mon, 14 Jul 2008 20:57:30 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Mon, 14 Jul 2008 15:57:31 -0500 From: Basavaraj Patil To: Julien Laganier , Message-ID: Thread-Topic: [MEXT] Adoption of draft-haley-mext-generic-signaling-message-01.txt Thread-Index: Acjl9DtQrRnCpyRJN0ufdX0PA6h8zA== In-Reply-To: <200807141903.00610.julien.IETF@laposte.net> Mime-version: 1.0 X-OriginalArrivalTime: 14 Jul 2008 20:57:31.0071 (UTC) FILETIME=[3B5BC4F0:01C8E5F4] X-Nokia-AV: Clean Subject: Re: [MEXT] Adoption of draft-haley-mext-generic-signaling-message-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 I support the adoption of I-D: draft-haley-mext-generic-signaling-message as a MEXT WG item. -Basavaraj On 7/14/08 12:03 PM, "Julien Laganier" wrote: > Hello Folks, > > The MEXT WG has a deliverable for a Generic Signaling Message for MIPv6. > > Hereby we'd like to ask WG participants whether or not they think this > individual submission should be adopted as the corresponding MEXT work > item. Please answer to this note to state your opinion by Monday July > 28th. > > Thank you for your support, > > -- julien & marcelo, MEXT chairs > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 14:00:25 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69AFD28C3BF; Mon, 14 Jul 2008 14:00:25 -0700 (PDT) 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 A2D0728C39F for ; Mon, 14 Jul 2008 14:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBxRIhN3xbQw for ; Mon, 14 Jul 2008 14:00:23 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id CFD6B28C3BF for ; Mon, 14 Jul 2008 14:00:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1216069236; x=1247605236; h=x-mimeole:content-class:mime-version:content-type: content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator: thread-topic:thread-index:references:from:to:cc: x-originalarrivaltime:x-ironport-av; z=X-MimeOLE:=20Produced=20By=20Microsoft=20Exchange=20V6.5 |Content-class:=20urn:content-classes:message |MIME-Version:=201.0|Content-Type:=20text/plain=3B=0D=0A =09charset=3D"us-ascii"|Content-Transfer-Encoding:=20quot ed-printable|Subject:=20RE:=20[MEXT]=20Authentication=20o ption=20support=20in=20Binding=20Revocation|Date:=20Mon, =2014=20Jul=202008=2014:00:17=20-0700|Message-ID:=20|In-Reply-To:=20|X-MS-Has-Attach:=20 |X-MS-TNEF-Correlator:=20|Thread-Topic:=20[MEXT]=20Authen tication=20option=20support=20in=20Binding=20Revocation |Thread-Index:=20Acjl8zqm4wv7+tiHSj+XuMlAkLdvqwAAC9uAAABG iqA=3D|References:=20<005601c8e37f$90fc3a60$ 5c0c7c0a@china.huawei.com><008201c8e388$9 84=20a4240$5c0c7=20c0a@china.huawei.com>< 00bc01c8e39e$b644f6d0$5c0c7c0a@china.huawei.com><000a01c8e=203a6$0e3c=20c8c0$5c0c7c0a@china.huawei .com>=20=20 =20<487BBC02.9090508@it.uc!=203m.es>=20=0D=0A=09|From:=20"Giaretta,=20Gerardo"=20 |To:=20"Ahmad=20Muhanna"=20,=0D=0A =20=20=20=20=20=20=20=20"marcelo=20bagnulo=20braun"=20,=0D=0A=20=20=20=20=20=20=20=20"Vijay=20 Devarapalli"=20|Cc:=20"Sri=20Gundavel li"=20,=0D=0A=20=20=20=20=20=20=20=20 "Frank=20Xia"=20,=20,=0D=0A=20=20=20=20=20=20=20=20"Basavaraj=20Patil"=20|X-OriginalArrivalTime:=2014=20J ul=202008=2021:00:17.0878=20(UTC)=20FILETIME=3D[9EC87F60: 01C8E5F4]|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5200,2160,53 38"=3B=20a=3D"4531146"; bh=slS7I9wiUMk73waeMlZKWVZV58DdLK2a4LwuKqrpjIc=; b=XaMem+oQkyYO1dzw4N7LjtE8frES7Dfum7ZlkJGN1xCSz5rPwtao8hsd ospciGpTNFS69WeE3T1DN60s6H7lPpb/Tlbo98b9UgQyLR5BmkTT5WoU1 E/HwooKSfJez4wYcqVFBMEoXlaDNC/uH2wNxJ4lt9b5mKRPLKReN0wTw4 8=; X-IronPort-AV: E=McAfee;i="5200,2160,5338"; a="4531146" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Jul 2008 14:00:36 -0700 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m6EL0Z0x025935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 14 Jul 2008 14:00:35 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m6EL0YD6019481; Mon, 14 Jul 2008 14:00:35 -0700 Received: from NAEX12.na.qualcomm.com ([129.46.51.246]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jul 2008 14:00:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Jul 2008 14:00:17 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Authentication option support in Binding Revocation Thread-Index: Acjl8zqm4wv7+tiHSj+XuMlAkLdvqwAAC9uAAABGiqA= References: <005601c8e37f$90fc3a60$5c0c7c0a@china.huawei.com><008201c8e388$984 a4240$5c0c7 c0a@china.huawei.com><00bc01c8e39e$b644f6d0$5c0c7c0a@china.huawei.com><000a01c8e 3a6$0e3c c8c0$5c0c7c0a@china.huawei.com> <487BBC02.9090508@it.uc! 3m.es> From: "Giaretta, Gerardo" To: "Ahmad Muhanna" , "marcelo bagnulo braun" , "Vijay Devarapalli" X-OriginalArrivalTime: 14 Jul 2008 21:00:17.0878 (UTC) FILETIME=[9EC87F60:01C8E5F4] Cc: Basavaraj Patil , mext@ietf.org Subject: Re: [MEXT] Authentication option support in Binding Revocation 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 As mentioned in my previous email, I agree that if there is some interest in that work, a separate draft is a better option Thanks Gerardo > -----Original Message----- > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > Sent: Monday, July 14, 2008 1:54 PM > To: marcelo bagnulo braun; Vijay Devarapalli > Cc: Giaretta, Gerardo; Sri Gundavelli; Frank Xia; mext@ietf.org; Basavaraj > Patil > Subject: RE: [MEXT] Authentication option support in Binding Revocation > > Hi Marcelo, > > > Subject: Re: [MEXT] Authentication option support in Binding > > Revocation > > > > or we split the binding revocation in two, one for IPSec > > (std track) and another for > > 4285 (informational) > > > > I think the last one would be best > > [Ahmad] > I agree. That should work. > > > > > Regards, marcelo > > > > > Vijay > > > > > > > > >> Gerardo > > >> > > >> > > >>> -----Original Message----- > > >>> From: mext-bounces@ietf.org > > [mailto:mext-bounces@ietf.org] On Behalf > > >>> Of Vijay Devarapalli Sent: Saturday, July 12, 2008 9:59 AM > > >>> To: Ahmad Muhanna; Sri Gundavelli; Frank Xia > > >>> Cc: Basavaraj Patil; mext@ietf.org > > >>> Subject: Re: [MEXT] Authentication option support in Binding > > >>> Revocation > > >>> > > >>> > > >>>> My understanding that Mobile IPv6 Generic Signaling > > Message (MGSM) > > >>>> and Binding Revocation are proposed as standard track document. > > >>>> Therefore, before we start talking about adding Auth protocol > > >>>> support to MGSM and consequently Binding Revocation, we > > need to do > > >>>> something about RFC4285. > > >>>> This RFC is still an Informational one and my understanding a > > >>>> standard track doc can not reference an Informational one. > > >>>> > > >>> It doesn't matter. The Generic Signaling Message just needs to > > >>> describe how to calculate the authentication data if the MN-HA > > >>> authentication option is used. RFC 4285 would be an Informational > > >>> reference, since it is not required for someone to use > > the Generic > > >>> Signaling Message. > > >>> > > >>> Vijay > > >>> > > >>> > > >>>> Any one knows what is the latest on RFC4285? Raj or Kuntal? > > >>>> > > >>>> Regards, > > >>>> Ahmad > > >>>> > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > >>>>> Behalf Of Muhanna, Ahmad (RICH1:2H10) > > >>>>> Sent: Saturday, July 12, 2008 7:05 AM > > >>>>> To: Vijay Devarapalli; Sri Gundavelli; Frank Xia > > >>>>> Cc: mext@ietf.org > > >>>>> Subject: Re: [MEXT] Authentication option support in Binding > > >>>>> Revocation > > >>>>> > > >>>>> Hi Vijay, > > >>>>> > > >>>>> > > >>>>>>> Subject: Re: [MEXT] Authentication option support in Binding > > >>>>>>> Revocation > > >>>>>>> > > >>>>>>> If there is a shared key between the mobile node and the home > > >>>>>>> agent, MN-HA Authentication option can be used. > > >>>>>>> > > >>>>>>> If there is a shared key between the mobile node and the AAA, > > >>>>>>> MN-AAA authentication option can be used. > > >>>>>>> > > >>>>>>> But you bring a good point, these options are defined to be > > >>>>>>> carried in BU/BA. We need to allow these options to > > be carried > > >>>>>>> in Generic Notification messages. > > >>>>>>> > > >>>>>> Specifying the use of MN-HA authentication option with the > > >>>>>> Generic Signaling Message sounds good to me. I doubt if the > > >>>>>> MN-AAA authentication option will ever be used with > > the Generic > > >>>>>> Signaling Message, though. > > >>>>>> > > >>>>> [Ahmad] > > >>>>> I agree. > > >>>>> If auth protocol to be used to authenticate the MIP6 Generic > > >>>>> Signaling Message, then it has to be the MN-HA AE in > > the case of > > >>>>> Client MIP6. MN-AAA AE is used during the initial > > registration to > > >>>>> help in bootstrapping MN-HA SA if it is needed. After the MIP6 > > >>>>> session is established, it is assumed that MN-HA SA has been > > >>>>> established. Therefore, MN-AAA AE has no value in this scenario. > > >>>>> Not only that, but it does not make sense either. > > >>>>> > > >>>>> > > >>>>> > > >>>>>> Vijay > > >>>>>> _______________________________________________ > > >>>>>> MEXT mailing list > > >>>>>> MEXT@ietf.org > > >>>>>> https://www.ietf.org/mailman/listinfo/mext > > >>>>>> > > >>>>>> > > >>>>> _______________________________________________ > > >>>>> MEXT mailing list > > >>>>> MEXT@ietf.org > > >>>>> https://www.ietf.org/mailman/listinfo/mext > > >>>>> > > >>>>> > > >>> _______________________________________________ > > >>> MEXT mailing list > > >>> MEXT@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/mext > > >>> > > > > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 14:09:35 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71D3B3A6C6F; Mon, 14 Jul 2008 14:09:35 -0700 (PDT) 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 5D8273A6C1C for ; Mon, 14 Jul 2008 14:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ff+p-EePJvX6 for ; Mon, 14 Jul 2008 14:09:33 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) by core3.amsl.com (Postfix) with ESMTP id A562E28C3A2 for ; Mon, 14 Jul 2008 14:06:09 -0700 (PDT) Received: from IBM52A5038A94F ([88.253.79.215]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1KIVFh1ywv-0005jy; Mon, 14 Jul 2008 17:06:35 -0400 From: "Alper Yegin" To: Date: Tue, 15 Jul 2008 00:06:13 +0300 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: Acjl79TJCLvYVGsJoUa0N8SIqY1ehQABPr3A Message-Id: <0MKp8S-1KIVFh1ywv-0005jy@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX180AWwHQRuL1M64OYUNsIEzhhfgZRPK6/cu7WM EhjVzNynORfg1IqtrAgnnqdP+g263lMRGnmZ8SG7heaOqQdxyZ skVTf0+pxc5QsJJ+vjmew== Subject: Re: [MEXT] Authentication option support in Binding Revocation 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 Folks, we should stop ignoring RFC 4285, as it is already being used in wireless architectures. Its informational RFC status, or some people's dislike, or missing an acknowledgement in the charter do not make this protocol non-existent. Unless IETF wants to wipe it off, IETF needs to accommodate it. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 14:10:57 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06D8E3A659B; Mon, 14 Jul 2008 14:10:57 -0700 (PDT) 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 DB6A53A659B for ; Mon, 14 Jul 2008 14:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, 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 bPcLDWS1CUHg for ; Mon, 14 Jul 2008 14:10:55 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id DAD6B3A6801 for ; Mon, 14 Jul 2008 14:10:51 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Jul 2008 17:11:15 -0400 Message-ID: In-Reply-To: <487BBC02.9090508@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Authentication option support in Binding Revocation Thread-Index: Acjl8zfjpim4Y7/eShe9l8vD/wU1tQAAeeVA References: <005601c8e37f$90fc3a60$5c0c7c0a@china.huawei.com><008201c8e388$984 a4240$5c0c7c0a@china.huawei.com><00bc01c8e39e$b644f6d0$5c0c7c0a@china.huawei.com><000a01c8e 3a6$0e3cc8c0$5c0c7c0a@china.huawei.com> <487BBC02.9090508@it.uc3m.es> From: "Vijay Devarapalli" To: "marcelo bagnulo braun" Cc: Basavaraj Patil , mext@ietf.org Subject: Re: [MEXT] Authentication option support in Binding Revocation 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, marcelo bagnulo braun wrote: > Vijay Devarapalli escribi=F3: >> = >> I don't think a separate draft is necessary for this. >> = >> = > probably it is cause 4285 is an informational rfc and we > probably want > that the binding revocation to a std track. If this is so, we need to > avoid the downward ref = > = > So either we do the binding revocation an informational document, or > either we do some trick to deal with the downard ref or we split the > binding revocation in two, one for IPSec (std track) and another for > 4285 (informational) = > = > I think the last one would be best The new text in the Generic Signaling Message draft would say If the MN-HA authentication option {RFC4285] was used to protect = the Binding Update and Binding Acknowledgement messages, then the = same can be used also to protect the Generic Signaling Message. The "Authentication Data" field in the MN-HA authentication option must be calculate as follows, when used with the Generic Signaling = Message. When the MN-HA authentication option is used to protect the Generic Signaling Message, timestamp-based replay protection as described in [RFC4285] must be used for preventing replay attacks. Do we need to add anything more? Why would this require a normative referen= ce to RFC 4285? IKEv2/IPsec would still be the default mechanism, of course. The Binding Revocation draft does not have to say anything about RFC 4285. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 14:32:15 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C4EE28C0E2; Mon, 14 Jul 2008 14:32:15 -0700 (PDT) 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 E060528C2E6 for ; Mon, 14 Jul 2008 14:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.099 X-Spam-Level: X-Spam-Status: No, score=-106.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_BACKHAIR_22=1, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqgvlNJYnN-P for ; Mon, 14 Jul 2008 14:32:12 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 0BE2528C0E2 for ; Mon, 14 Jul 2008 14:31:02 -0700 (PDT) Received: from localhost ([127.0.0.1]:40707 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1KIVdc-0006oz-Nc; Mon, 14 Jul 2008 23:31:16 +0200 MIME-Version: 1.0 From: "mext" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software To: charliep@computer.org X-Trac-Project: mext Date: Mon, 14 Jul 2008 21:31:16 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/mext/trac/ticket/15 Message-ID: <063.692a5e61b547fa7b7e34f34a2c06295a@tools.ietf.org> X-Trac-Ticket-ID: 15 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, amuhanna@nortel.com, mext@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: mext@ietf.org Subject: [MEXT] [mext] #15: BRR sent by HA too, not only by CN [Ahmad Muhanna ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mext@ietf.org 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 Ticket #15: BRR sent by HA too, not only by CN [Ahmad Muhanna ] BRR sent by HA too, not only by CN [Ahmad Muhanna ] The proposed change is a new functionality that it is not withing the scope of RFC3775bis and also requires new software update on the HA. On the other hand, I changed the subject again to read as "Applicability of sending BRR, BErr by the HA?" IMO, you need to separate these two messages (BRR and BErr) and they need to be discussed separately. Case of BRR message: I believe the intention of RFC3775 is to restrict the use of this message to the CN ONLY. IMO, it is quite clear that within the scope of RFC3775, this message is not applicable to the HA. For the following reasons: 1. RFC3775 defines a protocol to enable a mobile node to register its CoA in a foreign network with its home agent in order to be reachable at its home address. i.e. create a binding for the MN CoA and its HoA at the Home Agent. 2. RFC3775 developed a mechanism for the MN to refresh its BCE, i.e. RFC3775 defined a field in BA which is called lifetime. This field indicates to the MN the approved lifetime that the Home Agent agreed to honor while offering mobility services to the MN and at the same time maintain a BCE for the MN CoA and HoA. 3. In the contents of RFC3775 the mobile node is quite aware that without maintaining a current BCE at its Home agent, i.e. the basic fundamental functionality of MIPv6, the Mobile node will loose all of its mobility services and its reachability at the foreign network using its HoA. 4. RFC3775 specify that the MN needs to send a new BU message in order to refresh or extend the BCE lifetime. This is extremely important because a node like the HA, does not need to send a reminder to every single MN that it serves and maintains a BCE for. 5. If the HA needs to send a reminder to every MN about the expiry of its BCE, then we are introducing a new functionality which violates the basic RFC3775 functionality and a non sense complexity that absolutely is not necessary and not within the original intention of RFC3775. 6. On the other hand, CN maintains a limited number of BCE for specific mobile nodes and more importantly if the MN decides NOT to renew its BCE with a specific CN, the MN continues to be reachable by other CNs at its HoA and CoA via its Home Agent BCE. In other words, a MN binding with another CN represent the service (RO) between MN<->CN ONLY, however, in the case of HA it represents the MN's MIP6 service and access to the whole internet. Which also administratively governed. i.e. if the MN does not renew its BCE, then that is a clear indication for the HA to delete the MN BCE. 7. Finally, the fact that RFC3775 mentions that CN could be a HA, does not mean that the HA application at such a node need to support BRR. IMO, such a node could act as a CN for some MNs and a HA for others. Then, it is normal for this CN/HA node to support BRR for those MN which is serving as a CN but not a HA. --------------------------------------------------------------------- Alexandru Petrescu Hi Ahmad, I've changed the topic. Please make another thread, if you wish, about applicability and scope. Ahmad Muhanna wrote: [...] > [Ahmad] Hi Alex, The proposed changes is a new functionality > that it is not withing the scope of RFC3775bis and also requires > new software update on the HA. In what does that HA-sends-BRR functionality violate the basic 3775? What does it break? I see it offering better reliability: even if the critical BU is lost the HA requests the BU anew (BRR) and thus reduces the non-bound time from the entire lifetime to much less. > 6. On the other hand, CN maintains a limited number of BCE for > specific mobile nodes and more importantly if the MN decides > NOT to renew its BCE with a specific CN, the MN continues to > be reachable by other CNs at its HoA and CoA via its Home Agent > BCE. In other words, a MN binding with another CN represent > the service (RO) between MN<->CN ONLY, however, in the case > of HA it represents the MN's MIP6 service and access to the > whole internet. Which also administratively governed. i.e. > if the MN does not renew its BCE, then that is a > clear indication for the HA to delete the MN BCE. Not before it sends a BRR and waits for an answer to that. > 7. Finally, the fact that RFC3775 mentions that CN could be > a HA, does not mean that the HA application at such a node > need to support BRR. That's your reading. Other implementers read it in the way I said. > IMO, such a node could act as a CN for some MNs and a HA for > others. Then, it is normal for this CN/HA node to support BRR > for those MN which is serving as a CN but not a HA. Is a HA a "CN" when it is the dst field of the BU? --------------------------------------------------------------------- Ahmad Muhanna Okay, then RFC3775 has a mechanism already specified for updating the MN BCE at its HA, why do we need another new functionality which, IMO, does not scale and may cause a huge problem for the HA? > In what does that HA-sends-BRR functionality violate > the basic 3775? What does it break? [Ahmad] I am not sure if what does break is the right question here. It is a new functionality which is fundamentally in conflict with the original RFC3775 intention of how MIP6 BCE is managed at the HA. However, let me explain what could happen in case that the HA implements this new weird functionality: {{{ #!html
  1. Some of the HA are talking about supporting a million BCE simultaneously. Do you understand the impact on the HA when these BCEs starts getting close to expiry? and the HA needs to send a BRR message and not only that but retransmits those messages until a BU is received from each one of these MNs?
}}} {{{ #!html
  1. Personally, I wont agree to such functionality because Home Agent acts as a server offering a MIP6 mobility service to multiple MNs governed by a MIP6 protocol which offers a reliable mechanism for updating the MN BCE lifetime at the HA.
}}} {{{ #!html
  1. Let us assume for the sake of argument that this new functionality is supported by the HA, what is the impact:
    • 4.1. Can you imagine the unnecessary traffic that is generated for no reason?
    • 4.2. What is going to be the MN processing when it receives such a message? All current RFC3775 text talks about a BRR coming from the CN. Is there going to be a difference in there?
    • 4.3. How MN would recognize that this message is related to MN BCE at the HA?
    • 4.4. Backward compatibility, How, this would work for MN which only supports BRR from the CN?
    • 4.5. Finally, if this procedure is adopted, are we going to deprecate the existing one using lifetime field in BA, etc?
}}} > I see it offering better reliability: even if the critical BU > is lost the HA requests the BU anew (BRR) and thus reduces > the non-bound time from the entire lifetime to much less. [Ahmad] 1. Wow! Are you calling this a better reliability? What is your definition of reliability then? --------------------------------------------------------------------- Marcelo Bagnulo Braun i am trying to understand the impact of this in rfc3775 update I don't think that whether it is a good idea to use BRR from the HA is relevant for the discussion of RFC3775 update (it is of course relevant for the mext ml but not imho for this particular process of updating rfc3775) what imho is relavnt for the discussion of updating rfc3775 is whether rfc3775 is clear enough about whether HAs should send BRR or not From the text of rfc3775 that Alex sent in his original posting, it seems that only CNs should send BRR and BE and not by the HA, so, is there any text in rfc3775 that can possibly create confusion about HAs using BRR or BEs? Does anyone has interpreted rfc3775 in the way that HAs should send BRR and BEs? --------------------------------------------------------------------- K.Kawaguchi Couldn't we understand description in RFC3775 as follows? CN sends BRR. - Section 9.5 described Registration of CN. In it, section 9.5.5 described Sending BRR. HA does not send BRR. - Section 10.3 described Rigistration of HA. Although section 9.5.1 and section 9.5.4 were referred to, section 9.5.5 wasn't referred to. ----------------------------------------+----------------------------------- Reporter: charliep@computer.org | Owner: charliep@computer.org Type: enhancement | Status: new Priority: minor | Milestone: milestone1 Component: draft-ietf-mext-rfc3775bis | Version: 2.0 Severity: Active WG Document | Keywords: BRR, Binding Refresh Request ----------------------------------------+----------------------------------- -- Ticket URL: mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 14:39:20 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A797D3A6C40; Mon, 14 Jul 2008 14:39:20 -0700 (PDT) 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 F179428C33D for ; Mon, 14 Jul 2008 14:39:18 -0700 (PDT) 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 whNhiIbe4Svs for ; Mon, 14 Jul 2008 14:39:18 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id 40F573A6BDF for ; Mon, 14 Jul 2008 14:39:18 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 3so2231119ywj.49 for ; Mon, 14 Jul 2008 14:39:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:mime-version:content-type:content-transfer-encoding :content-disposition; bh=H2UGdct3wdi986zHaqO7aR1RlkP82s5B8qqwVED1w/c=; b=Cxy4/pRJbFBuhfNyDVtUMCPmDYd/sY1JcBm8vUymj6KXcykp4+GKWFxg0HnJF2Tj8p HO1lXpXmNdB8vzOc+ieQRPZx85hE9XnCYZQxcy5l/+lHxsKnQa++NtcC3vkNaPFYvEs6 UOkZTrveKwAAqPdyckhli8XsOTL9/ckzrrxU8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type :content-transfer-encoding:content-disposition; b=exKBvtB6Tkj0IoWFuV7D8p3iVzCj3wri3KsvMuteJr4cAAnXsBPxbHCN1g/qJBADxx bk4hBnNfM3uD8HA9Kcbh2gjetX/rJ7+uC5qX5M/mNQdKfGAbIXzfiW0i1viIffnmGT2h jZfBMfga8foXMQMSPX94V+X9SIKyqd3D2y1qM= Received: by 10.142.215.5 with SMTP id n5mr4378813wfg.131.1216071578816; Mon, 14 Jul 2008 14:39:38 -0700 (PDT) Received: by 10.142.141.12 with HTTP; Mon, 14 Jul 2008 14:39:38 -0700 (PDT) Message-ID: Date: Mon, 14 Jul 2008 14:39:38 -0700 From: "Vijay Devarapalli" To: "Arnaud Ebalard" MIME-Version: 1.0 Content-Disposition: inline Cc: ipsec@ietf.org, mext@ietf.org Subject: [MEXT] MIP6 and IKEv2 interaction (was Re: [IPsec] Redirect mechanism for IKEv2) 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 Arnaud, I changed the subject since this is not relevant to the IKEv2 redirect mechanism anymore. On Sat, Jul 12, 2008 at 3:21 AM, Arnaud Ebalard wrote: >>> To summarize most of my comments, the draft makes the redirect mechanism >>> happen at the IKE level and expects that it has no impact on the work of >>> the MIPv6 part. In practice, the address of the Home Agent being also >>> the address of the IKE GW and the IPsec SA (even if the negotiation >>> could be modified to be for different addresses regarding the IPsec SA >>> and the IKE GW), there is a need for synchronization between IKE and >>> MIPv6. IMHO, this is missing in the draft and should be stated. >> >> I am not sure if this document should talk about the interactions >> between the MIPv6 and IKEv2 processes in a particular implementation. > > If it does not, everything is left as an implementation issue, which > prevents IKE deamon from vendor "A" to be used out of the box with MIPv6 > daemon from vendor "B" on a given platform. My question would be: if > someone implements the mechanism proposed by the draft in an IKE daemon, > will that work out of the box when the IKE daemon is used on a > MN. AFAICT, no. No, it wouldn't work. RFC 4887 and RFC 5026 identify the additional requirements for making IKEv2 work with MIPv6. > IMHO, if it is time consuming to understand the precise associated needs > for interaction or to address them in the draft, it should be stated in > the document so noone thinks it will work without more work. IMHO, such a document is not required. For example it is sufficient to say that the address obtained through the INTERNAL_IP6_ADDRESS attribute should be assigned as the MIPv6 home address. Similarly it is sufficient to say that the home agent IP address bootstrapped by the mobile node should appear in the SPD entry that is used for protecting the Binding Update message. Nothing more needs to be said in the IETF. How the two requirements are implemented in the mobile node would be specific to the particular implementation. Even if we do say something about that in the IETF, it would be INFORMATIONAL at the most. >> I have seen other emails from you on this subject, especially the >> interactions between IKEv2 and MIPv6 as described in RFC 4877 and RFC >> 5026. Perhaps, as you suggest, it might be a good idea to write a >> separate document that describes how these two protocols can interact >> with each other. > > Yes, now that there is some implementation feedback on the topic, it > would be good to: > > 1) consider them > 2) address them > > The difficulties are that the subject is both IPsec/IKE and > MIPv6-related which makes it a less obvious item on ipsec or > mext ML than a new functionality for one of the protocol. > >> Personally, it is not clear to me on what sort of >> details you are looking for. I think many of the details you are >> looking for is implementation specific. > > The ones described and addressed in draft-sugimoto-mip6-pfkey-migrate > and draft-qi-mip6-ikev2-interfacing, to start with. Sure. I think these documents were proposed to be added to the IPsec and MEXT charters. But there wasn't enough support for them to get added to the charter. > Simply put: don't > expect MIPv6+IKE to work (bootstrapping, movement) without what is in > the drafts. Or it could be left implementation specific. I am not going to respond to the rest of your email since we seem to have some basic disagreement on what needs to be left implementation specific and what needs to be addressed in a Standards Track document. We should discuss that first. Vijay >>>> The IKEv2 exchange precedes the exchange of Mobile IPv6 signaling >>>> messages. >>> >>> In practice, AFAICT, the IKE exchange is *triggered* by the emission of >>> the BU. It seems that RFC 4877 has started to take a different direction >>> where IKE is used to configure MIPv6, but the details are missing. >> >> When the mobile node boots up and figures that it needs to configure a >> home address, it can trigger an IKEv2 exchange with the home agent. >> Nothing needs to be said. This would be implementation specific on the >> mobile node. > > Precisely and in the order of the sentence: > > - I agree that a MN will manage to know that it needs a Home Addres > - I don't see *how* it will trigger an IKEv2 exchange > - I don't see *how* it will retrieve the address gathered during the > IKEv2 exchange > > Again, at the end of the day, if 'A' develops a MIPv6 Daemon, and 'B' > develops an IKEv2 daemon, there is no way you can even start to make > them interoperate WRT HoA assignement *IF* they have not work together > to define a *custom* interface. What do you think? > > >>>> Therefore the mechanism described in this document can be also be >>>> used by a Mobile IPv6 home agent to re-direct a mobile node to >>>> another home agent. >>> >>> Collusion between Key Manager and HA operation. >> >> Yes. So? > > I don't follow you: are you considering that MIPv6 and IKEv2 operations > must be implemented in a single application in all cases? Hence, the > lack of interface because you consider that as internal plumbering? > > >>>> There is a Home Agent Switch mechanism available for re-directing a >>>> mobile node to another home agent, described in [5]. The Home Agent >>>> Switch mechanism can only be used after the binding cache had been >>>> created at the home agent for the mobile node. The disadvantage with >>>> this is that quite a bit of state is created on the home agent before >>>> the mobile node can be re-directed to another home agent. The >>>> mechanism described in this document can be used for re-directing a >>>> mobile node before any state is created on the home agent. >>> >>> IMHO, there is a difference between IKE and MIPv6 operations: >>> >>> 1) A Home Agent is overloaded and start redirecting MN to another HA: >>> for instance, it is already using all its available upload bandwidth >>> for registered MN (which is unrelated to IPsec/IKE). >>> 2) There are too many IKE peers connecting at the same time on an IKE >>> daemon (for the setup of IPsec SA between MN and HA or common >>> clients) and the IKE daemon starts redirecting clients to another IKE >>> daemon. >>> >>> What I mean is that, AFAICT, the two mechanism solve different problems, >>> through different channels. >> >> Do you see the need for any changes in the draft for this? > > perhaps adding some use cases by discussing how the IKE could monitor > some values (number of IKE peer, upload bandwidth consumed by MN, ...) > or how you expect an administrator would use the proposed solution: what > specific need does the solution address? > > >>> IMHO, the last sentence simply does not cover the possible associated >>> issues and how things should be done, *how* the associated users (IPsec >>> stack, MIPv6 module) are notified (on both sides). I am considering that >>> MIPv6 is used to cover all cases. >>> >>> - address of the IKE GW on the remote side >>> - the address of the HA used by the client >>> - the remote address of currently negotiated transport mode SA >>> protecting MIPv6 signaling >>> - endpoints of negotiated tunnel mode SA protecting data traffic if any >>> >>> I imagine that they will be set to the new IP. AFAICT, if the >>> negotiation was triggered by a BU, there will be a mismatch between the >>> triggering packet and the new destination. >> >> It does not have to be triggered by the Binding Update. The >> bootstrapping procedure on a Mobile IPv6 mobile node could be >> triggered for some other reason. > > Can you elaborate on that ? > > >>> How does the MN knows the address is anycast? >> >> The MIPv6 home agents anycast address is well known. See >> http://www.iana.org/assignments/ipv6-anycast-addresses. But I >> understand what you mean. I modified the paragraph as follows. >> >> When this mechanism is used with Mobile IPv6, a mobile node's >> security associations with its home agent may expire while it still >> has a valid binding cache entry at the home agent. In this case, the >> mobile node MUST NOT use the original home agent address as the >> destination address in the IKE_SA_INIT exchange to setup new security >> associations. It MUST try to setup security associations with its >> existing home agent. > > ack. Thanks. > > > Cheers, > > a+ > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 14:44:46 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0675A28C427; Mon, 14 Jul 2008 14:44:46 -0700 (PDT) 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 5F7A13A6B95 for ; Mon, 14 Jul 2008 14:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.188, 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 ftzZuUnxxEVk for ; Mon, 14 Jul 2008 14:44:43 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 33B9C28C42E for ; Mon, 14 Jul 2008 14:41:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=C99xNADs2BaXpCb658hiennSoHr91OpYXDtkxf4BsmFL4SCxWMPV2FARKb6yaQSa; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [75.26.137.116] (helo=[10.166.255.89]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1KIVoK-0006FD-VY; Mon, 14 Jul 2008 17:42:21 -0400 Message-ID: <487BC83A.6040800@earthlink.net> Date: Mon, 14 Jul 2008 14:42:18 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: mext@ietf.org, "mext-chairs@tools.ietf.org" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f525a68e13539542a34bc11740ad5a2a44d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Subject: [MEXT] Issues submitted to the issue tracker 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello folks, I have submitted all the issues that I believe are outstanding. If anyone knows of one that I have overlooked, please let me know. For the currently active issues, see: http://wiki.tools.ietf.org/wg/mext/trac/report/1 The issues that are shown in that report are the ones I'll discuss during the upcoming IETF meeting. I'll also mention whether or not there seems to be a consensus resolution to the issue. For instance, I think we have consensus on issue #4. Regards, Charlie P. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 14:54:50 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E00AF3A6A0F; Mon, 14 Jul 2008 14:54:50 -0700 (PDT) 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 1375A3A659B for ; Mon, 14 Jul 2008 14:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.794 X-Spam-Level: X-Spam-Status: No, score=-3.794 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtp41WqPQh0d for ; Mon, 14 Jul 2008 14:54:48 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id DD2283A6A0F for ; Mon, 14 Jul 2008 14:54:47 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (14.pool85-53-137.dynamic.orange.es [85.53.137.14])by smtp03.uc3m.es (Postfix) with ESMTP id B56EC487DB7; Mon, 14 Jul 2008 23:55:12 +0200 (CEST) Message-ID: <487BCB40.5050609@it.uc3m.es> Date: Mon, 14 Jul 2008 23:55:12 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Vijay Devarapalli References: <008201c8e388$984 a4240$5c0c7 c0a@china.huawei.com><00bc01c8e39e$b644f6d0$5c 0c7c0a@china.huawei.com><000a01c8e 3a6$0e3c c8c0$5c0c7c0a@china.huawei.com> <487BBC02.9090508@it.uc3m.es> In-Reply-To: X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-24.0832 TC:1F TRN:45 TV:5.5.1026(16032.002) 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: Basavaraj Patil , mext@ietf.org Subject: Re: [MEXT] Authentication option support in Binding Revocation 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-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Vijay Devarapalli escribi=F3: > Hi Marcelo, > > marcelo bagnulo braun wrote: > = >> Vijay Devarapalli escribi=F3: >> = >>> I don't think a separate draft is necessary for this. >>> >>> >>> = >> probably it is cause 4285 is an informational rfc and we >> probably want >> that the binding revocation to a std track. If this is so, we need to >> avoid the downward ref = >> >> So either we do the binding revocation an informational document, or >> either we do some trick to deal with the downard ref or we split the >> binding revocation in two, one for IPSec (std track) and another for >> 4285 (informational) = >> >> I think the last one would be best >> = > > The new text in the Generic Signaling Message draft would say > > If the MN-HA authentication option {RFC4285] was used to protect = > the Binding Update and Binding Acknowledgement messages, then the = > same can be used also to protect the Generic Signaling Message. The > "Authentication Data" field in the MN-HA authentication option must > be calculate as follows, when used with the Generic Signaling = > Message. > > > > When the MN-HA authentication option is used to protect the Generic > Signaling Message, timestamp-based replay protection as described in > [RFC4285] must be used for preventing replay attacks. > > Do we need to add anything more? Why would this require a normative refer= ence to RFC 4285? IKEv2/IPsec would still be the default mechanism, of cour= se. > = according to RFC4677 8.4.2. Normative References in Standards A normative reference is a reference to a document that must be followed in order to implement the standard. A non-normative reference (sometimes called an "informative reference") is one that is helpful to an implementor but is not needed. I guess that if we add the text you mention above, we would certainly = need rfc4285 for implemeting the generic message, right? Hence, it would be normative reference Regards, marcelo > The Binding Revocation draft does not have to say anything about RFC 4285. > > Vijay > > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 15:12:37 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A88A73A68F5; Mon, 14 Jul 2008 15:12:37 -0700 (PDT) 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 4CEB33A68F5 for ; Mon, 14 Jul 2008 15:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, 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 kt8qVla2DyQ1 for ; Mon, 14 Jul 2008 15:12:35 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 405FA3A68DF for ; Mon, 14 Jul 2008 15:12:35 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Jul 2008 18:12:57 -0400 Message-ID: In-Reply-To: <487BCB40.5050609@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Authentication option support in Binding Revocation Thread-Index: Acjl/EyR28AANImHSgev+AItkVOMBgAAOVZA References: <008201c8e388$984 a4240$5c0c7 c0a@china.huawei.com><00bc01c8e39e$b644f6d0$5c0c7c0a@china.huawei.com><000a01c8e 3a6$0e3c c8c0$5c0c7c0a@china.huawei.com> <487BBC02.9090508@it.uc3m.es> <487BCB40.5050609@it.uc3m.es> From: "Vijay Devarapalli" To: "marcelo bagnulo braun" Cc: Basavaraj Patil , mext@ietf.org Subject: Re: [MEXT] Authentication option support in Binding Revocation 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 marcelo bagnulo braun wrote: > Vijay Devarapalli escribi=F3: >> Hi Marcelo, >> = >> marcelo bagnulo braun wrote: >> = >>> Vijay Devarapalli escribi=F3: >>> = >>>> I don't think a separate draft is necessary for this. >>>> = >>>> = >>>> = >>> probably it is cause 4285 is an informational rfc and we probably >>> want that the binding revocation to a std track. If this is so, we >>> need to avoid the downward ref = >>> = >>> So either we do the binding revocation an informational document, or >>> either we do some trick to deal with the downard ref or we split the >>> binding revocation in two, one for IPSec (std track) and another >>> for 4285 (informational) = >>> = >>> I think the last one would be best >>> = >> = >> The new text in the Generic Signaling Message draft would say >> = >> If the MN-HA authentication option {RFC4285] was used to protect >> the Binding Update and Binding Acknowledgement messages, then the >> same can be used also to protect the Generic Signaling Message. The >> "Authentication Data" field in the MN-HA authentication option must >> be calculate as follows, when used with the Generic Signaling = >> Message. = >> = >> >> = >> When the MN-HA authentication option is used to protect the Generic >> Signaling Message, timestamp-based replay protection as described >> in [RFC4285] must be used for preventing replay attacks. >> = >> Do we need to add anything more? Why would this require a > normative reference to RFC 4285? IKEv2/IPsec would still be > the default mechanism, of course. >> = > according to RFC4677 > = > = > 8.4.2. Normative References in Standards > = > = > = > A normative reference is a reference to a document that > must be followed in order to implement the standard. A > non-normative reference (sometimes called an "informative > reference") is one that is helpful to an implementor but is not > needed. = > = > = > I guess that if we add the text you mention above, we would certainly > need rfc4285 for implemeting the generic message, right? I don't think so. One can implement the Generic Signaling Message protected= with IKEv2/IPsec without implementing anything from RFC 4285. The entire p= aragraph starts with, "If the MN-HA authentication option was used....". Un= der these circumstances, I would say RFC 4285 becomes an Informational refe= rence. Vijay > Hence, it would be normative reference > = > Regards, marcelo > = > = > = >> The Binding Revocation draft does not have to say anything about RFC >> 4285. = >> = >> Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 15:33:24 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 766B428C297; Mon, 14 Jul 2008 15:33:24 -0700 (PDT) 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 ACF413A6842 for ; Mon, 14 Jul 2008 15:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwQfbcMwpuSw for ; Mon, 14 Jul 2008 15:33:22 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id B5E1728C297 for ; Mon, 14 Jul 2008 15:33:22 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m6EMXlEN030431; Mon, 14 Jul 2008 17:33:48 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 17:33:47 -0500 Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 17:33:47 -0500 Message-ID: <487BD4DE.6000103@ericsson.com> Date: Mon, 14 Jul 2008 18:36:14 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Julien Laganier , mext@ietf.org References: <200807141903.00610.julien.IETF@laposte.net> In-Reply-To: <200807141903.00610.julien.IETF@laposte.net> X-OriginalArrivalTime: 14 Jul 2008 22:33:47.0655 (UTC) FILETIME=[AE788970:01C8E601] Subject: Re: [MEXT] Adoption of draft-haley-mext-generic-signaling-message-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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Chairs, I support the adoption of this document as a WG item. Cheers Suresh Julien Laganier wrote: > Hello Folks, > > The MEXT WG has a deliverable for a Generic Signaling Message for MIPv6. > > Hereby we'd like to ask WG participants whether or not they think this > individual submission should be adopted as the corresponding MEXT work > item. Please answer to this note to state your opinion by Monday July > 28th. > > Thank you for your support, > > -- julien & marcelo, MEXT chairs > > > ------------------------------------------------------------------------ > > Subject: > I-D Action:draft-haley-mext-generic-signaling-message-01.txt > From: > Internet-Drafts@ietf.org > Date: > Fri, 11 Jul 2008 08:15:01 -0700 (PDT) > To: > i-d-announce@ietf.org > > To: > i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Mobile IPv6 Generic Signaling Message > Author(s) : B. Haley, S. Gundavelli > Filename : draft-haley-mext-generic-signaling-message-01.txt > Pages : 14 > Date : 2008-07-11 > > This document specifies two new Mobility Header message types that > allow Mobile IPv6 entities to send and receive generic signaling > messages. > > > > > > > > > > > > Haley > > > > > > Expires - December 2008 > > > > > [page 1] > > > > > Mobile IPv6 Generic Signaling Message > > July 2008 > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-haley-mext-generic-signaling-message-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > ------------------------------------------------------------------------ > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 15:33:45 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0764D28C46D; Mon, 14 Jul 2008 15:33:45 -0700 (PDT) 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 C1A0128C46D for ; Mon, 14 Jul 2008 15:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CEjG+U2f4AJh for ; Mon, 14 Jul 2008 15:33:43 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id B6F3A28C13B for ; Mon, 14 Jul 2008 15:33:43 -0700 (PDT) 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 m6EMY9F9005133; Mon, 14 Jul 2008 17:34:09 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 17:34:09 -0500 Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 17:34:09 -0500 Message-ID: <487BD4F3.60702@ericsson.com> Date: Mon, 14 Jul 2008 18:36:35 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Julien Laganier , mext@ietf.org References: <200807141903.26551.julien.IETF@laposte.net> In-Reply-To: <200807141903.26551.julien.IETF@laposte.net> X-OriginalArrivalTime: 14 Jul 2008 22:34:09.0093 (UTC) FILETIME=[BB3FB750:01C8E601] Subject: Re: [MEXT] Adoption of draft-muhanna-mext-binding-revocation-02.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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Chairs, I support the adoption of this document as a WG item. Cheers Suresh Julien Laganier wrote: > Hello Folks, > > The MEXT WG has a deliverable for Binding Revocation for IP Mobility. > > Hereby we'd like to ask WG participants whether or not they think this > individual submission should be adopted as the corresponding MEXT work > item. Please answer to this note to state your opinion by Monday July > 28th. > > Thank you for your support, > > -- julien & marcelo, MEXT chairs > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Binding Revocation for IPv6 Mobility > Author(s) : A. Muhanna, et al. > Filename : draft-muhanna-mext-binding-revocation-02.txt > Pages : 32 > Date : 2008-07-11 > > This document defines the revocation semantics for terminating a > mobile node's mobility session and associated resources. These > semantics are generic enough and can be used by mobility entities in > the case of Client Mobile IPv6 and its extensions. This mechanism > allows the mobility entity which initiates the revocation procedure > to request its corresponding one to terminate either one, multiple or > all specified binding cache entries. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding-revocation-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > Subject: > I-D Action:draft-muhanna-mext-binding-revocation-02.txt > From: > Internet-Drafts@ietf.org > Date: > Fri, 11 Jul 2008 06:45:01 -0700 (PDT) > To: > i-d-announce@ietf.org > > To: > i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Binding Revocation for IPv6 Mobility > Author(s) : A. Muhanna, et al. > Filename : draft-muhanna-mext-binding-revocation-02.txt > Pages : 32 > Date : 2008-07-11 > > This document defines the revocation semantics for terminating a > mobile node's mobility session and associated resources. These > semantics are generic enough and can be used by mobility entities in > the case of Client Mobile IPv6 and its extensions. This mechanism > allows the mobility entity which initiates the revocation procedure > to request its corresponding one to terminate either one, multiple or > all specified binding cache entries. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding-revocation-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > ------------------------------------------------------------------------ > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 15:43:09 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0673B3A68C7; Mon, 14 Jul 2008 15:43:09 -0700 (PDT) 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 AC3E83A6A5C for ; Mon, 14 Jul 2008 15:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.79 X-Spam-Level: X-Spam-Status: No, score=-3.79 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aot4mUVHJv7Z for ; Mon, 14 Jul 2008 15:43:06 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 3676D3A68C7 for ; Mon, 14 Jul 2008 15:43:05 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (14.pool85-53-137.dynamic.orange.es [85.53.137.14])by smtp03.uc3m.es (Postfix) with ESMTP id 8FC5548392D; Tue, 15 Jul 2008 00:43:28 +0200 (CEST) Message-ID: <487BD690.4070008@it.uc3m.es> Date: Tue, 15 Jul 2008 00:43:28 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Vijay Devarapalli References: <00bc01c8e39e$b644f6d0$5c 0c7c0a@china.huawei.com><000a01c8e 3a6$0e3c c8c0 $5c0c7c0a@china.huawei.com> <487BBC02.9090508@it.uc3m.es> <487BCB40.5050609@it.uc3m.es> In-Reply-To: X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-27.7922 TC:1F TRN:61 TV:5.5.1026(16032.002) 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: Basavaraj Patil , mext@ietf.org Subject: Re: [MEXT] Authentication option support in Binding Revocation 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-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Vijay Devarapalli escribi=F3: > marcelo bagnulo braun wrote: > = >> Vijay Devarapalli escribi=F3: >> = >>> Hi Marcelo, >>> >>> marcelo bagnulo braun wrote: >>> >>> = >>>> Vijay Devarapalli escribi=F3: >>>> >>>> = >>>>> I don't think a separate draft is necessary for this. >>>>> >>>>> >>>>> >>>>> = >>>> probably it is cause 4285 is an informational rfc and we probably >>>> want that the binding revocation to a std track. If this is so, we >>>> need to avoid the downward ref = >>>> >>>> So either we do the binding revocation an informational document, or >>>> either we do some trick to deal with the downard ref or we split the >>>> binding revocation in two, one for IPSec (std track) and another >>>> for 4285 (informational) = >>>> >>>> I think the last one would be best >>>> >>>> = >>> The new text in the Generic Signaling Message draft would say >>> >>> If the MN-HA authentication option {RFC4285] was used to protect >>> the Binding Update and Binding Acknowledgement messages, then the >>> same can be used also to protect the Generic Signaling Message. The >>> "Authentication Data" field in the MN-HA authentication option must >>> be calculate as follows, when used with the Generic Signaling = >>> Message. = >>> >>> >>> >>> When the MN-HA authentication option is used to protect the Generic >>> Signaling Message, timestamp-based replay protection as described >>> in [RFC4285] must be used for preventing replay attacks. >>> >>> Do we need to add anything more? Why would this require a >>> = >> normative reference to RFC 4285? IKEv2/IPsec would still be >> the default mechanism, of course. >> = >> according to RFC4677 >> >> >> 8.4.2. Normative References in Standards >> >> >> >> A normative reference is a reference to a document that >> must be followed in order to implement the standard. A >> non-normative reference (sometimes called an "informative >> reference") is one that is helpful to an implementor but is not >> needed. = >> >> >> I guess that if we add the text you mention above, we would certainly >> need rfc4285 for implemeting the generic message, right? >> = > > I don't think so. One can implement the Generic Signaling Message protect= ed with IKEv2/IPsec without implementing anything from RFC 4285. The entire= paragraph starts with, "If the MN-HA authentication option was used....". = Under these circumstances, I would say RFC 4285 becomes an Informational re= ference. > > Vijay > > = mmmm... if you read the description of a non normative reference, right below, = it says that the refernece is helpful for the implementor but not = needed. I think that in this case, if someone wnat to implement the = solution using rfc4285 is more than usefu, but is actually needed. so i = don't see this as being a non normative reference. I mean, if we do this, 4285 would be certainly needed (more than just = useful) if you want to use 4285 securiyt and would be completely = irrelevant for an implementor that wants to use IPSec. So, i may not get this right, but i understand that a reference is = normative if you need it to implement some part of the spec, which seems = to be the case here. (in my experience, when you have two alternative = mechanisms that you can use in a spec, both are normative, not the other = way round, but certianly i hadn't had this level of deep disucssion in = this before, so may need more queries to figure it out) regards, marcelo >> Hence, it would be normative reference >> >> Regards, marcelo >> >> >> >> = >>> The Binding Revocation draft does not have to say anything about RFC >>> 4285. = >>> >>> Vijay >>> = > > > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 14 15:52:57 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E796E3A69F4; Mon, 14 Jul 2008 15:52:56 -0700 (PDT) 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 ED3E53A69F4 for ; Mon, 14 Jul 2008 15:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdrg2zrl36yw for ; Mon, 14 Jul 2008 15:52:54 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by core3.amsl.com (Postfix) with ESMTP id 2A68F3A6943 for ; Mon, 14 Jul 2008 15:52:54 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id k34so3549009wah.25 for ; Mon, 14 Jul 2008 15:53:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=iPR0B17O96gWZDWSZgaYtb6uAIjRAoKKQLZg8jswyKI=; b=JbgSvQn1f7xVa4S2mqmHyiz7fNRVVI8gOJakMX5TnMkl1GwgAUYwAmSz+BIRcit/TI va4tLTEDbT02bQHrNRU5iBgQ7kSlEdiQXXp0OUcgqG4Wf3r2r9gsu+Wol7VO1BWDIGrg Lv1qe1G18nn+op/MqifrvWhbdBYZ11ZosDvgU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=f3fNgiRfQIKykR+VdmUbgtiIGnelcaTxbjrkFtbI4NMrMRMADDtsLFuTBSC/CsV242 E7vv5RP+EfNW228fN8ANy+jPFWrS3Z8sLacfcLoIaS9oLXamqxfb5MC7QQqYvG3GovHn fIXBM9yXwWzeGSEKB9hw6Oho4g664u8Cfhp2A= Received: by 10.114.130.1 with SMTP id c1mr7725838wad.152.1216076000570; Mon, 14 Jul 2008 15:53:20 -0700 (PDT) Received: by 10.115.17.1 with HTTP; Mon, 14 Jul 2008 15:53:20 -0700 (PDT) Message-ID: <1d38a3350807141553p1d5fc68cr9e3f00367c54a0cf@mail.gmail.com> Date: Tue, 15 Jul 2008 06:53:20 +0800 From: "Hui Deng" To: "Vijay Devarapalli" In-Reply-To: MIME-Version: 1.0 References: Cc: ipsec@ietf.org, mext@ietf.org Subject: Re: [MEXT] MIP6 and IKEv2 interaction (was Re: [IPsec] Redirect mechanism for IKEv2) 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="===============0979058784==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0979058784== Content-Type: multipart/alternative; boundary="----=_Part_22428_15249009.1216076000568" ------=_Part_22428_15249009.1216076000568 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Please allow me cut in, > The ones described and addressed in draft-sugimoto-mip6-pfkey-migrate > > and draft-qi-mip6-ikev2-interfacing, to start with. > > Sure. I think these documents were proposed to be added to the IPsec > and MEXT charters. But there wasn't enough support for them to get > added to the charter. > as one of co-author of the draft, I have talked with both authors of these two drafts to consider merge them together, will try to propose it again in next ietf meeting. -Hui ------=_Part_22428_15249009.1216076000568 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Please allow me cut in,

> The ones described and addressed in draft-sugimoto-mip6-pfkey-migrate
> and draft-qi-mip6-ikev2-interfacing, to start with.

Sure. I think these documents were proposed to be added to the IPsec
and MEXT charters. But there wasn't enough support for them to get
added to the charter.
as one of co-author of the draft, I have talked with both authors of these two drafts
to consider merge them together, will try to propose it again in next ietf meeting.
 
-Hui
------=_Part_22428_15249009.1216076000568-- --===============0979058784== 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 --===============0979058784==-- From mext-bounces@ietf.org Mon Jul 14 15:55:24 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 015363A6C55; Mon, 14 Jul 2008 15:55:24 -0700 (PDT) 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 DC8B63A68E3 for ; Mon, 14 Jul 2008 15:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrTMQk+fxtK3 for ; Mon, 14 Jul 2008 15:55:21 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by core3.amsl.com (Postfix) with ESMTP id 949413A6B1D for ; Mon, 14 Jul 2008 15:55:21 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id x19so2720201pyg.24 for ; Mon, 14 Jul 2008 15:55:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=kDLo1iT3Yc4YlAZRbmpugMZUXsZEK9S+6WyJoPU8KzI=; b=dHLLB/Skar+yEZCMhA95IfhchDkjtQH0k3TIIsRWSdp/P3L5lToJgSb6wdkKyxclwX Byk3OiyLMDzwCPyugZIkVaH4MtoVeDsVW1pWVp7T68WK+WVDN0YAJEJ9ytKyel8fapOn u7xili1HkhLFB+aZlcz2TiLbxf1E90y22EgYo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=fyFJ79ied86yyGyPJ5yp6d5ucjFLlngeS9mcghjoPtgs93mJn0eDK1+auxjavmOFtm lURF2OwhDRm4OrvrDty8jiEAlhEPo+dZqQIoBvb6mDonRn8+TjuWITNwYb50ocL8IYdh Oe9kNPin+F0SvLtp0kGhuyP6C2k5SwUpGUcxU= Received: by 10.114.15.1 with SMTP id 1mr18252015wao.184.1216076147539; Mon, 14 Jul 2008 15:55:47 -0700 (PDT) Received: by 10.115.17.1 with HTTP; Mon, 14 Jul 2008 15:55:47 -0700 (PDT) Message-ID: <1d38a3350807141555j6b551ef0i8047cedb35bf5782@mail.gmail.com> Date: Tue, 15 Jul 2008 06:55:47 +0800 From: "Hui Deng" To: "Suresh Krishnan" In-Reply-To: <487BD4DE.6000103@ericsson.com> MIME-Version: 1.0 References: <200807141903.00610.julien.IETF@laposte.net> <487BD4DE.6000103@ericsson.com> Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Adoption of draft-haley-mext-generic-signaling-message-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: multipart/mixed; boundary="===============1787914107==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1787914107== Content-Type: multipart/alternative; boundary="----=_Part_22463_25951662.1216076147519" ------=_Part_22463_25951662.1216076147519 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, all I don't support the adoption of this document since I don't understand how this mobile header protocol could work together with IKEv2, thanks -Hui 2008/7/15 Suresh Krishnan : > Hi Chairs, > I support the adoption of this document as a WG item. > > Cheers > Suresh > > Julien Laganier wrote: > >> Hello Folks, >> >> The MEXT WG has a deliverable for a Generic Signaling Message for MIPv6. >> Hereby we'd like to ask WG participants whether or not they think this >> individual submission should be adopted as the corresponding MEXT work item. >> Please answer to this note to state your opinion by Monday July 28th. >> >> Thank you for your support, >> >> -- julien & marcelo, MEXT chairs >> >> ------------------------------------------------------------------------ >> >> Subject: >> I-D Action:draft-haley-mext-generic-signaling-message-01.txt >> From: >> Internet-Drafts@ietf.org >> Date: >> Fri, 11 Jul 2008 08:15:01 -0700 (PDT) >> To: >> i-d-announce@ietf.org >> >> To: >> i-d-announce@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : Mobile IPv6 Generic Signaling Message >> Author(s) : B. Haley, S. Gundavelli >> Filename : draft-haley-mext-generic-signaling-message-01.txt >> Pages : 14 >> Date : 2008-07-11 >> >> This document specifies two new Mobility Header message types that >> allow Mobile IPv6 entities to send and receive generic signaling >> messages. >> >> >> >> >> >> >> >> >> >> >> >> Haley >> >> >> >> >> >> Expires - December 2008 >> >> >> >> >> [page 1] >> >> >> >> >> Mobile IPv6 Generic Signaling Message >> >> July 2008 >> >> A URL for this Internet-Draft is: >> >> http://www.ietf.org/internet-drafts/draft-haley-mext-generic-signaling-message-01.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > ------=_Part_22463_25951662.1216076147519 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hello, all
 
I don't support the adoption of this document since I don't understand
how this mobile header protocol could work together with IKEv2,
 
thanks
 
-Hui
2008/7/15 Suresh Krishnan <suresh.krishnan@ericsson.com>:
Hi Chairs,
 I support the adoption of this document as a WG item.

Cheers
Suresh

Julien Laganier wrote:
Hello Folks,

The MEXT WG has a deliverable for a Generic Signaling Message for MIPv6.
Hereby we'd like to ask WG participants whether or not they think this individual submission should be adopted as the corresponding MEXT work item. Please answer to this note to state your opinion by Monday July 28th.

Thank you for your support,

-- julien & marcelo, MEXT chairs  

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

Subject:
I-D Action:draft-haley-mext-generic-signaling-message-01.txt
From:
Internet-Drafts@ietf.org
Date:
Fri, 11 Jul 2008 08:15:01 -0700 (PDT)
To:
i-d-announce@ietf.org

To:
i-d-announce@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts directories.

       Title           : Mobile IPv6 Generic Signaling Message
       Author(s)       : B. Haley, S. Gundavelli
       Filename        : draft-haley-mext-generic-signaling-message-01.txt
       Pages           : 14
       Date            : 2008-07-11

This document specifies two new Mobility Header message types that
allow Mobile IPv6 entities to send and receive generic signaling
messages.











Haley





Expires - December 2008




[page 1]




 Mobile IPv6 Generic Signaling Message

 July 2008

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-haley-mext-generic-signaling-message-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


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


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


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

------=_Part_22463_25951662.1216076147519-- --===============1787914107== 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 --===============1787914107==-- From cablesv-topexport@v-top-hk.com Mon Jul 14 19:45: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 D701628C152; Mon, 14 Jul 2008 19:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.955 X-Spam-Level: **** X-Spam-Status: No, score=4.955 tagged_above=-999 required=5 tests=[BAYES_80=2, FB_QUALITY_REPLICA=10.357, 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, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, GB_ROLEX=5, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, 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, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, SARE_SPEC_ROLEX_REP=1.666, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_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 ZgXwTy3O2Nnx; Mon, 14 Jul 2008 19:45:12 -0700 (PDT) Received: from 190-95-86-124.bk21-dsl.surnet.cl (190-95-86-124.bk21-dsl.surnet.cl [190.95.86.124]) by core3.amsl.com (Postfix) with SMTP id 0880C28C0DC; Mon, 14 Jul 2008 19:44:53 -0700 (PDT) X-Originating-IP: 66.167.108.59 by smtp.190.95.86.124; Mon, 14 Jul 2008 22:45:27 -0500 Message-ID: From: "Melva Billings" Reply-To: "Melva Billings" To: msec-archive@ietf.org Subject: Dreams can cost less replica watches from rolex here Date: Mon, 14 Jul 2008 22:45:27 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Have you always wanted a Rolex, but don't want to pay high prices for a brand name watch? Then you need to visit Prestige Replicas, a website dedicated exclusively to high quality replicas, with the most extensive inventory on the web and a proven track record of satisfied customers. http://www.wellsoe.com/ Prestige Replicas offers hundreds of Rolex replica watches starting just above $100, and during this spring season, their already low prices have been slashed by 15 percent if you buy two or more watches! No matter which model Rolex you choose, their 15% discount applies to them all! But don't let this limited time offer go by... spring is ending and it's time to impress your friends with a realistic, high quality Rolex replica watch, that will look and perform just like the real deal! http://www.wellsoe.com/ From mext-bounces@ietf.org Tue Jul 15 00:01:51 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E4DD28C2D9; Tue, 15 Jul 2008 00:01:51 -0700 (PDT) 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 5C98A3A6C3B for ; Mon, 14 Jul 2008 11:08:02 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PADgBdESjzs7 for ; Mon, 14 Jul 2008 11:08:01 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id B30BC3A6995 for ; Mon, 14 Jul 2008 11:08:00 -0700 (PDT) Received: from [75.26.137.116] (helo=[10.166.255.89]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1KISTF-0001Mb-UP; Mon, 14 Jul 2008 14:08:22 -0400 Message-ID: <487B9613.2010506@wichorus.com> Date: Mon, 14 Jul 2008 11:08:19 -0700 From: "Charles E. Perkins" Organization: WiChorus Inc. User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: mext@ietf.org X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f527f5df3fd10a5f92c82cf4b61c4cdb156350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 X-Mailman-Approved-At: Tue, 15 Jul 2008 00:01:50 -0700 Cc: "mext-chairs@tools.ietf.org" Subject: [MEXT] Mobility Support in IPv6 (draft-ietf-mext-rfc3775bis-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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello folks, I've submitted the revised Internet Draft. Until it shows up in the usual places, you can access it here: http://www.psg.com/~charliep/txt/mobilev6/draft-ietf-mext-rfc3775bis-01.txt This is another maintenance release, that does not have much text from the existing resolved issues, but instead just makes the simple editorial repairs and updates the citations to the latest RFCs and so on. The theory is that, in this way, we will have a solid base from which to depart as we make new revisions based on new consensus and resolved issues. It should be as if RFC 3775 were published recently without typos. I expect to submit another version of the draft very soon after IETF 72, which will include all of the substantive issues that have consensus resolutions from the meeting. I think that a number of existing issues already have consensus resolutions, but I can't submit any more drafts until after the meeting in Dublin. Regards, Charlie P. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 15 00:32:33 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1541F3A6B26; Tue, 15 Jul 2008 00:32:33 -0700 (PDT) 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 EAB7128C2E6 for ; Tue, 15 Jul 2008 00:32:31 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3eM2I7u1-FG for ; Tue, 15 Jul 2008 00:32:31 -0700 (PDT) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.179]) by core3.amsl.com (Postfix) with ESMTP id B60403A6883 for ; Tue, 15 Jul 2008 00:32:30 -0700 (PDT) Received: by ik-out-1112.google.com with SMTP id c28so2408489ika.5 for ; Tue, 15 Jul 2008 00:32:53 -0700 (PDT) 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=f6fhEdHyc4/BYvTFAB97aKur2oiXBKoIWrN5zRs2KRQ=; b=uTMOcvzbycgq3XG3onfibnarBVfTuA+WHxnGDPcDMvFlY+I/qW9lwmQhDCFykg0p9h X6Jm4Zf++cRqOhFOrwHhCYSBSeqsNsIL9wNFi1qh0cCvCNQXXTkzGfsXlgJBJUNaJuix oJMSahgieegBAC7f7dMW61oljauOcrjrqKu1s= 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=nWTnHG50Fkw4qUGlX/Do8fUOYTMo04C1G24dsx1TEtWiSyn6zcNzBMLcCNqyvVxPTi 6YcMAzZPAlb5jmFrYsWzYRF/9nktQLGIxXeDjFOi/yttcMBAIoKMNUKDqed8v4so+7NN WJJghPICCrPGvMCf0uKdpzag9LgJDwhp22jPk= Received: by 10.210.46.14 with SMTP id t14mr9661081ebt.124.1216107172836; Tue, 15 Jul 2008 00:32:52 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id g9sm2467255gvc.0.2008.07.15.00.32.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 15 Jul 2008 00:32:51 -0700 (PDT) From: Julien Laganier To: "Vijay Devarapalli" Date: Tue, 15 Jul 2008 09:32:51 +0200 User-Agent: KMail/1.9.9 References: <200807141856.36985.julien.IETF@laposte.net> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200807150932.51691.julien.IETF@laposte.net> Cc: mext@ietf.org Subject: Re: [MEXT] Authentication option support in Binding Revocation 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 On Monday 14 July 2008, Vijay Devarapalli wrote: > Hi Julien, Hi Vijay, > Julien Laganier wrote: > > Hello Frank, and other interesting parties, > > > > > > I wish you had left the WG chair hat off for this email. You might well wish so... I on the other hand believe I am in my role of WG chair when I try to ensure the MEXT WG follows the charter that was approved by the community. > I disagree. RFC 4285 is a valid alternative to the use of IKE/IPsec > for securing Binding Update and Binding Ack messages. Some of the > SDOs have adopted this over the use of IKE/IPsec. If the systems that > belong to these SDOs want to use the Generic Signaling Message, we > should not require them to use IKEv2/IPsec. They obviously would want > to use the same MN-HA key and the MN-HA authentication option for the > Generic Signaling Messages too. I am not saying that within some SDOs RFC 4285 isn't a valid alternative. But this is the IETF MEXT WG, and we've been chartered by the community to use IKE/IPsec as a security mechanism. The standard track MIPv6 specification mandates (thus require) to use IPsec/IKE as a security mechanism -- and this is orthogonal to the existence of an alternative security mechanism documented in the informational track RFC 4285. In a similar fashion, the standard track MGSM will mandates (thus require) to use IPsec/IKE as a security mechanism. Now anybody is free to document alternative mechanisms to secure MGSM, e.g., based on RFC 4285. Such a document can then be published as RFC as a result of either 1) the document being AD sponsored, or 2) the WG being rechartered to consider RFC 4285 as an alternative security mechanism to IKE/IPsec. --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 15 00:35:23 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 877D628C333; Tue, 15 Jul 2008 00:35:23 -0700 (PDT) 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 C541128C314; Tue, 15 Jul 2008 00:35:21 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 244e83lu74An; Tue, 15 Jul 2008 00:35:20 -0700 (PDT) Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id B2FC528C310; Tue, 15 Jul 2008 00:35:20 -0700 (PDT) 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 1KIf4U-0000Wn-C3; Tue, 15 Jul 2008 09:35:38 +0200 X-Hashcash: 1:20:080715:marcelo@it.uc3m.es::NM72hfoDf4OOjG3E:00000000000000000000000000000000000000000004X/K X-Hashcash: 1:20:080715:julien.ietf@laposte.net::L+7LzeoCDhdfCAWc:000000000000000000000000000000000000002UJi From: arno@natisbad.org (Arnaud Ebalard) To: "Vijay Devarapalli" References: X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:080715:dvijay@gmail.com::PjIQ5P1RgkQg+eGh:00rOK X-Hashcash: 1:20:080715:mext@ietf.org::w2WRDvBQcm7XYsj+:00002IE/ X-Hashcash: 1:20:080715:ipsec@ietf.org::N72OfcoBityoOqGi:0005zVv Date: Tue, 15 Jul 2008 09:34:59 +0200 Message-ID: <87bq0zvbvg.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: ipsec@ietf.org, Julien Laganier , mext@ietf.org Subject: Re: [MEXT] MIP6 and IKEv2 interaction 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="===============0791465721==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0791465721== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Transfer-Encoding: quoted-printable Hi Vijay, Julien, Marcelo, request for comment for you at the end. "Vijay Devarapalli" writes: > I changed the subject since this is not relevant to the IKEv2 redirect > mechanism anymore. ack. >>> I am not sure if this document should talk about the interactions >>> between the MIPv6 and IKEv2 processes in a particular implementation. >> >> If it does not, everything is left as an implementation issue, which >> prevents IKE deamon from vendor "A" to be used out of the box with MIPv6 >> daemon from vendor "B" on a given platform. My question would be: if >> someone implements the mechanism proposed by the draft in an IKE daemon, >> will that work out of the box when the IKE daemon is used on a >> MN. AFAICT, no. > > No, it wouldn't work. RFC 4887 and RFC 5026 identify the additional > requirements for making IKEv2 work with MIPv6. Yes, RFC 4877 contains additional requirements and help developers. RFC 5026 adds new functionalities but comes with new questions, IMHO. >> IMHO, if it is time consuming to understand the precise associated needs >> for interaction or to address them in the draft, it should be stated in >> the document so noone thinks it will work without more work. > > IMHO, such a document is not required. For example it is sufficient to > say that the address obtained through the INTERNAL_IP6_ADDRESS > attribute should be assigned as the MIPv6 home address. Similarly it > is sufficient to say that the home agent IP address bootstrapped by > the mobile node should appear in the SPD entry that is used for > protecting the Binding Update message. Nothing more needs to be said > in the IETF. How the two requirements are implemented in the mobile > node would be specific to the particular implementation. Even if we do > say something about that in the IETF, it would be INFORMATIONAL at the > most. RFC 2367 is informational (RFC 3549 too). I see your point but I also think that it makes sense to have the glue/bridges availables (even if it is in an informational fashion, resulting from development feedback). Leaving holes prevents interoperability, all the more when common interfaces do exist. MIGRATE draft is referenced in many documents including RFC 4877. >> The ones described and addressed in draft-sugimoto-mip6-pfkey-migrate >> and draft-qi-mip6-ikev2-interfacing, to start with. > > Sure. I think these documents were proposed to be added to the IPsec > and MEXT charters. But there wasn't enough support for them to get > added to the charter. There was support and at least two documents already available: they are just considered outside the scope of both WG. IPsec one because it is=20 MIPv6-specific and MEXT because it is considered an IPsec issue. >> Simply put: don't >> expect MIPv6+IKE to work (bootstrapping, movement) without what is in >> the drafts. > > Or it could be left implementation specific. Yes. I won't call that a solution, but this is a way to do it. In the end, as long as the implementation specific parts in MIPv6/IPsec/IKE picture are pointed, it is still useful, IMHO. Just like feedback from developers by the mean of informational documents. > I am not going to respond to the rest of your email since we seem to > have some basic disagreement on what needs to be left implementation > specific and what needs to be addressed in a Standards Track document. > We should discuss that first. ok, thank you for your comments. IIRC, I never asked for inclusion of implementation specific parts in Standards Track document. I just pointed that: =2D some mechanisms will not work out of the box because the glue is missing with other [normalized] parts of the picture =2D this is not explicitly stated in the documents that define the features. I find that misleading. If chairs tell me this is ok that way, I will stop bothering people with the two previous points. Cheers, a+ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIfFMqAlWVfAR6UCYRAuhIAJ9ORbRRMNZnYXk5H6x/pY7TCYprKwCffxPs o89Vl+cA6nwNj41C0JwsJBc= =U13V -----END PGP SIGNATURE----- --=-=-=-- --===============0791465721== 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 --===============0791465721==-- From mext-bounces@ietf.org Tue Jul 15 01:50:55 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 689233A6B51; Tue, 15 Jul 2008 01:50:55 -0700 (PDT) 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 EA4293A69DC for ; Tue, 15 Jul 2008 01:50:53 -0700 (PDT) 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 MVVWFliYhsM0 for ; Tue, 15 Jul 2008 01:50:53 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by core3.amsl.com (Postfix) with ESMTP id B7C603A6AEF for ; Tue, 15 Jul 2008 01:50:52 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id b11so1476076nfh.39 for ; Tue, 15 Jul 2008 01:51:16 -0700 (PDT) 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=ijAJJTe7JJYghzEPy2hbToZh3vW9YXCkrCKG+vwLUfw=; b=j3hqaAkwQjPzs3XGRD9bOtQx9sLGPOhTxvcVrQlFcwSRGqEeNUUCBsBcBapQKRgy30 Q3C1ZdNxwQ6Tptbr7on6qoU73CyB6YArzV8j7aEXSQx0KI2iErrksOdj2r/wy23W23Ww OP8GEgk4FJO/pe5foG+vnfd8SuhzKw4HvRWg8= 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=fVY6hUvtj8a9cE3cMw5uaojSYHMzkauA/HXSVOkMRF1tIFmTAKD+4tc+bEZcFsXejV 3ZuSzowDGfqQR3XzR2N3ovJlDew1UbbE9Od5mOn7K8CbBhYnweY+arLRaEXPIr45wRqD HjXhwC4IZA1g3HCkBuopMUAgNrWYGcVlNO+UE= Received: by 10.210.71.11 with SMTP id t11mr9743213eba.105.1216111876583; Tue, 15 Jul 2008 01:51:16 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id m5sm2666118gve.3.2008.07.15.01.51.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 15 Jul 2008 01:51:14 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Tue, 15 Jul 2008 10:51:10 +0200 User-Agent: KMail/1.9.9 References: <487BA2CF.9090908@it.uc3m.es> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200807151051.10807.julien.IETF@laposte.net> Subject: Re: [MEXT] Authentication option support in Binding Revocation 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 Vijay, On Monday 14 July 2008, Vijay Devarapalli wrote: > Hi Marcelo, > > marcelo bagnulo braun wrote: > > we have very clear guidance on this > > > > see the MEXT charter: > > > > The group employs IPsec and IKE as a security mechanism. The group > > shall refrain, however, from making generic extensions to these > > protocols. Any proposed extension must be reviewed by the INT and > > SEC ADs before it can be accepted as a part of a work item. > > The last sentence says any extensions to IKEv2 and IPsec should be > reviewed by the INT and SEC ADs before being adopted as WG items. Right. > > any work in using other security mechanisms need to be > > approved by SEC and INT Ads > > The charter does not say this. Perhaps I am missing something. Agree the charter does not say this. The charter quite clearly states "The group employs IPsec and IKE as a security mechanism". Thus this WG should currently limit itself to specifying use of IPsec and IKE as a security mechanism. --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 15 01:52:49 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 644433A6A37; Tue, 15 Jul 2008 01:52:49 -0700 (PDT) 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 163F03A692B for ; Tue, 15 Jul 2008 01:52:48 -0700 (PDT) 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 EvQ4vGqo2cFq for ; Tue, 15 Jul 2008 01:52:47 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by core3.amsl.com (Postfix) with ESMTP id BE6043A697F for ; Tue, 15 Jul 2008 01:52:46 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id b11so1476254nfh.39 for ; Tue, 15 Jul 2008 01:53:13 -0700 (PDT) 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=g9SIe9jNarAjasSG+PGnigoxwY1cHGVvizBrd92pe6Q=; b=KXSRi132mUU32X6eqJM1B8eqFvzEb0d8OuRNrz7KWQH0Lu50TmuQeVRJdn8Ht5VSo4 tKA9wnCemxLTTe/E73DJdHV7xofiry8HkdWWAyeJOWTS8Twzryl20mCm/qL1G0gSYU+Q zCqWOseVdNekLv0kskgxoBXhDNWlb+IXjYTz8= 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=Q1PTNUEccaBFfCJbKs4kWNjpTOWyghoGilzmIXx7UohranodBVeE3dst6P/VXjXAyo dQcXGhUsfB7ua0qHjB3Bvm4EN8h/ki2xdMLF/VQwlzoBDSlxcWnt4z5A4ExvtCxI/OyR EItZVAwnU9IzlWHH5j+B/VjBx+EJOtiWfmC1o= Received: by 10.210.28.6 with SMTP id b6mr9729151ebb.121.1216111993442; Tue, 15 Jul 2008 01:53:13 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id p10sm2666535gvf.7.2008.07.15.01.53.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 15 Jul 2008 01:53:12 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Tue, 15 Jul 2008 10:53:09 +0200 User-Agent: KMail/1.9.9 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200807151053.09663.julien.IETF@laposte.net> Cc: Basavaraj Patil Subject: Re: [MEXT] Authentication option support in Binding Revocation 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="iso-8859-15" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Raj, On Monday 14 July 2008, Basavaraj Patil wrote: > >>> 2)If authentication options defined in RFC4285 > >>> are used, which =A0option should be used? > >>> MN-HA or MN-AAA? > >> > >> This is out-of scope for this WG as well. > > > > I disagree. RFC 4285 is a valid alternative to the use of IKE/IPsec > > for securing Binding Update and Binding Ack messages. Some of the > > SDOs have adopted this over the use of IKE/IPsec. If the systems > > that belong to these SDOs want to use the Generic Signaling > > Message, we should not require them to use IKEv2/IPsec. They > > obviously would want to use the same MN-HA key and the MN-HA > > authentication option for the Generic Signaling Messages too. > > I agree with Vijay here. RFC4285 (or the bis version) is a valid > option for securing the signaling. Nobody said that 4285 is not a valid option to secure the signaling in = some contexts such as the SDOs who've been cited in the discussion. The point is, under our current charter, the MEXT WG uses IPsec and IKE. --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 15 01:59:22 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 535A03A6A91; Tue, 15 Jul 2008 01:59:22 -0700 (PDT) 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 5B7103A6A91 for ; Tue, 15 Jul 2008 01:59:20 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGtf85OqFHeE for ; Tue, 15 Jul 2008 01:59:19 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by core3.amsl.com (Postfix) with ESMTP id 9ACF53A693E for ; Tue, 15 Jul 2008 01:59:18 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id b11so1476870nfh.39 for ; Tue, 15 Jul 2008 01:59:43 -0700 (PDT) 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=xGbDvT8oMOHkeGwpw+RrlAUD3MpzQtD+60Marq9HoBA=; b=h+irqwVxdb73Nkmnsel+n/wx8aEGbh6ny2tRUaD7CleVFlJxKRYfO6pktRcIIzxXyD r+/BeXtjHSvMpxhPVHq7HV0rPh3jS9VaUyqEqU6nXGj/B7rSDWStu2HlEiNCk6FYRRE8 iw9Ehv90sx/Rx+GMMJ96utk7ZWMgVZavmAx5o= 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=NlMn5Z4NJJA9s8Paywf2/rRl/1k9TKJfFcyUTESYWY2slmqPix6k+cRQF+seKlIwk6 FKXuGzBxpycb9cInyeQGcPMjYdtfx0bwgZkxdDGn2Kc1DzhQfQrqp+OaNFveQIR5lh3D Hn7nFGCVshkZMAnUqTxwjzsZ/RryFa5ASiWdI= Received: by 10.210.136.10 with SMTP id j10mr9746921ebd.43.1216112383187; Tue, 15 Jul 2008 01:59:43 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id t2sm2686120gve.9.2008.07.15.01.59.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 15 Jul 2008 01:59:42 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Tue, 15 Jul 2008 10:59:39 +0200 User-Agent: KMail/1.9.9 References: <487BA72A.5070902@it.uc3m.es> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200807151059.39750.julien.IETF@laposte.net> Subject: Re: [MEXT] Authentication option support in Binding Revocation 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="iso-8859-15" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Vijay, On Monday 14 July 2008, Vijay Devarapalli wrote: > > The very first sentence reads: > > > > =A0 =A0 =A0 =A0 The group employs IPsec and IKE as a security mechanism. > > > > To me that means that whatever mechanism we define must work > > with IPSec IKE security and that it is out of the scope to do > > work on security based on other mechanism. > > I completely disagree. I wish I had paid more attention to that text > when we were re-chartering. = You can. > 4285bis was supposed to be in-scope. = But it's not. > > This means to me, that if we define an extension, we need to > > secure it using IPSec/IKE and that security based on other > > approaches is out of the scope and needs to be explicitly reviewed > > by INT and SEC ADs. > > The way the text is written currently, it does not say that. I read > it as - any extensions to IKEv2 and IPsec must be referred to the SEC > and INT Ads before getting adopted. It reads as: IPsec/IKE is the security mechanism, extensions to = IPsec/IKE must be reviewed by INT and SEC ADs before being adopted. Thus we are not chartered to specify use of RFC4285 as a security = mechanism to secure MGSM. > > That is our reading of the charter. We may ask for guidance > > from INT and SEC ADs if people think that we are reading it wrong, > > no problem with that. > > I think we should ask them then. I'm unsure what to ask... Do you want us to confirm with our AD that our charter saying "The group = employs IPsec and IKE as a security mechanism" implies that 4285 is = out-of-scope of our charter? --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 15 02:04:46 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B81583A6B4C; Tue, 15 Jul 2008 02:04:46 -0700 (PDT) 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 56C193A6B4C for ; Tue, 15 Jul 2008 02:04:46 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNpzcfw2AzDc for ; Tue, 15 Jul 2008 02:04:42 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by core3.amsl.com (Postfix) with ESMTP id 174FE3A6B06 for ; Tue, 15 Jul 2008 02:04:41 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id b11so1477485nfh.39 for ; Tue, 15 Jul 2008 02:05:08 -0700 (PDT) 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=if5x8NOgMHU1/fx+oZwIVhkGvqVhCQXX+qMrtnQceXQ=; b=TSqt6WYTNLAFdGr5mMKiZCuEXMBuByGpxjzyQX8eEXJGgZ5yIz6XlGkm4jtzhRmkWa L1WvsR6cBsWjZTpyFzT0qwmAOlnIHCki9YOMLjAw3gP6n0tcq6p5SlpKvKBh3F/EVpjb 2XKRc0kU3dY+2+MRPy86ZBCuz2922XBjeJTCw= 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=b1t5a2LsnDWfryaeJGRcFagzry6juhT/iGhV/GsZDHbh8TPjYdVciVING3QXbD4kLS 6A0dhvmdVo2WDbeZ8pczz45eQt8zEn3E2+4LIFqY/3/c2E5cYNR9vGOqr88+hk8Bt7oO Hoqzkg9+bVRPtSLMj4PGlbiY3EohpN6z30JlM= Received: by 10.210.129.10 with SMTP id b10mr9734479ebd.78.1216112708651; Tue, 15 Jul 2008 02:05:08 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id g9sm2705058gvc.0.2008.07.15.02.05.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 15 Jul 2008 02:05:07 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Tue, 15 Jul 2008 11:05:04 +0200 User-Agent: KMail/1.9.9 References: <0MKp8S-1KIVFh1ywv-0005jy@mrelay.perfora.net> In-Reply-To: <0MKp8S-1KIVFh1ywv-0005jy@mrelay.perfora.net> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200807151105.04543.julien.IETF@laposte.net> Subject: Re: [MEXT] Authentication option support in Binding Revocation 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 Alper, This WG has a charter and should follow it. MEXT is currently NOT chartered to use other security mechanisms than IPsec/IKE, thus an RFC4285 based security mechanism for MGSM is out-of-scope. If there's a real need to develop an RFC4285 based security mechanism for MGSM, I encourage the interested parties to first document one in an Internet Draft, and then get the draft AD sponsored, or a corresponding work item added to the MEXT charter. --julien On Monday 14 July 2008, Alper Yegin wrote: > Folks, we should stop ignoring RFC 4285, as it is already being used > in wireless architectures. Its informational RFC status, or some > people's dislike, or missing an acknowledgement in the charter do not > make this protocol non-existent. Unless IETF wants to wipe it off, > IETF needs to accommodate it. > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 15 04:27:02 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C4DD3A6882; Tue, 15 Jul 2008 04:27:02 -0700 (PDT) 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 4E75D3A6956 for ; Tue, 15 Jul 2008 04:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, 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 d54Q7H+V3j4H for ; Tue, 15 Jul 2008 04:27:00 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) by core3.amsl.com (Postfix) with ESMTP id 5DEC03A67D1 for ; Tue, 15 Jul 2008 04:27:00 -0700 (PDT) Received: from IBM52A5038A94F ([88.253.79.215]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1KIigm2TaH-0005w9; Tue, 15 Jul 2008 07:27:27 -0400 From: "Alper Yegin" To: "'Julien Laganier'" , Date: Tue, 15 Jul 2008 14:27:04 +0300 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <200807151105.04543.julien.IETF@laposte.net> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjmWeK0ShGOJJw4QK23mkwj66ur/wAE0g9Q Message-Id: <0MKp8S-1KIigm2TaH-0005w9@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX18/g7mjXaVxTVo/RhoIL6TKsYXXi+5ngesMcNE OZvbzJ77HSnT2PamVh3BkZj2X6le9RmUtI5APrv5Aq/i7i8zHr 35abwo4/vbhh5HAspMJDg== Subject: Re: [MEXT] Authentication option support in Binding Revocation 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 Julien, I acknowledge that I should have reacted to the charter text when it came up. Unless someone has a solid reason why IETF should ignore its own work and furthermore other SDOs' adoption of its own work, I cannot see a reason against working towards allowing use of RFC 4285 (and rechartering in parallel if people want to have a strictly followed charter). Alper > -----Original Message----- > From: julien laganier [mailto:julien.laganier@gmail.com] On Behalf Of > Julien Laganier > Sent: Tuesday, July 15, 2008 12:05 PM > To: mext@ietf.org > Cc: Alper Yegin > Subject: Re: [MEXT] Authentication option support in Binding Revocation > draft > > Alper, > > This WG has a charter and should follow it. MEXT is currently NOT > chartered to use other security mechanisms than IPsec/IKE, thus an > RFC4285 based security mechanism for MGSM is out-of-scope. > > If there's a real need to develop an RFC4285 based security mechanism > for MGSM, I encourage the interested parties to first document one in > an Internet Draft, and then get the draft AD sponsored, or a > corresponding work item added to the MEXT charter. > > --julien > > On Monday 14 July 2008, Alper Yegin wrote: > > Folks, we should stop ignoring RFC 4285, as it is already being used > > in wireless architectures. Its informational RFC status, or some > > people's dislike, or missing an acknowledgement in the charter do not > > make this protocol non-existent. Unless IETF wants to wipe it off, > > IETF needs to accommodate it. > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 15 04:53:23 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9A803A6956; Tue, 15 Jul 2008 04:53:23 -0700 (PDT) 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 7ACCA3A6956 for ; Tue, 15 Jul 2008 04:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.788 X-Spam-Level: X-Spam-Status: No, score=-3.788 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZG8d5aIsPDZG for ; Tue, 15 Jul 2008 04:53:21 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 203113A6982 for ; Tue, 15 Jul 2008 04:53:20 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (14.pool85-53-137.dynamic.orange.es [85.53.137.14])by smtp02.uc3m.es (Postfix) with ESMTP id EEC50411842; Tue, 15 Jul 2008 13:53:46 +0200 (CEST) Message-ID: <487C8FCA.2020601@it.uc3m.es> Date: Tue, 15 Jul 2008 13:53:46 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Alper Yegin References: <0MKp8S-1KIigm2TaH-0005w9@mrelay.perfora.net> In-Reply-To: <0MKp8S-1KIigm2TaH-0005w9@mrelay.perfora.net> X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-23.2295 TC:1F TRN:48 TV:5.5.1026(16032.006) 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] Authentication option support in Binding Revocation 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-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Alper Yegin escribi=F3: > Julien, > > I acknowledge that I should have reacted to the charter text when it came > up. = > Unless someone has a solid reason why IETF should ignore its own work and > furthermore other SDOs' adoption of its own work, I cannot see a reason > against working towards allowing use of RFC 4285 (and rechartering in > parallel if people want to have a strictly followed charter). > > = that is what it is not ok we are following the charter if we want to work on something, we open the recharter discussion and we = get WG consensu that we want to change the charter (and that among the = many different changes we want to make to the charter, a particular = subset is the most relevant) and then we start the work Regards, marcelo > Alper = > > = >> -----Original Message----- >> From: julien laganier [mailto:julien.laganier@gmail.com] On Behalf Of >> Julien Laganier >> Sent: Tuesday, July 15, 2008 12:05 PM >> To: mext@ietf.org >> Cc: Alper Yegin >> Subject: Re: [MEXT] Authentication option support in Binding Revocation >> draft >> >> Alper, >> >> This WG has a charter and should follow it. MEXT is currently NOT >> chartered to use other security mechanisms than IPsec/IKE, thus an >> RFC4285 based security mechanism for MGSM is out-of-scope. >> >> If there's a real need to develop an RFC4285 based security mechanism >> for MGSM, I encourage the interested parties to first document one in >> an Internet Draft, and then get the draft AD sponsored, or a >> corresponding work item added to the MEXT charter. >> >> --julien >> >> On Monday 14 July 2008, Alper Yegin wrote: >> = >>> Folks, we should stop ignoring RFC 4285, as it is already being used >>> in wireless architectures. Its informational RFC status, or some >>> people's dislike, or missing an acknowledgement in the charter do not >>> make this protocol non-existent. Unless IETF wants to wipe it off, >>> IETF needs to accommodate it. >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> = > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 15 05:31:50 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D7D73A6982; Tue, 15 Jul 2008 05:31:50 -0700 (PDT) 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 11F323A68F2 for ; Tue, 15 Jul 2008 05:31:49 -0700 (PDT) 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 WUT3Qvv6aTfv for ; Tue, 15 Jul 2008 05:31:45 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.187]) by core3.amsl.com (Postfix) with ESMTP id C80B13A684A for ; Tue, 15 Jul 2008 05:31:44 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 18so3159331fkq.5 for ; Tue, 15 Jul 2008 05:32:09 -0700 (PDT) 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=aeGsEJRgMmlXRw1cD4DPhEgE8zYX/j3RcenZIg6ETPs=; b=JoRt24+MdMIIVkHPmDf8J80ScAN+Hhbf66aQUBpRitjkUhjMEDuerppPIkASQYaYbl h74jNF4DKI2CPcBWudAhAOCcgDBGuIHhJV+8/nyMAX9Mwfnvf23Es6MaBva/SNY12Gc0 Udbm/YbgU69Pb0Yyt2YYOpsSLVqnhVEdq+0YA= 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=tEAUPOd0pOmufXHBwoGxjjH9si4a6JAVoXteNdBH68gigkIQUM7rVBY0KYPNuDdLco lB3vVKt/7OLEUqinAWT4rJr6299Pt2W4oYPupVzZYZ/FRyICqlByEG9NOhvCDIt/lbJ9 9vY0A8t7Sb103BWvRmclOWBaaKJxJJ9TqnoB4= Received: by 10.187.215.8 with SMTP id s8mr2422341faq.86.1216125129498; Tue, 15 Jul 2008 05:32:09 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id 11sm211332hug.62.2008.07.15.05.32.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 15 Jul 2008 05:32:08 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Tue, 15 Jul 2008 14:32:04 +0200 User-Agent: KMail/1.9.9 References: <87bq0zvbvg.fsf@natisbad.org> In-Reply-To: <87bq0zvbvg.fsf@natisbad.org> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200807151432.04934.julien.IETF@laposte.net> Cc: ipsec@ietf.org Subject: Re: [MEXT] MIP6 and IKEv2 interaction 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 Arnaud, Speaking as MEXT co-chair, below are inlined two clarifications: On Tuesday 15 July 2008, Arnaud Ebalard wrote: > > Julien, Marcelo, request for comment for you at the end. > > [...] > > >> The ones described and addressed in > >> draft-sugimoto-mip6-pfkey-migrate and > >> draft-qi-mip6-ikev2-interfacing, to start with. > > > > Sure. I think these documents were proposed to be added to the > > IPsec and MEXT charters. But there wasn't enough support for them > > to get added to the charter. > > There was support and at least two documents already available: they > are just considered outside the scope of both WG. IPsec one because > it is MIPv6-specific and MEXT because it is considered an IPsec > issue. A work item on interaction b/w IKEv2 and MIPv6 wasn't added to the MEXT charter for two reasons: - it wasn't possible to add every item with some support to the MEXT charter, prioritization was thus needed, and from that point of view there wasn't enough support for this compared to other items proposed at the time. - it was also noted that if interactions between MIPv6 and IKEv2 are to be based on PFKEY, although these could presumably fall into the MEXT scope, there's some upstream work to be done prior to that in the IPsec WG to revise PFKEY to IKEv2 and the revised IPsec architecture (RFC 4301). > >> Simply put: don't > >> expect MIPv6+IKE to work (bootstrapping, movement) without what is > >> in the drafts. > > > > Or it could be left implementation specific. > > Yes. I won't call that a solution, but this is a way to do it. In the > end, as long as the implementation specific parts in MIPv6/IPsec/IKE > picture are pointed, it is still useful, IMHO. Just like feedback > from developers by the mean of informational documents. > > > I am not going to respond to the rest of your email since we seem > > to have some basic disagreement on what needs to be left > > implementation specific and what needs to be addressed in a > > Standards Track document. We should discuss that first. > > ok, thank you for your comments. IIRC, I never asked for inclusion of > implementation specific parts in Standards Track document. I just > pointed that: > > - some mechanisms will not work out of the box because the glue is > missing with other [normalized] parts of the picture > - this is not explicitly stated in the documents that define the > features. I find that misleading. > > If chairs tell me this is ok that way, I will stop bothering people > with the two previous points. As of now we are not chartered to work on this topic, thus I consider we don't need to discuss that more, at least for now. --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 15 07:05:46 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D03FE3A693A; Tue, 15 Jul 2008 07:05:46 -0700 (PDT) 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 E14483A693A for ; Tue, 15 Jul 2008 07:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604, 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 eDE7PfhcXAPw for ; Tue, 15 Jul 2008 07:05:40 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) by core3.amsl.com (Postfix) with ESMTP id 920DD3A69D2 for ; Tue, 15 Jul 2008 07:05:40 -0700 (PDT) Received: from IBM52A5038A94F ([88.253.69.163]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1KIlAG0UU7-0004Yp; Tue, 15 Jul 2008 10:06:05 -0400 From: "Alper Yegin" To: "'marcelo bagnulo braun'" Date: Tue, 15 Jul 2008 17:05:39 +0300 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <487C8FCA.2020601@it.uc3m.es> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjmcXWsps3Y1yMoQAWFTTAJabmYxwAEaVLw Message-Id: <0MKpCa-1KIlAG0UU7-0004Yp@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX19Jy0wdTaHd42eV5Z4Wt41LckIAtbFJKqh0a2X X6DkPjwqEdjjg3hQ1/QIKWHwJ2uT+QNNQ1FF3pyc3W4WEL+Xjh fUMbTAaRjU70x7SAGS/Ng== Cc: mext@ietf.org, 'Julien Laganier' Subject: Re: [MEXT] Authentication option support in Binding Revocation 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Marcelo, I certainly respect the WG and the chairs if they want to strictly follow the charter. Even though several WGs in IETF utilize some leg room in going beyond the charter in a healthy and constructive way, I cannot expect every WG do the same as we cannot define a fine rule around this flexibility. For that I'd not even encourage we do that. But I'd suggest the work and discussions be accommodated to reflect the industry situation (use of RFC 4285), and Initiate discussion for a micro-surgery on the charter. Bundling this change with any other would be a sure recipe for unnecessary delay. Alper > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > Sent: Tuesday, July 15, 2008 2:54 PM > To: Alper Yegin > Cc: 'Julien Laganier'; mext@ietf.org > Subject: Re: [MEXT] Authentication option support in Binding Revocation > draft > = > Alper Yegin escribi=F3: > > Julien, > > > > I acknowledge that I should have reacted to the charter text when it > came > > up. > > Unless someone has a solid reason why IETF should ignore its own work > and > > furthermore other SDOs' adoption of its own work, I cannot see a reason > > against working towards allowing use of RFC 4285 (and rechartering in > > parallel if people want to have a strictly followed charter). > > > > > = > that is what it is not ok > = > we are following the charter > if we want to work on something, we open the recharter discussion and we > get WG consensu that we want to change the charter (and that among the > many different changes we want to make to the charter, a particular > subset is the most relevant) > = > and then we start the work > = > Regards, marcelo > = > = > > Alper > > > > > >> -----Original Message----- > >> From: julien laganier [mailto:julien.laganier@gmail.com] On Behalf Of > >> Julien Laganier > >> Sent: Tuesday, July 15, 2008 12:05 PM > >> To: mext@ietf.org > >> Cc: Alper Yegin > >> Subject: Re: [MEXT] Authentication option support in Binding Revocation > >> draft > >> > >> Alper, > >> > >> This WG has a charter and should follow it. MEXT is currently NOT > >> chartered to use other security mechanisms than IPsec/IKE, thus an > >> RFC4285 based security mechanism for MGSM is out-of-scope. > >> > >> If there's a real need to develop an RFC4285 based security mechanism > >> for MGSM, I encourage the interested parties to first document one in > >> an Internet Draft, and then get the draft AD sponsored, or a > >> corresponding work item added to the MEXT charter. > >> > >> --julien > >> > >> On Monday 14 July 2008, Alper Yegin wrote: > >> > >>> Folks, we should stop ignoring RFC 4285, as it is already being used > >>> in wireless architectures. Its informational RFC status, or some > >>> people's dislike, or missing an acknowledgement in the charter do not > >>> make this protocol non-existent. Unless IETF wants to wipe it off, > >>> IETF needs to accommodate it. > >>> > >>> _______________________________________________ > >>> MEXT mailing list > >>> MEXT@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mext > >>> > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 15 07:05:59 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 737C73A6A6F; Tue, 15 Jul 2008 07:05:59 -0700 (PDT) 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 4A1153A6A53 for ; Tue, 15 Jul 2008 07:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.566 X-Spam-Level: X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pH0rmb1GUml for ; Tue, 15 Jul 2008 07:05:57 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id D7A123A684A for ; Tue, 15 Jul 2008 07:05:56 -0700 (PDT) Received: from localhost ([127.0.0.1]:57876 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1KIlAS-0006Ne-DL; Tue, 15 Jul 2008 16:06:13 +0200 MIME-Version: 1.0 From: "mext" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software To: charliep@computer.org, julien.ietf@laposte.net X-Trac-Project: mext Date: Tue, 15 Jul 2008 14:06:12 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/mext/trac/ticket/3#comment:3 Message-ID: <074.4a9189d6832a511a998e9466cfe39cb8@tools.ietf.org> References: <065.3dcc374ac20c8e176e52b82612be2b65@tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <065.3dcc374ac20c8e176e52b82612be2b65@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, julien.ietf@laposte.net, mext@ietf.org, marcelo@it.uc3m.es, alexandru.petrescu@gmail.com X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: mext@ietf.org Subject: Re: [MEXT] [mext] #3: BRR, BErr are sent by HA too, not only by CN [Alexandru Petrescu ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mext@ietf.org 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 Ticket #3: BRR, BErr are sent by HA too, not only by CN [Alexandru Petrescu ] >From charliep@computer.org): * status: new => closed * severity: => Active WG Document * version: => 1.0 * milestone: => milestone1 * keywords: => BErr, BRR * resolution: => invalid This issue is being closed because it has been subdivided into two other issues, namely issue #12 and issue #15. ----------------------------------------+----------------------------------- Reporter: julien.ietf@laposte.net | Owner: charliep@computer.org Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: draft-ietf-mext-rfc3775bis | Version: 1.0 Severity: Active WG Document | Resolution: invalid Keywords: BErr, BRR | ----------------------------------------+----------------------------------- -- Ticket URL: mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 15 07:17:05 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BEC83A6995; Tue, 15 Jul 2008 07:17:05 -0700 (PDT) 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 784003A68C2 for ; Tue, 15 Jul 2008 07:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.785 X-Spam-Level: X-Spam-Status: No, score=-3.785 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhMs11YVqM3Z for ; Tue, 15 Jul 2008 07:17:02 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 488AE3A67EC for ; Tue, 15 Jul 2008 07:17:01 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (14.pool85-53-137.dynamic.orange.es [85.53.137.14])by smtp01.uc3m.es (Postfix) with ESMTP id 552EB7AADB1; Tue, 15 Jul 2008 16:17:28 +0200 (CEST) Message-ID: <487CB177.2080605@it.uc3m.es> Date: Tue, 15 Jul 2008 16:17:27 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Alper Yegin References: <0MKpCa-1KIlAG0UU7-0004Yp@mrelay.perfora.net> In-Reply-To: <0MKpCa-1KIlAG0UU7-0004Yp@mrelay.perfora.net> X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-30.9175 TC:1F TRN:69 TV:5.5.1026(16032.007) 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] Authentication option support in Binding Revocation 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-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Alper, My point is the following one: - the charter was approved by consensus and review by the IAB and IESG. - it is our work to make sure that it is honoured (not in the exact word = but in spirit, resulting in some flexibility) - in this particular case, there is a very clear note in the charter, = which clearly seems to me that we were provided some strict guidance = w.r.t. to this particular issue, so that is why we are being more = careful (and more rigid, if you wish) that what we would normally be = with other matters. Hopefully we will clarify this soon and we can have a clear way on how = to move forward. Regards, marcelo Alper Yegin escribi=F3: > Marcelo, > > I certainly respect the WG and the chairs if they want to strictly follow > the charter. Even though several WGs in IETF utilize some leg room in goi= ng > beyond the charter in a healthy and constructive way, I cannot expect eve= ry > WG do the same as we cannot define a fine rule around this flexibility. F= or > that I'd not even encourage we do that. > > But I'd suggest the work and discussions be accommodated to reflect the > industry situation (use of RFC 4285), and > > Initiate discussion for a micro-surgery on the charter. Bundling this cha= nge > with any other would be a sure recipe for unnecessary delay. > > Alper > > = >> -----Original Message----- >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >> Sent: Tuesday, July 15, 2008 2:54 PM >> To: Alper Yegin >> Cc: 'Julien Laganier'; mext@ietf.org >> Subject: Re: [MEXT] Authentication option support in Binding Revocation >> draft >> >> Alper Yegin escribi=F3: >> = >>> Julien, >>> >>> I acknowledge that I should have reacted to the charter text when it >>> = >> came >> = >>> up. >>> Unless someone has a solid reason why IETF should ignore its own work >>> = >> and >> = >>> furthermore other SDOs' adoption of its own work, I cannot see a reason >>> against working towards allowing use of RFC 4285 (and rechartering in >>> parallel if people want to have a strictly followed charter). >>> >>> >>> = >> that is what it is not ok >> >> we are following the charter >> if we want to work on something, we open the recharter discussion and we >> get WG consensu that we want to change the charter (and that among the >> many different changes we want to make to the charter, a particular >> subset is the most relevant) >> >> and then we start the work >> >> Regards, marcelo >> >> >> = >>> Alper >>> >>> >>> = >>>> -----Original Message----- >>>> From: julien laganier [mailto:julien.laganier@gmail.com] On Behalf Of >>>> Julien Laganier >>>> Sent: Tuesday, July 15, 2008 12:05 PM >>>> To: mext@ietf.org >>>> Cc: Alper Yegin >>>> Subject: Re: [MEXT] Authentication option support in Binding Revocation >>>> draft >>>> >>>> Alper, >>>> >>>> This WG has a charter and should follow it. MEXT is currently NOT >>>> chartered to use other security mechanisms than IPsec/IKE, thus an >>>> RFC4285 based security mechanism for MGSM is out-of-scope. >>>> >>>> If there's a real need to develop an RFC4285 based security mechanism >>>> for MGSM, I encourage the interested parties to first document one in >>>> an Internet Draft, and then get the draft AD sponsored, or a >>>> corresponding work item added to the MEXT charter. >>>> >>>> --julien >>>> >>>> On Monday 14 July 2008, Alper Yegin wrote: >>>> >>>> = >>>>> Folks, we should stop ignoring RFC 4285, as it is already being used >>>>> in wireless architectures. Its informational RFC status, or some >>>>> people's dislike, or missing an acknowledgement in the charter do not >>>>> make this protocol non-existent. Unless IETF wants to wipe it off, >>>>> IETF needs to accommodate it. >>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> >>>>> = >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >>> >>> = > > > > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 15 07:19:36 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 526883A6AD4; Tue, 15 Jul 2008 07:19:36 -0700 (PDT) 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 92AAF3A6AD4 for ; Tue, 15 Jul 2008 07:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.568 X-Spam-Level: X-Spam-Status: No, score=-106.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJCwEds9d1sv for ; Tue, 15 Jul 2008 07:19:34 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id B87533A6A51 for ; Tue, 15 Jul 2008 07:19:33 -0700 (PDT) Received: from localhost ([127.0.0.1]:57711 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1KIlNl-0003qJ-F2; Tue, 15 Jul 2008 16:19:57 +0200 MIME-Version: 1.0 From: "mext" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software To: julien.ietf@laposte.net X-Trac-Project: mext Date: Tue, 15 Jul 2008 14:19:57 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/mext/trac/ticket/8#comment:1 Message-ID: <072.0eed80369a02d3e091c58a975aaad445@tools.ietf.org> References: <063.7622031672aced0787b70d358cb06abb@tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <063.7622031672aced0787b70d358cb06abb@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: julien.ietf@laposte.net, julien.IETF@laposte.net, mext@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: julien.IETF@laposte.net, mext@ietf.org Subject: [MEXT] "Re: [mext] #8: Application using the care-of address " X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mext@ietf.org 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 Ticket #8: Application using the care-of address Old description: > RFC3775 mentions two times the possibility to use the > care-of address as a source address in outgoing packets. In the first > occurence, RFC3775 says that APIs to control this use are out-of-scope, > but since an API that allows an application to require the care-of > address to be used in outgoing packets has been specified since then in > RFC5014, RFC3775bis could mention RFC5014 as an example of such an API. > In the second occurence, RFC3775 says that a multicast application > could use the care-of address as a source address in outgoing packets > if it know the care-of address, but since RFC5014 allows to use the > care-of address as a source address without requiring the application > to knows the address itself that should be corrected in RFC3775bis. See > below the two slight modifications, plus the additional informative > reference. > > Please let me know what you think. > > Thanks, > > --julien > > ------------------------------------------------------------------------- > > OLD: > > o The mobile node MAY choose to directly use one of its care-of > addresses as the source of the packet, not requiring the use of a > Home Address option in the packet. This is particularly useful > for short-term communication that may easily be retried if it > fails. Using the mobile node's care-of address as the source for > such queries will generally have a lower overhead than using the > mobile node's home address, since no extra options need be used in > either the query or its reply. Such packets can be routed > normally, directly between their source and destination without > relying on Mobile IPv6. If application running on the mobile node > has no particular knowledge that the communication being sent fits > within this general type of communication, however, the mobile > node should not use its care-of address as the source of the > packet in this way. > > The choice of the most efficient communications method is > application specific, and outside the scope of this specification. > The APIs necessary for controlling the choice are also out of > scope. > > NEW: > > o The mobile node MAY choose to directly use one of its care-of > addresses as the source of the packet, not requiring the use of a > Home Address option in the packet. This is particularly useful > for short-term communication that may easily be retried if it > fails. Using the mobile node's care-of address as the source for > such queries will generally have a lower overhead than using the > mobile node's home address, since no extra options need be used in > either the query or its reply. Such packets can be routed > normally, directly between their source and destination without > relying on Mobile IPv6. If application running on the mobile node > has no particular knowledge that the communication being sent fits > within this general type of communication, however, the mobile > node should not use its care-of address as the source of the > packet in this way. > > The choice of the most efficient communications method is > application specific, and outside the scope of this specification. > The APIs necessary for controlling the choice are also out of > | scope. One example of such an API is described in the IPv6 Socket > | API for Source Address Selection specification [RFC5014]. > > -------------------------------------------------------------------------- > > OLD: > > A mobile node that wishes to send packets to a multicast group also > has two options: > > 1. Send directly on the foreign link being visited. > > The application is aware of the care-of address and uses it as a > source address for multicast traffic, just like it would use a > stationary address. The mobile node MUST NOT use Home Address > destination option in such traffic. > > NEW: > > A mobile node that wishes to send packets to a multicast group also > has two options: > > 1. Send directly on the foreign link being visited. > > | The application uses the care-of address as a source address for > | multicast traffic, just like it would use a stationary address. > | This requires that the application either knows the care-of > | address, or uses an API such as the IPv6 Socket API for Source > | Address Selection specification [RFC5014] to request the stack to > | use the care-of address as a source address in sent packets. The > mobile node MUST NOT use Home Address destination option in such > traffic. > > -------------------------------------------------------------------------- > > NEW: > > 18.2. Informative References > > | [RFC5014] Nordmark, E., Chakrabarti, S., and Laganier, J., "IPv6 > | Socket API for Source Address Selection", RFC 5014, > | September 2007. > > ---- > > [editorial note by Charles E. Perkins]: > Following this, there was a discussion about how to enable > an IKE daemon to use the care-of address. Since that seems > out of scope for rfc3775bis, I have not included it as part > the discussion for this issue. New description: RFC3775 mentions two times the possibility to use the care-of address as a source address in outgoing packets. In the first occurence, RFC3775 says that APIs to control this use are out-of-scope, but since an API that allows an application to require the care-of address to be used in outgoing packets has been specified since then in RFC5014, RFC3775bis could mention RFC5014 as an example of such an API. In the second occurence, RFC3775 says that a multicast application could use the care-of address as a source address in outgoing packets if it know the care-of address, but since RFC5014 allows to use the care-of address as a source address without requiring the application to knows the address itself that should be corrected in RFC3775bis. See below the two slight modifications, plus the additional informative reference. Please let me know what you think. Thanks, --julien ------------------------------------------------------------------------- OLD: o The mobile node MAY choose to directly use one of its care-of addresses as the source of the packet, not requiring the use of a Home Address option in the packet. This is particularly useful for short-term communication that may easily be retried if it fails. Using the mobile node's care-of address as the source for such queries will generally have a lower overhead than using the mobile node's home address, since no extra options need be used in either the query or its reply. Such packets can be routed normally, directly between their source and destination without relying on Mobile IPv6. If application running on the mobile node has no particular knowledge that the communication being sent fits within this general type of communication, however, the mobile node should not use its care-of address as the source of the packet in this way. The choice of the most efficient communications method is application specific, and outside the scope of this specification. The APIs necessary for controlling the choice are also out of scope. NEW: o The mobile node MAY choose to directly use one of its care-of addresses as the source of the packet, not requiring the use of a Home Address option in the packet. This is particularly useful for short-term communication that may easily be retried if it fails. Using the mobile node's care-of address as the source for such queries will generally have a lower overhead than using the mobile node's home address, since no extra options need be used in either the query or its reply. Such packets can be routed normally, directly between their source and destination without relying on Mobile IPv6. If application running on the mobile node has no particular knowledge that the communication being sent fits within this general type of communication, however, the mobile node should not use its care-of address as the source of the packet in this way. The choice of the most efficient communications method is application specific, and outside the scope of this specification. The APIs necessary for controlling the choice are also out of > scope. One example of such an API is described in the IPv6 Socket > API for Source Address Selection specification [RFC5014]. -------------------------------------------------------------------------- OLD: A mobile node that wishes to send packets to a multicast group also has two options: 1. Send directly on the foreign link being visited. The application is aware of the care-of address and uses it as a source address for multicast traffic, just like it would use a stationary address. The mobile node MUST NOT use Home Address destination option in such traffic. NEW: A mobile node that wishes to send packets to a multicast group also has two options: 1. Send directly on the foreign link being visited. > The application uses the care-of address as a source address for > multicast traffic, just like it would use a stationary address. > This requires that the application either knows the care-of > address, or uses an API such as the IPv6 Socket API for Source > Address Selection specification [RFC5014] to request the stack to > use the care-of address as a source address in sent packets. The mobile node MUST NOT use Home Address destination option in such traffic. -------------------------------------------------------------------------- NEW: 18.2. Informative References > [RFC5014] Nordmark, E., Chakrabarti, S., and Laganier, J., "IPv6 > Socket API for Source Address Selection", RFC 5014, > September 2007. ---- [editorial note by Charles E. Perkins]: Following this, there was a discussion about how to enable an IKE daemon to use the care-of address. Since that seems out of scope for rfc3775bis, I have not included it as part the discussion for this issue. ----------------------------------------+----------------------------------- Reporter: charliep@computer.org | Owner: charliep@computer.org Type: enhancement | Status: new Priority: minor | Milestone: Component: draft-ietf-mext-rfc3775bis | Version: Severity: Active WG Document | Resolution: Keywords: | ----------------------------------------+----------------------------------- -- Ticket URL: mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 15 07:22:45 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 263F93A69D2; Tue, 15 Jul 2008 07:22:45 -0700 (PDT) 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 B088F3A677C for ; Tue, 15 Jul 2008 07:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.57 X-Spam-Level: X-Spam-Status: No, score=-106.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zjkQufZv6lW for ; Tue, 15 Jul 2008 07:22:42 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id DA7D43A6995 for ; Tue, 15 Jul 2008 07:22:41 -0700 (PDT) Received: from localhost ([127.0.0.1]:57771 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1KIlQn-0002ij-W9; Tue, 15 Jul 2008 16:23:06 +0200 MIME-Version: 1.0 From: "mext" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software To: julien.ietf@laposte.net X-Trac-Project: mext Date: Tue, 15 Jul 2008 14:23:05 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/mext/trac/ticket/8#comment:2 Message-ID: <072.a39167a018989790ebcb0bc72610b099@tools.ietf.org> References: <063.7622031672aced0787b70d358cb06abb@tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <063.7622031672aced0787b70d358cb06abb@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: julien.ietf@laposte.net, julien.IETF@laposte.net, mext@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: julien.IETF@laposte.net, mext@ietf.org Subject: [MEXT] "Re: [mext] #8: Application using the care-of address " X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mext@ietf.org 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 Ticket #8: Application using the care-of address Old description: > RFC3775 mentions two times the possibility to use the > care-of address as a source address in outgoing packets. In the first > occurence, RFC3775 says that APIs to control this use are out-of-scope, > but since an API that allows an application to require the care-of > address to be used in outgoing packets has been specified since then in > RFC5014, RFC3775bis could mention RFC5014 as an example of such an API. > In the second occurence, RFC3775 says that a multicast application > could use the care-of address as a source address in outgoing packets > if it know the care-of address, but since RFC5014 allows to use the > care-of address as a source address without requiring the application > to knows the address itself that should be corrected in RFC3775bis. See > below the two slight modifications, plus the additional informative > reference. > > Please let me know what you think. > > Thanks, > > --julien > > ------------------------------------------------------------------------- > > OLD: > > o The mobile node MAY choose to directly use one of its care-of > addresses as the source of the packet, not requiring the use of a > Home Address option in the packet. This is particularly useful > for short-term communication that may easily be retried if it > fails. Using the mobile node's care-of address as the source for > such queries will generally have a lower overhead than using the > mobile node's home address, since no extra options need be used in > either the query or its reply. Such packets can be routed > normally, directly between their source and destination without > relying on Mobile IPv6. If application running on the mobile node > has no particular knowledge that the communication being sent fits > within this general type of communication, however, the mobile > node should not use its care-of address as the source of the > packet in this way. > > The choice of the most efficient communications method is > application specific, and outside the scope of this specification. > The APIs necessary for controlling the choice are also out of > scope. > > NEW: > > o The mobile node MAY choose to directly use one of its care-of > addresses as the source of the packet, not requiring the use of a > Home Address option in the packet. This is particularly useful > for short-term communication that may easily be retried if it > fails. Using the mobile node's care-of address as the source for > such queries will generally have a lower overhead than using the > mobile node's home address, since no extra options need be used in > either the query or its reply. Such packets can be routed > normally, directly between their source and destination without > relying on Mobile IPv6. If application running on the mobile node > has no particular knowledge that the communication being sent fits > within this general type of communication, however, the mobile > node should not use its care-of address as the source of the > packet in this way. > > The choice of the most efficient communications method is > application specific, and outside the scope of this specification. > The APIs necessary for controlling the choice are also out of > > scope. One example of such an API is described in the IPv6 Socket > > API for Source Address Selection specification [RFC5014]. > > -------------------------------------------------------------------------- > > OLD: > > A mobile node that wishes to send packets to a multicast group also > has two options: > > 1. Send directly on the foreign link being visited. > > The application is aware of the care-of address and uses it as a > source address for multicast traffic, just like it would use a > stationary address. The mobile node MUST NOT use Home Address > destination option in such traffic. > > NEW: > > A mobile node that wishes to send packets to a multicast group also > has two options: > > 1. Send directly on the foreign link being visited. > > > The application uses the care-of address as a source address for > > multicast traffic, just like it would use a stationary address. > > This requires that the application either knows the care-of > > address, or uses an API such as the IPv6 Socket API for Source > > Address Selection specification [RFC5014] to request the stack to > > use the care-of address as a source address in sent packets. The > mobile node > MUST NOT use Home Address destination option in such traffic. > > -------------------------------------------------------------------------- > > NEW: > > 18.2. Informative References > > > [RFC5014] Nordmark, E., Chakrabarti, S., and Laganier, J., "IPv6 > > Socket API for Source Address Selection", RFC 5014, > > September 2007. > > ---- > > [editorial note by Charles E. Perkins]: > Following this, there was a discussion about how to enable > an IKE daemon to use the care-of address. Since that seems > out of scope for rfc3775bis, I have not included it as part > the discussion for this issue. New description: RFC3775 mentions two times the possibility to use the care-of address as a source address in outgoing packets. In the first occurence, RFC3775 says that APIs to control this use are out-of-scope, but since an API that allows an application to require the care-of address to be used in outgoing packets has been specified since then in RFC5014, RFC3775bis could mention RFC5014 as an example of such an API. In the second occurence, RFC3775 says that a multicast application could use the care-of address as a source address in outgoing packets if it know the care-of address, but since RFC5014 allows to use the care-of address as a source address without requiring the application to knows the address itself that should be corrected in RFC3775bis. See below the two slight modifications, plus the additional informative reference. Please let me know what you think. Thanks, --julien ------------------------------------------------------------------------- OLD: o The mobile node MAY choose to directly use one of its care-of addresses as the source of the packet, not requiring the use of a Home Address option in the packet. This is particularly useful for short-term communication that may easily be retried if it fails. Using the mobile node's care-of address as the source for such queries will generally have a lower overhead than using the mobile node's home address, since no extra options need be used in either the query or its reply. Such packets can be routed normally, directly between their source and destination without relying on Mobile IPv6. If application running on the mobile node has no particular knowledge that the communication being sent fits within this general type of communication, however, the mobile node should not use its care-of address as the source of the packet in this way. The choice of the most efficient communications method is application specific, and outside the scope of this specification. The APIs necessary for controlling the choice are also out of scope. NEW: o The mobile node MAY choose to directly use one of its care-of addresses as the source of the packet, not requiring the use of a Home Address option in the packet. This is particularly useful for short-term communication that may easily be retried if it fails. Using the mobile node's care-of address as the source for such queries will generally have a lower overhead than using the mobile node's home address, since no extra options need be used in either the query or its reply. Such packets can be routed normally, directly between their source and destination without relying on Mobile IPv6. If application running on the mobile node has no particular knowledge that the communication being sent fits within this general type of communication, however, the mobile node should not use its care-of address as the source of the packet in this way. The choice of the most efficient communications method is application specific, and outside the scope of this specification. The APIs necessary for controlling the choice are also out of scope. > > One example of such an API is described in the IPv6 Socket API for Source Address Selection specification [RFC5014]. -------------------------------------------------------------------------- OLD: A mobile node that wishes to send packets to a multicast group also has two options: 1. Send directly on the foreign link being visited. The application is aware of the care-of address and uses it as a source address for multicast traffic, just like it would use a stationary address. The mobile node MUST NOT use Home Address destination option in such traffic. NEW: A mobile node that wishes to send packets to a multicast group also has two options: 1. Send directly on the foreign link being visited. > The application uses the care-of address as a source address for > multicast traffic, just like it would use a stationary address. > This requires that the application either knows the care-of > address, or uses an API such as the IPv6 Socket API for Source > Address Selection specification [RFC5014] to request the stack to > use the care-of address as a source address in sent packets. The mobile node MUST NOT use Home Address destination option in such traffic. -------------------------------------------------------------------------- NEW: 18.2. Informative References > [RFC5014] Nordmark, E., Chakrabarti, S., and Laganier, J., "IPv6 > Socket API for Source Address Selection", RFC 5014, > September 2007. ---- [editorial note by Charles E. Perkins]: Following this, there was a discussion about how to enable an IKE daemon to use the care-of address. Since that seems out of scope for rfc3775bis, I have not included it as part the discussion for this issue. ----------------------------------------+----------------------------------- Reporter: charliep@computer.org | Owner: charliep@computer.org Type: enhancement | Status: new Priority: minor | Milestone: Component: draft-ietf-mext-rfc3775bis | Version: Severity: Active WG Document | Resolution: Keywords: | ----------------------------------------+----------------------------------- -- Ticket URL: mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 15 08:12:39 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 979C23A691C; Tue, 15 Jul 2008 08:12:39 -0700 (PDT) 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 CF2753A67A8; Tue, 15 Jul 2008 08:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 bNIAZReKGwwf; Tue, 15 Jul 2008 08:12:38 -0700 (PDT) Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id D69983A63D3; Tue, 15 Jul 2008 08:12:37 -0700 (PDT) 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 1KImD5-0000y7-NE; Tue, 15 Jul 2008 17:12:59 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: Julien Laganier References: <87bq0zvbvg.fsf@natisbad.org> <200807151432.04934.julien.IETF@laposte.net> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:080715:julien.ietf@laposte.net::/GCaUhFOFdXONczp:0000000000000000000000000000000000000019MU X-Hashcash: 1:20:080715:dvijay@gmail.com::i1aiUNcFhwN8CX9e:01l7r X-Hashcash: 1:20:080715:mext@ietf.org::FeCUH7i8rOqLMDal:00009Ge2 X-Hashcash: 1:20:080715:ipsec@ietf.org::WVHYbvprPbebjd/z:000A4Kj Date: Tue, 15 Jul 2008 17:12:22 +0200 In-Reply-To: <200807151432.04934.julien.IETF@laposte.net> (Julien Laganier's message of "Tue, 15 Jul 2008 14:32:04 +0200") Message-ID: <87d4lfrxk9.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: ipsec@ietf.org, mext@ietf.org Subject: Re: [MEXT] MIP6 and IKEv2 interaction 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="===============0547790603==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0547790603== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Transfer-Encoding: quoted-printable Hi Julien, Julien Laganier writes: > Speaking as MEXT co-chair, below are inlined two clarifications: Ack. > - it wasn't possible to add every item with some support to the MEXT=20 > charter, prioritization was thus needed, and from that point of view=20 > there wasn't enough support for this compared to other items proposed=20 > at the time. With two proposed drafts and from the replies I have seen, I had a different feeling but I imagine you made a precise count. That's fine for me. > - it was also noted that if interactions between MIPv6 and IKEv2 are to=20 > be based on PFKEY, although these could presumably fall into the MEXT=20 > scope there's some upstream work to be done prior to that in the IPsec=20 > WG to revise PFKEY to IKEv2 and the revised IPsec architecture (RFC=20 > 4301). Hum, I don't see how/why the mechanism described in MIGRATE draft would benefit in waiting for an update of PF_KEY. On the opposite direction, if the glue between MIPv6 and IPsec/IKE provided by a PF_KEY-based interface is available as an informational document *when/if* there is an update of the standard, it would possibly be considered to be merged with this update. In the end, I don't buy this argument. >> ok, thank you for your comments. IIRC, I never asked for inclusion of >> implementation specific parts in Standards Track document. I just >> pointed that: >> >> - some mechanisms will not work out of the box because the glue is >> missing with other [normalized] parts of the picture >> - this is not explicitly stated in the documents that define the >> features. I find that misleading. >> >> If chairs tell me this is ok that way, I will stop bothering people >> with the two previous points. > > As of now we are not chartered to work on this topic, thus I consider we= =20 > don't need to discuss that more, at least for now. Ack. At your request, I will try and stop arguing against the trend in some recent mechanisms which now make no difference between IPsec/IKE and MIPv6 entities (implicitly leaving interfaces between the two as implementation issues). I will wait for you to bug me on that. Thanks for your time, Cheers, a+ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIfL5cAlWVfAR6UCYRAt40AJ9WObraZUszwXPXPlr4mDtJyK+RZwCglWDf W89Fp7RsTFOXpY+m7ZaswpA= =/zrW -----END PGP SIGNATURE----- --=-=-=-- --===============0547790603== 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 --===============0547790603==-- From mext-bounces@ietf.org Tue Jul 15 08:52:18 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 715F83A6881; Tue, 15 Jul 2008 08:52:18 -0700 (PDT) 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 27ACC3A6982 for ; Tue, 15 Jul 2008 08:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMiNyCLCmBOM for ; Tue, 15 Jul 2008 08:52:16 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 4812D3A686A for ; Tue, 15 Jul 2008 08:52:16 -0700 (PDT) Received: from 24.130.62.120 ([24.130.62.120]) by mse15be2.mse15.exchange.ms ([172.30.10.130]) via Exchange Front-End Server owa.mse15.exchange.ms ([172.30.10.124]) with Microsoft Exchange Server HTTP-DAV ; Tue, 15 Jul 2008 15:52:43 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Tue, 15 Jul 2008 08:52:42 -0700 From: Vijay Devarapalli To: Julien Laganier , Message-ID: Thread-Topic: [MEXT] Authentication option support in Binding Revocation draft Thread-Index: AcjmktCiiylBc986CkeJfTIf27nHgw== In-Reply-To: <200807151059.39750.julien.IETF@laposte.net> Mime-version: 1.0 Subject: Re: [MEXT] Authentication option support in Binding Revocation 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 Julien, On 7/15/08 1:59 AM, "Julien Laganier" wrote: >>> That is our reading of the charter. We may ask for guidance >>> from INT and SEC ADs if people think that we are reading it wrong, >>> no problem with that. >> >> I think we should ask them then. > > I'm unsure what to ask... > > Do you want us to confirm with our AD that our charter saying "The group > employs IPsec and IKE as a security mechanism" implies that 4285 is > out-of-scope of our charter? I was always under the impression that 4285bis will be taken up by the MEXT WG after the MIP6 WG shut down. 4285bis is a bug fix and it should be standardized ASAP. Frankly, I did not equate the sentence in the charter that says "The group employs IPsec and IKE as a security mechanism." with 4285bis being out of scope during the re-chartering process. I wish I had paid more attention to this back then. I do want to check with Jari to see if thought 4285bis was out of scope too. >From what I remember, he wanted the bug fix done too. I suggest we modify the charter to explicitly add a sentence on maintaining 4285-based mechanisms. We should also explicitly say "maintenance" so that we don't add new features like bootstrapping for RFC 4285, for which there was no consensus. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 15 08:58:46 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D30923A689F; Tue, 15 Jul 2008 08:58:46 -0700 (PDT) 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 556733A686A for ; Tue, 15 Jul 2008 08:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDIMRkIpykyJ for ; Tue, 15 Jul 2008 08:58:45 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 443523A69D2 for ; Tue, 15 Jul 2008 08:58:45 -0700 (PDT) Received: from 24.130.62.120 ([24.130.62.120]) by mse15be2.mse15.exchange.ms ([172.30.10.130]) via Exchange Front-End Server owa.mse15.exchange.ms ([172.30.10.124]) with Microsoft Exchange Server HTTP-DAV ; Tue, 15 Jul 2008 15:59:12 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Tue, 15 Jul 2008 08:59:12 -0700 From: Vijay Devarapalli To: marcelo bagnulo braun , Alper Yegin Message-ID: Thread-Topic: [MEXT] Authentication option support in Binding Revocation draft Thread-Index: Acjmk7kYXbLVAw82TkSKNU061IjZqw== In-Reply-To: <487CB177.2080605@it.uc3m.es> Mime-version: 1.0 Cc: 'Julien Laganier' , mext@ietf.org Subject: Re: [MEXT] Authentication option support in Binding Revocation 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Marcelo, On 7/15/08 7:17 AM, "marcelo bagnulo braun" wrote: > - in this particular case, there is a very clear note in the charter, > which clearly seems to me that we were provided some strict guidance > w.r.t. to this particular issue, so that is why we are being more > careful (and more rigid, if you wish) that what we would normally be > with other matters. I don't think this is so clear. If the charter had said "4285-based mechanisms are out-of scope", then yes. We never discussed whether 4285 should be out-of scope during the re-chartering process. FWIW, I had always assumed 4285-bis would be taken up by the MEXT WG. = > Hopefully we will clarify this soon and we can have a clear way on how > to move forward. As I said in another email, my suggestion would be to explicitly add maintenance of 4285 to the charter. Vijay > = > Regards, marcelo > = > = > Alper Yegin escribi=F3: >> Marcelo, >> = >> I certainly respect the WG and the chairs if they want to strictly follow >> the charter. Even though several WGs in IETF utilize some leg room in go= ing >> beyond the charter in a healthy and constructive way, I cannot expect ev= ery >> WG do the same as we cannot define a fine rule around this flexibility. = For >> that I'd not even encourage we do that. >> = >> But I'd suggest the work and discussions be accommodated to reflect the >> industry situation (use of RFC 4285), and >> = >> Initiate discussion for a micro-surgery on the charter. Bundling this ch= ange >> with any other would be a sure recipe for unnecessary delay. >> = >> Alper >> = >> = >>> -----Original Message----- >>> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >>> Sent: Tuesday, July 15, 2008 2:54 PM >>> To: Alper Yegin >>> Cc: 'Julien Laganier'; mext@ietf.org >>> Subject: Re: [MEXT] Authentication option support in Binding Revocation >>> draft >>> = >>> Alper Yegin escribi=F3: >>> = >>>> Julien, >>>> = >>>> I acknowledge that I should have reacted to the charter text when it >>>> = >>> came >>> = >>>> up. >>>> Unless someone has a solid reason why IETF should ignore its own work >>>> = >>> and >>> = >>>> furthermore other SDOs' adoption of its own work, I cannot see a reason >>>> against working towards allowing use of RFC 4285 (and rechartering in >>>> parallel if people want to have a strictly followed charter). >>>> = >>>> = >>>> = >>> that is what it is not ok >>> = >>> we are following the charter >>> if we want to work on something, we open the recharter discussion and we >>> get WG consensu that we want to change the charter (and that among the >>> many different changes we want to make to the charter, a particular >>> subset is the most relevant) >>> = >>> and then we start the work >>> = >>> Regards, marcelo >>> = >>> = >>> = >>>> Alper >>>> = >>>> = >>>> = >>>>> -----Original Message----- >>>>> From: julien laganier [mailto:julien.laganier@gmail.com] On Behalf Of >>>>> Julien Laganier >>>>> Sent: Tuesday, July 15, 2008 12:05 PM >>>>> To: mext@ietf.org >>>>> Cc: Alper Yegin >>>>> Subject: Re: [MEXT] Authentication option support in Binding Revocati= on >>>>> draft >>>>> = >>>>> Alper, >>>>> = >>>>> This WG has a charter and should follow it. MEXT is currently NOT >>>>> chartered to use other security mechanisms than IPsec/IKE, thus an >>>>> RFC4285 based security mechanism for MGSM is out-of-scope. >>>>> = >>>>> If there's a real need to develop an RFC4285 based security mechanism >>>>> for MGSM, I encourage the interested parties to first document one in >>>>> an Internet Draft, and then get the draft AD sponsored, or a >>>>> corresponding work item added to the MEXT charter. >>>>> = >>>>> --julien >>>>> = >>>>> On Monday 14 July 2008, Alper Yegin wrote: >>>>> = >>>>> = >>>>>> Folks, we should stop ignoring RFC 4285, as it is already being used >>>>>> in wireless architectures. Its informational RFC status, or some >>>>>> people's dislike, or missing an acknowledgement in the charter do not >>>>>> make this protocol non-existent. Unless IETF wants to wipe it off, >>>>>> IETF needs to accommodate it. >>>>>> = >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>> = >>>>>> = >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> = >>>> = >>>> = >> = >> = >> = >> = > = > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 15 09:04:21 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 901843A691C; Tue, 15 Jul 2008 09:04:21 -0700 (PDT) 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 09F133A691C for ; Tue, 15 Jul 2008 09:04:20 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKPpN6GP3ahc for ; Tue, 15 Jul 2008 09:04:19 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id D11203A6881 for ; Tue, 15 Jul 2008 09:04:18 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6FG4GK9004002; Tue, 15 Jul 2008 19:04:44 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Jul 2008 19:04:30 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Jul 2008 11:04:28 -0500 Received: from 10.241.59.19 ([10.241.59.19]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Tue, 15 Jul 2008 16:04:28 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Tue, 15 Jul 2008 11:04:28 -0500 From: Basavaraj Patil To: ext Vijay Devarapalli , Julien Laganier , Message-ID: Thread-Topic: [MEXT] Authentication option support in Binding Revocation draft Thread-Index: AcjmktCiiylBc986CkeJfTIf27nHgwAAaTN2 In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 15 Jul 2008 16:04:28.0788 (UTC) FILETIME=[75EA0B40:01C8E694] X-Nokia-AV: Clean Subject: Re: [MEXT] Authentication option support in Binding Revocation 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 Vijay, I agree that 4285bis should be published since it is a bug fix. Additionally, I do think that the WG should request the IESG to publish it as a proposed standard and not an Informational only RFC. 4285bis will be progressed either as a remnant of the MIP6 WG or potentially by the MEXT WG. Jari will need to elaborate on the plan. -Raj On 7/15/08 10:52 AM, "ext Vijay Devarapalli" wrote: > Hi Julien, > > On 7/15/08 1:59 AM, "Julien Laganier" wrote: > >>>> That is our reading of the charter. We may ask for guidance >>>> from INT and SEC ADs if people think that we are reading it wrong, >>>> no problem with that. >>> >>> I think we should ask them then. >> >> I'm unsure what to ask... >> >> Do you want us to confirm with our AD that our charter saying "The group >> employs IPsec and IKE as a security mechanism" implies that 4285 is >> out-of-scope of our charter? > > I was always under the impression that 4285bis will be taken up by the MEXT > WG after the MIP6 WG shut down. 4285bis is a bug fix and it should be > standardized ASAP. Frankly, I did not equate the sentence in the charter > that says "The group employs IPsec and IKE as a security mechanism." with > 4285bis being out of scope during the re-chartering process. I wish I had > paid more attention to this back then. > > I do want to check with Jari to see if thought 4285bis was out of scope too. > From what I remember, he wanted the bug fix done too. > > I suggest we modify the charter to explicitly add a sentence on maintaining > 4285-based mechanisms. We should also explicitly say "maintenance" so that > we don't add new features like bootstrapping for RFC 4285, for which there > was no consensus. > > Vijay > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 15 13:14:43 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A0A83A6931; Tue, 15 Jul 2008 13:14:43 -0700 (PDT) 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 BDE633A6B21 for ; Tue, 15 Jul 2008 13:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 SIA9gXPSMaJL for ; Tue, 15 Jul 2008 13:14:40 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id BD67F3A67D8 for ; Tue, 15 Jul 2008 13:14:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=os0GDWkz1dtIallrjbtZ+HWmv8TxrUJFQlBc1A9EfmhfocyyGfmI0X+W9ve9R4u7; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [75.26.137.116] (helo=[10.166.255.89]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1KIqvR-0003KO-Ss; Tue, 15 Jul 2008 16:15:06 -0400 Message-ID: <487D0547.3090409@earthlink.net> Date: Tue, 15 Jul 2008 13:15:03 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: marcelo bagnulo braun References: <00 b c 01c8e39e$b644f6d0$5c0c7c0a@china.huawei.com><200807141856.36985.julien. IE TF@laposte.net> <487BA2CF.9090908@it.uc3m.es> <487BA72A.5070902@it.uc3m.es> In-Reply-To: <487BA72A.5070902@it.uc3m.es> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52f0001e1726c085a4b8985b0cc494a057350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Cc: mext@ietf.org Subject: Re: [MEXT] Authentication option support in Binding Revocation 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Marcelo, marcelo bagnulo braun wrote: >> amarcelo bagnulo braun wrote: >> >> >>> we have very clear guidance on this >>> >>> see the MEXT charter: >>> >>> The group employs IPsec and IKE as a security mechanism. The group >>> shall refrain, however, from making generic extensions to these >>> protocols. Any proposed extension must be reviewed by the INT and SEC >>> ADs before it can be accepted as a part of a work item. >>> >> >> The last sentence says any extensions to IKEv2 and IPsec should be >> reviewed by the INT and SEC ADs before being adopted as WG items. That much makes sense to me. >> >> >>> any work in using other security mechanisms need to be >>> approved by SEC >>> and INT Ads I also do not think the charter was intended to say that. Or, perhaps worse, if it really was intended to say that, it somehow escaped the notice of a lot of people, somewhat like congressional earmarks are done. > > The very first sentence reads: > > The group employs IPsec and IKE as a security mechanism. > > To me that means that whatever mechanism we define must work with > IPSec IKE security and that it is out of the scope to do work on > security based on other mechanism. I think it is very possible to read the sentence in a way that is not at all so exclusionary. > > This means to me, that if we define an extension, we need to secure it > using IPSec/IKE and that security based on other approaches is out of > the scope and needs to be explicitly reviewed by INT and SEC ADs. > > > That is our reading of the charter. We may ask for guidance from INT > and SEC ADs if people think that we are reading it wrong, no problem > with that. Well, the proper people to ask are the people in the working group, who thought they knew what they were agreeing to but now seem to be surprised. As a side note, I think that the history of mip6 was to some extent a long battle against restrictions imposed by implementations of IPsec, as well as poor granularity for selectors for security associations. This is really bad for me since I was the first person to originally campaign to use IPsec for MIPv6 even though it was not standardized yet at that time. I now regret that. I still remember the insistence that IPsec-protected packets with mobility headers could not have payload. Even if IPsec were improved, I doubt anyone has the energy to reopen the discussion. It was very long and bruising, like many, many other discussions with IPsec. IPsec was not architected with the goal in mind to support mobile IP in any form, it seems to me. As a point of comparison, up until now I do not think that anyone has exposed security problems with the MN-HA authentication extension for MIPv4, except insofar as it originally specified MD5. It is simple, easy to understand and implement, and effective. Why not make use of the lessons we have learned from that? Bottom line for me: use IPsec when it offers advantages, use what else we know works when IPsec gets in the way. Regards, Charlie P. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 15 13:17:02 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCAC23A6AC2; Tue, 15 Jul 2008 13:17:02 -0700 (PDT) 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 DFFC53A67F5 for ; Tue, 15 Jul 2008 13:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsjiRvxuzu2p for ; Tue, 15 Jul 2008 13:17:01 -0700 (PDT) Received: from web84305.mail.re1.yahoo.com (web84305.mail.re1.yahoo.com [69.147.74.184]) by core3.amsl.com (Postfix) with SMTP id E55293A6AC2 for ; Tue, 15 Jul 2008 13:17:00 -0700 (PDT) Received: (qmail 87905 invoked by uid 60001); 15 Jul 2008 20:17:28 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=B8sbU9nuGKipK+5TTMUb7qh/FlsV9rBrfDgrceJ1RPLBW3F5WLsSNqahPRcKvFuR/vv5nBNPz7j7KFaNb89d6lLj4jwjNLm81X7EMdf/1E431RiEDx7w9fpcgYnE3UErsXRrwlojBU5etT+2BMaGvSThsuZAAnT2bec++Du77Hs=; Received: from [72.164.184.70] by web84305.mail.re1.yahoo.com via HTTP; Tue, 15 Jul 2008 13:17:28 PDT X-Mailer: YahooMailRC/975.45 YahooMailWebService/0.7.199 Date: Tue, 15 Jul 2008 13:17:28 -0700 (PDT) From: Behcet Sarikaya To: Vijay Devarapalli , Julien Laganier , mext@ietf.org MIME-Version: 1.0 Message-ID: <864800.87829.qm@web84305.mail.re1.yahoo.com> Subject: Re: [MEXT] Authentication option support in Binding Revocation draft 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="===============2087628062==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============2087628062== Content-Type: multipart/alternative; boundary="0-132556403-1216153048=:87829" --0-132556403-1216153048=:87829 Content-Type: text/plain; charset=us-ascii ----- Original Message ---- From: Vijay Devarapalli To: Julien Laganier ; mext@ietf.org Sent: Tuesday, July 15, 2008 10:52:42 AM Subject: Re: [MEXT] Authentication option support in Binding Revocation draft ... I suggest we modify the charter to explicitly add a sentence on maintaining 4285-based mechanisms. We should also explicitly say "maintenance" so that we don't add new features like bootstrapping for RFC 4285, for which there was no consensus. [behcet] Can I add another item to charter modification? Develop another solution nemo pd problem. The current charter's strict interpretation seems to allow only one. Anybody seconding this proposal please speak up! Regards, Behcet --0-132556403-1216153048=:87829 Content-Type: text/html; charset=us-ascii


----- Original Message ----
From: Vijay Devarapalli <vijay@wichorus.com>
To: Julien Laganier <julien.IETF@laposte.net>; mext@ietf.org
Sent: Tuesday, July 15, 2008 10:52:42 AM
Subject: Re: [MEXT] Authentication option support in Binding Revocation draft

...


I suggest we modify the charter to explicitly add a sentence on maintaining
4285-based mechanisms. We should also explicitly say "maintenance" so that
we don't add new features like bootstrapping for RFC 4285, for which there
was no consensus.

[behcet] Can I add another item to charter modification?
Develop another solution nemo pd problem.
The current charter's strict interpretation seems to allow only one.
Anybody seconding this proposal please speak up!

Regards,

Behcet

--0-132556403-1216153048=:87829-- --===============2087628062== 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 --===============2087628062==-- From mext-bounces@ietf.org Tue Jul 15 14:00:45 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B74183A680D; Tue, 15 Jul 2008 14:00:45 -0700 (PDT) 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 D61A03A67DD for ; Tue, 15 Jul 2008 14:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKa4m1Ijl3E4 for ; Tue, 15 Jul 2008 14:00:42 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id AECFE3A6AC2 for ; Tue, 15 Jul 2008 14:00:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1216155671; x=1247691671; h=x-mimeole:content-class:mime-version:content-type: content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator: thread-topic:thread-index:references:from:to:cc: x-originalarrivaltime:x-ironport-av; z=X-MimeOLE:=20Produced=20By=20Microsoft=20Exchange=20V6.5 |Content-class:=20urn:content-classes:message |MIME-Version:=201.0|Content-Type:=20text/plain=3B=0D=0A =09charset=3D"us-ascii"|Content-Transfer-Encoding:=20quot ed-printable|Subject:=20RE:=20[MEXT]=20Authentication=20o ption=20support=20in=20Binding=20Revocation=20draft|Date: =20Tue,=2015=20Jul=202008=2014:00:54=20-0700|Message-ID: =20|In-Reply-To:=20<487D0547.3090409@earthlink.ne t>|X-MS-Has-Attach:=20|X-MS-TNEF-Correlator:=20 |Thread-Topic:=20[MEXT]=20Authentication=20option=20suppo rt=20in=20Binding=20Revocation=20draft|Thread-Index:=20Ac jmt4wn604N92c1Reew0dIQ3stYkwABVdPw|References:=20<00=09b=09c=0901c8e39e$b644f6d0$5c0c7c0a@ china.huawei.com><200807141856.36985.julien.=09IE=09TF@la poste.net><487BA2CF.9090908@it.uc3m.es><487BA72A.5070902@it.uc3m.es>=20<487D0547.3090409@e arthlink.net>|From:=20"Giaretta,=20Gerardo"=20|To:=20"Charles=20E.=20Perkins"=20,=0D=0A=20=20=20=20=20=20=20=20"marce lo=20bagnulo=20braun"=20|Cc:=20|X-OriginalArrivalTime:=2015=20Jul=202008=2021:0 0:53.0558=20(UTC)=20FILETIME=3D[DE769560:01C8E6BD] |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5200,2160,5339"=3B=20 a=3D"4566699"; bh=AcYrB69FcdI0iQ9zr6XUkT3oNGuifVluwAKMmpvSPdw=; b=xPBPv7gUj2torYr8e2GmtPr+Ui1XQs9CkMlpG6+FrofQSqa0s3APgZao /8nMIidko45qNtADJHmN0+AUYJ5qzWHxY5CaX1CSvxHIoC4bxtg4i2IqT GHrk8kjFgnHki+K/yKHdujyoFDQ9QiNd0gvLZr3UBhXJ7I0Ft7lGNosaJ k=; X-IronPort-AV: E=McAfee;i="5200,2160,5339"; a="4566699" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Jul 2008 14:00:55 -0700 Received: from msgtransport06.qualcomm.com (msgtransport06.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m6FL0tah012156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 Jul 2008 14:00:55 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by msgtransport06.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m6FL0rLS008997; Tue, 15 Jul 2008 14:00:55 -0700 Received: from NAEX12.na.qualcomm.com ([129.46.51.246]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Jul 2008 14:00:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 15 Jul 2008 14:00:54 -0700 Message-ID: In-Reply-To: <487D0547.3090409@earthlink.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Authentication option support in Binding Revocation draft Thread-Index: Acjmt4wn604N92c1Reew0dIQ3stYkwABVdPw References: <00 b c 01c8e39e$b644f6d0$5c0c7c0a@china.huawei.com><200807141856.36985.julien. IE TF@laposte.net><487BA2CF.9090908@it.uc3m.es><487BA72A.5070902@it.uc3m.es> <487D0547.3090409@earthlink.net> From: "Giaretta, Gerardo" To: "Charles E. Perkins" , "marcelo bagnulo braun" X-OriginalArrivalTime: 15 Jul 2008 21:00:53.0558 (UTC) FILETIME=[DE769560:01C8E6BD] Cc: mext@ietf.org Subject: Re: [MEXT] Authentication option support in Binding Revocation 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 all, I agree with the WG chairs here. The charter is clear and the fact that there are no milestones related to rfc4285, besides the RFC on the motivations why that was defined, should be a clear indication of what the WG is chartered for. In my view, MEXT should work only on IPsec/IKEv2 based solution. This is so far the only solution which is standard in IETF and we should not try to revisit this every three months. And the fact that 3GPP and 3GPP2 have now adopted RFC4877 as the security mechanism shows that the motivations why rfc4285 was defined are no longer valid. Concerning the specific issue, I think the Binding Revocation draft should cover only the IPsec based solution. This is particularly important due to the strict timeline from 3GPP (and this draft is in the official 3GPP-IETF dependency list). If people are interested in a 4285-based solution, they are free to write a new draft and ask for a rechartering discussion to include it in the milestone. Gerardo > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Charles E. Perkins > Sent: Tuesday, July 15, 2008 1:15 PM > To: marcelo bagnulo braun > Cc: mext@ietf.org > Subject: Re: [MEXT] Authentication option support in Binding Revocation > draft > > > Hello Marcelo, > > marcelo bagnulo braun wrote: > >> amarcelo bagnulo braun wrote: > >> > >> > >>> we have very clear guidance on this > >>> > >>> see the MEXT charter: > >>> > >>> The group employs IPsec and IKE as a security mechanism. The group > >>> shall refrain, however, from making generic extensions to these > >>> protocols. Any proposed extension must be reviewed by the INT and SEC > >>> ADs before it can be accepted as a part of a work item. > >>> > >> > >> The last sentence says any extensions to IKEv2 and IPsec should be > >> reviewed by the INT and SEC ADs before being adopted as WG items. > > That much makes sense to me. > > > >> > >> > >>> any work in using other security mechanisms need to be > >>> approved by SEC > >>> and INT Ads > > I also do not think the charter was intended to say that. Or, perhaps > worse, if it really was intended to say that, it somehow escaped the > notice of a lot of people, somewhat like congressional earmarks are > done. > > > > > The very first sentence reads: > > > > The group employs IPsec and IKE as a security mechanism. > > > > To me that means that whatever mechanism we define must work with > > IPSec IKE security and that it is out of the scope to do work on > > security based on other mechanism. > > I think it is very possible to read the sentence in a way that > is not at all so exclusionary. > > > > This means to me, that if we define an extension, we need to secure it > > using IPSec/IKE and that security based on other approaches is out of > > the scope and needs to be explicitly reviewed by INT and SEC ADs. > > > > > > That is our reading of the charter. We may ask for guidance from INT > > and SEC ADs if people think that we are reading it wrong, no problem > > with that. > > Well, the proper people to ask are the people in the > working group, who thought they knew what they > were agreeing to but now seem to be surprised. > > As a side note, I think that the history of mip6 was to > some extent a long battle against restrictions imposed by > implementations of IPsec, as well as poor granularity for > selectors for security associations. This is really bad for > me since I was the first person to originally campaign to > use IPsec for MIPv6 even though it was not standardized > yet at that time. I now regret that. I still remember > the insistence that IPsec-protected packets with mobility > headers could not have payload. Even if IPsec were > improved, I doubt anyone has the energy to reopen > the discussion. It was very long and bruising, like > many, many other discussions with IPsec. IPsec > was not architected with the goal in mind to support > mobile IP in any form, it seems to me. > > As a point of comparison, up until now I do not think that > anyone has exposed security problems with the MN-HA > authentication extension for MIPv4, except insofar as it > originally specified MD5. It is simple, easy to understand > and implement, and effective. Why not make use of the > lessons we have learned from that? > > Bottom line for me: use IPsec when it offers advantages, > use what else we know works when IPsec gets in the way. > > Regards, > Charlie P. > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 15 14:19:08 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B3F23A6B21; Tue, 15 Jul 2008 14:19:08 -0700 (PDT) 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 6C8153A6B41 for ; Tue, 15 Jul 2008 14:19:06 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n93hMdRVEXSg for ; Tue, 15 Jul 2008 14:19:05 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 0678F3A6AD9 for ; Tue, 15 Jul 2008 14:19:04 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6FLJC6l012053; Wed, 16 Jul 2008 00:19:24 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Jul 2008 00:19:12 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Jul 2008 16:19:06 -0500 Received: from 10.241.59.218 ([10.241.59.218]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Tue, 15 Jul 2008 21:19:05 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Tue, 15 Jul 2008 16:19:05 -0500 From: Basavaraj Patil To: Giaretta Gerardo , Charles Perkins , Marcelo Bagnulo Message-ID: Thread-Topic: [MEXT] Authentication option support in Binding Revocation draft Thread-Index: Acjmt4wn604N92c1Reew0dIQ3stYkwABVdPwAADhZHA= In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 15 Jul 2008 21:19:06.0120 (UTC) FILETIME=[69AE5080:01C8E6C0] X-Nokia-AV: Clean Cc: ext Avi Lior , mext@ietf.org Subject: Re: [MEXT] Authentication option support in Binding Revocation 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 Gerardo, When I last checked with the 3GPP2 TSG-X chair (Avi Lior) about the use of Authentication protocol (RFC4285) with MIP6, I was told that 3GPP2 relies on RFC4285 as the basis for MIP6 signaling security. Maybe things have changed since March, 08. Additionally RFC4285 is also the default security method for MIP6 in WiMAX Rel 1 as well. Hence I believe that RFC4285 is a valid security solution for MIP6 deployments and cannot be simply ignored by the MEXT WG. I do tend to agree with Charlies sentiment that IPsec/IKEv2 in certain scenarios is an overkill for MIP6 security. Experience shows that large scale deployment of MIP4 using authentication akin to RFC4285 has worked well. So I don't see why MEXT should close the doors to anything but IPsec/IKEv2. The relevance of MIP6 itself (IMO) diminishes with this overarching dependence on IPsec/IKEv2 as the only security mechanism. -Raj On 7/15/08 4:00 PM, "Giaretta Gerardo" wrote: > Hi all, > > I agree with the WG chairs here. The charter is clear and the fact that > there are no milestones related to rfc4285, besides the RFC on the > motivations why that was defined, should be a clear indication of what > the WG is chartered for. > > In my view, MEXT should work only on IPsec/IKEv2 based solution. This is > so far the only solution which is standard in IETF and we should not try > to revisit this every three months. And the fact that 3GPP and 3GPP2 > have now adopted RFC4877 as the security mechanism shows that the > motivations why rfc4285 was defined are no longer valid. > > Concerning the specific issue, I think the Binding Revocation draft > should cover only the IPsec based solution. This is particularly > important due to the strict timeline from 3GPP (and this draft is in the > official 3GPP-IETF dependency list). > If people are interested in a 4285-based solution, they are free to > write a new draft and ask for a rechartering discussion to include it in > the milestone. > > Gerardo > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf > Of >> Charles E. Perkins >> Sent: Tuesday, July 15, 2008 1:15 PM >> To: marcelo bagnulo braun >> Cc: mext@ietf.org >> Subject: Re: [MEXT] Authentication option support in Binding > Revocation >> draft >> >> >> Hello Marcelo, >> >> marcelo bagnulo braun wrote: >>>> amarcelo bagnulo braun wrote: >>>> >>>> >>>>> we have very clear guidance on this >>>>> >>>>> see the MEXT charter: >>>>> >>>>> The group employs IPsec and IKE as a security mechanism. The group >>>>> shall refrain, however, from making generic extensions to these >>>>> protocols. Any proposed extension must be reviewed by the INT and > SEC >>>>> ADs before it can be accepted as a part of a work item. >>>>> >>>> >>>> The last sentence says any extensions to IKEv2 and IPsec should be >>>> reviewed by the INT and SEC ADs before being adopted as WG items. >> >> That much makes sense to me. >> >> >>>> >>>> >>>>> any work in using other security mechanisms need to be >>>>> approved by SEC >>>>> and INT Ads >> >> I also do not think the charter was intended to say that. Or, perhaps >> worse, if it really was intended to say that, it somehow escaped the >> notice of a lot of people, somewhat like congressional earmarks are >> done. >> >>> >>> The very first sentence reads: >>> >>> The group employs IPsec and IKE as a security mechanism. >>> >>> To me that means that whatever mechanism we define must work with >>> IPSec IKE security and that it is out of the scope to do work on >>> security based on other mechanism. >> >> I think it is very possible to read the sentence in a way that >> is not at all so exclusionary. >>> >>> This means to me, that if we define an extension, we need to secure > it >>> using IPSec/IKE and that security based on other approaches is out > of >>> the scope and needs to be explicitly reviewed by INT and SEC ADs. >>> >>> >>> That is our reading of the charter. We may ask for guidance from INT >>> and SEC ADs if people think that we are reading it wrong, no problem >>> with that. >> >> Well, the proper people to ask are the people in the >> working group, who thought they knew what they >> were agreeing to but now seem to be surprised. >> >> As a side note, I think that the history of mip6 was to >> some extent a long battle against restrictions imposed by >> implementations of IPsec, as well as poor granularity for >> selectors for security associations. This is really bad for >> me since I was the first person to originally campaign to >> use IPsec for MIPv6 even though it was not standardized >> yet at that time. I now regret that. I still remember >> the insistence that IPsec-protected packets with mobility >> headers could not have payload. Even if IPsec were >> improved, I doubt anyone has the energy to reopen >> the discussion. It was very long and bruising, like >> many, many other discussions with IPsec. IPsec >> was not architected with the goal in mind to support >> mobile IP in any form, it seems to me. >> >> As a point of comparison, up until now I do not think that >> anyone has exposed security problems with the MN-HA >> authentication extension for MIPv4, except insofar as it >> originally specified MD5. It is simple, easy to understand >> and implement, and effective. Why not make use of the >> lessons we have learned from that? >> >> Bottom line for me: use IPsec when it offers advantages, >> use what else we know works when IPsec gets in the way. >> >> Regards, >> Charlie P. >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://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 Jul 16 04:51:50 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4702528C14E; Wed, 16 Jul 2008 04:51:50 -0700 (PDT) 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 10D753A6A81 for ; Wed, 16 Jul 2008 04:51:49 -0700 (PDT) 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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7rAQfZX0mgx for ; Wed, 16 Jul 2008 04:51:42 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E010B3A6868 for ; Wed, 16 Jul 2008 04:51:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,373,1212364800"; d="scan'208,217";a="14509946" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 16 Jul 2008 11:52:07 +0000 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 m6GBq757001003; Wed, 16 Jul 2008 13:52:07 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6GBq706023520; Wed, 16 Jul 2008 11:52:07 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, 16 Jul 2008 13:52:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Jul 2008 13:51:26 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05F76EE9@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [MEXT] [mext] #11: De-registration when returning home[VijayDevarapalli ] Thread-Index: Acjh8V+MjNkSZIeVRpqs1hq3iTkwfwBgC3SQAAMZZiAAAGeZAgDuH1LA References: <010801c8e16b$5c2889d0$7471510a@psl.local> <7892795E1A87F04CADFCCF41FADD00FC05F1D85F@xmb-ams-337.emea.cisco.com> From: "Pascal Thubert (pthubert)" To: "Sri Gundavelli (sgundave)" , "Vijay Devarapalli" , "Koodli, Rajeev" X-OriginalArrivalTime: 16 Jul 2008 11:52:07.0124 (UTC) FILETIME=[5F313940:01C8E73A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=31344; t=1216209127; x=1217073127; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20RE=3A=20[MEXT]=20[mext]=20#11=3A=20De-r egistration=20when=20returning=20home[VijayDevarapalli=20] |Sender:=20; bh=6ZWyivD/FiwkmKR1ToQPdvtnlENb7BqmwF2IWL8eUWM=; b=q3rhGxpZGJT0dgryvaX+mb7QQEKk3hkqZCYCwIwgkd6+n4uAECG9A9sogy dRIwu2OAgXDg0Ltm2ToTgGZqiopOHJLccXXa/nJoEbPNGQk1JqUorU6uooCz waXAq7+K4d; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home[VijayDevarapalli ] 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="===============0920193284==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============0920193284== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8E73A.5EF7111B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8E73A.5EF7111B Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hello Vijay =20 I'm with Sri and Rajeev (and against Gerardo (sorry Gerardo :-) ) ) on the fact that we do not need to add text that might be misleading in what the node can or can not do at home with its home address until it is done with the deregistration BU. What does '"if the MN wants to use HoA " mean anyway? It might be somewhat unlawful and it might partially work anyway for the MN to start using the Home Addressright away. In particular, the MN could apply oDAD without hurting anyone.=20 =20 So I'd rather remove speculations and stick to normative: =20 Starting with your original text =20 A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.1), when the mobile node detects that its home subnet prefix is again on-link. To be able to send and receive packets using its home address from=20 the home link, the mobile node MUST send a Binding Update to its=20 home agent to instruct its home agent to no longer intercept or=20 tunnel packets for it. =20 I'd change this part slightly: =20 To be able to send and receive packets using its home address from=20 the home link, the mobile node MUST send a Binding Update to its=20 home agent to instruct its home agent to no longer intercept or=20 tunnel packets for it. =20 Like this: =20 The mobile node MUST send a Binding Update to its home agent to instruct=20 it to no longer intercept or tunnel packets for it. Until then the MN SHOULD NOT advertize its Home Address on the Home Link. =20 Does not mean I agree that this is the right this to do; I still think the MN should be able to force the ownership back. But I agree that this can be processed as another issue. =20 Pascal ________________________________ From: Sri Gundavelli (sgundave)=20 Sent: vendredi 11 juillet 2008 19:57 To: Vijay Devarapalli; Pascal Thubert (pthubert); Koodli, Rajeev Cc: charliep@computer.org; mext@ietf.org Subject: RE: RE: [MEXT] [mext] #11: De-registration when returning home[VijayDevarapalli ] =20 Vijay, =20 But the below text makes the assumption that the MN will not be able to reclaim the address and that has the implication on the new issue to be discussed. The root of this issue, was the change from SHOULD to MUST on requiring the MN to send a BU. Lets resolve the issue with clearly stating the requirement from MIP perspective, "if the MN wants to use HoA on the home-link, it MUST send the dereg message". The other text implying that the MN will not able to use the HoA on its home link is not required and this issue is not about that. =20 Thanks Sri =20 =20 ________________________________ From: Vijay Devarapalli [mailto:vijay@wichorus.com] Sent: Fri 7/11/2008 10:52 AM To: Pascal Thubert (pthubert); Sri Gundavelli (sgundave); Koodli, Rajeev Cc: charliep@computer.org; mext@ietf.org Subject: RE: [MEXT] [mext] #11: De-registration when returning home[VijayDevarapalli ] Sri, Pascal, Rajeev, I suggest you guys open a separate issue on whether a mobile node can claim its address without first sending a de-registration BU when it returns to the home link. RFC 3775 does not allow this. It is clearly a violation of RFC 3775. An RFC 3775-compliant mobile node is supposed to behave as described in RFC 3775 when it returns home. Not according to what RFC 4861 might allow an IPv6 host to do. For the issue we were discussing, lets go with the following text. A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.1), when the mobile node detects that its home subnet prefix is again on-link. To be able to send and receive packets using its home address from the home link, the mobile node MUST send a Binding Update to its home agent to instruct its home agent to no longer intercept or tunnel packets for it. Until the mobile node sends a de-registration Binding Update, it will not be able to send and receive packets using its home address from the home link. The home agent will continue to intercept all packets sent to the mobile's home address and tunnel to the previously registered care-of address. We need to close this issue. Based on what we decide later on whether the mobile node can claim its address without first sending a de-registration BU, we can revisit the above text. Vijay > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Pascal Thubert (pthubert) > Sent: Friday, July 11, 2008 9:40 AM > To: Sri Gundavelli (sgundave) > Cc: charliep@computer.org; mext@ietf.org > Subject: Re: [MEXT] [mext] #11: De-registration when > returning home[VijayDevarapalli ] > > Hi Sri, > > I won't reply to all your mails but I'm 100 % with you all the way > through. > > In particular, you're very right that it would just be > nonsense for a HA > to try and reclaim SeND based addresses when a MN proves ownership on > link. We need to prepare for the coming changes and adapt the spec. In > short the HA is a proxy and it should behave as such. > > RFC3775bis might live in its bubble and expect that all MN will act > proper. But there are a number of scenarios, including reboot > with loss > of state, where the MN might not. And the real attacks against the MN > home address might not come from nodes that behave proper, whether > that's voluntary or not. > > When the MN comes back home and does not have the right states to > unbind, > > - if the MN is a good citizen, it should DAD its address and the HA > should defend it. I'm asking that upon DAD, the HA do not set the > Override bit; that change to the spec would allow the MN to > differentiate a real collision from a proxy collision. I > would call that > a proxy-success for the DAD flow. > > - but to avoid trouble when coming home, I'd expect that > implementations > that do not wish to get angry customer calls in the middle of > the night > would send RA (Override) right away. I know, that's bad. But > that's damn > quick and efficent. That's how we do hot standby... > > What happens next? > > - A node should get its address back if only proxies are > defending it. > In MIP case, whether the MN can clean up the binding properly or fails > for some reason, it should NA(override) its address. At least that > should be rightful if DAD proxy-succeeds. > > - Upon NA override, a proxy should yield silently. > The HA should remove its binding. This flow would also > enables a HA that > gets a new BU to take over the binding from the old HA. > > Proxy or not proxy? That is the question... > > Pascal > > >-----Original Message----- > >From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] > On Behalf Of > Sri Gundavelli (sgundave) > >Sent: mercredi 9 juillet 2008 20:26 > >To: Giaretta, Gerardo > >Cc: charliep@computer.org; mext@ietf.org > >Subject: Re: [MEXT] [mext] #11: De-registration when returning home > [VijayDevarapalli > >] > > > > > >Just one comment. > > > > > >> Until the mobile node sends a de-registration Binding > Update, it will > >> not > >> be able to send and receive packets using its home address from the > home > >> link. > > > >I have a problem with this. As Pascal and Rajiv pointed out, nothing > >really stops the MN, which is the legitimate address owner to reclaim > >and start using its home address on the home link and without sending > >a BU with life=3D0. This has to confirm to the override flag purpose = in > >ND. > > > >Sri > > > >_______________________________________________ > >MEXT mailing list > >MEXT@ietf.org > >https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > ------_=_NextPart_001_01C8E73A.5EF7111B Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: [MEXT] [mext] #11: De-registration when returning home[VijayDevarapalli ]

Hello = Vijay

 

I’m with Sri and Rajeev (and = against Gerardo (sorry Gerardo J ) ) on the fact that we do not need to add text that might = be misleading in what the node can or can not do at home with its home = address until it is done with the deregistration BU. What does = ‘"if the MN wants to use HoA “ mean anyway?

It might be somewhat unlawful and = it might partially work anyway for the MN to start using the Home Addressright = away. In particular, the MN could apply oDAD without hurting anyone. =

 

So I’d rather remove = speculations and stick to normative:

 

Starting with your original text

 

   A = mobile node detects that it has returned to its home link = through

   the = movement detection algorithm in use (Section 11.5.1), when = the

   mobile = node detects that its home subnet prefix is again = on-link.

   To be = able to send and receive packets using its home address from =

   the = home link, the mobile node MUST send a Binding Update to its =

   home = agent to instruct its home agent to no longer intercept or =

   tunnel = packets for it.

 

I’d change this part slightly:

 

   To be = able to send and receive packets using its home address from =

   the = home link, the mobile node MUST send a Binding Update to its =

   home = agent to instruct its home agent to no longer intercept or =

   tunnel packets for = it.

 

Like this:

 

   The = mobile node MUST send a Binding Update to its home agent to instruct =

   it to = no longer intercept or tunnel packets for it. Until then the = MN

   SHOULD = NOT advertize its Home Address on the Home = Link.

 

Does not mean I agree that this is = the right this to do; I still think the MN should be able to force the = ownership back.

But I agree that this can be = processed as another issue.

 

Pascal

From: = Sri Gundavelli (sgundave)
Sent: vendredi 11 juillet = 2008 19:57
To: Vijay Devarapalli; = Pascal Thubert (pthubert); Koodli, Rajeev
Cc: charliep@computer.org; mext@ietf.org
Subject: RE: RE: [MEXT] = [mext] #11: De-registration when returning home[VijayDevarapalli = <vijay@wichorus.com>]

 

Vijay,

=

 

But the below text makes the assumption that the MN = will not be able to reclaim the address and that

has the implication on the new issue to be discussed. = The root of this issue, was the change from

SHOULD to MUST on requiring the MN to send a BU. Lets resolve the issue with clearly stating the

requirement from MIP perspective, "if the MN = wants to use HoA on the home-link, it MUST send the

dereg message". The other text implying = that the MN will not able to use the HoA on its home link = is

not required and this issue is not about = that.

 

Thanks

Sri

 

 

From: Vijay Devarapalli [mailto:vijay@wichorus.com]
Sent: Fri 7/11/2008 10:52 = AM
To: Pascal Thubert = (pthubert); Sri Gundavelli (sgundave); Koodli, = Rajeev
Cc: charliep@computer.org; mext@ietf.org
Subject: RE: [MEXT] = [mext] #11: De-registration when returning home[VijayDevarapalli <vijay@wichorus.com>]

Sri, Pascal, Rajeev,

I suggest you guys open a separate issue on whether a mobile node = can
claim its address without first sending a de-registration BU when it
returns to the home link.

RFC 3775 does not allow this. It is clearly a violation of RFC 3775. = An
RFC 3775-compliant mobile node is supposed to behave as described in = RFC
3775 when it returns home. Not according to what RFC 4861 might allow = an
IPv6 host to do.

For the issue we were discussing, lets go with the following text.

   A mobile node detects that it has returned to its home link through
   the movement detection algorithm in use (Section 11.5.1), = when the
   mobile node detects that its home subnet prefix is again = on-link.
   To be able to send and receive packets using its home = address from
   the home link, the mobile node MUST send a Binding Update = to its
   home agent to instruct its home agent to no longer = intercept or
   tunnel packets for it. Until the mobile node sends a de-registration
   Binding Update, it will not be able to send and receive = packets
   using its home address from the home link. The home agent = will
   continue to intercept all packets sent to the mobile's home address
   and tunnel to the previously registered care-of = address.

We need to close this issue.

Based on what we decide later on whether the mobile node can claim = its
address without first sending a de-registration BU, we can revisit = the
above text.

Vijay


> -----Original Message-----
> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On
> Behalf Of Pascal Thubert (pthubert)
> Sent: Friday, July 11, 2008 9:40 AM
> To: Sri Gundavelli = (sgundave)
> Cc: charliep@computer.org; mext@ietf.org
> Subject: Re: [MEXT] [mext] #11: De-registration when
> returning home[VijayDevarapalli <vijay@wichorus.com>]
>
> Hi Sri,
>
> I won't reply to all your mails but I'm 100 % with you all the = way
> through.
>
> In particular, you're very right that it would just be
> nonsense for a HA
> to try and reclaim SeND based addresses when a MN proves ownership = on
> link. We need to prepare for the coming changes and adapt the spec. = In
> short the HA is a proxy and it should behave as such.
>
> RFC3775bis might live in its bubble and expect that all MN will = act
> proper. But there are a number of scenarios, including reboot
> with loss
> of state, where the MN might not. And the real attacks against the = MN
> home address might not come from nodes that behave proper, = whether
> that's voluntary or not.
>
> When the MN comes back home and does not have the right states = to
> unbind,
>
> - if the MN is a good citizen, it should DAD its address and the = HA
> should defend it. I'm asking that upon DAD, the HA do not set = the
> Override bit; that change to the spec would allow the MN to
> differentiate a real collision from a proxy collision. I
> would call that
> a proxy-success for the DAD flow.
>
> - but to avoid trouble when coming home, I'd expect that
> implementations
> that do not wish to get angry customer calls in the middle of
> the night
> would send RA (Override) right away. I know, that's bad. But
> that's damn
> quick and efficent. That's how we do hot standby...
>
> What happens next?
>
> - A node should get its address back if only proxies are
> defending it.
> In MIP case, whether the MN can clean up the binding properly or = fails
> for some reason, it should NA(override) its address. At least = that
> should be rightful if DAD proxy-succeeds.
>
> - Upon NA override, a proxy should yield silently.
> The HA should remove its binding. This flow would also
> enables a HA that
> gets a new BU to take over the binding from the old HA.
>
> Proxy or not proxy? That is the question...
>
> Pascal
>
> >-----Original Message-----
> >From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] > On Behalf Of
> Sri Gundavelli = (sgundave)
> >Sent: mercredi 9 juillet 2008 20:26
> >To: Giaretta, Gerardo
> >Cc: charliep@computer.org; mext@ietf.org
> >Subject: Re: [MEXT] [mext] #11: De-registration when returning = home
> [VijayDevarapalli
> ><vijay@wichorus.com>]
> >
> >
> >Just one comment.
> >
> >
> >> Until the mobile node sends a de-registration Binding
> Update, it will
> >> not
> >> be able to send and receive packets using its home address = from the
> home
> >> link.
> >
> >I have a problem with this. As Pascal and Rajiv pointed out, = nothing
> >really stops the MN, which is the legitimate address owner to = reclaim
> >and start using its home address on the home link and without = sending
> >a BU with life=3D0. This has to confirm to the override flag = purpose in
> >ND.
> >
> >Sri
> >
> >_______________________________________________
> >MEXT mailing list
> >MEXT@ietf.org
> >https://www.ietf.org/= mailman/listinfo/mext
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/= mailman/listinfo/mext
>

------_=_NextPart_001_01C8E73A.5EF7111B-- --===============0920193284== 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 --===============0920193284==-- From mext-bounces@ietf.org Wed Jul 16 05:37:28 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDFAF3A6BA2; Wed, 16 Jul 2008 05:37:27 -0700 (PDT) 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 6C7313A6BA1 for ; Wed, 16 Jul 2008 05:37:27 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JY7ftpjHlEV9 for ; Wed, 16 Jul 2008 05:37:26 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D32313A6ADD for ; Wed, 16 Jul 2008 05:37:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,373,1212364800"; d="scan'208";a="14516276" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 16 Jul 2008 12:37:54 +0000 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 m6GCbrPQ014685; Wed, 16 Jul 2008 14:37:53 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6GCbrcV014816; Wed, 16 Jul 2008 12:37:53 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, 16 Jul 2008 14:37:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Jul 2008 14:37:12 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05F76F22@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Issue on HA behaviour upon MN returning Home [De-registration when returning home] Thread-Index: Acjh8V+MjNkSZIeVRpqs1hq3iTkwfwBgC3SQAAMZZiAAAGeZAgAAS1OAAO6CaxA= References: <010801c8e16b$5c2889d0$7471510a@psl.local> <7892795E1A87F04CADFCCF41FADD00FC05F1D85F@xmb-ams-337.emea.cisco.com> From: "Pascal Thubert (pthubert)" To: , "Vijay Devarapalli" X-OriginalArrivalTime: 16 Jul 2008 12:37:53.0292 (UTC) FILETIME=[C40934C0:01C8E740] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3248; t=1216211873; x=1217075873; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20New=20Issue=20on=20HA=20behaviour=20upon=20MN=2 0returning=20Home=20[De-registration=20when=20returning=20ho me] |Sender:=20; bh=FBeXVhDjQYSVac13S2Fc3GEt+Jgmv86zmhHRU3i1cKY=; b=lE1sBFE/HLbXiwBl4Gml/RFga7XfolCewqC4XdUcUvemqgJ26+X4xXNLj2 Kh3+GtRCeSEToXem3WRW85WjGBbjZWD0oiL4FAuf1298OcxZoMx16/zBlJ4W 2gRHDmFLNG; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: mext@ietf.org Subject: [MEXT] New Issue on HA behaviour upon MN returning Home [De-registration when returning home] 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 Charlie and Vijay: Following Vijay's advice, I'd wish to open a new issue on the behaviour of the HA on the Home Link. Issue ----- With both the original RFC 3775 and the current rework, a HA that has a binding to a Home Address owns that Home Adddress over the Home Link till either the node unbinds or the binding times out. Until then the HA will defend that Home Address using the Override bit in the NA messages over the Home Link, and until then it is unlawful for the node to use its Home Address if it is at Home or switch to another HA if it is not at Home. There are multiple issues with this behaviour: - service: Whether it is at Home or not, a node that looses the states about its current binding might be unreachable until the end of its binding lifetime. It will take a manual operation to recover from that situation when the lifetime is too long. And it will cause excess traffic or load on the HAs if the lifetime is too short. In any case there will be a service disruption that the user might perceive. - security: The HA defends an address that it does not own so it can not prove it owns it. With SeND, it would just be nonsense for a HA to try and reclaim SeND based addresses when a MN proves ownership on link. - compatibility with other proxies: The HA performs a form of ND proxying for the Mobile Node. We can expect that there will be new forms of ND proxies coming up - see for instance http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router-01 -, and there should be a common behaviour over a shared link for proxies, regardless of the registration mechanism; in particular a proxy should yield in the face of the object it proxies for. - speed: A Mobile Node reaching Home should be able to use its Home Address as optimistic (RFC 4429) right away like it could do on any visited link with any CoA. Proposed resolution ------------------- The proposal to fix this issue is to let the MN use DAD/oDAD over the Home Link with its Home Address. A proxy would defend the address without the O bit, and the MN would ignore it, and upon DAD completion, NA(Override) its address. The HA would be allowed to set the override bit only within a binding flow, when it knows synchronously that it represents the live MN. That would enable new HA to take over old HA when the MN looses states away from home. That would also enable MN to make before break a tunnel with new HA. Still it would still be beneficial to clear the binding properly so we can still SHOULD or MUST it, but whether that flow works properly or not, the MN would get its address back. What do you think? Pascal >> >> From: Vijay Devarapalli [mailto:vijay@wichorus.com] >> Sent: Fri 7/11/2008 10:52 AM >> To: Pascal Thubert (pthubert); Sri Gundavelli (sgundave); >> Koodli, Rajeev >> Cc: charliep@computer.org; mext@ietf.org >> Subject: RE: [MEXT] [mext] #11: De-registration when >> returning home[VijayDevarapalli ] >> >> >> >> Sri, Pascal, Rajeev, >> >> I suggest you guys open a separate issue on whether a mobile node can >> claim its address without first sending a de-registration BU when it >> returns to the home link. >> _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jul 16 11:50:18 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A39823A69DB; Wed, 16 Jul 2008 11:50:18 -0700 (PDT) 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 E5D2928C163 for ; Wed, 16 Jul 2008 11:50:16 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HabC2Ckz-+2A for ; Wed, 16 Jul 2008 11:50:16 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id C5A243A6988 for ; Wed, 16 Jul 2008 11:50:15 -0700 (PDT) Received: from [127.0.0.1] ([75.26.137.116]) by outbound.mse15.exchange.ms with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Jul 2008 14:50:44 -0400 Message-ID: <487E42FC.8030404@wichorus.com> Date: Wed, 16 Jul 2008 11:50:36 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <010801c8e16b$5c2889d0$7471510a@psl.local> <7892795E1A87F04CADFCCF41FADD00FC05F1D85F@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05F76F22@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05F76F22@xmb-ams-337.emea.cisco.com> X-OriginalArrivalTime: 16 Jul 2008 18:50:45.0057 (UTC) FILETIME=[DAA5A310:01C8E774] Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] New Issue on HA behaviour upon MN returning Home 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Pascal, Fixed the subject, since the chairs wanted new issues to carry the "RFC3775 changes" tag. Pascal Thubert (pthubert) wrote: > Charlie and Vijay: > > Following Vijay's advice, I'd wish to open a new issue on the behaviour > of the HA on the Home Link. > > Issue > ----- > With both the original RFC 3775 and the current rework, a HA that has a > binding to a Home Address owns that Home Adddress over the Home Link > till either the node unbinds or the binding times out. Until then the HA > will defend that Home Address using the Override bit in the NA messages > over the Home Link, and until then it is unlawful for the node to use > its Home Address if it is at Home or switch to another HA if it is not > at Home. > > There are multiple issues with this behaviour: > > - service: Whether it is at Home or not, a node that looses the states > about its current binding might be unreachable until the end of its > binding lifetime. It will take a manual operation to recover from that > situation when the lifetime is too long. And it will cause excess > traffic or load on the HAs if the lifetime is too short. In any case > there will be a service disruption that the user might perceive. I agree this needs to be fixed. > - security: The HA defends an address that it does not own so it can not > prove it owns it. With SeND, it would just be nonsense for a HA to try > and reclaim SeND based addresses when a MN proves ownership on link. Well, if SeND is not being used, does it make sense for the home agent to allow the mobile node to claim its address, until the mobile node de-registers with a secure binding update? What if a misbehaving mobile node on the home link tries to claim the legitimate mobile node's home address while the home agent is defending the address? > - compatibility with other proxies: The HA performs a form of ND > proxying for the Mobile Node. We can expect that there will be new forms > of ND proxies coming up - see for instance > http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router-01 -, > and there should be a common behaviour over a shared link for proxies, > regardless of the registration mechanism; in particular a proxy should > yield in the face of the object it proxies for. > > - speed: A Mobile Node reaching Home should be able to use its Home > Address as optimistic (RFC 4429) right away like it could do on any > visited link with any CoA. > > > Proposed resolution > ------------------- > > The proposal to fix this issue is to let the MN use DAD/oDAD over the > Home Link with its Home Address. A proxy would defend the address > without the O bit, This would modify the existing behavior. For unsolicited neighbor advertisements, the Home Agent sets the 'O' bit. See section 10.4.1. > and the MN would ignore it, and upon DAD completion, > NA(Override) its address. The HA would be allowed to set the override > bit only within a binding flow, when it knows synchronously that it > represents the live MN. I lost you. What does "within a binding flow" mean? Vijay > That would enable new HA to take over old HA > when the MN looses states away from home. That would also enable MN to > make before break a tunnel with new HA. > > Still it would still be beneficial to clear the binding properly so we > can still SHOULD or MUST it, but whether that flow works properly or > not, the MN would get its address back. > > What do you think? > > Pascal > >>> From: Vijay Devarapalli [mailto:vijay@wichorus.com] >>> Sent: Fri 7/11/2008 10:52 AM >>> To: Pascal Thubert (pthubert); Sri Gundavelli (sgundave); >>> Koodli, Rajeev >>> Cc: charliep@computer.org; mext@ietf.org >>> Subject: RE: [MEXT] [mext] #11: De-registration when >>> returning home[VijayDevarapalli ] >>> >>> >>> >>> Sri, Pascal, Rajeev, >>> >>> I suggest you guys open a separate issue on whether a mobile node can >>> claim its address without first sending a de-registration BU when it >>> returns to the home link. >>> _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jul 16 16:02:20 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9DB33A67B5; Wed, 16 Jul 2008 16:02:19 -0700 (PDT) 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 902CF3A67B5 for ; Wed, 16 Jul 2008 16:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 UVSWOXyJa1ly for ; Wed, 16 Jul 2008 16:02:17 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 85D4B3A67A3 for ; Wed, 16 Jul 2008 16:02:17 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id DC8B6C803D for ; Wed, 16 Jul 2008 19:02:41 -0400 (EDT) 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 10545-02 for ; Wed, 16 Jul 2008 19:02:40 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 16 Jul 2008 19:02:40 -0400 (EDT) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jul 2008 19:02:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Jul 2008 19:04:36 -0400 Message-ID: <4D35478224365146822AE9E3AD4A2666033471B1@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RFC3775 changes] New Issue on HA behaviour upon MN returning Home Thread-Index: AcjndODRIYcEbIwpRWS68ur088orRwAHeCvA From: "Koodli, Rajeev" To: "Vijay Devarapalli" , "Pascal Thubert (pthubert)" X-OriginalArrivalTime: 16 Jul 2008 23:02:40.0807 (UTC) FILETIME=[0C560B70:01C8E798] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] New Issue on HA behaviour upon MN returning Home 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 Vijay, > > Well, if SeND is not being used, does it make sense for the home agent > to allow the mobile node to claim its address, until the mobile node > de-registers with a secure binding update? What if a misbehaving mobile > node on the home link tries to claim the legitimate mobile node's home > address while the home agent is defending the address? [RKo:>] The Home Agent is *not* trying to improve the default ND security here. It is only proxying an address within the confines of *existing* ND security. The level of MIP security is limited to setting up a BCE, maintaining it (e.g., refresh), forwarding packets and de-registration of BCE. Beyond that, for the scenario you mention above, unsolicited NA from a bogus node does not result in NCE in a state other than STALE, which forces other nodes to probe (i.e., send NS) first before forwarding packets. The MN can reclaim the address. Anyway, this behavior is not specific to MIP. So, it is not a good argument here IMO. > > The proposal to fix this issue is to let the MN use DAD/oDAD over the > > Home Link with its Home Address. A proxy would defend the address > > without the O bit, > > This would modify the existing behavior. For unsolicited neighbor > advertisements, the Home Agent sets the 'O' bit. See section 10.4.1. > [RKo:>] The Proxy (i.e., HA) sets the 'O' bit only when sending unsolicited NA. 24/4861 allowed this (with a MAY); it is not clear why. It could have been lot cleaner to have 'P'roxy bit instead. Response to DAD probe is a solicited NA, and the Proxy must not set the 'O' bit. -Rajeev > > and the MN would ignore it, and upon DAD completion, > > NA(Override) its address. The HA would be allowed to set the override > > bit only within a binding flow, when it knows synchronously that it > > represents the live MN. > > I lost you. What does "within a binding flow" mean? > > Vijay > > > That would enable new HA to take over old HA > > when the MN looses states away from home. That would also enable MN to > > make before break a tunnel with new HA. > > > > Still it would still be beneficial to clear the binding properly so we > > can still SHOULD or MUST it, but whether that flow works properly or > > not, the MN would get its address back. > > > > What do you think? > > > > Pascal > > > >>> From: Vijay Devarapalli [mailto:vijay@wichorus.com] > >>> Sent: Fri 7/11/2008 10:52 AM > >>> To: Pascal Thubert (pthubert); Sri Gundavelli (sgundave); > >>> Koodli, Rajeev > >>> Cc: charliep@computer.org; mext@ietf.org > >>> Subject: RE: [MEXT] [mext] #11: De-registration when > >>> returning home[VijayDevarapalli ] > >>> > >>> > >>> > >>> Sri, Pascal, Rajeev, > >>> > >>> I suggest you guys open a separate issue on whether a mobile node can > >>> claim its address without first sending a de-registration BU when it > >>> returns to the home link. > >>> > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jul 16 16:19:20 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFDA73A68C6; Wed, 16 Jul 2008 16:19:20 -0700 (PDT) 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 DF6B33A68C6 for ; Wed, 16 Jul 2008 16:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 y8P-5vVnuJfH for ; Wed, 16 Jul 2008 16:19:18 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 024173A6863 for ; Wed, 16 Jul 2008 16:19:15 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 1AE8BC8038 for ; Wed, 16 Jul 2008 19:19:43 -0400 (EDT) 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 09279-10 for ; Wed, 16 Jul 2008 19:19:42 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 16 Jul 2008 19:19:42 -0400 (EDT) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jul 2008 19:19:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Jul 2008 19:21:38 -0400 Message-ID: <4D35478224365146822AE9E3AD4A2666033471CF@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Fwd: I-D Action:draft-muhanna-mext-binding-revocation-02.txt Thread-Index: Acjl1AZczByVl9sJQ/aLdEq+xWyQYQBxpahA From: "Koodli, Rajeev" To: "Julien Laganier" , X-OriginalArrivalTime: 16 Jul 2008 23:19:42.0382 (UTC) FILETIME=[6D3E04E0:01C8E79A] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Subject: Re: [MEXT] Fwd: I-D Action:draft-muhanna-mext-binding-revocation-02.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 support the adoption of this draft as a WG item. -Rajeev > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Julien Laganier > Sent: Monday, July 14, 2008 10:02 AM > To: mext@ietf.org > Subject: [MEXT] Fwd: I-D Action:draft-muhanna-mext-binding-revocation- > 02.txt > > Hello Folks, > > The MEXT WG has a deliverable for Binding Revocation for IP Mobility. > > Hereby we'd like to ask WG participants whether or not they think this > individual submission should be adopted as the corresponding MEXT work > item. Please answer to this note to state your opinion by Monday July > 28th. > > Thank you for your support, > > -- julien & marcelo, MEXT chairs _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jul 16 16:22:30 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C752A3A687D; Wed, 16 Jul 2008 16:22:30 -0700 (PDT) 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 E0A573A687D for ; Wed, 16 Jul 2008 16:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.571 X-Spam-Level: X-Spam-Status: No, score=-106.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DeQB5w+SgAG for ; Wed, 16 Jul 2008 16:22:27 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 01B583A6863 for ; Wed, 16 Jul 2008 16:22:24 -0700 (PDT) Received: from localhost ([127.0.0.1]:52526 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1KJGKW-0000Qd-MH; Thu, 17 Jul 2008 01:22:40 +0200 MIME-Version: 1.0 From: "mext" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software To: charliep@computer.org X-Trac-Project: mext Date: Wed, 16 Jul 2008 23:22:40 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/mext/trac/ticket/16 Message-ID: <063.c95a2d67b2a3a9638c10a31fe147cbed@tools.ietf.org> X-Trac-Ticket-ID: 16 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, pthubert@cisco.com, mext@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: mext@ietf.org Subject: [MEXT] [mext] #16: HA behaviour upon MN returning Home [Pascal Thubert ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mext@ietf.org 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 Ticket #16: HA behaviour upon MN returning Home [Pascal Thubert ] HA behaviour upon MN returning Home [Pascal Thubert ] With both the original RFC 3775 and the current rework, a HA that has a binding to a Home Address owns that Home Adddress over the Home Link till either the node unbinds or the binding times out. Until then the HA will defend that Home Address using the Override bit in the NA messages over the Home Link, and until then a mobile node would be out of compliance to use its Home Address if it is at Home or switch to another HA if it is not at Home. There are multiple issues with this behaviour: - service: Whether it is at Home or not, a node that looses the states about its current binding might be unreachable until the end of its binding lifetime. It will take a manual operation to recover from that situation when the lifetime is too long. And it will cause excess traffic or load on the HAs if the lifetime is too short. In any case there will be a service disruption that the user might perceive. - security: The HA defends an address that it does not own so it can not prove it owns it. With SeND, it would just be nonsense for a HA to try and reclaim SeND based addresses when a MN proves ownership on link. - compatibility with other proxies: The HA performs a form of ND proxying for the Mobile Node. We can expect that there will be new forms of ND proxies coming up - see for instance http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router-01 -, and there should be a common behaviour over a shared link for proxies, regardless of the registration mechanism; in particular a proxy should yield in the face of the object it proxies for. - speed: A Mobile Node reaching Home should be able to use its Home Address as optimistic (RFC 4429) right away like it could do on any visited link with any CoA. Proposed resolution: The proposal to fix this issue is to let the MN use DAD/oDAD over the Home Link with its Home Address. A proxy would defend the address without the O bit, and the MN would ignore it, and upon DAD completion, NA(Override) its address. The HA would be allowed to set the override bit only within a binding flow, when it knows synchronously that it represents the live MN. That would enable new HA to take over old HA when the MN looses states away from home. That would also enable MN to make before break a tunnel with new HA. Still it would still be beneficial to clear the binding properly so we can still SHOULD or MUST it, but whether that flow works properly or not, the MN would get its address back. --------------------------------------------------------------------- Vijay Devarapalli : > - security: The HA defends an address that it does not own so it can not > prove it owns it. With SeND, it would just be nonsense for a HA to try > and reclaim SeND based addresses when a MN proves ownership on link. Well, if SeND is not being used, does it make sense for the home agent to allow the mobile node to claim its address, until the mobile node de- registers with a secure binding update? What if a misbehaving mobile node on the home link tries to claim the legitimate mobile node's home address while the home agent is defending the address? > The proposal to fix this issue is to let the MN use DAD/oDAD over the > Home Link with its Home Address. A proxy would defend the address > without the O bit, This would modify the existing behavior. For unsolicited neighbor advertisements, the Home Agent sets the 'O' bit. See section 10.4.1. ----------------------------------------+----------------------------------- Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: major | Milestone: IETF72 Component: draft-ietf-mext-rfc3775bis | Version: 2.0 Severity: Active WG Document | Keywords: Returning Home ----------------------------------------+----------------------------------- -- Ticket URL: mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jul 16 21:01:42 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E43B43A695B; Wed, 16 Jul 2008 21:01:41 -0700 (PDT) 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 D10AB3A695B for ; Wed, 16 Jul 2008 21:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7OIf+MijbnR for ; Wed, 16 Jul 2008 21:01:40 -0700 (PDT) Received: from web84313.mail.re1.yahoo.com (web84313.mail.re1.yahoo.com [69.147.74.192]) by core3.amsl.com (Postfix) with SMTP id C4FA93A6944 for ; Wed, 16 Jul 2008 21:01:39 -0700 (PDT) Received: (qmail 81204 invoked by uid 60001); 17 Jul 2008 04:02:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=07V3KB9OGzEUEqVKz+NViAXhn6QDkCJShdTA2rBWJ8YeAK4nJWvfvhBw30t29ysBfVUR1AjvqbfG+tH3dBV6cLrFmWPEROFT0ZS7h4uwwSZTZhZFxvPredgkQHOcJ7DB2VbVTuuBAp4jXL9FemtvjPwB83414KGJXXzjN/hTquI=; Received: from [72.164.184.10] by web84313.mail.re1.yahoo.com via HTTP; Wed, 16 Jul 2008 21:02:06 PDT X-Mailer: YahooMailRC/975.45 YahooMailWebService/0.7.199 Date: Wed, 16 Jul 2008 21:02:06 -0700 (PDT) From: Behcet Sarikaya To: Julien Laganier , mext@ietf.org MIME-Version: 1.0 Message-ID: <871958.81191.qm@web84313.mail.re1.yahoo.com> Subject: Re: [MEXT] Adoption of draft-muhanna-mext-binding-revocation-02.txt 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="===============0685568590==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0685568590== Content-Type: multipart/alternative; boundary="0-1265159387-1216267326=:81191" --0-1265159387-1216267326=:81191 Content-Type: text/plain; charset=us-ascii I support adoption of draft-muhanna-mext-binding-revocation-02.txt as a WG item. Regards, Behcet ----- Original Message ---- From: Julien Laganier To: mext@ietf.org Sent: Monday, July 14, 2008 12:03:26 PM Subject: [MEXT] Adoption of draft-muhanna-mext-binding-revocation-02.txt Hello Folks, The MEXT WG has a deliverable for Binding Revocation for IP Mobility. Hereby we'd like to ask WG participants whether or not they think this individual submission should be adopted as the corresponding MEXT work item. Please answer to this note to state your opinion by Monday July 28th. Thank you for your support, -- julien & marcelo, MEXT chairs A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Binding Revocation for IPv6 Mobility Author(s) : A. Muhanna, et al. Filename : draft-muhanna-mext-binding-revocation-02.txt Pages : 32 Date : 2008-07-11 This document defines the revocation semantics for terminating a mobile node's mobility session and associated resources. These semantics are generic enough and can be used by mobility entities in the case of Client Mobile IPv6 and its extensions. This mechanism allows the mobility entity which initiates the revocation procedure to request its corresponding one to terminate either one, multiple or all specified binding cache entries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding-revocation-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --0-1265159387-1216267326=:81191 Content-Type: text/html; charset=us-ascii
I support adoption of draft-muhanna-mext-binding-revocation-02.txt as a WG item.

Regards,

Behcet

----- Original Message ----
From: Julien Laganier <julien.IETF@laposte.net>
To: mext@ietf.org
Sent: Monday, July 14, 2008 12:03:26 PM
Subject: [MEXT] Adoption of draft-muhanna-mext-binding-revocation-02.txt

Hello Folks,

The MEXT WG has a deliverable for Binding Revocation for IP Mobility.

Hereby we'd like to ask WG participants whether or not they think this
individual submission should be adopted as the corresponding MEXT work
item. Please answer to this note to state your opinion by Monday July
28th.

Thank you for your support,

-- julien & marcelo, MEXT chairs 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

    Title          : Binding Revocation for IPv6 Mobility
    Author(s)      : A. Muhanna, et al.
    Filename        : draft-muhanna-mext-binding-revocation-02.txt
    Pages          : 32
    Date            : 2008-07-11

This document defines the revocation semantics for terminating a
mobile node's mobility session and associated resources.  These
semantics are generic enough and can be used by mobility entities in
the case of Client Mobile IPv6 and its extensions.  This mechanism
allows the mobility entity which initiates the revocation procedure
to request its corresponding one to terminate either one, multiple or
all specified binding cache entries.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding-revocation-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--0-1265159387-1216267326=:81191-- --===============0685568590== 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 --===============0685568590==-- From mext-bounces@ietf.org Wed Jul 16 23:52:53 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0460B3A6A64; Wed, 16 Jul 2008 23:52:53 -0700 (PDT) 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 6F9B53A69FC for ; Wed, 16 Jul 2008 23:52:52 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zh4XWhtEB7FE for ; Wed, 16 Jul 2008 23:52:51 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D51A33A6A64 for ; Wed, 16 Jul 2008 23:52:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,202,1215388800"; d="scan'208";a="14584852" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 17 Jul 2008 06:53:19 +0000 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 m6H6rJMR015541; Thu, 17 Jul 2008 08:53:19 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6H6rJBa008841; Thu, 17 Jul 2008 06:53:19 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); Thu, 17 Jul 2008 08:53:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 17 Jul 2008 08:52:37 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05F7712F@xmb-ams-337.emea.cisco.com> In-Reply-To: <4D35478224365146822AE9E3AD4A2666033471B1$0001@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RFC3775 changes] New Issue on HA behaviour upon MN returning Home Thread-Index: AcjndODRIYcEbIwpRWS68ur088orRwAHeCvAABGE6XA= References: <4D35478224365146822AE9E3AD4A2666033471B1$0001@exchtewks3.starentnetworks.com> From: "Pascal Thubert (pthubert)" To: "Koodli, Rajeev" , "Vijay Devarapalli" X-OriginalArrivalTime: 17 Jul 2008 06:53:19.0446 (UTC) FILETIME=[CBE06760:01C8E7D9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4556; t=1216277599; x=1217141599; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[RFC3775=20changes]=20New=20Issue=20on= 20HA=20behaviour=20upon=20MN=20returning=20Home |Sender:=20; bh=rlCnoXUjg+OpBjq65KKKJSNs43rCG4or0c6igkFkQPA=; b=UzOoSFhUMBaMv8nPlWAAVP+xXUakhw3fWLDN8K0+2sWCi7jIJieCxHQi/E 9Jvntfrh/bqOz97YSUUo2nIrgcxsvpq9A8edozD37y0EhxRnTQwKa3MUYmWG bB/zK2pmnD; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] New Issue on HA behaviour upon MN returning Home 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 >[RKo:>] The Proxy (i.e., HA) sets the 'O' bit only when sending >unsolicited NA. 24/4861 allowed this (with a MAY); it is not clear why. >It could have been lot cleaner to have 'P'roxy bit instead. Response to >DAD probe is a solicited NA, and the Proxy must not set the 'O' bit. > I agree. Inferring is not as good as knowing. This definition belongs to proxy ND but RFC4389 only discusses P bit in RAs... Pascal >-----Original Message----- >From: Koodli, Rajeev [mailto:rkoodli@starentnetworks.com] >Sent: jeudi 17 juillet 2008 01:05 >To: Vijay Devarapalli; Pascal Thubert (pthubert) >Cc: charliep@computer.org; mext@ietf.org; Sri Gundavelli (sgundave) >Subject: RE: [RFC3775 changes] New Issue on HA behaviour upon MN returning Home > > >Vijay, > >> >> Well, if SeND is not being used, does it make sense for the home agent >> to allow the mobile node to claim its address, until the mobile node >> de-registers with a secure binding update? What if a misbehaving >mobile >> node on the home link tries to claim the legitimate mobile node's home >> address while the home agent is defending the address? > >[RKo:>] The Home Agent is *not* trying to improve the default ND >security here. It is only proxying an address within the confines of >*existing* ND security. The level of MIP security is limited to setting >up a BCE, maintaining it (e.g., refresh), forwarding packets and >de-registration of BCE. > >Beyond that, for the scenario you mention above, unsolicited NA from a >bogus node does not result in NCE in a state other than STALE, which >forces other nodes to probe (i.e., send NS) first before forwarding >packets. The MN can reclaim the address. Anyway, this behavior is not >specific to MIP. So, it is not a good argument here IMO. > >> > The proposal to fix this issue is to let the MN use DAD/oDAD over >the >> > Home Link with its Home Address. A proxy would defend the address >> > without the O bit, >> >> This would modify the existing behavior. For unsolicited neighbor >> advertisements, the Home Agent sets the 'O' bit. See section 10.4.1. >> > >[RKo:>] The Proxy (i.e., HA) sets the 'O' bit only when sending >unsolicited NA. 24/4861 allowed this (with a MAY); it is not clear why. >It could have been lot cleaner to have 'P'roxy bit instead. Response to >DAD probe is a solicited NA, and the Proxy must not set the 'O' bit. > >-Rajeev > > > >> > and the MN would ignore it, and upon DAD completion, >> > NA(Override) its address. The HA would be allowed to set the >override >> > bit only within a binding flow, when it knows synchronously that it >> > represents the live MN. >> >> I lost you. What does "within a binding flow" mean? >> >> Vijay >> >> > That would enable new HA to take over old HA >> > when the MN looses states away from home. That would also enable MN >to >> > make before break a tunnel with new HA. >> > >> > Still it would still be beneficial to clear the binding properly so >we >> > can still SHOULD or MUST it, but whether that flow works properly or >> > not, the MN would get its address back. >> > >> > What do you think? >> > >> > Pascal >> > >> >>> From: Vijay Devarapalli [mailto:vijay@wichorus.com] >> >>> Sent: Fri 7/11/2008 10:52 AM >> >>> To: Pascal Thubert (pthubert); Sri Gundavelli (sgundave); >> >>> Koodli, Rajeev >> >>> Cc: charliep@computer.org; mext@ietf.org >> >>> Subject: RE: [MEXT] [mext] #11: De-registration when >> >>> returning home[VijayDevarapalli ] >> >>> >> >>> >> >>> >> >>> Sri, Pascal, Rajeev, >> >>> >> >>> I suggest you guys open a separate issue on whether a mobile node >can >> >>> claim its address without first sending a de-registration BU when >it >> >>> returns to the home link. >> >>> >> > > >"This email message and any attachments are confidential information of Starent Networks, Corp. The >information transmitted may not be used to create or change any contractual obligations of Starent >Networks, Corp. Any review, retransmission, dissemination or other use of, or taking of any action >in reliance upon this e-mail and its attachments by persons or entities other than the intended >recipient is prohibited. If you are not the intended recipient, please notify the sender immediately >-- by replying to this message or by sending an email to postmaster@starentnetworks.com -- and >destroy all copies of this message and any attachments without reading or disclosing their contents. >Thank you." _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jul 17 00:52:45 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AD7128C14A; Thu, 17 Jul 2008 00:52:45 -0700 (PDT) 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 9FB5728C11D for ; Thu, 17 Jul 2008 00:52:44 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-leK+kso0-D for ; Thu, 17 Jul 2008 00:52:43 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 6064C28C14A for ; Thu, 17 Jul 2008 00:52:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,202,1215388800"; d="scan'208";a="14590700" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 17 Jul 2008 07:53:10 +0000 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 m6H7rAER031719; Thu, 17 Jul 2008 09:53:10 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6H7rAb0029808; Thu, 17 Jul 2008 07:53:10 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); Thu, 17 Jul 2008 09:53:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 17 Jul 2008 09:52:28 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05F7717B@xmb-ams-337.emea.cisco.com> In-Reply-To: <487E42FC.8030404@wichorus.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RFC3775 changes] New Issue on HA behaviour upon MN returning Home Thread-Index: AcjndN3zOaKYU3kMTnudMJuDraZthwAZNo3A References: <010801c8e16b$5c2889d0$7471510a@psl.local> <7892795E1A87F04CADFCCF41FADD00FC05F1D85F@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05F76F22@xmb-ams-337.emea.cisco.com> <487E42FC.8030404@wichorus.com> From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" X-OriginalArrivalTime: 17 Jul 2008 07:53:10.0074 (UTC) FILETIME=[280EC1A0:01C8E7E2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7297; t=1216281190; x=1217145190; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[RFC3775=20changes]=20New=20Issue=20on= 20HA=20behaviour=20upon=20MN=20returning=20Home |Sender:=20; bh=SWTY3NWASCxp9cOK8yvOyHniFsW32B656Qpx5ytvkBs=; b=FIjjwVgbzCzXADbPxiTugG8qKg0u/p+i6FGRi2FQV35xuDxxRDufjWh4lE cUp8dUyAtdc6lKJ+R0ec7Nx55RbsJdk4kYEb5fl0AQKmx/Nw4nRExD/UN49w xzffk4WHsu; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] New Issue on HA behaviour upon MN returning Home 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: Let me rephrase the proposed resolution in more details: For me there are 2 phases in the HA proxy operation. Sync, and async. Sync is upon a communication with the MN. For instance the MN sends a BU, the HA completes DAD, sends NA and BA (success) back to the MN. Async is upon communication with another node (solicited) or upon a timer (unsolicited). What I'm asking to change on the HA side is that in the async case, the HA does not set the override because its binding might be stale. I'm also asking that the HA marks a binding as stale upon a NA (override), stops intercepting packets and stops defending the address in ND flows. What I'm asking to change on the MN side is to allow it to perform (optimistic) DAD for its Home Address when it returns home regardless of the known state of the binding. I'm also asking that both the MN and the HA may ignore a NA without the override bit and consider DAD a success if no NA (Override) is heard. I'm not asking to change that the MN MUST clean up the binding. That's a good thing to remove the stale BCE in the HA before end of lifetime. But if we do it to early there might be packets lost before the MN gets its address back. The way things would work with the change is that upon DAD completion, the MN returning home would send NA (Override) and get its address back regardless of the state of the HAs. The coup (the NA(override)) on the home address would trigger the stale HA to stop intercepting so there would be (almost) no packet loss during the transition. Also, a MN that is away from home may bind with a new HA without cleaning a binding with an old HA first; the new HA will complete DAD, send NA(override) at which point old HA will yield and new HA will start forwarding with (almost) no packet loss during the transition. In that case the MN would clean up the old BCE after the successful BA from the new HA. If the initial binding is with a backlevel HA on the home link, that HA will defend the address with the O bit as prescribed by RFC 3775 and the MN or new HA will not complete DAD. The RFC 3775 operation will thus happen unchanged. A backlevel MN binding with a HA with the proposed behaviour will clean up the old binding before it attempts anything so then again things happen prescribed as by RFC 3775. A MN that looses its states about an existing binding, regardless of whether it implements the original or the new behaviour, will always be able to bind again if the HA implements the new behaviour, and will not be able to bind till end of lifetime if the HA implements the old behaviour. Seems to me that the new proposal is compatible with the existing standard. Pascal >-----Original Message----- >From: Vijay Devarapalli [mailto:vijay@wichorus.com] >Sent: mercredi 16 juillet 2008 20:51 >To: Pascal Thubert (pthubert): >Cc: charliep@computer.org; mext@ietf.org; Koodli, Rajeev; Sri Gundavelli (sgundave) >Subject: Re: [RFC3775 changes] New Issue on HA behaviour upon MN returning Home > >Hi Pascal, > >Fixed the subject, since the chairs wanted new issues to carry the >"RFC3775 changes" tag. > >Pascal Thubert (pthubert) wrote: >> Charlie and Vijay: >> >> Following Vijay's advice, I'd wish to open a new issue on the behaviour >> of the HA on the Home Link. >> >> Issue >> ----- >> With both the original RFC 3775 and the current rework, a HA that has a >> binding to a Home Address owns that Home Adddress over the Home Link >> till either the node unbinds or the binding times out. Until then the HA >> will defend that Home Address using the Override bit in the NA messages >> over the Home Link, and until then it is unlawful for the node to use >> its Home Address if it is at Home or switch to another HA if it is not >> at Home. >> >> There are multiple issues with this behaviour: >> >> - service: Whether it is at Home or not, a node that looses the states >> about its current binding might be unreachable until the end of its >> binding lifetime. It will take a manual operation to recover from that >> situation when the lifetime is too long. And it will cause excess >> traffic or load on the HAs if the lifetime is too short. In any case >> there will be a service disruption that the user might perceive. > >I agree this needs to be fixed. > >> - security: The HA defends an address that it does not own so it can not >> prove it owns it. With SeND, it would just be nonsense for a HA to try >> and reclaim SeND based addresses when a MN proves ownership on link. > >Well, if SeND is not being used, does it make sense for the home agent >to allow the mobile node to claim its address, until the mobile node >de-registers with a secure binding update? What if a misbehaving mobile >node on the home link tries to claim the legitimate mobile node's home >address while the home agent is defending the address? > >> - compatibility with other proxies: The HA performs a form of ND >> proxying for the Mobile Node. We can expect that there will be new forms >> of ND proxies coming up - see for instance >> http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router-01 -, >> and there should be a common behaviour over a shared link for proxies, >> regardless of the registration mechanism; in particular a proxy should >> yield in the face of the object it proxies for. >> >> - speed: A Mobile Node reaching Home should be able to use its Home >> Address as optimistic (RFC 4429) right away like it could do on any >> visited link with any CoA. >> >> >> Proposed resolution >> ------------------- >> >> The proposal to fix this issue is to let the MN use DAD/oDAD over the >> Home Link with its Home Address. A proxy would defend the address >> without the O bit, > >This would modify the existing behavior. For unsolicited neighbor >advertisements, the Home Agent sets the 'O' bit. See section 10.4.1. > > > and the MN would ignore it, and upon DAD completion, >> NA(Override) its address. The HA would be allowed to set the override >> bit only within a binding flow, when it knows synchronously that it >> represents the live MN. > >I lost you. What does "within a binding flow" mean? > >Vijay > >> That would enable new HA to take over old HA >> when the MN looses states away from home. That would also enable MN to >> make before break a tunnel with new HA. >> >> Still it would still be beneficial to clear the binding properly so we >> can still SHOULD or MUST it, but whether that flow works properly or >> not, the MN would get its address back. >> >> What do you think? >> >> Pascal >> >>>> From: Vijay Devarapalli [mailto:vijay@wichorus.com] >>>> Sent: Fri 7/11/2008 10:52 AM >>>> To: Pascal Thubert (pthubert); Sri Gundavelli (sgundave); >>>> Koodli, Rajeev >>>> Cc: charliep@computer.org; mext@ietf.org >>>> Subject: RE: [MEXT] [mext] #11: De-registration when >>>> returning home[VijayDevarapalli ] >>>> >>>> >>>> >>>> Sri, Pascal, Rajeev, >>>> >>>> I suggest you guys open a separate issue on whether a mobile node can >>>> claim its address without first sending a de-registration BU when it >>>> returns to the home link. >>>> > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From doncs@att.com Thu Jul 17 03:01: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 776D33A6A13 for ; Thu, 17 Jul 2008 03:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.852 X-Spam-Level: X-Spam-Status: No, score=-1.852 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, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_MESSAGE=0.001, 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, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_WEOFFER=0.3, TVD_RCVD_IP=1.931, 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, 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 NBCLEsGZHzKX for ; Thu, 17 Jul 2008 03:01:08 -0700 (PDT) Received: from 114.194-224-87.telenet.ru (114.194-224-87.telenet.ru [87.224.194.114]) by core3.amsl.com (Postfix) with ESMTP id 4DBC93A69FC for ; Thu, 17 Jul 2008 03:01:08 -0700 (PDT) Message-ID: <000601c8e7f4$026a36cf$1fd5b1ae@onpwueax> From: "Purses" To: "Cartier Replica" Subject: Franck Muller Watches Date: Thu, 17 Jul 2008 08:14:15 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C8E7F4.026A0441" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C8E7F4.026A0441 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Replica Watches We offer the finest quality luxury designer replica watches=20 and timepieces at the most attractive prices anywhere.=20 Visit our catalogue... ------=_NextPart_000_0003_01C8E7F4.026A0441 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Replica Watches

We offer the finest quality luxury designer = replica watches
and timepieces at the most attractive prices = anywhere.

Visit our = catalogue...
------=_NextPart_000_0003_01C8E7F4.026A0441-- From mext-bounces@ietf.org Thu Jul 17 05:03:29 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E16913A6947; Thu, 17 Jul 2008 05:03:28 -0700 (PDT) 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 8A4503A6947 for ; Thu, 17 Jul 2008 05:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-d2iMd8mwgC for ; Thu, 17 Jul 2008 05:03:26 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id A32BB3A68DE for ; Thu, 17 Jul 2008 05:03:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=whaddad@qualcomm.com; q=dns/txt; s=qcdkim; t=1216296238; x=1247832238; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version: x-ironport-av; z=From:=20"Haddad,=20Wassim=20Michel"=20|To:=20"mext@ietf.org"=20|CC:=20"Hadda d,=20Wassim=20Michel"=20|Date:=20Th u,=2017=20Jul=202008=2005:03:53=20-0700|Subject:=20MIPv6 =20Residual=20Threats=20v02|Thread-Topic:=20MIPv6=20Resid ual=20Threats=20v02|Thread-Index:=20AcjoBS5XbRdO3lP4Ed2hf QAfW+eO+A=3D=3D|Message-ID:=20|Accept-Language:=20en-US|Content-Language:=20en |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"iso-8 859-1"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 200,2160,5340"=3B=20a=3D"4797821"; bh=kdVCgh8BDIwE9WCImQ90BasNm2Xa1FsOwhBAOeV4KEM=; b=WGzeTwC+0mRBMfovdCP0koPaY+4QEp1OV6NNKi0+WTiRgC65kbTv1ccF usoDXMzdsod0J4vgFmteh9K1KIrmvlShElZuuWtFgqTfCUFiD6TnXCM1V wedSGUxeaCTjT+z38jEdWN5vCodZqi+P9u0xVP1rd0ZcBvu6QtIZZvnBw w=; X-IronPort-AV: E=McAfee;i="5200,2160,5340"; a="4797821" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Jul 2008 05:03:57 -0700 Received: from msgtransport06.qualcomm.com (msgtransport06.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m6HC3v39031163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 17 Jul 2008 05:03:57 -0700 Received: from nasanexhc02.na.qualcomm.com (nasanexhc02.na.qualcomm.com [172.30.33.23]) by msgtransport06.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m6HC3vlF007051 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 17 Jul 2008 05:03:57 -0700 Received: from NASANEXMB01.na.qualcomm.com ([129.46.50.94]) by nasanexhc02.na.qualcomm.com ([172.30.33.23]) with mapi; Thu, 17 Jul 2008 05:03:57 -0700 From: "Haddad, Wassim Michel" To: "mext@ietf.org" Date: Thu, 17 Jul 2008 05:03:53 -0700 Thread-Topic: MIPv6 Residual Threats v02 Thread-Index: AcjoBS5XbRdO3lP4Ed2hfQAfW+eO+A== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [MEXT] MIPv6 Residual Threats v02 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! FYI, we've submitted a new version: http://www.ietf.org/internet-drafts/draft-haddad-mext-mip6-residual-threats- 02.txt Comments appreciated. Regards, Wassim H. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jul 17 15:30:52 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B969928C108; Thu, 17 Jul 2008 15:30:52 -0700 (PDT) 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 3CB3D3A692C; Thu, 17 Jul 2008 15:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b86u9CjprsUg; Thu, 17 Jul 2008 15:30:50 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 9FC503A6831; Thu, 17 Jul 2008 15:30:49 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 691C6C801E; Thu, 17 Jul 2008 18:31:15 -0400 (EDT) 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 11242-04; Thu, 17 Jul 2008 18:31:11 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP; Thu, 17 Jul 2008 18:31:11 -0400 (EDT) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jul 2008 18:31:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 17 Jul 2008 18:33:07 -0400 Message-ID: <4D35478224365146822AE9E3AD4A2666033E173C@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Network-based Mobility Extensions (NetExt) Bar BOF Thread-Index: AcjoXRWPSJApqEV3R5GKw/F7RXnI0g== From: "Koodli, Rajeev" To: , , X-OriginalArrivalTime: 17 Jul 2008 22:31:11.0751 (UTC) FILETIME=[D0C8B970:01C8E85C] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Cc: Basavaraj Patil Subject: [MEXT] Network-based Mobility Extensions (NetExt) Bar BOF 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="===============0313252104==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============0313252104== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8E85C.D0982C75" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8E85C.D0982C75 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello folks, =20 As many of you involved in Network-based Mobility (PMIPv6) are aware, there appears to be more interest in Network-based Mobility than the NETLMM charter can reasonably handle. So, Raj and myself are pondering whether there is enough interest among folks to work on a few more items. To this extent, we are planning to hold a Bar BOF at Dublin. At this stage, this is only to investigate=20 =20 a) if there are a few topics which we should be working on (relevant to network-based mobility), and=20 b) whether there is enough interest behind them to work on.=20 =20 This is tentatively set for Thursday (7/31), at 1300. We will confirm the time and venue later.=20 =20 If you are interested in presenting what you think should be worked on, here is a template we would like you to use. 1. Title (of course)=20 2. Brief description of the topic, no more than few sentences=20 3. Why this topic needs to be worked on now (feel free to include any need(s) from external organizations/industry but please be as clear as possible). Again, no more than couple of sentences=20 You should spend at most a slide for this. As an example, 1. Session Control for PMIPv6=20 2. PMIPv6 provides a network-based mobility management without the explicit involvement of a Mobile Node. It does not provide control mechanisms to offer features such as QoS and Policy at the granularity of an individual mobility session. This work extends the PMIPv6 protocol to provide such support.=20 3. Deployments (such as in 3GPP) where PMIPv6 is a candidate protocol need Session Control. For instance, the GPRS Tunneling Protocol (GTP) already provides the necessary signaling support for QoS.=20 Please send us your requests. The ML to be used for this discussion is: netext@mail.mobileip.jp If you have any questions or comments, please post to the Netext ML or send email to basavaraj.patil@nokia.com and rkoodli@starentnetworks.com =20 We hope to have a good and focused discussion which could lead to a short list of topics for further consideration. =20 Thank you and see you in Dublin. =20 Regards, =20 -Rajeev and Raj =20 ------_=_NextPart_001_01C8E85C.D0982C75 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello folks,
 
As many of you involved in Network-based Mobility (PMIPv6) are aware, = there appears to be more interest in Network-based Mobility than the NETLMM = charter can reasonably handle. So, Raj and myself are pondering whether there is = enough interest among folks to work on a few more items. To this extent, we are planning to hold a Bar BOF at Dublin. At this stage, this is only to investigate

 

a) if there are a few topics which we should be = working on (relevant to network-based mobility), and

b) whether there is enough interest behind them to = work on.

 

This is tentatively set for Thursday (7/31), at 1300. = We will confirm the time and venue later.
 
If you are interested in presenting what you think should be worked on, = here is a template we would like you to use.

  1. Title (of course) =
  2. Brief description of the topic, no more = than few sentences
  3. Why this topic needs to be worked on now = (feel free to include any need(s) from external organizations/industry = but please be as clear as possible). Again, no more than couple of = sentences =

You should spend at most a slide for this. As an = example,

  1. Session Control for = PMIPv6 =
  2. PMIPv6 provides a network-based mobility management without the explicit involvement of a Mobile Node. It = does not provide control mechanisms to offer features such as QoS and Policy = at the granularity of an individual mobility session. This work extends = the PMIPv6 protocol to provide such support. =
  3. Deployments (such as in 3GPP) where = PMIPv6 is a candidate protocol need Session Control. For instance, the GPRS = Tunneling Protocol (GTP) already provides the necessary signaling support for = QoS.

Please send us your requests.

The ML to be used for this discussion is: netext@mail.mobileip.jp<= /span>

If you have any questions or comments, please post to the Netext ML or send email to = basavaraj.patil@nokia.com and rkoodli@starentnetworks.com
=  
We hope to have a good and focused discussion which could lead to a = short list of topics for further consideration.
 
Thank you and see you in Dublin.
 
Regards,
 
-Rajeev and Raj

 

------_=_NextPart_001_01C8E85C.D0982C75-- --===============0313252104== 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 --===============0313252104==-- From mext-bounces@ietf.org Thu Jul 17 18:14:53 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F47A28C139; Thu, 17 Jul 2008 18:14:53 -0700 (PDT) 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 925A83A6A02 for ; Thu, 17 Jul 2008 18:14:52 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weofzB4FOygd for ; Thu, 17 Jul 2008 18:14:51 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by core3.amsl.com (Postfix) with ESMTP id 69A3D3A69FE for ; Thu, 17 Jul 2008 18:14:51 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so119728rvf.49 for ; Thu, 17 Jul 2008 18:15:23 -0700 (PDT) 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=pSbZc/7zCyXXtCkJMW16t8bxxJ2YfnwaX6eZDsBL9Fo=; b=FLs/S+J7Juyzi0JvK9pskor2rlPpbwVyab5Iv93jrQ94S/y4xbEVWRDmCW6ryx+zkg zMLtoZv0ll4kR6qG/ilUWPkWM2B4FGl2lSNbl4qhdDfm0zDT8Vj3Lv4gfAm6cLE7YQPM TguWn5+FhMtR/tBB/dcVdcsgXmHR2xiiR/3fw= 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=rA37iFnL78ff3zVLDK2UASngzzW62CtSvI5kBBwzRH0IAS+oKAARsU+12rEg/yBmh/ bJ6nY37C+CvrXfyzDCH+OYUCM3tFl9WbRIvHqeF5kgXymoU4sTQaNeFrI5cboLertYcM X5SKwTM8viCY3n9fOnDfeZB+YhU7V4GjhnLVE= Received: by 10.141.29.8 with SMTP id g8mr1572130rvj.62.1216343722782; Thu, 17 Jul 2008 18:15:22 -0700 (PDT) Received: from ?172.17.105.59? ( [61.200.198.242]) by mx.google.com with ESMTPS id g22sm952049rvb.7.2008.07.17.18.15.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 17 Jul 2008 18:15:22 -0700 (PDT) From: Ryuji Wakikawa To: "Koodli, Rajeev" In-Reply-To: <4D35478224365146822AE9E3AD4A2666033E173C@exchtewks3.starentnetworks.com> References: <4D35478224365146822AE9E3AD4A2666033E173C@exchtewks3.starentnetworks.com> Message-Id: <2BED9A33-0B58-48EC-84A8-621CBE2B806A@gmail.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Fri, 18 Jul 2008 10:15:18 +0900 X-Mailer: Apple Mail (2.926) Cc: mipshop@ietf.org, Basavaraj Patil , "netlmm@ietf.org Mailing List" , mext Subject: Re: [MEXT] [Mipshop] Network-based Mobility Extensions (NetExt) Bar BOF 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-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed"; DelSp="yes" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org WW91IGNhbiBzdWJzY3JpYmUgdG8gdGhlIGxpc3QgZnJvbSB0aGUgZm9sbG93aW5nIFVSTC4KCmh0 dHA6Ly93d3cubW9iaWxlaXAuanAvbWFpbG1hbi9saXN0aW5mby9uZXRleHQKCnJlZ2FyZHMsCnJ5 dWppCgpPbiAyMDA4LzA3LzE4LCBhdCA3OjMzLCBLb29kbGksIFJhamVldiB3cm90ZToKCj4gSGVs bG8gZm9sa3MsCj4KPiBBcyBtYW55IG9mIHlvdSBpbnZvbHZlZCBpbiBOZXR3b3JrLWJhc2VkIE1v YmlsaXR5IChQTUlQdjYpIGFyZSAgCj4gYXdhcmUsIHRoZXJlIGFwcGVhcnMgdG8gYmUgbW9yZSBp bnRlcmVzdCBpbiBOZXR3b3JrLWJhc2VkIE1vYmlsaXR5ICAKPiB0aGFuIHRoZSBORVRMTU0gY2hh cnRlciBjYW4gcmVhc29uYWJseSBoYW5kbGUuIFNvLCBSYWogYW5kIG15c2VsZiAgCj4gYXJlIHBv bmRlcmluZyB3aGV0aGVyIHRoZXJlIGlzIGVub3VnaCBpbnRlcmVzdCBhbW9uZyBmb2xrcyB0byB3 b3JrICAKPiBvbiBhIGZldyBtb3JlIGl0ZW1zLiBUbyB0aGlzIGV4dGVudCwgd2UgYXJlIHBsYW5u aW5nIHRvIGhvbGQgYSBCYXIgIAo+IEJPRiBhdCBEdWJsaW4uIEF0IHRoaXMgc3RhZ2UsIHRoaXMg aXMgb25seSB0byBpbnZlc3RpZ2F0ZQo+Cj4gYSkgaWYgdGhlcmUgYXJlIGEgZmV3IHRvcGljcyB3 aGljaCB3ZSBzaG91bGQgYmUgd29ya2luZyBvbiAocmVsZXZhbnQgIAo+IHRvIG5ldHdvcmstYmFz ZWQgbW9iaWxpdHkpLCBhbmQKPiBiKSB3aGV0aGVyIHRoZXJlIGlzIGVub3VnaCBpbnRlcmVzdCBi ZWhpbmQgdGhlbSB0byB3b3JrIG9uLgo+Cj4gVGhpcyBpcyB0ZW50YXRpdmVseSBzZXQgZm9yIFRo dXJzZGF5ICg3LzMxKSwgYXQgMTMwMC4gV2Ugd2lsbCAgCj4gY29uZmlybSB0aGUgdGltZSBhbmQg dmVudWUgbGF0ZXIuCj4KPiBJZiB5b3UgYXJlIGludGVyZXN0ZWQgaW4gcHJlc2VudGluZyB3aGF0 IHlvdSB0aGluayBzaG91bGQgYmUgd29ya2VkICAKPiBvbiwgaGVyZSBpcyBhIHRlbXBsYXRlIHdl IHdvdWxkIGxpa2UgeW91IHRvIHVzZS4KPiAJ4oCiIFRpdGxlIChvZiBjb3Vyc2UpCj4gCeKAoiBC cmllZiBkZXNjcmlwdGlvbiBvZiB0aGUgdG9waWMsIG5vIG1vcmUgdGhhbiBmZXcgc2VudGVuY2Vz Cj4gCeKAoiBXaHkgdGhpcyB0b3BpYyBuZWVkcyB0byBiZSB3b3JrZWQgb24gbm93IChmZWVsIGZy ZWUgdG8gaW5jbHVkZSAgCj4gYW55IG5lZWQocykgZnJvbSBleHRlcm5hbCBvcmdhbml6YXRpb25z L2luZHVzdHJ5IGJ1dCBwbGVhc2UgYmUgYXMgIAo+IGNsZWFyIGFzIHBvc3NpYmxlKS4gQWdhaW4s IG5vIG1vcmUgdGhhbiBjb3VwbGUgb2Ygc2VudGVuY2VzCj4gWW91IHNob3VsZCBzcGVuZCBhdCBt b3N0IGEgc2xpZGUgZm9yIHRoaXMuIEFzIGFuIGV4YW1wbGUsCj4gCeKAoiBTZXNzaW9uIENvbnRy b2wgZm9yIFBNSVB2Ngo+IAnigKIgUE1JUHY2IHByb3ZpZGVzIGEgbmV0d29yay1iYXNlZCBtb2Jp bGl0eSBtYW5hZ2VtZW50IHdpdGhvdXQgdGhlICAKPiBleHBsaWNpdCBpbnZvbHZlbWVudCBvZiBh IE1vYmlsZSBOb2RlLiBJdCBkb2VzIG5vdCBwcm92aWRlIGNvbnRyb2wgIAo+IG1lY2hhbmlzbXMg dG8gb2ZmZXIgZmVhdHVyZXMgc3VjaCBhcyBRb1MgYW5kIFBvbGljeSBhdCB0aGUgIAo+IGdyYW51 bGFyaXR5IG9mIGFuIGluZGl2aWR1YWwgbW9iaWxpdHkgc2Vzc2lvbi4gVGhpcyB3b3JrIGV4dGVu ZHMgdGhlICAKPiBQTUlQdjYgcHJvdG9jb2wgdG8gcHJvdmlkZSBzdWNoIHN1cHBvcnQuCj4gCeKA oiBEZXBsb3ltZW50cyAoc3VjaCBhcyBpbiAzR1BQKSB3aGVyZSBQTUlQdjYgaXMgYSBjYW5kaWRh dGUgIAo+IHByb3RvY29sIG5lZWQgU2Vzc2lvbiBDb250cm9sLiBGb3IgaW5zdGFuY2UsIHRoZSBH UFJTIFR1bm5lbGluZyAgCj4gUHJvdG9jb2wgKEdUUCkgYWxyZWFkeSBwcm92aWRlcyB0aGUgbmVj ZXNzYXJ5IHNpZ25hbGluZyBzdXBwb3J0IGZvciAgCj4gUW9TLgo+IFBsZWFzZSBzZW5kIHVzIHlv dXIgcmVxdWVzdHMuCj4gVGhlIE1MIHRvIGJlIHVzZWQgZm9yIHRoaXMgZGlzY3Vzc2lvbiBpczog bmV0ZXh0QG1haWwubW9iaWxlaXAuanAKPiBJZiB5b3UgaGF2ZSBhbnkgcXVlc3Rpb25zIG9yIGNv bW1lbnRzLCBwbGVhc2UgcG9zdCB0byB0aGUgTmV0ZXh0IE1MICAKPiBvciBzZW5kIGVtYWlsIHRv IGJhc2F2YXJhai5wYXRpbEBub2tpYS5jb20gYW5kIHJrb29kbGlAc3RhcmVudG5ldHdvcmtzLmNv bQo+Cj4gV2UgaG9wZSB0byBoYXZlIGEgZ29vZCBhbmQgZm9jdXNlZCBkaXNjdXNzaW9uIHdoaWNo IGNvdWxkIGxlYWQgdG8gYSAgCj4gc2hvcnQgbGlzdCBvZiB0b3BpY3MgZm9yIGZ1cnRoZXIgY29u c2lkZXJhdGlvbi4KPgo+IFRoYW5rIHlvdSBhbmQgc2VlIHlvdSBpbiBEdWJsaW4uCj4KPiBSZWdh cmRzLAo+Cj4gLVJhamVldiBhbmQgUmFqCj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwo+IE1pcHNob3AgbWFpbGluZyBsaXN0Cj4gTWlwc2hvcEBpZXRm Lm9yZwo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWlwc2hvcAoKX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTUVYVCBtYWlsaW5n IGxpc3QKTUVYVEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21leHQK From mext-bounces@ietf.org Fri Jul 18 05:51:28 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 357CF3A694E; Fri, 18 Jul 2008 05:51:28 -0700 (PDT) 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 E3D013A694E for ; Fri, 18 Jul 2008 05:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFc1k8vwDGG5 for ; Fri, 18 Jul 2008 05:51:25 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 72E3B3A6893 for ; Fri, 18 Jul 2008 05:51:25 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BD7F520A66; Fri, 18 Jul 2008 14:51:57 +0200 (CEST) X-AuditID: c1b4fb3c-ad099bb00000193b-3a-488091edc9db Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8C55F20853; Fri, 18 Jul 2008 14:51:57 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jul 2008 14:51:57 +0200 Received: from [153.88.44.114] ([153.88.44.114]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jul 2008 14:51:55 +0200 Message-ID: <488091EB.1030607@ericsson.com> Date: Fri, 18 Jul 2008 14:51:55 +0200 From: Conny Larsson User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Julien Laganier References: <200807141901.50950.julien.IETF@laposte.net> In-Reply-To: <200807141901.50950.julien.IETF@laposte.net> X-OriginalArrivalTime: 18 Jul 2008 12:51:56.0615 (UTC) FILETIME=[0F859570:01C8E8D5] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] Fwd: I-D Action:draft-muhanna-mext-binding-revocation-02.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="===============0435220953==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============0435220953== Content-Type: multipart/alternative; boundary="------------010605050906030708050309" This is a multi-part message in MIME format. --------------010605050906030708050309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Julien, I have read the draft and I support adopting the draft as a working group item. Regards Conny Julien Laganier wrote: > Hello Folks, > > The MEXT WG has a deliverable for Binding Revocation for IP Mobility. > > Hereby we'd like to ask WG participants whether or not they think this > individual submission should be adopted as the corresponding MEXT work > item. Please answer to this note to state your opinion by Monday July > 28th. > > Thank you for your support, > > -- julien & marcelo, MEXT chairs > > > ------------------------------------------------------------------------ > > Subject: > I-D Action:draft-muhanna-mext-binding-revocation-02.txt > From: > Internet-Drafts@ietf.org > Date: > Fri, 11 Jul 2008 06:45:01 -0700 (PDT) > To: > i-d-announce@ietf.org > > To: > i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Binding Revocation for IPv6 Mobility > Author(s) : A. Muhanna, et al. > Filename : draft-muhanna-mext-binding-revocation-02.txt > Pages : 32 > Date : 2008-07-11 > > This document defines the revocation semantics for terminating a > mobile node's mobility session and associated resources. These > semantics are generic enough and can be used by mobility entities in > the case of Client Mobile IPv6 and its extensions. This mechanism > allows the mobility entity which initiates the revocation procedure > to request its corresponding one to terminate either one, multiple or > all specified binding cache entries. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding-revocation-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > ------------------------------------------------------------------------ > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > --------------010605050906030708050309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Julien,

I have read the draft and I support adopting the draft as a working group item.

Regards
Conny

Julien Laganier wrote: 
Hello Folks,

The MEXT WG has a deliverable for Binding Revocation for IP Mobility. 

Hereby we'd like to ask WG participants whether or not they think this 
individual submission should be adopted as the corresponding MEXT work 
item. Please answer to this note to state your opinion by Monday July 
28th.

Thank you for your support,

-- julien & marcelo, MEXT chairs


Subject:
I-D Action:draft-muhanna-mext-binding-revocation-02.txt
From:
Internet-Drafts@ietf.org
Date:
Fri, 11 Jul 2008 06:45:01 -0700 (PDT)
To:
i-d-announce@ietf.org
To:
i-d-announce@ietf.org		 

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Binding Revocation for IPv6 Mobility
	Author(s)       : A. Muhanna, et al.
	Filename        : draft-muhanna-mext-binding-revocation-02.txt
	Pages           : 32
	Date            : 2008-07-11

This document defines the revocation semantics for terminating a
mobile node's mobility session and associated resources.  These
semantics are generic enough and can be used by mobility entities in
the case of Client Mobile IPv6 and its extensions.  This mechanism
allows the mobility entity which initiates the revocation procedure
to request its corresponding one to terminate either one, multiple or
all specified binding cache entries.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding-revocation-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
  

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
  

_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext
--------------010605050906030708050309-- --===============0435220953== 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 --===============0435220953==-- From mext-bounces@ietf.org Fri Jul 18 06:01:15 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4D2F3A69C2; Fri, 18 Jul 2008 06:01:15 -0700 (PDT) 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 A2A5D3A69C2 for ; Fri, 18 Jul 2008 06:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MI27J1DnYUMD for ; Fri, 18 Jul 2008 06:01:13 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 2AEDF3A697F for ; Fri, 18 Jul 2008 06:01:13 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8B77A20DF3; Fri, 18 Jul 2008 15:00:46 +0200 (CEST) X-AuditID: c1b4fb3c-af89ebb00000193b-61-488093fe9777 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5B6D320DDD; Fri, 18 Jul 2008 15:00:46 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jul 2008 15:00:46 +0200 Received: from [153.88.44.114] ([153.88.44.114]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jul 2008 15:00:45 +0200 Message-ID: <488093FE.6040702@ericsson.com> Date: Fri, 18 Jul 2008 15:00:46 +0200 From: Conny Larsson User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Julien Laganier References: <200807141903.00610.julien.IETF@laposte.net> In-Reply-To: <200807141903.00610.julien.IETF@laposte.net> X-OriginalArrivalTime: 18 Jul 2008 13:00:45.0636 (UTC) FILETIME=[4AD7C840:01C8E8D6] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of draft-haley-mext-generic-signaling-message-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: multipart/mixed; boundary="===============0006315430==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============0006315430== Content-Type: multipart/alternative; boundary="------------030309070309010602000306" This is a multi-part message in MIME format. --------------030309070309010602000306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Julien, I support draft-muhanna-mext-binding-revocation to become a working group item and since this draft relays on "Generic Signaling Message for MIPv6" I also support this draft to become a working group item. Regards Conny Julien Laganier wrote: > Hello Folks, > > The MEXT WG has a deliverable for a Generic Signaling Message for MIPv6. > > Hereby we'd like to ask WG participants whether or not they think this > individual submission should be adopted as the corresponding MEXT work > item. Please answer to this note to state your opinion by Monday July > 28th. > > Thank you for your support, > > -- julien & marcelo, MEXT chairs > > > ------------------------------------------------------------------------ > > Subject: > I-D Action:draft-haley-mext-generic-signaling-message-01.txt > From: > Internet-Drafts@ietf.org > Date: > Fri, 11 Jul 2008 08:15:01 -0700 (PDT) > To: > i-d-announce@ietf.org > > To: > i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Mobile IPv6 Generic Signaling Message > Author(s) : B. Haley, S. Gundavelli > Filename : draft-haley-mext-generic-signaling-message-01.txt > Pages : 14 > Date : 2008-07-11 > > This document specifies two new Mobility Header message types that > allow Mobile IPv6 entities to send and receive generic signaling > messages. > > > > > > > > > > > > Haley > > > > > > Expires - December 2008 > > > > > [page 1] > > > > > Mobile IPv6 Generic Signaling Message > > July 2008 > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-haley-mext-generic-signaling-message-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > ------------------------------------------------------------------------ > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > --------------030309070309010602000306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Julien,

I support draft-muhanna-mext-binding-revocation to become a working group item and since this draft relays on "Generic Signaling Message for MIPv6" I also support this draft to become a working group item.

Regards
Conny

Julien Laganier wrote: 
Hello Folks,

The MEXT WG has a deliverable for a Generic Signaling Message for MIPv6. 

Hereby we'd like to ask WG participants whether or not they think this 
individual submission should be adopted as the corresponding MEXT work 
item. Please answer to this note to state your opinion by Monday July 
28th.

Thank you for your support,

-- julien & marcelo, MEXT chairs


Subject:
I-D Action:draft-haley-mext-generic-signaling-message-01.txt
From:
Internet-Drafts@ietf.org
Date:
Fri, 11 Jul 2008 08:15:01 -0700 (PDT)
To:
i-d-announce@ietf.org
To:
i-d-announce@ietf.org		 

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Mobile IPv6 Generic Signaling Message
	Author(s)       : B. Haley, S. Gundavelli
	Filename        : draft-haley-mext-generic-signaling-message-01.txt
	Pages           : 14
	Date            : 2008-07-11

This document specifies two new Mobility Header message types that
allow Mobile IPv6 entities to send and receive generic signaling
messages.











Haley





Expires - December 2008




[page 1]




 Mobile IPv6 Generic Signaling Message

 July 2008

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-haley-mext-generic-signaling-message-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
  

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
  

_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext
--------------030309070309010602000306-- --===============0006315430== 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 --===============0006315430==-- From asamblea20072008@gmail.com Sun Jul 20 08:48: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 241A73A6A71; Sun, 20 Jul 2008 08:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.236 X-Spam-Level: *** X-Spam-Status: No, score=3.236 tagged_above=-999 required=5 tests=[AWL=-0.802, BAYES_50=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 B1+BVkQBspv8; Sun, 20 Jul 2008 08:48:42 -0700 (PDT) Received: from avas-mr22.fibertel.com.ar (avas-mr22.fibertel.com.ar [24.232.0.139]) by core3.amsl.com (Postfix) with ESMTP id E300B3A6A42; Sun, 20 Jul 2008 08:48:41 -0700 (PDT) Received: from 200-127-4-67.cab.prima.net.ar ([200.127.4.67]:1594 "EHLO coloso" smtp-auth: "asamblea20072008" rhost-flags-OK-OK-OK-FAIL) by avas-mr22.fibertel.com.ar with ESMTPA id S419046AbYGTPtF convert rfc822-to-8bit; Sun, 20 Jul 2008 12:49:05 -0300 Message-ID: <386-220087020154839929@coloso> To: "MKT" Errors-to: asamblea20072008_@gmail.com From: "asamblea20072008" Subject: COMPUTADORA ATHLON $999 Date: Sun, 20 Jul 2008 12:48:40 -0300 MIME-Version: 1.0 Content-type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8BIT X-Fib-Al-Info: Al X-Fib-Al-MRId: 76dae43cdd6ecf9c0907d4838b13731e X-Fib-Al: noav X-Fib-Al-SA: analyzed X-Fib-Al-From: asamblea20072008@gmail.com COMPUTADORAS con 1 AÑO DE GARANTIA ENTREGA EN LOCAL EN LA ZONA DE CABALLITO - CAPITAL FEDERAL ENVIOS AL INTERIOR, PAGO CON TARJETA DE CREDITO DE MANERA TELEFONICA CREDITOS PERSONALES HASTA EN 36 CUOTAS FACTURA A o B CEL: 15-3197-5821 EMail: asamblea20072008@gmail.com -Modelo: ATHLON FIRE -Procesador: AMD ATHLON 64 DUAL CORE 4800+ Socket AM2 BOX -Motherboard: MSI K9N6GM-V chipset nVidia nForce 430 -Memoria: 1GB DDR2 667 -Placa de video: nVIDIA GeForce 6100GS 256MB -Disco rígido: 80 GB SATA2 -Medio optico: ReGrabadora de DVD PHILIPS 20X -Placa de red: 10/100 on board -Placa de sonido: 8 canales -Puertos: 2USB frontales + 4USB traseros -Gabinete: KIT CIRKUIT PLANET 1305 -Teclado multimedia, Mouse optico, Parlantes y Diskettera 3 ½. -Garantia 12 meses -Sistema operativo instalado y funcionando FULL, todos los programa y utilidades -PRECIO $999 From mext-bounces@ietf.org Mon Jul 21 03:18:46 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5952F3A68C0; Mon, 21 Jul 2008 03:18:46 -0700 (PDT) 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 8D2C63A68C4 for ; Mon, 21 Jul 2008 03:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgldQ6yMfXjc for ; Mon, 21 Jul 2008 03:18:44 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 8BAFD3A68C0 for ; Mon, 21 Jul 2008 03:18:44 -0700 (PDT) Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id CCCD47CB478; Mon, 21 Jul 2008 12:19:21 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Chan-Wah Ng Organization: Universidad Carlos III de Madrid Date: Mon, 21 Jul 2008 12:19:21 +0200 Message-Id: <1216635561.4539.45.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: mext Subject: [MEXT] Comments on draft-ng-nemo-ce-req-02.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1247285999==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1247285999== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-0jQajgn0J/6Xf/PtYx08" --=-0jQajgn0J/6Xf/PtYx08 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Chan-Wah, I've read last version of the CE NEMO RO Requirements draft and I have some minor comments. First of all, I found quite interesting the scenarios' descriptions. It quite useful to know what you consumer electronics manufacturers think it'd be deployed in the future and what optimisations need to be addressed. Regarding the content of the draft, I already sent some comments in the past based on a previous version of the draft. I'd like to add the following minor comments/questions: * Regarding Req4 (Protocol Harmony), IMHO a NEMO RO approach that is not able to operate with some protocols (I'm thinking in IPsec, which could be the most problematic) could also be OK, as long as the NEMO RO approach does not prevent these protocol to operate (following the bi-directional tunnel path). I'd say Req4 is a desired requirement. * Regarding Des4 (Separability), I think this should be a required characteristic (rather than a desired one), since trying to route optimise everything could be very suboptimal. Even if this is only statically configured, some communications should be allowed not to be optimised. Thanks, Carlos --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-0jQajgn0J/6Xf/PtYx08 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkiEYqkACgkQNdy6TdFwT2fUtgCfUL7wsAUCkxUqStohhHp2BSiS 3EUAniUDpBbjDPPHblIGsZcRHr043Ey8 =eA9q -----END PGP SIGNATURE----- --=-0jQajgn0J/6Xf/PtYx08-- --===============1247285999== 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 --===============1247285999==-- From mext-bounces@ietf.org Mon Jul 21 06:37:26 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFA0028C111; Mon, 21 Jul 2008 06:37:26 -0700 (PDT) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id DA03128C116; Mon, 21 Jul 2008 06:37:25 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20080721133725.DA03128C116@core3.amsl.com> Date: Mon, 21 Jul 2008 06:37:25 -0700 (PDT) Cc: mext mailing list , Internet Architecture Board , mext chair , RFC Editor Subject: [MEXT] Document Action: 'AAA Goals for Mobile IPv6' to Informational RFC 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 The IESG has approved the following document: - 'AAA Goals for Mobile IPv6 ' as an Informational RFC This document is the product of the Mobility EXTensions for IPv6 Working Group. The IESG contact persons are Jari Arkko and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-aaa-ha-goals-01.txt Technical Summary Mobile IPv6 provides the basic IP mobility functionality for IPv6. When Mobile IPv6 is used in tightly managed environments with the use of the AAA (Authentication, Authorization and Accounting) infrastructure, an interface between Mobile IPv6 and AAA protocols needs to be defined. Also, two scenarios for bootstrapping Mobile IPv6 service, i.e., split and integrated scenarios, require the specification of a message exchange between the HA and AAA infrastructure for authentication and authorization purposes and a message exchange between the AAA server and the NAS in order to provide the visited network with the necessary configuration information (e.g. Home Agent address). This document describes various scenarios where a AAA interface is required. Additionally, it lists design goals and requirements for the communication between the HA and the AAA server and the NAS and the AAA server needed in the split and integrated scenarios. Requirements are listed in case either IPsec or RFC 4285 is used for Mobile IPv6 authentication. This document only describes requirements, goals and scenarios. It does not provide solutions. Working Group Summary This is a product of the MEXT WG. Document Quality The document does not specify a protocol but a set of goals. As such there is no implementation of it, nor plans to implement it. There was however, a strong expression of interest in this document from the DIME WG which this document is an input to. There was a thorough review of the document from Hannes Tschofenig. Personnel The document shepherd is Marcelo Bagnulo. The responsible AD is Jari Arkko. RFC Editor Note In the abstract, change s/AAA/Authentication, Authorization, and Accounting (AAA)/ In section 4.2, change: s/AAAH/AAAH (AAA server in Home network)/ In Section 4.1 s/vailidity/validity/ In Section 4.2 s/The Home Agent can the assigned/The Home Agent can be assigned/ Also, make the following change: OLD: G4.4 The HA SHOULD be able to request the AAAH server to authenticate the MN with the value in the MN-AAA Mobility Message Authentication Option. NEW: G4.4 The HA supporting the Authentication Protocol MUST be able to request the AAAH server to authenticate the MN with the value in the MN-AAA Mobility Message Authentication Option. and the following: OLD: G6.3 The ASP/MSP SHOULD be able to indicate to the MSA if it can allocate a Home Agent to the MN. Therefore the NAS SHOULD be able to include suggested HA address in the ASP in the NAS - AAA interaction. NEW: G6.3 The ASP/MSP supporting the allocation of a Home Agent MUST be able to indicate to the MSA if it can allocate a Home Agent to the MN. Therefore the NAS MUST be able to include suggested HA address in the ASP in the NAS - AAA interaction. and finally, in Section 5.5, change: OLD: The AAAH SHOULD be able to indicate to the HA if the MN is authorized to autoconfigure its Home Address. NEW: The AAAH SHOULD be able to indicate to the HA if the MN is authorized to autoconfigure its Home Address. If the AAAH does not indicate to the HA if a MN is authorized to autoconfigure its address, the MN is not authorized. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 21 14:54:04 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48C233A68C6; Mon, 21 Jul 2008 14:54:04 -0700 (PDT) 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 75C803A68C6 for ; Mon, 21 Jul 2008 14:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.589 X-Spam-Level: X-Spam-Status: No, score=-6.589 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gSrwlUajiY1 for ; Mon, 21 Jul 2008 14:54:02 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 74D133A67F5 for ; Mon, 21 Jul 2008 14:54:02 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6LLsZN11796; Mon, 21 Jul 2008 21:54:36 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Jul 2008 16:54:31 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Binding Revocation Support Error handling Thread-Index: AcjrfEHuKYV9P9oQS1+Yqy5fsnAYLQ== From: "Ahmad Muhanna" To: Subject: [MEXT] Binding Revocation Support Error handling 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="===============1879026225==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============1879026225== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8EB7C.5BFCBCFE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8EB7C.5BFCBCFE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Hello All, =20 In preparation to Binding Revocation presentation, I came a cross the issue of error handling in the case when the receiving node does not support Binding Revocation. I am planning to touch on this during the Binding Revocation presentation. However, probably we can start discussion in preparation:)=20 =20 Currently, Binding Error is used to report that a specific MH type is not supported. However, with the introduction of MGSM with different signaling defined as subtypes, I feel that we probably need to define something more generic but specific to MGSM. =20 Thoughts Please? Regards,=20 Ahmad=20 =20 ------_=_NextPart_001_01C8EB7C.5BFCBCFE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hello=20 All,
 
In = preparation to=20 Binding Revocation presentation, I came a cross the issue of error = handling in=20 the case when the receiving node does not support Binding = Revocation. I am = planning to touch on=20 this during the Binding Revocation presentation. However, probably we = can start=20 discussion in preparation:) 
 
Currently, = Binding=20 Error is used to report that a specific MH type is not = supported.=20 However, with the introduction of MGSM with different signaling defined = as=20 subtypes, I feel that we probably need to define something more = generic but=20 specific to MGSM.
 
 Thoughts=20 Please?

Regards, =
Ahmad

 
------_=_NextPart_001_01C8EB7C.5BFCBCFE-- --===============1879026225== 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 --===============1879026225==-- From mext-bounces@ietf.org Mon Jul 21 15:01:57 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0701A3A68A5; Mon, 21 Jul 2008 15:01:57 -0700 (PDT) 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 CE7043A68A5 for ; Mon, 21 Jul 2008 15:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 xmAjkP6DSfyh for ; Mon, 21 Jul 2008 15:01:55 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id EF08D3A67E7 for ; Mon, 21 Jul 2008 15:01:54 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Jul 2008 18:02:28 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Binding Revocation Support Error handling Thread-Index: AcjrfEHuKYV9P9oQS1+Yqy5fsnAYLQAAJKqA References: From: "Vijay Devarapalli" To: "Ahmad Muhanna" , Subject: Re: [MEXT] Binding Revocation Support Error handling 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 My preference would be to add a new status code in section 4.3 of draft-haley-mext-generic-notification-message-00.txt to indicate an unknown sub-type. We can use 133 to indicate "Notification Sub-type not recognized". Vijay > -----Original Message----- > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > Sent: Monday, July 21, 2008 2:55 PM > To: mext@ietf.org > Cc: Brian Haley; Sri Gundavelli; Vijay Devarapalli > Subject: Binding Revocation Support Error handling > > > Hello All, > > In preparation to Binding Revocation presentation, I came a > cross the issue of error handling in the case when the > receiving node does not support Binding Revocation. I am > planning to touch on this during the Binding Revocation > presentation. However, probably we can start discussion in > preparation:) > > Currently, Binding Error is used to report that a specific MH > type is not supported. However, with the introduction of MGSM > with different signaling defined as subtypes, I feel that we > probably need to define something more generic but specific to MGSM. > > Thoughts Please? > > Regards, > Ahmad > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 21 15:06:45 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5BF33A6847; Mon, 21 Jul 2008 15:06:45 -0700 (PDT) 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 3F1FF3A6847 for ; Mon, 21 Jul 2008 15:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 5YIh8cq82lCp for ; Mon, 21 Jul 2008 15:06:44 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 6E32A3A6811 for ; Mon, 21 Jul 2008 15:06:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=qWKbQBdAQ+g5KREEcWK9J47wK0yC0yqU7GWfX6+66meao7+5DmE1kT5qw3Qnax/3; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [75.26.137.116] (helo=[10.166.255.89]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1KL3XO-0004w7-1i for mext@ietf.org; Mon, 21 Jul 2008 18:07:22 -0400 Message-ID: <4885088D.8000901@earthlink.net> Date: Mon, 21 Jul 2008 15:07:09 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: mext@ietf.org References: <487B7E10.1060906@earthlink.net> In-Reply-To: <487B7E10.1060906@earthlink.net> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f525d217e6ea34d8eb2b3b67dd3acc8f0ba350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Subject: Re: [MEXT] An unanswered question about "MIPv6 Generic Signaling Message" (MGSM) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello again folks, Apparently, any message could fit as a subtype of the proposed generic signaling message. This means that the proposal is too generic. I can't see any justification for this, given that so few of the basic message types have been used. There is no real indication that we are ever going to run out. If we had used 100 or even 50 of the message types already, I could see some justification for this extraordinarily generic approach. As it is, I think we ought to continue to utilize the basic message type space, and avoid the message overhead and the complication of yet another subtype space. Does anyone have any comparable example from another working group, where there was a desire to create a completely generic message type with subtypes, when the basic type numbering space was hardly touched? Regards, Charlie P. Charles E. Perkins wrote: > > Hello folks, > > A while back, I asked the following question: > >> Could you provide some examples of messages that >> would NOT fit as subtypes of the proposed generic >> signaling message? > > Does anyone have an answer to this question? I feel like I must be > missing some basic point here. > > Thanks in advance, > Charlie P. > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 21 15:40:05 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A8283A6833; Mon, 21 Jul 2008 15:40:05 -0700 (PDT) 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 25E543A6833 for ; Mon, 21 Jul 2008 15:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 nVilUjBxbYq8 for ; Mon, 21 Jul 2008 15:40:03 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 3FD383A67E7 for ; Mon, 21 Jul 2008 15:40:03 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Jul 2008 18:40:40 -0400 Message-ID: In-Reply-To: <20080721133725.DA03128C116@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Document Action: 'AAA Goals for Mobile IPv6' to Informational RFC Thread-Index: AcjrNwcwilNi/VH2TpGsV63AZBppWQASYwRg References: <20080721133725.DA03128C116@core3.amsl.com> From: "Vijay Devarapalli" To: "Jari Arkko" , "Giaretta, Gerardo" Cc: mext chair , mext mailing list Subject: Re: [MEXT] Document Action: 'AAA Goals for Mobile IPv6' to Informational RFC 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, Marcelo, Julien I have a couple of comments. > Also, make the following change: > OLD: > G4.4 The HA SHOULD be able to request the AAAH server to > authenticate the MN with the value in the MN-AAA Mobility Message > Authentication Option. > > NEW: > G4.4 The HA supporting the Authentication Protocol MUST be able > to request the AAAH server to authenticate the MN with the value > in the MN-AAA Mobility Message Authentication Option. We should add a reference to RFC 4285 here. It may not be immediately obvious what "Authentication Protocol" means. G4.4 The HA supporting the Authentication Protocol [5] MUST be able to request the AAAH server to authenticate the MN with the value in the MN-AAA Mobility Message Authentication Option. > and finally, in Section 5.5, change: > OLD: > The AAAH SHOULD be able to indicate to the HA if the MN is > authorized to autoconfigure its Home Address. > NEW: > The AAAH SHOULD be able to indicate to the HA if the MN is > authorized to autoconfigure its Home Address. > If the AAAH does not indicate to the HA if a MN is authorized to > autoconfigure its address, the MN is not authorized. I am not sure why we need the second sentence. For those systems that require AAA authorization before the MN is allowed to auto-configure its home address, it is ok to have the above requirement. But it should be possible for a system to use home address auto-configuration without any indication from the AAA on how the address should be configured. Instead, the last sentence reads as if the home agent does not allow the MN to auto-configure its home address unless the AAA server says it is ok. If someone can forward the IESG discussion related to this change, it would be great. I thought about this requirement a little bit more. Perhaps we should delete it. A mobile node being allowed to auto-configure a home address depends on how the home link is configured. The home agent can allow/disallow this based on configuration. I don't think the AAA server should care about whether the MN is allowed to auto-configure a home address. Comments? Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 21 15:53:52 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E95E3A6877; Mon, 21 Jul 2008 15:53:52 -0700 (PDT) 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 4D2133A6877 for ; Mon, 21 Jul 2008 15:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23dn7aqq-lVO for ; Mon, 21 Jul 2008 15:53:50 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 1D2163A67E7 for ; Mon, 21 Jul 2008 15:53:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,226,1215388800"; d="scan'208";a="55776619" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 21 Jul 2008 22:54:28 +0000 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 m6LMsRsG021248; Mon, 21 Jul 2008 15:54:27 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m6LMsRVk011328; Mon, 21 Jul 2008 22:54:27 GMT Date: Mon, 21 Jul 2008 15:54:27 -0700 (PDT) From: Sri Gundavelli To: "Charles E. Perkins" In-Reply-To: <4885088D.8000901@earthlink.net> Message-ID: References: <487B7E10.1060906@earthlink.net> <4885088D.8000901@earthlink.net> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3260; t=1216680867; x=1217544867; c=relaxed/simple; s=sjdkim3002; 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]=20An=20unanswered=20question=20a bout=20=22MIPv6=20Generic=20Signaling=0A=20Message=22=20(MGS M) |Sender:=20; bh=8vSXrGe07KQahRSlc0G/axvyeB16zLEZoNwdxXv5FOY=; b=PSvDk+4sJTfNKAdGih9aIvckWQstHma/FuPAKZS5U3LY36+GlWI+1JlrdF Prcao3s1XTyGyYhfxPdkTTD49Yqw9LUiT/c7JF4mK5g8KkD7ajHu7w0Q3nb6 Aqc25jcfs2; 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] An unanswered question about "MIPv6 Generic Signaling Message" (MGSM) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Charlie, There is a long thread on this topic and was discussed in the WG extensively prior to entering this work into the charter. Few points: - Its not just about saving MH Types. That is a very minor aspect. - The goal is to create a message that can be used for different event types. All the considerations related to transport, session identification, firewall considerations, security considerations, IPv4/NAT traversals ..etc, all should be specified just for this message and all of this apply to all the events. - Any new message has to only define the reciever actions for that specific message, without the need to define any of the above considerations for each and every message. - There was a recent discussion on the validity of the Auth Option in a message other than a BU/BA and it was considered not valid. Defining new options for a MGSM message will allow its use for all events. - It appears this is just about saving MH types, its not. When we start defining a new event, that draft has to deal with all the above considerations. If that event leverages the Generic Notification work, the focus of the draft is contained to the event details and sender/receiver considerations. If we can see the flow Session is created Event-1 Event-2 Session is terminated All those events associated within a session have common properties, there is no reason to float new messages, there is some value in using this generic message. Hope this helps. Regards Sri On Mon, 21 Jul 2008, Charles E. Perkins wrote: > Hello again folks, > > Apparently, any message could fit as a subtype > of the proposed generic signaling message. > > This means that the proposal is too generic. > > I can't see any justification for this, given that > so few of the basic message types have been > used. There is no real indication that we are > ever going to run out. > > If we had used 100 or even 50 of the message > types already, I could see some justification > for this extraordinarily generic approach. As it > is, I think we ought to continue to utilize the > basic message type space, and avoid the > message overhead and the complication of > yet another subtype space. > > Does anyone have any comparable example > from another working group, where there > was a desire to create a completely generic > message type with subtypes, when the basic > type numbering space was hardly touched? > > Regards, > Charlie P. > > > > Charles E. Perkins wrote: >> >> Hello folks, >> >> A while back, I asked the following question: >> >> > Could you provide some examples of messages that >> > would NOT fit as subtypes of the proposed generic >> > signaling message? >> >> Does anyone have an answer to this question? I feel like I must be >> missing some basic point here. >> >> Thanks in advance, >> Charlie P. >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 21 16:07:18 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B54713A6A05; Mon, 21 Jul 2008 16:07:18 -0700 (PDT) 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 352AC28C1C7 for ; Mon, 21 Jul 2008 16:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.529 X-Spam-Level: X-Spam-Status: No, score=-6.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDSkq7DOt3hW for ; Mon, 21 Jul 2008 16:07:16 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 402F928C1C6 for ; Mon, 21 Jul 2008 16:07:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,226,1215388800"; d="scan'208";a="88796266" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 21 Jul 2008 23:07:53 +0000 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 m6LN7r4p005411; Mon, 21 Jul 2008 16:07:53 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6LN7q4A020515; Mon, 21 Jul 2008 23:07:52 GMT Date: Mon, 21 Jul 2008 16:07:52 -0700 (PDT) From: Sri Gundavelli To: Vijay Devarapalli In-Reply-To: Message-ID: References: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1264; t=1216681673; x=1217545673; c=relaxed/simple; s=sjdkim4002; 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=20Binding=20Revocation=20Support=20Error= 20handling=20 |Sender:=20; bh=OLu5Hr7WsEuSpP/jOSdLxTu/dUzfBxgEA0Njh27ocVo=; b=RHEBn7NNKUsB2AyELbP9NEan3rL3OPhGUMZes48EOoIblhnclWh+3Y6cVJ sTIHSxBLfkSIvSnaH3To00kNp7VcqwpshIfevYnYP/XKGAehZUxxmG2a0vRU 06qqjniyO+; 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] Binding Revocation Support Error handling 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Makes sense. Sri On Mon, 21 Jul 2008, Vijay Devarapalli wrote: > My preference would be to add a new status code in section 4.3 of > draft-haley-mext-generic-notification-message-00.txt to indicate an > unknown sub-type. We can use 133 to indicate "Notification Sub-type not > recognized". > > Vijay > >> -----Original Message----- >> From: Ahmad Muhanna [mailto:amuhanna@nortel.com] >> Sent: Monday, July 21, 2008 2:55 PM >> To: mext@ietf.org >> Cc: Brian Haley; Sri Gundavelli; Vijay Devarapalli >> Subject: Binding Revocation Support Error handling >> >> >> Hello All, >> >> In preparation to Binding Revocation presentation, I came a >> cross the issue of error handling in the case when the >> receiving node does not support Binding Revocation. I am >> planning to touch on this during the Binding Revocation >> presentation. However, probably we can start discussion in >> preparation:) >> >> Currently, Binding Error is used to report that a specific MH >> type is not supported. However, with the introduction of MGSM >> with different signaling defined as subtypes, I feel that we >> probably need to define something more generic but specific to MGSM. >> >> Thoughts Please? >> >> Regards, >> Ahmad >> >> > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 21 17:34:05 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D88EF3A6833; Mon, 21 Jul 2008 17:34:05 -0700 (PDT) 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 616813A6833 for ; Mon, 21 Jul 2008 17:34:04 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7Q76ZbcePzB for ; Mon, 21 Jul 2008 17:34:03 -0700 (PDT) Received: from web33501.mail.mud.yahoo.com (web33501.mail.mud.yahoo.com [68.142.206.150]) by core3.amsl.com (Postfix) with SMTP id 379813A67E7 for ; Mon, 21 Jul 2008 17:34:03 -0700 (PDT) Received: (qmail 64773 invoked by uid 60001); 22 Jul 2008 00:34:21 -0000 Received: from [210.94.41.89] by web33501.mail.mud.yahoo.com via HTTP; Mon, 21 Jul 2008 17:34:19 PDT X-RocketYMMF: uxaanurag X-Mailer: YahooMailRC/1042.40 YahooMailWebService/0.7.218 Date: Mon, 21 Jul 2008 17:34:19 -0700 (PDT) From: Anurag Uxa To: Vijay Devarapalli , Ahmad Muhanna , mext@ietf.org MIME-Version: 1.0 Message-ID: <156979.64696.qm@web33501.mail.mud.yahoo.com> Subject: Re: [MEXT] Binding Revocation Support Error handling X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anurag Uxa 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 It will be good. I think along with error handling if we can think of MTU n= egotiation prior to create tunnel between FA & HA it will be good. ----- Original Message ---- > From: Vijay Devarapalli > To: Ahmad Muhanna ; mext@ietf.org > Sent: Tuesday, July 22, 2008 7:02:28 AM > Subject: Re: [MEXT] Binding Revocation Support Error handling > = > My preference would be to add a new status code in section 4.3 of > draft-haley-mext-generic-notification-message-00.txt to indicate an > unknown sub-type. We can use 133 to indicate "Notification Sub-type not > recognized". > = > Vijay > = > > -----Original Message----- > > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] = > > Sent: Monday, July 21, 2008 2:55 PM > > To: mext@ietf.org > > Cc: Brian Haley; Sri Gundavelli; Vijay Devarapalli > > Subject: Binding Revocation Support Error handling = > > = > >=A0 = > > Hello All, > >=A0 = > > In preparation to Binding Revocation presentation, I came a = > > cross the issue of error handling in the case when the = > > receiving node does not support Binding Revocation. I am = > > planning to touch on this during the Binding Revocation = > > presentation. However, probably we can start discussion in = > > preparation:) = > >=A0 = > > Currently, Binding Error is used to report that a specific MH = > > type is not supported. However, with the introduction of MGSM = > > with different signaling defined as subtypes, I feel that we = > > probably need to define something more generic but specific to MGSM. > >=A0 = > >=A0 Thoughts Please? > > = > > Regards, = > > Ahmad = > > = > > = > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > = > ______________________________________________________________________ > = > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email = > ______________________________________________________________________ = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 21 21:38:55 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C4C23A6913; Mon, 21 Jul 2008 21:38:55 -0700 (PDT) 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 04E023A6913 for ; Mon, 21 Jul 2008 21:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATLfbtZSRlol for ; Mon, 21 Jul 2008 21:38:52 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 6CF813A6885 for ; Mon, 21 Jul 2008 21:38:51 -0700 (PDT) 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 m6M4dUEM025172; Tue, 22 Jul 2008 13:39:30 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb2) with ESMTP id m6M4dU323025; Tue, 22 Jul 2008 13:39:30 +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 m6M4dV127522; Tue, 22 Jul 2008 13:39:31 +0900 (JST) Received: from ncc1701e.sg.panasonic.com ([10.81.113.10]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 12:37:50 +0800 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ncc1701e.sg.panasonic.com (Postfix) with ESMTP id 610F7264E224; Tue, 22 Jul 2008 12:38:12 +0800 (SGT) From: Chan-Wah Ng To: cjbc@it.uc3m.es In-Reply-To: <1216635561.4539.45.camel@localhost> References: <1216635561.4539.45.camel@localhost> Date: Tue, 22 Jul 2008 12:38:12 +0800 Message-Id: <1216701492.7067.8.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 X-OriginalArrivalTime: 22 Jul 2008 04:37:50.0999 (UTC) FILETIME=[B3029270:01C8EBB4] Cc: mext Subject: Re: [MEXT] Comments on draft-ng-nemo-ce-req-02.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="utf-8" Content-Transfer-Encoding: base64 Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org SGVsbG8gQ2FybG9zLAoKVGhhbmtzIGZvciB0aGUgY29tbWVudHMuCgpPbiBNb24sIDIwMDgtMDct MjEgYXQgMTI6MTkgKzAyMDAsIENhcmxvcyBKZXPDunMgQmVybmFyZG9zIENhbm8gd3JvdGU6IAo+ IEhpIENoYW4tV2FoLAo+IAo+IAlJJ3ZlIHJlYWQgbGFzdCB2ZXJzaW9uIG9mIHRoZSBDRSBORU1P IFJPIFJlcXVpcmVtZW50cyBkcmFmdCBhbmQgSSBoYXZlCj4gc29tZSBtaW5vciBjb21tZW50cy4K PiAKPiAJRmlyc3Qgb2YgYWxsLCBJIGZvdW5kIHF1aXRlIGludGVyZXN0aW5nIHRoZSBzY2VuYXJp b3MnIGRlc2NyaXB0aW9ucy4gSXQKPiBxdWl0ZSB1c2VmdWwgdG8ga25vdyB3aGF0IHlvdSBjb25z dW1lciBlbGVjdHJvbmljcyBtYW51ZmFjdHVyZXJzIHRoaW5rCj4gaXQnZCBiZSBkZXBsb3llZCBp biB0aGUgZnV0dXJlIGFuZCB3aGF0IG9wdGltaXNhdGlvbnMgbmVlZCB0byBiZQo+IGFkZHJlc3Nl ZC4KPiAKPiAJUmVnYXJkaW5nIHRoZSBjb250ZW50IG9mIHRoZSBkcmFmdCwgSSBhbHJlYWR5IHNl bnQgc29tZSBjb21tZW50cyBpbiB0aGUKPiBwYXN0IGJhc2VkIG9uIGEgcHJldmlvdXMgdmVyc2lv biBvZiB0aGUgZHJhZnQuIEknZCBsaWtlIHRvIGFkZCB0aGUKPiBmb2xsb3dpbmcgbWlub3IgY29t bWVudHMvcXVlc3Rpb25zOgo+IAo+IAkqIFJlZ2FyZGluZyBSZXE0IChQcm90b2NvbCBIYXJtb255 KSwgSU1ITyBhIE5FTU8gUk8gYXBwcm9hY2ggdGhhdCBpcwo+IG5vdCBhYmxlIHRvIG9wZXJhdGUg d2l0aCBzb21lIHByb3RvY29scyAoSSdtIHRoaW5raW5nIGluIElQc2VjLCB3aGljaAo+IGNvdWxk IGJlIHRoZSBtb3N0IHByb2JsZW1hdGljKSBjb3VsZCBhbHNvIGJlIE9LLCBhcyBsb25nIGFzIHRo ZSBORU1PIFJPCj4gYXBwcm9hY2ggZG9lcyBub3QgcHJldmVudCB0aGVzZSBwcm90b2NvbCB0byBv cGVyYXRlIChmb2xsb3dpbmcgdGhlCj4gYmktZGlyZWN0aW9uYWwgdHVubmVsIHBhdGgpLiBJJ2Qg c2F5IFJlcTQgaXMgYSBkZXNpcmVkIHJlcXVpcmVtZW50Lgo+IAoKVGhlIHByb2JsZW0gaGVyZSBp cyBob3cgZG9lcyB0aGUgTVIvTU4ga25vd3Mgd2hpY2ggcHJvdG9jb2wgaXMKc3VwcG9zZWRseSBi cm9rZW4gYnkgUk8/ICBUaGUgY29uc3VtZXIgZWxlY3Ryb25pY3MgY2Fubm90IHJlbHkgb24gYQpl eHBlcmllbmNlL2tub3dsZWRnZWFibGUgdXNlci4gIElmIFJPIHN0YXJ0cyBicmVha2luZyBjZXJ0 YWluIHByb3RvY29scwpmb3IgdGhlbSAoZWcgSVBTZWMgd2hpbGUgdGhleSB0cnkgdG8gYWNjZXNz IGNvbXBhbnkncyBWUE4pLCB0aGV5IHdpbGwKZGl0Y2ggdGhlIE1SIGFuZCBidXkgYW5vdGhlciBv bmUuCgpFdmVuIGlmIHRoZSBNUiBrbm93cywgaG93IE1SIGtub3dzIHdoaWNoIHByb3RvY29sIHRo ZSBNTk4gaXMgcnVubmluZwp0aGVuPyAgSXQgaXMgbXVjaCBzYWZlciwgSU1ITywgdG8gc3RyaWN0 bHkgaW5zaXN0IG9uIHByb3RvY29sIGhhcm1vbnkuCgo+IAkqIFJlZ2FyZGluZyBEZXM0IChTZXBh cmFiaWxpdHkpLCBJIHRoaW5rIHRoaXMgc2hvdWxkIGJlIGEgcmVxdWlyZWQKPiBjaGFyYWN0ZXJp c3RpYyAocmF0aGVyIHRoYW4gYSBkZXNpcmVkIG9uZSksIHNpbmNlIHRyeWluZyB0byByb3V0ZQo+ IG9wdGltaXNlIGV2ZXJ5dGhpbmcgY291bGQgYmUgdmVyeSBzdWJvcHRpbWFsLiBFdmVuIGlmIHRo aXMgaXMgb25seQo+IHN0YXRpY2FsbHkgY29uZmlndXJlZCwgc29tZSBjb21tdW5pY2F0aW9ucyBz aG91bGQgYmUgYWxsb3dlZCBub3QgdG8gYmUKPiBvcHRpbWlzZWQuCgpQb3NzaWJseS4gIFRoaXMg bWF5IGdldCBhIGxpdHRsZSB0cmlja3kgb24gaG93IGRvZXMgdGhlIE1SIGlkZW50aWZpZXMKZmxv d3MgZnJvbSBNTk4gaW4gb3JkZXIgdG8gc2VwYXJhdGUgdGhlbS4KCi9yZ2RzCi9jd25nIAoKCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCk1FWFQgbWFpbGlu ZyBsaXN0Ck1FWFRAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tZXh0Cg== From mext-bounces@ietf.org Tue Jul 22 00:32:18 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12B443A689D; Tue, 22 Jul 2008 00:32:18 -0700 (PDT) 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 F25213A689D for ; Tue, 22 Jul 2008 00:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfR0crRgVjuV for ; Tue, 22 Jul 2008 00:32:16 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id CD6383A6885 for ; Tue, 22 Jul 2008 00:32:15 -0700 (PDT) Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id B4746490434; Tue, 22 Jul 2008 09:32:54 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Chan-Wah Ng In-Reply-To: <1216701492.7067.8.camel@localhost> References: <1216635561.4539.45.camel@localhost> <1216701492.7067.8.camel@localhost> Organization: Universidad Carlos III de Madrid Date: Tue, 22 Jul 2008 09:32:54 +0200 Message-Id: <1216711974.4539.120.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: mext Subject: Re: [MEXT] Comments on draft-ng-nemo-ce-req-02.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0120886384==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0120886384== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-eeaXwn1q3C481TAgHY2L" --=-eeaXwn1q3C481TAgHY2L Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Chan Wah, El mar, 22-07-2008 a las 12:38 +0800, Chan-Wah Ng escribi=F3: > Hello Carlos, >=20 > Thanks for the comments. >=20 > On Mon, 2008-07-21 at 12:19 +0200, Carlos Jes=FAs Bernardos Cano wrote:=20 > > Hi Chan-Wah, > >=20 > > I've read last version of the CE NEMO RO Requirements draft and I have > > some minor comments. > >=20 > > First of all, I found quite interesting the scenarios' descriptions. I= t > > quite useful to know what you consumer electronics manufacturers think > > it'd be deployed in the future and what optimisations need to be > > addressed. > >=20 > > Regarding the content of the draft, I already sent some comments in th= e > > past based on a previous version of the draft. I'd like to add the > > following minor comments/questions: > >=20 > > * Regarding Req4 (Protocol Harmony), IMHO a NEMO RO approach that is > > not able to operate with some protocols (I'm thinking in IPsec, which > > could be the most problematic) could also be OK, as long as the NEMO RO > > approach does not prevent these protocol to operate (following the > > bi-directional tunnel path). I'd say Req4 is a desired requirement. > >=20 >=20 > The problem here is how does the MR/MN knows which protocol is > supposedly broken by RO? The consumer electronics cannot rely on a > experience/knowledgeable user. If RO starts breaking certain protocols > for them (eg IPSec while they try to access company's VPN), they will > ditch the MR and buy another one. >=20 > Even if the MR knows, how MR knows which protocol the MNN is running > then? It is much safer, IMHO, to strictly insist on protocol harmony. I'm looking at this requirement assuming that Des4 is also a required characteristic. With this in mind, the MR has to decide (based on operator/user configuration) which flows have to be route optimised. Then it's very simple for the MR not to try to optimise those communications (if any) that make use of protocols that are broken by the NEMO RO solution. In this way, the MR would not break any communication, just it would not be able to optimise some. >=20 > > * Regarding Des4 (Separability), I think this should be a required > > characteristic (rather than a desired one), since trying to route > > optimise everything could be very suboptimal. Even if this is only > > statically configured, some communications should be allowed not to be > > optimised. >=20 > Possibly. This may get a little tricky on how does the MR identifies > flows from MNN in order to separate them. Well, I think current devices (NATs, firewalls, etc.) deal with flow identification quite well Kind Regards, Carlos >=20 > /rgds > /cwng=20 >=20 >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-eeaXwn1q3C481TAgHY2L Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkiFjSYACgkQNdy6TdFwT2dBoQCg49rzSTzrSyT42JeK9SfMrVo7 E6EAn0kWLhT7342E1Nlub20Ukbm8oNeo =I05o -----END PGP SIGNATURE----- --=-eeaXwn1q3C481TAgHY2L-- --===============0120886384== 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 --===============0120886384==-- From mext-bounces@ietf.org Tue Jul 22 04:07:28 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 100FB3A6846; Tue, 22 Jul 2008 04:07:28 -0700 (PDT) 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 3F20F3A6846 for ; Tue, 22 Jul 2008 04:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id casJMluEyl9p for ; Tue, 22 Jul 2008 04:07:26 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id D59DE3A683F for ; Tue, 22 Jul 2008 04:07:25 -0700 (PDT) Received: from dummyhost19.it.uc3m.es (unknown [163.117.139.225])by smtp01.uc3m.es (Postfix) with ESMTP id BFD1E7D1E58;Tue, 22 Jul 2008 13:08:01 +0200 (CEST) Message-ID: <4885BF91.6080907@it.uc3m.es> Date: Tue, 22 Jul 2008 13:08:01 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: "Christian.Bauer@dlr.de" , Serkan.Ayaz@dlr.de, mext X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-6.9297 TC:1F TRN:44 TV:5.5.1026(16046.006) 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] draft-bauer-mext-aero-topology-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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, thanks for writing this, i think it is very useful to understand the problem in more detail some questions - how many ACSPs can a given MR be connected to simultaneously? You say that there are two global ACSPs, do they cover both all the globe or each of them cover half of the globe, so that you can only connect to one at the time? - in section 3.1.2. ATS/AOS CNs it reads: The CNs mentioned here are the communication peers from the IP point of view and do not necessarily have to be and might usually not be the "real" end system. what does this means? what is the real end system? - I don't understand this: 3.1.3. MNNs The MNNs of the ATS and AOS domains on board an aircraft are, as mentioned in [I-D.ietf-mext-aero-reqs], LFNs and potentially even LMNs. A LMN is a node that is running MIPv6 and that its HA is located in the NEMO, so how you expect to have LMNs? Do you expect that running a HA in the aircraft will be a usual practice? - section 3.4. Location of Home Agents reads: An important discussion is the location of the HA(s) that is also directly related to the advertisement of the MNPs. There are two possible options: 1. An airline has a HA which is serving the aircraft belonging to that airline. 2. One of the global ACSPs provides HA(s) for the airline if they have an agreement with them. The second choice is more reasonable for two reasons. First, for airlines having a relatively small number of aircraft it will not be cost effective to deploy HA(s), Why do you say that? I mean, do you think that running a HA is expensive? I mean, i would certainly expect that an airline can afford running a HA, doesn't seem to cpllex to me... in opposite to the ACSP that can act as a Mobility Service Provider. Second if the HA(s) are deployed at the ACSP and a local mobility management protocol like [I-D.ietf-netlmm-proxymip6] is deployed the aircraft will be "at home" as long as it is directly attached to that ACSP (as in Figure 2) and hence there will be no tunnelling overhead from the MR point of view. but, i don't understand how would this interact with nemo ro... I mean, if you have pmip, wouldn't that be enogh, since you cna optimize the path within the ACSP? I mean, if the ACSP is global, then the aircraft never needs to leave the ACSP, hence we don't need nemo ro, we only need pmip, don't we? or are you thinking to use nemo ro when you leave the acsp? - later on in section 3.5. Trust Relationships reads Certificates can be assumed between the aircraft and the ACSP, at least for the one acting as Mobility Services Provider. you mean X509 digital certificates right? (i mean it seems somehow confusing cause you also talk about certififed services, which i guess means soemthing else? So, who is the CA for these certificates? Can we assume that all the aircrafts trust the CA that has issues these certifcates? what about crl or any other form of stauts validation? is this needed? who provides this? _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 22 06:19:06 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C6013A69A9; Tue, 22 Jul 2008 06:19:06 -0700 (PDT) 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 ECAF53A69C0 for ; Tue, 22 Jul 2008 06:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.59 X-Spam-Level: X-Spam-Status: No, score=-6.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PwRnyRERov4 for ; Tue, 22 Jul 2008 06:19:04 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id D81003A69A9 for ; Tue, 22 Jul 2008 06:19:03 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6MDJeX17971; Tue, 22 Jul 2008 13:19:40 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Jul 2008 08:19:32 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Binding Revocation Support Error handling Thread-Index: AcjrfEHuKYV9P9oQS1+Yqy5fsnAYLQAAJKqAAB/03fA= References: From: "Ahmad Muhanna" To: "Vijay Devarapalli" , Subject: Re: [MEXT] Binding Revocation Support Error handling 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 Vijay, That could work. I also was thinking that probably an approach similar to Binding Err would be more elegant:) What I mean, it would be nice if the MGSM framework define a separate subtype for reporting errors related to the MGSM signaling. Just an idea to consider. Regards, Ahmad > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay@wichorus.com] > Sent: Monday, July 21, 2008 5:02 PM > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org > Cc: Brian Haley; Sri Gundavelli > Subject: RE: Binding Revocation Support Error handling > > My preference would be to add a new status code in section > 4.3 of draft-haley-mext-generic-notification-message-00.txt > to indicate an unknown sub-type. We can use 133 to indicate > "Notification Sub-type not recognized". > > Vijay > > > -----Original Message----- > > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > Sent: Monday, July 21, 2008 2:55 PM > > To: mext@ietf.org > > Cc: Brian Haley; Sri Gundavelli; Vijay Devarapalli > > Subject: Binding Revocation Support Error handling > > > > > > Hello All, > > > > In preparation to Binding Revocation presentation, I came a > cross the > > issue of error handling in the case when the receiving node > does not > > support Binding Revocation. I am planning to touch on this > during the > > Binding Revocation presentation. However, probably we can start > > discussion in > > preparation:) > > > > Currently, Binding Error is used to report that a specific > MH type is > > not supported. However, with the introduction of MGSM with > different > > signaling defined as subtypes, I feel that we probably need > to define > > something more generic but specific to MGSM. > > > > Thoughts Please? > > > > Regards, > > Ahmad > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 22 07:24:51 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50E3F3A6A47; Tue, 22 Jul 2008 07:24:51 -0700 (PDT) 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 C57903A6A47 for ; Tue, 22 Jul 2008 07:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.734 X-Spam-Level: X-Spam-Status: No, score=-3.734 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9CzNbyegZUb for ; Tue, 22 Jul 2008 07:24:48 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 9ED8C3A6A20 for ; Tue, 22 Jul 2008 07:24:48 -0700 (PDT) Received: from dummyhost19.it.uc3m.es (unknown [163.117.139.225])by smtp02.uc3m.es (Postfix) with ESMTP id D4655421F3E;Tue, 22 Jul 2008 16:25:27 +0200 (CEST) Message-ID: <4885EDD7.8020101@it.uc3m.es> Date: Tue, 22 Jul 2008 16:25:27 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Ryuji Wakikawa X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-6.1555 TC:1F TRN:31 TV:5.5.1026(16046.007) 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 Subject: [MEXT] draft-wakikawa-mext-cr-consideration-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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ryuji, thanks for writing this down i think this is exactly the disucssion we need to have at this point. Some questions: in section 2.1. Triggering Route Optimization you state: The home agent distribution such as the global HAHA [ID-HAHAINTEROP] [ID-HAHA] is much simpler. The mobile router or the mobile node are not involving the route optimization trigger. The trigger is given by the home agent. But, the HA is also a middle box so the same problems that apply to the CR/MR based ro triggering applies to the HA. I mean, how do you configure the policies int he HA? (i understadn that in the same way you configure them in the CR) As i see it, the HA approach is simpler cause you always do RO, in the sense that you always use the MNN-MR-HA-HA-CN path, whcih is always as optimum as the HAHA approach provides, or am i missing something? Later on, it reads: 2.3. Registering Binding to Correspondent Router The Correspondent Router and the mobile router are not belong to the same administrative domain, there are several security concerns. I don't think this is a concern in the aviation case, since we have assumed that it is posible to establish trust between the MR and a mobility anchor point near to the CN, so this shouldn't be an issues (or at least we have assumed that this is not an issue) similarly with the rest of the issues in this section. If the trust can be assumed, i think these are non issues. later on, it states: MR-CR Route Management: Therefore, even if one direction is optimized, there is no guarantee that the reverse path is also optimized (Figure 2). I don't understand how this could happen I understand that asymmetric routing is quite common, but mostly in the core. I fail to see how a you could end up with a non optimized path in only one direction and i fail to see how you could possibly do better. Could you expand on this, for instance with an example of topology that would end up in this situation? regards, marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 22 07:57:26 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2017F3A6A58; Tue, 22 Jul 2008 07:57:26 -0700 (PDT) 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 808E23A6A71 for ; Tue, 22 Jul 2008 07:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.155 X-Spam-Level: X-Spam-Status: No, score=-5.155 tagged_above=-999 required=5 tests=[AWL=1.444, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1X4QBfRALyv for ; Tue, 22 Jul 2008 07:57:23 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 8F7C03A6A53 for ; Tue, 22 Jul 2008 07:57:23 -0700 (PDT) Received: from dummyhost19.it.uc3m.es (unknown [163.117.139.225])by smtp02.uc3m.es (Postfix) with ESMTP id C4283421FC0for ; Tue, 22 Jul 2008 16:58:01 +0200 (CEST) Message-ID: <4885F579.4060707@it.uc3m.es> Date: Tue, 22 Jul 2008 16:58:01 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: mext X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-5.7345 TC:1F TRN:13 TV:5.5.1026(16046.007) 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] ad-hoc meeting for nemo ro for aviation 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi all, We are organizing a small ad-hoc meeting in dublin to discuss nemo ro for the aviation case. The meeting is set for TUESDAY, July 29, 2008 from 17:00 till 20:00 Please, send an email to the chairs if you would be interested in actively participating (i.e., the room has limited capacity) in such an ad-hoc meeting. Regards, Julien and marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 22 08:22:01 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 714DF3A6A82; Tue, 22 Jul 2008 08:22:01 -0700 (PDT) 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 7E7E53A6A73 for ; Tue, 22 Jul 2008 08:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.857 X-Spam-Level: X-Spam-Status: No, score=-3.857 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxTxCfbtQ5N2 for ; Tue, 22 Jul 2008 08:21:58 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id F00A03A6A74 for ; Tue, 22 Jul 2008 08:21:22 -0700 (PDT) Received: from dummyhost19.it.uc3m.es (unknown [163.117.139.225])by smtp01.uc3m.es (Postfix) with ESMTP id 01AA87D2FB6;Tue, 22 Jul 2008 17:22:02 +0200 (CEST) Message-ID: <4885FB19.5080609@it.uc3m.es> Date: Tue, 22 Jul 2008 17:22:01 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Ryuji Wakikawa , mext X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-10.0967 TC:1F TRN:31 TV:5.5.1026(16048.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] draft-wakikawa-mext-haha-interop2008-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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, again, good document, this is very good input for the disucssion this is very clear and short description of the status of global haha I recommend people to take a few minutes and read this cause it is a very input for the discussion. one thing that i am missing here is an analysis of the issues/concerns/limitations of the approach. Of the top of my head, i have a few questions right away. Would the deployment model of the global haha would be compatible with the avaiation model described in draft-bauer-mext-aero-topology-00? I mean, in draft-bauer-mext-aero-topology-00, we have multiple ACSPs, and several ANSP and in order to obtain the ro benefits all of them should have a HA in them and then the assumption that all has are in the same admin domain will not hold any longer, i think. wouldn't this be an issue? An additional issue pointed out by Jari in the Madrid meeting is that if there is only direct connectivity between the CN and the MR and there is no connectivity with the rest of the infrastrcuture, the haha approach wouldn't work, which seems an additional liability than the CR approach. I think it would make sense to try to summarize all the pros and cons to have a good discussion. one question: In section 3. Global HAHA Protocol it reads Routing Packets (3-4, 9-10 in Figure 2) The packets originated by the mobile node are always routed through the primary home agent as shown in Figure 2. They are tunneled to the primary home agent to which the mobile node is currently registering and, then, routed directly to the CN. The primary home agent does not have the state of the correspondent node and cannot forward the packets to the closest home agent of the correspondent node. So, does this means that the haha approach does not optimize the path for packets flowing from the MN to the CN? From the draft it seems that the haha appraoch only optimizes the traffic from the CN to the MR, but i think i am misunderstanding something here... _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 22 08:26:39 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F6D33A69F2; Tue, 22 Jul 2008 08:26:39 -0700 (PDT) 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 B5D383A69F2 for ; Tue, 22 Jul 2008 08:26:37 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AJsBpIRjjqK for ; Tue, 22 Jul 2008 08:26:36 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by core3.amsl.com (Postfix) with ESMTP id 739603A6979 for ; Tue, 22 Jul 2008 08:26:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,231,1215381600"; d="vcf'?scan'208";a="13355724" Received: from dhcp-rocq-52.inria.fr ([128.93.62.52]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Jul 2008 17:27:13 +0200 Message-ID: <4885FC45.4080605@inria.fr> Date: Tue, 22 Jul 2008 17:27:01 +0200 From: Thierry Ernst Organization: INRIA User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: marcelo bagnulo braun References: <4885BF91.6080907@it.uc3m.es> In-Reply-To: <4885BF91.6080907@it.uc3m.es> Content-Type: multipart/mixed; boundary="------------060200000103070804060303" Cc: Serkan.Ayaz@dlr.de, "Christian.Bauer@dlr.de" , mext Subject: Re: [MEXT] draft-bauer-mext-aero-topology-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: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --------------060200000103070804060303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > > > 1. An airline has a HA which is serving the aircraft belonging to > > that airline. > > > > 2. One of the global ACSPs provides HA(s) for the airline if they > > have an agreement with them. > > > > The second choice is more reasonable for two reasons. First, for > > airlines having a relatively small number of aircraft it will not be > > cost effective to deploy HA(s), > > Why do you say that? I mean, do you think that running a HA is > expensive? I mean, i would certainly expect that an airline can afford > running a HA, doesn't seem to cpllex to me... I low-cost company typically doesn't have the skills and resources to run such kind of service and would rather rely on a third party. The cost of running the service will probably be a function of the number of HAs. In addition, charter airlines don't know where they are flying to. Here again they might more probably outsource their HA service (as all Internet services indeed). Thierry. --------------060200000103070804060303 Content-Type: text/x-vcard; charset=utf-8; name="thierry_ernst.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="thierry_ernst.vcf" begin:vcard fn:Thierry Ernst n:Ernst;Thierry org:INRIA Rocquencourt;IMARA - LARA adr:;;;;;;France tel;work:+33 1 39 63 59 30 tel;fax:+33 1 39 63 54 91 tel;cell:+33 6 76 56 25 96 url:http://www.lara.prd.fr version:2.1 end:vcard --------------060200000103070804060303 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 --------------060200000103070804060303-- From mext-bounces@ietf.org Tue Jul 22 08:38:44 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5FA73A6A5F; Tue, 22 Jul 2008 08:38:44 -0700 (PDT) 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 0B4B03A6A53 for ; Tue, 22 Jul 2008 08:38:44 -0700 (PDT) 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_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZZKNqdVNL-5 for ; Tue, 22 Jul 2008 08:38:40 -0700 (PDT) Received: from smtp-2.dlr.de (smtp-3.dlr.de [195.37.61.187]) by core3.amsl.com (Postfix) with ESMTP id EF7263A6A2F for ; Tue, 22 Jul 2008 08:38:39 -0700 (PDT) Received: from exbe04.intra.dlr.de ([192.168.35.37]) by smtp-2.dlr.de with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 17:39:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Jul 2008 17:38:46 +0200 Message-ID: In-Reply-To: <4885FB19.5080609@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] draft-wakikawa-mext-haha-interop2008-00.txt thread-index: AcjsDuUe9y2rRgNNQemBLDuvz7HJVgAAZZsQ References: <4885FB19.5080609@it.uc3m.es> From: To: , , X-OriginalArrivalTime: 22 Jul 2008 15:39:18.0491 (UTC) FILETIME=[1A9942B0:01C8EC11] Subject: Re: [MEXT] draft-wakikawa-mext-haha-interop2008-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, > one question: > > In section 3. Global HAHA Protocol it reads > > Routing Packets (3-4, 9-10 in Figure 2) > > The packets originated by the mobile node are always routed through > the primary home agent as shown in Figure 2. They are tunneled to > the primary home agent to which the mobile node is currently > registering and, then, routed directly to the CN. The primary home > agent does not have the state of the correspondent node and cannot > forward the packets to the closest home agent of the correspondent > node. > > So, does this means that the haha approach does not optimize the path > for packets flowing from the MN to the CN? > From the draft it seems that the haha appraoch only optimizes the > traffic from the CN to the MR, but i think i am misunderstanding > something here... I guess traffic to the MR still has to be routed over the primary HA, and not over the one who receives the packets from the CN, because the MR has an IPsec/IKEv2 session with only this primary HA? At least until the HA switch message has been received and properly processed at the MR... Christian _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 22 11:22:58 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49F203A6972; Tue, 22 Jul 2008 11:22:58 -0700 (PDT) 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 437F03A6881 for ; Tue, 22 Jul 2008 11:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 u8jc9GOVPIX5 for ; Tue, 22 Jul 2008 11:22:55 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id B6DCA3A6972 for ; Tue, 22 Jul 2008 11:22:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=b1qdEFbapX0MKQi7rtT3GLV2r5uwV49tJmBTX1bwzbc6TgEEtOpQNVLVTdArAELj; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [75.26.137.116] (helo=[10.166.255.25]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1KLMWK-00079N-FD; Tue, 22 Jul 2008 14:23:32 -0400 Message-ID: <488625A0.2050908@earthlink.net> Date: Tue, 22 Jul 2008 11:23:28 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Sri Gundavelli References: <487B7E10.1060906@earthlink.net> <4885088D.8000901@earthlink.net> In-Reply-To: X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52f11ed4bb23fa259b7c2d8439c0e38ef6350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Cc: mext@ietf.org Subject: Re: [MEXT] An unanswered question about "MIPv6 Generic Signaling Message" (MGSM) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Sri, Your message caused me to go back and re-read a LOT of messages on this subject. Eventually, I had to stop before getting through all of them. It's a challenging assignment, which I reckon few people would complete. Nevertheless I got a very good feel for the main ideas. Your message seemed to indicate that my concerns had already been discussed and were missing the point of the MGSM draft. I did find some messages in support of that position, but I found quite numerous messages with general questions about the approach. So in my mind the question is really not at all settled. Furthermore, the IPv6 draft I was able to find has expired. Maybe there is another one that I did not find yet. Or, maybe your comments were really more oriented towards the IPv4 version of the draft. But the IPv6 draft does not support your following text: > - The goal is to create a message that can be used > for different event types. All the considerations related > to transport, session identification, firewall considerations, > security considerations, IPv4/NAT traversals ..etc, all > should be specified just for this message and all of this > apply to all the events. Those considerations are not covered in the IPv6 draft. But, what the heck, let's just assume that they could be. But, on the other hand, they are not covered in the IPv4 document either. Actually, it seems that the transport considerations are limited to retransmissions, and only the IPv6 document has that. Or, maybe you intended some of them to be covered implicitly by enabling the use of certain mobility extensions. But that was not stated either, in either the IPv4 or the IPv6 draft. Sri Gundavelli wrote: > > - Its not just about saving MH Types. That is a very > minor aspect. O.K. > > > - Any new message has to only define the reciever > actions for that specific message, without the need > to define any of the above considerations for each > and every message. Until we have the considerations, that's sort of a moot point. Plus, once we have them, it might turn out that they don't all apply to all messages. But, again, if they do, they belong in the base document. > > - There was a recent discussion on the validity of the > Auth Option in a message other than a BU/BA and it > was considered not valid. Defining new options for a > MGSM message will allow its use for all events. Well, it would be easier and better to define the use of the Auth Option for various messages as they are specified. In fact, limiting the Binding Authentication Data to only BU/BA was already against my better judgment, and I acceded only because of the threat of drastically more delay by the IESG. Do you think the IESG would be more friendly towards enabling the use of the Auth Option for a _completely_ generic message format??(?) I really don't see that. > > - It appears this is just about saving MH types, its > not. When we start defining a new event, that draft > has to deal with all the above considerations. If > that event leverages the Generic Notification work, > the focus of the draft is contained to the event > details and sender/receiver considerations. If we can > see the flow > > Session is created > Event-1 > Event-2 > Session is terminated This doesn't narrow it down at all! > > All those events associated within a session have common > properties, there is no reason to float new messages, > there is some value in using this generic message. I also don't believe any part of this (sorry to be so skeptical, but I hope you don't mind if I state my honest opinion). Regards, Charlie P. > > On Mon, 21 Jul 2008, Charles E. Perkins wrote: > >> Hello again folks, >> >> Apparently, any message could fit as a subtype >> of the proposed generic signaling message. >> >> This means that the proposal is too generic. >> >> I can't see any justification for this, given that >> so few of the basic message types have been >> used. There is no real indication that we are >> ever going to run out. >> >> If we had used 100 or even 50 of the message >> types already, I could see some justification >> for this extraordinarily generic approach. As it >> is, I think we ought to continue to utilize the >> basic message type space, and avoid the >> message overhead and the complication of >> yet another subtype space. >> >> Does anyone have any comparable example >> from another working group, where there >> was a desire to create a completely generic >> message type with subtypes, when the basic >> type numbering space was hardly touched? >> >> Regards, >> Charlie P. >> >> >> >> Charles E. Perkins wrote: >>> >>> Hello folks, >>> >>> A while back, I asked the following question: >>> >>> > Could you provide some examples of messages that >>> > would NOT fit as subtypes of the proposed generic >>> > signaling message? >>> >>> Does anyone have an answer to this question? I feel like I must be >>> missing some basic point here. >>> _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 22 12:23:50 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 655C63A69A4; Tue, 22 Jul 2008 12:23:50 -0700 (PDT) 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 5E68E3A69A4 for ; Tue, 22 Jul 2008 12:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 HOGu0CBuADKQ for ; Tue, 22 Jul 2008 12:23:48 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 142C73A6965 for ; Tue, 22 Jul 2008 12:23:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ahGBgq5mdUIDJWNlOOkWW+wcRm0FYgjVWNP/DbfW6pLUemuVnhtemv/TVlDQ6Jkb; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [75.26.137.116] (helo=[10.166.255.25]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1KLNTJ-0001OJ-DH; Tue, 22 Jul 2008 15:24:29 -0400 Message-ID: <488633EA.5030806@earthlink.net> Date: Tue, 22 Jul 2008 12:24:26 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Sri Gundavelli References: <487B7E10.1060906@earthlink.net> <4885088D.8000901@earthlink.net> <488625A0.2050908@earthlink.net> In-Reply-To: <488625A0.2050908@earthlink.net> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5208707d96a66371b8a8cdcd8feb31ac72350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Cc: mext@ietf.org Subject: Re: [MEXT] An unanswered question about "MIPv6 Generic Signaling Message" (MGSM) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello again Sri, I found the new draft: http://tools.ietf.org/id/draft-haley-mext-generic-notification-message-00.txt I scanned through it, and it doesn't seem to be very much different regarding the issues that I raised in my email from earlier this morning. I still didn't find any discussion about firewalls or NATs, for instance. Regards, Charlie P. Charles E. Perkins wrote: > > Hello Sri, > > Your message caused me to go back and re-read a > LOT of messages on this subject. Eventually, I had to > stop before getting through all of them. It's a challenging > assignment, which I reckon few people would complete. > > Nevertheless I got a very good feel for the main ideas. > Your message seemed to indicate that my concerns had > already been discussed and were missing the point of > the MGSM draft. I did find some messages in support > of that position, but I found quite numerous messages with > general questions about the approach. So in my mind > the question is really not at all settled. > > Furthermore, the IPv6 draft I was able to find has > expired. Maybe there is another one that I did not > find yet. Or, maybe your comments were really more > oriented towards the IPv4 version of the draft. > But the IPv6 draft does not support your following text: > > > >> - The goal is to create a message that can be used >> for different event types. All the considerations related >> to transport, session identification, firewall considerations, >> security considerations, IPv4/NAT traversals ..etc, all >> should be specified just for this message and all of this >> apply to all the events. > > > Those considerations are not covered in the IPv6 > draft. But, what the heck, let's just assume that they > could be. But, on the other hand, they are not > covered in the IPv4 document either. Actually, > it seems that the transport considerations are limited > to retransmissions, and only the IPv6 document > has that. Or, maybe you intended some of them > to be covered implicitly by enabling the use of > certain mobility extensions. But that was not > stated either, in either the IPv4 or the IPv6 draft. > > > > Sri Gundavelli wrote: >> >> - Its not just about saving MH Types. That is a very >> minor aspect. > > O.K. >> >> >> - Any new message has to only define the reciever >> actions for that specific message, without the need >> to define any of the above considerations for each >> and every message. > > > Until we have the considerations, that's sort of a > moot point. Plus, once we have them, it might turn > out that they don't all apply to all messages. But, again, > if they do, they belong in the base document. > > >> >> - There was a recent discussion on the validity of the >> Auth Option in a message other than a BU/BA and it >> was considered not valid. Defining new options for a >> MGSM message will allow its use for all events. > > Well, it would be easier and better to define the use of > the Auth Option for various messages as they are > specified. In fact, limiting the Binding Authentication Data > to only BU/BA was already against my better judgment, > and I acceded only because of the threat of drastically > more delay by the IESG. Do you think the IESG would > be more friendly towards enabling the use of the Auth > Option for a _completely_ generic message format??(?) > > I really don't see that. > > >> >> - It appears this is just about saving MH types, its >> not. When we start defining a new event, that draft >> has to deal with all the above considerations. If >> that event leverages the Generic Notification work, >> the focus of the draft is contained to the event >> details and sender/receiver considerations. If we can >> see the flow >> >> Session is created >> Event-1 >> Event-2 >> Session is terminated > > This doesn't narrow it down at all! > >> >> All those events associated within a session have common >> properties, there is no reason to float new messages, >> there is some value in using this generic message. > > I also don't believe any part of this (sorry to be > so skeptical, but I hope you don't mind if I state > my honest opinion). > > Regards, > Charlie P. > >> >> On Mon, 21 Jul 2008, Charles E. Perkins wrote: >> >>> Hello again folks, >>> >>> Apparently, any message could fit as a subtype >>> of the proposed generic signaling message. >>> >>> This means that the proposal is too generic. >>> >>> I can't see any justification for this, given that >>> so few of the basic message types have been >>> used. There is no real indication that we are >>> ever going to run out. >>> >>> If we had used 100 or even 50 of the message >>> types already, I could see some justification >>> for this extraordinarily generic approach. As it >>> is, I think we ought to continue to utilize the >>> basic message type space, and avoid the >>> message overhead and the complication of >>> yet another subtype space. >>> >>> Does anyone have any comparable example >>> from another working group, where there >>> was a desire to create a completely generic >>> message type with subtypes, when the basic >>> type numbering space was hardly touched? >>> >>> Regards, >>> Charlie P. >>> >>> >>> >>> Charles E. Perkins wrote: >>>> >>>> Hello folks, >>>> >>>> A while back, I asked the following question: >>>> >>>> > Could you provide some examples of messages that >>>> > would NOT fit as subtypes of the proposed generic >>>> > signaling message? >>>> >>>> Does anyone have an answer to this question? I feel like I must be >>>> missing some basic point here. >>>> > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 22 15:59:52 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 102B33A69BA; Tue, 22 Jul 2008 15:59:52 -0700 (PDT) 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 217803A68BE for ; Tue, 22 Jul 2008 15:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.531 X-Spam-Level: X-Spam-Status: No, score=-6.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-pY4SijCeEm for ; Tue, 22 Jul 2008 15:59:49 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id E28B23A6862 for ; Tue, 22 Jul 2008 15:59:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,234,1215388800"; d="scan'208";a="56303350" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 22 Jul 2008 23:00:31 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6MN0VIs028238; Tue, 22 Jul 2008 16:00:31 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6MN0VUd025195; Tue, 22 Jul 2008 23:00:31 GMT Date: Tue, 22 Jul 2008 16:00:31 -0700 (PDT) From: Sri Gundavelli To: "Charles E. Perkins" In-Reply-To: <488625A0.2050908@earthlink.net> Message-ID: References: <487B7E10.1060906@earthlink.net> <4885088D.8000901@earthlink.net> <488625A0.2050908@earthlink.net> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3680; t=1216767631; x=1217631631; c=relaxed/simple; s=sjdkim1004; 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]=20An=20unanswered=20question=20a bout=20=22MIPv6=20Generic=20Signaling=0A=20Message=22=20(MGS M) |Sender:=20; bh=Y/PZdoOX651It5RSfhmXJfZPC5zSTVEnzHJNmdBa2IY=; b=H17D2SfQAu46dNS40G3/k31kpr8btaS3HQS6hXYImHFS3JxxYFHOONON1p vtmkLShHf0OTBZNAVnOQW8jEOnOmQWBHEDOaPHVTiEuHsnZcHkS/s9Ulb6PZ IlzVheUO6mn+vhNKIqyP2gvumQrpjbWMwzsXtNKM7sZajNzLhIZpg=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] An unanswered question about "MIPv6 Generic Signaling Message" (MGSM) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Charlie, On Tue, 22 Jul 2008, Charles E. Perkins wrote: > > Hello Sri, > > Your message caused me to go back and re-read a > LOT of messages on this subject. Eventually, I had to > stop before getting through all of them. It's a challenging > assignment, which I reckon few people would complete. > > Nevertheless I got a very good feel for the main ideas. > Your message seemed to indicate that my concerns had > already been discussed and were missing the point of > the MGSM draft. I did find some messages in support > of that position, but I found quite numerous messages with > general questions about the approach. So in my mind > the question is really not at all settled. > > Furthermore, the IPv6 draft I was able to find has > expired. Maybe there is another one that I did not > find yet. Or, maybe your comments were really more > oriented towards the IPv4 version of the draft. > But the IPv6 draft does not support your following text: > Ok. The draft requires additional considerations. Thats a fair comment and agreed. No questions there. If the IPv6 or the IPv4 draft failed to do a good job, it should not imply the requirement or the need for a generic message disappears. Your feedback can help us improve the draft. >> - There was a recent discussion on the validity of the >> Auth Option in a message other than a BU/BA and it >> was considered not valid. Defining new options for a >> MGSM message will allow its use for all events. > > Well, it would be easier and better to define the use of > the Auth Option for various messages as they are > specified. In fact, limiting the Binding Authentication Data > to only BU/BA was already against my better judgment, > and I acceded only because of the threat of drastically > more delay by the IESG. Do you think the IESG would > be more friendly towards enabling the use of the Auth > Option for a _completely_ generic message format??(?) > Absolutely. I believe so. An option that is defined for a Generic Notification message will be valid for all notification messages that leverages that semantic. IESG should not have a problem with it. There is no need to define MN-Id, Auth Option, IPv4 HoA option for all events and ratify their use for future events. Once defined for generic notification message, its valid for all events that uses that mechanism. We could have avoided the issue related to Auth Option, had we defined the Generic Notification message earlier and made it valid for that message. I dont see much value in repeating all the common considerations for every notification that we define. What out of the above considertions will really change between an LMA going-down event or some other event. If I relate to SNMP, SMI, we will be defining different Trap PDU formats for every event. Why should every draft that defines an event associated with a mobility session, go into the details of defining IPsec PAD considerations or how the message should be transported ...etc. Why should every event should have an impact on a firewall considerations ? There is a mobility session that got created and that session can be identified using parameters X,Y,Z (based on CMIP or PMIP, HoA or MN-Id...), considerations are fixed. Transport and IPsec/PAD considerations are fixed. What is not fixed is the event properties, event meta-data and the receiver and sender actions. Why should we not abstract the common properties and provide a generic container and offer generic semantics. If SDO like 3GPP wants to use its vendor specific events, the same semantics can be used. Regards Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 22 22:25:04 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99BB53A6A20; Tue, 22 Jul 2008 22:25:04 -0700 (PDT) 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 0A3833A6A20 for ; Tue, 22 Jul 2008 22:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.59 X-Spam-Level: X-Spam-Status: No, score=-6.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JG2xwx5PvHoz for ; Tue, 22 Jul 2008 22:25:03 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id B55153A684F for ; Tue, 22 Jul 2008 22:25:02 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6N5PfS27742; Wed, 23 Jul 2008 05:25:41 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Jul 2008 00:24:54 -0500 Message-ID: In-Reply-To: <488625A0.2050908@earthlink.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] An unanswered question about "MIPv6 Generic Signaling Message" (MGSM) Thread-Index: AcjsKBgTuD/xxgV9RTOUb626u37N8QAUgTug References: <487B7E10.1060906@earthlink.net> <4885088D.8000901@earthlink.net> <488625A0.2050908@earthlink.net> From: "Ahmad Muhanna" To: "Charles E. Perkins" Cc: mext@ietf.org Subject: Re: [MEXT] An unanswered question about "MIPv6 Generic Signaling Message" (MGSM) 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 Charlie, Please allow me to comment on one of your points below. Regards, Ahmad > > - It appears this is just about saving MH types, its not. When we > > start defining a new event, that draft has to deal with all > the above > > considerations. If that event leverages the Generic > Notification work, > > the focus of the draft is contained to the event details and > > sender/receiver considerations. If we can see the flow > > > > Session is created > > Event-1 > > Event-2 > > Session is terminated > > This doesn't narrow it down at all! > > > > > All those events associated within a session have common > properties, > > there is no reason to float new messages, there is some > value in using > > this generic message. > > I also don't believe any part of this (sorry to be so > skeptical, but I hope you don't mind if I state my honest opinion). [Ahmad] I believe the wg chairs declared consensus on the topic "Mobile IPv6 Generic Signaling Message" which I supported and still respect despite some attempts to always refer to other than what has been agreed on. Probably different understanding of the meaning of "Agreement or Consensus". Putting this aside, I totally agree with what you just said. I share the same opinion. It does not make sense that we can come up with this generic signaling message that is so generic to capture every event that would ever be needed for a mobility session. The proof for this is: if we go back not far, but less than 3 months, we will find different versions of the scope of this generic container thing documented on this ml and still evolving:) Not only that, but, for example, the fact that a BU with lifetime of zero is considered OUTSIDE the scope of this Generic signaling while a revocation message which accomplish the same impact on the BCE is?! This concept of PLUG-N-PLAY signaling framework:) IMO, does not necessarily stand on strong legs! I believe some of us just missed the MIP6 BU/BA with few years, otherwise, we would have had all kind of messages in a single generic container with one security requirement:) In relation to the Auth protocol, thus far all the discussion is related to messages that impact sessions that were created using a Client MIP6 BU/BA. But I believe you are making a very good point, that the security requirement can not be captured as part of the generic message. On the contrary, it should be specific to the event itself. Simply because the generic framework is supposed to be so generic that captures all possible signaling/events that would ever happen to a mobility session and can concentrate on, for example, retransmission of the message. (Although, different events may require different retransmission timeouts) Therefore, those events can not have the same security requirements. I believe your point is also related to the discussion regarding secure vs. a non-secure message, but your comment rang a strong sounding bell and somehow connected the dots! During that discussion it was suggested to use two MH to be assigned to IPsec and Non-IPsec messages hoping by that we be generic enough to have one security which fit the generic signaling message framework. BTW: other interpretations believe those MH types are for Secure and Non-secure (means no security measures at all). Best Regards, Ahmad > > Regards, > Charlie P. > > > > > On Mon, 21 Jul 2008, Charles E. Perkins wrote: > > > >> Hello again folks, > >> > >> Apparently, any message could fit as a subtype of the proposed > >> generic signaling message. > >> > >> This means that the proposal is too generic. > >> > >> I can't see any justification for this, given that so few of the > >> basic message types have been used. There is no real > indication that > >> we are ever going to run out. > >> > >> If we had used 100 or even 50 of the message types > already, I could > >> see some justification for this extraordinarily generic > approach. As > >> it is, I think we ought to continue to utilize the basic > message type > >> space, and avoid the message overhead and the complication of yet > >> another subtype space. > >> > >> Does anyone have any comparable example from another > working group, > >> where there was a desire to create a completely generic > message type > >> with subtypes, when the basic type numbering space was hardly > >> touched? > >> > >> Regards, > >> Charlie P. > >> > >> > >> > >> Charles E. Perkins wrote: > >>> > >>> Hello folks, > >>> > >>> A while back, I asked the following question: > >>> > >>> > Could you provide some examples of messages that > would NOT fit > >>> > as subtypes of the proposed generic signaling message? > >>> > >>> Does anyone have an answer to this question? I feel > like I must be > >>> missing some basic point here. > >>> > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://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 Jul 23 13:53:10 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75CDD3A6A6E; Wed, 23 Jul 2008 13:53:10 -0700 (PDT) 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 8CA043A6802; Wed, 23 Jul 2008 13:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 1uFnjqk0DNAK; Wed, 23 Jul 2008 13:53:07 -0700 (PDT) Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id 8F7A13A6781; Wed, 23 Jul 2008 13:53:07 -0700 (PDT) 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 1KLlLE-0000Uk-3G; Wed, 23 Jul 2008 22:53:44 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: MEXT IETF WG , IPsec IETF WG User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) X-Hashcash: 1:20:080723:mext@ietf.org::qlZXP/T5W/01KakR:00006WUZ X-Hashcash: 1:20:080723:ipsec@ietf.org::2GoUKpuZm5uRit7W:00022rc X-Hashcash: 1:20:080723:louis.granboulan@eads.net::ccUv8cJholm6Tp3E:0000000000000000000000000000000000001YGh X-Hashcash: 1:20:080723:cedric.blancher@eads.net::z0DMHlV6sxw/Ingr:00000000000000000000000000000000000006mx4 X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 Date: Wed, 23 Jul 2008 22:53:01 +0200 Message-ID: <87hcag1fwy.fsf@natisbad.org> MIME-Version: 1.0 Subject: [MEXT] Mobile IPv6 and IPsec/IKE 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="===============0083069584==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0083069584== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Hi, [apologies for those who are on both lists] For those interested by *practical* deployment of MIPv6 with IPsec/IKE under Linux, I have written a page describing how to set things up. It is available here: http://natisbad.org/MIPv6/index.html It is based on an improved version of MIGRATE draft (resulting from discussions with the authors). This is the first version of the page and some parts are still under construction, so, be gentle. If you have comments, bug reports or ideas, do not hesitate. Cheers, a+ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIh5otAlWVfAR6UCYRAvnzAKCN4GYnLVNUqVeO4DxKQUXi+rrmcQCcDaZp ZNpKH4Lj4D+mU5p2chibhDc= =JFKW -----END PGP SIGNATURE----- --=-=-=-- --===============0083069584== 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 --===============0083069584==-- From mext-bounces@ietf.org Wed Jul 23 14:29:43 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABB993A67DF; Wed, 23 Jul 2008 14:29:43 -0700 (PDT) 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 82B223A6832 for ; Wed, 23 Jul 2008 14:29:42 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lk8zuFtZuWuW for ; Wed, 23 Jul 2008 14:29:41 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 9C0DF3A67DF for ; Wed, 23 Jul 2008 14:29:41 -0700 (PDT) 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 m6NLOnHX012143; Wed, 23 Jul 2008 16:30:23 -0500 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Jul 2008 00:29:59 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 16:29:57 -0500 Received: from 172.19.60.169 ([172.19.60.169]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 23 Jul 2008 21:29:57 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Wed, 23 Jul 2008 16:29:58 -0500 From: Basavaraj Patil To: ext Arnaud Ebalard , MEXT IETF WG Message-ID: Thread-Topic: [MEXT] Mobile IPv6 and IPsec/IKE Thread-Index: AcjtC0GJQ5qcdNXmm0eUK2MnzezUpg== In-Reply-To: <87hcag1fwy.fsf@natisbad.org> Mime-version: 1.0 X-OriginalArrivalTime: 23 Jul 2008 21:29:57.0182 (UTC) FILETIME=[410C7DE0:01C8ED0B] X-Nokia-AV: Clean Subject: Re: [MEXT] Mobile IPv6 and IPsec/IKE 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 Useful document. Now if only support for IKEv2 can also be added :) -Raj On 7/23/08 3:53 PM, "ext Arnaud Ebalard" wrote: > Hi, [apologies for those who are on both lists] > > For those interested by *practical* deployment of MIPv6 with IPsec/IKE > under Linux, I have written a page describing how to set things up. It > is available here: > > http://natisbad.org/MIPv6/index.html > > It is based on an improved version of MIGRATE draft (resulting from > discussions with the authors). > > This is the first version of the page and some parts are still under > construction, so, be gentle. If you have comments, bug reports or > ideas, do not hesitate. > > Cheers, > > a+ > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://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 Jul 23 16:13:02 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 965413A68D0; Wed, 23 Jul 2008 16:13:02 -0700 (PDT) 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 BA5773A6809 for ; Wed, 23 Jul 2008 16:13:01 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bta94B3xoo2A for ; Wed, 23 Jul 2008 16:13:00 -0700 (PDT) Received: from sd-1637.dedibox.fr (sd-1637.dedibox.fr [88.191.18.91]) by core3.amsl.com (Postfix) with ESMTP id 4F4FB3A6887 for ; Wed, 23 Jul 2008 16:13:00 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sd-1637.dedibox.fr (Postfix) with ESMTP id BE874A3CF2; Thu, 24 Jul 2008 01:13:42 +0200 (CEST) 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 wgqd76UnSOvJ; Thu, 24 Jul 2008 01:13:39 +0200 (CEST) Received: from [192.168.1.102] (p2233-ipbf1203hodogaya.kanagawa.ocn.ne.jp [122.24.153.233]) by sd-1637.dedibox.fr (Postfix) with ESMTP id DDCFAA3C20; Thu, 24 Jul 2008 01:13:37 +0200 (CEST) Message-ID: <4887BB1E.5000207@hongo.wide.ad.jp> Date: Thu, 24 Jul 2008 08:13:34 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Basavaraj Patil References: In-Reply-To: X-Enigmail-Version: 0.95.6 Cc: MEXT IETF WG Subject: Re: [MEXT] Mobile IPv6 and IPsec/IKE 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-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, If you are looking for similar information for ikev2, please look at: http://www.nautilus6.org/doc/dk-howto/Howto_dynamic_keying.html It may be a little outdated now, but it should be useful anyway. PS: Sorry for the poor presentation ^^ Sebastien. Basavaraj Patil a =E9crit : > Useful document. Now if only support for IKEv2 can also be added :) > = > -Raj > = > = > = > On 7/23/08 3:53 PM, "ext Arnaud Ebalard" wrote: > = >> Hi, [apologies for those who are on both lists] >> >> For those interested by *practical* deployment of MIPv6 with IPsec/IKE >> under Linux, I have written a page describing how to set things up. It >> is available here: >> >> http://natisbad.org/MIPv6/index.html >> >> It is based on an improved version of MIGRATE draft (resulting from >> discussions with the authors). >> >> This is the first version of the page and some parts are still under >> construction, so, be gentle. If you have comments, bug reports or >> ideas, do not hesitate. >> >> Cheers, >> >> a+ >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > = > _______________________________________________ > 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 Wed Jul 23 20:28:51 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3302D3A69F4; Wed, 23 Jul 2008 20:28:51 -0700 (PDT) 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 123C93A69E6 for ; Wed, 23 Jul 2008 20:28:50 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QdrnmxMIMkm for ; Wed, 23 Jul 2008 20:28:49 -0700 (PDT) Received: from komaba.jp.toyota-itc.com (komaba.jp.toyota-itc.com [IPv6:2001:268:124:1::143]) by core3.amsl.com (Postfix) with ESMTP id DA4D03A69C0 for ; Wed, 23 Jul 2008 20:28:48 -0700 (PDT) Received: from [192.168.119.177] ([192.168.119.177]) (authenticated bits=0) by komaba.jp.toyota-itc.com (8.13.6/8.13.6) with ESMTP id m6N82HWO009534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jul 2008 17:02:17 +0900 (JST) (envelope-from ryuji.wakikawa@gmail.com) Message-ID: <4886E551.6070200@gmail.com> Date: Wed, 23 Jul 2008 17:01:21 +0900 From: Ryuji Wakikawa User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: marcelo bagnulo braun References: <4885FB19.5080609@it.uc3m.es> In-Reply-To: <4885FB19.5080609@it.uc3m.es> Cc: mext Subject: Re: [MEXT] draft-wakikawa-mext-haha-interop2008-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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Marcelo, Thanks for comments! again;-) arcelo bagnulo braun wrote: > Hi, > > again, good document, this is very good input for the disucssion > > this is very clear and short description of the status of global haha > > I recommend people to take a few minutes and read this cause it is a > very input for the discussion. > > one thing that i am missing here is an analysis of the > issues/concerns/limitations of the approach. > > Of the top of my head, i have a few questions right away. Would the > deployment model of the global haha would be compatible with the > avaiation model described in draft-bauer-mext-aero-topology-00? > I mean, in draft-bauer-mext-aero-topology-00, we have multiple ACSPs, > and several ANSP and in order to obtain the ro benefits all of them > should have a HA in them and then the assumption that all has are in > the same admin domain will not hold any longer, i think. wouldn't this > be an issue? I didn't read that doc in detail yet.. let me answer these questions later. > An additional issue pointed out by Jari in the Madrid meeting is that > if there is only direct connectivity between the CN and the MR and > there is no connectivity with the rest of the infrastrcuture, the haha > approach wouldn't work, which seems an additional liability than the > CR approach. Well, in such case, how can you utilize CR for that? Before RO, NEMO requires home binding registration. If there is no reachability to HA, it's impossible to make communication from MR. I don't think this is an issue here... > I think it would make sense to try to summarize all the pros and cons > to have a good discussion. I agree. > one question: > > In section 3. Global HAHA Protocol it reads > > Routing Packets (3-4, 9-10 in Figure 2) > > The packets originated by the mobile node are always routed through > the primary home agent as shown in Figure 2. They are tunneled to > the primary home agent to which the mobile node is currently > registering and, then, routed directly to the CN. The primary home > agent does not have the state of the correspondent node and cannot > forward the packets to the closest home agent of the correspondent > node. > > So, does this means that the haha approach does not optimize the path > for packets flowing from the MN to the CN? > From the draft it seems that the haha appraoch only optimizes the > traffic from the CN to the MR, but i think i am misunderstanding > something here... Since MR is always associated with the closest HA, the path between the primary HA and MR is shorten. In addition, when the primary HA routes packets to CN, the packets are routed along the regular IP routing path. This path must be the most optimized path on the Internet. (This is what MIP6 RO provides) regards, ryuji _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jul 23 20:28:52 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B40A83A6A13; Wed, 23 Jul 2008 20:28:52 -0700 (PDT) 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 A34FB3A6A13 for ; Wed, 23 Jul 2008 20:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8l3EJiBN69NL for ; Wed, 23 Jul 2008 20:28:50 -0700 (PDT) Received: from komaba.jp.toyota-itc.com (komaba.jp.toyota-itc.com [IPv6:2001:268:124:1::143]) by core3.amsl.com (Postfix) with ESMTP id 1B0BD3A69C0 for ; Wed, 23 Jul 2008 20:28:49 -0700 (PDT) Received: from [192.168.119.177] ([192.168.119.177]) (authenticated bits=0) by komaba.jp.toyota-itc.com (8.13.6/8.13.6) with ESMTP id m6N7V8t8009220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jul 2008 16:31:19 +0900 (JST) (envelope-from ryuji.wakikawa@gmail.com) Message-ID: <4886DE04.9010403@gmail.com> Date: Wed, 23 Jul 2008 16:30:12 +0900 From: Ryuji Wakikawa User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: marcelo bagnulo braun References: <4885EDD7.8020101@it.uc3m.es> In-Reply-To: <4885EDD7.8020101@it.uc3m.es> Cc: mext Subject: Re: [MEXT] draft-wakikawa-mext-cr-consideration-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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Marcelo, Thanks for your comments. marcelo bagnulo braun wrote: > Hi Ryuji, > > thanks for writing this down > i think this is exactly the disucssion we need to have at this point. > > Some questions: > > in section 2.1. Triggering Route Optimization you state: > > The home agent distribution such as the global HAHA [ID-HAHAINTEROP] > [ID-HAHA] is much simpler. The mobile router or the mobile node are > not involving the route optimization trigger. The trigger is given > by the home agent. > > But, the HA is also a middle box so the same problems that apply to > the CR/MR based ro triggering applies to the HA. I mean, how do you > configure the policies int he HA? (i understadn that in the same way > you configure them in the CR) right. Currently, in globalHAHA, RO states are always exchanged and no dynamic. We can also design a global HAHA with the similar triggering issue of CR;-) > > As i see it, the HA approach is simpler cause you always do RO, in the > sense that you always use the MNN-MR-HA-HA-CN path, whcih is always as > optimum as the HAHA approach provides, or am i missing something? after writing my comment above, i found the same answer here:-) > > Later on, it reads: > > 2.3. Registering Binding to Correspondent Router > > The Correspondent Router and the mobile router are not belong to the > same administrative domain, there are several security concerns. > > I don't think this is a concern in the aviation case, since we have > assumed that it is posible to establish trust between the MR and a > mobility anchor point near to the CN, so this shouldn't be an issues > (or at least we have assumed that this is not an issue) OK... This document is not specific to aviation case, but I tried to explain general CR issues. It is very important for operators(who deploy CR) to understand this security aspects. To me, having trust between MR and all CRs is strong requirements. > similarly with the rest of the issues in this section. If the trust > can be assumed, i think these are non issues. > > later on, it states: MR-CR Route Management: > > Therefore, even if one direction is optimized, there is no guarantee > that the reverse path is also optimized (Figure 2). > > I don't understand how this could happen > I understand that asymmetric routing is quite common, but mostly in > the core. I fail to see how a you could end up with a non optimized > path in only one direction and i fail to see how you could possibly do > better. Could you expand on this, for instance with an example of > topology that would end up in this situation? It depends on size of AS and location of CR. How can you guarantee that the packets destined to MR are intercepted by CR in AS? see the WIDE AS topology in this URL. http://two.wide.ad.jp/ Let's assume that CR is located at fujisawa (middle of the topology map). how can you guarantee that the packets to MR are re-directed to that CR? By OSPF routing, the packets are routed to one of peering points but not to CR. If CN is located in the fukuoka (left upper in the map), the packets are routed to the Internet from Dojima (left down in the map and peering point) by OSPF. In that case, CR cannot be involved in the path from CN to MR... The packet are not route-optimized and routed to the MR's HA at the end. regards, ryuji > regards, marcelo > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jul 24 00:36:23 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1D1A3A6966; Thu, 24 Jul 2008 00:36:23 -0700 (PDT) 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 155CE3A6961 for ; Thu, 24 Jul 2008 00:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 z7ULWLQ-7jLD for ; Thu, 24 Jul 2008 00:36:21 -0700 (PDT) Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id E7B453A67B7 for ; Thu, 24 Jul 2008 00:36:20 -0700 (PDT) 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 1KLvNf-0000KU-7x; Thu, 24 Jul 2008 09:36:55 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: Basavaraj Patil , Sebastien Decugis References: <4887BB1E.5000207@hongo.wide.ad.jp> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:080724:basavaraj.patil@nokia.com::eDk0Cdl8XrdcrWBW:0000000000000000000000000000000000001McU X-Hashcash: 1:20:080724:mext@ietf.org::KShIF8RY2LGDZGjW:00001kgZ X-Hashcash: 1:20:080724:sdecugis@hongo.wide.ad.jp::5yhhefcd2kfF5hlN:0000000000000000000000000000000000004De7 Date: Thu, 24 Jul 2008 09:35:58 +0200 In-Reply-To: <4887BB1E.5000207@hongo.wide.ad.jp> (Sebastien Decugis's message of "Thu, 24 Jul 2008 08:13:34 +0900") Message-ID: <8763qv68f5.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: MEXT IETF WG Subject: Re: [MEXT] Mobile IPv6 and IPsec/IKE 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="===============1881255984==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1881255984== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Basavaraj, > Basavaraj Patil a =C3=A9crit : >> Useful document. Now if only support for IKEv2 can also be added :) Thanks. See additional comments below. Sebastien Decugis writes: > Hi, > > If you are looking for similar information for ikev2, please look at: > http://www.nautilus6.org/doc/dk-howto/Howto_dynamic_keying.html My fault. Sorry, Seb. I should have added an entry in the FAQ at the end of the document to point the reader to that page. This is done, now. > It may be a little outdated now, but it should be useful anyway. Yep. The kernel patches are kind of historical: they implement SADB_X_EXT_PACKET for Linux 2.6.22 (i.e. from expired 04 version of MIGRATE draft). I still have a dump of Sebastien's SVN repository that includes the additional patches for racoon2 to support the updated design of MIGRATE=20 we have worked on together. Neither me or Sebastien have time (at the moment) to maintain the racoon2 part of the equation: if/when a new 05 version of the draft is published, this will allow pushing the patches mainline to the various projects and free some CPU cycles currently allocated to maintenance in order to possibly spend time on racoon2. Cheers, a+ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIiDDtAlWVfAR6UCYRAox2AJ9NPwUb9ePjHvk71XnGrjD0nIHzbwCdF4Tn w8JBz6RZDzFWOFWEff2P5sk= =vhle -----END PGP SIGNATURE----- --=-=-=-- --===============1881255984== 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 --===============1881255984==-- From primmis21072008@gmail.com Thu Jul 24 01:22: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 221E53A68B7; Thu, 24 Jul 2008 01:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.462 X-Spam-Level: ** X-Spam-Status: No, score=2.462 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_50=0.001, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccfXIWwDZAMo; Thu, 24 Jul 2008 01:22:30 -0700 (PDT) Received: from avas-mr20.fibertel.com.ar (avas-mr20.fibertel.com.ar [24.232.0.123]) by core3.amsl.com (Postfix) with ESMTP id 0BAE33A68AB; Thu, 24 Jul 2008 01:22:30 -0700 (PDT) Received: from 59-95-189-190.cab.prima.net.ar ([190.189.95.59]:62466 "EHLO desktop" smtp-auth: "primmis21072008" rhost-flags-OK-FAIL-OK-FAIL) by avas-mr20.fibertel.com.ar with ESMTPA id S1021994AbYGXIMc convert rfc822-to-8bit; Thu, 24 Jul 2008 05:12:32 -0300 Message-ID: <3824-2200874248122781@desktop> To: "CUATRIS" Errors-to: primmis21072008_@gmail.com From: "primmis21072008@gmail.com" Subject: CUATRICICLOS 0Km TODAS LAS MARCAS Date: Thu, 24 Jul 2008 10:12:27 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8BIT X-Fib-Al-Info: Al X-Fib-Al-MRId: 11557d785e3ebbc97c78370635cdfc73 X-Fib-Al: noav X-Fib-Al-SA: analyzed X-Fib-Al-From: primmis21072008@gmail.com CUATRICICLO ZANELLA KIDS 50CC ZANELLA ZANELLA KIDS 50CC pesos 1,599.00 CUATRICICLO FD 50 MONDIAL MOTOR Monocilíndrico, 2 Tiempos CILINDRADA 41.5 CC pesos 3,700.00 CUATRICICLO FX 70 ZANELLA FX 70 pesos 3,890.00 CUATRICICLO FX 90CC ZANELLA Motor Monocilindrico 4T Cilindrada 90 cc pesos 3,990.00 CUATRICICLO FX 110CC ZANELLA Motor Monocilindrico 4T Cilindrada 107 cc pesos 4,390.00 CUATRICICLO Xbeach 110CC X-SCREAMS Motor 110CC 4 Tiempos Refrigerado por Aire Caja Manual (2WD) 4 forward pesos 5,499.00 CUATRICICLO ATV FD 110L MONDIAL MOTOR Monocilíndrico 4 tiempos CILINDRADA 107cc pesos 5,500.00 CUATRICICLO Kaptor 150 CC X-SCREAMS Motor 150CC 4 Tiempos caja Automatica (2WD) con marcha atrás pesos 6,499.00 CUATRICICLO FD 150Q MONDIAL MOTOR Monocilíndrico 4 tiempos CILINDRADA 149.65CC pesos 6,500.00 CUATRICICLO FD 200S MONDIAL MOTOR 4 Tiempos, Monocilindrico CILINDRADA: 196.9CC pesos 7,499.00 CUATRICICLO FX 150CC ZANELLA Motor Monocilindrico 4T Cilindrada 149 cc pesos 6,990.00 CUATRICICLO FX 200 ZANELLA FX 200 pesos 7,990.00 CUATRICICLO Reactor 200CC X-SCREAMS Motor 200CC 4 Tiempos Refrigerado por Agua Caja Manual (2WD) 4 forward pesos 8,499.00 CUATRICICLO INTERCEPTOR 200CC X-SCREAMS Motor 200CC 4 Tiempos Caja Manual (2WD) 5 forward + marcha atrás pesos 9,500.00 CUATRICICLO FX 250 ZANELLA FX 250 pesos 9,990.00 CUATRICICLO FD 250H MONDIAL MOTOR Monocilindrico, 4 Tiempos REFRIGERACIÓN Por aire pesos 10,500.00 CUATRICICLO FD 250Q MONDIAL MOTOR Monocilindrico, 4 tiempos CILINDRADA 248 CC pesos 13,000.00 CUATRICICLO AGROTRUCK 250 X-SCREAMS Motor 251CC 4 Tiempos Water Cooler Caja Automatica con marcha atrás pesos 12,500.00 CUATRICICLO EXPLORER 250 ZANELLA EXPLORER 250 pesos 12,990.00 CUATRICICLO GFORCE 250 ZANELLA GFORCE 250 pesos 14,490.00 CUATRICICLO FX 400 ZANELLA FX 400 pesos 21,490.00 CUATRICICLO GFORCE 500 ZANELLA GFORCE 500 pesos 29,990.00 EMAIL: primmis21072008@gmail.com From mext-bounces@ietf.org Thu Jul 24 10:01:05 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E2533A687C; Thu, 24 Jul 2008 10:01:05 -0700 (PDT) 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 475E73A687C for ; Thu, 24 Jul 2008 10:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.872 X-Spam-Level: X-Spam-Status: No, score=-4.872 tagged_above=-999 required=5 tests=[AWL=1.727, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kG59pDSp+4rH for ; Thu, 24 Jul 2008 10:01:02 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id A0D673A69D3 for ; Thu, 24 Jul 2008 10:01:02 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (129.pool85-53-131.dynamic.orange.es [85.53.131.129])by smtp02.uc3m.es (Postfix) with ESMTP id 864F7423D17for ; Thu, 24 Jul 2008 19:01:45 +0200 (CEST) Message-ID: <4888B578.7050009@it.uc3m.es> Date: Thu, 24 Jul 2008 19:01:44 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: mext X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-9.7532 TC:1F TRN:69 TV:5.5.1026(16050.007) 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] Thoughts on the different nemo ro approaches 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, I have been reading the drafts people have submitted for the nemo ro work for the aviation case. In particular, i have read draft-bauer-mext-aero-topology-00 draft-wakikawa-mext-haha-interop2008-00 draft-wakikawa-mext-cr-consideration-00 draft-wakikawa-nemo-orc-01 draft-thubert-mext-global-haha-00 draft-bernardos-mext-nemo-ro-cr-00 Essentially we have two different approaches, one based on distributed HAs and another one based on the concept of the correspondent router. It seems to me that the CR based approach is more complex than the ha based approach, so i guess that a first legitimate question to ask is where does the complexity springs from? One observation that i would like to contrast with the group is that the HA based approach makes the following fundamental assumption: A set of globally distributed anchor points that are within the _same_ administrative domain are available and are enough to provide the RO capabilities required. OTOH, the CR based approach makes a different assumption, which is that a set of distributed anchor points with which is possible to have a trust relationship are available and are enough to provide the RO capabilties required. The difference as i understand it, is that the HA based approach assumes that the anchor points are in the same admin domain (or that they are within domains with strong admin relationship, which allows them to do functions that are usually not acceptable across domains) and the CR based approach does not makes that assumption. By assuming that these anchor points are in the same admin domain, the HA based approach can take advantage of the following functions that are not available across domains (i may be missing some function): - anycast routing - host/MNP route injection to sink traffic for the proper anchor point. - strong state synchronization between HAs/anchor points The usage of these tools indeed make life easier, but they impose some constraints. I think that we need to understand these constraints, and figure out whether they are acceptable for the aviation community. In other words, i think that a relevant exercise at this point is to try to figure out how a HA based approach can be deployed within the aviation scenario described in draft-bauer-mext-aero-topology-00 So, let's consider how this could be deployed. A first deployment scenario would be that the HAs are deployed within a gACSP. This seems like the perfect match. The gACSP has global infrastructure, so it can be assumed to have HAs distributed along the globe and they can provide reasonable good enough rute optimization. So, if an aricraft is using the gACSP all the way, this seems to work reasonably. A first question may be posed though in this scenario about addressing. From which prefix the MNP is extracted from? I mean, one option is that the gACSP has a prefix for this, and uses it to assign to all the different companies that it serves. However, this would result in a form of provider dependent addressing and maybe the problems of provider dependent addressing would rise here. In other words, is it ok for the aviation companies to use a prefix that is owned by the gASCP? This basically means that if they want to change the provider (i don't know if this is possible), they will need to renumber. A related question to this one, about what is the normal relation between the aviation company and the gASCP? Is it normal that a given aviation company works with one or both the gACSP that exists? If they work with one, the provide lock in effect could be an issue. If they work with two, then would this approach implies that they need to have two prefixes, one for each gACSP? That would probably be problematic from the network management perspective. In both cases, either if they decide to use two prefixes, or they use a single gACSP with only one prefix, the next question is whether they can acquire a CoA from the other gACSP? if they can, it is possible that the gACSP performs cold potato routing and the RO benefits are not achieved. The other option of course is that the aviation companies have a provider indepedent prefix and that the gACSP announces it on behalf of their clients. In this case both gACSP can announce the client prefix. The potential issue here is what is the impact for the global routing table of such practice. A second scenario is where other than gASCP are considered. At this point, i don't even grasp how the scenarios are. For instance, is it possible that some airlines do not have any relationship with any of the two gASCP? In that case, they only have contracts with smaller providers and in that case i this not clear to me how the ha infrastructure can be deployed. I mean, would this imply that each of the smaller players will have a HA and they would run HAHA protocol between them? I don't know if the implications of these are acceptable for the relationship that those players have. One particular case where this is significant is when the communication with the gACSP is down for whatever reason. If this is the case, and the HA infrastrucutre is not reachable, the direct communication between the aircraft and the CNs that are directly attached to the same ACSP is not possible, even if they have direct connectivity. I am not sure if this is acceptable. So, imho, what needs to be understood a bit more in depth is the possible deployment models of a HA based approach in the aviation reality. I am hoping that we can have this discussion in dublin Regards, marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jul 24 10:28:26 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CC673A6A4D; Thu, 24 Jul 2008 10:28:26 -0700 (PDT) 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 23E3A28C0DB for ; Thu, 24 Jul 2008 10:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.547 X-Spam-Level: X-Spam-Status: No, score=-5.547 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7yn9GzhSbaM for ; Thu, 24 Jul 2008 10:28:24 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id E9D1A3A6A49 for ; Thu, 24 Jul 2008 10:28:23 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m6OHT3je028683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 24 Jul 2008 10:29:08 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m6OHT2S3021467; Thu, 24 Jul 2008 12:29:02 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m6OHSuX8021261; Thu, 24 Jul 2008 12:29:02 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Jul 2008 10:29:02 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Jul 2008 10:29:00 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A104BD3A6E@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <4888B578.7050009@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Thoughts on the different nemo ro approaches Thread-Index: AcjtrwC7ZCRmcWEDQTCOlQ/7z8hsDAAAkGBQ References: <4888B578.7050009@it.uc3m.es> From: "Templin, Fred L" To: "marcelo bagnulo braun" , "mext" X-OriginalArrivalTime: 24 Jul 2008 17:29:02.0172 (UTC) FILETIME=[C39AC1C0:01C8EDB2] Subject: Re: [MEXT] Thoughts on the different nemo ro approaches 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, What is the timeframe you are looking for a RO solution for aeronautical use cases? To my understanding, ATS/AOS communications require safety-of-flight certified links and I am not seeing near-term safety-of-flight certified links with performance characteristics capable of handling IPv6 let alone the additional signalling required for RO (at least not in terms of scaling to the anticipated numbers of aircraft in a multiple access domain). Asked another way, can the aeronautical use cases be considered as a near-term driver for a RO solution when the links may not yet be ready to handle even IPv6? Thanks - Fred fred.l.templin@boeing.com >-----Original Message----- >From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >Sent: Thursday, July 24, 2008 10:02 AM >To: mext >Subject: [MEXT] Thoughts on the different nemo ro approaches > >Hi, > >I have been reading the drafts people have submitted for the nemo ro >work for the aviation case. >In particular, i have read > >draft-bauer-mext-aero-topology-00 >draft-wakikawa-mext-haha-interop2008-00 >draft-wakikawa-mext-cr-consideration-00 >draft-wakikawa-nemo-orc-01 >draft-thubert-mext-global-haha-00 >draft-bernardos-mext-nemo-ro-cr-00 > >Essentially we have two different approaches, one based on distributed >HAs and another one based on the concept of the correspondent router. >It seems to me that the CR based approach is more complex than the ha >based approach, so i guess that a first legitimate question to ask is >where does the complexity springs from? >One observation that i would like to contrast with the group >is that the >HA based approach makes the following fundamental assumption: A set of >globally distributed anchor points that are within the _same_ >administrative domain are available and are enough to provide the RO >capabilities required. > >OTOH, the CR based approach makes a different assumption, >which is that >a set of distributed anchor points with which is possible to have a >trust relationship are available and are enough to provide the RO >capabilties required. > >The difference as i understand it, is that the HA based >approach assumes >that the anchor points are in the same admin domain (or that they are >within domains with strong admin relationship, which allows them to do >functions that are usually not acceptable across domains) and the CR >based approach does not makes that assumption. > >By assuming that these anchor points are in the same admin domain, the >HA based approach can take advantage of the following >functions that are >not available across domains (i may be missing some function): >- anycast routing >- host/MNP route injection to sink traffic for the proper anchor point. >- strong state synchronization between HAs/anchor points > >The usage of these tools indeed make life easier, but they impose some >constraints. >I think that we need to understand these constraints, and figure out >whether they are acceptable for the aviation community. In >other words, >i think that a relevant exercise at this point is to try to figure out >how a HA based approach can be deployed within the aviation scenario >described in draft-bauer-mext-aero-topology-00 > >So, let's consider how this could be deployed. > >A first deployment scenario would be that the HAs are deployed >within a >gACSP. This seems like the perfect match. The gACSP has global >infrastructure, so it can be assumed to have HAs distributed along the >globe and they can provide reasonable good enough rute >optimization. So, >if an aricraft is using the gACSP all the way, this seems to work >reasonably. A first question may be posed though in this >scenario about >addressing. From which prefix the MNP is extracted from? I mean, one >option is that the gACSP has a prefix for this, and uses it to >assign to >all the different companies that it serves. However, this would result >in a form of provider dependent addressing and maybe the problems of >provider dependent addressing would rise here. In other >words, is it ok >for the aviation companies to use a prefix that is owned by the gASCP? >This basically means that if they want to change the provider (i don't >know if this is possible), they will need to renumber. >A related question to this one, about what is the normal relation >between the aviation company and the gASCP? Is it normal that a given >aviation company works with one or both the gACSP that exists? If they >work with one, the provide lock in effect could be an issue. If they >work with two, then would this approach implies that they need to have >two prefixes, one for each gACSP? That would probably be problematic >from the network management perspective. In both cases, either if they >decide to use two prefixes, or they use a single gACSP with only one >prefix, the next question is whether they can acquire a CoA from the >other gACSP? if they can, it is possible that the gACSP performs cold >potato routing and the RO benefits are not achieved. >The other option of course is that the aviation companies have a >provider indepedent prefix and that the gACSP announces it on >behalf of >their clients. In this case both gACSP can announce the client prefix. >The potential issue here is what is the impact for the global routing >table of such practice. > >A second scenario is where other than gASCP are considered. >At this point, i don't even grasp how the scenarios are. For instance, >is it possible that some airlines do not have any relationship >with any >of the two gASCP? In that case, they only have contracts with smaller >providers and in that case i this not clear to me how the ha >infrastructure can be deployed. I mean, would this imply that each of >the smaller players will have a HA and they would run HAHA protocol >between them? I don't know if the implications of these are acceptable >for the relationship that those players have. > >One particular case where this is significant is when the >communication >with the gACSP is down for whatever reason. If this is the >case, and the >HA infrastrucutre is not reachable, the direct communication >between the >aircraft and the CNs that are directly attached to the same >ACSP is not >possible, even if they have direct connectivity. I am not sure if this >is acceptable. > >So, imho, what needs to be understood a bit more in depth is the >possible deployment models of a HA based approach in the aviation >reality. I am hoping that we can have this discussion in dublin > >Regards, marcelo > > > >_______________________________________________ >MEXT mailing list >MEXT@ietf.org >https://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 Jul 24 10:37:08 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2F0C3A692B; Thu, 24 Jul 2008 10:37:07 -0700 (PDT) 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 623AD3A6977 for ; Thu, 24 Jul 2008 10:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.501 X-Spam-Level: X-Spam-Status: No, score=-3.501 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3SIRkSIQCZg for ; Thu, 24 Jul 2008 10:37:05 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id B27973A691D for ; Thu, 24 Jul 2008 10:37:04 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (129.pool85-53-131.dynamic.orange.es [85.53.131.129])by smtp01.uc3m.es (Postfix) with ESMTP id 2D32A7D2F56; Thu, 24 Jul 2008 19:37:48 +0200 (CEST) Message-ID: <4888BDEB.5020401@it.uc3m.es> Date: Thu, 24 Jul 2008 19:37:47 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: "Templin, Fred L" References: <4888B578.7050009@it.uc3m.es> <39C363776A4E8C4A94691D2BD9D1C9A104BD3A6E@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A104BD3A6E@XCH-NW-7V2.nw.nos.boeing.com> X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-28.2963 TC:1F TRN:93 TV:5.5.1026(16050.007) 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 Subject: Re: [MEXT] Thoughts on the different nemo ro approaches 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-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Fred, thanks for the input according to draft-bauer-mext-aero-topology-00 Meanwhile ICAO is currently producing an amended version of the manual that allows the ATN to be an internetwork based on IPv6 for both ground- ground and air-ground communications. States have already begun deployment of the ground portion. Definition of the mobility support for aircraft within this new ATN architecture is underway in the ICAO and will form the basis of new ATN manual [icao9896]. I guess you can find similar statements in other places as well. So it seem that there are some people that think this will be possible = in the future and now it is good time to design the solution, in order = to deploy the solution within the required timing Regards, marcelo Templin, Fred L escribi=F3: > Marcelo, > > What is the timeframe you are looking for a RO solution > for aeronautical use cases? To my understanding, ATS/AOS > communications require safety-of-flight certified links > and I am not seeing near-term safety-of-flight certified > links with performance characteristics capable of handling > IPv6 let alone the additional signalling required for RO > (at least not in terms of scaling to the anticipated numbers > of aircraft in a multiple access domain). > > Asked another way, can the aeronautical use cases be > considered as a near-term driver for a RO solution when > the links may not yet be ready to handle even IPv6? > > Thanks - Fred > fred.l.templin@boeing.com > = > = >> -----Original Message----- >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] = >> Sent: Thursday, July 24, 2008 10:02 AM >> To: mext >> Subject: [MEXT] Thoughts on the different nemo ro approaches >> >> Hi, >> >> I have been reading the drafts people have submitted for the nemo ro = >> work for the aviation case. >> In particular, i have read >> >> draft-bauer-mext-aero-topology-00 >> draft-wakikawa-mext-haha-interop2008-00 >> draft-wakikawa-mext-cr-consideration-00 >> draft-wakikawa-nemo-orc-01 >> draft-thubert-mext-global-haha-00 >> draft-bernardos-mext-nemo-ro-cr-00 >> >> Essentially we have two different approaches, one based on distributed = >> HAs and another one based on the concept of the correspondent router. >> It seems to me that the CR based approach is more complex than the ha = >> based approach, so i guess that a first legitimate question to ask is = >> where does the complexity springs from? >> One observation that i would like to contrast with the group = >> is that the = >> HA based approach makes the following fundamental assumption: A set of = >> globally distributed anchor points that are within the _same_ = >> administrative domain are available and are enough to provide the RO = >> capabilities required. >> >> OTOH, the CR based approach makes a different assumption, = >> which is that = >> a set of distributed anchor points with which is possible to have a = >> trust relationship are available and are enough to provide the RO = >> capabilties required. >> >> The difference as i understand it, is that the HA based = >> approach assumes = >> that the anchor points are in the same admin domain (or that they are = >> within domains with strong admin relationship, which allows them to do = >> functions that are usually not acceptable across domains) and the CR = >> based approach does not makes that assumption. >> >> By assuming that these anchor points are in the same admin domain, the = >> HA based approach can take advantage of the following = >> functions that are = >> not available across domains (i may be missing some function): >> - anycast routing >> - host/MNP route injection to sink traffic for the proper anchor point. >> - strong state synchronization between HAs/anchor points >> >> The usage of these tools indeed make life easier, but they impose some = >> constraints. >> I think that we need to understand these constraints, and figure out = >> whether they are acceptable for the aviation community. In = >> other words, = >> i think that a relevant exercise at this point is to try to figure out = >> how a HA based approach can be deployed within the aviation scenario = >> described in draft-bauer-mext-aero-topology-00 >> >> So, let's consider how this could be deployed. >> >> A first deployment scenario would be that the HAs are deployed = >> within a = >> gACSP. This seems like the perfect match. The gACSP has global = >> infrastructure, so it can be assumed to have HAs distributed along the = >> globe and they can provide reasonable good enough rute = >> optimization. So, = >> if an aricraft is using the gACSP all the way, this seems to work = >> reasonably. A first question may be posed though in this = >> scenario about = >> addressing. From which prefix the MNP is extracted from? I mean, one = >> option is that the gACSP has a prefix for this, and uses it to = >> assign to = >> all the different companies that it serves. However, this would result = >> in a form of provider dependent addressing and maybe the problems of = >> provider dependent addressing would rise here. In other = >> words, is it ok = >> for the aviation companies to use a prefix that is owned by the gASCP? = >> This basically means that if they want to change the provider (i don't = >> know if this is possible), they will need to renumber. >> A related question to this one, about what is the normal relation = >> between the aviation company and the gASCP? Is it normal that a given = >> aviation company works with one or both the gACSP that exists? If they = >> work with one, the provide lock in effect could be an issue. If they = >> work with two, then would this approach implies that they need to have = >> two prefixes, one for each gACSP? That would probably be problematic = >> = > >from the network management perspective. In both cases, either if they = > = >> decide to use two prefixes, or they use a single gACSP with only one = >> prefix, the next question is whether they can acquire a CoA from the = >> other gACSP? if they can, it is possible that the gACSP performs cold = >> potato routing and the RO benefits are not achieved. >> The other option of course is that the aviation companies have a = >> provider indepedent prefix and that the gACSP announces it on = >> behalf of = >> their clients. In this case both gACSP can announce the client prefix. = >> The potential issue here is what is the impact for the global routing = >> table of such practice. >> >> A second scenario is where other than gASCP are considered. >> At this point, i don't even grasp how the scenarios are. For instance, = >> is it possible that some airlines do not have any relationship = >> with any = >> of the two gASCP? In that case, they only have contracts with smaller = >> providers and in that case i this not clear to me how the ha = >> infrastructure can be deployed. I mean, would this imply that each of = >> the smaller players will have a HA and they would run HAHA protocol = >> between them? I don't know if the implications of these are acceptable = >> for the relationship that those players have. >> >> One particular case where this is significant is when the = >> communication = >> with the gACSP is down for whatever reason. If this is the = >> case, and the = >> HA infrastrucutre is not reachable, the direct communication = >> between the = >> aircraft and the CNs that are directly attached to the same = >> ACSP is not = >> possible, even if they have direct connectivity. I am not sure if this = >> is acceptable. >> >> So, imho, what needs to be understood a bit more in depth is the = >> possible deployment models of a HA based approach in the aviation = >> reality. I am hoping that we can have this discussion in dublin >> >> Regards, marcelo >> >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://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 Jul 24 10:45:31 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ADC63A6977; Thu, 24 Jul 2008 10:45:31 -0700 (PDT) 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 B7FC83A691D for ; Thu, 24 Jul 2008 10:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.073 X-Spam-Level: X-Spam-Status: No, score=-6.073 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtYPDCPX2EZV for ; Thu, 24 Jul 2008 10:45:26 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 595553A689F for ; Thu, 24 Jul 2008 10:45:25 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m6OHk3Pe011009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 24 Jul 2008 10:46:04 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m6OHk3RP003194; Thu, 24 Jul 2008 10:46:03 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m6OHk3wD003156; Thu, 24 Jul 2008 10:46:03 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Jul 2008 10:46:03 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Jul 2008 10:46:01 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A104BD3A9F@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <4888BDEB.5020401@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Thoughts on the different nemo ro approaches Thread-Index: AcjttABr3FDaS8rTSUmwpWQ9MFuspwAAJcMg References: <4888B578.7050009@it.uc3m.es> <39C363776A4E8C4A94691D2BD9D1C9A104BD3A6E@XCH-NW-7V2.nw.nos.boeing.com> <4888BDEB.5020401@it.uc3m.es> From: "Templin, Fred L" To: "marcelo bagnulo braun" X-OriginalArrivalTime: 24 Jul 2008 17:46:03.0207 (UTC) FILETIME=[24305570:01C8EDB5] Cc: mext Subject: Re: [MEXT] Thoughts on the different nemo ro approaches 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 Thanks Marcelo, Nonetheless, link performance characteristics are an important consideration (e.g., see RFC3819). I tried to raise this at the mike at one of the past meetings but didn't do a very good job of it, so it seemed necessary to raise it again here. Fred fred.l.templin@boeing.com = >-----Original Message----- >From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] = >Sent: Thursday, July 24, 2008 10:38 AM >To: Templin, Fred L >Cc: mext >Subject: Re: [MEXT] Thoughts on the different nemo ro approaches > >Hi Fred, > >thanks for the input > >according to draft-bauer-mext-aero-topology-00 > > Meanwhile > > ICAO is currently producing an amended version of the manual that > > allows the ATN to be an internetwork based on IPv6 for both ground- > > ground and air-ground communications. States have already begun > > deployment of the ground portion. Definition of the = >mobility support > > for aircraft within this new ATN architecture is underway = >in the ICAO > > and will form the basis of new ATN manual [icao9896]. > >I guess you can find similar statements in other places as well. >So it seem that there are some people that think this will be possible = >in the future and now it is good time to design the solution, in order = >to deploy the solution within the required timing > >Regards, marcelo > > > >Templin, Fred L escribi=F3: >> Marcelo, >> >> What is the timeframe you are looking for a RO solution >> for aeronautical use cases? To my understanding, ATS/AOS >> communications require safety-of-flight certified links >> and I am not seeing near-term safety-of-flight certified >> links with performance characteristics capable of handling >> IPv6 let alone the additional signalling required for RO >> (at least not in terms of scaling to the anticipated numbers >> of aircraft in a multiple access domain). >> >> Asked another way, can the aeronautical use cases be >> considered as a near-term driver for a RO solution when >> the links may not yet be ready to handle even IPv6? >> >> Thanks - Fred >> fred.l.templin@boeing.com >> = >> = >>> -----Original Message----- >>> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] = >>> Sent: Thursday, July 24, 2008 10:02 AM >>> To: mext >>> Subject: [MEXT] Thoughts on the different nemo ro approaches >>> >>> Hi, >>> >>> I have been reading the drafts people have submitted for = >the nemo ro = >>> work for the aviation case. >>> In particular, i have read >>> >>> draft-bauer-mext-aero-topology-00 >>> draft-wakikawa-mext-haha-interop2008-00 >>> draft-wakikawa-mext-cr-consideration-00 >>> draft-wakikawa-nemo-orc-01 >>> draft-thubert-mext-global-haha-00 >>> draft-bernardos-mext-nemo-ro-cr-00 >>> >>> Essentially we have two different approaches, one based on = >distributed = >>> HAs and another one based on the concept of the = >correspondent router. >>> It seems to me that the CR based approach is more complex = >than the ha = >>> based approach, so i guess that a first legitimate question = >to ask is = >>> where does the complexity springs from? >>> One observation that i would like to contrast with the group = >>> is that the = >>> HA based approach makes the following fundamental = >assumption: A set of = >>> globally distributed anchor points that are within the _same_ = >>> administrative domain are available and are enough to = >provide the RO = >>> capabilities required. >>> >>> OTOH, the CR based approach makes a different assumption, = >>> which is that = >>> a set of distributed anchor points with which is possible to have a = >>> trust relationship are available and are enough to provide the RO = >>> capabilties required. >>> >>> The difference as i understand it, is that the HA based = >>> approach assumes = >>> that the anchor points are in the same admin domain (or = >that they are = >>> within domains with strong admin relationship, which allows = >them to do = >>> functions that are usually not acceptable across domains) = >and the CR = >>> based approach does not makes that assumption. >>> >>> By assuming that these anchor points are in the same admin = >domain, the = >>> HA based approach can take advantage of the following = >>> functions that are = >>> not available across domains (i may be missing some function): >>> - anycast routing >>> - host/MNP route injection to sink traffic for the proper = >anchor point. >>> - strong state synchronization between HAs/anchor points >>> >>> The usage of these tools indeed make life easier, but they = >impose some = >>> constraints. >>> I think that we need to understand these constraints, and = >figure out = >>> whether they are acceptable for the aviation community. In = >>> other words, = >>> i think that a relevant exercise at this point is to try to = >figure out = >>> how a HA based approach can be deployed within the aviation = >scenario = >>> described in draft-bauer-mext-aero-topology-00 >>> >>> So, let's consider how this could be deployed. >>> >>> A first deployment scenario would be that the HAs are deployed = >>> within a = >>> gACSP. This seems like the perfect match. The gACSP has global = >>> infrastructure, so it can be assumed to have HAs = >distributed along the = >>> globe and they can provide reasonable good enough rute = >>> optimization. So, = >>> if an aricraft is using the gACSP all the way, this seems to work = >>> reasonably. A first question may be posed though in this = >>> scenario about = >>> addressing. From which prefix the MNP is extracted from? I = >mean, one = >>> option is that the gACSP has a prefix for this, and uses it to = >>> assign to = >>> all the different companies that it serves. However, this = >would result = >>> in a form of provider dependent addressing and maybe the = >problems of = >>> provider dependent addressing would rise here. In other = >>> words, is it ok = >>> for the aviation companies to use a prefix that is owned by = >the gASCP? = >>> This basically means that if they want to change the = >provider (i don't = >>> know if this is possible), they will need to renumber. >>> A related question to this one, about what is the normal relation = >>> between the aviation company and the gASCP? Is it normal = >that a given = >>> aviation company works with one or both the gACSP that = >exists? If they = >>> work with one, the provide lock in effect could be an = >issue. If they = >>> work with two, then would this approach implies that they = >need to have = >>> two prefixes, one for each gACSP? That would probably be = >problematic = >>> = >> >from the network management perspective. In both cases, = >either if they = >> = >>> decide to use two prefixes, or they use a single gACSP with = >only one = >>> prefix, the next question is whether they can acquire a CoA = >from the = >>> other gACSP? if they can, it is possible that the gACSP = >performs cold = >>> potato routing and the RO benefits are not achieved. >>> The other option of course is that the aviation companies have a = >>> provider indepedent prefix and that the gACSP announces it on = >>> behalf of = >>> their clients. In this case both gACSP can announce the = >client prefix. = >>> The potential issue here is what is the impact for the = >global routing = >>> table of such practice. >>> >>> A second scenario is where other than gASCP are considered. >>> At this point, i don't even grasp how the scenarios are. = >For instance, = >>> is it possible that some airlines do not have any relationship = >>> with any = >>> of the two gASCP? In that case, they only have contracts = >with smaller = >>> providers and in that case i this not clear to me how the ha = >>> infrastructure can be deployed. I mean, would this imply = >that each of = >>> the smaller players will have a HA and they would run HAHA protocol = >>> between them? I don't know if the implications of these are = >acceptable = >>> for the relationship that those players have. >>> >>> One particular case where this is significant is when the = >>> communication = >>> with the gACSP is down for whatever reason. If this is the = >>> case, and the = >>> HA infrastrucutre is not reachable, the direct communication = >>> between the = >>> aircraft and the CNs that are directly attached to the same = >>> ACSP is not = >>> possible, even if they have direct connectivity. I am not = >sure if this = >>> is acceptable. >>> >>> So, imho, what needs to be understood a bit more in depth is the = >>> possible deployment models of a HA based approach in the aviation = >>> reality. I am hoping that we can have this discussion in dublin >>> >>> Regards, marcelo >>> >>> >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://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 Jul 24 11:03:39 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AE6D3A686A; Thu, 24 Jul 2008 11:03:39 -0700 (PDT) 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 7171F3A686A for ; Thu, 24 Jul 2008 11:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhGWjeI8332e for ; Thu, 24 Jul 2008 11:03:37 -0700 (PDT) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id 9C3143A6813 for ; Thu, 24 Jul 2008 11:03:37 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id C0459328328; Thu, 24 Jul 2008 13:04:21 -0500 (CDT) Received: from ndjsxgw03.ndc.nasa.gov (ndjsxgw03.ndc.nasa.gov [129.166.32.111]) by ndjsppt02.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id m6OI4M5h016593; Thu, 24 Jul 2008 13:04:22 -0500 Received: from NDJSEVS25A.ndc.nasa.gov ([129.166.32.124]) by ndjsxgw03.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Jul 2008 13:04:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Jul 2008 13:04:21 -0500 Message-ID: In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A104BD3A9F@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Thoughts on the different nemo ro approaches Thread-Index: AcjttABr3FDaS8rTSUmwpWQ9MFuspwAAJcMgAABjmOA= References: <4888B578.7050009@it.uc3m.es><39C363776A4E8C4A94691D2BD9D1C9A104BD3A6E@XCH-NW-7V2.nw.nos.boeing.com><4888BDEB.5020401@it.uc3m.es> <39C363776A4E8C4A94691D2BD9D1C9A104BD3A9F@XCH-NW-7V2.nw.nos.boeing.com> From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: "Templin, Fred L" , "marcelo bagnulo braun" X-OriginalArrivalTime: 24 Jul 2008 18:04:21.0616 (UTC) FILETIME=[B2E43F00:01C8EDB7] Cc: mext Subject: Re: [MEXT] Thoughts on the different nemo ro approaches 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 >-----Original Message----- >From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >Behalf Of Templin, Fred L >Sent: Thursday, July 24, 2008 1:46 PM > >Nonetheless, link performance characteristics are an important >consideration (e.g., see RFC3819). I tried to raise this at the >mike at one of the past meetings but didn't do a very good job >of it, so it seemed necessary to raise it again here. I basically agree with Fred, but propose that we make some simplifying assumptions and move on. There are actually 2 high-level issues with the datalink layers: I1 - What form of MAC protocols or techniques will be used? I2 - What spectrum will be available? Without capable datalink protocols or available spectrum, the network won't be worth building. But without the network, the datalinks are not worth building. It is not worth the cost to develop, certify, and equip new datalinks only to run ISO protocols over them :), so we must press forward with the network. So ... I propose that we assume: A1 - The datalink protocols and spectrum are being worked on in parallel to our efforts on the network. There are other groups chartered to handle this (e.g. ICAO WG-T and WG-F). A2 - The people working on the datalink will be evaluating it specifically as a bearer for IP services. This is at least true of the Future Comm Study, where supporting networking was an evaluation criterion. With regards to A2, we may want to just find the right people and make sure they're aware of RFC 3819 and any other relevant documents that would help them make a good decision. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jul 24 11:20:29 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B31B3A6A23; Thu, 24 Jul 2008 11:20:29 -0700 (PDT) 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 2795B3A6A19 for ; Thu, 24 Jul 2008 11:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJhH-LFNEERq for ; Thu, 24 Jul 2008 11:20:27 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 437053A69D3 for ; Thu, 24 Jul 2008 11:20:27 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m6OIKtQA017667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jul 2008 11:20:57 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m6OIKsYp021674; Thu, 24 Jul 2008 11:20:54 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m6OIKn7c021479; Thu, 24 Jul 2008 11:20:54 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Jul 2008 11:20:50 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Jul 2008 11:20:48 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A104BD3AF0@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Thoughts on the different nemo ro approaches Thread-Index: AcjttABr3FDaS8rTSUmwpWQ9MFuspwAAJcMgAABjmOAAAHuhsA== References: <4888B578.7050009@it.uc3m.es><39C363776A4E8C4A94691D2BD9D1C9A104BD3A6E@XCH-NW-7V2.nw.nos.boeing.com><4888BDEB.5020401@it.uc3m.es> <39C363776A4E8C4A94691D2BD9D1C9A104BD3A9F@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" , "marcelo bagnulo braun" X-OriginalArrivalTime: 24 Jul 2008 18:20:50.0325 (UTC) FILETIME=[00354450:01C8EDBA] Cc: mext Subject: Re: [MEXT] Thoughts on the different nemo ro approaches 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 Wesley, I think we are largely in accord; see below: >-----Original Message----- >From: Eddy, Wesley M. (GRC-RCN0)[VZ] [mailto:wesley.m.eddy@nasa.gov] >Sent: Thursday, July 24, 2008 11:04 AM >To: Templin, Fred L; marcelo bagnulo braun >Cc: mext >Subject: RE: [MEXT] Thoughts on the different nemo ro approaches > >>-----Original Message----- >>From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >>Behalf Of Templin, Fred L >>Sent: Thursday, July 24, 2008 1:46 PM >> >>Nonetheless, link performance characteristics are an important >>consideration (e.g., see RFC3819). I tried to raise this at the >>mike at one of the past meetings but didn't do a very good job >>of it, so it seemed necessary to raise it again here. > >I basically agree with Fred, but propose that we make some >simplifying assumptions and move on. > >There are actually 2 high-level issues with the datalink layers: > >I1 - What form of MAC protocols or techniques will be used? > >I2 - What spectrum will be available? > >Without capable datalink protocols or available spectrum, the >network won't be worth building. But without the network, the >datalinks are not worth building. It is not worth the cost to >develop, certify, and equip new datalinks only to run ISO >protocols over them :), so we must press forward with the >network. I don't know why we would build new datalinks to support ISO either. :^} But, just to socialize an aeronautical use case term the Controller Pilot Data Link Communications (CPDLC) protocol will require data links that can support safety-of-flight while scaling to large numbers of aircraft within a common signals-in-space coverage region regarless of the underlying network/transport. >So ... I propose that we assume: > >A1 - The datalink protocols and spectrum are being worked on in > parallel to our efforts on the network. There are other groups > chartered to handle this (e.g. ICAO WG-T and WG-F). > >A2 - The people working on the datalink will be evaluating it > specifically as a bearer for IP services. This is at least > true of the Future Comm Study, where supporting networking was > an evaluation criterion. > >With regards to A2, we may want to just find the right people and >make sure they're aware of RFC 3819 and any other relevant documents >that would help them make a good decision. These are good suggestions, and I support our moving forward with good faith in link designers. Also, I think these documents like draft-bauer are a good start at information sharing between the IETF and ICAO and would like to see more of it. However, my sense of it is that we may be moving too fast and may not be engaging enough people within the two communities in a cross-functional manner. Thanks - Fred fred.l.templin@boeing.com _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jul 24 12:10:23 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACE0D3A682D; Thu, 24 Jul 2008 12:10:23 -0700 (PDT) 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 AFDF73A691D for ; Thu, 24 Jul 2008 12:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[RCVD_BAD_ID=2.088, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXdj04OUn38C for ; Thu, 24 Jul 2008 12:10:17 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 8938B3A6452 for ; Thu, 24 Jul 2008 12:10:12 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (129.pool85-53-131.dynamic.orange.es [85.53.131.129])by smtp01.uc3m.es (Postfix) with ESMTP id 3368F7E1F7C; Thu, 24 Jul 2008 21:10:10 +0200 (CEST) Message-ID: <4888D391.7010202@it.uc3m.es> Date: Thu, 24 Jul 2008 21:10:09 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: "Templin, Fred L" References: <4888B578.7050009@it.uc3m.es><39C363776A4E8C4A94691D2BD9D1C9A104 BD3A6E@XCH-NW-7V2.nw.nos.boeing.com><4888BDEB.5020401@it.uc3m.es> <39C363776A4E8C4A94691D2BD9D1C9A104BD3A9F@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A104BD3AF0@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A104BD3AF0@XCH-NW-7V2.nw.nos.boeing.com> X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-9.1442 TC:1F TRN:19 TV:5.5.1026(16052.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 Subject: Re: [MEXT] Thoughts on the different nemo ro approaches 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > These are good suggestions, and I support our moving forward > with good faith in link designers. Also, I think these documents > like draft-bauer are a good start at information sharing between > the IETF and ICAO and would like to see more of it. However, my > sense of it is that we may be moving too fast and may not be > engaging enough people within the two communities in a > cross-functional manner. > > fully agree any suggestion how to improve the interaction or any additional document would be very appreciated We could try to go to one of their meeting and make a presentation to try to engage more people or even do a joint meeting, if people think this would be useful regards, marcelo > Thanks - Fred > fred.l.templin@boeing.com > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 25 01:04:30 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D67F3A68D7; Fri, 25 Jul 2008 01:04:30 -0700 (PDT) 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 E745D3A69AB for ; Fri, 25 Jul 2008 01:04:29 -0700 (PDT) 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_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHmOzhiiQX9M for ; Fri, 25 Jul 2008 01:04:29 -0700 (PDT) Received: from smtp-2.dlr.de (smtp-3.dlr.de [195.37.61.187]) by core3.amsl.com (Postfix) with ESMTP id D76BF3A68D7 for ; Fri, 25 Jul 2008 01:04:27 -0700 (PDT) Received: from exbe04.intra.dlr.de ([192.168.35.37]) by smtp-2.dlr.de with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Jul 2008 10:04:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 25 Jul 2008 10:03:45 +0200 Message-ID: In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A104BD3AF0@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [MEXT] Thoughts on the different nemo ro approaches thread-index: AcjttABr3FDaS8rTSUmwpWQ9MFuspwAAJcMgAABjmOAAAHuhsAAcs4Yg References: <4888B578.7050009@it.uc3m.es><39C363776A4E8C4A94691D2BD9D1C9A104BD3A6E@XCH-NW-7V2.nw.nos.boeing.com><4888BDEB.5020401@it.uc3m.es><39C363776A4E8C4A94691D2BD9D1C9A104BD3A9F@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A104BD3AF0@XCH-NW-7V2.nw.nos.boeing.com> From: To: , , X-OriginalArrivalTime: 25 Jul 2008 08:04:26.0788 (UTC) FILETIME=[0EB71E40:01C8EE2D] Cc: mext@ietf.org Subject: Re: [MEXT] Thoughts on the different nemo ro approaches 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 don't know why we would build new datalinks to support > ISO either. :^} But, just to socialize an aeronautical use > case term the Controller Pilot Data Link Communications > (CPDLC) protocol will require data links that can support > safety-of-flight while scaling to large numbers of aircraft > within a common signals-in-space coverage region regarless > of the underlying network/transport. There are already two air-ground access networks in operational use here in Europe, while additional ones will start to appear because ANSPs have to in Europe. CPDLC is already in use, over VDL Mode 2 and OSI protocols. > These are good suggestions, and I support our moving forward > with good faith in link designers. Also, I think these documents > like draft-bauer are a good start at information sharing between > the IETF and ICAO and would like to see more of it. However, my > sense of it is that we may be moving too fast and may not be > engaging enough people within the two communities in a > cross-functional manner. Wesley has already pointed out that there is a chicken-egg problem here. Besides this, we (that is DLR) also have people here that are working on the future data link development, and they are also in ICAO ACP WG-T. We already have a quiet good information exchange, not just with the WG-T community but with other people as well (ANSP). But I do agree that in general IP networking for air-ground communications has not received the attention it deserves inside the aviation industry. Christian _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Jul 25 08:52:36 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3C113A69A1; Fri, 25 Jul 2008 08:52:35 -0700 (PDT) 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 639743A698A for ; Fri, 25 Jul 2008 08:52:34 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9q8Owif7Vne for ; Fri, 25 Jul 2008 08:52:33 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 6A3643A694F for ; Fri, 25 Jul 2008 08:52:33 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m6PFqTmA016874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 25 Jul 2008 08:52:30 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m6PFqT8C014264; Fri, 25 Jul 2008 08:52:29 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m6PFqSuG014201; Fri, 25 Jul 2008 08:52:29 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jul 2008 08:52:28 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 25 Jul 2008 08:52:25 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A104C1C518@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Thoughts on the different nemo ro approaches Thread-Index: AcjttABr3FDaS8rTSUmwpWQ9MFuspwAAJcMgAABjmOAAAHuhsAAcs4YgABCKg0A= References: <4888B578.7050009@it.uc3m.es><39C363776A4E8C4A94691D2BD9D1C9A104BD3A6E@XCH-NW-7V2.nw.nos.boeing.com><4888BDEB.5020401@it.uc3m.es><39C363776A4E8C4A94691D2BD9D1C9A104BD3A9F@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A104BD3AF0@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: , , X-OriginalArrivalTime: 25 Jul 2008 15:52:28.0467 (UTC) FILETIME=[70B34830:01C8EE6E] Cc: mext@ietf.org Subject: Re: [MEXT] Thoughts on the different nemo ro approaches 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 Christian, >-----Original Message----- >From: Christian.Bauer@dlr.de [mailto:Christian.Bauer@dlr.de] >Sent: Friday, July 25, 2008 1:04 AM >To: Templin, Fred L; wesley.m.eddy@nasa.gov; marcelo@it.uc3m.es >Cc: mext@ietf.org >Subject: Re: [MEXT] Thoughts on the different nemo ro approaches > >Hi, > >> I don't know why we would build new datalinks to support >> ISO either. :^} But, just to socialize an aeronautical use >> case term the Controller Pilot Data Link Communications >> (CPDLC) protocol will require data links that can support >> safety-of-flight while scaling to large numbers of aircraft >> within a common signals-in-space coverage region regarless >> of the underlying network/transport. >There are already two air-ground access networks in >operational use here >in Europe, while additional ones will start to appear because >ANSPs have >to in Europe. >CPDLC is already in use, over VDL Mode 2 and OSI protocols. Yes, I know about these. But, I suspect I am in a minority among the IETF community to which the aviation use cases are new. Plus, VDL Mode 2 is a fine example of a link type that does not have performance characteristics that would accommodate IPv6 or mobility-related signalling. >> These are good suggestions, and I support our moving forward >> with good faith in link designers. Also, I think these documents >> like draft-bauer are a good start at information sharing between >> the IETF and ICAO and would like to see more of it. However, my >> sense of it is that we may be moving too fast and may not be >> engaging enough people within the two communities in a >> cross-functional manner. >Wesley has already pointed out that there is a chicken-egg >problem here. And I already said I support our moving forward with good faith in link designers. However, that does not mean that we shouldn't still talk about the links. >Besides this, we (that is DLR) also have people here that are >working on >the future data link development, and they are also in ICAO ACP WG-T. Are they participating in the IETF also? >We already have a quiet good information exchange, not just with the >WG-T community but with other people as well (ANSP). > >But I do agree that in general IP networking for air-ground >communications has not received the attention it deserves inside the >aviation industry. If that is true, then it further strengthens the point I was making which is that air-ground communications has not received the attention it deserves *outside* the aviation industry (e.g., within the IETF). Thanks - Fred fred.l.templin@boeing.com > >Christian > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Jul 26 00:57:31 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5778B3A695A; Sat, 26 Jul 2008 00:57:31 -0700 (PDT) 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 802943A6937 for ; Sat, 26 Jul 2008 00:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=-0.611, BAYES_20=-0.74, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mwb0GZWAP6Nf for ; Sat, 26 Jul 2008 00:57:29 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 8789B3A695A for ; Sat, 26 Jul 2008 00:57:29 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (146.pool85-53-137.dynamic.orange.es [85.53.137.146])by smtp01.uc3m.es (Postfix) with ESMTP id 592467E8471; Sat, 26 Jul 2008 09:57:31 +0200 (CEST) Message-ID: <488AD8E9.8080503@it.uc3m.es> Date: Sat, 26 Jul 2008 09:57:29 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: "Christian.Bauer@dlr.de" , mext X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-0.9465 TC:1F TRN:7 TV:5.5.1026(16054.005) 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] Location of HAs 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Chrsitian, In your draft you suggest that it would be possible for the airlines to have their onw HA in their network (even if this is not the desirable option according to you) If they were to do that, in which network they would place the HA? In the ANSP at their headquarters? regards, marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Jul 26 01:29:52 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62B373A69E2; Sat, 26 Jul 2008 01:29:52 -0700 (PDT) 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 1AA913A69F9 for ; Sat, 26 Jul 2008 01:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_71=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nnt+Xv3o33I6 for ; Sat, 26 Jul 2008 01:29:50 -0700 (PDT) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by core3.amsl.com (Postfix) with ESMTP id 371C83A6985 for ; Sat, 26 Jul 2008 01:29:50 -0700 (PDT) Received: from exbe04.intra.dlr.de ([192.168.35.37]) by smtp-3.dlr.de with Microsoft SMTPSVC(6.0.3790.1830); Sat, 26 Jul 2008 10:29:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 26 Jul 2008 10:29:31 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Location of HAs thread-index: Acju9UKWiT4z2hE3RuC7YboW0S98CAAA2z5v References: <488AD8E9.8080503@it.uc3m.es> From: To: , X-OriginalArrivalTime: 26 Jul 2008 08:29:52.0865 (UTC) FILETIME=[C6BDBD10:01C8EEF9] Subject: Re: [MEXT] Location of HAs 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, > In your draft you suggest that it would be possible for the airlines to > have their onw HA in their network (even if this is not the desirable > option according to you) I will talk about this during the presentation next week. But basically no one will forbid an airline to be its own Mobility Services Provider. > If they were to do that, in which network they would place the HA? In > the ANSP at their headquarters? The HAs would be located in the Airline Network(s, which in turn are connected to the ATN by ACSPs. > > regards, marcelo Christian _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From dvdmovies21072008@gmail.com Sat Jul 26 04:08: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 D26633A6A97; Sat, 26 Jul 2008 04:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.622 X-Spam-Level: **** X-Spam-Status: No, score=4.622 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DATE_IN_PAST_03_06=0.044, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, 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 JYKFjM9V3xNW; Sat, 26 Jul 2008 04:08:45 -0700 (PDT) Received: from avas-mr15.fibertel.com.ar (avas-mr15.fibertel.com.ar [24.232.0.247]) by core3.amsl.com (Postfix) with ESMTP id B897B3A6A8C; Sat, 26 Jul 2008 04:08:44 -0700 (PDT) Received: from 6-18-245-190.fibertel.com.ar ([190.245.18.6]:1099 "EHLO f3t" smtp-auth: "dvdmovies21072008" rhost-flags-OK-FAIL-OK-FAIL) by avas-mr15.fibertel.com.ar with ESMTPA id S474658AbYGZK63 convert rfc822-to-8bit; Sat, 26 Jul 2008 07:58:29 -0300 Message-ID: <3839-22008762655821359@f3t> To: "dvds" Errors-to: dvdmovies21072008_@gmail.com From: "dvdmovies21072008@gmail.com" Subject: DVD MOVIES NUEVOS TITULOS EN DVD Date: Sat, 26 Jul 2008 07:58:21 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8BIT X-Fib-Al-Info: Al X-Fib-Al-MRId: fe8778942cc7eb86eaa61b1144774a57 X-Fib-Al: noav X-Fib-Al-SA: analyzed X-Fib-Al-From: dvdmovies21072008@gmail.com NOVEDADES DVD MOVIES 21 de Julio!! SUPER ESTRENOS EN DVD dvdmovies21072008@gmail.com NO SON SCREEN DE CINE, son copia de DVD Pedidos a dvdmovies21072008@gmail.com Pida el Listado en Excell completo con mas de 1500 titulos 1424 Postdata te amo 1425 30 Dias de Noche 1426 27 Bodas 1427 10000 AC 1428 Los Dueños de la Noche 1429 El Buen Nombre 1430 Corazones 1431 La Educacion de las Hadas 1432 El Cantante 1433 Como Celebre el Fin del Mundo 1434 Hannah Montana en Accion 1435 Hitman Agente 47 1436 Sweeney Todd de Tim Burton con Jonnhy Deep 1437 Promesas del Este 1438 1408 (Pelicula) 1439 Corresponsales en Peligro 1440 Bobby Z 1441 Deuda (de Jorge Lanata) 1442 El Dirario de los Muertos 1443 Antes de Morir 1444 Las Cronicas de Spiderwick 1445 Orfanato 1446 Bolas de Fuego 1447 Cloverfield Monstruo 1448 La Dalia Negra 1449 Sin Lugar para Los Debiles 1450 Semi-Pro (Comedia excelente con Will Ferrell) 1451 Cleaner (con Samuel L Jackson) 1452 Los crímenes de Oxford (con Elijah Wood) 1453 My Mom's new Boyfriend (con Antonio Banderas y Meg Ryan) 1454 In Brudge (con Colin Farrell) 1455 The Children Of Huang Shi 1456 Funny Games US (con Naomi Watts, Tim Roth y Devon Gearhart) 1457 Mad Money (con Diane Keaton, Queen Latifah, Katie Holmes) 1458 Onion Movie 1459 Vantage Point (con Dennis Quaid) Para realizar un pedido desde CAPITAL FEDERAL nos tenes que pasar los titulos que queres (nombre y numero), y los siguientes datos Nombre: Direccion: TE: Fecha y horario de entrega: (con un margen de 3 Horas, por ejemplo de 9 a 12Hs) Para realizar un pedido desde GBA o interior, se realizan previo pago a traves de PagoFacil o Rapipago Al dia siguiente se acredita y te mandamos el numero de guia para que hagas el seguimiento Nos tenes que pasar ademas los titulos que queres, los siguientes datos Nombre y Apellido: Direccion: Ciudad: Codigo Postal: Provincia: TE: Saludos Maxi DVDMovies From mext-bounces@ietf.org Sun Jul 27 05:10:13 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D89C23A6884; Sun, 27 Jul 2008 05:10:13 -0700 (PDT) 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 6472B3A686D for ; Sun, 27 Jul 2008 05:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_71=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvvNs5+6nXl3 for ; Sun, 27 Jul 2008 05:10:11 -0700 (PDT) Received: from psmtp.com (exprod8ob120.obsmtp.com [64.18.3.39]) by core3.amsl.com (Postfix) with SMTP id 2FFCF3A6857 for ; Sun, 27 Jul 2008 05:10:09 -0700 (PDT) Received: from source ([193.221.170.178]) by exprod8ob120.postini.com ([64.18.7.12]) with SMTP; Sun, 27 Jul 2008 05:10:13 PDT Received: from HHBRUE006.hq.corp.eurocontrol.int (hhbrue006.hq.corp.eurocontrol.int [193.221.160.195]) by ecw.eurocontrol.int (8.12.10/8.12.7) with ESMTP id m6RCA44Z007939; Sun, 27 Jul 2008 14:10:07 +0200 (MEST) Received: from HHBRUE004.hq.corp.eurocontrol.int ([193.221.160.197]) by HHBRUE006.hq.corp.eurocontrol.int with Microsoft SMTPSVC(6.0.3790.3959); Sun, 27 Jul 2008 14:10:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 27 Jul 2008 14:10:03 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Location of HAs Thread-Index: Acju9UKWiT4z2hE3RuC7YboW0S98CAAA2z5vADoHADA= References: <488AD8E9.8080503@it.uc3m.es> From: "CERASI Eivan" To: , , X-OriginalArrivalTime: 27 Jul 2008 12:10:04.0810 (UTC) FILETIME=[B4164EA0:01C8EFE1] Subject: Re: [MEXT] Location of HAs 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 concur with Christian. An airline may wish to act as MSP for certain services. It may even be part of it's fleet in some regions of the globe. For ATS the situation may be different due the safety critical aspects. Some regions can have legislation that would impact the way these flows are enabled. The architecture should prevent this. Eivan -----Original Message----- From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Christian.Bauer@dlr.de Sent: Saturday 26 July 2008 10:30 To: marcelo@it.uc3m.es; mext@ietf.org Subject: Re: [MEXT] Location of HAs Hi, > In your draft you suggest that it would be possible for the airlines > to have their onw HA in their network (even if this is not the > desirable option according to you) I will talk about this during the presentation next week. But basically no one will forbid an airline to be its own Mobility Services Provider. > If they were to do that, in which network they would place the HA? In > the ANSP at their headquarters? The HAs would be located in the Airline Network(s, which in turn are connected to the ATN by ACSPs. > > regards, marcelo Christian _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext ____ This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful. Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy. Any views expressed in this message are those of the sender. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Jul 27 05:25:12 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 295F03A68B9; Sun, 27 Jul 2008 05:25:12 -0700 (PDT) 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 815D13A68B9 for ; Sun, 27 Jul 2008 05:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCdFxiMKHcjg for ; Sun, 27 Jul 2008 05:25:10 -0700 (PDT) Received: from exprod8og106.obsmtp.com (exprod8og106.obsmtp.com [64.18.3.92]) by core3.amsl.com (Postfix) with SMTP id 1F8123A68AA for ; Sun, 27 Jul 2008 05:25:08 -0700 (PDT) Received: from source ([193.221.170.178]) by exprod8ob106.postini.com ([64.18.7.12]) with SMTP; Sun, 27 Jul 2008 05:25:14 PDT Received: from HHBRUE006.hq.corp.eurocontrol.int (hhbrue006.hq.corp.eurocontrol.int [193.221.160.195]) by ecw.eurocontrol.int (8.12.10/8.12.7) with ESMTP id m6RCP94Z011069; Sun, 27 Jul 2008 14:25:10 +0200 (MEST) Received: from HHBRUE004.hq.corp.eurocontrol.int ([193.221.160.197]) by HHBRUE006.hq.corp.eurocontrol.int with Microsoft SMTPSVC(6.0.3790.3959); Sun, 27 Jul 2008 14:25:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 27 Jul 2008 14:25:08 +0200 Message-ID: In-Reply-To: <4888B578.7050009@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Thoughts on the different nemo ro approaches Thread-Index: Acjtrw/3UFjy46jwSHO9hUZbzYbdewCGkqrg References: <4888B578.7050009@it.uc3m.es> From: "CERASI Eivan" To: "marcelo bagnulo braun" , "mext" X-OriginalArrivalTime: 27 Jul 2008 12:25:09.0462 (UTC) FILETIME=[CF4D3F60:01C8EFE3] Subject: Re: [MEXT] Thoughts on the different nemo ro approaches 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, Thanks for this e-mail. I agree that the HAHA approach is less complex. More importantly, it minimizes changes on the MR which is a key benefit as we would avoid retro-fit of airborne components. The application of HAHA concept of foreign/local is a bit confusing for me, maybe it could be associated to administrative authorities whereby the local is your default MSP and foreign is an alternative MSP that is willing to perform some value-added services such as a binding for the MR. One of the downsides of HAHA is that the MR is excluded from the RO decision process and we lose any "RO triger" that we previously discussed. I also understand that it relies on DHAAD which may induce protocol overhead over radio links. Just thinking, maybe a route to investigate is to have some flag within MR packets to address these issues and allow the MR to play some role. Eivan -----Original Message----- From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of marcelo bagnulo braun Sent: Thursday 24 July 2008 19:02 To: mext Subject: [MEXT] Thoughts on the different nemo ro approaches Hi, I have been reading the drafts people have submitted for the nemo ro work for the aviation case. In particular, i have read draft-bauer-mext-aero-topology-00 draft-wakikawa-mext-haha-interop2008-00 draft-wakikawa-mext-cr-consideration-00 draft-wakikawa-nemo-orc-01 draft-thubert-mext-global-haha-00 draft-bernardos-mext-nemo-ro-cr-00 Essentially we have two different approaches, one based on distributed HAs and another one based on the concept of the correspondent router. It seems to me that the CR based approach is more complex than the ha based approach, so i guess that a first legitimate question to ask is where does the complexity springs from? One observation that i would like to contrast with the group is that the HA based approach makes the following fundamental assumption: A set of globally distributed anchor points that are within the _same_ administrative domain are available and are enough to provide the RO capabilities required. OTOH, the CR based approach makes a different assumption, which is that a set of distributed anchor points with which is possible to have a trust relationship are available and are enough to provide the RO capabilties required. The difference as i understand it, is that the HA based approach assumes that the anchor points are in the same admin domain (or that they are within domains with strong admin relationship, which allows them to do functions that are usually not acceptable across domains) and the CR based approach does not makes that assumption. By assuming that these anchor points are in the same admin domain, the HA based approach can take advantage of the following functions that are not available across domains (i may be missing some function): - anycast routing - host/MNP route injection to sink traffic for the proper anchor point. - strong state synchronization between HAs/anchor points The usage of these tools indeed make life easier, but they impose some constraints. I think that we need to understand these constraints, and figure out whether they are acceptable for the aviation community. In other words, i think that a relevant exercise at this point is to try to figure out how a HA based approach can be deployed within the aviation scenario described in draft-bauer-mext-aero-topology-00 So, let's consider how this could be deployed. A first deployment scenario would be that the HAs are deployed within a gACSP. This seems like the perfect match. The gACSP has global infrastructure, so it can be assumed to have HAs distributed along the globe and they can provide reasonable good enough rute optimization. So, if an aricraft is using the gACSP all the way, this seems to work reasonably. A first question may be posed though in this scenario about addressing. From which prefix the MNP is extracted from? I mean, one option is that the gACSP has a prefix for this, and uses it to assign to all the different companies that it serves. However, this would result in a form of provider dependent addressing and maybe the problems of provider dependent addressing would rise here. In other words, is it ok for the aviation companies to use a prefix that is owned by the gASCP? This basically means that if they want to change the provider (i don't know if this is possible), they will need to renumber. A related question to this one, about what is the normal relation between the aviation company and the gASCP? Is it normal that a given aviation company works with one or both the gACSP that exists? If they work with one, the provide lock in effect could be an issue. If they work with two, then would this approach implies that they need to have two prefixes, one for each gACSP? That would probably be problematic from the network management perspective. In both cases, either if they decide to use two prefixes, or they use a single gACSP with only one prefix, the next question is whether they can acquire a CoA from the other gACSP? if they can, it is possible that the gACSP performs cold potato routing and the RO benefits are not achieved. The other option of course is that the aviation companies have a provider indepedent prefix and that the gACSP announces it on behalf of their clients. In this case both gACSP can announce the client prefix. The potential issue here is what is the impact for the global routing table of such practice. A second scenario is where other than gASCP are considered. At this point, i don't even grasp how the scenarios are. For instance, is it possible that some airlines do not have any relationship with any of the two gASCP? In that case, they only have contracts with smaller providers and in that case i this not clear to me how the ha infrastructure can be deployed. I mean, would this imply that each of the smaller players will have a HA and they would run HAHA protocol between them? I don't know if the implications of these are acceptable for the relationship that those players have. One particular case where this is significant is when the communication with the gACSP is down for whatever reason. If this is the case, and the HA infrastrucutre is not reachable, the direct communication between the aircraft and the CNs that are directly attached to the same ACSP is not possible, even if they have direct connectivity. I am not sure if this is acceptable. So, imho, what needs to be understood a bit more in depth is the possible deployment models of a HA based approach in the aviation reality. I am hoping that we can have this discussion in dublin Regards, marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext ____ This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful. Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy. Any views expressed in this message are those of the sender. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Jul 27 15:42:55 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A28C33A6A00; Sun, 27 Jul 2008 15:42:55 -0700 (PDT) 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 E68223A6A00 for ; Sun, 27 Jul 2008 15:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bq0bcFgokN8Z for ; Sun, 27 Jul 2008 15:42:48 -0700 (PDT) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id 3D0413A6974 for ; Sun, 27 Jul 2008 15:42:48 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 3AD96328014 for ; Sun, 27 Jul 2008 17:42:56 -0500 (CDT) Received: from ndjsxgw04.ndc.nasa.gov (ndjsxgw04.ndc.nasa.gov [129.166.32.112]) by ndjsppt03.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id m6RMgub2023885 for ; Sun, 27 Jul 2008 17:42:56 -0500 Received: from NDJSEVS25A.ndc.nasa.gov ([129.166.32.124]) by ndjsxgw04.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.3959); Sun, 27 Jul 2008 17:42:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 27 Jul 2008 17:42:55 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-bauer-mext-aero-topology-00 Thread-Index: AcjwOhyA2GRdhNDhSEm58P9mc2peFA== From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: X-OriginalArrivalTime: 27 Jul 2008 22:42:56.0247 (UTC) FILETIME=[1CD3C870:01C8F03A] Subject: [MEXT] draft-bauer-mext-aero-topology-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: multipart/mixed; boundary="===============0792959857==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============0792959857== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8F03A.1C87A93D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8F03A.1C87A93D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think this draft is a very positive contribution to the WG, and = subsequent revisions and discussions around the draft will help us to bridge the = gaps between IETF and the aero folks. =20 A few comments I have for discussion are: =20 1) In section 3.2, referring to the "lACSP #3" node in FIgure 1, the = text describes it as being "an airport data link operated by the airport = company, although this is not existing by the time this was written." =20 My question is, does this refer to Gatelink (or Wireless Gatelink), and = if so, doesn't that already exist? =20 2) Is it worth saying specifically that the 2 global ACSPs that = currently exist are specialized providers (ARINC and SITA) and not typical telecom service providers? To me, this has 2 benefits: (a) it makes us consider the operational impact of our solution on this kind of niche provider compared to a typical telecom provider with differing business and technology cycles, and (b) it may make the *potential* for use of the Internet through commodity providers as a lower-cost alternative to link ANSPs and/or provide ground-ground transport between data link ground stations and other sites. =20 3) In 3.3.2 on AOS, the "..." is used to represent the possibility of multiple networks between 2 nodes; can the Internet be one? If there is even a possibility of that, then we should mention it. This would further motivate solutions that play nice with global BGP operations, beyond what has already been stated in the requirements draft. =20 =20 ------_=_NextPart_001_01C8F03A.1C87A93D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
I think this draft is a = very positive contribution to the WG, and subsequent
=0A=
revisions and discussions around the = draft will help us to bridge the gaps
=0A=
between IETF and the aero = folks.
=0A=
 
=0A=
A few comments I have for discussion = are:
=0A=
 
=0A=
1) In section 3.2, referring to the = "lACSP #3" node in FIgure 1, the text
=0A=
describes it as being "an airport data = link operated by the airport company,
=0A=
although this is not existing by the = time this was written."
=0A=
 
=0A=
My question is, does this refer to = Gatelink (or Wireless Gatelink), and if
=0A=
so, doesn't that already = exist?
=0A=
 
=0A=
2) Is it worth saying specifically that = the 2 global ACSPs that currently
=0A=
exist are specialized providers (ARINC = and SITA) and not typical telecom
=0A=
service providers?  To me, this = has 2 benefits: (a) it makes us consider
=0A=
the operational impact of our solution = on this kind of niche provider
=0A=
compared to a typical telecom provider = with differing business and
=0A=
technology cycles, and (b) it may make = the *potential* for use of the
=0A=
Internet through commodity providers as = a lower-cost alternative to link
=0A=
ANSPs and/or provide ground-ground = transport between data link ground
=0A=
stations and other = sites.
=0A=
 
=0A=
3) In 3.3.2 on AOS, the "..." is used = to represent the possibility of
=0A=
multiple networks between 2 nodes; can = the Internet be one?  If there
=0A=
is even a possibility of that, then we = should mention it.  This would
=0A=
further motivate solutions that play = nice with global BGP operations,
=0A=
beyond what has already been stated in = the requirements draft.
=0A=
 
=0A=
 
------_=_NextPart_001_01C8F03A.1C87A93D-- --===============0792959857== 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 --===============0792959857==-- From mext-bounces@ietf.org Sun Jul 27 16:03:50 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9064E3A6A0C; Sun, 27 Jul 2008 16:03:50 -0700 (PDT) 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 1E4753A6A13 for ; Sun, 27 Jul 2008 16:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJAaEgChDZLx for ; Sun, 27 Jul 2008 16:03:48 -0700 (PDT) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id 108953A6A0C for ; Sun, 27 Jul 2008 16:03:48 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 32A0632800A for ; Sun, 27 Jul 2008 18:03:56 -0500 (CDT) Received: from ndjsxgw04.ndc.nasa.gov (ndjsxgw04.ndc.nasa.gov [129.166.32.112]) by ndjsppt03.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id m6RN3u1M008229 for ; Sun, 27 Jul 2008 18:03:56 -0500 Received: from NDJSEVS25A.ndc.nasa.gov ([129.166.32.124]) by ndjsxgw04.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.3959); Sun, 27 Jul 2008 18:03:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 27 Jul 2008 18:03:55 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: correspondent router drafts Thread-Index: AcjwPQuL14ksydTaRkm9H43FxTVrtw== From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: X-OriginalArrivalTime: 27 Jul 2008 23:03:56.0208 (UTC) FILETIME=[0BD29300:01C8F03D] Subject: [MEXT] correspondent router drafts 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="===============1468163551==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============1468163551== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8F03D.0B8B1894" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8F03D.0B8B1894 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This includes comments on draft-bernardos-mext-nemo-ro-cr-00 and draft-wakikawa-mext-cr-consideration-00. =20 Both of these are great contributions, in my opinion, the first gives a requirement-by-requirement analysis of the CR approach for aero use, that I largely agree with. =20 For the CR solution possibility, I was thinking there would be a small number of CRs with each ANSP, with under a hundred total. I think it would be possible to configure the list of these in an MR initially = as a static configuration, and update it using some new message from the HA that informs it of changes to the set of CRs. This would assume that as operational entities bring CRs online or take them offline that they communicate those changes to each other, and the changes would be pushed from the HAs to the MRs. The nice thing about this is that it is much less overhead than trying to have the MR discover CRs itself, or having the CRs somehow discover the MR's traffic, both of which seem doomed to me. =20 The criticisms with the CR approach that Ryuji's draft brings forward are all credible, but I see most of them as more related to general Internet use of the CR approach, rather than specific to aviation. I believe the CR approach is feasible for the aviation world's = constraints. HOWEVER, if it doesn't work for other industries, it violates one of our listed "desirable features", so I believe that finding out if CR can be made to work for other industries needs to be explored now. As I understand, the global HAHA approach has some desirability to other (larger) industries, which gives it a major advantage. =20 One idea I had after reading Ryuji's explanation of the problem of selecting an egress CR from a site is that it may be possible to leverage the possibility to aggregate aero IPv6 addresses in order to reduce the impact of routing advertisements for the MNPs. I know at one point Terry Davis was working with ICAO to request an IPv6 allocation to be used for aeronautics, and this block would be cut up between the various stakeholders. It might be possible to have all the MNPs drawn from the same block so that the routes would aggregate. This doesn't totally remove the problem, though, but it may make it simpler. =20 =20 ------_=_NextPart_001_01C8F03D.0B8B1894 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
This includes comments = on draft-bernardos-mext-nemo-ro-cr-00 and
=0A=
draft-wakikawa-mext-cr-consideration-00.
=0A=
 
=0A=
Both of these are great contributions, = in my opinion, the first gives a
=0A=
requirement-by-requirement analysis of = the CR approach for aero
=0A=
use, that I largely agree = with.
=0A=
 
=0A=
For the CR solution possibility, I was = thinking there would be a small
=0A=
number of CRs with each ANSP, with = under a hundred total.  I think
=0A=
it would be possible to configure the = list of these in an MR initially as
=0A=
a static configuration, and update it = using some new message from
=0A=
the HA that informs it of changes to = the set of CRs.  This would assume
=0A=
that as operational entities bring CRs = online or take them offline that
=0A=
they communicate those changes to each = other, and the changes
=0A=
would be pushed from the HAs to the = MRs.  The nice thing about this
=0A=
is that it is much less overhead than = trying to have the MR discover
=0A=
CRs itself, or having the CRs somehow = discover the MR's traffic, both
=0A=
of which seem doomed to me.
=0A=
 
=0A=
The criticisms with the CR approach = that Ryuji's draft brings forward
=0A=
are all credible, but I see most of = them as more related to general
=0A=
Internet use of the CR approach, rather = than specific to aviation.  I
=0A=
believe the CR approach is feasible for = the aviation world's constraints.
=0A=
HOWEVER, if it doesn't work for other = industries, it violates one of
=0A=
our listed "desirable features", so I = believe that finding out if CR can
=0A=
be made to work for other industries = needs to be explored now.  As
=0A=
I understand, the global HAHA = approach has some desirability to
=0A=
other (larger) industries, which gives = it a major advantage.
=0A=
 
=0A=
One idea I had after reading Ryuji's = explanation of the problem of
=0A=
selecting an egress CR from a site is = that it may be possible to
=0A=
leverage the possibility to aggregate = aero IPv6 addresses in order
=0A=
to reduce the impact of routing = advertisements for the MNPs.  I
=0A=
know at one point Terry Davis was = working with ICAO to request
=0A=
an IPv6 allocation to be used for = aeronautics, and this block would
=0A=
be cut up between the various = stakeholders.  It might be possible
=0A=
to have all the MNPs drawn from the = same block so that the routes
=0A=
would aggregate.  This doesn't = totally remove the problem, though,
=0A=
but it may make it simpler.
=0A=
 
=0A=
 
------_=_NextPart_001_01C8F03D.0B8B1894-- --===============1468163551== 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 --===============1468163551==-- From mext-bounces@ietf.org Mon Jul 28 01:17:03 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08F5B3A6AE2; Mon, 28 Jul 2008 01:17:03 -0700 (PDT) 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 A17293A6ADF for ; Mon, 28 Jul 2008 01:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.639 X-Spam-Level: X-Spam-Status: No, score=-0.639 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wANdyq4M5rUG for ; Mon, 28 Jul 2008 01:17:00 -0700 (PDT) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.228]) by core3.amsl.com (Postfix) with ESMTP id 308FC3A696B for ; Mon, 28 Jul 2008 01:17:00 -0700 (PDT) Received: by qb-out-0506.google.com with SMTP id z8so539288qbc.41 for ; Mon, 28 Jul 2008 01:17:09 -0700 (PDT) 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=0i7vzM4j8zKQU9URStlwhnAc6u0GabFDTLPYGalNl2k=; b=MydkjZetZfOs/0GgS7Z9X53yjpS2zftqa+zhYd2J0E3z/XNNdkf8g0puS/1LZJMdiF dDNbIRYqAfeGw5QMKtWe4lxy4Bh0Opv6mey63nZPebJLGIQ8fWEX73unbQ50GSBu+nbY 0DUAuvENCaPMeHV0mJGnG+uoW4WgrKB+MyYEM= 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=GnWDv19+Eq8L3N3l9juzptq+mL+0DY41t/Q7icyklVdfZ373HIY0IvIk0xdH5jGwdD 0s4PHfa9BPvg4m7qwE7DpcdzQUN8Nutxy4zrSRem8EBpdTm4T+t7giVPDfPu7vz5LLXd mcz++mTBWRtudLcqB8v8hphB3sveTGsNzowyA= Received: by 10.114.152.17 with SMTP id z17mr4572098wad.63.1217233028666; Mon, 28 Jul 2008 01:17:08 -0700 (PDT) Received: from ?172.17.3.147? ( [130.129.64.64]) by mx.google.com with ESMTPS id k23sm21492095waf.22.2008.07.28.01.17.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 28 Jul 2008 01:17:07 -0700 (PDT) From: Ryuji Wakikawa To: marcelo bagnulo braun In-Reply-To: <4888B578.7050009@it.uc3m.es> References: <4888B578.7050009@it.uc3m.es> Message-Id: <8F8C6F2D-639A-44E1-A16B-9F3678EB6236@gmail.com> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Mon, 28 Jul 2008 17:17:02 +0900 X-Mailer: Apple Mail (2.928.1) Cc: mext Subject: Re: [MEXT] Thoughts on the different nemo ro approaches 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Marcelo, Thanks for summary. On 2008/07/25, at 2:01, marcelo bagnulo braun wrote: > Hi, > > I have been reading the drafts people have submitted for the nemo ro > work for the aviation case. > In particular, i have read > > draft-bauer-mext-aero-topology-00 > draft-wakikawa-mext-haha-interop2008-00 > draft-wakikawa-mext-cr-consideration-00 > draft-wakikawa-nemo-orc-01 > draft-thubert-mext-global-haha-00 > draft-bernardos-mext-nemo-ro-cr-00 > > Essentially we have two different approaches, one based on > distributed HAs and another one based on the concept of the > correspondent router. > It seems to me that the CR based approach is more complex than the > ha based approach, so i guess that a first legitimate question to > ask is where does the complexity springs from? > One observation that i would like to contrast with the group is that > the HA based approach makes the following fundamental assumption: A > set of globally distributed anchor points that are within the _same_ > administrative domain are available and are enough to provide the RO > capabilities required. > > OTOH, the CR based approach makes a different assumption, which is > that a set of distributed anchor points with which is possible to > have a trust relationship are available and are enough to provide > the RO capabilties required. > > The difference as i understand it, is that the HA based approach > assumes that the anchor points are in the same admin domain (or that > they are within domains with strong admin relationship, which allows > them to do functions that are usually not acceptable across domains) > and the CR based approach does not makes that assumption. > > By assuming that these anchor points are in the same admin domain, > the HA based approach can take advantage of the following functions > that are not available across domains (i may be missing some > function): > - anycast routing > - host/MNP route injection to sink traffic for the proper anchor > point. what's differences of these two? IMO, Anycast routing is used to sink traffic for the propose anchor point. > - strong state synchronization between HAs/anchor points There are several approaches to sync MN's state. As described in Pascal's ID, there are several approaches how to manage MN's state such as on-demand, proactive, even predictive mode. Airflights' movements can be easily traced and expected, there are many ways to optimize this state sync functionality. > The usage of these tools indeed make life easier, but they impose > some constraints. > I think that we need to understand these constraints, and figure out > whether they are acceptable for the aviation community. In other > words, i think that a relevant exercise at this point is to try to > figure out how a HA based approach can be deployed within the > aviation scenario described in draft-bauer-mext-aero-topology-00 > > So, let's consider how this could be deployed. > > A first deployment scenario would be that the HAs are deployed > within a gACSP. This seems like the perfect match. The gACSP has > global infrastructure, so it can be assumed to have HAs distributed > along the globe and they can provide reasonable good enough rute > optimization. So, if an aricraft is using the gACSP all the way, > this seems to work reasonably. A first question may be posed though > in this scenario about addressing. From which prefix the MNP is > extracted from? I mean, one option is that the gACSP has a prefix > for this, and uses it to assign to all the different companies that > it serves. However, this would result in a form of provider > dependent addressing and maybe the problems of provider dependent > addressing would rise here. In other words, is it ok for the > aviation companies to use a prefix that is owned by the gASCP? This > basically means that if they want to change the provider (i don't > know if this is possible), they will need to renumber. > A related question to this one, about what is the normal relation > between the aviation company and the gASCP? Is it normal that a > given aviation company works with one or both the gACSP that exists? > If they work with one, the provide lock in effect could be an issue. > If they work with two, then would this approach implies that they > need to have two prefixes, one for each gACSP? That would probably > be problematic from the network management perspective. In both > cases, either if they decide to use two prefixes, or they use a > single gACSP with only one prefix, the next question is whether they > can acquire a CoA from the other gACSP? if they can, it is possible > that the gACSP performs cold potato routing and the RO benefits are > not achieved. agree on deploying HAs in gACSP. I also want to know the relationship of gASCP, ASCP, ANSP and aviation companies. Are there any peering points such as IX in aviation networks? > > The other option of course is that the aviation companies have a > provider indepedent prefix and that the gACSP announces it on behalf > of their clients. > In this case both gACSP can announce the client prefix. The > potential issue here is what is the impact for the global routing > table of such practice. I think this is reasonable approach for aviation case. do you see any potential issue? We inject HAHA experimental prefix from different ISPs(i.e. AS) to BGP. We don't have any issues so far. > > > A second scenario is where other than gASCP are considered. > At this point, i don't even grasp how the scenarios are. For > instance, is it possible that some airlines do not have any > relationship with any of the two gASCP? In that case, they only have > contracts with smaller providers and in that case i this not clear > to me how the ha infrastructure can be deployed. I mean, would this > imply that each of the smaller players will have a HA and they would > run HAHA protocol between them? I don't know if the implications of > these are acceptable for the relationship that those players have. It is very important to know WHO will manage HA. I am not sure each airline company will operate HA by themselves.. > > One particular case where this is significant is when the > communication with the gACSP is down for whatever reason. If this is > the case, and the HA infrastrucutre is not reachable, the direct > communication between the aircraft and the CNs that are directly > attached to the same ACSP is not possible, even if they have direct > connectivity. I am not sure if this is acceptable. Do we need to discuss this redundancy requirement in this RO discussion? As I mentioned in the other mails, this is not correct behavior of MobileIP/NEMO. Both protocols rely on HA reliability and requires HA accessibility in order to provide mobility support. That's why we are working on HA reliability protocol (local redundancy) and globalHAHA (global redundancy). BTW, I don't think we should consider the case of gACSP down. Is this realistic scenarios? If so, shall I return to Japan by sailing!? regards, ryuji > So, imho, what needs to be understood a bit more in depth is the > possible deployment models of a HA based approach in the aviation > reality. I am hoping that we can have this discussion in dublin > > Regards, marcelo > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 28 02:35:32 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A08C3A68FA; Mon, 28 Jul 2008 02:35:32 -0700 (PDT) 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 84C4F3A6893 for ; Mon, 28 Jul 2008 02:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[AWL=0.980, 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 gGO9kizfMCK9 for ; Mon, 28 Jul 2008 02:35:26 -0700 (PDT) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.236]) by core3.amsl.com (Postfix) with ESMTP id C4C8E3A68FA for ; Mon, 28 Jul 2008 02:35:25 -0700 (PDT) Received: by qb-out-0506.google.com with SMTP id z8so544530qbc.41 for ; Mon, 28 Jul 2008 02:35:34 -0700 (PDT) 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=hbC7pUS1ewKsTdYtwmT/o+KufFpYnAIMprZHXSXeVrA=; b=NlaYqGpfqrrHBtxu1tTpH0P7JZshJsUVGTDYV9fB7KGIEm8KBY253ipskYBNfV6iPx PhFaXDCMGGG0tzRacaL0opbgdwsRHk5uuOYoYAxYa5/nhYvmAnXhFNDvXQQvGRyyHLNF mIQI7Cyv9iHWou7LqMZ8//K1XkG42j3AF8TeM= 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=Fh0e8djBFYy/uCbChr33Mbp+XFiHz4DsJdCK/VBNPXFuhs+aoyr3ZYlV216c4i3TEk XVGo96gmFiCVJLuAYIif7+ftFnVuOngh3xTBgCSJ+e6qCHhcRKL5URdKCN77c/ipxpJd z6615yiWRW4kn4KdJqTcucN7+czmRZVoPvEik= Received: by 10.114.194.1 with SMTP id r1mr4630952waf.205.1217237734359; Mon, 28 Jul 2008 02:35:34 -0700 (PDT) Received: from ryujibookpro.meeting.ietf.org ( [130.129.19.206]) by mx.google.com with ESMTPS id m31sm17890172wag.21.2008.07.28.02.35.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 28 Jul 2008 02:35:33 -0700 (PDT) From: Ryuji Wakikawa To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" In-Reply-To: References: Message-Id: <2F47249F-394B-4567-8415-9DDCA47A7D8D@gmail.com> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Mon, 28 Jul 2008 18:35:29 +0900 X-Mailer: Apple Mail (2.928.1) Cc: mext@ietf.org Subject: Re: [MEXT] correspondent router drafts 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Eddy, Thanks for comments, please find my reply inline. On 2008/07/28, at 8:03, Eddy, Wesley M. (GRC-RCN0)[VZ] wrote: > This includes comments on draft-bernardos-mext-nemo-ro-cr-00 and > draft-wakikawa-mext-cr-consideration-00. > > Both of these are great contributions, in my opinion, the first > gives a > requirement-by-requirement analysis of the CR approach for aero > use, that I largely agree with. > > For the CR solution possibility, I was thinking there would be a small > number of CRs with each ANSP, with under a hundred total. I think > it would be possible to configure the list of these in an MR > initially as > a static configuration, and update it using some new message from > the HA that informs it of changes to the set of CRs. This would > assume > that as operational entities bring CRs online or take them offline > that > they communicate those changes to each other, and the changes > would be pushed from the HAs to the MRs. The nice thing about this > is that it is much less overhead than trying to have the MR discover > CRs itself, or having the CRs somehow discover the MR's traffic, both > of which seem doomed to me. When I was working on the Optimized Route Cache (ORC) protocol (one of CR solution submitted a long time ago), we tried several approaches to discover CR, using DNS, anycast, and even static configuration! If MR pre-knows a set of CNs, setting up CR info locally and statically is the easiest approach. > The criticisms with the CR approach that Ryuji's draft brings forward > are all credible, but I see most of them as more related to general > Internet use of the CR approach, rather than specific to aviation. I > believe the CR approach is feasible for the aviation world's > constraints. > HOWEVER, if it doesn't work for other industries, it violates one of > our listed "desirable features", so I believe that finding out if CR > can > be made to work for other industries needs to be explored now. As > I understand, the global HAHA approach has some desirability to > other (larger) industries, which gives it a major advantage. Yes, my document analysis CR issues in general scenarios. I see there are plenty of assumptions in aviation industry. We must be very careful to standardize a RO solution if there are piles of assumptions (which are only available in aviation industry). Please imagine if somebody deploys that RO solution without expected assumptions, it breaks the protocol behavior and might brings security threats. Another question is whether an RO solution is only for aviation industry or not. Will ATS be inter-connected to other infrastructures and consider the interoperability in a near future? If we have a CR based solution only for aviation industry, I believe it should be somehow capable of operation in general scenarios, too. > One idea I had after reading Ryuji's explanation of the problem of > selecting an egress CR from a site is that it may be possible to > leverage the possibility to aggregate aero IPv6 addresses in order > to reduce the impact of routing advertisements for the MNPs. I > know at one point Terry Davis was working with ICAO to request > an IPv6 allocation to be used for aeronautics, and this block would > be cut up between the various stakeholders. It might be possible > to have all the MNPs drawn from the same block so that the routes > would aggregate. This doesn't totally remove the problem, though, > but it may make it simpler. Very interesting. if aviation industry obtains a prefix chunk for all flights, we can do more optimization in solution space in terms of aggregation, route injection, etc. regards, ryuji > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 28 02:45:42 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DA443A6895; Mon, 28 Jul 2008 02:45:42 -0700 (PDT) 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 299853A6895 for ; Mon, 28 Jul 2008 02:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7cCHii86Ind for ; Mon, 28 Jul 2008 02:45:40 -0700 (PDT) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id 2BFEC3A6809 for ; Mon, 28 Jul 2008 02:45:40 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 31DB0328125; Mon, 28 Jul 2008 04:45:49 -0500 (CDT) Received: from ndjsxgw04.ndc.nasa.gov (ndjsxgw04.ndc.nasa.gov [129.166.32.112]) by ndjsppt02.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id m6S9jn6W028215; Mon, 28 Jul 2008 04:45:49 -0500 Received: from NDJSEVS25A.ndc.nasa.gov ([129.166.32.124]) by ndjsxgw04.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Jul 2008 04:45:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 04:43:27 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] correspondent router drafts Thread-Index: AcjwlUqA/IlAbvq5SfSaCMMcBMamMgAARh7o References: <2F47249F-394B-4567-8415-9DDCA47A7D8D@gmail.com> From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: "Ryuji Wakikawa" X-OriginalArrivalTime: 28 Jul 2008 09:45:49.0216 (UTC) FILETIME=[B75D3A00:01C8F096] Cc: mext@ietf.org Subject: Re: [MEXT] correspondent router drafts 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="===============0510220330==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============0510220330== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8F096.B6CAF1B5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8F096.B6CAF1B5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This document from a recent ICAO meeting seems to indicate that's still = the plan: =20 http://www.icao.int/anb/panels/acp/wg/i/wgi7/ACP-WGI07-WP02-Draft%20ICAO%= 20IPv6%20Addressing%20Plan.doc =20 ________________________________ From: Ryuji Wakikawa [mailto:ryuji.wakikawa@gmail.com] Sent: Mon 7/28/2008 4:35 AM To: Eddy, Wesley M. (GRC-RCN0)[VZ] Cc: mext@ietf.org Subject: Re: [MEXT] correspondent router drafts Very interesting. if aviation industry obtains a prefix chunk for all flights, we can do=20 more optimization in solution space in terms of aggregation, route=20 injection, etc. ------_=_NextPart_001_01C8F096.B6CAF1B5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [MEXT] correspondent router = drafts=0A= =0A= =0A= =0A=
=0A=
This document = from a recent ICAO meeting seems to indicate that's still the = plan:
=0A=
 
=0A= =0A=

 
=0A=
=0A=
=0A=
=0A=
From: Ryuji Wakikawa = [mailto:ryuji.wakikawa@gmail.com]
Sent: Mon 7/28/2008 4:35 = AM
To: Eddy, Wesley M. (GRC-RCN0)[VZ]
Cc: = mext@ietf.org
Subject: Re: [MEXT] correspondent router = drafts

=0A=
=0A=


Very interesting.
if aviation industry obtains = a prefix chunk for all flights, we can do 
more optimization in = solution space in terms of aggregation, route 
injection, = etc.

------_=_NextPart_001_01C8F096.B6CAF1B5-- --===============0510220330== 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 --===============0510220330==-- From mext-bounces@ietf.org Mon Jul 28 02:48:52 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D43B33A6910; Mon, 28 Jul 2008 02:48:51 -0700 (PDT) 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 3A7DE3A69B9 for ; Mon, 28 Jul 2008 02:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggC6J8oa5NAA for ; Mon, 28 Jul 2008 02:48:49 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id D80353A6809 for ; Mon, 28 Jul 2008 02:48:47 -0700 (PDT) Received: from [130.129.23.64] (unknown [130.129.23.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id B9DE8425C91; Mon, 28 Jul 2008 11:48:54 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Ryuji Wakikawa In-Reply-To: <2F47249F-394B-4567-8415-9DDCA47A7D8D@gmail.com> References: <2F47249F-394B-4567-8415-9DDCA47A7D8D@gmail.com> Organization: Universidad Carlos III de Madrid Date: Mon, 28 Jul 2008 11:48:52 +0200 Message-Id: <1217238532.26923.15.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: mext@ietf.org Subject: Re: [MEXT] correspondent router drafts X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1614375651==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1614375651== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Fl8qpk8mRmpp7os7+gcU" --=-Fl8qpk8mRmpp7os7+gcU Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Ryuji, (some text skipped) > Yes, my document analysis CR issues in general scenarios. > I see there are plenty of assumptions in aviation industry. >=20 > We must be very careful to standardize a RO solution if there are =20 > piles of assumptions (which are only available in aviation industry). > Please imagine if somebody deploys that RO solution without expected =20 > assumptions, it breaks the protocol behavior and might brings security =20 > threats. >=20 > Another question is whether an RO solution is only for aviation =20 > industry or not. > Will ATS be inter-connected to other infrastructures and consider the =20 > interoperability in a near future? > If we have a CR based solution only for aviation industry, I believe =20 > it should be somehow capable of operation in general scenarios, too. I guess the WG is chartered to work on a solution for the aviation industry (not to work on a generic NEMO RO solution). I completely agree that it'd be much better to have a generic solution (covering other scenarios), though my feeling is that this would be harder (not even know if feasible), given the particular requirements of the aviation industry. Regards, Carlos --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-Fl8qpk8mRmpp7os7+gcU Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkiNlgQACgkQNdy6TdFwT2f0hACfQP6oNGGee13KSW4xz0AM+9pP 1XsAniYpAUt9nvQUuNmm5P4Jxm85P90Q =fBLL -----END PGP SIGNATURE----- --=-Fl8qpk8mRmpp7os7+gcU-- --===============1614375651== 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 --===============1614375651==-- From mext-bounces@ietf.org Mon Jul 28 02:52:14 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DFF63A6904; Mon, 28 Jul 2008 02:52:14 -0700 (PDT) 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 537B43A6904 for ; Mon, 28 Jul 2008 02:52:13 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3H5J7ywA15k2 for ; Mon, 28 Jul 2008 02:52:07 -0700 (PDT) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.234]) by core3.amsl.com (Postfix) with ESMTP id BB1C13A6809 for ; Mon, 28 Jul 2008 02:52:07 -0700 (PDT) Received: by qb-out-0506.google.com with SMTP id z8so545617qbc.41 for ; Mon, 28 Jul 2008 02:52:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:to:subject:date:user-agent:cc :mime-version:content-type:content-transfer-encoding :content-disposition:message-id:from; bh=4P+r2Qcr6mA4TadOUWNGcgN1lk1kAe/fNbUaihtj9x4=; b=kdlGDwT4eNAjDVSQ/WEu/HCCK2ckUacw3CDfmwCHHziU3jokj3WscTvVxu8mi3cYRC iKZVTloUPkJEjoPVchHOYEMXGICB4l4YcJTi16IyweqY7mz8VERjKvndZT6yoc3DLFZ4 qJNXoxOdolms7Yy5VhWCQApNbLXa3fh16jwUA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=to:subject:date:user-agent:cc:mime-version:content-type :content-transfer-encoding:content-disposition:message-id:from; b=Ylke/cTVTNy8WKpTRt0EvS3q4MO0YpNiS1fH/RDZAlofowjygl+RsjSZ8FYddgY1j4 Zf0n9CfWojBcvfY6qkBKcP4/L7XwEPyZqTrk/bcXk7zkZPU7IB5EIM9NjQpKG0su5PYc fTidCUV+48O1y9x3gYQziprJnWn0pasIarL5I= Received: by 10.114.109.1 with SMTP id h1mr4651349wac.35.1217238736508; Mon, 28 Jul 2008 02:52:16 -0700 (PDT) Received: from klee.meeting.ietf.org ( [130.129.23.54]) by mx.google.com with ESMTPS id v25sm17801616wah.36.2008.07.28.02.52.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 28 Jul 2008 02:52:15 -0700 (PDT) To: mext@ietf.org Date: Mon, 28 Jul 2008 11:52:11 +0200 User-Agent: KMail/1.9.6 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200807281152.11292.julien.laganier.IETF@googlemail.com> From: Julien Laganier Subject: [MEXT] MEXT Presenters 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 send your presentations to Marcelo and me before 14:00 today for today's session, and before 11:00 tomorrow for tomorrow's session. This is required for remotes participants to have access to meeting material. Thank you for your support. --julien & marcelo [ New email address: julien.laganier.IETF@googlemail.com ] _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 28 03:02:04 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF4EE3A68DD; Mon, 28 Jul 2008 03:02:04 -0700 (PDT) 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 4DC2C3A691B for ; Mon, 28 Jul 2008 03:02:03 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVUkJH1KWA56 for ; Mon, 28 Jul 2008 03:02:02 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id E50893A6895 for ; Mon, 28 Jul 2008 03:02:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,265,1215381600"; d="vcf'?scan'208";a="15569399" Received: from unknown (HELO chokaisan.local) ([130.129.20.12]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jul 2008 12:02:09 +0200 Message-ID: <488D991F.9040800@inria.fr> Date: Mon, 28 Jul 2008 12:02:07 +0200 From: Thierry Ernst Organization: INRIA User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <2F47249F-394B-4567-8415-9DDCA47A7D8D@gmail.com> <1217238532.26923.15.camel@localhost> In-Reply-To: <1217238532.26923.15.camel@localhost> Content-Type: multipart/mixed; boundary="------------080906020809080506000109" Cc: mext@ietf.org Subject: Re: [MEXT] correspondent router drafts 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. --------------080906020809080506000109 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit No, Carlos, at this point in time the WG missions is about collecting requirements for uses cases and understands the open issues. The charter is not saying that separate solutions will be developed for different use cases. A solution that solve the same problems for all studied use case is preferable though we may not have the choice. At least this is were we were standing on when the NEMO WG charter was revised just before WGs were merged together. Thierry. Carlos Jesús Bernardos Cano wrote: > Hi Ryuji, > > (some text skipped) > > >> Yes, my document analysis CR issues in general scenarios. >> I see there are plenty of assumptions in aviation industry. >> >> We must be very careful to standardize a RO solution if there are >> piles of assumptions (which are only available in aviation industry). >> Please imagine if somebody deploys that RO solution without expected >> assumptions, it breaks the protocol behavior and might brings security >> threats. >> >> Another question is whether an RO solution is only for aviation >> industry or not. >> Will ATS be inter-connected to other infrastructures and consider the >> interoperability in a near future? >> If we have a CR based solution only for aviation industry, I believe >> it should be somehow capable of operation in general scenarios, too. >> > > I guess the WG is chartered to work on a solution for the aviation > industry (not to work on a generic NEMO RO solution). I completely agree > that it'd be much better to have a generic solution (covering other > scenarios), though my feeling is that this would be harder (not even > know if feasible), given the particular requirements of the aviation > industry. > > Regards, > > Carlos > > > ------------------------------------------------------------------------ > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > --------------080906020809080506000109 Content-Type: text/x-vcard; charset=utf-8; name="thierry_ernst.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="thierry_ernst.vcf" begin:vcard fn:Thierry Ernst n:Ernst;Thierry org:INRIA Rocquencourt;IMARA - LARA adr:;;;;;;France tel;work:+33 1 39 63 59 30 tel;fax:+33 1 39 63 54 91 tel;cell:+33 6 76 56 25 96 url:http://www.lara.prd.fr version:2.1 end:vcard --------------080906020809080506000109 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 --------------080906020809080506000109-- From mext-bounces@ietf.org Mon Jul 28 03:20:13 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FEC23A690D; Mon, 28 Jul 2008 03:20:13 -0700 (PDT) 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 CBA273A67B1 for ; Mon, 28 Jul 2008 03:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQvz+EwjSa9Y for ; Mon, 28 Jul 2008 03:20:10 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 5098E3A69BF for ; Mon, 28 Jul 2008 03:20:08 -0700 (PDT) Received: from [130.129.23.64] (unknown [130.129.23.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 57FE9425E75; Mon, 28 Jul 2008 12:20:15 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Thierry Ernst In-Reply-To: <488D991F.9040800@inria.fr> References: <2F47249F-394B-4567-8415-9DDCA47A7D8D@gmail.com> <1217238532.26923.15.camel@localhost> <488D991F.9040800@inria.fr> Organization: Universidad Carlos III de Madrid Date: Mon, 28 Jul 2008 12:20:13 +0200 Message-Id: <1217240413.26923.30.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: mext@ietf.org Subject: Re: [MEXT] correspondent router drafts X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0678441993==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0678441993== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-XSiLZ7X/sUia8rmykG2g" --=-XSiLZ7X/sUia8rmykG2g Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Thierry, Well, the charter definitely says that the WG has to work on collecting needs of NEMO RO for 3 use cases. However, the WG at this point is only chartered work on a document (to be submitted as proposed standard) for the aviation use case. Regarding the work on solutions for automotive an CE, the charter says the following: "Work on automotive and personal mobile router solutions requires rechartering." Regards, Carlos El lun, 28-07-2008 a las 12:02 +0200, Thierry Ernst escribi=F3: > No, Carlos, at this point in time the WG missions is about collecting=20 > requirements for uses cases and understands the open issues. The charter=20 > is not saying that separate solutions will be developed for different=20 > use cases. A solution that solve the same problems for all studied use=20 > case is preferable though we may not have the choice. >=20 > At least this is were we were standing on when the NEMO WG charter was=20 > revised just before WGs were merged together. > Thierry. >=20 > Carlos Jes=FAs Bernardos Cano wrote: > > Hi Ryuji, > > > > (some text skipped) > > > > =20 > >> Yes, my document analysis CR issues in general scenarios. > >> I see there are plenty of assumptions in aviation industry. > >> > >> We must be very careful to standardize a RO solution if there are =20 > >> piles of assumptions (which are only available in aviation industry). > >> Please imagine if somebody deploys that RO solution without expected =20 > >> assumptions, it breaks the protocol behavior and might brings security= =20 > >> threats. > >> > >> Another question is whether an RO solution is only for aviation =20 > >> industry or not. > >> Will ATS be inter-connected to other infrastructures and consider the= =20 > >> interoperability in a near future? > >> If we have a CR based solution only for aviation industry, I believe =20 > >> it should be somehow capable of operation in general scenarios, too. > >> =20 > > > > I guess the WG is chartered to work on a solution for the aviation > > industry (not to work on a generic NEMO RO solution). I completely agre= e > > that it'd be much better to have a generic solution (covering other > > scenarios), though my feeling is that this would be harder (not even > > know if feasible), given the particular requirements of the aviation > > industry. > > > > Regards, > > > > Carlos > > > > =20 > > -----------------------------------------------------------------------= - > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > =20 >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-XSiLZ7X/sUia8rmykG2g Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkiNnV0ACgkQNdy6TdFwT2dtQgCguVPQgnIKPd6np8tLX0kevALA ehMAnRZLmI04X/HhZOxG/wHT199GW8eW =OVkG -----END PGP SIGNATURE----- --=-XSiLZ7X/sUia8rmykG2g-- --===============0678441993== 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 --===============0678441993==-- From mext-bounces@ietf.org Mon Jul 28 05:29:34 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41B683A68DD; Mon, 28 Jul 2008 05:29:34 -0700 (PDT) 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 6004D3A68DD for ; Mon, 28 Jul 2008 05:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.509 X-Spam-Level: X-Spam-Status: No, score=-4.509 tagged_above=-999 required=5 tests=[AWL=-1.791, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MY_CID_AND_ARIAL2=1.46, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxRb8lmKgVQe for ; Mon, 28 Jul 2008 05:29:31 -0700 (PDT) Received: from exprod8og109.obsmtp.com (exprod8og109.obsmtp.com [64.18.3.98]) by core3.amsl.com (Postfix) with SMTP id 228D33A68C8 for ; Mon, 28 Jul 2008 05:29:31 -0700 (PDT) Received: from source ([193.221.170.178]) by exprod8ob109.postini.com ([64.18.7.12]) with SMTP; Mon, 28 Jul 2008 05:29:37 PDT Received: from HHBRUE006.hq.corp.eurocontrol.int (hhbrue006.hq.corp.eurocontrol.int [193.221.160.195]) by ecw.eurocontrol.int (8.12.10/8.12.7) with ESMTP id m6SCTU4Z003371; Mon, 28 Jul 2008 14:29:32 +0200 (MEST) Received: from HHBRUE004.hq.corp.eurocontrol.int ([193.221.160.197]) by HHBRUE006.hq.corp.eurocontrol.int with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Jul 2008 14:29:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 14:29:29 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [MEXT] correspondent router drafts Thread-Index: AcjwlUqA/IlAbvq5SfSaCMMcBMamMgAARh7oAAWRTZA= References: <2F47249F-394B-4567-8415-9DDCA47A7D8D@gmail.com> From: "CERASI Eivan" To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" , "Ryuji Wakikawa" X-OriginalArrivalTime: 28 Jul 2008 12:29:30.0674 (UTC) FILETIME=[9568C920:01C8F0AD] Cc: mext@ietf.org Subject: Re: [MEXT] correspondent router drafts 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="===============0479371272==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============0479371272== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C8F0AD.951C979A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8F0AD.951C979A Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C8F0AD.951C979A" ------_=_NextPart_002_01C8F0AD.951C979A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, that was the input paper. As we are still working on a global prefix so the outcome is different. =20 The current status is that each MSP obtains his own prefix (/32) which is to be advertised via BGP on the ATN. =20 =20 In particular: 1. Each aircraft constitutes a /56 IPv6 end site, based on the ICAO 24 bit aircraft address. 2. Mobile IPv6 is assumed as the mobility solution. Each aircraft is assumed to be associated with one or more =20 3. An aircraft may have different subnets for different services (ATS, AOC, AAC, APC, etc.). =20 Mobility Service Providers (MSPs), which deploy a Home Agent advertising a /32 aggregate prefix route that contains the aircraft's assignment. =20 Mobility Service Provider (MSP): a service provider that provides Mobile IPv6 service (i.e. Home Agents). =20 =20 NB: The use of the ICAO aircraft address is a recommendation. =20 Eivan ________________________________ From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Eddy, Wesley M. (GRC-RCN0)[VZ] Sent: Monday 28 July 2008 11:43 To: Ryuji Wakikawa Cc: mext@ietf.org Subject: Re: [MEXT] correspondent router drafts =09 =09 This document from a recent ICAO meeting seems to indicate that's still the plan: =20 =09 http://www.icao.int/anb/panels/acp/wg/i/wgi7/ACP-WGI07-WP02-Draft%20ICAO %20IPv6%20Addressing%20Plan.doc =20 ________________________________ From: Ryuji Wakikawa [mailto:ryuji.wakikawa@gmail.com] Sent: Mon 7/28/2008 4:35 AM To: Eddy, Wesley M. (GRC-RCN0)[VZ] Cc: mext@ietf.org Subject: Re: [MEXT] correspondent router drafts =09 =09 =09 Very interesting. if aviation industry obtains a prefix chunk for all flights, we can do=20 more optimization in solution space in terms of aggregation, route=20 injection, etc. =09 =09 ____ This message and any files transmitted with it are legally privileged and= intended for the sole use of the individual(s) or entity to whom they ar= e addressed. If you are not the intended recipient, please notify the sen= der by reply and delete the message and any attachments from your system.= Any unauthorised use or disclosure of the content of this message is str= ictly prohibited and may be unlawful. Nothing in this e-mail message amounts to a contractual or legal commitme= nt on the part of EUROCONTROL, unless it is confirmed by appropriately si= gned hard copy. Any views expressed in this message are those of the sender. =0D ------_=_NextPart_002_01C8F0AD.951C979A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [MEXT] correspondent router = drafts
Yes, that was the input paper. As we are = still working=20 on a global prefix so the outcome is different.
 
The current status is that each MSP = obtains his own=20 prefix (/32) which is to be advertised via BGP on the = ATN.
 
 

In=20 particular:

1. Each = aircraft=20 constitutes a /56 IPv6 end site, based on the ICAO 24 bit aircraft=20 address.

2. = Mobile IPv6 is=20 assumed as the mobility solution. Each aircraft is assumed to be = associated with=20 one or more  =

3. An aircraft may = have=20 different subnets for different services (ATS, AOC, AAC, APC, = etc.).

 

Mobility = Service=20 Providers (MSPs), which deploy a Home Agent advertising a /32 aggregate = prefix=20 route that contains the aircraft's assignment.

 

Mobility Service Provider (MSP): a = service=20 provider that provides Mobile IPv6 service (i.e. Home = Agents).

 

NB: The use of the ICAO aircraft address is a = recommendation.

 

Eivan

From: mext-bounces@ietf.org=20 [mailto:mext-bounces@ietf.org] On Behalf Of Eddy, Wesley M.=20 (GRC-RCN0)[VZ]
Sent: Monday 28 July 2008 11:43
To: = Ryuji=20 Wakikawa
Cc: mext@ietf.org
Subject: Re: [MEXT]=20 correspondent router drafts

This = document from a recent=20 ICAO meeting seems to indicate that's still the plan:
 
http://www.icao.int/anb/panels/ac= p/wg/i/wgi7/ACP-WGI07-WP02-Draft%20ICAO%20IPv6%20Addressing%20Plan.doc

 
From: Ryuji = Wakikawa=20 [mailto:ryuji.wakikawa@gmail.com]
Sent: Mon 7/28/2008 4:35=20 AM
To: Eddy, Wesley M. (GRC-RCN0)[VZ]
Cc:=20 mext@ietf.org
Subject: Re: [MEXT] correspondent router=20 drafts


Very interesting.
if aviation industry = obtains a prefix=20 chunk for all flights, we can do 
more optimization in = solution space=20 in terms of aggregation, route 
injection,=20 etc.

____

This message and any files transmitted with it are legally privileged and=
 intended for the sole use of the individual(s) or entity to whom they ar=
e addressed. If you are not the intended recipient, please notify the sen=
der by reply and delete the message and any attachments from your system.=
 Any unauthorised use or disclosure of the content of this message is str=
ictly prohibited and may be unlawful.

Nothing in this e-mail message amounts to a contractual or legal commitme=
nt on the part of EUROCONTROL, unless it is confirmed by appropriately si=
gned hard copy.

Any views expressed in this message are those of the sender.
=0D
------_=_NextPart_002_01C8F0AD.951C979A--

------_=_NextPart_001_01C8F0AD.951C979A
Content-Type: image/gif;
	name="attaad8.gif"
Content-Transfer-Encoding: base64
Content-ID: <697522212@28072008-057A>
Content-Description: attaad8.gif
Content-Location: attaad8.gif

R0lGODlhXAJKAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAYADwBV
AjgAhQAAAAAAAB0AABUVFRAQEBERETMzMygoKDExMTw8PCUlJVFRUVZWVlhYWHAAAGNjY3R0dIcN
DZSUlIWFhb8/P6Ojo7Gxsb+/v9cAAMzMzNnZ2f8AAP8EBPsYGP8YGP8DA/8zM/8sLP8yMv8lJf88
PP9RUf9/f/9jY/90dP9zc/+Fhf+UlP+/v/+xsf+jo/+wsP+2tv/f3//MzP/Z2ebm5v/z8//m5vPz
8//s7P/o6P/v7////wECAwECAwECAwECAwb/QIBwSCwaj8ikcslsOp/QqHRKrVqv2Kx2y+16v+Cw
eEzeDDdosnrtNJuFaTY3AKDL73g23V7P+/+Aam5wAHGBh1pvcYaIU3yNkJFFj32SlpeWaG+FmJ1t
Z5ueR3uipXkBpKSmq6xem4ytnq+csUJ2lLW5V7eVur6/S26wwIivmqGsuMTLUKnMz7XChZrQgcez
ubzV25O93N+is8jgd+O+yuTM6Ons7e7v8PHy8/T19vf4+fr7/P3+/wADChxIsKDBgwgT1hvEkFPD
hw4jQpwosSLFixYzYtyosSPHjx5DghwpsqOAPs5SolypsiXLly5jwpwpsybNmzZz4typsyfP/58+
gwId6nIDiKNIkypdyrSp06dQo0qdSrUq1BAcRFjdyrWr16kdIhgYS/bAAbJkEaBdy3btAAJt48qd
S7eu3bt48+rdy7ev37+AA+stEGDDjsOIEytezLix48eQI0ueTLky5BgeLGvezLkzZRMUFCeoIGGB
4gkZIk9Y/ICB59ewY8ueTbu27du3GxTCzbu3b8mYfwsXDjoxjQeHK+xArkHCBAgPLCx/YHq6BQ0K
lCduPby79+/gw4t3rNvw+PPoGwdPzz5y8cQWEiyQbjrDhAnKTSfYYUEChAs7mAYBa661Z+CBCCbo
W3kKNvjbeg4a+B5iGhy2AA313ZfagBkmcP/fagMqxl2EJJZoooMNFCabDDMcJkMNitXQ4mEy7iCD
jZHJcKNkOz5Wg44zRlbjYTPAiBuEjhXpYo87KImYjovZMOOQlL24mJNPJsakbBPugCENGAa4w4cS
3GBahvjdgFx12xV44ps3VJYaZRVmYOebeCLGYGwjjLADCxuooJgKJCC2wgky+FnCDCoIytgIJIxQ
gmSLQqYCpCOcINmhiJHg6G1INubpDiSUWuhhkhIJaamKRXoYp5SVcIINpyKWamIj9JhrbV3ucMF9
FVowgQUXXOBchcrdAOCx/EnXZp4noqaYBI1NQC1lpilw3wIVQmvinrD1KQMKo7ZAgqaXyrr/w6GJ
7rBonyxo2oKmNo7Qgg2CtlACCuuiUEIJLLg7w6IDk3CjCiW4gBih9c5wAsADLxrvDvNy+vCoD98o
66eehcqYpyucugKMIY9gg7v8ursCYjNAqvChDgNs7qQn+GtDCSS4sAKkJ2xA77qRnjzwCbkOnWvN
i/572MP5/hvkY73aNqK3EaLm3wIVVKCABhY8gJwED0yggIBY8/fAgF0jh1i2h4VJNYngviYpuSeo
0LIMTJtcwgqEtpsrCfzqrfBhKPSJgg0jDMz3CCyocELLO+S6twsnuEAC4jNeGmkJibZQwwg6+yk4
oSg8PoLjiIq+wtOdebyYp422Gm/gOzK8/zQKlu/Qt72ft6CC5SewwEILLYxQQ84u7HoYCbOTugIL
fz//d/A5r5AwwIKC7kLA7oXW29RvK4gafmKuZlp/5KN2AQ1inh9mf2vvoED84aOoIp87w86wDJ4W
2ujukeOfoOrmJyKtrHgy2ADOGlUoxKEge4mqnaSYd5i+3ahd7YrcDgiou1IJqn8T/NyWWpcZyMBu
Uutq0gYi5ScSrAxltirVBhhlMD9lkFT5IkEJWqijAqqQhQEM4K7+lj0d0gxSNjDXCFIGmajVBnz1
O9D4UmMa1CzgPr9Kjfq8lgD7HCYDV5wAgCwkP/pFMUFx80yuMtWolunrgfbKGQBz5bgaQP/vZy1T
QeEi1wIU+O5UOzyZ5E4QMujJoAQn6+CTCjiCFZCrSZnqYMiK16gT6CuIsXFdq1TgwMLZ4ASISpQL
KOnJw1hOR6AEYOQOdYJR7WtnpLoR45YWStDJagUbOCQhc+nKFTiyj9AbWB9R2ETvQUZZN/gQ+yYD
xTOyZ4piWtMNKiAsLYLxBjSYn2kkcE1qxk8BdoqOM9G4m9iooAbPE96fVLCy4bHzTyMT1DkZBaNZ
IqZxdmvSO1nwwhm88Jy64yTFVNCCe75wBzVwFL4+tYKT8XNdvgwY31oE0EyW8DHP28FCTyZQihUU
n4mkGPcYxc+EEumdGWWU79BJsn8mknj/unMBQH93zowG9FW/02dHiykZ+2Sgi2BcZmSaOc7zXACZ
O1COBDSgAWv5Kk5HbaoElNNUqjoVMcr50BiLaqA0nodWteIqcC4qVl4Z8zE+3Y+vViMZopb1rXBl
T4rM054RxnUxmrzrZpy4mLR+ka1DdZNeB0vY4Xi1sAnKK2Ilw1fF+DWp1wrsYidLWdkctrLpUSxm
GdPYxPhUWxNgk2Q3S9rSPuaypgWPZlO7g84mJk52mhMzBcva2mJ2rrY9z2pT61rYuDW3wL2rbjhw
jeIa97jITa5yl8vc5jr3udC9xgeiS93qWve6ynUAKrbL3e5697vgDa94x0ve8pr3vOhN/69618ve
9rr3vfCNr3gVQt/62ve++M2vfvfL3/76978ADrCAB0zgAhv4wAhOsIIXzOAGO/jBEI6whCdM4Qpb
+MIYzrCGN8zhDnv4wyAOsYhHTOISm/jEKE5xLnYAABa7uMUwfrGMY0xje8z4xjTGsY5zrOIe2+N/
CispkF+Vg0+Z9H8vvMcL+VbQV3FvnTuFciKNlBgqH8bHWIYHDE53KZnWsFGgi6UP/fbAc90jBYU6
16UKirhTkdJkh0Gc4wpVN8XUOTFZznMXqBGJArpQlS501w39diN/sTgSgyBCormA5gzaAEalm2Wg
N5iyGWwABTpK4N9KpelxseoLi9Yzifj5DAkYrDCSfTu1pho3aNFFigQzyASpj+GFRoc1gKXDpO0o
tsM0C6qHAmxZvFQABlKLOsTXOEMSzEEIJDCbFkfw0yMB+EhMtzqAxTsZtI3w7G4v+9vJTnazj+Dt
IqC5ZZBuAaD6pKiUTXpiIiyBCljgKcmpIFGNcsG2i1BuctP62CI2NiK2vDwGZrB/NlqhDgm9wRLI
GhkCzwKaN4ipgTnKhS0zFWLazCqEJa9wMkDYDABHghaAehgAR7YkdmSDF7WI5SxaEpQumCVJ9JsL
M5rBjnokpSUtBkoustEMlLTzFoE65UiXQ23uAZ6kO90XS7exd55OdSIEAQA7

------_=_NextPart_001_01C8F0AD.951C979A--

--===============0479371272==
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

--===============0479371272==--


From mext-bounces@ietf.org  Mon Jul 28 06:26:51 2008
Return-Path: 
X-Original-To: nemo-archive@megatron.ietf.org
Delivered-To: ietfarch-nemo-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 62E9C3A6A5F;
	Mon, 28 Jul 2008 06:26:51 -0700 (PDT)
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 C993B3A68E8
	for ; Mon, 28 Jul 2008 06:26:33 -0700 (PDT)
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 mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id haIBCQw-leK0 for ;
	Mon, 28 Jul 2008 06:26:33 -0700 (PDT)
Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176])
	by core3.amsl.com (Postfix) with ESMTP id 093603A69CC
	for ; Mon, 28 Jul 2008 06:26:32 -0700 (PDT)
Received: by py-out-1112.google.com with SMTP id x19so2118383pyg.24
	for ; Mon, 28 Jul 2008 06:26:42 -0700 (PDT)
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=1eCy3mzpDTmOEWpPmvFcYyvbd27rkYB74ST0WwEity0=;
	b=cipAojtFkVhX8DqzvFVSdwovU7gxBS+zc+wVXFboGG7h+jbP4a+rzDu6Uih5XiVxdb
	lygQVf5zdrKqTZd1yQPkrbkSzbOfmln3Snm4R7DRFBl0jrcBbBpo4eNnOfCI2HmXgHfd
	1XH/pNmsYkotTLOynuPSmX8i76IlqyOTJB2AQ=
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=nUj4LYUUaZ0WPwkSt92o/fyw5D53YTLeXGWaYtYSc+k89c8ClYAOQ8qjCJHg4VClXq
	zMD78FEzKGfJGzY8j6Zeli9flHQJqz6LFBajh4FlWshlxWpWGpnI27soykx4fojaJYmB
	KMdk8k0l3SDcn6l9aY8X6K6H6B16f1CTeHvY0=
Received: by 10.114.196.1 with SMTP id t1mr4896844waf.80.1217251602162;
	Mon, 28 Jul 2008 06:26:42 -0700 (PDT)
Received: from klee.meeting.ietf.org ( [130.129.19.49])
	by mx.google.com with ESMTPS id f20sm18144695waf.53.2008.07.28.06.26.40
	(version=TLSv1/SSLv3 cipher=RC4-MD5);
	Mon, 28 Jul 2008 06:26:41 -0700 (PDT)
From: Julien Laganier 
To: mext@ietf.org
User-Agent: KMail/1.9.6
MIME-Version: 1.0
Content-Disposition: inline
Date: Mon, 28 Jul 2008 15:26:37 +0200
Message-Id: <200807281526.37672.julien.IETF@laposte.net>
X-Mailman-Approved-At: Mon, 28 Jul 2008 06:26:49 -0700
Subject: [MEXT] [URGENT] MEXT Presenters
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 send your presentations to Marcelo and me NOW for today's 
session, and before 11:00 tomorrow for tomorrow's session. This 
is required for remotes participants to have access to meeting 
material.

Thank you for your support.

--julien & marcelo
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext


From mext-bounces@ietf.org  Mon Jul 28 08:09:45 2008
Return-Path: 
X-Original-To: nemo-archive@megatron.ietf.org
Delivered-To: ietfarch-nemo-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 08AA128C16B;
	Mon, 28 Jul 2008 08:09:45 -0700 (PDT)
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 6D40028C16B
	for ; Mon, 28 Jul 2008 08:09:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.185
X-Spam-Level: 
X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5
	tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id vklTLlR+bjCM for ;
	Mon, 28 Jul 2008 08:09:42 -0700 (PDT)
Received: from mail128.messagelabs.com (mail128.messagelabs.com
	[216.82.250.131])
	by core3.amsl.com (Postfix) with SMTP id BB8F93A6982
	for ; Mon, 28 Jul 2008 08:09:28 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: alexandru.petrescu@gmail.com
X-Msg-Ref: server-13.tower-128.messagelabs.com!1217257777!6671427!1
X-StarScan-Version: 5.5.12.14.2; banners=.,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 11860 invoked from network); 28 Jul 2008 15:09:37 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8)
	by server-13.tower-128.messagelabs.com with SMTP;
	28 Jul 2008 15:09:37 -0000
Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134])
	by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m6SF9bR9029414
	for ; Mon, 28 Jul 2008 08:09:37 -0700 (MST)
Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142])
	by il06exr04.mot.com (8.13.1/Vontu) with SMTP id m6SF9b7T025595
	for ; Mon, 28 Jul 2008 10:09:37 -0500 (CDT)
Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117])
	by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id m6SF9ZBK025582
	for ; Mon, 28 Jul 2008 10:09:36 -0500 (CDT)
Message-ID: <488DE12F.7080200@gmail.com>
Date: Mon, 28 Jul 2008 17:09:35 +0200
From: Alexandru Petrescu 
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: mext 
X-Antivirus: avast! (VPS 080726-1, 26/07/2008), Outbound message
X-Antivirus-Status: Clean
X-CFilter-Loop: Reflected
Subject: [MEXT] side comment MR-to-MR and CR-to-MR
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: mext-bounces@ietf.org
Errors-To: mext-bounces@ietf.org

Well, I see MR-to-MR RO to be a bit different than CR-to-MR in that 
MR-to-MR suposedly have their egress on same subnet (like car-to-car or 
plane-to-plane are in vicinity), whereas CR-to-MR are separated by 
potentially multiple hops.  This leads to IP solutions working on same 
subnet or across subnets...

Just some note...

Alex


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext


From mext-bounces@ietf.org  Mon Jul 28 08:21:46 2008
Return-Path: 
X-Original-To: nemo-archive@megatron.ietf.org
Delivered-To: ietfarch-nemo-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id BD81628C0E0;
	Mon, 28 Jul 2008 08:21:46 -0700 (PDT)
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 73B9D28C158
	for ; Mon, 28 Jul 2008 08:21:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.35
X-Spam-Level: 
X-Spam-Status: No, score=-5.35 tagged_above=-999 required=5 tests=[AWL=0.349, 
	BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3,
	RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id Wfk532A67SUg for ;
	Mon, 28 Jul 2008 08:21:40 -0700 (PDT)
Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132])
	by core3.amsl.com (Postfix) with ESMTP id B4EE53A6AAD
	for ; Mon, 28 Jul 2008 08:21:40 -0700 (PDT)
Received: from [130.129.23.64] (unknown [130.129.23.64])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by smtp02.uc3m.es (Postfix) with ESMTP id 1D5A94259BC;
	Mon, 28 Jul 2008 17:21:49 +0200 (CEST)
From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano 
To: Alexandru Petrescu 
In-Reply-To: <488DE12F.7080200@gmail.com>
References: <488DE12F.7080200@gmail.com>
Organization: Universidad Carlos III de Madrid
Date: Mon, 28 Jul 2008 17:21:47 +0200
Message-Id: <1217258507.26923.46.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1 
Cc: mext 
Subject: Re: [MEXT] side comment MR-to-MR and CR-to-MR
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: cjbc@it.uc3m.es
List-Id: Mobile IPv6 EXTensions WG 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1138401297=="
Sender: mext-bounces@ietf.org
Errors-To: mext-bounces@ietf.org


--===============1138401297==
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-7u5r48Objr0aOSutVWJN"


--=-7u5r48Objr0aOSutVWJN
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

Hi Alex,

	Thanks for the note. I was thinking on a generic MR-to-MR (i.e.
multiple hops between them). IMHO, an MR-to-MR scenario in which the
egress interfaces are on the same subnet would be easier to tackle.

	Carlos

El lun, 28-07-2008 a las 17:09 +0200, Alexandru Petrescu escribi=F3:
> Well, I see MR-to-MR RO to be a bit different than CR-to-MR in that=20
> MR-to-MR suposedly have their egress on same subnet (like car-to-car or=20
> plane-to-plane are in vicinity), whereas CR-to-MR are separated by=20
> potentially multiple hops.  This leads to IP solutions working on same=20
> subnet or across subnets...
>=20
> Just some note...
>=20
> Alex
>=20
>=20
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email=20
> ______________________________________________________________________
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext
--=20
Carlos Jes=FAs Bernardos Cano     http://www.netcoms.net
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67

--=-7u5r48Objr0aOSutVWJN
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada
	digitalmente

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAkiN5AsACgkQNdy6TdFwT2drIwCeIYsoUWOhNTp5Z7I52DgH8AD8
WT4AoMdDK6UdZgerUhe5Wbt2pY5l2lPQ
=6gqk
-----END PGP SIGNATURE-----

--=-7u5r48Objr0aOSutVWJN--


--===============1138401297==
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

--===============1138401297==--



From mext-bounces@ietf.org  Mon Jul 28 08:31:05 2008
Return-Path: 
X-Original-To: nemo-archive@megatron.ietf.org
Delivered-To: ietfarch-nemo-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id A50413A6A1D;
	Mon, 28 Jul 2008 08:31:05 -0700 (PDT)
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 EB1AD3A6982
	for ; Mon, 28 Jul 2008 08:31:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.392
X-Spam-Level: 
X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=1.207, 
	BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id g-y1qBYqlNOU for ;
	Mon, 28 Jul 2008 08:31:01 -0700 (PDT)
Received: from mail153.messagelabs.com (mail153.messagelabs.com
	[216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 2938F28C1A2
	for ; Mon, 28 Jul 2008 08:30:56 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: alexandru.petrescu@gmail.com
X-Msg-Ref: server-7.tower-153.messagelabs.com!1217259065!8040466!1
X-StarScan-Version: 5.5.12.14.2; banners=.,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 11183 invoked from network); 28 Jul 2008 15:31:05 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8)
	by server-7.tower-153.messagelabs.com with SMTP;
	28 Jul 2008 15:31:05 -0000
Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134])
	by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m6SFV59E007315
	for ; Mon, 28 Jul 2008 08:31:05 -0700 (MST)
Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144])
	by il06exr04.mot.com (8.13.1/Vontu) with SMTP id m6SFV4Nn012991
	for ; Mon, 28 Jul 2008 10:31:05 -0500 (CDT)
Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117])
	by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id m6SFV3jP012974
	for ; Mon, 28 Jul 2008 10:31:04 -0500 (CDT)
Message-ID: <488DE637.7050205@gmail.com>
Date: Mon, 28 Jul 2008 17:31:03 +0200
From: Alexandru Petrescu 
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: mext 
X-Antivirus: avast! (VPS 080726-1, 26/07/2008), Outbound message
X-Antivirus-Status: Clean
X-CFilter-Loop: Reflected
Subject: [MEXT] Is packet from CN to LFN always going through HA1 and HA2
 after MR chose HA2?
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: mext-bounces@ietf.org
Errors-To: mext-bounces@ietf.org

Is packet from CN to LFN always go through HA1 _and_ HA2 after MR chose HA2?

Is this better performing than packet going only to HA1?

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext


From mext-bounces@ietf.org  Mon Jul 28 08:51:15 2008
Return-Path: 
X-Original-To: nemo-archive@megatron.ietf.org
Delivered-To: ietfarch-nemo-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 3864D3A6A76;
	Mon, 28 Jul 2008 08:51:15 -0700 (PDT)
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 12B453A6A1D
	for ; Mon, 28 Jul 2008 08:51:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level: 
X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[AWL=0.490, 
	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 NeSJVGV+FzuQ for ;
	Mon, 28 Jul 2008 08:51:13 -0700 (PDT)
Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.233])
	by core3.amsl.com (Postfix) with ESMTP id 182C83A6845
	for ; Mon, 28 Jul 2008 08:51:13 -0700 (PDT)
Received: by qb-out-0506.google.com with SMTP id z8so587551qbc.41
	for ; Mon, 28 Jul 2008 08:51:22 -0700 (PDT)
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=s8hQFZvfwrGYadVYfXlxgqwbuwuPf+iQg1YZpuHsLtU=;
	b=pPYEut8Ust08YQBRIQuNEOyTfpjUI+9sil5Kt3qgzzmRinwIayq5Et9EKJ+4gG5DsN
	icqqjzAcmNvtj6MLxF9XDpFNDSPlhlPJAE+GIntxh/G/+mIxy8QsLKsffu56vL82qmoM
	E9+TRxSRRiYX9rApmEPBBWBhB3/x+VYyI/LEk=
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=RY7WjlK9NvOXq54rpfsL/RHo+OepTKbdmeVCVyPS8xkuKHEIXzhdvPhyJW8cXEcG/n
	4qJrIYot3smo0HniVXXHPmgKPx6s2vB3aFgiD4xM1UeX2oJrnKADpeEgJXTkXV3lJqD5
	HwKcDMEYZUurHOpg6dnQ+Fu9h4NflYS9Ds6Vc=
Received: by 10.114.153.18 with SMTP id a18mr5105937wae.161.1217260282214;
	Mon, 28 Jul 2008 08:51:22 -0700 (PDT)
Received: from ryujibookpro.meeting.ietf.org ( [130.129.19.206])
	by mx.google.com with ESMTPS id n38sm23463016wag.24.2008.07.28.08.51.20
	(version=TLSv1/SSLv3 cipher=RC4-MD5);
	Mon, 28 Jul 2008 08:51:21 -0700 (PDT)
From: Ryuji Wakikawa 
To: Alexandru Petrescu 
In-Reply-To: <488DE637.7050205@gmail.com>
References: <488DE637.7050205@gmail.com>
Message-Id: <65BF381B-1AC2-4AE9-B0F8-8C5C8BDECAC6@gmail.com>
Mime-Version: 1.0 (Apple Message framework v928.1)
Date: Tue, 29 Jul 2008 00:51:17 +0900
X-Mailer: Apple Mail (2.928.1)
Cc: mext 
Subject: Re: [MEXT] Is packet from CN to LFN always going through HA1 and
	HA2 after MR chose HA2?
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: mext-bounces@ietf.org
Errors-To: mext-bounces@ietf.org

Hi Alex,

well, how you define close in this RO context.
Both HAs advertise the same prefix (anycast), CN's packet is routed to  
the closest HA (HA2) to CN.

HA2 can directly route this packet to MN, but we need modifications to  
mobile node and mobile router to receive packets from multiple HAs.

The global HAHA is extension free to mobile nodes;-)

ryuji

On 2008/07/29, at 0:31, Alexandru Petrescu wrote:

> Is packet from CN to LFN always go through HA1 _and_ HA2 after MR  
> chose HA2?
>
> Is this better performing than packet going only to HA1?
>
> Alex
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email  
> ______________________________________________________________________
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext

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


From mext-bounces@ietf.org  Tue Jul 29 07:06:30 2008
Return-Path: 
X-Original-To: nemo-archive@megatron.ietf.org
Delivered-To: ietfarch-nemo-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 6610C28C32E;
	Tue, 29 Jul 2008 07:06:30 -0700 (PDT)
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 1C62028C17C
	for ; Tue, 29 Jul 2008 07:06:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.852
X-Spam-Level: 
X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[AWL=0.747, 
	BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id WKC-PNgCbYPP for ;
	Tue, 29 Jul 2008 07:06:27 -0700 (PDT)
Received: from psmtp.com (exprod8ob116.obsmtp.com [64.18.3.31])
	by core3.amsl.com (Postfix) with SMTP id CC2FC28C318
	for ; Tue, 29 Jul 2008 07:06:21 -0700 (PDT)
Received: from source ([193.221.170.178]) by exprod8ob116.postini.com
	([64.18.7.12]) with SMTP; Tue, 29 Jul 2008 07:06:32 PDT
Received: from HHBRUE007.hq.corp.eurocontrol.int
	(hhbrue007.hq.corp.eurocontrol.int [193.221.160.203])
	by ecw.eurocontrol.int (8.12.10/8.12.7) with ESMTP id m6TE6J4Z023225;
	Tue, 29 Jul 2008 16:06:24 +0200 (MEST)
Received: from HHBRUE004.hq.corp.eurocontrol.int ([193.221.160.197]) by
	HHBRUE007.hq.corp.eurocontrol.int with Microsoft
	SMTPSVC(6.0.3790.3959); Tue, 29 Jul 2008 16:06:18 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 29 Jul 2008 16:06:18 +0200
Message-ID: 
In-Reply-To: <8F8C6F2D-639A-44E1-A16B-9F3678EB6236@gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [MEXT] Thoughts on the different nemo ro approaches
Thread-Index: AcjwimtfJmHZ0U2HTpyuy6UBNXYToAA+O4iQ
References: <4888B578.7050009@it.uc3m.es>
	<8F8C6F2D-639A-44E1-A16B-9F3678EB6236@gmail.com>
From: "CERASI Eivan" 
To: "marcelo bagnulo braun" 
X-OriginalArrivalTime: 29 Jul 2008 14:06:18.0766 (UTC)
	FILETIME=[45B70AE0:01C8F184]
Cc: mext 
Subject: Re: [MEXT] Thoughts on the different nemo ro approaches
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 another thought on the subject.

In their own way, both solutions assume that a service provider between
the MR and CN is capable of providing managed value-added services to
perform RO.

This is very different to RO for MIP; I was wondering if it would make
sense to apply the NEMO RO solution as a means to enhance MIP RO. I
recognise it is not really within the charter but it may be an
additional aspect to support solution space and make more universal that
for the aviation sector.

Eivan

> Hi,
>
> I have been reading the drafts people have submitted for the nemo ro 
> work for the aviation case.
> In particular, i have read
>
> draft-bauer-mext-aero-topology-00
> draft-wakikawa-mext-haha-interop2008-00
> draft-wakikawa-mext-cr-consideration-00
> draft-wakikawa-nemo-orc-01
> draft-thubert-mext-global-haha-00
> draft-bernardos-mext-nemo-ro-cr-00
>
> Essentially we have two different approaches, one based on distributed

> HAs and another one based on the concept of the correspondent router.
> It seems to me that the CR based approach is more complex than the ha 
> based approach, so i guess that a first legitimate question to ask is 
> where does the complexity springs from?
> One observation that i would like to contrast with the group is that 
> the HA based approach makes the following fundamental assumption: A 
> set of globally distributed anchor points that are within the _same_ 
> administrative domain are available and are enough to provide the RO 
> capabilities required.
>
> OTOH, the CR based approach makes a different assumption, which is 
> that a set of distributed anchor points with which is possible to have

> a trust relationship are available and are enough to provide the RO 
> capabilties required.
>
> The difference as i understand it, is that the HA based approach 
> assumes that the anchor points are in the same admin domain (or that 
> they are within domains with strong admin relationship, which allows 
> them to do functions that are usually not acceptable across domains) 
> and the CR based approach does not makes that assumption.
>
> By assuming that these anchor points are in the same admin domain, the

> HA based approach can take advantage of the following functions that 
> are not available across domains (i may be missing some
> function):
> - anycast routing
> - host/MNP route injection to sink traffic for the proper anchor 
> point.
> - strong state synchronization between HAs/anchor points
> The usage of these tools indeed make life easier, but they impose some

> constraints.
> I think that we need to understand these constraints, and figure out 
> whether they are acceptable for the aviation community. In other 
> words, i think that a relevant exercise at this point is to try to 
> figure out how a HA based approach can be deployed within the aviation

> scenario described in draft-bauer-mext-aero-topology-00
>
> So, let's consider how this could be deployed.
>
> A first deployment scenario would be that the HAs are deployed within 
> a gACSP. This seems like the perfect match. The gACSP has global 
> infrastructure, so it can be assumed to have HAs distributed along the

> globe and they can provide reasonable good enough rute optimization. 
> So, if an aricraft is using the gACSP all the way, this seems to work 
> reasonably. A first question may be posed though in this scenario 
> about addressing. From which prefix the MNP is extracted from? I mean,

> one option is that the gACSP has a prefix for this, and uses it to 
> assign to all the different companies that it serves. However, this 
> would result in a form of provider dependent addressing and maybe the 
> problems of provider dependent addressing would rise here.  In other 
> words, is it ok for the aviation companies to use a prefix that is 
> owned by the gASCP? This basically means that if they want to change 
> the provider (i don't know if this is possible), they will need to 
> renumber.
> A related question to this one, about what is the normal relation 
> between the aviation company and the gASCP? Is it normal that a given 
> aviation company works with one or both the gACSP that exists?
> If they work with one, the provide lock in effect could be an issue.  
> If they work with two, then would this approach implies that they need

> to have two prefixes, one for each gACSP? That would probably be 
> problematic from the network management perspective. In both cases, 
> either if they decide to use two prefixes, or they use a single gACSP 
> with only one prefix, the next question is whether they can acquire a 
> CoA from the other gACSP? if they can, it is possible that the gACSP 
> performs cold potato routing and the RO benefits are not achieved.
>
> The other option of course is that the aviation companies have a  
> provider indepedent prefix and that the gACSP announces it on behalf  
> of their clients.
> In this case both gACSP can announce the client prefix. The  
> potential issue here is what is the impact for the global routing  
> table of such practice.
>
>
> A second scenario is where other than gASCP are considered.
> At this point, i don't even grasp how the scenarios are. For  
> instance, is it possible that some airlines do not have any  
> relationship with any of the two gASCP? In that case, they only have  
> contracts with smaller providers and in that case i this not clear  
> to me how the ha infrastructure can be deployed. I mean, would this  
> imply that each of the smaller players will have a HA and they would  
> run HAHA protocol between them? I don't know if the implications of  
> these are acceptable for the relationship that those players have.
>
> One particular case where this is significant is when the  
> communication with the gACSP is down for whatever reason. If this is  
> the case, and the HA infrastrucutre is not reachable, the direct  
> communication between the aircraft and the CNs that are directly  
> attached to the same ACSP is not possible, even if they have direct  
> connectivity. I am not sure if this is acceptable.
> So, imho, what needs to be understood a bit more in depth is the  
> possible deployment models of a HA based approach in the aviation  
> reality. I am hoping that we can have this discussion in dublin
>
> Regards, marcelo
>
>
>
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext
____

This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful.

Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy.

Any views expressed in this message are those of the sender.

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


From mext-bounces@ietf.org  Tue Jul 29 08:23:30 2008
Return-Path: 
X-Original-To: nemo-archive@megatron.ietf.org
Delivered-To: ietfarch-nemo-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id F02BD28C31A;
	Tue, 29 Jul 2008 08:23:29 -0700 (PDT)
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 B9C0A3A67B7
	for ; Tue, 29 Jul 2008 08:22:53 -0700 (PDT)
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 mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id vLrNFHFbMF3u for ;
	Tue, 29 Jul 2008 08:22:53 -0700 (PDT)
Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.231])
	by core3.amsl.com (Postfix) with ESMTP id E62A83A6853
	for ; Tue, 29 Jul 2008 08:22:52 -0700 (PDT)
Received: by qb-out-0506.google.com with SMTP id z8so780708qbc.41
	for ; Tue, 29 Jul 2008 08:23:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=domainkey-signature:received:received:message-id:date:from:to
	:subject:mime-version:content-type:content-transfer-encoding
	:content-disposition;
	bh=74bvSacwTdiR9RG3DBE67C+cp6Y1JoDCO+o9JqFy3xg=;
	b=KMR/BiNB19CMDOG4AEbrimqO8zHHv025Lu846mF232u2gyogNL9cb3SOs/IRDNnA3Q
	wQoJAGzo9pShJ6CK3A59ObCyyi5gPQbbvck70iRIbCES7bDADfL0dvxdb3Rzm31+HvKf
	lCmW9eImpclKmSob7YQShdsXNqmTJ0jPycB6A=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:to:subject:mime-version:content-type
	:content-transfer-encoding:content-disposition;
	b=qPEOZCWxJesbIbgaaSpR7jo/AmZVwAY8CGBaQ+jIGkvnRCAY9nkuHPIbCPeEo1KQmH
	eTyk/HydOelme3Mz1IfVcKcdcy6R0hXsFSzodYzpinOgu6vpAAMABIQ4VG7C4LAU1TrB
	yPJr107DQuRQTUDq2GnFFjQhrHcYo1Yk12Fns=
Received: by 10.142.194.1 with SMTP id r1mr2165175wff.306.1217344984469;
	Tue, 29 Jul 2008 08:23:04 -0700 (PDT)
Received: by 10.143.44.6 with HTTP; Tue, 29 Jul 2008 08:23:04 -0700 (PDT)
Message-ID: <94a5534b0807290823m6f9ab84bv46adc8b9d6a8f4d4@mail.gmail.com>
Date: Tue, 29 Jul 2008 20:53:04 +0530
From: "Magesh Shanmugam" 
To: mext@ietf.org
MIME-Version: 1.0
Content-Disposition: inline
Subject: [MEXT] Query on Binding Revocation Procedure for Proxy 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: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mext-bounces@ietf.org
Errors-To: mext-bounces@ietf.org

Ahmad

Since the Binding Revocation proceudre (i.e. exchange of BRI & BRA)
can be triggered by any node in Proxy Mobile IPv6, is it possible that
both MAG & LMA can trigger BRI message simultaneously (due to some
adminstrative reasons)

i.e. MAG sends a BRI with G bit set (i.e. bulk revocation of PMIPv6
bindings) and LMA sends a BRI with either one PMIPv6 binding
revocation or G bit set for bulk PMIPv6 binding revocation.  Both the
BRI messages does not set the A bit in BRI, hence won't wait for ACK.

What should be the behavior at MAG & LMA.

Thanks
S Magesh
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext


From mext-bounces@ietf.org  Tue Jul 29 23:06:50 2008
Return-Path: 
X-Original-To: nemo-archive@megatron.ietf.org
Delivered-To: ietfarch-nemo-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 104B13A69D9;
	Tue, 29 Jul 2008 23:06:50 -0700 (PDT)
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 E7C513A69A2
	for ; Tue, 29 Jul 2008 23:06:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.399
X-Spam-Level: 
X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, 
	BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id E+3TL6NOD9MA for ;
	Tue, 29 Jul 2008 23:06:47 -0700 (PDT)
Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57])
	by core3.amsl.com (Postfix) with ESMTP id C70BA3A68EF
	for ; Tue, 29 Jul 2008 23:06:46 -0700 (PDT)
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	m6U66tF28421; Wed, 30 Jul 2008 06:06:55 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 30 Jul 2008 01:06:46 -0500
Message-ID: 
In-Reply-To: <94a5534b0807290823m6f9ab84bv46adc8b9d6a8f4d4@mail.gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [MEXT] Query on Binding Revocation Procedure for Proxy Mobile
	IPv6
Thread-Index: Acjxjxv9SNdZYzntRTSAHa7YrlFobgAegSKA
References: <94a5534b0807290823m6f9ab84bv46adc8b9d6a8f4d4@mail.gmail.com>
From: "Ahmad Muhanna" 
To: "Magesh Shanmugam" , 
Subject: Re: [MEXT] Query on Binding Revocation Procedure for Proxy 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: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mext-bounces@ietf.org
Errors-To: mext-bounces@ietf.org

Magesh,

Let me try to address in the following way:

1. From administrative prospective, it is sometimes hard to imagine that
the administrative decision would come through the two different nodes,
but I agree this could be looked at from a race condition where the
administrative reasons are different, but possible.

2. This case needs to be addressed as a race condition and should be
handled as follows:
2.1. In case of Global revocation, we MUST mandate that the node which
send a BRI with the 'G' bit is set MUST also set the A bit, since this
BRI is related to many sessions not a single one.

2.2. Even if the A bit is not set in the BRI, if the BRI is
authenticated and securely protected, the receiving node must process
the BRI and delete the session, if the session is already deleted, then
the receiving node does not need to do any thing extra.

Hope this address your concern.

Regards,
Ahmad
 

> -----Original Message-----
> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On 
> Behalf Of Magesh Shanmugam
> Sent: Tuesday, July 29, 2008 4:23 PM
> To: mext@ietf.org
> Subject: [MEXT] Query on Binding Revocation Procedure for 
> Proxy Mobile IPv6
> 
> Ahmad
> 
> Since the Binding Revocation proceudre (i.e. exchange of BRI 
> & BRA) can be triggered by any node in Proxy Mobile IPv6, is 
> it possible that both MAG & LMA can trigger BRI message 
> simultaneously (due to some adminstrative reasons)
> 
> i.e. MAG sends a BRI with G bit set (i.e. bulk revocation of PMIPv6
> bindings) and LMA sends a BRI with either one PMIPv6 binding 
> revocation or G bit set for bulk PMIPv6 binding revocation.  
> Both the BRI messages does not set the A bit in BRI, hence 
> won't wait for ACK.
> 
> What should be the behavior at MAG & LMA.
> 
> Thanks
> S Magesh
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext
> 
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext


From mext-bounces@ietf.org  Tue Jul 29 23:20:50 2008
Return-Path: 
X-Original-To: nemo-archive@megatron.ietf.org
Delivered-To: ietfarch-nemo-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 946D93A6A14;
	Tue, 29 Jul 2008 23:20:50 -0700 (PDT)
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 AF05A3A69B8
	for ; Tue, 29 Jul 2008 23:20:49 -0700 (PDT)
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 0ykb9eCkxBzG for ;
	Tue, 29 Jul 2008 23:20:48 -0700 (PDT)
Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171])
	by core3.amsl.com (Postfix) with ESMTP id C4DBD3A6A19
	for ; Tue, 29 Jul 2008 23:20:48 -0700 (PDT)
Received: by wf-out-1314.google.com with SMTP id 27so246306wfd.31
	for ; Tue, 29 Jul 2008 23:20:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=domainkey-signature:received:received:message-id:date:from:to
	:subject:in-reply-to:mime-version:content-type
	:content-transfer-encoding:content-disposition:references;
	bh=mVj6oKHvlSBXkxzG/qq+cweG1MwJvkcrVBqKiCZuzUM=;
	b=U7a+nzGlNvmHtRJP3I+RvifBtZqTC1CP/Rr7Z1qknWfiUr55GRDAm1EAbfmxbVKBOe
	HL2phEN+Q84YtB+4Y05WwLyeJvxhnwKnJXHxV/WyUnxY3GbFBK7JUfQerEJTg1Rs2aJ4
	w9n97YoXJYuYqO0jQiKscvIHfXPyIhMVZrvho=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:to:subject:in-reply-to:mime-version
	:content-type:content-transfer-encoding:content-disposition
	:references;
	b=UIFyDC7W7ZsyQiKY1Fnv+mHeaYPVMQuE5n/5NBats81g1lGWr9lglRfAmv2tPQQTST
	SvSxCpRkb/DxpQS5yxMwaS0Avms1pSCtBn+T2tBW9SU7NMZ/z51pDMXItepBFKta3bmL
	nGIx7VHrGSku9wn5wtSFg0b/pBgRpjsTKKwus=
Received: by 10.143.33.12 with SMTP id l12mr2503689wfj.272.1217398851190;
	Tue, 29 Jul 2008 23:20:51 -0700 (PDT)
Received: by 10.143.44.6 with HTTP; Tue, 29 Jul 2008 23:20:51 -0700 (PDT)
Message-ID: <94a5534b0807292320v4c7c862dme9842e98b13d506e@mail.gmail.com>
Date: Wed, 30 Jul 2008 11:50:51 +0530
From: "Magesh Shanmugam" 
To: "Ahmad Muhanna" , "mext@ietf.org" 
In-Reply-To: 
MIME-Version: 1.0
Content-Disposition: inline
References: <94a5534b0807290823m6f9ab84bv46adc8b9d6a8f4d4@mail.gmail.com>
	
Subject: Re: [MEXT] Query on Binding Revocation Procedure for Proxy 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: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mext-bounces@ietf.org
Errors-To: mext-bounces@ietf.org

Ahmad

Thanks for your explanation.

My query here is that when MAG sends a BRI with G bit set, but not A
bit, then immediately after sending the BRI it will clean up its
resources (i.e. Binding Update List and other related resources), but
at the LMA side if the cleaning up of resource is partial success
(i.e. not all the resources are cleaned-up), then what should be the
behavior at MAG, since it might have cleaned up all the resources.

Regards
S Magesh


On 7/30/08, Ahmad Muhanna  wrote:
> Magesh,
>
> Let me try to address in the following way:
>
> 1. From administrative prospective, it is sometimes hard to imagine that
> the administrative decision would come through the two different nodes,
> but I agree this could be looked at from a race condition where the
> administrative reasons are different, but possible.
>
> 2. This case needs to be addressed as a race condition and should be
> handled as follows:
> 2.1. In case of Global revocation, we MUST mandate that the node which
> send a BRI with the 'G' bit is set MUST also set the A bit, since this
> BRI is related to many sessions not a single one.
>
> 2.2. Even if the A bit is not set in the BRI, if the BRI is
> authenticated and securely protected, the receiving node must process
> the BRI and delete the session, if the session is already deleted, then
> the receiving node does not need to do any thing extra.
>
> Hope this address your concern.
>
> Regards,
> Ahmad
>
>
> > -----Original Message-----
> > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On
> > Behalf Of Magesh Shanmugam
> > Sent: Tuesday, July 29, 2008 4:23 PM
> > To: mext@ietf.org
> > Subject: [MEXT] Query on Binding Revocation Procedure for
> > Proxy Mobile IPv6
> >
> > Ahmad
> >
> > Since the Binding Revocation proceudre (i.e. exchange of BRI
> > & BRA) can be triggered by any node in Proxy Mobile IPv6, is
> > it possible that both MAG & LMA can trigger BRI message
> > simultaneously (due to some adminstrative reasons)
> >
> > i.e. MAG sends a BRI with G bit set (i.e. bulk revocation of PMIPv6
> > bindings) and LMA sends a BRI with either one PMIPv6 binding
> > revocation or G bit set for bulk PMIPv6 binding revocation.
> > Both the BRI messages does not set the A bit in BRI, hence
> > won't wait for ACK.
> >
> > What should be the behavior at MAG & LMA.
> >
> > Thanks
> > S Magesh
> > _______________________________________________
> > MEXT mailing list
> > MEXT@ietf.org
> > https://www.ietf.org/mailman/listinfo/mext
> >
>
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext


From mext-bounces@ietf.org  Tue Jul 29 23:27:22 2008
Return-Path: 
X-Original-To: nemo-archive@megatron.ietf.org
Delivered-To: ietfarch-nemo-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id EC9503A69B8;
	Tue, 29 Jul 2008 23:27:21 -0700 (PDT)
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 33F0E3A68EF
	for ; Tue, 29 Jul 2008 23:27:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.428
X-Spam-Level: 
X-Spam-Status: No, score=-6.428 tagged_above=-999 required=5 tests=[AWL=0.171, 
	BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id yK7TcVY560bi for ;
	Tue, 29 Jul 2008 23:27:20 -0700 (PDT)
Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56])
	by core3.amsl.com (Postfix) with ESMTP id 08AA93A69B8
	for ; Tue, 29 Jul 2008 23:27:19 -0700 (PDT)
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
	m6U6RSu12503; Wed, 30 Jul 2008 06:27:28 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 30 Jul 2008 01:27:23 -0500
Message-ID: 
In-Reply-To: <94a5534b0807292320v4c7c862dme9842e98b13d506e@mail.gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [MEXT] Query on Binding Revocation Procedure for Proxy Mobile
	IPv6
Thread-Index: AcjyDGvwkh7CYFMBT+qyjUP9RpwPcAAAARNw
References: <94a5534b0807290823m6f9ab84bv46adc8b9d6a8f4d4@mail.gmail.com>
	
	<94a5534b0807292320v4c7c862dme9842e98b13d506e@mail.gmail.com>
From: "Ahmad Muhanna" 
To: "Magesh Shanmugam" , 
Subject: Re: [MEXT] Query on Binding Revocation Procedure for Proxy 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: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mext-bounces@ietf.org
Errors-To: mext-bounces@ietf.org

Magesh,

As I said, we will mandate the A bit when the G bit is set. 
On the other hand, I understand your concern as the MAG cleaned all
sessions, e.g. 1-10. sine the A bit is not set. The LMA received BRI to
clean 10 sessions but it already cleaned 1. right?

The LMA needs to clean the remaining 9. that is it.
The MAG already cleaned the session indicated in the LMA BRI and 9 more.
Nothing else should be done.

Now: As a follow up to the new behavior, i.e. G bit is set then A bit is
always set, In case the same scenario happened, then the LMA will send a
BRA with status code "success" since all session have been deleted
anyway.


Regards,
Ahmad
 

> -----Original Message-----
> From: Magesh Shanmugam [mailto:smagesh77@gmail.com] 
> Sent: Wednesday, July 30, 2008 7:21 AM
> To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org
> Subject: Re: [MEXT] Query on Binding Revocation Procedure for 
> Proxy Mobile IPv6
> 
> Ahmad
> 
> Thanks for your explanation.
> 
> My query here is that when MAG sends a BRI with G bit set, 
> but not A bit, then immediately after sending the BRI it will 
> clean up its resources (i.e. Binding Update List and other 
> related resources), but at the LMA side if the cleaning up of 
> resource is partial success (i.e. not all the resources are 
> cleaned-up), then what should be the behavior at MAG, since 
> it might have cleaned up all the resources.
> 
> Regards
> S Magesh
> 
> 
> On 7/30/08, Ahmad Muhanna  wrote:
> > Magesh,
> >
> > Let me try to address in the following way:
> >
> > 1. From administrative prospective, it is sometimes hard to imagine 
> > that the administrative decision would come through the two 
> different 
> > nodes, but I agree this could be looked at from a race 
> condition where 
> > the administrative reasons are different, but possible.
> >
> > 2. This case needs to be addressed as a race condition and 
> should be 
> > handled as follows:
> > 2.1. In case of Global revocation, we MUST mandate that the 
> node which 
> > send a BRI with the 'G' bit is set MUST also set the A bit, 
> since this 
> > BRI is related to many sessions not a single one.
> >
> > 2.2. Even if the A bit is not set in the BRI, if the BRI is 
> > authenticated and securely protected, the receiving node 
> must process 
> > the BRI and delete the session, if the session is already deleted, 
> > then the receiving node does not need to do any thing extra.
> >
> > Hope this address your concern.
> >
> > Regards,
> > Ahmad
> >
> >
> > > -----Original Message-----
> > > From: mext-bounces@ietf.org 
> [mailto:mext-bounces@ietf.org] On Behalf 
> > > Of Magesh Shanmugam
> > > Sent: Tuesday, July 29, 2008 4:23 PM
> > > To: mext@ietf.org
> > > Subject: [MEXT] Query on Binding Revocation Procedure for Proxy 
> > > Mobile IPv6
> > >
> > > Ahmad
> > >
> > > Since the Binding Revocation proceudre (i.e. exchange of 
> BRI & BRA) 
> > > can be triggered by any node in Proxy Mobile IPv6, is it possible 
> > > that both MAG & LMA can trigger BRI message 
> simultaneously (due to 
> > > some adminstrative reasons)
> > >
> > > i.e. MAG sends a BRI with G bit set (i.e. bulk revocation 
> of PMIPv6
> > > bindings) and LMA sends a BRI with either one PMIPv6 binding 
> > > revocation or G bit set for bulk PMIPv6 binding revocation.
> > > Both the BRI messages does not set the A bit in BRI, hence won't 
> > > wait for ACK.
> > >
> > > What should be the behavior at MAG & LMA.
> > >
> > > Thanks
> > > S Magesh
> > > _______________________________________________
> > > MEXT mailing list
> > > MEXT@ietf.org
> > > https://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 Jul 30 00:07:21 2008
Return-Path: 
X-Original-To: nemo-archive@megatron.ietf.org
Delivered-To: ietfarch-nemo-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 74BCD3A69DC;
	Wed, 30 Jul 2008 00:07:21 -0700 (PDT)
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 ED4F43A69DC
	for ; Wed, 30 Jul 2008 00:07:19 -0700 (PDT)
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 DtUECN3+BaxI for ;
	Wed, 30 Jul 2008 00:07:18 -0700 (PDT)
Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175])
	by core3.amsl.com (Postfix) with ESMTP id DB6BA3A6778
	for ; Wed, 30 Jul 2008 00:07:18 -0700 (PDT)
Received: by wf-out-1314.google.com with SMTP id 27so261121wfd.31
	for ; Wed, 30 Jul 2008 00:07:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=domainkey-signature:received:received:message-id:date:from:to
	:subject:in-reply-to:mime-version:content-type
	:content-transfer-encoding:content-disposition:references;
	bh=ykxtbftLemcnOFQIP+t5pK+ToQGSqpCdseInQmhrIFI=;
	b=eE+aqH7Sd8PazQza9sOYu5yfmtTe2ASqJEQ08i5l8+TfbhaD6k0sReGaRirZIJ/iCW
	nZ/ODx9GLY4YL4PAl01d43SR7Nm8uBZd2OWT2Fj1egjpu5XKEwvVsc2CbB5hH25D/OK0
	Qvv5jg8kT4uTo6e+2NO3tfFKisfZFWT12Bv+s=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:to:subject:in-reply-to:mime-version
	:content-type:content-transfer-encoding:content-disposition
	:references;
	b=Yn1Y8DiCMiLtWB0P7CX0hATLKb5HuwhdrOEOLiE9PAKoqNBv+xyR2VRmwXQMjzqBUb
	NO+xVJHw6yLe8TZ8rHcvw2k1yl9wrVD6hw+8tXQPu3BmONCIgD79rqh7T08ZoaW+CduM
	gqJvf3CA6Aw/Y8MmLZ4oj0gEr1Su3W6fJX33Y=
Received: by 10.142.158.17 with SMTP id g17mr2531877wfe.24.1217401651993;
	Wed, 30 Jul 2008 00:07:31 -0700 (PDT)
Received: by 10.143.44.6 with HTTP; Wed, 30 Jul 2008 00:07:31 -0700 (PDT)
Message-ID: <94a5534b0807300007s1bb06161g84672559b586ce43@mail.gmail.com>
Date: Wed, 30 Jul 2008 12:37:31 +0530
From: "Magesh Shanmugam" 
To: "Ahmad Muhanna" , "mext@ietf.org" 
In-Reply-To: 
MIME-Version: 1.0
Content-Disposition: inline
References: <94a5534b0807290823m6f9ab84bv46adc8b9d6a8f4d4@mail.gmail.com>
	
	<94a5534b0807292320v4c7c862dme9842e98b13d506e@mail.gmail.com>
	
Subject: Re: [MEXT] Query on Binding Revocation Procedure for Proxy 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: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mext-bounces@ietf.org
Errors-To: mext-bounces@ietf.org

Ahmad

I'm fine mandating A bit, when either MAG or LMA triggers BRI with G bit set.

Thanks
S Magesh

On 7/30/08, Ahmad Muhanna  wrote:
> Magesh,
>
> As I said, we will mandate the A bit when the G bit is set.
> On the other hand, I understand your concern as the MAG cleaned all
> sessions, e.g. 1-10. sine the A bit is not set. The LMA received BRI to
> clean 10 sessions but it already cleaned 1. right?
>
> The LMA needs to clean the remaining 9. that is it.
> The MAG already cleaned the session indicated in the LMA BRI and 9 more.
> Nothing else should be done.
>
> Now: As a follow up to the new behavior, i.e. G bit is set then A bit is
> always set, In case the same scenario happened, then the LMA will send a
> BRA with status code "success" since all session have been deleted
> anyway.
>
>
> Regards,
> Ahmad
>
>
> > -----Original Message-----
> > From: Magesh Shanmugam [mailto:smagesh77@gmail.com]
> > Sent: Wednesday, July 30, 2008 7:21 AM
> > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org
> > Subject: Re: [MEXT] Query on Binding Revocation Procedure for
> > Proxy Mobile IPv6
> >
> > Ahmad
> >
> > Thanks for your explanation.
> >
> > My query here is that when MAG sends a BRI with G bit set,
> > but not A bit, then immediately after sending the BRI it will
> > clean up its resources (i.e. Binding Update List and other
> > related resources), but at the LMA side if the cleaning up of
> > resource is partial success (i.e. not all the resources are
> > cleaned-up), then what should be the behavior at MAG, since
> > it might have cleaned up all the resources.
> >
> > Regards
> > S Magesh
> >
> >
> > On 7/30/08, Ahmad Muhanna  wrote:
> > > Magesh,
> > >
> > > Let me try to address in the following way:
> > >
> > > 1. From administrative prospective, it is sometimes hard to imagine
> > > that the administrative decision would come through the two
> > different
> > > nodes, but I agree this could be looked at from a race
> > condition where
> > > the administrative reasons are different, but possible.
> > >
> > > 2. This case needs to be addressed as a race condition and
> > should be
> > > handled as follows:
> > > 2.1. In case of Global revocation, we MUST mandate that the
> > node which
> > > send a BRI with the 'G' bit is set MUST also set the A bit,
> > since this
> > > BRI is related to many sessions not a single one.
> > >
> > > 2.2. Even if the A bit is not set in the BRI, if the BRI is
> > > authenticated and securely protected, the receiving node
> > must process
> > > the BRI and delete the session, if the session is already deleted,
> > > then the receiving node does not need to do any thing extra.
> > >
> > > Hope this address your concern.
> > >
> > > Regards,
> > > Ahmad
> > >
> > >
> > > > -----Original Message-----
> > > > From: mext-bounces@ietf.org
> > [mailto:mext-bounces@ietf.org] On Behalf
> > > > Of Magesh Shanmugam
> > > > Sent: Tuesday, July 29, 2008 4:23 PM
> > > > To: mext@ietf.org
> > > > Subject: [MEXT] Query on Binding Revocation Procedure for Proxy
> > > > Mobile IPv6
> > > >
> > > > Ahmad
> > > >
> > > > Since the Binding Revocation proceudre (i.e. exchange of
> > BRI & BRA)
> > > > can be triggered by any node in Proxy Mobile IPv6, is it possible
> > > > that both MAG & LMA can trigger BRI message
> > simultaneously (due to
> > > > some adminstrative reasons)
> > > >
> > > > i.e. MAG sends a BRI with G bit set (i.e. bulk revocation
> > of PMIPv6
> > > > bindings) and LMA sends a BRI with either one PMIPv6 binding
> > > > revocation or G bit set for bulk PMIPv6 binding revocation.
> > > > Both the BRI messages does not set the A bit in BRI, hence won't
> > > > wait for ACK.
> > > >
> > > > What should be the behavior at MAG & LMA.
> > > >
> > > > Thanks
> > > > S Magesh
> > > > _______________________________________________
> > > > MEXT mailing list
> > > > MEXT@ietf.org
> > > > https://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 Jul 30 03:07:06 2008
Return-Path: 
X-Original-To: nemo-archive@megatron.ietf.org
Delivered-To: ietfarch-nemo-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 1131528C296;
	Wed, 30 Jul 2008 03:07:06 -0700 (PDT)
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 370193A6AA4
	for ; Wed, 30 Jul 2008 03:07:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.374
X-Spam-Level: 
X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, 
	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 wDM7RhEggKb2 for ;
	Wed, 30 Jul 2008 03:07:04 -0700 (PDT)
Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms
	[216.52.164.185])
	by core3.amsl.com (Postfix) with ESMTP id BBDA03A6A07
	for ; Wed, 30 Jul 2008 03:07:03 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 30 Jul 2008 06:06:48 -0400
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [MEXT] Query on Binding Revocation Procedure for Proxy MobileIPv6
Thread-Index: AcjyDGvwkh7CYFMBT+qyjUP9RpwPcAAAARNwAAfa4LA=
References: <94a5534b0807290823m6f9ab84bv46adc8b9d6a8f4d4@mail.gmail.com><94a5534b0807292320v4c7c862dme9842e98b13d506e@mail.gmail.com>
	
From: "Vijay Devarapalli" 
To: "Ahmad Muhanna" ,
	"Magesh Shanmugam" , 
Subject: Re: [MEXT] Query on Binding Revocation Procedure for Proxy
	MobileIPv6
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 Ahmad,

A related question. Why don't we set the 'A' bit all the time? It seems
to me that it is a good idea to get a confirmation any time you revoke a
binding.

Vijay 

> -----Original Message-----
> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On 
> Behalf Of Ahmad Muhanna
> Sent: Tuesday, July 29, 2008 11:27 PM
> To: Magesh Shanmugam; mext@ietf.org
> Subject: Re: [MEXT] Query on Binding Revocation Procedure for 
> Proxy MobileIPv6
> 
> Magesh,
> 
> As I said, we will mandate the A bit when the G bit is set. 
> On the other hand, I understand your concern as the MAG cleaned all
> sessions, e.g. 1-10. sine the A bit is not set. The LMA 
> received BRI to
> clean 10 sessions but it already cleaned 1. right?
> 
> The LMA needs to clean the remaining 9. that is it.
> The MAG already cleaned the session indicated in the LMA BRI 
> and 9 more.
> Nothing else should be done.
> 
> Now: As a follow up to the new behavior, i.e. G bit is set 
> then A bit is
> always set, In case the same scenario happened, then the LMA 
> will send a
> BRA with status code "success" since all session have been deleted
> anyway.
> 
> 
> Regards,
> Ahmad
>  
> 
> > -----Original Message-----
> > From: Magesh Shanmugam [mailto:smagesh77@gmail.com] 
> > Sent: Wednesday, July 30, 2008 7:21 AM
> > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org
> > Subject: Re: [MEXT] Query on Binding Revocation Procedure for 
> > Proxy Mobile IPv6
> > 
> > Ahmad
> > 
> > Thanks for your explanation.
> > 
> > My query here is that when MAG sends a BRI with G bit set, 
> > but not A bit, then immediately after sending the BRI it will 
> > clean up its resources (i.e. Binding Update List and other 
> > related resources), but at the LMA side if the cleaning up of 
> > resource is partial success (i.e. not all the resources are 
> > cleaned-up), then what should be the behavior at MAG, since 
> > it might have cleaned up all the resources.
> > 
> > Regards
> > S Magesh
> > 
> > 
> > On 7/30/08, Ahmad Muhanna  wrote:
> > > Magesh,
> > >
> > > Let me try to address in the following way:
> > >
> > > 1. From administrative prospective, it is sometimes hard 
> to imagine 
> > > that the administrative decision would come through the two 
> > different 
> > > nodes, but I agree this could be looked at from a race 
> > condition where 
> > > the administrative reasons are different, but possible.
> > >
> > > 2. This case needs to be addressed as a race condition and 
> > should be 
> > > handled as follows:
> > > 2.1. In case of Global revocation, we MUST mandate that the 
> > node which 
> > > send a BRI with the 'G' bit is set MUST also set the A bit, 
> > since this 
> > > BRI is related to many sessions not a single one.
> > >
> > > 2.2. Even if the A bit is not set in the BRI, if the BRI is 
> > > authenticated and securely protected, the receiving node 
> > must process 
> > > the BRI and delete the session, if the session is already 
> deleted, 
> > > then the receiving node does not need to do any thing extra.
> > >
> > > Hope this address your concern.
> > >
> > > Regards,
> > > Ahmad
> > >
> > >
> > > > -----Original Message-----
> > > > From: mext-bounces@ietf.org 
> > [mailto:mext-bounces@ietf.org] On Behalf 
> > > > Of Magesh Shanmugam
> > > > Sent: Tuesday, July 29, 2008 4:23 PM
> > > > To: mext@ietf.org
> > > > Subject: [MEXT] Query on Binding Revocation Procedure for Proxy 
> > > > Mobile IPv6
> > > >
> > > > Ahmad
> > > >
> > > > Since the Binding Revocation proceudre (i.e. exchange of 
> > BRI & BRA) 
> > > > can be triggered by any node in Proxy Mobile IPv6, is 
> it possible 
> > > > that both MAG & LMA can trigger BRI message 
> > simultaneously (due to 
> > > > some adminstrative reasons)
> > > >
> > > > i.e. MAG sends a BRI with G bit set (i.e. bulk revocation 
> > of PMIPv6
> > > > bindings) and LMA sends a BRI with either one PMIPv6 binding 
> > > > revocation or G bit set for bulk PMIPv6 binding revocation.
> > > > Both the BRI messages does not set the A bit in BRI, 
> hence won't 
> > > > wait for ACK.
> > > >
> > > > What should be the behavior at MAG & LMA.
> > > >
> > > > Thanks
> > > > S Magesh
> > > > _______________________________________________
> > > > MEXT mailing list
> > > > MEXT@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/mext
> > > >
> > >
> > 
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://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 Jul 30 04:55:22 2008
Return-Path: 
X-Original-To: nemo-archive@megatron.ietf.org
Delivered-To: ietfarch-nemo-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id BAE7E28C1A0;
	Wed, 30 Jul 2008 04:55:22 -0700 (PDT)
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 DC4E828C29B
	for ; Wed, 30 Jul 2008 04:55:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.449
X-Spam-Level: 
X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 
	BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id KGSRVfm8eAPL for ;
	Wed, 30 Jul 2008 04:55:20 -0700 (PDT)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56])
	by core3.amsl.com (Postfix) with ESMTP id 96A6A3A68B3
	for ; Wed, 30 Jul 2008 04:55:20 -0700 (PDT)
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
	m6UBr4L09037; Wed, 30 Jul 2008 11:53:04 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 30 Jul 2008 06:54:48 -0500
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [MEXT] Query on Binding Revocation Procedure for Proxy MobileIPv6
Thread-Index: AcjyDGvwkh7CYFMBT+qyjUP9RpwPcAAAARNwAAfa4LAAA4ldwA==
References: <94a5534b0807290823m6f9ab84bv46adc8b9d6a8f4d4@mail.gmail.com><94a5534b0807292320v4c7c862dme9842e98b13d506e@mail.gmail.com>
	
	
From: "Ahmad Muhanna" 
To: "Vijay Devarapalli" ,
	"Magesh Shanmugam" , 
Subject: Re: [MEXT] Query on Binding Revocation Procedure for Proxy
	MobileIPv6
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,

That is not a bad idea. If people on the list think that the 'A' bit
needs to be set all the times, then I can update the document
accordingly.

My personal opinion, the famous 'should' will give the needed
flexibility while we mandate the obvious behavior, i.e. in global
revocation.

Regards,
Ahmad
 

> -----Original Message-----
> From: Vijay Devarapalli [mailto:vijay@wichorus.com] 
> Sent: Wednesday, July 30, 2008 11:07 AM
> To: Muhanna, Ahmad (RICH1:2H10); Magesh Shanmugam; mext@ietf.org
> Subject: RE: [MEXT] Query on Binding Revocation Procedure for 
> Proxy MobileIPv6
> 
> Hi Ahmad,
> 
> A related question. Why don't we set the 'A' bit all the 
> time? It seems to me that it is a good idea to get a 
> confirmation any time you revoke a binding.
> 
> Vijay 
> 
> > -----Original Message-----
> > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] 
> On Behalf 
> > Of Ahmad Muhanna
> > Sent: Tuesday, July 29, 2008 11:27 PM
> > To: Magesh Shanmugam; mext@ietf.org
> > Subject: Re: [MEXT] Query on Binding Revocation Procedure for Proxy 
> > MobileIPv6
> > 
> > Magesh,
> > 
> > As I said, we will mandate the A bit when the G bit is set. 
> > On the other hand, I understand your concern as the MAG cleaned all 
> > sessions, e.g. 1-10. sine the A bit is not set. The LMA 
> received BRI 
> > to clean 10 sessions but it already cleaned 1. right?
> > 
> > The LMA needs to clean the remaining 9. that is it.
> > The MAG already cleaned the session indicated in the LMA BRI and 9 
> > more.
> > Nothing else should be done.
> > 
> > Now: As a follow up to the new behavior, i.e. G bit is set 
> then A bit 
> > is always set, In case the same scenario happened, then the 
> LMA will 
> > send a BRA with status code "success" since all session have been 
> > deleted anyway.
> > 
> > 
> > Regards,
> > Ahmad
> >  
> > 
> > > -----Original Message-----
> > > From: Magesh Shanmugam [mailto:smagesh77@gmail.com] 
> > > Sent: Wednesday, July 30, 2008 7:21 AM
> > > To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org
> > > Subject: Re: [MEXT] Query on Binding Revocation Procedure for 
> > > Proxy Mobile IPv6
> > > 
> > > Ahmad
> > > 
> > > Thanks for your explanation.
> > > 
> > > My query here is that when MAG sends a BRI with G bit set, 
> > > but not A bit, then immediately after sending the BRI it will 
> > > clean up its resources (i.e. Binding Update List and other 
> > > related resources), but at the LMA side if the cleaning up of 
> > > resource is partial success (i.e. not all the resources are 
> > > cleaned-up), then what should be the behavior at MAG, since 
> > > it might have cleaned up all the resources.
> > > 
> > > Regards
> > > S Magesh
> > > 
> > > 
> > > On 7/30/08, Ahmad Muhanna  wrote:
> > > > Magesh,
> > > >
> > > > Let me try to address in the following way:
> > > >
> > > > 1. From administrative prospective, it is sometimes hard 
> > to imagine 
> > > > that the administrative decision would come through the two 
> > > different 
> > > > nodes, but I agree this could be looked at from a race 
> > > condition where 
> > > > the administrative reasons are different, but possible.
> > > >
> > > > 2. This case needs to be addressed as a race condition and 
> > > should be 
> > > > handled as follows:
> > > > 2.1. In case of Global revocation, we MUST mandate that the 
> > > node which 
> > > > send a BRI with the 'G' bit is set MUST also set the A bit, 
> > > since this 
> > > > BRI is related to many sessions not a single one.
> > > >
> > > > 2.2. Even if the A bit is not set in the BRI, if the BRI is 
> > > > authenticated and securely protected, the receiving node 
> > > must process 
> > > > the BRI and delete the session, if the session is already 
> > deleted, 
> > > > then the receiving node does not need to do any thing extra.
> > > >
> > > > Hope this address your concern.
> > > >
> > > > Regards,
> > > > Ahmad
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: mext-bounces@ietf.org 
> > > [mailto:mext-bounces@ietf.org] On Behalf 
> > > > > Of Magesh Shanmugam
> > > > > Sent: Tuesday, July 29, 2008 4:23 PM
> > > > > To: mext@ietf.org
> > > > > Subject: [MEXT] Query on Binding Revocation Procedure 
> for Proxy 
> > > > > Mobile IPv6
> > > > >
> > > > > Ahmad
> > > > >
> > > > > Since the Binding Revocation proceudre (i.e. exchange of 
> > > BRI & BRA) 
> > > > > can be triggered by any node in Proxy Mobile IPv6, is 
> > it possible 
> > > > > that both MAG & LMA can trigger BRI message 
> > > simultaneously (due to 
> > > > > some adminstrative reasons)
> > > > >
> > > > > i.e. MAG sends a BRI with G bit set (i.e. bulk revocation 
> > > of PMIPv6
> > > > > bindings) and LMA sends a BRI with either one PMIPv6 binding 
> > > > > revocation or G bit set for bulk PMIPv6 binding revocation.
> > > > > Both the BRI messages does not set the A bit in BRI, 
> > hence won't 
> > > > > wait for ACK.
> > > > >
> > > > > What should be the behavior at MAG & LMA.
> > > > >
> > > > > Thanks
> > > > > S Magesh
> > > > > _______________________________________________
> > > > > MEXT mailing list
> > > > > MEXT@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/mext
> > > > >
> > > >
> > > 
> > _______________________________________________
> > MEXT mailing list
> > MEXT@ietf.org
> > https://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 Jul 30 10:48:16 2008
Return-Path: 
X-Original-To: nemo-archive@megatron.ietf.org
Delivered-To: ietfarch-nemo-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id E131B28C3B2;
	Wed, 30 Jul 2008 10:48:15 -0700 (PDT)
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 C799D28C0ED
	for ; Tue, 29 Jul 2008 09:58:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.386
X-Spam-Level: 
X-Spam-Status: No, score=-0.386 tagged_above=-999 required=5 tests=[AWL=0.050, 
	BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 
	HTML_MESSAGE=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 u4fvVKdYSyT6 for ;
	Tue, 29 Jul 2008 09:58:19 -0700 (PDT)
Received: from ricky.india.internal.net (unknown [59.145.147.70])
	by core3.amsl.com (Postfix) with ESMTP id 09B2D28C0EE
	for ; Tue, 29 Jul 2008 09:57:00 -0700 (PDT)
Received: from Magesh (magesh.india.internal.net.16.172.in-addr.arpa
	[172.16.8.41] (may be forged))
	by ricky.india.internal.net (8.12.10/8.12.10) with ESMTP id
	m6TGwNH5006459 for ; Tue, 29 Jul 2008 22:28:23 +0530
Message-Id: <200807291658.m6TGwNH5006459@ricky.india.internal.net>
From: "Magesh Shanmugam" 
To: 
Date: Tue, 29 Jul 2008 22:36:00 +0530
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Thread-Index: AcjxnWAqb5Xlvnc2TqmVR6T3mSHKsQ==
X-Cyberoam-Version: 9.5.3.22
X-Cyberoam-smtpxy-version: 0.0.3.0
X-Cyberoam-AV-Status: Clean
X-Cyberoam-Proto: SMTP
X-Cyberoam-AV-Policy: None
X-Cyberoam-AS-Policy: Global Spam Policy
X-Mailman-Approved-At: Wed, 30 Jul 2008 10:48:14 -0700
Subject: [MEXT] Query on Binding Revocation Procedure for Proxy 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: ,
	
Content-Type: multipart/mixed; boundary="===============1943623729=="
Sender: mext-bounces@ietf.org
Errors-To: mext-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1943623729==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_009D_01C8F1CB.86200680"

This is a multi-part message in MIME format.

------=_NextPart_000_009D_01C8F1CB.86200680
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Ahmad

Since the Binding Revocation proceudre (i.e. exchange of BRI & BRA)
can be triggered by any node in Proxy Mobile IPv6, is it possible that
both MAG & LMA can trigger BRI message simultaneously (due to some
adminstrative reasons)

i.e. MAG sends a BRI with G bit set (i.e. bulk revocation of PMIPv6
bindings) and LMA sends a BRI with either one PMIPv6 binding
revocation or G bit set for bulk PMIPv6 binding revocation.  Both the
BRI messages does not set the A bit in BRI, hence won't wait for ACK.

What should be the behavior at MAG & LMA.

Thanks
S Magesh



------=_NextPart_000_009D_01C8F1CB.86200680
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









Ahmad

Since the=20
Binding Revocation proceudre (i.e. exchange of BRI & BRA)
can be=20
triggered by any node in Proxy Mobile IPv6, is it possible that
both =
MAG=20
& LMA can trigger BRI message simultaneously (due to =
some
adminstrative=20
reasons)

i.e. MAG sends a BRI with G bit set (i.e. bulk =
revocation of=20
PMIPv6
bindings) and LMA sends a BRI with either one PMIPv6=20
binding
revocation or G bit set for bulk PMIPv6 binding revocation.=20
 Both the
BRI messages does not set the A bit in BRI, hence =
won't wait=20
for ACK.

What should be the behavior at MAG & =
LMA.

Thanks
S=20
Magesh



------=_NextPart_000_009D_01C8F1CB.86200680--


--===============1943623729==
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

--===============1943623729==--



From mext-bounces@ietf.org  Wed Jul 30 11:07:22 2008
Return-Path: 
X-Original-To: nemo-archive@megatron.ietf.org
Delivered-To: ietfarch-nemo-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id D56D928C3C1;
	Wed, 30 Jul 2008 11:07:22 -0700 (PDT)
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 AE7EB28C3C3
	for ; Wed, 30 Jul 2008 11:02:55 -0700 (PDT)
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 H-qYPF7PUCei for ;
	Wed, 30 Jul 2008 11:02:54 -0700 (PDT)
Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26])
	by core3.amsl.com (Postfix) with ESMTP id 5630C28C3BB
	for ; Wed, 30 Jul 2008 11:02:54 -0700 (PDT)
Received: by qw-out-2122.google.com with SMTP id 3so14945qwe.31
	for ; Wed, 30 Jul 2008 11:03:06 -0700 (PDT)
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:date:content-type:message-id:sender;
	bh=2xrXei/9oNnNTlOyjsDjksae5KhEi7mriqbd5ERtKFA=;
	b=EBVSjSfFAEYtVRwBGQfarsTAy+QPiGpY4acltEX7Lh7bkwgHFUYv6yGlIhZ+F6xAMd
	lhd4hYUGpSax9Jd42LcCloBy1dRbmya5IqRqfNeAhXrK2XR1bFJfDH+lg1+cB7NH722K
	0b1CM56ecj6ndQE6tw3o7FVg/NxJ44PmZ370g=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=from:to:subject:user-agent:cc:mime-version:date:content-type
	:message-id:sender;
	b=nhzgV9plhe2H+FUNRus6ZQQkcgh67UDb+CpThJWDg8t90US0sYhDtAzVtItpYq9E5I
	aZsWqrCWwPzV5GaolObFLGiBaWOYNyqMLCEZujY9RFbXKocCEcTcGw9BLX+rVa4LL8rB
	O5dzcUWSuFoE3hGUgWBWG84OsrGAPLJkvPts0=
Received: by 10.214.9.8 with SMTP id 8mr5353078qai.29.1217440986305;
	Wed, 30 Jul 2008 11:03:06 -0700 (PDT)
Received: from klee.meeting.ietf.org ( [130.129.19.49])
	by mx.google.com with ESMTPS id i52sm2372600rne.16.2008.07.30.11.03.04
	(version=TLSv1/SSLv3 cipher=RC4-MD5);
	Wed, 30 Jul 2008 11:03:05 -0700 (PDT)
From: Julien Laganier 
To: iesg-secretary@ietf.org
User-Agent: KMail/1.8.2
MIME-Version: 1.0
Date: Wed, 30 Jul 2008 20:03:01 +0200
Content-Type: Multipart/Mixed;
  boundary="Boundary-00=_VzKkIv+1TUKJ/5x"
Message-Id: <200807302003.01751.julien.IETF@laposte.net>
X-Mailman-Approved-At: Wed, 30 Jul 2008 11:07:21 -0700
Cc: draft-ietf-mext-nemo-v4traversal@tools.ietf.org, mext@ietf.org
Subject: [MEXT] Submission of DSMIPv6 specification to IESG
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=_VzKkIv+1TUKJ/5x
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

IESG secretariat:

We'd like to submit the following draft to IESG for 
publication as Proposed Standard:

draft-ietf-mext-nemo-v4traversal-05

Attached is the document shepherd write-up.

Best,

--julien

--Boundary-00=_VzKkIv+1TUKJ/5x
Content-Type: text/plain;
  charset="us-ascii";
  name="DSMIPv6-writeup.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="DSMIPv6-writeup.txt"

   (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

The Document Shepherd for this document is Julien Laganier, MEXT co-chair, who
reviewed this version of the document and believes this version is ready for
forwarding to the IESG.

   (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

Yes, the document had review from both inside and outside the WG.

   (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

No.

   (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

No.

   (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

The whole WG is behind this document.

   (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarise the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

No.

   (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?

Yes.

   (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

Yes.

   (1.i)  Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?

Yes.

   (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

Yes (The document does not contain formal language).

   (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up?  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary
             Relevant content can frequently be found in the abstract
             and/or introduction of the document.  If not, this may be
             an indication that there are deficiencies in the abstract
             or introduction.

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.

          Working Group Summary
             Was there anything in WG process that is worth noting?  For
             example, was there controversy about particular points or
             were there decisions where the consensus was particularly
             rough?

This document is a product of the Mobility EXTensions for IPv6 (MEXT) working
group.

          Document Quality
             Are there existing implementations of the protocol?  Have a
             significant number of vendors indicated their plan to
             implement the specification?  Are there any reviewers that
             merit special mention as having done a thorough review,
             e.g., one that resulted in important changes or a
             conclusion that the document had no substantive issues?  If
             there was a MIB Doctor, Media Type or other expert review,
             what was its course (briefly)?  In the case of a Media Type
             review, on what date was the request posted?

Pasi Eronen reviewed the specification and his comments regarding interaction
of DSMIPv6 with the IPsec architecture were resolved.

          Personnel
             Who is the Document Shepherd for this document?  Who is the
             Responsible Area Director?

The Document Shepherd for this document is Julien Laganier (MEXT WG co-chair).
The Responsible Area Director is Jari Arkko (Internet Area Director).

--Boundary-00=_VzKkIv+1TUKJ/5x
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

--Boundary-00=_VzKkIv+1TUKJ/5x--


From mext-bounces@ietf.org  Thu Jul 31 05:17:26 2008
Return-Path: 
X-Original-To: nemo-archive@megatron.ietf.org
Delivered-To: ietfarch-nemo-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 27DD93A6C1E;
	Thu, 31 Jul 2008 05:17:26 -0700 (PDT)
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 AF6DE3A6C1E
	for ; Thu, 31 Jul 2008 05:17:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.466
X-Spam-Level: 
X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133, 
	BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id sDnJf4LQFOsh for ;
	Thu, 31 Jul 2008 05:17:24 -0700 (PDT)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56])
	by core3.amsl.com (Postfix) with ESMTP id 98CE33A677C
	for ; Thu, 31 Jul 2008 05:17:24 -0700 (PDT)
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
	m6VCEwT29454; Thu, 31 Jul 2008 12:14:58 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 31 Jul 2008 07:16:49 -0500
Message-ID: 
In-Reply-To: <200807311415.01657.julien.IETF@laposte.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [MEXT] Adoption of draft-muhanna-mext-binding-revocation-02.txt
Thread-Index: AcjzBxhRMQQz0b3ARH+obFBcZKg7kwAABHiw
References: <200807141903.26551.julien.IETF@laposte.net>
	<200807311415.01657.julien.IETF@laposte.net>
From: "Ahmad Muhanna" 
To: "Julien Laganier" , ,
	
Subject: Re: [MEXT] Adoption of draft-muhanna-mext-binding-revocation-02.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 Julien;

We Will submit the draft before the end of the week.


Regards,
Ahmad
 

> -----Original Message-----
> From: julien laganier [mailto:julien.laganier@gmail.com] On 
> Behalf Of Julien Laganier
> Sent: Thursday, July 31, 2008 1:15 PM
> To: mext@ietf.org; 
> draft-muhanna-mext-binding-revocation@tools.ietf.org
> Subject: Re: [MEXT] Adoption of 
> draft-muhanna-mext-binding-revocation-02.txt
> 
> Folks,
> 
> We have WG consensus to adopt this draft as a WG item. 
> Authors, please resubmit the draft as:
> 
> draft-ietf-mext-binding-revocation-00.txt
> 
> --julien & marcelo, MEXT chairs
> 
> On Monday 14 July 2008, Julien Laganier wrote:
> > Hello Folks,
> >
> > The MEXT WG has a deliverable for Binding Revocation for IP 
> Mobility.
> >
> > Hereby we'd like to ask WG participants whether or not they 
> think this 
> > individual submission should be adopted as the 
> corresponding MEXT work 
> > item. Please answer to this note to state your opinion by 
> Monday July 
> > 28th.
> >
> > Thank you for your support,
> >
> > -- julien & marcelo, MEXT chairs
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> > directories.
> >
> > 	Title           : Binding Revocation for IPv6 Mobility
> > 	Author(s)       : A. Muhanna, et al.
> > 	Filename        : draft-muhanna-mext-binding-revocation-02.txt
> > 	Pages           : 32
> > 	Date            : 2008-07-11
> >
> > This document defines the revocation semantics for terminating a 
> > mobile node's mobility session and associated resources.  These 
> > semantics are generic enough and can be used by mobility 
> entities in 
> > the case of Client Mobile IPv6 and its extensions.  This mechanism 
> > allows the mobility entity which initiates the revocation 
> procedure to 
> > request its corresponding one to terminate either one, 
> multiple or all 
> > specified binding cache entries.
> >
> > A URL for this Internet-Draft is:
> > 
> http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding-revoca
> >tion-02.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > Below is the data which will enable a MIME compliant mail reader 
> > implementation to automatically retrieve the ASCII version of the 
> > Internet-Draft.
> 
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext


From mext-bounces@ietf.org  Thu Jul 31 05:20:59 2008
Return-Path: 
X-Original-To: nemo-archive@megatron.ietf.org
Delivered-To: ietfarch-nemo-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 2E7E23A6C37;
	Thu, 31 Jul 2008 05:20:59 -0700 (PDT)
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 F2BDC3A6C0C
	for ; Thu, 31 Jul 2008 05:14:14 -0700 (PDT)
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 mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id RPEkrFsnHe9J for ;
	Thu, 31 Jul 2008 05:14:14 -0700 (PDT)
Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30])
	by core3.amsl.com (Postfix) with ESMTP id E9A353A69E3
	for ; Thu, 31 Jul 2008 05:14:13 -0700 (PDT)
Received: by yw-out-2324.google.com with SMTP id 3so239475ywj.49
	for ; Thu, 31 Jul 2008 05:14:01 -0700 (PDT)
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:references:in-reply-to:mime-version:content-type
	:content-transfer-encoding:content-disposition:message-id:sender;
	bh=R+/e+4MsT2oat6CFzTFER/DnzW9T0SB85J3axYd3Etk=;
	b=lftrvRoiXxkJCWHjSeJPpyB0rph7fyzwS/YwAsRb17UdH3bxJKzb8mVEkmn+vmTOBs
	nutLb8ypYONHHc2J3WZ66koPayjkZczahwCfD+FTTAuICkhvSa+tNPJOo5cbf/HUfTKv
	8Pjg8Y7G1Kpw8P4AL2fqgFDCh6qrgHkWvjhNg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=from:to:subject:date:user-agent:references:in-reply-to:mime-version
	:content-type:content-transfer-encoding:content-disposition
	:message-id:sender;
	b=vbOrXvyBJCEHgWLGYQlDGBEwmo3pGrVGH1VtOgyh7JhBKY3dt1tLu0g9ueuvSEeGLj
	OUEB6esK3nl0gDzK1J9guskNQrtGx3RnYzhJItxJwf9NAS9rPx1X2NUymS+vCmpOJcDG
	gHTAYrRukJI2niaBsfKuveqPkO+RLEZckSzR4=
Received: by 10.151.41.21 with SMTP id t21mr1129918ybj.212.1217506441019;
	Thu, 31 Jul 2008 05:14:01 -0700 (PDT)
Received: from klee.local ( [130.129.19.49])
	by mx.google.com with ESMTPS id a30sm4467220rnb.8.2008.07.31.05.13.56
	(version=TLSv1/SSLv3 cipher=RC4-MD5);
	Thu, 31 Jul 2008 05:13:59 -0700 (PDT)
From: Julien Laganier 
To: mext@ietf.org,
 draft-haley-mext-generic-signaling-message@tools.ietf.org
Date: Thu, 31 Jul 2008 14:13:54 +0200
User-Agent: KMail/1.9.6
References: <200807141903.00610.julien.IETF@laposte.net>
In-Reply-To: <200807141903.00610.julien.IETF@laposte.net>
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <200807311413.54215.julien.IETF@laposte.net>
X-Mailman-Approved-At: Thu, 31 Jul 2008 05:20:57 -0700
Subject: Re: [MEXT] Adoption of
	draft-haley-mext-generic-signaling-message-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

Folks,

We have WG consensus to adopt this draft as a WG item. Authors, please 
resubmit the draft as:

draft-ietf-mext-generic-signaling-message-00.txt

--julien & marcelo, MEXT chairs

On Monday 14 July 2008, Julien Laganier wrote:
> Hello Folks,
>
> The MEXT WG has a deliverable for a Generic Signaling Message for
> MIPv6.
>
> Hereby we'd like to ask WG participants whether or not they think
> this individual submission should be adopted as the corresponding
> MEXT work item. Please answer to this note to state your opinion by
> Monday July 28th.
>
> Thank you for your support,
>
> -- julien & marcelo, MEXT chairs
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext


From mext-bounces@ietf.org  Thu Jul 31 05:20:59 2008
Return-Path: 
X-Original-To: nemo-archive@megatron.ietf.org
Delivered-To: ietfarch-nemo-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id C9B3C28C0E2;
	Thu, 31 Jul 2008 05:20:59 -0700 (PDT)
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 225FE3A6A40
	for ; Thu, 31 Jul 2008 05:15:27 -0700 (PDT)
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 bDvUW13nWE16 for ;
	Thu, 31 Jul 2008 05:15:26 -0700 (PDT)
Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28])
	by core3.amsl.com (Postfix) with ESMTP id F137D3A6C0C
	for ; Thu, 31 Jul 2008 05:15:25 -0700 (PDT)
Received: by yw-out-2324.google.com with SMTP id 3so239642ywj.49
	for ; Thu, 31 Jul 2008 05:15:05 -0700 (PDT)
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:references:in-reply-to:mime-version:content-type
	:content-transfer-encoding:content-disposition:message-id:sender;
	bh=uXACxirwvZ+fserwhiVauO0aZ6ezhWe+4EvdP9GROxA=;
	b=LhoXngB/Ol/Zq/JliSJBKW56HWX3uRDoNHqrAloGEDgaZtKLPUksz2xWB61t71WYM/
	d7bhQR9V3ulbZwfayeP54V858rbXGjwS5T8hAD4vDbl2r7bNbR3Td/c9ql0Q6Qh2FYHR
	7hjHJPtNZLpXiSynT/E2asA3lFOpCswgmXtPQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=from:to:subject:date:user-agent:references:in-reply-to:mime-version
	:content-type:content-transfer-encoding:content-disposition
	:message-id:sender;
	b=tL30AnOqbXkV/y837lvCo5YNX8yQH/DUZn57vKNKHaK8Xn/qvFmTy8PLjgUr8XQ6gr
	YbENiAi83BEN0J6nFcTgzd0Eel00A9HmGbWgt2CFnmc+xwiXZ8tXGJhlYCmmCJaRhT/O
	YqKB2OQXMVD1uxlLyjw4qhTgSax89pzQ3/At8=
Received: by 10.151.145.11 with SMTP id x11mr1129635ybn.182.1217506505751;
	Thu, 31 Jul 2008 05:15:05 -0700 (PDT)
Received: from klee.local ( [130.129.19.49])
	by mx.google.com with ESMTPS id a68sm4418502rnc.12.2008.07.31.05.15.03
	(version=TLSv1/SSLv3 cipher=RC4-MD5);
	Thu, 31 Jul 2008 05:15:05 -0700 (PDT)
From: Julien Laganier 
To: mext@ietf.org,
 draft-muhanna-mext-binding-revocation@tools.ietf.org
Date: Thu, 31 Jul 2008 14:15:01 +0200
User-Agent: KMail/1.9.6
References: <200807141903.26551.julien.IETF@laposte.net>
In-Reply-To: <200807141903.26551.julien.IETF@laposte.net>
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <200807311415.01657.julien.IETF@laposte.net>
X-Mailman-Approved-At: Thu, 31 Jul 2008 05:20:57 -0700
Subject: Re: [MEXT] Adoption of draft-muhanna-mext-binding-revocation-02.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,

We have WG consensus to adopt this draft as a WG item. Authors, please 
resubmit the draft as:

draft-ietf-mext-binding-revocation-00.txt

--julien & marcelo, MEXT chairs

On Monday 14 July 2008, Julien Laganier wrote:
> Hello Folks,
>
> The MEXT WG has a deliverable for Binding Revocation for IP Mobility.
>
> Hereby we'd like to ask WG participants whether or not they think
> this individual submission should be adopted as the corresponding
> MEXT work item. Please answer to this note to state your opinion by
> Monday July 28th.
>
> Thank you for your support,
>
> -- julien & marcelo, MEXT chairs
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
> 	Title           : Binding Revocation for IPv6 Mobility
> 	Author(s)       : A. Muhanna, et al.
> 	Filename        : draft-muhanna-mext-binding-revocation-02.txt
> 	Pages           : 32
> 	Date            : 2008-07-11
>
> This document defines the revocation semantics for terminating a
> mobile node's mobility session and associated resources.  These
> semantics are generic enough and can be used by mobility entities in
> the case of Client Mobile IPv6 and its extensions.  This mechanism
> allows the mobility entity which initiates the revocation procedure
> to request its corresponding one to terminate either one, multiple or
> all specified binding cache entries.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding-revoca
>tion-02.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext


From mext-bounces@ietf.org  Thu Jul 31 06:02:56 2008
Return-Path: 
X-Original-To: nemo-archive@megatron.ietf.org
Delivered-To: ietfarch-nemo-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id E71913A6806;
	Thu, 31 Jul 2008 06:02:55 -0700 (PDT)
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 022CF3A63EC
	for ; Thu, 31 Jul 2008 06:00:52 -0700 (PDT)
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 kTz3hS+QoyuM for ;
	Thu, 31 Jul 2008 06:00:49 -0700 (PDT)
Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29])
	by core3.amsl.com (Postfix) with ESMTP id 0E0D63A67AE
	for ; Thu, 31 Jul 2008 06:00:48 -0700 (PDT)
Received: by yw-out-2324.google.com with SMTP id 3so248464ywj.49
	for ; Thu, 31 Jul 2008 06:00:18 -0700 (PDT)
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-disposition:message-id:content-type
	:content-transfer-encoding:sender;
	bh=C1NDMO19n/o00fGfz2Cd4zQJUHeWNtIMT/5Li+Trb1w=;
	b=WcpYPGOZUJjMrucQeffXbD80S1WPWd4PirWiMRMGsCHZeDSIMZJlHr4y7Ho5OyX1q1
	xiFYnN/zevg9BRxC1Lz90ivNhvPGC//Bl+nbH98n810zLYs+oPxNpzVBT6hAhrikSf1r
	swNQFuI8hAZKDuwiP+EsCfDA52EyPKNuf2GpQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=from:to:subject:date:user-agent:mime-version:content-disposition
	:message-id:content-type:content-transfer-encoding:sender;
	b=HIkV1wCYEpTkW5fC5JAxhM6qMjRhU4cpmbBBdAev/wM5iNyrEios3I2akzUoF1OABT
	cb5cOJo2rPkOQpPU1QnQDfKdqt2jF9kVsTqSl9ryuULRDTgGJvAOgKCHkJB3oN9XcNoi
	zIdhwLpTd2jL6P7uY9R4WOMC2MYQOSNtKl3z0=
Received: by 10.150.137.8 with SMTP id k8mr1197932ybd.87.1217509218685;
	Thu, 31 Jul 2008 06:00:18 -0700 (PDT)
Received: from klee.meeting.ietf.org ( [130.129.19.49])
	by mx.google.com with ESMTPS id i51sm4579034rne.18.2008.07.31.05.59.44
	(version=TLSv1/SSLv3 cipher=RC4-MD5);
	Thu, 31 Jul 2008 06:00:07 -0700 (PDT)
From: Julien Laganier 
To: mext@ietf.org,
 marcelo bagnulo braun 
Date: Thu, 31 Jul 2008 14:59:14 +0200
User-Agent: KMail/1.9.6
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <200807311459.15169.julien.IETF@laposte.net>
X-Mailman-Approved-At: Thu, 31 Jul 2008 06:02:54 -0700
Subject: [MEXT] Consensus call: Binding revocation will NOT use GSM
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,

During the 2nd MEXT session, there was consensus amongst the session 
attendees that Binding Revocation shall NOT use the GSM framework. 
Rather, the consensus was that binding revocation shall use directly 
the mobility header and allocates its own MH types values.

Hereby we'd like to confirm that room consensus on the mailing list. If 
you haven't expressed an opinion during the session, please send a note 
to the list stating whether you agree or disagree with that room 
consensus by 2008-08-14.

-- julien & marcelo, MEXT chairs



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


From mext-bounces@ietf.org  Thu Jul 31 06:14:28 2008
Return-Path: 
X-Original-To: nemo-archive@megatron.ietf.org
Delivered-To: ietfarch-nemo-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id EEAC93A69BE;
	Thu, 31 Jul 2008 06:14:27 -0700 (PDT)
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 8BF213A6848
	for ; Thu, 31 Jul 2008 06:14:12 -0700 (PDT)
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 mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id tn7zpy4mtMGG for ;
	Thu, 31 Jul 2008 06:14:11 -0700 (PDT)
Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31])
	by core3.amsl.com (Postfix) with ESMTP id B00043A69BB
	for ; Thu, 31 Jul 2008 06:14:11 -0700 (PDT)
Received: by yw-out-2324.google.com with SMTP id 3so251553ywj.49
	for ; Thu, 31 Jul 2008 06:14:29 -0700 (PDT)
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:mime-version:content-type:content-transfer-encoding
	:content-disposition:message-id:sender;
	bh=5xuKk5oTxlkA6mIUiMoPX6cmSPm4LuurrhV/8pWTJDE=;
	b=Bu+V3TMZIS6bPauL/OI2UgOPFjwF1ohZxwpUKN41lSBJ9bagsoABNfRijhRfY3C+Zr
	rYAwSJdejNo0L6S6qfcLk6JPS2iSxJZuJJidjYwCg4N/jNz0TuOZlSqi4amqlufYRIoh
	e2hEbaoCvanRPd86P3Zuz+ycTUcxzhwAXYzM8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=from:to:subject:date:user-agent:cc:mime-version:content-type
	:content-transfer-encoding:content-disposition:message-id:sender;
	b=V3mLzP9LMYGRS9Q6lK+SQmtkoIG3mavZ1VQEnYzJ0e0gHfNL/+LKZU30BURV4BRRW/
	VVAMyoVQd4hmzKuwqWjmU2IN95iLkoVl4UG/fYUwPmav0frf50GzM8aWrNgKxyOTRWxf
	zulzqukRZx8snAohpCl0z+96DP6x1EiA6pLb0=
Received: by 10.151.102.16 with SMTP id e16mr1218654ybm.188.1217510069133;
	Thu, 31 Jul 2008 06:14:29 -0700 (PDT)
Received: from klee.meeting.ietf.org ( [130.129.19.49])
	by mx.google.com with ESMTPS id k41sm4732058rnd.6.2008.07.31.06.14.03
	(version=TLSv1/SSLv3 cipher=RC4-MD5);
	Thu, 31 Jul 2008 06:14:21 -0700 (PDT)
From: Julien Laganier 
To: mext@ietf.org
Date: Thu, 31 Jul 2008 15:13:39 +0200
User-Agent: KMail/1.9.6
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <200807311513.39874.julien.IETF@laposte.net>
X-Mailman-Approved-At: Thu, 31 Jul 2008 06:14:26 -0700
Subject: [MEXT] Scope and applicability of Generic Signalling 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

Folks,

During the 2nd MEXT session, there were many attendees thinking that the 
Generic Signaling Framework scope and applicability are not well enough 
defined for the group to progress with that charter item.

Hereby we'd like to initiate a discussion on what shall the scope and 
applicability of the Generic Signalling Message be. Please send your 
opinions on that topic to the list.

-- julien & marcelo, MEXT chairs
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext


From mext-bounces@ietf.org  Thu Jul 31 06:30:04 2008
Return-Path: 
X-Original-To: nemo-archive@megatron.ietf.org
Delivered-To: ietfarch-nemo-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id A87223A6AA2;
	Thu, 31 Jul 2008 06:30:04 -0700 (PDT)
X-Original-To: mext@ietf.org
Delivered-To: mext@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0)
	id 2F39E3A698B; Thu, 31 Jul 2008 06:30:01 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20080731133002.2F39E3A698B@core3.amsl.com>
Date: Thu, 31 Jul 2008 06:30:02 -0700 (PDT)
Cc: mext@ietf.org
Subject: [MEXT] I-D Action:draft-ietf-mext-binding-revocation-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           : Binding Revocation for IPv6 Mobility
	Author(s)       : A. Muhanna, et al.
	Filename        : draft-ietf-mext-binding-revocation-00.txt
	Pages           : 32
	Date            : 2008-07-31

This document defines the revocation semantics for terminating a
mobile node's mobility session and associated resources.  These
semantics are generic enough and can be used by mobility entities in
the case of Client Mobile IPv6 and its extensions.  This mechanism
allows the mobility entity which initiates the revocation procedure
to request its corresponding one to terminate either one, multiple or
all specified binding cache entries.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-mext-binding-revocation-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2008-07-31061832.I-D@ietf.org>


--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
https://www.ietf.org/mailman/listinfo/mext

--NextPart--


From mext-bounces@ietf.org  Thu Jul 31 07:07:56 2008
Return-Path: 
X-Original-To: nemo-archive@megatron.ietf.org
Delivered-To: ietfarch-nemo-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id A4DEA3A696E;
	Thu, 31 Jul 2008 07:07:56 -0700 (PDT)
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 E9C103A696E
	for ; Thu, 31 Jul 2008 07:07:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.49
X-Spam-Level: 
X-Spam-Status: No, score=-6.49 tagged_above=-999 required=5 tests=[AWL=0.109, 
	BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 3E3TytD27R8q for ;
	Thu, 31 Jul 2008 07:07:51 -0700 (PDT)
Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57])
	by core3.amsl.com (Postfix) with ESMTP id B557F3A6924
	for ; Thu, 31 Jul 2008 07:07:50 -0700 (PDT)
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	m6VE7CY05574 for ; Thu, 31 Jul 2008 14:07:12 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 31 Jul 2008 09:06:57 -0500
Message-ID: 
In-Reply-To: <20080731133002.2F39E3A698B@core3.amsl.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D Action:draft-ietf-mext-binding-revocation-00.txt
Thread-Index: AcjzEc16q55pQvTfSjKx9KnnvSbldAAAynSg
References: <20080731133002.2F39E3A698B@core3.amsl.com>
From: "Ahmad Muhanna" 
To: 
Subject: Re: [MEXT] I-D Action:draft-ietf-mext-binding-revocation-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 Folks,

The content of this draft is the same as
draft-muhanna-mext-binding-revocation-02 with the following changes:

1. Clarified that the (A) bit MUST be set whenever the (G) bit is set.
2. a Minor clarification to make sure that the Binding Revocation use
the same security association that was used for exchanging the BU/BA
messages.

We appreciate your review and comments.

Regards,
Ahmad
 

> -----Original Message-----
> From: i-d-announce-bounces@ietf.org 
> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of 
> Internet-Drafts@ietf.org
> Sent: Thursday, July 31, 2008 2:30 PM
> To: i-d-announce@ietf.org
> Cc: mext@ietf.org
> Subject: I-D Action:draft-ietf-mext-binding-revocation-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           : Binding Revocation for IPv6 Mobility
> 	Author(s)       : A. Muhanna, et al.
> 	Filename        : draft-ietf-mext-binding-revocation-00.txt
> 	Pages           : 32
> 	Date            : 2008-07-31
> 
> This document defines the revocation semantics for 
> terminating a mobile node's mobility session and associated 
> resources.  These semantics are generic enough and can be 
> used by mobility entities in the case of Client Mobile IPv6 
> and its extensions.  This mechanism allows the mobility 
> entity which initiates the revocation procedure to request 
> its corresponding one to terminate either one, multiple or 
> all specified binding cache entries.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-re
vocation-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
> 
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext


From mext-bounces@ietf.org  Thu Jul 31 07:08:32 2008
Return-Path: 
X-Original-To: nemo-archive@megatron.ietf.org
Delivered-To: ietfarch-nemo-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 67CA93A6C1F;
	Thu, 31 Jul 2008 07:08:32 -0700 (PDT)
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 21B593A6C1F
	for ; Thu, 31 Jul 2008 07:08:28 -0700 (PDT)
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 mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id m-2f9j1RZ+8p for ;
	Thu, 31 Jul 2008 07:08:24 -0700 (PDT)
Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55])
	by core3.amsl.com (Postfix) with ESMTP id 208F73A6804
	for ; Thu, 31 Jul 2008 07:08:24 -0700 (PDT)
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	m6VE7M517137; Thu, 31 Jul 2008 14:07:22 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 31 Jul 2008 09:07:21 -0500
Message-ID: 
In-Reply-To: <200807311459.15169.julien.IETF@laposte.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [MEXT] Consensus call: Binding revocation will NOT use GSM
Thread-Index: AcjzDmzRQxYVmglqQwCSQfsdQPmMRAAB/PxA
From: "Mohamed Khalil" 
To: "Julien Laganier" , ,
	"marcelo bagnulo braun" 
Subject: Re: [MEXT] Consensus call: Binding revocation will NOT use GSM
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 am ok  that binding revocation will use directly the MH and allocates
its own MH types values.
-----Original Message-----
From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of
Julien Laganier
Sent: Thursday, July 31, 2008 7:59 AM
To: mext@ietf.org; marcelo bagnulo braun
Subject: [MEXT] Consensus call: Binding revocation will NOT use GSM


Folks,

During the 2nd MEXT session, there was consensus amongst the session 
attendees that Binding Revocation shall NOT use the GSM framework. 
Rather, the consensus was that binding revocation shall use directly 
the mobility header and allocates its own MH types values.

Hereby we'd like to confirm that room consensus on the mailing list. If 
you haven't expressed an opinion during the session, please send a note 
to the list stating whether you agree or disagree with that room 
consensus by 2008-08-14.

-- julien & marcelo, MEXT chairs



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