[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on draft-ietf-shim6-proto-00.txt
my p.o.v. w.r.t. the comments you made
El 05/10/2005, a las 14:29, Jari Arkko escribió:
Thanks for writing this. We are beginning to see
a complete shim6 protocol proposal! This document
answered many questions that I have had at least.
Overall, I think the approach is solid. But I did have
a number of questions and comments, see below:
Missing a discussion on the relationship of the shim6
processing wrt other processing that is taking place
at the IP layer, including at least IPsec but probably
also Mobile IPv6. I know from past experience that
its quite hard to define the relationships and processing
order correctly, and I suspect that its increasingly hard
Also, what is the relationship of Shim6 processing to
things in the host that depend on literal addresses,
such as IPsec policies?
Another missing discussion: the document refers to
SCTP as if it would be obvious how it can use Shim6. I'm
not sure that's the case. Or at least its not obvious to me :-)
basically, as i read it, the point would be to include a section about
shim interaction with other potentially affected protocols, such as
MIP, IPSec, SCTP
I think this makes sense
Yet another missing discussion: is there some interaction
with this protocol and the protocol defined in Marcelo's
draft that talked about communication with non-shim6
peers? It would appear that some aspects (e.g. input from
RAs) is common.
As i understand it, we have two cases:
- a host within the multihomed site that wants to initiate a new
communication with an external legacy host after an outage, and
- a host within the multihomed site that wants to initiate a new
communication with an external shim host after an outage
In the first case the mechanisms for doing this must only reside in the
multihomed host, while in the second case, the mechanism can involve
both (the multihomed and the external) hosts
Clearly the mechanisms used for the first case can be used for the
second case as well (obviously the mechanisms for the second and not
suitable for the first case)
The question is whether it wouldn't be better to define mechanisms that
are specific for the second case, taking advantage of the shim
capabilities of the shim peer.
The benefit that i can think of in this case would be that retrial
would be transparent for the ULP, since it would be solved by the shim.
The drawback is that the shim session needs to be established before
the communication is initiated, which may not always be the case. An
additional drawback is the added complexity, that need to quantify,
since these shim based mechanisms to deal with non working ULIDs are in
addition to the mechanisms for dealing with legacy hosts. Additional
difficulties for this mechanisms is the discovery of alternative
locators for initiating the communication, which is likely to be based
on information posted in the DNS, but that information is probably not
as good as it may seem, since the addresses associated with a given
FQDN may not belong to a single host, resulting in invalid ULID/locator
As a side note, these mechanisms for dealing with non reachable ULIDs
are needed for supporting things like ULAs as ULIDs.
And one more: the document is relatively silent on
(un)reachability detection mechanisms beyond shim6-based
probing. We do have ND(NUD), L2, etc. mechanisms that
should be taken into account. If your L2 tells you that its
lost the connection, there's no point in probing at L3,
we need to find another interface!
multihoming can be provided for IPv6 with failover and load
I'm a bit concerned that we have not figured out all the details
regarding load spreading. You don't want a particular session
spread around different paths, because doing so would
confuse existing congestion avoidance mechanisms. The obvious
answer appears to be making sure that that we keep the same
locator pair for the same session. But can we identify sessions
in all cases? Also, protocol description in Section 4 and beyond
does not talk about when and how loadsharing is initiated and
I am not sure what do you mean by load sharing...
If we are talking about distributing the traffic across the multiple
exit paths of the multihomed site, i would say that this would be
naturally provided by the selection of ULIDs by the applications. I
mean, just the fact that different hosts select different prefixes for
initiating communications would result in a distribution of the load
across the different ISPs.
I mean that there is no point to distribute the packets of a given
communication among the different paths, since what really matters
AFAICT is the overall load, which is the aggregation of the load of all
nodes, which will be distributed because different communications will
use different prefixes hence different ISPs (as opposed to a single
communication distributing the load among multiple ISPs)
However, this is clearly not good enough for achieving some form of
traffic engineering or policing where something more that spreading the
load evenly across isps is required.
In any case, i think it would make sense to explain this in the doc
o Communication continues without any change for the ULP packets.
In addition, there might be some messages exchanged between the
shim sub-layers for (un)reachability detection.
o At some point in time something fails. Depending on the approach
to reachability detection, there might be some advise from the
ULP, or the shim (un)reachability detection might discover that
there is a problem.
At this point in time one or both ends of the communication need
to explore the different alternate locator pairs until a working
pair is found, and rehome to using that pair.
Some additional thinking may be needed here wrt. what
goes on in the alternative paths during the first step and
which end does what in the second step.The reason that
I worry about this is the various middleboxes that we may
In an IPv6-only world we don't need to worry about NATs.
However, there may be stateful firewalls that prevent, for
instance, the peer from contacting our other locator since
the firewall may not have seen any traffic to the peer from
our other locator yet.
o The shim (un)reachability detection will monitor the new locator
pair as it monitored the original locator pair, so that
failures can be detected.
There's no consideration here for switch-due-to-policy, such as
someone preferring his LAN connection when its present
over wireless connections, regardless of whether the wireless
works or not. Personally, I'm fine with avoiding
policy (it'll never get configured anyway) but perhaps this
is a limitation that should be explicitly stated & discussed.
i think it may be good to support this configuration...
I mean, this would be also the case of primary/backup configuration
where the backup link has worse performance than the primary, so the
primary is preferred as soon as it is available
This is also related to the load sharing support.
used IP protocols this is done by using a different value in the
Label field, that is, there is no additional header added to the
packets. But for other IP protocol types there is an extra 8 byte
header inserted, which carries the next header value.
This seems a bit surprising, but I'm probably missing
something. (Postscript: after reading the rest of the
document I now understand what's going on. But there
may be other readers who are left wondering at this
point in the document.)
In addition, the non-shim6 messages, which we call payload packets,
will not contain the ULIDs after a failure. This introduces the
requirement that the <peer locator, local locator, local context
MUST uniquely identify the context. Since the peer's set of
might be dynamic the simplest form of unique allocation of the local
context tag is to pick a number that is unique on the host. Hosts
which serve multiple ULIDs using disjoint sets of locators can
maintain the context tag allocation per such disjoint set.
Not sure if this always needs to be true.
It might be that the shim6 failover protocol signaling
is used to tell the peer what the new locators are. If
that's the case, then the local context tag alone does
not need to be unique, you could rely also on the
Also, there seems to be security issue in using just
the context tag to do the demux.
as i understand it, once that the context is identified using the
context tag, the addresses included in the packet are verified against
the locator set available for that context. If the addresses included
in the packet are not included in the locator set of the context, the
packet will be ignored
As i see it the unique context tag is needed not because we have
unknown addresses than can be used as locators, but because those
addresses may be inlcuded in more than one context.
So if both contextA and contextB have Address1 and Address2 as valid
locators (for each endpoint) then when a packet using Address! and
Adress2 is received, the hosts cannot tell which context (A or B) to
use to perform the demux
Both Address1 and Address2 must have been validated and are included
explicitly as locators in the locators set of each context.
(Or is there some
crypto hash somewhere too?) If I learn or guess
your tag, does that mean that I can start sending
traffic that appears to come from you, even if I
use a different source IP and my host is under
ingress filtering restrictions?
i don't think so, see above
The peers' lists of locators are normally exchanged as part of the
context establishment exchange. But the set of locators might be
dynamic. For this reason there is a Locator List Update message and
This appears to require (optional?) CGA.
Perhaps this could be stated
earlier on when you talked about HBA.
The above probe and keepalive messages assume we have an established
host-pair context. However, communication might fail during the
initial context (that is, when the application or transport protocol
is trying to setup some communication). If we want the shim to be
able to optimize discovering a working locator pair in that case, we
need a mechanism to test the reachability of locators independent of
some context. We define a locator pair test message and
acknowledgement for this purpose, even though it isn't yet clear
whether we need such a thing.
It isn't clear to me how this would be done. Presumably
its the application that is going through the IPs retrieved
from DNS, not the IP layer.
Is this something that we
need to handle?
i guess that is under discussion if it is worthy, see above...
It might be possible to combine these functions. But lets
do the individual design first for each, and combine later
Also, the assistance from payload packets in the explore
phase is not discussed.
i am missing what you mean here... could you expand?