From rajeev_koodli@yahoo.com Tue Jun 2 10:05:01 2009 Return-Path: X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A2063A6C33 for ; Tue, 2 Jun 2009 10:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.403 X-Spam-Level: X-Spam-Status: No, score=-0.403 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nocZHXLGXxHR for ; Tue, 2 Jun 2009 10:05:00 -0700 (PDT) Received: from n55a.bullet.mail.sp1.yahoo.com (n55a.bullet.mail.sp1.yahoo.com [98.136.45.2]) by core3.amsl.com (Postfix) with SMTP id 73D533A67B7 for ; Tue, 2 Jun 2009 10:05:00 -0700 (PDT) Received: from [216.252.122.218] by n55.bullet.mail.sp1.yahoo.com with NNFMP; 02 Jun 2009 17:05:00 -0000 Received: from [67.195.9.81] by t3.bullet.sp1.yahoo.com with NNFMP; 02 Jun 2009 17:05:00 -0000 Received: from [67.195.9.104] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 02 Jun 2009 17:05:00 -0000 Received: from [127.0.0.1] by omp108.mail.gq1.yahoo.com with NNFMP; 02 Jun 2009 17:05:00 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 414879.23978.bm@omp108.mail.gq1.yahoo.com Received: (qmail 53880 invoked by uid 60001); 2 Jun 2009 17:05:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1243962300; bh=cXbge3+lcm9Hnf7zs4aiVwm+Ozz/9gB6WoVmKYx0GyM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=uECksd/2Kn4gk0z8aErm4rpzMO99HEtIjZxZoNdSvb0wmJV/bSvo3NR8ZLHBMLR45mE8EsJWZ/9lu5fAxYLfEIzNnMPsiNVp/R1lO5yMNmCR0N6KNUHaBGG5iXwg41G3mqZFwFERrfvjm6YUIBTwAZtrzrRcV6EOxtUQTGgfR8A= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=tB0hRgLj+ddfOa3w/O/12CN9RUkYql1nqDCnHh/ieFOgbKSfIQu5HkcjHUPosGES/Grvsk1KPQBEN/1iCGM9+fwalNtF1XAnVQDesDUnVBGZEAHZUc3IE++82vAhNhqI/W5BsG/f2VOW/OXMNAahXvMHVf0RvCPq3eaitqLXNb4=; Message-ID: <296070.52985.qm@web111413.mail.gq1.yahoo.com> X-YMail-OSG: kjm_0TAVM1mEjrFu8t_qNjosMNDUWs4oM8unmWFyHGsRWH8qmC5a0FHAdclWXoEC2s83Qjh07a7XSnR6rpN2EyiuQi27hYBahgpRhmc1PkAzymlzpqlBUL0k6OUTrmuPyx4om2752C5Vk.ApAp6vSdI9NqzmWMwlmFS.ukuPVg0HRfvZyQyxy2JI2rn7aD88dQ1IsfUKLcKlS6PNLUZl.bxvZXvw3N3fTNq7vY87ifhMZlkeRZ0gMDR0WnFYC2hx7KQYWQrVOaH3sp3OgrDaRjO87XqPBME9pcIpvpdmGQiJuNrucvD3DsdW6TkU4XYyU7J9vLEA8nsRgVvWAgpAbL4o.gG9IdBvuKEnS.2lePFLwg9o Received: from [71.141.252.72] by web111413.mail.gq1.yahoo.com via HTTP; Tue, 02 Jun 2009 10:05:00 PDT X-Mailer: YahooMailClassic/5.3.9 YahooMailWebService/0.7.289.10 Date: Tue, 2 Jun 2009 10:05:00 -0700 (PDT) From: Rajeev Koodli To: irsg@isi.edu MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1809627619-1243962300=:52985" Cc: mobopts@irtf.org Subject: [Mobopts] draft-irtf-mobopts-mmcastv6-ps X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 17:05:01 -0000 --0-1809627619-1243962300=:52985 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Dear IRSG, The Mobopts RG I-D:draft-irtf-mobopts-mmcastv6-ps=A0has completed IRSG review. =A0The revised version of the I-D (rev 07) which incorporates the comments is now available at: http://www.ietf.org/internet-drafts/draft-irtf-mobopts-mmcastv6-ps-07.txt. Craig Partridge who has performed the IRSG review; thanks Craig. The IRSG review is available from the IRTF tracker web page at: =A0http://trac.tools.ietf.org/group/irtf/trac/ticket/26 Please consider this email as the start of a two week IRSG=A0poll. The=A0de= adline for this poll is : June 16th, 2009. =A0Please use one of the poll responses defined below.=A0The possible poll = responses are: =A0=A0 =A0 o =A0'Ready to publish' -- requires a thorough read and reasonab= ly =A0=A0 =A0 =A0 =A0 detailed review =A0=A0 =A0o =A0'Not ready to publish' -- requires a thorough read,=A0reason= ably=A0detailed review, and actionable comments. =A0=A0 =A0 o =A0'No objection' -- I don't object if this document=A0=A0goes= forward; =A0=A0 =A0 =A0 =A0I've read the document (perhaps quickly); I have some sma= ll =A0=A0 =A0 =A0 =A0comments which are not show stoppers; I don't have great =A0=A0 =A0 =A0 expertise in the area. =A0=A0 =A0 o =A0'Request more time to review' -- a commitment to provide a =A0=A0 =A0 =A0 =A0 =A0 =A0thorough review in a specified period of time. The most relevant rule is that "At least two other IRSG members (besides the one sponsoring the document) need to vote 'ready to publish' for the document to move forward." Please review and submit your vote. Thanks, -Rajeev (Document shepherd) =0A=0A=0A --0-1809627619-1243962300=:52985 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

Dear IRSG,

The Mobopts= RG I-D:draft-irtf-mobopts-mmcastv6-ps=A0has completed IRSG
review.
<= br>
=A0The revised version of the I-D (rev 07) which incorpora= tes the
comments is now available at:

http://www.ietf.org/internet-drafts/draft-irtf-mobopts-mmcastv6-ps-07.txt.

=A0http://trac.tools.ietf= ..org/group/irtf/trac/ticket/26

Please consider this email a= s the start of a two week IRSG=A0poll. The=A0deadline for this poll is : Ju= ne 16th, 2009.

=A0Please use one of the poll responses defined below= ..
=A0The possible poll responses are:

=A0=A0 =A0 o =A0'Ready to publish' -- = requires a thorough read and reasonably
=A0=A0 =A0 =A0 =A0 detailed revi= ew

=A0=A0 =A0o =A0'Not ready to publish' -- requires a thoro= ugh read,=A0reasonably=A0detailed review, and actionable comments.

= =A0=A0 =A0 o =A0'No objection' -- I don't object if this document=A0=A0goes= forward;
=A0=A0 =A0 =A0 =A0I've read the document (perhaps quickly); I = have some small
=A0=A0 =A0 =A0 =A0comments which are not show stoppers; = I don't have great
=A0=A0 =A0 =A0 expertise in the area.
=A0=A0 =A0 o =A0'Request more time to review' -- a commitment to provide = a
=A0=A0 =A0 =A0 =A0 =A0 =A0thorough review in a specified period of tim= e.

The most relevant rule is that "At least two other IRSG members(besides the one sponsoring the document) need to vote 'ready to
publish' for the document to move forward."

Please review and submit your vote.

Thanks,

-Rajeev

(Document shepherd)

<= /td>

=0A=0A --0-1809627619-1243962300=:52985-- From jari.arkko@piuha.net Wed Jun 3 03:03:15 2009 Return-Path: X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0A8D28C10D for ; Wed, 3 Jun 2009 03:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.534 X-Spam-Level: X-Spam-Status: No, score=-1.534 tagged_above=-999 required=5 tests=[AWL=-0.334, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzwzO9TllSme for ; Wed, 3 Jun 2009 03:03:14 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 8E5BB3A6452 for ; Wed, 3 Jun 2009 03:03:13 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id F2A1919878F; Wed, 3 Jun 2009 13:03:13 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 3E66F198699; Wed, 3 Jun 2009 13:03:13 +0300 (EEST) Message-ID: <4A264A5E.3080506@piuha.net> Date: Wed, 03 Jun 2009 13:03:10 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: ml-mobopts , draft-irtf-mobopts-location-privacy-solutions@tools.ietf.org References: <4A26493D.7080608@piuha.net> In-Reply-To: <4A26493D.7080608@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [Mobopts] review of draft-irtf-mobopts-location-privacy-solutions X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 10:03:15 -0000 I recently read this draft, and wanted to post some comments and questions: The draft was well written and easy to read. It is about a very interesting topic, and something that I would like to see even more IRTF work on. Generally very interesting stuff, particularly about the solution that allows you to communicate with a peer without telling the peer what your home address is! For background information, the draft specifies two different solutions. The first solution uses a reverse tunneled binding update and obfuscated home address field to prevent outsiders on the mobile node's link from discovering the mobile node's home address, even if route optimization to the correspondent node is used. The first solution extends the definition of Routing Header Type 2 from RFC 3775 and allocates a new IPv6 destination option for a new type of a home address. The second solution specifies a new mechanism to allocate home addresses, and functionality in the home agent to translate payload packets from the use of the real home address to a newly allocated temporary home address. The solution introduces router-based inspection and modification of data packets. The draft allocates IPv6 destination option values, Mobility Options, and modifies the existing Routing Header Type 2 format. I can see a potential problem in the redefinition of Type 2 Routing Header. As you know, problems have been discovered in standardized routing headers long after their specification. I am concerned that the overloading of the Type 2 routing header used by RFC 3775 and the proposed experimental extension couples the fate of these two functions. That is, if a problem is discovered later in the draft, it may lead to networks filtering all Type 2 routing headers, and not just the ones using the extensibility bits. It would be more prudent to allocate a new value for this specification, or perhaps use one of the already defined experimental values from RFC 4727. Another problem is that as far as I can determine, the second solution introduces router-based packet inspection and an IPv6 NAT-like functionality. Or am I missing something? Even if so, I am uncertain, if the solution really needed this functionality. It might have been possible to use or extend the existing home address allocation mechanism, defined in RFC 4877 and make mobile node and upper layers aware of which temporary home address is being used.) Or maybe the issue is that the draft does not talk about how all this shows up for the mobile node vs. the correspondent node. If the mobile node believes it uses its home address when the correspondent node sees only a pseudoaddress, then you have essentially implemented an address translation, with some e2e effects visible to applications. If the mobile node is aware which address the other end sees, then that address can be chosen in address selection, and there is no e2e effects, just two invisible address changes along the path. Also, I wonder if it was necessary to define a new mechanism for home address allocation, when we already have one in RFC 4877. Perhaps it could be extended to request allocation from a "privacy prefix". I wish Section 4 had talked about applicability of the two methods. Does the second method provide support for home - foreign - home movements? It would seem that the answer is no. It should provide support for foreign-foreign movements, even though the spec is silent on this. Note that if it did provide foreign-foreign movements, while the real home address would be unknown, then by definition the correspondent node would have to know that that the mobile node in location A is the same node as the one that just moved to location B; the identity of the mobile node (as a concept) would be revealed. Secondly, if the spec provides no support for foreign-foreign or home-foreign-home movements, there's a slightly simpler design :-) just bypass all mobile IP processing and use a care-of address to communicate with the correspondent node. Some other observations: > Kpm = HMAC_SHA1 (Kbm, 0). If you are going to derive keys from Kbm, it would be a good idea to use a longer string than "0" -- there might be other keys derived in the future from Kbm. E.g., use "PRIVACY". > encrypted home address = Enc(Kpm, the home address) > > Where Enc(.) is a symmetric key encryption algorithm. AES is the > default encryption algorithm. Are there details missing? E.g., SHA1 produces 160 bits and AES takes 128 bits (or one of the versions takes 128 bits). Which version of AES is used? What mode? > 5.3.5. Receiving ICMP Error Message > > If such a message is received, > the mobile node MUST not attempt to use the location privacy solution > with the correspondent node. I suspect a SHOULD would be more useful here. > However, eavesdroppers on the HA-CN path can launch an attack to > compromise the return routability procedure anyway. This isn't entirely accurate. First some background. If you look at Mobile IPv6 without extensions defined in this specification, attackers on the HA-CN path will be able to block traffic, look at data packets, etc. However, this would be the case even if there was no Mobile IPv6 and there was a non-mobile host in the home network, trying to connect to the CN. And then back to this specification. What this specification does is re-use some aspects of the base specification for another purpose, namely employ some of the key material for confidential information. The key material isn't quite made for that, and therefore HA-CN path attackers will be able to see even the home addresses. But that too is kind of besides the point. I would rewrite the paragraph as follows: OLD With the solution in Section 5, the real home address is visible in the Binding Update and Binding Acknowledgment messages along the HA-CN path. However, eavesdroppers on the HA-CN path can launch an attack to compromise the return routability procedure anyway. Despite the limitations of the existing return routability mechanism, this solution meets all the requirements set forth for the location privacy solutions and provides a simple way to provide location privacy protection while allowing the use of the real home address with the correspondent node. NEW: With the solution in Section 5, the real home address is visible in the Binding Update and Binding Acknowledgment messages along the HA-CN path. Like Mobile IPv6 itself, it has not been designed to change the communications between the home network and the correspondent node; the same issues would affect non-mobile hosts as well. This solution meets all the requirements set forth for the location privacy solutions and provides a simple way to provide location privacy protection while allowing the use of the real home address with the correspondent node. > When receiving a Home Test Init message, the home agent performs the > operation as specified in Section 6.6.4. If this operation succeeds > when the Pseudo Home Address mobility option is present in the Home > Test Init message, the home agent generates a Home Test Init message > and forwards to the correspondent node. As shown in the following, > the pseudo home address carried in the Pseudo Home Address mobility > option is used as the source IP address in the forwarded Home Test > Init message. > > IPv6 header (source = pseudo home address, destination = > correspondent) > Mobility Header (HoTI) > Home Init Cookie This is an on-path modification of a packet not addressed to the party doing the modification. This is considered bad practice. It might even break things, such as any end-to-end security applied between the mobile node and correspondent node. Not to mention TCP checksums. Perhaps another approach would have been cleaner, such as an explicit message sent to the home agent (say, Home Test Init Delegate message). > 6. IP Address Location Privacy Solution Using the Pseudo Home Address There are standard mechanisms for registering a new home address (e.g., RFC 4877). The use of such mechanisms would have resulted in a much cleaner approach architecturally; additional options could have been specified for marking a home address request to be from a privacy address pool. As both the mobile node, home agent, and correspondent node would have been on the same page about the used address, there would not be any of the NAT-like effects this specification creates. And we wouldn't need additional mechanisms. > 6.3.1. Reverse Tunneling Mode > > The format of payload packets reverse-tunneled via the home agent is > the same as that specified for the home address test procedure in > Section 6.2.1. I am having trouble understanding this. First of all, the format in 6.2.1 was IP-tunneled packets with MH. Does the home agent do some conversions of home address=>pseudo home-address on the fly for each data packet? > 6.3.2. Route Optimization Mode > > When the route optimized correspondent binding update procedure is > performed, the format of payload packets exchanged between the mobile > node and the correspondent node is the same as specified in RFC 3775. > The operation of the mobile node when communicating with the > correspondent node via the route optimization mode is described in > Section 6.5.6. > > When the reverse tunneled correspondent binding update procedure is > performed, the format of payload packets exchanged between the mobile > node and the correspondent node is the same as specified in Section > 5, except that the encrypted pseudo home address SHOULD be included > in the Encrypted Home Address destination option and the Type 2 > routing header. I was confused by this. First of all, we are under "6.3 Payload packets", so why does it matter how the binding update procedure is done? Either your payload packets are route optimized or reverse tunneled, and 6.3.1 already dealt with the reverse tunneled mode. Secondly, this is the first time you are introducing EHoA option usage for your second solution. Is this a typo, and you meant the HoA? > 6.4. Prefix Discovery > > The solution to protect location privacy during the prefix discovery > procedure is similar to that used during the home binding update > procedure. What does prefix discovery have to do with your solution? > The Binding Update List entry is extended with a field, called Pseudo > Home Address. This field MAY be implemented as a pointer that points > to a corresponding entry in the Pseudo Home Address table. ... > For the > binding sent to a specific home agent, the Pseudo Home Address field > points to the first entry in the Pseudo Home Address table (or NULL > if the table is empty), so that the mobile node can access all the > pseudo home addresses registered at this home agent; Is the field for (a) *one* address or (b) a *list* of addresses, or (c) for an address *or* a value denoting no pseudo address is used? I think you actually want (c). > In addition, if the Return Routability procedure > is for a new session with the correspondent node, the mobile node > selects any pseudo home address from those already registered with > the home agent and stored in the Pseudo Home Address table; > otherwise, the mobile node must use the same pseudo home address as > used with the same correspondent node before. I think you mean the correct thing here, but the description may not be clearest for the reader. The route optimization mechanisms are actually not relevant here; once you exchange the first payload packet with the correspondent node via home agent or directly (when you are at home), you are committed to that address. This should be explained more clearly. Route optimization and all signaling simply must follow the commitment the node has taken earlier. How you know that such a commitment exists is another matter... > > > Encrypted Home Address (E) > > The Encrypted Home Address (E) bit is set to indicate that the > encrypted home address is carried in the routing header. > > Note that if the Type 2 routing > header with the 'E' set is present in a packet, the encrypted home > address therein MUST not be treated as the real destination IP > address by the receiver. I wonder what the tradeoffs are to do this as an extension of Type 2 routing header vs. a new routing header type? The latter text seems to indicate mandatory behaviour that existing Type 2 implementations obviously cannot follow. I realize that you should not get to this situation because you need signalling agreement before you can use the extended Type 2 header. However, I'm concerned that if we find a problem in the extension, this will affect negatively on what firewalls etc. do on Type 2. As a result, perhaps it would be better to use a new type? Or has this matter been analyzed in some manner during discussions in MobOpts? > advertently > deterministicly > procesing Typos Missing things: I suspect the specification should say something about how it interacts with other extensions of Mobile IPv6. At least RFC 4866, draft-ietf-mext-multiplecoa and maybe others. Jari From schmidt@informatik.haw-hamburg.de Sat Jun 13 15:10:32 2009 Return-Path: X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F5D93A6C29; Sat, 13 Jun 2009 15:10:32 -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 UCQ7-lhdN+v4; Sat, 13 Jun 2009 15:10:31 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 4BE553A6C0E; Sat, 13 Jun 2009 15:10:30 -0700 (PDT) Envelope-to: netlmm@ietf.org, mobopts@irtf.org Received: from e178155159.adsl.alicedsl.de ([85.178.155.159] helo=[192.168.178.23]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1MFbQs-000NFv-8b; Sun, 14 Jun 2009 00:10:38 +0200 Message-ID: <4A3423D6.2000805@informatik.haw-hamburg.de> Date: Sun, 14 Jun 2009 00:10:30 +0200 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: netlmm@ietf.org, "mobopts@irtf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: gorry@erg.abdn.ac.uk Subject: [Mobopts] A New Draft on Minimal Multicast Deployment in PMIPv6 Domains X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2009 22:10:32 -0000 Dear all, multicast support for PMIPv6 domains has been desired and debated by a number of folks, and at the same time some divergent understanding of the topic arose, the extremes being: * PMIPv6 cannot work with multicast * PMIPv6 inherently supports multicast by itself We believe, both is not true. To clarify the issue, we have prepared a document defining multicast listener support in PMIPv6 domains solely on the basis of standardized IETF protocols (see below): http://www.ietf.org/internet-drafts/draft-schmidt-multimob-pmipv6-mcast-deployment-00.txt It assigns the role of MLD proxies to MAGs and standard MLD queriers to LMAs, and we believe this is the minimal solution solely based on standard protocol behavior. At the price of multicast functions at MAG and LMA, this approach provides some (but not all possible) traffic aggregations. As may be known, there are attempts to initiate a working group "Multimob" to work on multicast extensions for mobility protocols. Thereof, PMIPv6 plays a major role. In writing this announcement, I would very much like to stimulate the involvement and exchange of PMIP mobility people with the multicast and mip guys already present at the subject. Looking forward to your comments! Thomas ---------------------------- snip ---------------------------------- A new version of I-D, draft-schmidt-multimob-pmipv6-mcast-deployment-00.txt has been successfuly submitted by Thomas Schmidt and posted to the IETF repository. Filename: draft-schmidt-multimob-pmipv6-mcast-deployment Revision: 00 Title: A Minimal Deployment Option for Multicast Listeners in PMIPv6 Domains Creation_date: 2009-06-13 WG ID: Independent Submission Number_of_pages: 10 Abstract: This document describes deployment options for activating multicast listener functions in Proxy Mobile IPv6 domains without modifying mobility and multicast protocol standards. Similar to Home Agents in Mobile IPv6, PMIPv6 Local Mobility Anchors serve as multicast subscription anchor points, while Mobile Access Gateways provide MLD proxy functions. In this scenario, Mobile Nodes remain agnostic of multicast mobility operations. -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From j.schoenwaelder@jacobs-university.de Wed Jun 17 05:44:58 2009 Return-Path: X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE98A28C255 for ; Wed, 17 Jun 2009 05:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[AWL=-0.380, BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kR+4GaMz95QJ for ; Wed, 17 Jun 2009 05:44:53 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D721C28C24F for ; Wed, 17 Jun 2009 05:44:52 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 788D0C0030; Wed, 17 Jun 2009 14:44:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 3z8bAvY7h8Cx; Wed, 17 Jun 2009 14:44:41 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 77873C0029; Wed, 17 Jun 2009 14:44:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7ABCBB45AEF; Wed, 17 Jun 2009 14:44:40 +0200 (CEST) Date: Wed, 17 Jun 2009 14:44:40 +0200 From: Juergen Schoenwaelder To: Rajeev Koodli Message-ID: <20090617124440.GB9754@elstar.local> Mail-Followup-To: Rajeev Koodli , "irsg@ISI.EDU" , "mobopts@irtf.org" References: <296070.52985.qm@web111413.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <296070.52985.qm@web111413.mail.gq1.yahoo.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "irsg@ISI.EDU" , "mobopts@irtf.org" Subject: Re: [Mobopts] [IRSG] draft-irtf-mobopts-mmcastv6-ps X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 12:44:59 -0000 > The Mobopts RG I-D:draft-irtf-mobopts-mmcastv6-ps has completed IRSG > review. [...] > Please consider this email as the start of a two week IRSG poll. The > deadline for this poll is : June 16th, 2009. > > Please use one of the poll responses defined below. I have 'no objection' - the document seems to be fairly well written and provides a pretty detailed overview over the issues. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From rajeev_koodli@yahoo.com Wed Jun 17 07:53:10 2009 Return-Path: X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A728D28C0E2 for ; Wed, 17 Jun 2009 07:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.934 X-Spam-Level: X-Spam-Status: No, score=-0.934 tagged_above=-999 required=5 tests=[AWL=0.531, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWZAEcbOa3gY for ; Wed, 17 Jun 2009 07:53:09 -0700 (PDT) Received: from web111414.mail.gq1.yahoo.com (web111414.mail.gq1.yahoo.com [67.195.15.210]) by core3.amsl.com (Postfix) with SMTP id B69543A6A7A for ; Wed, 17 Jun 2009 07:53:09 -0700 (PDT) Received: (qmail 25686 invoked by uid 60001); 17 Jun 2009 14:52:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1245250365; bh=xlpoOA59bMK1V8+G49uiXvdOlCl++g1auG3Q/35vMuo=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=yDuZQ8rPLNFOgAfqXb9H9aH/2val6TnFKGtih+qW5j1XGL6+hg0HrREsNmUb8lMAJwYMNePk+C/hXTtoHp3WharQpKKaK3qjlpadAWeTMNd0qQHekHHgO9dNoMV/QS31Adbg8zF1WBuDzDMtrEZdkaPBe+ZU+1OsaCEeWqQ8RkI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=Q7dm1OEn5RToByF5DSm0xFDxBGGtlfLUTwUvPCab7R6ng2mbxIRPFVkamehDSjjXikLRPQlU6YvTwePHjcJmLccM4hNuHxQEpZSYeQjsknPUz+Wvvj1T9yLGa0nDUIt90qv6KNvM4IypWTVHkPpw6C5jSJbnKprdxUPkY02MdB8=; Message-ID: <839650.25665.qm@web111414.mail.gq1.yahoo.com> X-YMail-OSG: 3uh2_3wVM1nsdaLWgj8c0XGyM4PtTzgJ4g1921Gq02MlizfL18FdYoV2lWgZRbiUvaeORksaXAUbMem7KMkyKGosERjsunR99A8TLDIkOM0TF3NOoiQgRPGwIbtTpHOTA82Fi.F9J3Y8yjPJgtQDg6OZRZQ1On3P01i3xOXMujc7U6Sx8upoVWY.0HZ_mVqRb8HiFnnjWdtJMPiS57FSR3fQHaPOOUZQlrxJZA41HhQ1PHU09LknwyeGMFCeX_mGFli6VTGVyLSJt10e34XQxZmsS99AVGVTlklvs6Fy8WqWLeLaRS2fErAh31UyjZlFh.s7gEzyhwodzBZ.LAk84A-- Received: from [71.141.229.98] by web111414.mail.gq1.yahoo.com via HTTP; Wed, 17 Jun 2009 07:52:45 PDT X-Mailer: YahooMailClassic/5.4.12 YahooMailWebService/0.7.289.15 Date: Wed, 17 Jun 2009 07:52:45 -0700 (PDT) From: Rajeev Koodli To: Juergen Schoenwaelder MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2073466951-1245250365=:25665" Cc: "irsg@ISI.EDU" , "mobopts@irtf.org" Subject: Re: [Mobopts] [IRSG] draft-irtf-mobopts-mmcastv6-ps X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 14:53:10 -0000 --0-2073466951-1245250365=:25665 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Juergen. We have Craig with 'Ready to Publish'. We do need more votes.=A0 Could folks please respond? Thanks, -Rajeev --- On Wed, 6/17/09, Juergen Schoenwaelder wrote: From: Juergen Schoenwaelder Subject: Re: [IRSG] draft-irtf-mobopts-mmcastv6-ps To: "Rajeev Koodli" Cc: "irsg@ISI.EDU" , "mobopts@irtf.org" Date: Wednesday, June 17, 2009, 5:44 AM > The Mobopts RG I-D:draft-irtf-mobopts-mmcastv6-ps has completed IRSG > review. [...] =20 > Please consider this email as the start of a two week IRSG poll. The > deadline for this poll is : June 16th, 2009. >=20 >=A0 Please use one of the poll responses defined below. I have 'no objection' - the document seems to be fairly well written and provides a pretty detailed overview over the issues. /js --=20 Juergen Schoenwaelder=A0 =A0 =A0 =A0 =A0=A0=A0Jacobs University Bremen gGmb= H Phone: +49 421 200 3587=A0 =A0 =A0 =A0=A0=A0Campus Ring 1, 28759 Bremen, Ge= rmany Fax:=A0=A0=A0+49 421 200 3103=A0 =A0 =A0 =A0=A0=A0 =0A=0A=0A --0-2073466951-1245250365=:25665 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

Thanks Juergen.

=
We have Craig with 'Ready to Publish'. We do need more votes.=A0
=

Could folks please respond?

Th= anks,

-Rajeev


--- On Wed, 6/1= 7/09, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

From: Juergen Schoenwaelder &l= t;j.schoenwaelder@jacobs-university.de>
Subject: Re: [IRSG] draft-irtf-m= obopts-mmcastv6-ps
To: "Rajeev Koodli" <rajeev_koodli@yahoo.com>
C= c: "irsg@ISI.EDU" <irsg@ISI.EDU>, "mobopts@irtf.org" <mobopts@irtf.or= g>
Date: Wednesday, June 17, 2009, 5:44 AM

> The Mobopts RG I-D:draft-irtf-mobopts-mmcastv6-ps has completed IRSG> review.

[...]

> Please consider this email as the start of = a two week IRSG poll. The
> deadline for this poll is : June 16th, 2009.=
>
>=A0 Please use one of the poll responses defined below.

I= have 'no objection' - the document seems to be fairly well written
and = provides a pretty detailed overview over the issues.

/js

-- <= br>Juergen Schoenwaelder=A0 =A0 =A0 =A0 =A0=A0=A0Jacobs University Bremen g= GmbH
Phone: +49 421 200 3587=A0 =A0 =A0 =A0=A0=A0Campus Ring 1, 28759 Br= emen, Germany
Fax:=A0=A0=A0+49 421 200 3103=A0 =A0 =A0 =A0=A0=A0<http://www.jacob= s-university.de/>

=0A= =0A --0-2073466951-1245250365=:25665-- From dhoang@it.uts.edu.au Sun Jun 28 15:29:58 2009 Return-Path: X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 108113A6AC2 for ; Sun, 28 Jun 2009 15:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.788 X-Spam-Level: * X-Spam-Status: No, score=1.788 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVgdMY3TakHJ for ; Sun, 28 Jun 2009 15:29:56 -0700 (PDT) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by core3.amsl.com (Postfix) with ESMTP id 943003A6941 for ; Sun, 28 Jun 2009 15:29:56 -0700 (PDT) Received: from [192.168.0.127] (c122-106-197-247.belrs3.nsw.optusnet.com.au [122.106.197.247]) (authenticated sender dhoang1) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n5SMU747018864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 29 Jun 2009 08:30:09 +1000 Message-ID: <4A47EEF0.60305@it.uts.edu.au> Date: Mon, 29 Jun 2009 08:30:08 +1000 From: Doan Hoang User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: mobopts@irtf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Mobopts] IEEE HEALTHCOM deadline in 5 days - please be advised X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 22:29:58 -0000 Healthcom 2009 (IEEE sponsored) - Deadline extended Please be informed that the deadline for Healthcom 2009 has been extended to 3 July, 2009. Please pass on this message to your colleagues whose research interests are in e-Health and Information and Communication Technology. 11th International Conference on e-Health networking, Applications & Services. http://www.healthcom2009.org Sydney, Australia December 16-18, 2009 Doan Hoang & Maralyn Foureur TPC Chairs -- Doan B. Hoang, PhD Professor of Computer Networks Director, iNEXT - Centre for Innovation in IT Services and Applications Faculty of Engineering and Information Technology Phone:(+61 2) 9514 7943 University of Technology, Sydney Fax:(+61 2) 9514 1807 NSW 2007, AUSTRALIA Email: Doan.Hoang@uts.edu.au http://www.inext.uts.edu.au http://www.research.uts.edu.au/strengths/inext/overview.html