Extension to Sockets API for Mobile IPv6
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: Internet Architecture Board <email@example.com>, RFC Editor <firstname.lastname@example.org>, mip6 mailing list <email@example.com>, mip6 chair <firstname.lastname@example.org> Subject: Document Action: 'Extension to Sockets API for Mobile IPv6' to Informational RFC The IESG has approved the following document: - 'Extension to Sockets API for Mobile IPv6 ' <draft-ietf-mip6-mipext-advapi-08.txt> as an Informational RFC This document is the product of the Mobility for IPv6 Working Group. The IESG contact persons are Margaret Wasserman and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-mipext-advapi-08.txt
Technical Summary This document describes data structures and API support for Mobile IPv6 as an extension to Advanced Socket API for IPv6. Mobility Support in IPv6 introduces mobility protocol header for IPv6. It is expected that future Mobile IPv6 applications and implementations may need to access Mobility binding messages and Return Routability messages for diagnostic, packet accounting and local policy setting purposes. In order to provide portability for Mobile IP applications that use sockets under IPv6, standardization is needed for the Mobile IPv6 specific APIs. This document provides mechanism for API access to retrieve and set information for Mobility Header messages, Home Address destination options and type 2 Routing header extension headers. It discusses the common data structures and definitions that might be used by advanced Mobile IPv6 socket applications. Working Group Summary This document is a work item of the MIP6 WG. Protocol Quality This document was updated based on AD review comments from Thomas Narten. This document was reviewed for the IESG by Margaret Wasserman. RFC Editor Note OLD: 4. Common Structures and Definitions In this section, the structures are specified in a way so that they maximize the probability that the compiler-layout of data structures are identical to the packet formats on the wire. However, ANSI-C provides few guarantees about the size and alignment of data structures. Thus, depending on the implementation of a compiler, there is a slim chance that in certain systems, the compiled layout of the following data structures may not match the packet formats defined in RFC 3775 . The structure definitions below are examples of contents or the fields that match with the wired packet format in most Operating Systems. Depending on the compiler used as well as the host byte order, the layout of the structures might need to be different in some cases. But as long as they provide the same fields as below we can ensure application portability when using this API. The constants and structures shown below are in network byte order, so an application needs to perform the appropriate byte order conversion (ntohs(), etc) when necessary. NEW: 4. Common Structures and Definitions In this section, the structures are specified in a way so that they maximize the probability that the compiler-layout of data structures are identical to the packet formats on the wire. However, ANSI-C provides few guarantees about the size and alignment of data structures. The assumption is that the Advanced Socket API  will pass up the actual packet content (the wire format) in the buffer and in the ancillary data objects. Thus if an implementor has to handle a system where the ANSI-C compiler does not and can not lay out these structures to match the wire formats in RFC 3775 , the structures defined by this API can not be supported on such a system. The constants and structures shown below are in network byte order, so an application needs to perform the appropriate byte order conversion (ntohs(), etc) when necessary.