Mobile IPv6 Location Privacy Solutions
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: RFC Editor <email@example.com> Cc: The IESG <firstname.lastname@example.org>, <email@example.com>, firstname.lastname@example.org Subject: Re: Experimental RFC to be: draft-irtf-mobopts-location-privacy-solutions-16.txt The IESG has no problem with the publication of 'Mobile IPv6 Location Privacy Solutions' <draft-irtf-mobopts-location-privacy-solutions-16.txt> as an Experimental RFC. The IESG would also like the IRSG or RFC-Editor to review the comments in the datatracker (https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14376&rfc_flag=0) related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the comment log. The IESG contact person is Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-irtf-mobopts-location-privacy-solutions-16.txt The process for such documents is described at http://www.rfc-editor.org/indsubs.html. Thank you, The IESG Secretary
Technical Summary This document defines two location privacy schemes for Mobile IPv6. Working Group Summary This is a product of the MOBOPTS RG at the IRTF. Document Quality No technical review has been performed. Personnel The document shepherd is Basavaraj Patil, and the responsible AD is Jari Arkko. RFC Editor Note RFC 3932 Section 3 response 2 applies: The IESG thinks that this work is related to IETF work done in the MEXT WG, but this does not prevent publishing. The IESG generally welcomes research work in the mobility space, and would like to see IRTF documents published on location privacy. The IESG notes that code points already allocated for this type of experimental specifications in RFCs 4727 and 5096 are used in the draft. Given this, the IESG has no problem with the publication of this specification. Once more experience of these extensions is gained or new designs are developed, permanent IANA allocations could be considered. 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 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, including address translation.