[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Evalulation: draft-ietf-mobileip-ipv6
Here are the comments to add to my previous set of discuss comments.
Erik
Major issue:
------------
Section 11.3.1 says that one of the mobile node's care of addresses
is good enough as a source when sending packets with a HAO.
This isn't correct since the CN will verify that the source address
is exactly the CoA that the CN has in its BCE. Thus the requirement for
the sending is to use the CoA contained in the binding update list
and no other CoA.
The same issue appears in 11.3.2 where it says:
destination option into the packet, replacing the Source Address
in the packet's IP header with a care-of address suitable for the
link on which the packet is being sent, as described in Section
11.3.1.
"with the care-of address used with this correspondent" is better once 11.3.1
has been fixed.
Minor issues:
-------------
Section 8.2 has a MUST for an administrative knob. We try to avoid mandating
knobs to make it easier to implement small devices.
Could this be a SHOULD instead?
Section 9.1. says:
Destination Cache [12]. That is, any Binding Cache entry for this
destination SHOULD take precedence over any Destination Cache entry
for the same destination.
I don't think "precedence" is the best way to describe this.
The binding cache provides information that a routing header be added,
but the destination cache is still consulted e.g. for path MTU information.
(In fact, when the CoA changes it would presumably be useful to carry the
path MTU from the destination cache entry for the old CoA to the destination
cache entry for the new CoA since it is likely to be a more robust starting
point than using the interface MTU on the correspondent.)
Section 9.3.4 says that the BCE SHOULD be deleted due to ICMP errors.
But packets with HAO can continue to arrive which will cause a Binding Error.
It makes sense to point out this downside in this section and leave the SHOULD
in place.
Section 9.4.3 talks about avoiding route optimization for HOT messages,
but there is no corresponding text about avoiding using HOA for HOTI messages
in section 11.
Is there something generic which can be said about applying HOA and RH type 2
to MH messages? I think the only case where RH type 2 makes sense and
should be allowed is for a bind ack when the BU was succesful.
If there isn't a generic rule that can be applied perhaps text should
be added in section 6 for the different MH types e.g.
A HOT message is never sent using RH type 2 even if there
is an existing binding, and HOA is never applied to a HOT message
since HOT messages bypass the binding update list; in essence
route optimization MUST NOT be applied to HOT messages.
and similarly for COT, HOTI, COTI, BU, and perhaps others.
That way the specific text in 9.4.3 can be removed and there isn't need
to add text elsewhere in section 9 or 11.
Does it make sense to explicitly state that RH type 2 and HAO must never
be applied to Neighbor Discovery packets? Or packets local to a link in
general?
Section 9.5.1 says:
o If the Alternate Care-of Address option is present, the care-of
address is the address in that option.
[...]
o Otherwise, the home address is the Source Address field in the
packet's IPv6 header. This implies that the mobile node is at
home and is about to perform de-registration.
The last sentence implicitly states that sending a BU with alt-coa and
no HAO is not allowed. If the intent is to forbid that combination
please make it explicit. Otherwise drop the last sentence.
Section 9.5.2 talks about the CN reducing the lifetime
of a binding. Given that the MN might continue sending packets with HAO
until the MN thinks the binding times out it seems unwise for the CN
to limit the lifetime unless it explicitly informs the MN by sending a BAck.
Section 9.5.4 states that Binding Acks don't use the Binding Cache.
Do they or do they not use the Binding Update List to determine whether
or not to add a HAO?
Section 10.3.1:
o Else, if the home address for the binding (the Home Address field
in the packet's Home Address option) is not an on-link IPv6
address with respect to the home agent's current Prefix List or if
the corresponding prefix was not advertised with the Home Agent
(H) bit set, then the home agent MUST reject the Binding Update
and SHOULD return a Binding Acknowledgement to the mobile node, in
which the Status field is set to 132 (not home subnet).
The H-bit is set in the RA and not for each prefix as this text assumes.
Is the intent just to say that "if the HA is not operating as a HA on that
interface"?
Section 10.6.1:
I question the wisdom of having HAs learn information to advertise
from other HAs on the link; normal routers do not do this so why do
HA have to be different in this respect?
To minimize the risk of bad effects if a MN moves from one HA to
another on the home link, why not have the HAs verify that the
other HAs on the link advertise the same list of prefixes and the same
M/O settings and log an event should they differ?
That would simplify section 10.6.1 quite significantly.
Section 10.6.2 says:
o The valid or preferred lifetime or the state of the flags changes
for the prefix of the mobile node's registered home address.
But when the lifetimes decrement in real time the above would become
true every second (the lifetime granularity).
I don't think that is the intent.
What is the intent?
Section 10.6.2 has:
MaxScheduleDelay = min (MaxMobPfxAdvInterval, Preferred Lifetime),
Is this the right thing to do even when a prefix is deprecated?
(i.e. it has a zero preferred lifetime).
Section 10.1 is not very clear that (and when) the Binding Update List
is used to add HAO to outgoing packets.
Compare with section 9.1 which is clear that the Binding Cache is
used to add a RH type 2.
(Presumably such a statement for HAO would have an exception clause as well
since there are packets to which HAO should not be added even there is
a BUL entry.)
I think the text should capture that when there is a BUL entry for the HoA
that is "current" (i.e. the CN has been informed of the latest CoA
and optionally the binding ack has been received) that precense of that
BUL entry means that packets can be sent directly to the CN with HAO added.
Some more discription on this front also help nail down the meaning
of "binding exists" and "aware that the CN already has a BCE" in section
11.3.1. In both those cases the "current" property is silently assumed.
Section 11.3.1 says:
reverse tunneling. Detailed operation for both of these cases is
described later in this section and also discussed in [29].
but I have no idea what detailed operation the default address selection
document offers for reverse tunneling vs. route optimization.
Did the last sentence get placed in the wrong part of the text?
Section 11.4.3 has:
o If a solicitation has been sent recently, the ICMP Identifier
value MUST be the same as in the solicitation.
which seems odd given that solicitations and advertisements might
cross in flight and "recently" is not well-defined.
Isn't the intent that if an advertisement matches the most recently
sent identifier value (and no advertisement has previously matched it)
the advertisement is considered to be solicited and is used to update the
state about the prefixes.
Otherwise the advertisement is considered to be unsolicited and
can only be used to trigger a (rate limited) solicitation?
If that is the case it doesn't make sense to have a MUST discard when
the ICMP identifier doesn't match.
Section 11.7.1 last sentence has a MAY while referring to some possible
future work in appendix B.5. This makes no sense since it isn't possible
to implement this until the work outlined in B.5 has resulted in a
specification. Thus this needs to be reworded to refer to this
as "Perhaps this can be solved in the future using the scheme outlined
in appendix B.5" or something along those lines.
Section 11.7.2:
In addition, when a mobile node receives a packet for which the
mobile node can deduce that the original sender of the packet has a
stale Binding Cache entry for the mobile node, the mobile node SHOULD
initiate a correspondent binding procedure.
How does a mobile node tell that the sender has stale info?
By the fact that the packet was not send to the MN?
Section 11.7.2:
o The packet does not contain a Care-of Test Init message.
Why is CoTI special? Aren't there other RR procedure messages that should
be subject to the same exclusion?
Section 11.7.2:
A mobile node MAY also choose to keep its location private from
certain correspondent nodes, and thus need not initiate the
correspondent binding procedure.
While the document uses "location" all over to refer to "topological location"
I think in a sentence about location privacy it would be good to spell
this out to avoid confusing this with geographical location privacy.
Section 11.7.2:
A Binding Update is created as follows:
o The Source Address of the IPv6 header MUST contain the current
care-of address of the mobile node.
Is use of alt-coa explicitly forbidden?
Section 11.7.3:
o If the Status field indicates that the Binding Update was rejected
(the Status field is greater than or equal to 128), then the
mobile node SHOULD record in its Binding Update List that future
Binding Updates SHOULD NOT be sent to this destination.
Optionally, the mobile node MAY then take steps to correct the
cause of the error and retransmit the Binding Update (with a new
Sequence Number value), subject to the rate limiting restriction
specified in Section 11.8.
I thought e.g. responding to 135-138 errors was more than optional.
Requiring that the MN give up (SHOULD NOT) is odd in any case.
Only if the MN either doesn't have a recourse or chooses not to
take optional recourse, is it the case that it SHOULD NOT send further BUs.
Section 11.8:
I assume that this retransmission behavior should apply to home agent discovery
as well. The document seems silent on such retransmissions.
Nits:
-----
Some IPv6 nodes might implement HAO and/or RH type 2 even if they do not
implement route optimization. Thus it would be useful to restate the
constraints for those found in section 8.2 under section 8.1 with a
"if an IPv6 node implements X it MUST ...".
Section 9.1 says:
o The home address of the mobile node for which this is the Binding
Cache entry. This field is used as the key for searching the
Binding Cache for the destination address of a packet being sent.
If the destination address of the packet matches the home address
in the Binding Cache entry, this entry SHOULD be used in routing
that packet.
It would be more clear if this had "except as noted in xxx"
because there are some cases in the return routability procedure
when the binding cache entry needs to be explicitly ignored.
The descriptions for the ICMP parameter problem errors do not specify
how to set the offset field in section 9.2:
o The Payload Proto field MUST be IPPROTO_NONE (59 decimal).
Otherwise, the node MUST discard the message and SHOULD send ICMP
Parameter Problem [14], Code 0, to the Source Address of the
packet.
with the offset pointing at the payload proto field.
o The Header Len field in the Mobility Header MUST NOT be less than
the length specified for this particular type of message in
Section 6.1. Otherwise, the node MUST discard the message and
SHOULD send ICMP Parameter Problem [14], Code 0, to the Source
Address of the packet.
with the offset pointing at the header len field.
In 9.2:
Mobile nodes are expected to include a Home Address destination
option in a packet they believe the correspondent node has a Binding
Cache entry for the home address of a mobile node. Packets
s/expected/can/ since they might choose to reverse tunnel
s/packet they/packet when they/
In 9.5.1:
o The Sequence Number field in the Binding Update is greater than
the Sequence Number received in the valid previous Binding Update
for this home address, if any.
s/valid previous/previous valid/
In 9.5.1
If the mobile node sends a sequence number which is not greater than
the sequence number from the last successful Binding Update, then the
I assume "succesful" should be "valid" since there is no definition of
what is a succesful BU.
In 9.5.1:
If the Binding Update is valid according to the tests above, then the
Binding Update is processed further as follows:
It would be good to explicitly state that the recorded sequence number
is updated from the binding update packet here.
Section 9.5.1 checks the H-bit earlier and then unnecessarily talks about
checking the H-bit in these paragraphs:
o If the Lifetime specified in the Binding Update is nonzero and the
specified care-of address is not equal to the home address for the
binding, then this is a request to cache a binding for the mobile
node. If the Home Registration (H) bit is set in the Binding
Update, the Binding Update is processed according to the procedure
specified in Section 10.3.1; otherwise, it is processed according
to the procedure specified in Section 9.5.2.
o If the Lifetime specified in the Binding Update is zero or the
specified care-of address matches the home address for the
binding, then this is a request to delete the mobile node's cached
binding. In this case, the Binding Update MUST include a valid
home nonce index, and the care-of nonce index MUST be ignored by
the correspondent node. The generation of the binding management
key depends then exclusively on the home keygen token (Section
5.2.5). If the Home Registration (H) bit is set in the Binding
Update, the Binding Update is processed according to the procedure
specified in Section 10.3.2; otherwise, it is processed according
to the procedure specified in Section 9.5.3.
Section 9.5.{1,2,3} talks about a a binding cache entry for a
mobile node when in
fact a binding cache entry is for a home address; a mobile node can have
multiple HoA each having a binding cache entry:
This might cause confusion. Suggest using "home address" instead.
Section 9.6 second paragraph (except first few words) and third paragraph
are about Home Agent behavior and is already covered in section 10; no need
to talk about that in the correspondent node section.
Section 9.6 fourth paragraph should point out that discarding a BCE before
it times out will cause packets with HAO to be dropped. Also add point
about keeping information around until the nonces used to create the BCE
have expired to prevent replays.
Section 10.3.1
home agent assures to the mobile node that its address(es) will
continue to be kept unique by the home agent at least as long as the
lifetime granted for the bindings is not over.
s/bindings is not over/binding/ (no "s")
In 10.4.4:
This section describes how home agents support the use of stateful
address autoconfiguration mechanisms such as DHCPv6 [28] from the
mobile nodes. If this support is not provided, then the M and O bits
must remain cleared on the Mobile Prefix Advertisement Messages. Any
mobile node which issues autoconfiguration queries for servers
without this support will not receive a response.
The "autoconfiguration queries" is odd. Is it supposed to mean "tries
to use DHCPv6"? Then I suggest saying so explicitly.
In 11.3.3:
While away from home, a mobile node will receive packets addressed to
its home address, by one of three methods:
I only count to two methods.
In 11.3.4:
1. Send directly on the foreign link being visited.
The application is aware of the care-of address and uses it for
multicast traffic just like any other stationary address. The
mobile node MUST NOT use Home Address destination option in such
traffic.
It would be helpful to add that the care-of address is used as the source
address in this case.
In 11.3.4 last paragraph it talks about reverse tunneling and
then covers performance issues about multicast packets tunneled
in the forward direction.
Saying "bidirectional" instead of "reverse" would be less confusing.
Section 11.5.4:
home address. In addition, when returning home prior to the
expiration of a current binding for its home address, and configuring
its home address on its network interface on its home link, the
mobile node MUST NOT perform Duplicate Address Detection on its own
home address, in order to avoid confusion or conflict with its home
agent's use of the same address. If the mobile node returns home
after the bindings for all of its care-of addresses have expired,
then it SHOULD perform DAD.
It makes sense to add that the MUST NOT also applies to performing
DAD on the link-local address when the L-bit was set in the BU.
In 11.6.1:
MAY record the same information in multiple Binding List entries.
Elsewhere this is called a binding update list.
Section 11.6.2:
mobile node SHOULD continue waiting for additional messages.
More clear to say "a CoT message" instead of "additional messages".
mobile node SHOULD continue waiting for additional messages.
More clear to say "a HoT message" instead of "additional messages".
Section 11.7.1:
value is received, because information learned through prefix
discovery on an earlier registration may have changed.
s/on/after/
Section 11.7.1:
If the mobile node has additional home addresses using a different
interface identifier, then the mobile node SHOULD send an additional
packet containing a Binding Update to its home agent to register the
care-of address for each such other home address (or set of home
addresses sharing an interface identifier).
The above seems like a carry-over from when multiple addresses
using the same interface ID could be updated in a single BU.
Suggest replace with:
If the mobile node has additional home addresses,
then the mobile node SHOULD send an additional
packet containing a Binding Update to its home agent to register the
care-of address for each such other home address.
Section 11.7.2:
Binding Update List. This is necessary in order to ensure that
correspondent nodes do not have invalid information about the current
location of the mobile node. The initiated procedures can be used to
s/invalid/stale/
Section 11.7.2 has:
If set to one of the mobile node's current care-of addresses, the
Binding Update requests the correspondent node to create or update an
entry for the mobile node in the correspondent node's Binding Cache
in order to record this care-of address for use in sending future
packets to the mobile node. In this case, the value specified in the
"set" makes no sense. But even replacing it with "sent" doesn't
make sense since BUs aren't sent to MNs.
Is the intent "sent to correpondent to create or update a binding cache entry"?
Section 11.7.2:
If the mobile node wants to ensure that its new care-of address has
been entered into a correspondent node's Binding Cache, the mobile
node MAY request an acknowledgement by setting the Acknowledge (A)
bit in the Binding Update. In this case, however, the mobile node
The "If ... MAY " construction doesn't make sense.
s/MAY/needs to/
In 15.4.1:
ability of attackers to see these nonces. For instance, this
prevents attacks launched from the mobile node's current foreign
link where no link-layer confidentiality is available.
s/where/even when/
In 15.4.3:
In contrast, an attacker who uses only plain IPv6 generally has to be
stay on the link in order to continue the attack. Note that in order
s/has to be stay/has to stay/
In 15.4.3:
vulnerability. This limited vulnerability can also be compared to
similar vulnerabilities in IPv6 Neighbor Discovery, with Neighbor
Cache entries having a limited lifetime.
Neighbor cache entries have no limited lifetime. They can be garbage
collected, and NUD will remove ones with stale information should
they be used. So I suggest you strike the last sentence.
Section 9.3.1:
No additional authentication of the Home Address option is required,
except that if the IPv6 header of a packet is covered by
authentication, then that authentication MUST also cover the Home
Address option; this coverage is achieved automatically by the
s/authentication/IPsec Authentication Header/ at least for the first occurance.
to the packet's final destination, and thus the option is included in
the authentication computation. By requiring that any authentication
s/authentication/AH/
When attempting to verify authentication data in a packet that
contains a Home Address option, the receiving node MUST calculate the
authentication data as if the following were true: The Home Address
s/authentication/AH authentication/
Section 9.3.2:
of its care-of address. When calculating authentication data in a
packet that contains a type 2 routing header, the correspondent node
MUST calculate the authentication data as if the following were true:
s/authentication/AH authentication/
Section 15.8:
No special authentication of the Home Address option is required
beyond the above, except that if the IPv6 header of a packet is
covered by authentication, then that authentication MUST also cover
s/covered by authentication/covered by IPsec Authentication Header/
---