Skip to main content

IPv6 Socket API for Source Address Selection
draft-chakrabarti-ipv6-addrselect-api-07

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>
Subject: Document Action: 'IPv6 Socket API for Source Address 
         Selection' to Informational RFC 

The IESG has approved the following document:

- 'IPv6 Socket API for Source Address Selection '
   <draft-chakrabarti-ipv6-addrselect-api-08.txt> as an Informational RFC

This document has been reviewed in the IETF but is not the product of an
IETF Working Group. 

The IESG contact person is Jari Arkko.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chakrabarti-ipv6-addrselect-api-08.txt

Ballot Text

Technical Summary

  The IPv6 default address selection document [RFC3484] describes the
  rules for selecting source and destination IPv6 addresses, and 
  indicates that applications should be able to reverse the sense of 
  some of the address selection rules through some unspecified API. 
  However, no such socket API exists in the basic [RFC3493] or advanced 
  [RFC3542] IPv6 socket API documents. This document fills that gap by
  specifying new socket level options and flags for the getaddrinfo()
  API to specify preferences for address selection that modify the
  default address selection algorithm.  The socket API described in
  this document will be particularly useful for IPv6 applications 
  that want to choose between temporary and public addresses, and 
  for Mobile IPv6 aware applications that want to use the care-of
  address for communication.

Working Group Summary

  This document is not the product of an IETF working group. It has 
  however been discussed on the IPv6 working group mailing list by key
  members of the community. There were some controversy about the design 
  of the name to address function (getaddrinfo) extensions, but consensus
  has been that the extension maintains source compatibility, and binary 
  compatibility except in rare use cases.

Document Quality

  A couple of vendors have expressed their interest in implementing the
  specification. Jun-ichiro Hagino did a thorough review of the document 
  that resulted in the current design of the name to address function 
  (getaddrinfo) extensions. Geoff Huston from IP Directorate has reviewed
  the specification. 

Personnel

  Julien Laganier is the Document Shepherd for this document.
  Jari Arkko is the Responsible Area Director.

Note to RFC Editor
 
  Please change "structre" to "structure" in Section 7.

  Please change the first sentence in the Security Considerations
  section as follows:

  OLD:
  This document conforms to the same security implications as specified
  in the Basic IPv6 socket API [RFC3493].
  NEW:
  This document conforms to the same security implications as specified
  in the Basic IPv6 socket API [RFC3493] and address selection rules
  [RFC3484].

RFC Editor Note