Re: [Pana] Switching to direct communication [was Re: PANA relay draft]
"Alper Yegin" <alper.yegin@yegin.org> Wed, 01 December 2010 14:24 UTC
Return-Path: <alper.yegin@yegin.org>
X-Original-To: pana@core3.amsl.com
Delivered-To: pana@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A91A13A6B48 for <pana@core3.amsl.com>; Wed, 1 Dec 2010 06:24:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.741
X-Spam-Level:
X-Spam-Status: No, score=-100.741 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, 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 WS4dZWmbGLbI for <pana@core3.amsl.com>; Wed, 1 Dec 2010 06:24:57 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 303CC3A6C54 for <pana@ietf.org>; Wed, 1 Dec 2010 06:24:57 -0800 (PST)
Received: from ibm (dsl.static.85-105-43069.ttnet.net.tr [85.105.168.61]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MU0hV-1OxdtV2ML3-00Qt7S; Wed, 01 Dec 2010 09:26:09 -0500
From: Alper Yegin <alper.yegin@yegin.org>
To: robert.cragie@gridmerge.com
References: <317A507F-239C-4AAD-B88F-2D5744E7D5F2@gmail.com> <F75BDF80-67C2-4008-8DC1-6EA8E1C00088@um.es> <4CE6E4B1.1080007@toshiba.co.jp> <934C8E59-C49E-4D96-A311-FB48B3DACD78@um.es> <00d601cb8bd3$c1909730$44b1c590$%yegin@yegin.org> <4CEEF0EA.3000707@toshiba.co.jp> <028c01cb8d3a$98967d50$c9c377f0$%yegin@yegin.org> <789D8FFB-6375-4433-AD79-927B0FB7970F@um.es> <00b901cb8fbe$79dee4c0$6d9cae40$%yegin@yegin.org> <4CF458C6.20803@toshiba.co.jp> <000001cb90d4$77ed0680$67c71380$@yegin@yegin.org> <4CF652AF.4080500@gridmerge.com>
In-Reply-To: <4CF652AF.4080500@gridmerge.com>
Date: Wed, 01 Dec 2010 16:25:51 +0200
Message-ID: <014d01cb9163$b017f120$1047d360$@yegin>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_014E_01CB9174.73A0C120"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcuRXsSCeJ57fIKoQEKEp6UenTkXcQABNTfw
Content-Language: en-us
X-Provags-ID: V02:K0:ebN8JGeQWfBOZ4euazB+2r7pFd2RomCJ1ZJgSOwo1s3 /qc//AdTue0oG33J+yCoAH1d8l/l7/0KBCjCbWOURAAhScz65m DFRriJ71LDlkxQYT/AZ8ykkxDtgq6MnJ+BPvtkQBobJD+uReA1 LeMj43N0DQSDHSmR6GTdqnIesxpHS/ehqZurlYteB8zq9LkSax id7pO/bYS2zWsmk/S5dXiR4PF1dkT21MOMDzgEJ7KU=
Cc: pana@ietf.org, 'Ralph Droms' <rdroms.ietf@gmail.com>
Subject: Re: [Pana] Switching to direct communication [was Re: PANA relay draft]
X-BeenThere: pana@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Protocol for carrying Authentication for Network Access <pana.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pana>, <mailto:pana-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pana>
List-Post: <mailto:pana@ietf.org>
List-Help: <mailto:pana-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pana>, <mailto:pana-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Dec 2010 14:24:59 -0000
I think this text is fine. From: Robert Cragie [mailto:robert.cragie@gridmerge.com] Sent: Wednesday, December 01, 2010 3:51 PM To: Alper Yegin Cc: 'Yoshihiro Ohba'; 'Rafa Marin Lopez'; pana@ietf.org; 'Ralph Droms'; 'Samita Chakrabarti'; 'Paul Duffy (paduffy)' Subject: Re: Switching to direct communication [was Re: PANA relay draft] Maybe I'm missing something but switching to direct communication has nothing to do with a *change* in the PAA address. I would suggest the following: "If direct IP routing becomes available[1] and the PaC is notified about the PAA's[2] IP address using an out-of-band mechanism that is not specified in this document, the PaC may choose to directly communicate with the PAA without use of the relay operation. The PaC[3] IP address update procedure defined in [RFC5191] may additionally[4] be performed to switch to non-relay operation, using the directly reachable IP address of the PAA." [1] Removed ZigBee IP reference [2] "the change of PAA's" -> "the PAA's" [3] Added PaC as per Alper's suggestion [4] Added "additionally" as this is independent from getting the PAA address Comments? Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com <http://www.gridmerge.com/> On 30/11/2010 9:20 PM, Alper Yegin wrote: Looks good to me. One minor update: "The IP address update procedure" --> "PaC IP address update procedure" Alper -----Original Message----- From: Yoshihiro Ohba [mailto:yoshihiro.ohba@toshiba.co.jp] Sent: Tuesday, November 30, 2010 3:52 AM To: Alper Yegin Cc: 'Rafa Marin Lopez'; pana@ietf.org; 'Ralph Droms'; robert.cragie@gridmerge.com; 'Samita Chakrabarti'; 'Paul Duffy (paduffy)' Subject: Re: Switching to direct communication [was Re: PANA relay draft] OK. How about the following change? Current text: "If direct IP routing becomes available (e.g., after the successful PANA authentication as in the case of Zigbee IP), the PaC may choose to directly communicate with the PAA without use of the relay operation. The IP address update procedure defined in [RFC5191] may be performed to switch to non-relay operation." Propose text: "If direct IP routing becomes available (e.g., after the successful PANA authentication as in the case of Zigbee IP) and the PaC is notified about the change of PAA's IP address using an out-of-band mechanism that is not specified in this document, the PaC may choose to directly communicate with the PAA without use of the relay operation. The IP address update procedure defined in [RFC5191] may be performed to switch to non-relay operation, using the directly reachable IP address of the PAA." Yoshihiro Ohba (2010/11/29 21:10), Alper Yegin wrote: Rafa, El 26/11/2010, a las 08:21, Alper Yegin escribió: Let me create a new thread on this specific topic. It has been identified that switching from relay to direct communication requires not only change of PaC's address but also change of PAA's address. But RFC 5191 supports change of PaC's address for a given PANA session but does not support change of PAA's address. Yes, RFC 5191 has an explicit support for that. So it seems that switching to direct communication requires to go through a full PANA authentication. I don't think that's necessary at all. If the PaC learns another (or new) IP address of the PAA by some out- of scope mechanism, then it can start using that IP address. And that's the case in Zigbee. [Rafa] What I believed is that a new PANA authentication was necessary when you switch the PAA's interface, as Yoshi has mentioned. It does not mean that it is the best option of course, but what happens is that there is no support for PAA's address change. I believe this scenario was not considered in RFC 5191. We didn't envision this scenario. Hence RFC 5191 is "silent" about it. In other words, there is no explicit facility to realize that (PAA IP address change), and there is no prohibition against it either. Which means, if some implementation/SDO/deployment can figure out a way to enable that w/o breaking the RFC, it's OK. And that's the case with this Zigbee Alliance usage. In the same way that "In order to maintain the PANA session, the PAA needs to be notified about the change of PaC address.", I would expect a mechanism saying that: "In order to maintain the PANA session, the PaC needs to be notified about the change of PAA address." We can say something to that affect in the relay I-D. Alper Alper So if we mention "direct IP routing MAY be available" then we may also need to mention that "switching to direct communication requires a full PANA authentication using the new PaC's and PAA's addresses." What do you think? Yoshihiro Ohba (2010/11/24 21:32), Alper Yegin wrote: [Rafa] In my opinion, after the successful PAA authentication, I believe that it would be better that PaC does not require the PRE anymore. In other words, the PaC and the PAA know each other. Moreover I assume that after the successful PAA authentication the PaC will be able to contact directly the PAA without the assistance of the PRE. If these assumptions are reasonable, there will not be PAA-initated messages that go through the PRE. I think this spec shall not mandate or prohibit use of PRE after the first successful PANA auth. Spec shall allow both, and the consumers (deployments, architectures) shall decide. If direct IP routing becomes available (e.g., after the successful PANA authentication as in the case of Zigbee IP), [Rafa]. Is the PRE informed by the PAA?. If it is, how?. In other words, how is this enabled after a successful PANA authentication? The PRE is not informed by the PAA when direct IP routing becomes available. [Rafa] I mean that it is mentioned that direct IP routing is available , how is this enabled after a successful PANA authentication? is the PaC enabled to use a non link-local IPv6 address?. I think the spec shall say "direct IP routing MAY be available". In the specific case of zigbee, PaC receives RA and configures a global IPv6 address. Such details belong to zigbee spec. On the other hand, what entity is acting as EP?. An EP may reside in the PRE, or it could be a separate entity from the PRE. the PaC may choose to directly communicate with the PAA without use of the relay operation. [Rafa] However, it has been said that PaC that "From the PaC's perspective, the PRE appears as the PAA." This sentences seems to mean that PaC knows that it is talking with a relay first. The PaC may not know that it is talking with a relay first. OTOH, the PaC may know, after successful PANA authentication, that it was talking with a relay, by using some out-of-band mechanism. But this does not mean that switching to direct communication is needed. The point here is that we try to describe possible cases as much as possible. The IP address update procedure defined in [RFC5191] may be performed to switch to non-relay operation. [Rafa] Who is sending this notification? The notification is generated locally by the node that has updated an IP address. [Rafa] What is that node? the PAA? the PaC? both?. I mean to switch to non-relay operation, under PaC point of view the PAA is switching the IP address (PaC thought the PAA was the PRE but now it is the real PAA) That's right. Both PaC's and PAA's IP address are changing for the given PANA session. ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es -------------------------------------------------------
- [Pana] PANA relay draft Ralph Droms
- Re: [Pana] PANA relay draft Rafa Marin Lopez
- Re: [Pana] PANA relay draft Yoshihiro Ohba
- Re: [Pana] PANA relay draft Rafa Marin Lopez
- Re: [Pana] PANA relay draft Alper Yegin
- [Pana] Switching to direct communication [was Re:… Yoshihiro Ohba
- Re: [Pana] Switching to direct communication [was… Alper Yegin
- Re: [Pana] PANA relay draft Rafa Marin Lopez
- Re: [Pana] Switching to direct communication [was… Rafa Marin Lopez
- Re: [Pana] PANA relay draft Alper Yegin
- Re: [Pana] Switching to direct communication [was… Alper Yegin
- Re: [Pana] Switching to direct communication [was… Yoshihiro Ohba
- [Pana] Channel binding [ was Re: PANA relay draft] Yoshihiro Ohba
- Re: [Pana] Switching to direct communication [was… Alper Yegin
- Re: [Pana] Channel binding [ was Re: PANA relay d… Alper Yegin
- Re: [Pana] Channel binding [ was Re: PANA relay d… Yoshihiro Ohba
- Re: [Pana] Channel binding [ was Re: PANA relay d… Alper Yegin
- Re: [Pana] Switching to direct communication [was… Alper Yegin
- Re: [Pana] Switching to direct communication [was… Rafa Marin Lopez
- Re: [Pana] Channel binding [ was Re: PANA relay d… Rafa Marin Lopez
- Re: [Pana] Switching to direct communication [was… Yoshihiro Ohba
- Re: [Pana] Switching to direct communication [was… Rafa Marin Lopez