Mobile IPv6 Location Privacy Solutions
RFC 5726

Approval announcement
Draft of message to be sent after approval:

Announcement

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

Ballot Text

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.

RFC Editor Note