Subject: new issue: [LL26] source address selection is different from destination access

From: Erik Guttman <[email-masked]>
Date: Tue, 11 Feb 2003 15:29:33 +0100 (CET)

The text of the issue follows.  Please also see
http://www.spybeam.org/ll26.html

----------------------------------------------------------------
Description of Issue  source address selection is different from
                      destination access    
Submitter Name  Philip Nye    
Submitter Email Address  [email-masked]    
Date first submitted  10 Feb 2003
Reference 
Comment Type ['T'echnical | 'E'ditorial]  E    
Priority ['S' Must fix | '1' Should fix | '2' May fix ]  1    
Section  2.6

Rationale/Explanation of issue: 

Section 2.6 depite its title "Source Address Selection"  actually talks
a lot about how to reach destination addresses. This makes change to
wording difficult and confuses some issues under discussion.  Lengthy
description of problem: Selection of source address is an issue
connected with multihoming and the degree to which v4LL addresses are
deprecated in the presence of configured addresses. 

Access to destination addresses is a simple choice of when to ARP and
when to send to a router and should be treated in a different section.

Based on the existing text in draft 7 these sections would become as
below.  This text would be potentially modified by issues LL1, LL13,
LL17, LL19 and maybe others.

Requested Change: Delete section 2.6 and replace with:

2.6 Source Address Selection

Since each interface on a host may have a link-local address in
addition to zero or more other addresses configured by other means
(e.g. manually or via a DHCP server), a host may have to make a
choice about what source address to use when it sends a packet or
initiates a TCP connection.

If the destination address is in the 169.254/16 prefix (including the
169.254.255.255 broadcast address), the host SHOULD use its link-
local source address, if it has one.

If the destination address is the 255.255.255.255 broadcast address
or a multicast address, then the host may use either its link-local
source address or a routable address, as appropriate.

If the destination address is a unicast address outside the 169.254/16
prefix, then the host SHOULD use an appropriate routable source address,
if it has one. If the host does not have a routable source address, then
it MAY choose to send its packet, with a link-local source IP address
and a routable destination IP address. 

In the case where two hosts on the same link each have both a link-
local address and another address configured via some other means,
the host may use either its link-local source address or a routable
address, depending on which is expected to be more likely to remain
stable for the expected lifetime of the connection. Note that link-
local addresses may be forced to change over time, as described in
Section 2.5.

2.6a Accessing destination addresses

If the destination address of a packet to be sent is in the 169.254/16
prefix (including the 169.254.255.255 broadcast address), the host MAY
choose to ARP for the destination address and then send its packet, with
a link- local destination IP address, directly to its destination on the
same physical link. The host MUST NOT send the packet to any router for
forwarding. 

If the destination address is a unicast address outside the 169.254/16
prefix and the source address is a Link-Local address, then the sender
MAY choose to ARP for the destination address and then send its packet,
with a link-local source IP address and a routable destination IP
address, directly to its destination on the same physical link. The host
MUST NOT send the packet to any router for forwarding.

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Feb 2003 09:37:39 -0500

agree with the rationale, disagree with the requested change.

A host SHOULD always use a routable address as a source address if it has
one, even when sending to an LL destination.

---

From: "Philip Nye" <[email-masked]>
Date: Tue, 11 Feb 2003 15:18:01 -0000

> From: "Keith Moore" <[email-masked]>
>

I happen to agree with this - the change should be in LL1 I think.

But given the number of other issues proposing textual changes to section
2.6 I simply split it based on the text in the draft.

I would suggest that my split be (conceptually) applied first then other
changes be applied to the text as split.

I certainly agree with some of the other proposals which would modify this
text but didn't want to confuse the issue of what it should say with the
problem stated in the issue and in fact the whole idea of splitting it is to
allow discussion of source selection to be separated from the rules on how
to send the packet which are less controversial.

How is best to resolve this interdependence of issues Erik? Should I try and
reword my proposal or add a note?

Philip

---

From: Erik Guttman <[email-masked]>
Date: Tue, 11 Feb 2003 16:25:11 +0100 (CET)

Philip,

On Tue, 11 Feb 2003, Philip Nye wrote:
> text but didn't want to confuse the issue 
[snip] 
> reword my proposal or add a note?

Since the text will likely be in flux as we discuss other issues, how 
about you leave the suggested text blank at this point and just include
an editorial instruction to 'divide the source address selection' and
'destination access policy' text.

The question is - should we discuss/approve LL26 at the same time as LL1
and LL2 (which are The Hot Topics and need to be brought up ASAP), or
should we consider the editorial splitting afterwards? 

Erik

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Feb 2003 10:28:05 -0500

my impression is that we're trying too hard to express these issues in terms
of changes to the existing text, when the existing text suffers from several
assumptions that are now being questioned.

let's agree on the principles, and figure out how they affect the text later.

On Tue, 11 Feb 2003 15:18:01 -0000

---

From: "Philip Nye" <[email-masked]>
Date: Tue, 11 Feb 2003 18:27:50 -0000

> From: "Erik Guttman" <[email-masked]>
>

I've send you a modified proposal.

Philip