Subject: Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation

From: Charlie Perkins <[email-masked]>
Date: Fri, 01 Feb 2002 01:17:29 -0800

Hello Erik,

Continuing our discussion...

Erik Nordmark wrote:

>
> The first and foremost purpose of including what is in effect two destination
> addresses in a packet sent to the mobile is to be able
> to identify the mobile node indepedent of its current location.
> Thus identical to the purpose of the HAO.

The care-of address is the routing destination.  The home address
is the endpoint identifier -- i.e., the socket destination.  They
are used differently.  The care-of address should be be made
invisible to the application.  The home address should not be
made visible to the routing infrastructure, very broadly
speaking.

The purposes of the two devices under consideration (the
HAO and the routing header) are tailored to accomplish the
above.  I would not say they are symmetric.  If pushed to
trying to make some abstraction, I would say they are
instead dual.  Duality is, however, tricky, and I have never
seen a good analysis of the duality between routing and
endpoint identification.  One thing about dual spaces,
however, is that even if they are isomorphic, the correspondence
used to make the isomorphism is not natural.  That's why I
think "symmetry" is a wrong word.

> > The Routing Header is used for routing.  It provides an address
> > (namely, the care-of address) that has to be used for routing, but
> > that at the same time should be made invisible to any higher-level
> > protocols.
>
> I don't disagree with that RH could be used to carry the extra destination
> address. But the purpose of carrying it is to identify the MN.

I can understand this statement under the assumption that you
mean, "provide the home address to the mobile node as an
identifier".  Yes, the routing header does do that.  In fact, you
"could" make the care-of address as the final segment, and
have a new option that says "use this as your destination
home address", as has been pointed out elsewhere.  Then
I think you have to offer a solution about what happens when
that home address was an interior address in a list of routers
used for some purpose requiring a routing header.  Does the
node formulating the routing header have to condition its
construction based on knowledge about the care-of address
of the mobile node?  This is the additional complication
that will certainly become necessary if you mandate more
restrictive behavior now.  Or else in the future we will more
likely "un-mandate" it.  Oh, well!

> Whether there are benefits in using RH for this, beyond the fact that it
> is easier to change existing MIPv6 implementation to use a different RH type, is
> hard to tell.  I think we can't possibly tell until we know
> something more about the future in the areas of mobile routers/networks
> and/or use of RH for explicit routing by actual applications (as opposed
> to just traceroute -g).
> I base this thinking on not having seen anybody explain the architecture
> and conceptual model for such a scheme - the references to RH are that it
> mechanistically works.
> I don't disagree with the "works" part - but you seem to claim there is a
> deeper argument for RH being better and I fail to find one.

Then I would suggest that since RH manifestly "works", and since
we can not be sure that firewall vendors will be "nice" for any
alternative proposal especially when that alternative has to be
extended for the mobile router on my belt that communicates with
my PDA and laptop and earrings  -- that we should go with what
works.  And, after all, this is FAR more validation and analysis
than seems to go into other Proposed Standards!

Do I dare mention again that it's implemented and works?
I'm not trying to be antagonistic!

> > One shouldn't impose symmetry on the handling of addresses that
> > are to be used for different purposes entirely.
>
> We seem to agree that the HoA in a HAO sent *from* a MN serves to
> identify the MN.

Right, as long as we mean "endpoint identification".

> The above statement of "different purpose" seem to say that the HoA in a packet
> sent *to* a MN does not identify the MN?  I'm confused - either the home
> address identifies the MN or it does not - this can't depend on what type of
> packet the HoA is contained in.

Of course it does identify the endpoint.  The IPv6 endpoint
has several IP addresses, and having the home address is
crucial for picking the right internal sockets and so on.

I've gotta go to bed.  More later...

Regards,
Charlie P.

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 1 Feb 2002 09:00:34 +0100 (CET)

> Erik Nordmark wrote:
> 
> > Do people see strong arguments for/against handling the "source HoA" and the
> > destination "HoA" using the same mechanism?
> 
> Perhaps they are essentially different problems.
> 
> The Home Address Option is not used for routing.  It's used
> to identify the mobile node, when the default use of the routable
> IP address would lead to the "wrong answer".

Charlie,

Whether there are benefits in using RH for this, beyond the fact that it
is easier to change existing MIPv6 implementation to use a different RH type,
is hard to tell.
I think we can't possibly tell until we know something more about the future
in the areas of mobile routers/networks and/or use of RH for explicit routing
by actual applications (as opposed to just traceroute -g).
I base this thinking on not having seen anybody explain the architecture
and conceptual model for such a scheme - the references to RH are that it
mechanistically works. 
I don't disagree with the "works" part - but you seem to claim there is a
deeper argument for RH being better and I fail to find one.

> > Does it make any difference e.g. in IPsec related complexity?
> 
> I think it will be better to entirely remove the authentication
> of the Binding Update from the domain of IPsec.

I wasn't thinking of that subject - in fact this email thread has nothing to
do with how BUs are authenticated and authorized. 

I was thinking of the case when
folks want to use IPsec for the data traffic carried between nodes where some
of the nodes use MIPv6. The complexity of handling the HAO is well-known
in that case. Thus the question was whether putting the ADA together with the 
HAO, using the mechanisms we've already worked out in all their complexity,
would be any simpler than handling HAO the way we do (with respect to IPsec)
and have the RH which may have some other interaction with IPsec.

The answer from Francis on this question is that it doesn't matter, but
I'd like to explore some more details in that space to better understand.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 4 Feb 2002 13:05:07 +0100 (CET)

> made visible to the routing infrastructure, very broadly

I agree that the home address shouldn't be visible to the routing
infrastructure.
But below you talk about the home address being 
"interior address in a list of routers" which seems to conflict
with your statement above.

> think "symmetry" is a wrong word.

Well, the source and destination addresses in an IP packet look
rather symmetric to me, even though the functions the have as
a packet passes through a network are a bit different.
It seems to have served IP well to have the source and destination IP
addresses in the same IP header.
Thus one could make the argument that it makes sense to put the source and
destination HoA in the same place in the headers would make sense as well.

> identifier".

What I meant was more limited - identifying the MN in the sense that e.g. TCP
connections terminated on the MN use that HoA to identify the
connection.

>  Yes, the routing header does do that.  In fact, you

We are going around in circles both in the discussion and in your
arguments.
I've asked you many times on the list why you seen the need to
combine explicit routing (using source routing) and mobility
the way you describe.
Your respons has always been something like 
	its obvious that things should work as RH since this is routing
and using that as the motivation for it needing to work as RH.

In order to talk more intelligently about this it seems like we need
to understand:
1. Mobile routers/networks and how route optimization should work with such
2. Explicit routing using source routing - will applications do this?
3. How #1 and #2 should interact

To me saying whether destination options, routing headers, or Deering/Zill
tunneling fit better in this completely undefined space seems
to be rather unproductive speculation.

> than seems to go into other Proposed Standards!

RH works. 
Tunneling works.
The fact that HAO works for the source HoA means that we know exactly how to 
make a destination HoA work as a destination option as well.

The point is that the attribute "works" doesn't seem to help
tell them apart.
"Number of lines of code changes in an implementation" can be used to
tell them apart, and that is definitely one factor for the WG to consider
together with other factors.

> Right, as long as we mean "endpoint identification".

Hmm - but from above it seems like you have a different definition of
this term than I have. 

  Erik

---

From: "Jari T. Malinen" <[email-masked]>
Date: Mon, 04 Feb 2002 23:29:51 -0800

Erik,

> to be rather unproductive speculation.

Cannot agree more with this argument. It would therefore be
logical to concentrate on asking what is known, to limit the
analysis needed, and on host mobility requirements. Hence,
to go beyond saying just new RH, below, as a longer technical
answer, is a treatment of the issue reflecting it against the
keyword "undefined" you mention.

Comparison of new RH replacements based on their "undefinedness",
for

- New Routing Header
- New Destination Option
- ZOD/MR ZOD Tunneling
- Deering-Zill Tunneling
- New Header Type

1. New Routing Header

A Routing Header is a routing semantics entity with the
property that even though a node receives the packet, the header
causes further forwarding of the packet, through re-submission
to the network layer, towards the same or another L3
endpoint, internal or external to the node. The security
requirements call for the specific property of the endpoint being
internal to the node (a known property required for all 5
alternatives, to enforce the stateless filtering of packets
not staying in the destination node, based on packet content
only).

Known properties:
- Header Type: Routing Header
- Header structure: same as RH T0, with the limitation of
  1 address; we always have this entity alone in a header.
- Processing Rules (as with RH T0), exactly, except for limiting
  forwarding out of the node.
- Other behavior: Path MTU: as in IPv6. Very simplified note:
  A "beautiful" implementation may provide a way such
  as described by Francis, a more common way is to keep packet
  less or equal than the minimum IPv6 MTU of 1280 octets or that
  fragmentation is possible otherwise (a less robust but still
  "acceptable" IPv6 stack?).
- Problems resulting from use for other purposes: None, since
  this is meant (currently) for the sole purpose of host mobility.
  When the condition in the future may be relaxed, e.g. for the
  above unknowns you mention, the general requirement may get
  broken, possibly in an uncontrolled way.
- Final properties since this uses a standardized header.
- Interaction with IPsec (as RH T0)

Derivable properties
- Header ordering rules (e.g., as described by Pekka Savola)

Unknown properties:
- None (?).

Requirement for change
- 1 bit in format, enforcement of ordering rules against RH T0,
  enforcement of node-internal only forwarding.

2. New DO

This is an entity with endpoint semantics, that is, by reception
this destination option is meant to be consumed by the final L3
communication endpoint in the host which directly delivers the
upper layer part of the packet to the transport layer.

Known properties:
- Header Type: Destination Header
- Problems resulting from use for other purposes: None, since
  this is meant (currently) for the sole purpose of host mobility.

Derivable properties
- Header structure: Possibly the option alone, possibly with
  other DOs. In the latter case may need more rules.
  Option format: Possibly like HAO.
- Header ordering rules. Probably immediately after HAO.
- Processing Rules: As with HAO but for IP hdr dst. addr.
- Final properties since this uses a standardized header with
  MIPv6 draft version 15 DO HAO as a model for the DO.
- Interaction with IPsec (as HAO)

Unknown properties:
- None (??).

Requirement for change
- Addition of a new Dst Opt processing.
  Format, enforcement of ordering rules, option-internal rules.
  Since no forwarding is assumed, no need for enforcing
  node-internal forwarding.

3. ZOD/MR.ZOD Tunneling

This is an entity with unselected semantics, both endpoint and
routing semantics are described, but no restriction has been made.
That is, by reception, the Shim either switches endpoint
addresses from authorized state for internal delivery to
upper layer or in case of generalization, packet is
forwarded based on state. Non-generalized mode (NGM) fulfills
the generic requirement of not forwarding out of the node.
Alternatively this could have been treated as the applicable
component of the proposal but since this is a whole draft,
NGM cannot realistically be just extracted to MIPv6 draft?

Known properties:
- Header Type: Nothing needed (except a flag both ways)

Derivable properties
- Position of the flag, this was not specified for all cases, but
  rough alternatives were given.

Unknown properties:
- Problems resulting from use for other purposes: Not known,
  since this proposal does not restrict itself to host mobility.
  The choice for delivery vs. forwarding was not made nor strict
  restriction to use with host mobility in delivery, nor the use
  of RO signaling as establishing the state were mandated. This
  many open options leave room for too many unknowns given the
  level of security required for the choice at hand.
- Interaction/security with other protocols (given the amount of
  security and other analysis in MIPv6, any generic new method
  deserves this note)
- All possible signaling methods for setting up the
  authorized state (a downside of the proposal is its reliance
  on state, which gets the critique all non-routing-state-based
  forwarding usually does, esp. in its generalized format)
- Final stabilized properties, since there may be changes due to
  problems found with other uses.
- Interaction with IPsec

Requirement for change
- Entry and processing of the bits (Shims)
- Possible robustness features (several, some due to statefulness)

Summary: if it had restricted itself to host IPv6 mobility only,
  it would have been a stronger candidate. Then, I do not give
  the proper credit to this otherwise well thought draft, it
  should be a contender with the Deering-Zill tunneling, though
  the requirement for state in forwarding is a liability.

4. Deering-Zill Tunneling

This has a clear routing semantics, its compressed tunneling
headers call for a unambiguous forwarding close to that in
plain tunneling. However, for route-optimized traffic to
work between all nodes, unrestricted DZ-tunneling through
filters should be allowed so I have a doubt the generic
requirement for stateless filter-based reflection protection
can in all the cases be fullfilled (I obviously missed something).

Known properties:
- Header Types, ordering, header formats, processing (much is known)

Derivable properties
- operation with host mobility
- Some security behavior that is not repeated in the draft

Unknown properties:
- Problems resulting from use for other purposes: Not known,
  since this proposal does not restrict itself to host mobility.
- Interaction/security with other protocols (given the amount of
  security and other analysis in MIPv6, any generic new method
  deserves this note)
- Final stabilized properties, since there may be changes due to
  problems found with other uses.
- Interaction with IPsec (a part of it)

Requirement for change
- Generation and processing of new header types

Summary: This proposal has a cleaner semantics and would have
  been a stronger candidate should its security implications for
  all its potential uses (IPsec etc) have been better understood
  today.

5. New Extension Header

This is the most unknown in its semantics, all is open here.
We can construct another routing header -like extension header
or a new destination header -like entity, just to begin to
enumerate the open choices.

Known properties
- None, except the general requirement

Derivable properties
- Format contains an address

Unknown properties
- Everything else

Requirement for change
- Unknown

Summary: not a serious alternative given the level of missing
  detail that would be needed by now.

Based on this dimension of analysis, I would prefer routing
header, the DO being the other realistic alternative but with
significantly more towards unknowns while all the others having
too many unknowns to be realistic to adopt today for the very
specific use of host mobility that RH here has had (both tunneling
methods, esp. Deering-Zill, have much potential for later use
but with some questions of their applicability now).

>   Erik

BR,

-Jari

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 5 Feb 2002 12:00:54 +0100 (CET)

Jari,

Thanks for putting together this list - it is quite useful.
I might steal parts of it in order to complete the comparison
writeup that Phil is pushing to get completed.

>   forwarding out of the node.

It might also make sense to restrict so that the address in the RH
is in fact a Home Address of the MN.

>   "acceptable" IPv6 stack?).

I think you have to require that the applications limit the
messages they send so that the resulting packets (with a 40 byte IP
header and UDP header etc) does not exceed 1280-24=1256 bytes
in order to allow the IP layer to insert the RH.
Of course, for MN to MN communication both a HOA and RH are inserted
so the applications need to send even smaller packets.
Assuming the applications will do this might be problematic since
there might be applications which actually think that 1280 is the limit.
So I think reasonable PMTU handling is necessary - indepedent of
whether this is a new RH type, destination option, or Deering/Zill tunneling.
My only point was that for tunneling the problem is well understood and
written down in RFCs.

>   broken, possibly in an uncontrolled way.

There is a slight risk, deriving from the fact that this RH type 1
isn't used for source routing but has a name which makes it sound like
source routing, that firewalls will just drop all source routed packets.
If something other than RH is used I think it will help communicate to
the firewall implementors that its a MIPv6 "header" hence firewalls should
only block it if they want to block MIPv6.

> - Header ordering rules (e.g., as described by Pekka Savola)

Did he describe what should happen when RH type NEW is followed
by RH type 0 in the packet?

>   other DOs. In the latter case may need more rules.

I imagine we want the rule that when both HAO and ADA options are sent
they MUST be included in the same destination options header.
It makes no sense to allow two destination option headers in the packet
for the purpose of having one carry the HAO and the other carry the ADA
and I suspect it's easier for an implementation to be able to
extract both addresses in the same context in the code.

>   node-internal forwarding.

Hmm - I think we actually need wording that says that the address in the ADA
must be at least an IP address assigned to the node (and perhaps we want to
constrain this to be a Home Address assigned to the node) to prevent
implementations that replacing the IP destination field with the ADA (so 
that transport protocols can easily find the destination HoA)
in the case when the ADA is not assigned to the node.

> [...]

I think there are also implementation considerations for implementations
which have IP-in-IP as a pseudo-device driver since with DZ-tunneling
the MN-to-MN traffic would presumably use full IP-in-IP tunnel headers.
In that case the pseudo-device driver for tunnel decapsulation would need
to have a way to check with the MIP part of the code whether decapsulation
of a particular packet should be allowed.

> enumerate the open choices.

It seems like having a new extension header to just carry the
destination HoA doesn't make much sense - the source HoA would
still be a destination option.
If both source HoA and destination HoA (when both are needed) are
carried in such a new header the proposal seems to become either
(depending on processing rules and header order rules I think) like DZ 
tunneling *or* like a new destination option for the destination HoA.

> but with some questions of their applicability now).

Your list didn't include any unknowns for the DO case, but above you
refer to such unknows (if I parse the sentence correctly).

I agree there are a lot more unknowns for the other alternatives.

  Erik

---

From: "Jari T. Malinen" <[email-masked]>
Date: Tue, 05 Feb 2002 11:30:17 -0800

Erik,

> writeup that Phil is pushing to get completed.

Please go ahead.

> is in fact a Home Address of the MN.

Ok.

> My only point was that for tunneling the problem is well understood and

It's basically a non-MIPv6 (IPv6-generic) issue and there are
practical reasons why it is not advisable to make application
too aware of this. First, fragmentation is bad, e.g., firewalls
need to reassemble fragmented packets e.g. when smart proxying,
and fragmentation causes complications for IPsec. Fragmentation
seems work but it's complicated and inefficient, you do not want
to make that but when necessary. E.g., if you have multiple links
via which you can forward, you do not want even your bigger
packets to fragment unnecessarily if you have a chance they
can go over fatter pipes unfragmented (e.g. ATM). Hence, allowing
packets beyond minimum MTU is something practical boxes want to
do. But, when you do send over narrow paths, a stack can do
automatic fragmenting after adding extensions transparent to
application, unless fragmentation is forbidden. In that case,
you can either make it visible to the app giving it a low
value guessing the maximum the stack may add, or do it blindly
and indicate packet too big to the application. This was of
behavior in a sending box. Don't know if all this needs
to be in a spec. Maybe, since otherwise there might be the
misconception an IP stack cannot add anything besides IPv6
header to a packet by current IPv6 rules..

> only block it if they want to block MIPv6.

This is more of a user interface question. Nowadays both implementors
and sysadmins need to cope with so much more complicated filtering
issues when application level stuff gets into firewalls. I personally
have doubts of relevance in this argument.

> by RH type 0 in the packet?

Yes, in a followup mail Tue Jan 29.

> extract both addresses in the same context in the code.

Makes sense.

> in the case when the ADA is not assigned to the node.

Wording is ok, here I just refered to the inherent properties
of a DO, where no forwarding occurs naturally (though you _could_
with complicated rules bring routing semantics even to a DO).

> of a particular packet should be allowed.

That amounts to adding the don't forward to wrong addresses
-precondition. When doing this, it immediately brings a question
on the combinatorics of having MIPv6 and non-MIPv6 uses of DZ
and how does a FW know if a node has non-MIPv6 uses which
do not have the above restriction to enforce the reflection
prevention and whether this encourages FWs eventually to block DZ.
But to me these things seem underdefined hence my reservations to DZ.

> tunneling *or* like a new destination option for the destination HoA.

Yes, so here is more pain with no gain. Unless you contemplate
nuances on how IPsec recognizes these. I see not much point here since
even for DO you can most likely have the desired behavior by specifying
processing rules before submitting packet to the AH/ESP, e.g. whether to
change the address to the IPhdr dst address or not (something RH does by
default)..

> refer to such unknows (if I parse the sentence correctly).

I used a more fine-grained scale where DO issues tended to be
more open (more derivable than known) though not unknown or
unsolvable.

BR,

-Jari

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 5 Feb 2002 21:32:57 +0100 (CET)

> header to a packet by current IPv6 rules..

It is probably useful to add a "heads-up" to the mipv6 specification
to increase the likelyhood that new implementors are aware that they
need to think about PMTU issues in this area. But I don't think the
spec needs to go into more detail than that.

> have doubts of relevance in this argument.

Predicting the behavior of products and configuration intended to
prevent communication (also known as firewalls) is quite dicy.

But we do have an existence proof in IPv4 with ICMP destination unreachable
code "fragmentation needed and DF set".
There are various gross hacks e.g. in PPPoE equipment to deal with
the fact that a large number of firewalls fronting large web sites
block these packets - presumably as part of either blocking all ICMP 
packets or as part of blocking ICMP error packets.
I don't know of the root cause - but accidentally disabling path MTU discovery
from working through lots of deployed firewalls seem to be the net effect.

Sure, my concerns in this area could be viewed as FUD, but to me it
sure seems safer to be able to say "this is a MIPv6 option which is safe"
than "this type of the routing header shouldn't be treated as a routing
header from the perspective of a firewall". The probability of a firewall
implementor and/or adminstrator understanding the former seems higher.

> But to me these things seem underdefined hence my reservations to DZ.

Agreed.

  Erik

---

From: "Jari T. Malinen" <[email-masked]>
Date: Tue, 05 Feb 2002 15:38:03 -0800

Erik,

> prevent communication (also known as firewalls) is quite dicy.

Agreed. Being in focus in MIPv6 discussions and considered relevant
we can't help but trying to do that.

> from working through lots of deployed firewalls seem to be the net effect.

Yes, though I suspect it has more to do with the fact ICMP messages
that affect someone's state are unsecured rather than just being
similar.

> implementor and/or adminstrator understanding the former seems higher.

True though one could also say "block node-external source routing,
pass node-internal source routing", which is close to what one needs
to understand when deciding to block source routing.

BR,

-Jari

---

From: Francis Dupont <[email-masked]>
Date: Thu, 07 Feb 2002 20:45:12 +0100

...

   Unknown properties:
   - ...
   
=> I have done it (authors have it).

=> so my D/Z tunneling and IPsec interaction note can become useful
if the D/Z tunneling receives more interest.
(summary of my note: the important point is the order of the crypto
transform and the D/Z compression, and AH gives more choice because
the two operations can commute).

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Thu, 07 Feb 2002 21:09:32 +0100

=> this kind of MUST is clearly an abuse (things can still work without it)
but it makes things far simpler without drawbacks... I.e. it makes sense.

Regards

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 8 Feb 2002 09:48:10 +0100 (CET)

> the two operations can commute).

Francis,

In your opinion are all open issues with the interaction of D/Z tunneling
solved? (And it is just an issue of putting the right words in the D/Z
internet-draft.) Or are there additional unsolved issues in this area?

  Erik

---

From: Francis Dupont <[email-masked]>
Date: Fri, 08 Feb 2002 10:35:43 +0100

solved?

=> there are at least no more unknown. I don't know exactly what is
the meaning of "solved" in this context (the important point is
to know what are the interactions, what are the differences between
IPsec and IPsec with D/Z tunneling and what are possible choices if
we'd like to go further).

   (And it is just an issue of putting the right words in the D/Z
   internet-draft.)

=> mainly.

   Or are there additional unsolved issues in this area?
   
=> there is nothing really unsolved but there is a possible choice
for AH in tunnel mode, i.e. we can define a D/Z tunnel mode for AH
(not for ESP or IPcomp) which has the same security properties than
the standard tunnel mode for AH but less overhead in bytes.
The problem is that AH is not very popular in the IPsec WG and this
topics is not really in the IPv6 WG scope (i.e. this is a problem for
the IESG :-). In some words, is the game worth the candle?

Regards

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 08 Feb 2002 09:37:38 -0800

Hello Erik,

> with your statement above.

There isn't any conflict.  In any source route, the nodes which
are "farther down" in the list, are "intentionally" made to be
"not visible" until it gets to be their turn.  But, you are correct
that my statement could be misinterpreted.  What I should have
said is that the "home address should not be made visible
to the routing infrastructure _prematurely_" -- i.e., not until
it can be conveniently and/or correctly  used as a next hop.

> and using that as the motivation for it needing to work as RH.

I _wanted_ my response to be understood as saying that we CAN
model it using RH, and if we don't model it as RH, we'll have to
eventually say how to put source route segments before and after
the newly created thing, and that the new thing will be a lot harder
because we didn't model it using RH in the first place.  That's a lot
different than your characterization.

> to be rather unproductive speculation.

Here, I basically agree with you.  We can't boil the ocean now.

I would suggest that we proceed as follows:

- Leave RH for now
- Replace it if need be in the future.

> make a destination HoA work as a destination option as well.

Yes, except insofar as one wishes the new thing to work with routing headers.

> together with other factors.

How about "works now" vs. "works eventually"?

> Hmm - but from above it seems like you have a different definition of

I seriously doubt that!  We've both been around that mulberry bush more
than once, I'd say.

Regards,
Charlie P.