Subject: (IPng 7442) RE: simple source address selection

From: Richard Draves <[email-masked]>
Date: Wed, 28 Apr 1999 21:46:34 -0700

> >   The IPv6 addressing architecture [3] allows multiple 
> addresses to be
> >   assigned to interfaces. These addresses may have different
> >   reachability scopes (link-local, site-local, or global).
> 
> Some of the assignable addresses are multicast addresses, which have a
> wider range of possible scope values.

Yes, I guess I should say unicast to clarify.
 
> Question: does DHCPv6 support the preferred/deprecated attribute for
> addresses assigned via DHCP?

Turns out the answer is yes, so I will need to update this and the other
reference.

> You may want to observe that, in the case of a multicast destination,
> one MUST use the "strong" host model, i.e., the source address must
> belong to the originating interface (or, more accurately, to an
> interface attached to the same link as the originating interface).
> This is a requirement of most current multicast routing protocols.

OK...

> Although I have long been an advocate of the strong host model for
> unicast as well, I finally conceded the need to allow use of a source
> address that belongs to a different interface than the 
> originating one,
> for unusual circumstances like responding to a ping of a 
> unidirectional
> interface.  However, I think the source-address selection rules should
> cause the strong host behavior to occur whenever possible.  Thus, I
> would advocate a Rule 0, preceding your other rules, that says if SA
> belongs to the outgoing interface and SB does not, you MUST use
> choose SA.

I disagree with this. I implemented strong host model in MSR IPv6 (don't
support unidirectional links, sorry) - the only way we'll send a packet with
a mismatched source address and outgoing interface is if an
application/upper layer specifies a source address on a forwarding
interface. However I don't see a reason to force this choice on
implementors.

> So, for example, if a node specifies that a packet be sent 
> out interface
> x, destined to an address that belongs to its own, different, 
> interface y,
> it should carry one of x's addresses as a source address, 
> which contradicts
> your Rule 1.  Note: this example can occur only in the case 
> were the upper
> layer has explicitly specified the outgoing interface, 
> overriding the host
> routing layer's inclination to send the packet out -- and 
> then looped back
> from -- the interface belonging to the destination address

I don't see a contradiction here.

For a strong host model implementation, the set of candidate source
addresses will be those addresses assigned to interface x. So the algorithm
will not use y's address as the source, despite rule 1, because it's not in
the set of candidates.

For a weak host model implementation, y's address will be in the set of
candidate source addresses and it will be chosen as the source address, but
that's OK for weak model.
   
> Another issue with your language above regarding the weak 
> model -- "this
> MAY be the set of all addresses assigned to the nodeís 
> interfaces" -- is
> that, when sending a packet to a less-than-global 
> destination, there may
> be some of a node's unicast address that MUST NOT be used a 
> source address
> under any circumstances.  For example, when sending a packet 
> to a site-
> local destination via interface x, you MUST NOT use a site-local or
> link-local source address that belongs to an interface y that is not
> attached to the same site as interface x.

Yes, I need to clean this up for destination addresses of less than global
scope.

> >4. Source Address Selection
> 
> I know this is specified elsewhere, but you might want to throw a
> sentence in somewhere, reminding people that multicast addresses and
> anycast addresses MUST NEVER be used as source addresses.  
> This is sort
> of a "Rule -1", preceding all others, that takes those kinds 
> of addresses
> out of the pool of candidate source addresses.

OK

> >   Addresses that are manually configured (or otherwise not auto-
> >   configured according to [4]), we treat as having "preferred"
> >   configuration status.
> 
> The answer to my earlier question about DHCPv6 may require a slight
> rewording here.

Yup

> >   Rule 1: If one of the source addresses is equal to the destination
> >   address, an implementation MUST choose that source address.
> 
> This rule (and probably all of them) needs to be qualified 
> with language
> about scopes and interfaces.  For example, if I am sending a packet to
> destination site-local address A in attached site S1, I can use A as a
> source address ONLY IF A is one my addresses on an interface attached
> to site S1.  If A happens to be one of my addresses only on 
> an interface
> that is NOT attached to S1, it is NOT a candidate for use as source
> address in that packet.

Rather than qualify all the rules, isn't it simpler just to be clearer about
the set of candidate source addresses?

> >7. Other Format Prefixes
> >
> >   This document does not specify source address selection in the
> >   presence of NSAP addresses, IPX addresses, or addresses 
> with as-yet-
> >   undefined format prefixes.
> 
> Rather than leaving it undefined, I suggest that we say that 
> all address
> prefixes other than link-local, site-local, and multicast be 
> interpreted
> as global-scope unicast.  If it turns out that that is the usage they
> eventually take on (which I think is the most likely usage), then all
> the fielded equipment will do the right thing without any 
> modification.
> If, on the other hand, those currently-unused prefixes end up being
> assigned different semantics, part of their specification can be how
> they fit into the source-selection rules.

OK

Thanks,
Rich
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Steve Deering <[email-masked]>
Date: Thu, 29 Apr 1999 11:29:52 -0700

At 9:46 PM -0700 4/28/99, Richard Draves wrote:
>At 2:05 PM -0700 4/28/99, Steve Deering wrote:
> > address that belongs to a different interface than the originating
> >  one, for unusual circumstances like responding to a ping of a 
> > unidirectional interface.  However, I think the source-address
> > selection rules should cause the strong host behavior to occur
> > whenever possible.  Thus, I would advocate a Rule 0, preceding your
> > other rules, that says if SA belongs to the outgoing interface and
> > SB does not, you MUST choose SA.
>
>support unidirectional links, sorry) - the only way we'll send a packet
>with a mismatched source address and outgoing interface is if an

I guess I'm advocating a new, "semi-strong" (or "semi-weak"?) host model.
The historical debates on this topic always polarized into two positions:

	strong:	When originating a packet from interface x, the source
		address MUST be one that belongs to interface x.

	weak:	Any of a host's addresses may be used as the source
		address of packets originated by that host, regardless
		of the originating interface.

The reason the Host Requirements working group could never converge
on one model or the other is that both have serious problems:

	- The weak model permits -- and makes quite common -- behavior
	  that defeats ICMP Redirect and can cause tripling of the
	  traffic load on the first-hop link (each original packet,
	  a redirected copy of each original packet, and, if not
	  rate-controlled, an ICMP Redirect message in response to
	  each original packet).

	- The strong model forbids behavior that is necessary in some
	  circumstances, such as responding to pings of, or TCP
	  connections to, receive-only interfaces.  It also requires
	  a more complicated host routing layer implementation, and one
	  that is different from that of a router (which irked the Unix
	  folks who built systems that were intended to perform either
	  role).

Rather than forcing a choice between those two problematic positions,
I'm suggesting an intermediate model:

	semi-strong:  When originating a packet from interface x, the
	     source address SHOULD be one that belongs to interface x.      

The IETF definition of "SHOULD" is "do this unless you have a good reason
to do otherwise".  An example of a good reason is that the upper-layer
protocol requests transmission of a packet out interface x with a source
address belonging to interface y.  Another good reason is that the upper-
layer protocol requests transmission with a source address that belongs
to a receive-only interface.

A somewhat less good -- but still grudgingly permitted :) -- reason is
the unwillingness of the implementor to do the more sophisticated host
routing implementation that would ensure that a packet went out the
interface corresponding to its source address in the case where the
upper-layer specifies the source address but does not care which
interface it goes out.

Now in the case covered by your draft, the upper-layer does not care
what the source address is, so there is no overriding reason to prevent
the source address from being one that belongs to the outgoing interface.

If hosts follow this approach, then except when there is an overriding
reason to do otherwise, they will behave in a way that makes Redirect
work properly.

--> I'd appreciate comments on this approach from anyone, especially
     implementors.

> > out interface x, destined to an address that belongs to its own,
> > different, interface y, it should carry one of x's addresses as
> > a source address, which contradicts your Rule 1.
>

You are correct that the issue does not arise in the strong-model case.
It was the weak-model implementation that I was concerned about: I
claimed (my opinion) that the packet "should carry one of x's addresses
as a source address", but your Rule 1 would prevent that from happening.
This comes back to the weak vs. semi-strong issue: the weak model says
any source address is OK and there is no reason to prefer one source
address over another.  The semi-strong model says any source address is
OK, but when given a choice, choose one that belongs to the originating
interface.

> > with language about scopes and interfaces...
>

Yes, that would be the better fix.

Steve

---

From: Robert Elz <[email-masked]>
Date: Fri, 30 Apr 1999 15:36:40 +1000

Date:        Thu, 29 Apr 1999 11:29:52 -0700
    From:        Steve Deering <[email-masked]>
    Message-ID:  <v04204e00b34e3e78cc17@[171.69.116.90]>

  | An example of a good reason is that the upper-layer
  | protocol requests transmission of a packet out interface x with a source
  | address belonging to interface y.  Another good reason is that the upper-
  | layer protocol requests transmission with a source address that belongs
  | to a receive-only interface.

Another scenario to consider is where a multi-homed host (not a router) is
connected to two links, between which there is no routing (either temporarily,
or permanently).

Consider the case where the router that should connect the links is
temporarily out of order.   A host on either link (directly, or at
some remote distance) may happen to have a connection to the multi-homed
host using the address that is on the "far side" of the host (in terms
of the link via which packets arrive).   Since there is no router available
to connect the two links, the only way they can be delivered is to the
"wrong" interface (which can trivially achieved via a host route at
appropriate places).  Similarly, the only way replies can be sent is
out the "wrong" interface.  Obviously this doesn't work if the host
implements strict strong model (but much about the way the internet runs
makes that a very rare host).

  | A somewhat less good -- but still grudgingly permitted :) -- reason is
  | the unwillingness of the implementor to do the more sophisticated host
  | routing implementation that would ensure that a packet went out the
  | interface corresponding to its source address in the case where the
  | upper-layer specifies the source address but does not care which
  | interface it goes out.

Or that the host implementor has done the work to participate enough
in the routing protocols and policies that it knows the best route to
the destination (and would ignore an ICMP even if one were sent perhaps).

  | The semi-strong model says any source address is
  | OK, but when given a choice, choose one that belongs to the originating
  | interface.

This seems right to me.   It also seems to be in conformance with what
most implementations actually do (for IPv4 anyway).  There may be something
which actually implements "randomly pick a source address" (true weak model),
but if there is, I have not seen it.

kre

---

From: Steve Deering <[email-masked]>
Date: Fri, 30 Apr 1999 12:23:55 -0700

At 3:36 PM +1000 4/30/99, Robert Elz wrote:
>temporarily out of order...

In the scenario you described, I think you are talking about manual
configuration of the multihomed host and one or more routers to deal
with the problem.  I agree that manual configuration should be able
to override the default behavior of the multihomed host.

>the destination (and would ignore an ICMP even if one were sent perhaps).

Yeah, I suppose.

>but if there is, I have not seen it.

Probably not "randomly pick a source address", but I believe some
implementations have the notion of a "primary address" (e.g., the first
address configured at boot time) that is always used as the source
address whenever the upper layer doesn't care, regardless of outgoing
interface.

And in the scenario that I raised in my first response to Rich's new
draft, in which a host sends a packet from interface x to its own address
for interface y, a weak host following Rich's Rules would be *required* to
pick a source address that does *not* belong to the outgoing interface,
which is even worse than random if one agrees with the semi-strong model.

Steve