Mobile IPv6 Location Privacy Solutions
RFC 5726
Approval announcement
Draft of message to be sent after approval:
From: The IESG <iesg-secretary@ietf.org>
To: RFC Editor <rfc-editor@rfc-editor.org>
Cc: The IESG <iesg@ietf.org>, <iana@iana.org>, ietf-announce@ietf.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.