[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on draft-ietf-shim6-proto-03
Shinta Sugimoto wrote:
Hello,
Let me post my comments on draft-ietf-shim6-proto-03. I have not read
the whole document yet, but here are my comments/questions from Section
1 to Section 14. Some are editorial, some are technical. I will
continue to read rest of the document and send more comments later.
Thanks for your comments and sorry for the tardy response.
I've used your comments as an indication where we can make the document
more clear, and I've applied your typo fixes.
o No extra roundtrip for setup; deferred setup.
I am not sure what does the above (fourth) bullet mean. Does
"deferred setup" mean context establishment follows the IP transaction
based on the ULID pair ?
What it means (and I'll clarify the document) is that we don't require
some extra shim6 handshake before TCP/UDP/etc packets can flow. Instead
normal TCP/UDP/whatever packets can flow and later and in parallel the
shim6 context can be setup.
I am not sure if there is semantic difference between "load balancing"
and "load spreading", but the former sounds more familiar to me.
I'll switch back to "balancing" since that is more common.
One can make a distinction between "balance" as a way to enforce a
particular split (e.g., a 50/50 balance), and the techniques in shim6 to
have different connections (from the same or different hosts) pick at
random between multiple destination addresses doesn't ensure "balance" -
a single connection might represent the bulk of the traffic. Hence I
used "spreading" for this for loose concept.
Section 1.4 talks about relation to IP Multicast as above. While I
agree that applying SHIM6 to the sender of IP Multicast does not seem
reasonable (in a sense that it requires sender to establish context
with all the receivers, which is unrealistic) it might be worth taking
a look at applicability of SHIM6 to the receiver node. As typical
scenario of IP multicast would be that the sender node is stationary
and receiver spreads in the network. It is more likely that receiver
changes its locator frequently than sender.
The approach doesn't prevent the receiver of multicast to change its
locators, since the receiver is not explicitly identified; the
destination address is a multicast address and not the unicast locator
of the receiver.
In general, I agree with what is stated in Section 1.5 about renumbering
implications. Particularly, we should consider how a host treats the
ULID which becomes unavailable. In such case, at least the ULID should
be removed from the physical interface and marked as
"still-in-use-but-to-be-soon-removed." The active connection which is
based on the ULID may continue but the ULID should not be used for new
connections.
I see the text is missing the introductory material which explains that
the "locator role" of the IPv6 address can be renumbered away; it is the
"ULID role" which raises the issue. I'll start the section as:
<t>As stated above, this approach does not try to make communication
survive renumbering in the general case.</t>
<t>When a host is renumbered, the effect is that one or more locators become
invalid, and zero or more locators are added to the host's network
interface.
This means that the set of locators that is used in the shim will change,
which the shim can handle as long as not all the original locators become
invalid at the same time.</t>
<t>But IP addresses are also used as ULID, and making the communication
survive locators becoming invalid can potentially cause some confusion
at the
upper layers. <old text>
IMHO, it would be good to mention that IP addresses to be specified in
selector information of security policy should be ULID (if locator agility
is required). I expect that even IKEv1/IKEv2 would also be possible to
run over SHIM6, for instance.
I'll add something.
1.7 Traffic Engineering
At the time of this writing it is not clear what requirements for
traffic engineering make sense for the shim6 protocol, since the
requirements must both result in some useful behavior as well as be
implementable using a host-to-host locator agility mechanism like
shim6. What is clear that whatever they are, shim6 will not be able
to provide identical capabilities to traffic engineering using BGP
and Provide Independent IP addresses.
It was not clear to me what the above paragraph means.
Could someone elaborate more on this ?
Let me know if this is more clear:
Inherent in a scalable multihoming mechanism that separates locators
from identifiers is that each host ends up with multiple locators.
This means that at least for initial contact, it is the remote peer that
needs to select which peer locator to try first. In the case of shim6
this is performed by applying RFC 3484 address selection.
This is quite different than the common case of IPv4 multihoming where
the site has a single IP address prefix, since in that case the peer
performs no destination address selection.
Thus in "single prefix multihoming" the site, and in many cases its
upstream ISPs, can use BGP to exert some control of the ingress used to
reach the site. This capability can't easily be recreated in "multiple
prefix multihoming" such as shim6.
...[snip]...
Current locator pair Each end of the context has a current locator
pair which is used to send packets to be peer.
The two ends might use different current locator
pairs though.
Is this true ? My understanding is that the two ends (I and R) must
have exactly the same current locator pair for the bi-directional
context. Otherwise, I guess receiver node maybe confused when it
tries to demux the receiving packet. Could someone help me clarify ?
They can be different. The locator *sets* known by the two ends will be
the same, but each end can independently decide to switch over to use a
different locator pair for the packets it is sending.
The receiver uses the set of locator pairs for the demux in combination
with the context tag. For the data packets the 47-bit context tag is all
the receiver needs to check for demuxing.
Forked Instance Identifier (FII) In order to handle context forking,
a context is identified by a ULID-pair and a
forked context identifier. The default context
has a FII of zero.
Is any specific data type defined for FII (eg. unsigned int) ?
Presumably a future ULP-to-SHIM6 API document will define the exact data
type. Presumably one doesn't have to support a lot of forked contexts,
thus a 32-bit FII would certainly be sufficient.
o Some heuristic on A or B (or both) determine that it might make
sense to make this communication robust against locator failures.
For instance, this heuristic might be that more than 50 packets
s/heuristic/heuristics/
Singular form is without the 's' AFAIK.
o In addition to failures detected based on end-to-end observations,
one endpoint might be know for certain that one or more of its
s/know/known/
s/be// is even better
I think this is an interesting issue. Assuming that node A sends packet
to B traversing the tunneling agent C; if the packet from node A happens
to be tunneled by C to B, we have several choices how to apply SHIM6.
I think the consequence would be depending on which entities establish
context. Let me expand it a little bit more.
a) If A and B establish SHIM6 context, a packet received by node B would
look like:
[Outer IP header]
src=C, dst=B
[Inner IP header]
src=L(A), dst=L(B)
[Shim6 Extension header]
...(Payload)...
b) If C and B establish SHIM6 context, a packet received by node B would
look like:
[Outer IP header]
src=L(C), dst=L(B)
[Shim6 Extension header]
[Inner IP header]
src=A, dst=B
...(Payload)...
Yes, those options do exist.
b) is basically applying a shim to the tunnel itself, and perhaps there
will be some use for this in some cases.
In most cases IP-in-IP tunnels are used as a routing technique, thus
it makes sense to apply them on the locators which means that the
sender would insert the shim6 header after any IP-in-IP
encapsulation; this is what occurs naturally when routers apply IP-
in-IP encapsulation.
I would like to have clarification which case a) or b) does the above
sentence means. IMHO, both a) and b) should be possible. b) is slightly
complex in a sense that SHIM6 packet processing takes place after
forwarding is done (at the router, namely node C in this case) at the
IP layer however it remains logical. Any comments ?
For Mobile IPv6 tunnels (which was on my mind when writing the above) it
makes sense to apply the shim above the tunneling layer.
So the text does refer to case a), even if that's hard to see from
reading it.
I'll use your text to more clearly state the options.
7.4 Context confusion
...[snip]...
The requirement is that the old context which used the context tag
MUST be removed; it can no longer be used to send packets.
Yes, but we should note one thing: Even if a node receives I1 message
with a duplicated context tag proposed by the other end, receiver node
should not delete old context until the context establishment is
successfully done.
Yes, I think that text exists in the detailed descriptions in 7.7 etc,
but it makes sense to add it in 7.4 as well.
o If the state is ESTABLISHED, it means that the Initiator has lost
the context information for this context and it is trying to
establish a new one. In this case, the host MUST update the
existing context and replace CT(peer) with the Initiator Context
Tag included in the I1 message and then reply with an R2 message,
including the associated state information. In this case the host
MUST look for any other (old) context with a matching CT(peer) as
specified in Section 7.12. This completes the I1 processing, with
the context state being unchanged.
Same as my previous comment, but I believe the above rule is not good
because it may allow malicious node to send false I1 message (by possibly
spoofing the source IP address) and delete corresponding context.
Correct. I think Marcelo had found this, but not send it to the mailing
list. Basically we shouldn't update CT(peer) until after a 3-way handshake.
If at least one of the above verification fails, then it silently
discard the packet and it has completed the I2 processing.
IMHO, it is better to rephrase above paragraph as below:
"If any of the above verification fails, the host MUST silently discard
the packet and complete the I2 processing."
Yes, that's better.
7.12 Match for Context Confusion
When the host receives an I2, I2bis, or R2 it MUST look for a
similar (might be same) comment again, but I believe the verification
discussed here should be applied for I2bis and R2 message. For I2
message, if the CT looks different from the one appeared on I1 message,
the I2 message should be considered invalid.
I don't understand the case. There is no state created on the reception
of the I1. But the initiator can't change the CT because it is included
in the verifier option computation. So what case do you think is
problematic?
I understand it is necessary to restore the original packet included in
the ICMP error message. Besides, I wonder if there is any kind of ICMP
error message to which SHIM6 protocol stack should react (e.g. changing
state of corresponding context). For instance, if the node receives
host unreach, should the corresponding host pair context be torn down ?
The draft-ietf-shim6-failure-detection-03.txt document treats those as
hints. In any case, they are not used to fail the shim6 context/ULID but
a hint that the destination locator is unreachable.
Better to replace "5 minutes" with certain protocol constant
(i.e. MINIMUM_CONTEXT_TIMEOUT).
I don't know if this needs to be a constant; different implementations
can pick different values based on their judgement of how long their
applications might use a context when there is no connected socket. For
instance, an implementation that uses different APIs than the socket API
might be able to know all the references applications retain to remote
IP addresses, in which case it can tear things down immediately when the
last reference is gone.
So I think 5 minutes is an example.
11.1 Sending ULP Payload after a Switch
What about the next header field in the IPv6 protocol header ? I believe
that SHIM6 should override the next header field of IPv6 protocol header
when locator switch is performed. The new protocol value for SHIM6
(IPPROTO_SHIM6 ?) is to be assigned by IANA. Is my understanding
correct ?
You're correct. I've added that description.
Erik