[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [mobile-ip] Last Call: Mobility Support in IPv6 to ProposedStandard
Hello,
On Thu, 23 Jan 2003, The IESG wrote:
> The IESG has received a request from the IP Routing for Wireless/Mobile
> Hosts Working Group to consider Mobility Support in IPv6
> <draft-ietf-mobileip-ipv6-20.txt> as a Proposed Standard.
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send any comments to the
> iesg@ietf.org or ietf@ietf.org mailing lists by 2003-2-6.
I had hoped to complete the reading and commentary before the last call
and the publication of -20, but didn't manage to do so, unfortunately.
The spec is so long :-/.
Anyway, below are the comments I wrote down during the read. I tried to
put them down to separate categories, but the line between them is quite
flaky. Don't chew too long on them, there are probably lots of bugs in
the comments -- if in doubt, ask or ignore :-)
I don't think this is ready yet to be published, probably like 2-3 rounds
is still required (not that those rounds couldn't be done pretty quick if
so).
...
The big picture
===============
1) When reading the spec, Dynamic Home Agend Address Discovery mechanism
and Mobile Prefix Advertisements struck as something that have come in as
a feature creep at some point. The main point of these mechanisms seems
to be to cope with changing the IP addresses or changes in topology of the
home agents/home link. This doesn't seem to be a required base feature of
the protocol to me -- useful in some ways due to mobility, of course, but
not required. Off-band reconfiguration would be entirely ok for now too.
If these bring complexity, they could be removed to their own specs and/or
simplified here. Reconfiguration of the home link is not an easy issue!
(one particular issue that struct me as "Oh no!" in mobile prefix
advertisements was the aggregation/data collection of advertisements by the
home agent. Was it ever considered that MN could be required to have HA to
more than one HA on the same link (if more than one are present?)
2) I find the special NS (sect 7.5) hack disturbing. I'm not entirely sure
why this is needed, and why it couldn't be worked around. I recall that
this is needed in some special cases such as returning home while home agent
is being booted and there are multiple home agents or something. Call that
rare? Of course, nicer ways to deal with this would maybe be possible, like
specifying which data must (or must not be) preserved across reboots, or
generating an RFC3041 address for the returning MN which would be used for
sending a BU signalling "hello, I'm back!".
Major issues
============
1)
When the mobile node has received both the Home and Care-of Test
messages, the return routability procedure is complete. As a result
of the procedure, the mobile node has the data it needs to send a
Binding Update to the correspondent node. The mobile node hashes the
tokens together to form a 20 octet binding key Kbm:
Kbm = SHA1 (home keygen token | care-of keygen token)
==> a hash of 128 bits generates a 160-bit key? Is this enough entropy for
this algorithm?? Perhaps this is ok (I don't know how well those hashing
algorithms work with this little input), but if so, the reasoning
should be mentioned explicitly somewhere (e.g. security considerations?)
In this case, the care-of keygen token is not used.
Instead, the binding management key is generated as follows:
Kbm = SHA1(home keygen token)
==> 64 bits -> 160 bits, see above
2)
The Alternate Care-of Address option is valid only in Binding Update.
The Alternate Care-of Address field contains an address to use as the
care-of address for the binding, rather than using the Source Address
of the packet as the care-of address.
==> One should consider having a better roadmap of different care-of address
usage scenarios. To me, this ACoA option seemed a bit puzzling at least.
3)
The Source Address of the Home Agent Address Discovery Request
message packet is typically one of the mobile node's current care-of
addresses. At the time of performing this dynamic home agent address
discovery procedure, it is likely that the mobile node is not
registered with any home agent. Therefore, neither the nature of the
address nor the identity of the mobile node can be established at
this time. The home agent MUST then return the Home Agent Address
Discovery Reply message directly to the Source Address chosen by the
mobile node.
==> issues about possible subnets where prefixlen is longer than 64, as
noted by draft-savola-ipv6-127-prefixlen-04. Should there be an explicit
restriction (somewhere) to use DHAAD only if the prefix length is 64?
4)
8.2 IPv6 Nodes with Support for Route Optimization
Nodes that implement route optimization are a subset of all IPv6
nodes on the Internet. The ability of a correspondent node to
participate in route optimization is essential for the efficient
operation of the IPv6 Internet, for the following reasons:
==> should there also be a section why route optimization is non-essential
or bad, for balance?
and:
o Reduced network load across the entire Internet, as mobile devices
begin to predominate. At the time this is being written, laptop
computers already outsell desktops and wireless telephones far
outsell laptops.
==> I'm not sure if the last sentece is relevant to a technical
specification.
5) something about upper-case keywords..
o The node MUST allow route optimization to be administratively
enabled or disabled. The default SHOULD be enabled.
==> is MUST a bit strong (e.g. consider appliances that may not have any
config knobs). Perhaps a reword: "If node defaults to enabling route
optimization, there MUST be a way to administratively disable it", though
I'm not sure if that's optimal either.
o Every IPv6 router SHOULD be able to send an Advertisement Interval
option (Section 7.3) in each of its Router Advertisements [12], to
aid movement detection by mobile nodes (as in Section 11.5.1).
The use of this option in Router Advertisements MUST be
configurable.
==> as above, I personally like a MUST but it seems a bit strong, for _all_
routers..?
o Every IPv6 router SHOULD be able to support sending unsolicited
multicast Router Advertisements at the faster rate described in
Section 7.6. The use of this faster rate MUST be configurable.
==> see above
o Filtering routers SHOULD support different rules for type 0 and
type 2 routing headers (see Section 6.4) so that filtering of
source routed packets (type 0) will not necessarily limit Mobile
IPv6 traffic which is delivered via type 2 routing headers.
==> I'd reword this as "Routers supporting filtering packets with routing
headers SHOULD support different ...".
o The node MUST support receiving a Binding Error message (Section
11.3.6).
o The node SHOULD support receiving ICMP errors (Section 11.3.5).
==> I find it strange that this is a SHOULD for mobile nodes, but a feature
that will be used by most IPv6 nodes -- it's a MUST, no debate about it!
Binding Error messages are subject to rate limiting in the same
manner as is done for ICMPv6 messages [14].
==> should there be a SHOULD/MUST keyword here?
Packets addressed to
the mobile node's site-local address SHOULD NOT be tunneled to the
mobile node by default, but this behavior MUST be configurable to
enable it; currently, the exact definition and semantics of a "site"
and a site-local address are incompletely defined in IPv6, and this
default behavior might change at some point in the future.
==> MUST for a config knob like this seems too harsh a requirement to me,
a required knob to enable site-locals? Come on..
multicast recipients). Multicast packets addressed to a multicast
address with scope larger than link-local but smaller than global
(e.g., site-local and organization-local [3]), to which the mobile
node is subscribed, SHOULD NOT be tunneled to the mobile node by
default. This behavior MUST be configurable to allow it to be
enabled.
==> again, a rather harsh requirement.
such queries will generally have a lower overhead than using the
mobile node's home address, since no extra options need be used in
either the query or its reply. Such packets can be routed
normally, directly between their source and destination without
relying on Mobile IPv6. If application running on the mobile node
has no particular knowledge that the communication being sent fits
within this general type of communication, however, the mobile
node SHOULD NOT use its care-of address as the source of the
packet in this way.
==> I don't think it is appropriate to use upper-case normatives for
specification when MIPv6 usability is concerned (esp. SHOULD NOT);
thus remove the caps?
For packets received by the first of these methods, the mobile node
MUST check that the IPv6 source address of the tunneled packet is the
IP address of its home agent. In this method the mobile node SHOULD
also send a Binding Update to the original sender of the packet, as
described in Section 11.7.2, subject to the rate limiting defined in
Section 11.8.
==> as previously stated, I find it unacceptable to specify this "SHOULD do
RO" in upper-caps. Reverse tunneling can be totally OK. People will start
doing RO if it makes sense for them, period -- no spec forcing is necessary.
On some types of network interfaces, the mobile node MAY also
supplement this monitoring of Router Advertisements, by setting its
network interface into "promiscuous" receive mode, so that it is able
to receive all packets on the link, including those not addressed to
it at the link layer (i.e., disabling link-level address filtering).
The mobile node will then be able to detect any packets sent by the
router, in order to detect reachability from the router. This use of
promiscuous mode may be useful on very low bandwidth (e.g., wireless)
links, but its use MUST be configurable on the mobile node since it
==> the MUST requirement needs re-phrasing. "If it is enabled by defaults,
its use MUST be configurable..." ?
6)
to the Source Address. Unlike the treatment of regular packets, this
addressing procedure does not use information from the Binding Cache.
However, a routing header is needed in some cases. If the Source
Address is the home address of the mobile node, i.e., the Binding
Update did not contain a Home Address destination option, then the
Binding Acknowledgement MUST be sent to that address, and the routing
header MUST NOT be used. Otherwise, the Binding Acknowledgement MUST
be sent using a type 2 routing header which contains the mobile
node's home address.
==> the latter case seems strange. Consider e.g. a BU with HAO option for
which CN replies with BA expired nonces (or something like that),
what use is it to use routing header to send that back to the MN?
Rather, it could be much more robust to
just by default push everything to the home address, and have them reverse
tunneled to the MN.
7)
Regardless of the setting of the Acknowledge (A) bit in the Binding
Update, the home agent MUST return a Binding Acknowledgement to the
mobile node, constructed as follows:
==> there seem to be some confusion throughout the draft on when exactly
BA's are sent. This surely does not reflect to the general overview in the
first chapters ("if requested"). Some roadmap should be nice?
o The state of any retransmissions needed for this Binding Update,
if the Acknowledge (A) bit was set in this Binding Update. This
state includes the time remaining until the next retransmission
attempt for the Binding Update, and the current state of the
exponential back-off mechanism for retransmissions.
==> not necessarily a question to be answered here, but is this
retransmission mechanism also valid for other kind of BU's which MUST be
acknowledged (like home registrations, IIRC) -- ie, ones where BA should be
received?
8)
As described in Section 11.4.1, a mobile node attempts dynamic home
agent address discovery by sending an ICMP Home Agent Address
Discovery Request message to the Mobile IPv6 Home-Agents anycast
address [16] for its home IP subnet prefix. A home agent receiving
such a Home Agent Address Discovery Request message that is serving
this subnet SHOULD return an ICMP Home Agent Address Discovery Reply
message to the mobile node, with the Source Address of the Reply
packet set to one of the global unicast addresses of the home agent.
==> this, or section 11.4.1 does not discuss the security implications (or
lack thereof) by enabling unchecked DHAAD from everywhere for all subnets
you can guess. This is briefly noted in the security considerations though.
Could be a useful feature for mapping Home agents/network infrastructure
in the Internet, one packet per subnet only.
9)
[...]
o Among home agents with equal preference, their IP addresses in the
Home Agent Addresses field SHOULD be listed in an order randomized
with respect to other home agents with equal preference, each time
a Home Agent Address Discovery Reply message is returned by this
home agent.
o If more than one global IP address is associated with a home
agent, these addresses SHOULD be listed in a randomized order.
==> these 3 bullets seem rather redundant optimizations to me. A MN cannot
depend on them being done (SHOULD's), so it must implement same preference
ordering functions itself anyway! This seems only useful when the number of
used items exceed MTU, and in that case, even simpler clipping could be
used.
10)
11.5 Movement
11.5.1 Movement Detection
==> one thing that may have to be considered is, when MN moves on to a new
link, or detects it's also on range of a different link, should it re-perform
DAD for _already existing_ addresses? If so, on which addresses (probably
link link-locals/site-locals would be enough).
This is a new situation brought by movement.
11)
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
SHOULD NOT continue to retransmit the Binding Update once the
retransmission timeout period has reached MAX_BINDACK_TIMEOUT.
The mobile node SHOULD create a Binding Update as follows:
==> Shouldn't this be a MUST (or remove upper case normative completely)?
Or can you create it differently? Note that this list does not restrict
any additional options. If not,
you could separate the cases "this is how BU MUST be created" and "this is
why BU should be sent at all if to be created".
12)
The vulnerabilities for off-path attackers are the same as in regular
IPv6. Those nodes that are not on the path between the home agent
and the correspondent node will not be able to receive the probe
messages.
==> the last sentence is not entirely accurate. Was it really meant to say that
probe messages cannot be received unless you're on path HA<->CN,
_not_ MN<->HA _or_ MN<->CN (care-of test init could be considered as a probe
IMO).
Substantial/semi-editorial issues
=================================
o In Mobile IPv6, the mobile node does not have to tunnel multicast
packets to its home agent.
==> this is not really true anymore.
o The dynamic home agent address discovery mechanism in Mobile IPv6
returns a single reply to the mobile node. The directed broadcast
approach used in IPv4 returns separate replies from each home
agent.
==> btw, does directed broadcast approach in v4 even work if "no ip
directed-broadcast" or the like has been configured?
While a mobile node is attached to some foreign link away from home,
it is also addressable at one or more care-of addresses. A care-of
address is an IP address associated with a mobile node that has the
subnet prefix of a particular foreign link. The mobile node can
acquire its care-of address through conventional IPv6 stateless or
stateful auto-configuration mechanisms.
==> manual configuration is probably also okay..?
A Binding Update may also be used to delete a previously established
binding by setting the care-of address equal to the home address
(Section 6.1.7).
==> according to section 6.1.7, deletion can also happen if lifetime is set
to zero, and then Kbm is calculated as follows.
* Source Address = care-of address
* Destination Address = correspondent
* Parameters:
+ home address (within the Home Address destination option or
in the Source Address)
==> above it says "Source Address = care-of address" so "or in the Source
Address" looks redundant?
response. However, the correspondent node MUST NOT accept nonces
beyond MAX_NONCE_LIFE seconds (see Section 12) after the first use.
As the difference between these two constants is 30 seconds, a
convenient way to enforce the above lifetimes is to generate a new
nonce every 30 seconds.
==> is it appropriate to discuss the difference between two constants
defined in section 12 _here_? (ie. if they're changed in sect 12, the
difference may not be 30 seconds anymore.)
It seems good for clarity at least..
following the Mobility Header. Uses the same values as the IPv6
Next Header field [11].
This field is intended to be used by a future specification of
piggybacking binding messages on payload packets (see Appendix
B.1). Implementations conforming to this specification SHOULD set
the payload protocol type to IPPROTO_NONE (59 decimal).
==> Shouldn't this be better named "Next Header"? (Possibly remove the
discussion about piggy-backing too)
The pseudo-header contains IPv6 header fields, as specified in
Section 8.1 of RFC 2460 [11]. The Next Header value used in the
pseudo-header is TBD <To be assigned by IANA>. The addresses used
in the pseudo-header are the addresses that appear in the Source
and Destination Address fields in the IPv6 packet carrying the
Mobility Header. Note that the procedures described in Section
11.3.1 apply even for the Mobility Header.
==> s/procedures/procedures of sending packets while away from home/ for
readability? or if the subsequent sentences describe it adequately, then
replace e.g. s/Mobility Header. If/Mobility Header: if/ or the like.
Mobility Options
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. Contains zero or
more TLV-encoded mobility options. The encoding and format of
defined options are described in Section 6.2. The receiver MUST
ignore and skip any options which it does not understand.
==> I'm all for simplicity for now, but does this provide enough flexibility
for the future? That is, should one define the option types like with
destination options that some values would be skipped and ignored, some not?
In the former case, introduction of widely used mobility options would
probably require some kind of acknowledgement messages if you cannot be sure
the options were understood...
, the protocol used for establishing the IPsec
security associations between the mobile node and the home agent
does not survive movements. It may then have to be rerun. (Note
that the IPsec security associations themselves are expected to
survive movements.) If manual IPsec configuration is used, the bit
MUST be set to 1.
This bit is valid only in Binding Updates sent to the home agent.
Correspondent nodes MUST ignore this bit.
==> and MN's MUST NOT send it CN's (must seems like a slight overkill
though), right? (not sure if it's worth noting it here, though.)
* Binding Authorization Data option
* Nonce Indices option.
* Alternate Care-of Address option
If no options are present in this message, 4 bytes of padding is
necessary and the Header Len field will be set to 1.
==> uhh, in above it said that it must always contain one or more options,
and the sentence above is useless?
Lifetime
The granted lifetime, in time units of 4 seconds, for which this
node SHOULD retain the entry for this mobile node in its Binding
Cache. A value of all one bits (0xffff) indicates infinity.
The value of this field is undefined if the Status field indicates
that the Binding Update was rejected.
==> whole lifetime field in ack seems redundant to me, especially now that
in most cases BU's aren't even acknowledged. If BU's would be typically
acknowledged, this could be useful to indicate when to resend the BU for
long connections (if CN's typically have shorter lifetimes for bindings
than as limit requested in BU).
Or, can CN still send a BA even if not requested by A-bit in BU? If so, the
text in 5.2.6 should perhaps be updated a bit; it gave me the impression
that BA would be sent basically only if requested by A-bit..
So, with current BU lifetime semantics, this seems a bit redundant.. but I
guess it's no big deal as BA's aren't sent that often..
* Binding Authorization Data option
* Binding Refresh Advice option
If no options are present in this message, 4 bytes of padding is
necessary and the Header Len field will be set to 1.
==> yet again, above it says one or more options are present..
Status
8-bit unsigned integer indicating the reason for this message.
The following values are currently defined:
1 Unknown binding for Home Address destination option
2 Unrecognized MH Type value
==> tlv notation would be better if 2) is common because then redundant Home
Address is tranmitted? On the other hand, otherwise you'd probably require
extra padding for 1).
The first 96 bits from the MAC result are used as the Authenticator
field. Note that, if the message is sent to a destination which is
itself mobile, the "final dest" address may not be the address found
in the Destination Address field of the IPv6 header; instead the
address of the true destination (e.g., its home address) should be
used.
==> refer to section XXX on destination address selection?
6.2.5 Alternate Care-of Address
The Alternate Care-of Address option has an alignment requirement of
8n+6. Its format is as follows:
==> is this alignment requirement expression format commonplace? It wasn't
100% intuitive to me at least.
IPv6 requires that options appearing in a Hop-by-Hop Options header
or Destination Options header be aligned in a packet so that
multi-octet values within the Option Data field of each option fall
on natural boundaries (i.e., fields of width n octets are placed at
an integer multiple of n octets from the start of the header, for n =
1, 2, 4, or 8) [11]. The alignment requirement [11] for the Home
Address option is 8n+6.
==> this notation has already been used a few times in previous option
types, move it there? (see above.)
Home agents MUST include the Source Link-Layer Address option in all
Router Advertisements they send.
==> an addional sentence/reference justifying this would be nice.
Any IPv6 node may at any time be a correspondent node of a mobile
node, either sending a packet to a mobile node or receiving a packet
from a mobile node. There are no Mobile IPv6 specific MUST
requirements for such nodes, and basic IPv6 techniques are
sufficient. If a mobile node attempts to set up route optimization
with a node with only basic IPv6 support, an ICMP error will signal
that the node does not support such optimizations, and communications
will flow through the home agent.
==> has this kind of signalling been tested? does it work?
Add a reference to 10.3.5?
9.1 Conceptual Data Structures
IPv6 nodes with route optimization support maintain a Binding Cache
of bindings for other nodes. A separate Binding Cache SHOULD be
maintained by each IPv6 node for each of its IPv6 addresses.
==> s/addresses/unicast routable addresses/ ...?
o A flag indicating whether or not this Binding Cache entry is a
home registration entry.
==> is this applicable for MN's, CN's or HA's only?
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.
o The checksum must be verified as per Section 6.1. Otherwise, the
node MUST silently discard the message.
==> is it important in which order these rules are processed? One could
argue checksum verification should go first.
9.4.3 Sending Home Test Messages
The correspondent node creates a home keygen token and uses the
current nonce index as the Home Nonce Index. It then creates a Home
Test message (Section 6.1.5) and sends it to the mobile node at the
latter's home address. Note that the Home Test message is always
sent to the home address of the mobile node, even when there is an
existing binding for the mobile node.
==> the last sentence seems to make no sense. If there would be an existing
binding, it would still be sent to the home address! Is the intention to
say _which_ home address Home Test will be sent to, in case a binding has
one and the Home Init Test has another as source address? Or should the
discussion have been under care-of test message?
o L=1: Defend both the given non link-local unicast (home) address
and the derived link-local.
==> note, I don't believe it's stated anywhere what this "derivation" is;
its apparent intention is clear though.
packets on the home link addressed to the mobile node's home address.
==> this is different what it says in the first paragraph of this section.
Addressed to the MN != w/ MN's home address. The former implies also
capturing link-local packets, the latter not. Are link-local unicast
messages (like NUD) captured? Make it clearer!
10.3.2 Primary Care-of Address De-Registration
==> would it be useful to say here that this is only(?) used when the MN
returns home. It would make some of the later comments easier to
understand.
o The Key Management Mobility Capability (K) bit is set or reset,
and actions based on its value are performed as described in the
previous section. The mobile node's home address is used as its
new care-of address.
==> the last sentence seems quite confusing. care-of address for the
purposes of what? (but see above)
However, packets addressed to the mobile node's link-local address
MUST NOT be tunneled to the mobile node. Instead, such a packet MUST
be discarded, and the home agent SHOULD return an ICMP Destination
Unreachable, Code 3, message to the packet's Source Address (unless
this Source Address is a multicast address).
==> some of this text should be moved up to 10.4.1 at least, if not also
earlier.
All MLD packets are sent directly between the mobile node and the
home agent. Since these packets all contain a link-local source
address,
==> this is not true when bootstrapping: the source can also be the
unspecied address, as described in draft-ietf-magma-mld-source; but this
doesn't really matter (just being pedantic :-).
o The tunnel entry point is the primary care-of address as
registered with the home agent and the tunnel exit point is the
home agent.
o When a home agent decapsulates a tunneled packet from the mobile
node, the home agent MUST verify that the Source Address in the
tunnel IP header is the mobile node's primary care-of address.
Otherwise any node in the Internet could send traffic through the
home agent and escape ingress filtering limitations.
==> there seems to be some overlap with the last two bullets?
Prefix Information option has the autonomous address configuration
(A) flag set and the prefix length is valid for address
autoconfiguration on the home subnet, add these advertisements and
preserve the on-link (L) flag value. Clear the Router Address (R)
flag and zero the interface-id portion of the prefix field to
prevent mobile nodes from treating another router's interface
address as belonging to the home agent. Treat the lifetimes of
these prefixes as decrementing in real time, as defined in Section
6.2.7 of RFC 2461 [12].
==> what's meant by "prevent mobile nodes ..." sentence? I believe the
prefix information in RA's already have the interface ID part set to
zero..?
Each Binding Update List entry conceptually contains the following
fields:
o The IP address of the node to which a Binding Update was sent. If
the Binding Update was successfully received by that node (e.g.,
not lost by the network), a Binding Cache entry may have been
created or updated based on this Binding Update. The Binding
Cache entry may still exist, if that node has not deleted the
entry before its expiration for some reason.
==> how is other than the first sentence relevant for the Binding Update List?
Should be tailed down a bit, it seems to me.
For packets sent by a mobile node while it is at home, no special
Mobile IPv6 processing is required. Likewise, if the mobile node
uses any address other than any of its home addresses as the source
of a packet sent while away from home no special Mobile IPv6
processing is required. In either case, the packet is simply
addressed and transmitted in the same way as any normal IPv6 packet.
==> this paragraph is unnecessary, considering the paragraph title ("away
from home") but I guess ok for clarity.
Direct Delivery
==> IMO the title is misleading ("Route Optimization"?)
and this subsection does not mention binding updates at all..!
This manner of delivering packets does not require going through
the home network, and typically will enable faster and more
reliable transmission.
==> I would not say "faster" here, not at all. In the long term, yes, but
otherwise no.
This is the mechanism which tunnels the packets via the home
agent. It isn't as efficient as the above mechanism, but is
needed if there is no binding yet with the correspondent node.
Specifically:
* The packet is sent to the home agent using IPv6 encapsulation
[15].
==> this does not give any references to the packet inside the
encapsulation.
processing is performed on the packet, initializing the
Authentication Data in the IPsec header. The AH authentication
data MUST be calculated as if the following were true:
* the IPv6 source address in the IPv6 header contains the mobile
node's home address,
* the Home Address field of the Home Address destination option
(Section 6.3) contains the new care-of address.
==> to be clear, does this require special case processing in IPsec code for
Mobile IPv6? Is this feature already in IPsec specs? Should be clearer.
o This allows, but does not require, the receiver of the packet
containing a Home Address destination option to exchange the two
fields of the incoming packet, simplifying processing for all
subsequent packet headers. However, such an exchange is not
required, as long as the result of the authentication calculation
remains the same.
==> I don't quite get what this says. I don't see how authentication
calculation could be the same in cases that 1) src=A, hao=B, and 2) src=B,
hao=A. That would be a big bug?
[...]
o The Home Address field in the routing header is one of the node's
home addresses, if the segments left field was 1. Thus, in
particular the address field is required to be a unicast routable
address.
Once the above checks have been performed, the node swaps the IPv6
destination field with the Home Address field in the routing header,
decrements segments left, and resubmits the packet to IP for
processing the next header.
==> I'd recommend removing the special casing for "segments left = 0 when
receiving -implementations" from the two bullets above,
as it finally all breaks down here -- segments left=255 due to wrapping?
node must join that multicast group. One method by which a mobile
node MAY join the group is via a (local) multicast router on the
foreign link being visited. In this case, the mobile node MUST NOT
use its home address or the Home Address destination option when
sending MLD packets [17]
==> s/[17]/[17]./
==> also, in that case, I don't think MN should use HAO when sending
_actual_ multicast packets either _anymore_ using a _local_ multicast router..
Just better to phase it is "MUST use its care-of address [...]".
If, after a mobile node transmits a Home Agent Address Discovery
Request message to the Home Agents Anycast address, it does not
receive a corresponding Home Agent Address Discovery Reply message
within INITIAL_DHAAD_TIMEOUT (see Section 12) seconds, the mobile
node MAY retransmit the same Request message to the same anycast
address. This retransmission MAY be repeated up to a maximum of
DHAAD_RETRIES (see Section 12) attempts. Each retransmission MUST be
delayed by twice the time interval of the previous retransmission.
==> hey come on, if anybody didn't reply at first, do you really think they
would for the 5th time? If this is really needed, make that e.g. 2-3
retransmissions and delay of 30 sec (to cope with reboots if that's deemed
necessary), possibly except the first retransmission.
As described in Section 4, in order to form a new care-of address, a
mobile node MAY use either stateless [13] or stateful (e.g., DHCPv6
[29]) Address Autoconfiguration. If a mobile node needs to send
packets as part of the method of address autoconfiguration, it MUST
use an IPv6 link-local address rather than its own IPv6 home address
as the Source Address in the IPv6 header of each such
autoconfiguration packet.
==> note that, in the first DAD packet, source can also be the unspecified
address.
11.5.4 Returning Home
A mobile node detects that it has returned to its home link through
the movement detection algorithm in use (Section 11.5.1), when the
mobile node detects that its home subnet prefix is again on-link.
==> is a router advertisement received through a VPN to the home link
considered being home?
A mobile node that initiates a return routability procedure MUST send
(in parallel) a Home Test Init message and a Care-of Test Init
messages. However, if the mobile node has recently received one or
both home or care-of keygen tokens, and associated nonce indices for
the desired addresses, it MAY reuse them. Therefore, the return
routability procedure may in some cases be completed with only one
message pair. It may even be completed without any messages at all,
if the mobile node has a recent home keygen token and and has
==> please define "recent", I believe there are even constants for that
somewhere!
previous home agent is still defending the existing binding.
Therefore, mobile nodes that use home agent address discovery
SHOULD ensure information about their bindings is not lost,
de-register before losing this information, or use small
lifetimes.
==> a possible fix here would be be the secondary HA's reporting back this
defending is being in progress by home agent X, so MN would know that it
should contant HA X. But I'm not sure if it's worth the complexity now..
17. Acknowledgements
We would like to thank the members of the Mobile IP and IPng Working
Groups for their comments and suggestions on this work. We would
particularly like to thank (in alphabetical order) Fred Baker
(Cisco), Josh Broch (Carnegie Mellon University), Samita Chakrabarti
==> typically, I don't think organizations are acknowledged in the IETF like
this, but I'm ok with it.
Trivial editorial issues
========================
security association
An IPsec security association is a simplex "connection" that
affords security services to the traffic carried by it. Security
services are afforded to a security association by the use of the
AH and ESP protocols.
==> "afford" sounds strange to me, reword?
destination option
Destination options are carried by the IPv6 Destination Options
extension header. Destination options include optional
information that need be examined only by the IPv6 node given as
the destination address in the IPv6 header, not by other
intermediate routing nodes. Mobile IPv6 defines one new
destination option, the Home Address destination option (see
Section 6.3).
==> "other intermediate routing nodes" is an ambiguous referral ("other,
intermediate nodes"?).
4.1 Basic Operation
A mobile node is always expected to be addressable at its home
address, whether it is currently attached to its home link or is away
from home. The "home address" is an IP address assigned to the
mobile node within its home subnet prefix on its home link.
==> home subnet prefix and home link definitions are circular; only one
req'd?
Bindings established with correspondent nodes using keys created by
way of the return routability procedure MUST NOT exceed
MAX_RR_BINDING_LIFE seconds (see Section 12).
==> s/LIFE/LIFETIME/, and the same for other variables ending with _LIFE ?
outer IP address corresponds to the current location of the mobile
node (Binding Updates sent to the home agents are secure). The home
agent identifies the mobile node through the source address of the
inner packet.(Typically, this is the home address of the mobile node,
==> s/.(/. (/
There MAY be additional information, associated with this Binding
Refresh Request message, that need not be present in all Binding
==> s/,//
Key Management Mobility Capability (K)
If this bit is reset
==> "reset" is perhaps a bit unoptimal wording, "cleared"/"zero"? (similar
in a few other places of the document)
Mobility Options
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. Contains one or
more TLV-encoded mobility options. The encoding and format of
defined options are described in Section 6.2. The receiver MUST
ignore and skip any options which it does not understand.
==> s/Contains/It contains/ (same for a few other places)
Reserved
32-bit reserved field. Initialized to zero for transmission, and
ignored on reception.
==> different wording for MBZ as previous definitions, not that it matters
that much..
Internet-Draft Mobility Support in IPv6 January 2003
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
==> figures should not be split to two pages, but I guess there's not much
to be done about it (except when at rfc editor)
8.4 IPv6 Home Agents
In order for a mobile node to operate correctly while away from home,
at least one IPv6 router on the mobile node's home link must function
==> circular definition again, but may be ok for clarity?
o Every home agent SHOULD support sending ICMP Mobile Prefix
Advertisements (Section 6.8), and SHOULD respond to Mobile Prefix
Solicitations (Section 6.7). This behavior MUST be configurable,
so that home agents can be configured to avoid sending such Prefix
Advertisements according to the needs of the network
administration in the home domain.
==> s/This behaviour/If supported, this behaviour/ ?
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:
The routing header contains the care-of address, the destination IPv6
address field of the IPv6 header contains the home address, and the
Segments Left field is zero. The IPsec Security Policy Database look
MUST based on the mobile node's home address.
==> s/look/lookup/ (or look up)
o L=0: Defend the given address.
==> s/ / /
o Cookie values used the Home Test Init and Care-of Test Init
messages.
==> s/used/used in/ ?
* The Source Address in the tunnel packet is the primary care-of
address as registered with the home agent.
* The Destination Address in the tunnel packet is the home
agent's address.
==> add here, at the end, something like "Then, the home agent will pass the
encapsulated packet to the correspondent node."
11.3.3 Receiving Packets While Away from Home
While away from home, a mobile node will receive packets addressed to
its home address, by one of three methods:
o Packets sent by a correspondent node that does not have a Binding
Cache entry for the mobile node, will be tunneled to the mobile
node via its home agent.
==> reword for clarity, e.g.: "... for the mobile node, will be sent to the
home address, captured by the home agent and tunneled to the mobile node."
prefix. As described in Section 10.5, the home agent on its home
link that receives this Request message will return an ICMP Home
Agent Address Discovery Reply message, giving the global unicast IP
addresses for the home agents operating on the home link
==> s/link/link./
If the mobile node has a current registration with some home agent on
its home link (the Lifetime for that registration has not yet
==> s/on its home link// (seems redundant by the definition of home agent)
expired), then the mobile node MUST attempt any new registration
first with that home agent. If that registration attempt fails
(e.g., times out or is rejected), the mobile node SHOULD then
reattempt this registration with another home agent on its home link.
==> s/on its home link// (as above)
The mobile node SHOULD also mark its link-local address as tentative,
and follow standard Duplicate Address Detection procedures[13].
==> s/[13]/ [13]/
to learn the home agent's link-layer address, since the home agent
will be currently configured to intercept packets to the mobile
node's home address for Duplicate Address Detection (DAD). In
==> s/for/using/
The mobile node then sends its Binding Update using the home agent's
link-layer address, instructing its home agent to no longer serve as
a home agent for it. By processing this Binding Update, the home
==> s/using/to/ or if that's not the intent, clarify!
This procedure also protects against Denial-of-Service attacks in
which the attacker pretends to be a mobile, but uses the victim's
address as the care of address. This would cause the correspondent
node to send the victim some unexpected traffic. The procedure
defends against these attacks by requiring at least passive presence
of the attacker at the care-of address or on the path from the
correspondent to the care of address. Normally, this will be the
mobile node.
==> s/care of/care-of/ (and elsewhere if applicable)?
just the interception of a few packets, whereas in regular IPv6 it is
necessary to intercept every packet. The effect of the attacks is
the same regardless of the method, however. In any case, the most
difficult task attacker faces in these attacks is getting to the
right path.
==> s/getting to/getting on/ ?
15.4.4 Return Routability Replays
The return routability procedure also protects the participants
against replayed Binding Updates. The attacker is unable replay the
same message due to the sequence number which is a part of the
Binding Update. It is also unable to modify the Binding Update since
the MAC would not verify after such modification.
==> reword "would not verify" -- "verification would fail" ?
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings