Skip to main content

Extension to Sockets API for Mobile IPv6
draft-ietf-mip6-mipext-advapi-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>, 
    mip6 mailing list <mip6@ietf.org>, 
    mip6 chair <mip6-chairs@tools.ietf.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

Ballot Text

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 [2].

    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 [1] 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 [2], 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.

RFC Editor Note