WG ACTION: ACCEPT [LL45] Embellish text coping with scoped addresses

Action: Accept the change.

LL45

Description of Issue: Embellish text coping with scoped addresses
Submitter Name:       Alex Zinin
Submitter Email:      
Date submitted:       20 Feb 04
Reference:            
(T=tech, E=edit):     T
Priority (S must, 1 Should, 2 May fix): 2
Section:              3.2
Rationale/Explanation: 
Long Description:

From section 3.2
>    One possibility is to support this only in the case where the
>    application specifically expresses which interface to send from.

>    There is no standard or obvious solution to this problem.  Existing
>    application software written for the Internet protocol suite is
>    largely incapable of dealing with address ambiguity. This does not
>    preclude an implementer from finding a solution, writing
applications
>    which are able to use it, and providing a host which can support
>    dynamic configuration of Link-Local IPv4 addresses on more than one
>    interface.  This solution will almost surely not be generally
>    applicable to existing software and transparent to higher layers,
>    however.

The text reads as if we don't know how to work with scoped addresses
at all. This is not true. We know that:

  1. The IP stack must have the outbound interface associated with
    a packet that needs to be sent to a LL destination address

  2. The outbound interface cannot be derived from the packet's
    header parameters such as src or dst address (e.g. by using
    the forwarding table lookup), hence

  3. Outbound interface association MUST be done explicitly
    through other means. The specification does not stipulate
    those means, but examples include ...

Proposed Change:

From: 

>    One possibility is to support this only in the case where the
>    application specifically expresses which interface to send from.
>
>    There is no standard or obvious solution to this problem.  Existing
>    application software written for the Internet protocol suite is
>    largely incapable of dealing with address ambiguity. This does not
>    preclude an implementer from finding a solution, writing
applications
>    which are able to use it, and providing a host which can support
>    dynamic configuration of Link-Local IPv4 addresses on more than one
>    interface.  This solution will almost surely not be generally
>    applicable to existing software and transparent to higher layers,
>    however.

To:

>    One possibility is to support this only in the case where the
>    application specifically expresses which interface to send from.
>
>    There is no standard or obvious solution to this problem.  Existing
!    application software written for the IPv4 protocol suite is
                                          ^^^^
>    largely incapable of dealing with address ambiguity. This does not
>    preclude an implementer from finding a solution, writing
applications
>    which are able to use it, and providing a host which can support
>    dynamic configuration of Link-Local IPv4 addresses on more than one
>    interface.  This solution will almost surely not be generally
>    applicable to existing software and transparent to higher layers,
>    however.

  Given that the IP stack must have the outbound interface associated 
  with a packet that needs to be sent to a LL destination address, 
  interface selection must occur.  The outbound interface cannot be 
  derived from the packet's header parameters such as src or dst address 
  (e.g. by using the forwarding table lookup).  Therefore, outbound
  interface association MUST be done explicitly through other means. 
  The specification does not stipulate those means.