[GIST] NLI address choice for responding nodes

Roland Bless <[email protected]>
Newsgroups gmane.ietf.nsis
Organization Institute of Telematics, University of Karlsruhe
Message-ID <[email protected]>
Hi Robert,

Max Laier came across the following issue while
investigating mobility scenarios and actually implementing
support for them in GIST:

- while it is described on p.50 (sec. 5.2.2) how the NLI
  is to be determined for Query or Confirm messages, there is
  no guidance how to do it for Response messages.
  But the NLI in responses is important, because it
  determines where an MA will be destined to in C-mode.
  "A suitable choice is the interface that is carrying
  the outbound flow." is not applicable for responding
  nodes, though the rest of the paragraph seems to be
  applicable to a responding node, too.

- if a responding node has several addresses on the same
  interface configured, it is not really obvious how to
  choose the best NLI address. It is even in most cases
  not possible to determine the associated interface
  address via which the query came, because the interception
  usually happens on the interface and not on particular
  i/f addresses. It may be the case that you have non-public
  and public-addresses configured on the same interface or
  that you may have to choose between different CoAs. The
  situation may be easier in case that the GIST node is
  the flow destination. In this case you may use the MRI
  information in order to find an address for the Response's
  NLI and sending the response from it.

- the only idea that I have is to either use MRI information
  if the GIST node is the flow destination or to find out and
  use the outgoing interface where packets are routed to the NLI
  address of the Querier (i.e., to use the reverse route).
  In the latter case, the MA will probably arrive at a
  different interface than the incoming flow interface
  at which the query arrived.

Any other suggestions?

Regards,
 Roland
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.