Subject: RE: draft-ipngwg-default-addr-select-00.txt

From: Richard Draves <[email-masked]>
Date: Mon, 25 Oct 1999 12:58:19 -0700

>   |    Changed the candidate set definition for source 
> address selection, 
>   |    so that only addresses assigned to the outgoing interface are 
>   |    allowed. 
> 
> I think this is a mistake.

Great! I was hoping to provoke some discussion.

> Eg: consider a node with two interfaces A and B.   Allow A to have
> a global address GA (and a local address LA though that won't be
> relevant here).   Allow B to have just a local address LB (no global
> prefix has been advertised on that link).   For the purposes of
> this example it doesn't matter whether the local addresses are site
> local, link local (or both).
> 
> Then consider a packet to be sent to the destination global address GD
> (exactly one address is available, and it has global scope).
> 
> And then assume that the node has chosen to transmit the 
> packet through
> interface B (as assumed in section 5 of the draft, the 
> outgoing interface
> has been chosen already).   For the purposes of this example (just to
> avoid the "why?" questions, assume that interface B is the only
> interface containing a default route, and that no more specific route
> can be used to reach GD).

It sounds to me like your node is misconfigured. Can you construct a
realistic situation that would explain this configuration?
 
> While selecting an address from the set on the outgoing 
> interface ought
> be done where possible, forcing selection of a useless source address,
> when an adequate one would have been available, doesn't make a lot of
> sense.

When I asked about this at the Tokyo meeting, no one could come up with a
good scenario or criteria for when an address from an interface other than
the outgoing interface should be used.

Put another way, if the candidate set is to contain addresses from multiple
interfaces, to implement the preference for the outgoing interface there
would need to be a rule added saying to prefer an address on the outgoing
interface over an address on another interface. Where in the prioritized
list of rules do you think this rule would belong?

One compelling scenario raised at the Tokyo meeting was with unidirectional
interfaces, where one would necessarily need to reply by sending packets out
another interface. But in that situation the source address is specified by
an upper-layer or application.

> The equivalent for IPv4 would be to demand that the source address
> selected be the address of the outgoing interface, only to discover
> that you're sending through an unnumbered interface...   IPv6
> doesn't really have unnumbered interfaces, but it does have ones that
> have only local scope addresses.

I don't have any experience with unnumbered interfaces. Can you draw an
analogy to their use in v4 to create a scenario for v6 where an interface
with only a link-local address will originate new communication to a global
destination?

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: Robert Elz <[email-masked]>
Date: Tue, 26 Oct 1999 17:52:10 +1000

Date:        Mon, 25 Oct 1999 12:58:19 -0700
    From:        Richard Draves <[email-masked]>
    Message-ID:  <4D0A23B3F74DD111ACCD00805F31D81014515CFD@RED-MSG-50>

  | It sounds to me like your node is misconfigured. Can you construct a
  | realistic situation that would explain this configuration?

Sure, though what is misconfigured, and what is just unusual, is kind
of hard to distinguish at the minute - we don't have "you should be
configured like this" guidelines yet.   (More below).

Part of this is that I believe that we ought keep the mechanisms as
flexible as possible so we can adapt to what turns out to be the
operating modes that people fall into naturally, rather than constraining
them to the operating mode we now see as the one which everyone ought
to use.   It may be that having a global address on every interface is what
the world moves to, but then again, it might not.

  | When I asked about this at the Tokyo meeting, no one could come up with a
  | good scenario or criteria for when an address from an interface other than
  | the outgoing interface should be used.

I would say, when the interface has no available suitable address, as one
scenario.

  | Put another way, if the candidate set is to contain addresses from multiple
  | interfaces, to implement the preference for the outgoing interface there
  | would need to be a rule added saying to prefer an address on the outgoing
  | interface over an address on another interface. Where in the prioritized
  | list of rules do you think this rule would belong?

I wouldn't do it that way.   After I sent the previous message I realised
that I hadn't said what I would change in the draft, and almost decided to
reply to myself and fill in the details - then I thought I'd wait for some
response.

Rather than adding all the addresses into the candidate set, and then be
faced with the problem of choosing which to select somehow, I'd be more
selective when building the candidate set.

That is, I would change section 4.1 to be something like...

  For the purposes of source address selection, the candidate set of
  source addresses CandidateSrc(D) for a destination address D contains
  all the unicast addresses assigned to the interface that will be used to
  send to the destination D.  If no address with scope equal or greater than
  that of D is in CandidateSrc(D), then addresses of scope greater than,
  or equal to, the scope of D from other interfaces are added to
  CandidateSrc(D).

Then CandidateSrc(D) only contains addresses from the desireable interface
unless none of those is likely to be suitable.   With that in mind, the
rest of the rules don't need to concern interfaces, they'll find the
best (or one of a set of equal best addresses) as it is.

  | One compelling scenario raised at the Tokyo meeting was with unidirectional
  | interfaces, where one would necessarily need to reply by sending packets out
  | another interface. But in that situation the source address is specified by
  | an upper-layer or application.

Huh?    Why?

Why would the application be any more likely to supply the address in
that case than in any other?   Are applications supposed to be endowed
with knowledge of unidirectional links for some reason?

Surely the application just says "open a connection to D", and then if
the path to D is via one half of a unidirectional link, that is what
gets used.    Dealing with this case will probably take more language
in the candidate set selection algorithm, as here the interface might
actually have a global address, it just isn't one that you really prefer
to use.  Or perhaps this is a rare enough case, that as long as you
have a working address, whether it is the "best" or not doesn't matter
as much.

  | I don't have any experience with unnumbered interfaces. Can you draw an
  | analogy to their use in v4 to create a scenario for v6 where an interface
  | with only a link-local address will originate new communication to a global
  | destination?

Sure - unnumbered interfaces are used for all those point to point links
for which having an address achieves little, and not having one conserves
address space.   Maybe IPv6 has enough address space to simply number
everything, but given various kind of tunnels (IPv4 tunnels, VPN tunnels,
etc) I'm not sure that we necessarily want to mandate burning addresses
on such things (if they could reasonably use /126 blocks or something
it would probably be OK, but it is more likely they will be using /64
blocks).

And for initiating communication - all I need for that is to have my
point to point link terminate on my firewall, which is running my
mailer - when I send mail, to the world, it goes internally to the
firewall, which relays it out its point to point link into the world.
The firewall box has a global address for the LAN interface(s) on the
internal side, it doesn't really need one for its *DSL, or ISDN, or
whatever, interface to the world, just a link local will do fine there.

Tim Hartrick's IPv4 tunnels are one possible unnumbered interface, there
are many more - the question for here is whether we should be mandating
that all such things have IPv6 global addresses (or at least, addresses
with a scope as large as any other interfaces on the system), or whether
we should be leaving that unspecified for now, to see just how the
community configures its systems.   There never was an IPv4 "how to choose
the source address" specification, so when unnumbered interfaces became
useful, their implementation was (fairly) simple.   I would suggest that
we keep IPv6 flexible the same way.

Your reply to Tim was ...

[email-masked] said:
  | So you can't assign global addresses to your tunnel interfaces? 

It isn't (or shouldn't be) whether it can be done or not, but whether
it must be done.   If this is to be mandatory, is there any better reason
than simplifying the source address selection algorithm?

  | One thought is that an interface that can't be assigned addresses
  | shouldn't qualify as an interface.

This sounds like playing with words to suit the definition.   I'm not sure
that's a good idea, all it can do is lead to future confusion.   In any
case, in some of these cases (I don't know about Tim's) the interface may
have addresses, just not ones with sufficient scope.

 | Another thought: how will your node receive packets from the 6bone that are
 | sent to the global address? They will be arriving via the tunnel. So it
 | would seem that your implementation uses a "weak host" model? In Oslo and
 | Tokyo the working group was considering a "semi-strong" model for IPv6

That would be overspecification.   There's no particular reason why any
of these models must be part of the specs - implementations can be of
strong, weak, or the "semi-strong" kind as needed.   Further, in many of the
cases that matter here, the device with the multiple interfaces is a
router anyway, for which those models are irrelevant (whether a router
simply receives a packet sent to an "incorrect" interface, or whether it
internally routes it to the correct interface, and then receives it, is
really an irrelevant consideration from the outside).

  | A final thought, appropriate only for routers: you could consider the
  | ethernet interface to be originating/receiving packets using the
  | global address, and it's internally forwarding the packets over to the
  | tunnel interface. If this is a desired viewpoint, I'd want to change
  | the draft to be more explicit about effectively enlarging the
  | candidate set of source addresses on routers. 

It can be viewed that way, but this is really more artificial layering,
which isn't going to match what anyone is really doing - and there's also
no real reason why this functionality needs to be confined to routers.

kre

---

From: Francis Dupont <[email-masked]>
Date: Wed, 27 Oct 1999 22:53:51 +0200

In your previous mail you wrote:

   
=> this seems nice (ie. better than the MUST in 4.1) but I don't know
if we should take preferred/deprecated property into account too:
 - if the outgoing interface for D has only deprecated addresses,
   should we add in CandidateSrc(D) preferred addresses of other
   interfaces?
 - on a host this issue is bound to the default router selection
   which can be connected (or not) to prefix management (ie. we can try
   select the default router on an interface with a preferred global
   address).
 - 6. is empty but a home address is some kind of super-preferred
   address, ie. we should use it if there is no good reason to
   use another address. Obviously this "SHOULD" is stronger than
   the 4.1 provoking "MUST"...

   ...

=> I agree, unnumbered interfaces *are* very important in the IPv4 world.
We must have a similar facility for IPv6 (the decision was done when
we adopted the address per interface in place of the address per node
as in CLNS). When an unnumbered IPv4 interface is used then we take
an address from another interface, in the IPv6 world this translates
in when an interface with only addresses in too small scopes is used
then we take an address from another interface with a larger scope.
(ie. I fully support Robert's proposal on this point!)
   
Regards

[email-masked]