[MEXT] "[mext] #8: Application using the care-of address " <julien.IETF at laposte.net>

["mext" <trac at tools.ietf.org>]

Ticket #8: Application using the care-of address  <julien.IETF at laposte.net>

 RFC3775 mentions two times the possibility to use the
 care-of address as a source address in outgoing packets. In the first
 occurence, RFC3775 says that APIs to control this use are out-of-scope,
 but since an API that allows an application to require the care-of
 address to be used in outgoing packets has been specified since then in
 RFC5014, RFC3775bis could mention RFC5014 as an example of such an API.
 In the second occurence, RFC3775 says that a multicast application
 could use the care-of address as a source address in outgoing packets
 if it know the care-of address, but since RFC5014 allows to use the
 care-of address as a source address without requiring the application
 to knows the address itself that should be corrected in RFC3775bis. See
 below the two slight modifications, plus the additional informative
 reference.

 Please let me know what you think.

 Thanks,

 --julien

 -------------------------------------------------------------------------

 OLD:

    o  The mobile node MAY choose to directly use one of its care-of
       addresses as the source of the packet, not requiring the use of a
       Home Address option in the packet.  This is particularly useful
       for short-term communication that may easily be retried if it
       fails.  Using the mobile node's care-of address as the source for
       such queries will generally have a lower overhead than using the
       mobile node's home address, since no extra options need be used in
       either the query or its reply.  Such packets can be routed
       normally, directly between their source and destination without
       relying on Mobile IPv6.  If application running on the mobile node
       has no particular knowledge that the communication being sent fits
       within this general type of communication, however, the mobile
       node should not use its care-of address as the source of the
       packet in this way.

       The choice of the most efficient communications method is
       application specific, and outside the scope of this specification.
       The APIs necessary for controlling the choice are also out of
       scope.

 NEW:

    o  The mobile node MAY choose to directly use one of its care-of
       addresses as the source of the packet, not requiring the use of a
       Home Address option in the packet.  This is particularly useful
       for short-term communication that may easily be retried if it
       fails.  Using the mobile node's care-of address as the source for
       such queries will generally have a lower overhead than using the
       mobile node's home address, since no extra options need be used in
       either the query or its reply.  Such packets can be routed
       normally, directly between their source and destination without
       relying on Mobile IPv6.  If application running on the mobile node
       has no particular knowledge that the communication being sent fits
       within this general type of communication, however, the mobile
       node should not use its care-of address as the source of the
       packet in this way.

       The choice of the most efficient communications method is
       application specific, and outside the scope of this specification.
       The APIs necessary for controlling the choice are also out of
 |     scope. One example of such an API is described in the IPv6 Socket
 |     API for Source Address Selection specification [RFC5014].

 --------------------------------------------------------------------------

 OLD:

    A mobile node that wishes to send packets to a multicast group also
    has two options:

    1.  Send directly on the foreign link being visited.

        The application is aware of the care-of address and uses it as a
        source address for multicast traffic, just like it would use a
        stationary address.  The mobile node MUST NOT use Home Address
        destination option in such traffic.

 NEW:

    A mobile node that wishes to send packets to a multicast group also
    has two options:

    1.  Send directly on the foreign link being visited.

 |      The application uses the care-of address as a source address for
 |      multicast traffic, just like it would use a stationary address.
 |      This requires that the application either knows the care-of
 |      address, or uses an API such as the IPv6 Socket API for Source
 |      Address Selection specification [RFC5014] to request the stack to
 |      use the care-of address as a source address in sent packets. The
        mobile node MUST NOT use Home Address destination option in such
        traffic.

 --------------------------------------------------------------------------

 NEW:

 18.2.  Informative References

 |  [RFC5014] Nordmark, E., Chakrabarti, S., and Laganier, J., "IPv6
 |            Socket API for Source Address Selection", RFC 5014,
 |            September 2007.


 ----


 [editorial note by Charles E. Perkins]:
 Following this, there was a discussion about how to enable
 an IKE daemon to use the care-of address.  Since that seems
 out of scope for rfc3775bis, I have not included it as part
 the discussion for this issue.


----------------------------------------+-----------------------------------
 Reporter:  charliep at computer.org       |       Owner:  charliep at computer.org
     Type:  enhancement                 |      Status:  new                  
 Priority:  minor                       |   Milestone:                       
Component:  draft-ietf-mext-rfc3775bis  |     Version:                       
 Severity:  Active WG Document          |    Keywords:                       
----------------------------------------+-----------------------------------
-- 
Ticket URL: <http://www3.tools.ietf.org/wg/mext/trac/ticket/8>
mext <http://tools.ietf.org/wg/mext/>
_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext