Substantial/semi-editorial issues ================================= 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). 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". 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. 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? 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 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? 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. 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 . 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" ? -------------------------- Jari Arkko writes: Retransmissions and mandatory BAs -- I think you are right, both A=1 and mandatory BA case needs to have retransmission rules and state. -------------------------- Erik Nordmark responds to Jari Arkko: That looks odd - typically protocols only need the "request" retranmitted. Having retransmit timers on a "reply" might cause confusion when the "request" is also being retransmitted. In this particular case, for A=1 the BU will be retransmitted when the MN doesn't receive a BA. For error BAs presumably what caused the BU to be sent (e.g. receiving packets tunneled from the HA) will sooner or later result in a new BU (because the first BU was not accepted) which will cause the same error i.e. a new BA. Isn't that sufficient? -------------------------- Jari Arkko responds to Erik Nordmark: Yes. I don't think we can have the retransmission rules depend on something that only the peer can know -- such as if an error happens. However, we do have the rule that all BUs from a HA will be acked. This is something that the mobile node knows: if I'm sending a BU to a HA, I should expect an ack. But looking at the spec, we *do* require the (A) bit to be set for those. So the current text appears fine after all? -------------------------- Pekka Savola responds to Jari Arkko: > * DHAAD security considerations. I think we have discussed > this in the past. I hope some of that would have ended up in sec cons then ;-). > * Movement detection DAD & old addresses. I think all addresses > have to be DADed per existing RFCs, if we have indeed > seen a movement. Perhaps not all -- globals are supposed to be globals and perhaps DAD for them is a bit of a cornercase. -------------------------- Jari Arkko responds to Pekka Savola (in some cases responses from Pekka, Charlie, and Hesham are shown here as well): > Substantial/semi-editorial issues > ================================= > > 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). (Charlie) I think it is accurate, because the CoTI is not a probe for the home address. The point of the discussion is that, for any particular IPv6 address, packets using that address have the stated vulnerability. I don't think it has to be stated that, for a node using an IPv6 address, that its use of some (a priori unrelated) IPv6 address may introduce a vulnerability along some other path. For the purposes of IPv6 addressing and associated vulnerabilities, that is unrelated. If more words are required (not so in my opinion, but anyway): "The vulnerabilities that off-path attackers may be able to exploit, affecting the home address, are the same as in regular IPv6." (Jari) The text says HA-CN path, so it seems to be correct in this sense already. Pekka has a point though in that care-of tests are also probes. The text is a bit weak here. But I'd rather avoid description of the whole probing sequence here, so why don't we just add use "home address probe messages" instead "probe messages". (Pekka) The point was indeed about the unclear term "probe messages". This change would seem to fix the (minor) ambiguity? > 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". (Charlie) I'm O.K. with either choice here, with a preference towards the latter, or even "A Binding Update is created as follows:". > 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. (Charlie) Since it is assumed that the mobile node is running IPv6, it is also assumed that it follows the rules for address configuration that are part of the IPv6 specification. That already includes link-local address configuration and so on. It would be unwise to repeat those parts of the IPv6 specification again within the Mobile IPv6 specification. (Pekka) I'm not sure if I didn't elaborate the point enough. The _problem_ (which is IMO more than just an editorial issue), is the fundamental change of stationary/mobile nodes. Stationary node makes DAD once, when it is booted up in a network. No duplicates there. Mobile node could visit 1000 networks in a day using the same link-local address. There might be a clash in even one of them. Does this change in model have to be taken into consideration? IMO, it needs to be at least described somewhere (security considerations, if there is no better location -- easy way to DoS MN's in local networks!), if not "solved" by specifying that DAD must be run every time a node detects it's on a new link. (Hesham) Makes sense to say that the MN will need to do DAD on its link-local address every time it moves somewhere in the spec. The security considerations section is the wrong place to say it IMO. There are no security issues here specific to MIPv6 as far as I can see. The issues you mention above are relevant to stationary nodes as well. (Pekka) I don't think SecCons is best place either, but better than none. Availability is part of security, and if your DAD clashes (intentionally or due to someone figuring out your link-local address from e.g. global address's last 64 bits, and anticipates the link where you're moving next) it's not nice.. Totally agree [that the issues you mention above are relevant to stationary nodes as well], but stationary nodes do not by definition move that often from network to another -- and even, typically when they do, they're phyically moved, which implies a new DAD. On the other hand, MN's (in about all cases I can think of) _do_ move, and particularly without being shut down -- otherwise regular mobility with new stateless config'd addresses without MIPv6 would be sufficient. (Jari) Remember that not all things that may happen to mobile nodes need to be described in our specification -- some should be discussed in ND specifications, for instance. And as you know, DAD failures are being addressed in SEND. Anyways, we have recently added Section B.6 that mentions some of these things. I think it says what we need to say: http://www.piuha.net/~jarkko/publications/mipv6/drafts/mobilev6.html#future:nd (Pekka) I think this is missing one particularly important issue, which IMO must be explicitly maintained. That is, the possible clash of the link-local address (probably EUI64-based) on links where the mobile node is moving. Clashes with Care-of and home addresses are a different thing (and in some cases, derive from the same problem: if a node has done DAD for it's LL address, and global address is derived from that, no redoing DAD is necessary for the rest) (Hesham) But these are not send issues, it's just a good ol' address collision (rare) of link local addresses. The CoA collisions are taken care-of with DAD. The HoA collision should not happen (or persist anyway) unless there is some sort of DoS attacks. So these are different problems. Re: B.6 -- That's fine, but it does not address the issue above. I think all it needs is a couple of lines in the spec (i.e. we do not need to talk about ND attacks). (Jari) I added the link-local part in B.6. Let me know if this is OK or if something more is needed. (Hesham) Fine with me. (Pekka) I can live with this, but I suggest adding a last paragraph, like: "In particular, the need and the tradeoffs of re-performing Duplicate Address Detection for the link-local address every time when the mobile node moves on to new links will need to be examined." > 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? (Charlie) Yes, the retransmission mechanism is also valid for other such binding updates, but I don't see that any text is needed to say so. Perhaps it would be better to delete the second sentence, to avoid giving the impression that this state is somehow particular for correspondent nodes... > 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? (Charlie) What is the need for a roadmap? If the 'A' bit is set, a Binding Update is always sent. If the home agent gets a Binding Update, it always sends a Binding Update. Do you really think this is unclear? I don't see how adding more text would help. Do you have a suggestion? (Jari) Charlie, he is right in the sense that Section 4.2 claims the BAs are sent upon request, which isn't quite the case. I have fixed this as follows: A Binding Acknowledgement is used to acknowledge receipt of a Binding Update, if an acknowledgement was requested in the Binding Update, the Binding Update was sent to a home agent, or an error occurred. (Pekka) Sounds ok -- I assume the text at the top of 5.2.6 is sufficiently clear already, or are minor edits necessary there? "This section provides an overview of this binding procedure. The below figure shows the message flow. The Binding Update creates a binding, and the Binding Acknowledgement is optional. ... Binding Acknowledgement: The Binding Update is optionally acknowledged by the correspondent node. The contents of the message are as follows:". This is highlighted slightly by the fact that 5.1 (BU's to HA's) did no have a section like this. (Jari) Yes. Its not really optional in the true sense. I changed the text to say "... is in some cases acknowledged ..." and deleted the optional discussion from the first text fragement. > 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 ...". Done. > 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! Changed. > 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? Yes. I put in a SHOULD. > 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? Perhaps. Not sure I see what the disadvantages are, beyond the pretty optimal max 1.5 RTT exchange. Note that 802 link detection, link authentication, cipher negotiation, IPv6 parameter detection, & other tasks currently take a *huge* amount of time. But this isn't related to route optimization, its related to movements (and is hopefully getting better). I added: "These effects combine to enable much better performance and robustness for communications between mobile nodes and IPv6 correspondent nodes. Route optimization introduces a small amount of additional state for the peers, some additional messaging, and upto 1.5 roundtrip delays before it can be turned on. However, it is believed that the benefits far outweight the costs in most cases. Section 11.3.1 discusses how mobile nodes may avoid route optimization for some of the remaining cases, such as very short-term communications." > 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. Removed. > o In Mobile IPv6, the mobile node does not have to tunnel multicast > packets to its home agent. > > ==> this is not really true anymore. Strictly speaking, MIPv6 nodes can use multicast on the visited link with care-of addresses... but this isn't news so I deleted the item. > 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? I guess not. I'm not sure we should discuss that in this text, though. Not edited. > 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..? No. Its for the care-of address. There was a feature in the spec previously that said that you could have manually configured care-of addresses for different links. But we removed this; it really isn't practical if you think about it. In any case, I softened the language to "... conventional IPv6 mechanisms, such as stateless ...". > 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. This has already been fixed as a part of another issue. Just a reference to 6.1.7 remains. > * 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? Ah I see. Changed to "(within the Home Address destination option if different from the Source Address) > 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.. Hmm... maybe not? Section 12 is for *constants* while section 13 is for configuration variables. The note would have just one audience -- the guy who updates the RFC. Not edited. > 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) Uh... the name was a deliberate attempt to make it clear that you can't just chain these headers like some other extension headers can. I removed the piggybacking text and referred to a "future extension" instead. > 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 . 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. I added "procedures of calculating upper layer checksums while away from home". > 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... All the future cases we have looked at have found the current scheme sufficient. For instance, an option which really needs to be understood could be specified so that it must be copied to the response. Nodes that don't do this didn't support the option. Not edited. > , 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.) Added ", and MUST be cleared in other Binding Updates" > * 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? Should have been zero or more. Fixed. > 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.. It has been updated due to some other comments. > 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.. BAs are likely to be sent most of the time; for home registrations they are always sent and for CN registrations I suspect doing them is a good tradeoff against having to lose packets if the BU was lost. In any case, we need a lifetime field in the Ack because the peer can return a smaller lifetime than we requested. > * 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.. Should have been zero or more. Fixed. > 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). This is an issue we discussed at length half a year ago. We finally agreed on this format. But yeah, there are tradeoffs. Not very important ones, however, imho. Not edited. > 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? No such place -- this is the definitive section for this stuff. But I agree that the "e.g." is pretty vague. Corrected to the form: "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 home address form the Home Address destination option should be used." > 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. Not for me either at first sight, but see RFC 2460... not edited, this appears commonplace in IPv6. > 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.) Yes. Moved. > 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. Yes. Added "This simplifies the process of returning home, as discussed in Section 11.5.4." > 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? I'm 100% sure it works. Here's the argument: in order to set-up route optimization you have to get HOTs and COTs. If the CN doesn't answer you are not going to get them. And if you don't have route optimization set up, you will be doing bidirectional tunneling. It works. However, the ICMP erros are less of a sure thing. You might not get them (policy at the peer) or your implementation might not support acting upon them. Anyways, the reference has been added. > 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/ ...? Right. > 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? Added "(applicable only on nodes which support home agent functionality)". > 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. Moved. > 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? You are right. Added "... without route optimization". > 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. Yes. Add "The link-local address is derived by replacing, the subnet prefix in the mobile node's home address with the link-local prefix." > 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! Section 10.4.1 seems outdated with respect to the L bit and with respect to the requirements in 10.4.2. In particular, 10.4.2 requires ICMP to be sent for packets addressed to the mobile node's link-local address. This appears to be hard unless the home agent is also intercepting packets on this address. I have added the following text to the beginning of Section 10.4.1 and replaced "home address" with "address" throughout the rest of the section. ... home agent sends a NA ... If the Link-Layer Address Compatibility~(L) flag has been specified in the Binding Update, the home agent MUST do the same for the link-local address of the mobile node. (Pekka) This is one issue that seemed confusing to me when reading the draft. It was not clear to me which packets would be captured, whether "Home Address" of the MN would also include it's LL address, etc. (the beginning of 4.1 doesn't suggest so, at least.) This might have to be stated more explicitly in the introductory chapters (like 4.1). If LL messages are not proxied/captured, this might lead to problems (if not now, in the future). (Jari) The packets are now intercepted, but of course the next section says that they will not be forwarded to the mobile node but rather an ICMP is generated. Home address does not include the LL address, so 4.1 is correct. But if you specify L=1 in your Binding Update, then the home agent will defend your LL, intercept your LL traffic, and generate ICMPs out of it. I don't think we want to pass link-local traffic to the mobile node. > 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. Its not only used for that. But I added the following text: "A binding may need to be de-registered when the mobile node returns home, or when the mobile node knows that it will soon not have any care-of addresses in the visited network." > 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) Changed text: "The mobile node's home address is used as its new care-of address for the purposes of moving the key management connection to a new endpoint." > 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. Yes. But to avoid too drastic text movements in this stage, I decided to remove the duplicated "MUST tunnel" from 10.4.1 and call 10.4.2 "Processing Intercepted Packets" instead. > 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 :-). Edited to "Since these packets all are destined to a link-scope multicast address and have a hop limit of 1 there is no direct forwarding of such packets between the home network and the mobile node." (Pekka) s/these packets all/all these packets/, s/of 1/of 1,/ > 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? Edited. > 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..? Not if they are home agents. That's why this text is there. Not edited. (Pekka) Oh, right. Perhaps 7.2 could be further clarified: Router Address (R) 1-bit router address flag. When set, indicates that the Prefix field, in addition to advertising the indicated prefix, contains a complete IP address assigned to the sending router. ==> e.g. reword to something similar to: 1-bit router address flag. When set, indicates that the Prefix field, contains a complete IP address assigned to the sending router. The indicated prefix is the first Prefix Length bits of the Prefix field. (Jari) Done. > 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. Deleted this unnecessary text. > 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. Left in place then. > Direct Delivery > > ==> IMO the title is misleading ("Route Optimization"?) > and this subsection does not mention binding updates at all..! Changed to Route Optimization. And I've reorganized the text a bit in this section to bring to the right place the text that talked about existence of a BCE at the CN. > 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. I don't understand this comment. Note that it says "typically". But direct delivery of packets is faster -- note that we are not discussing all the overhead associated with setting up the RO, just the transport which is the subject of this section. Not edited. (Pekka) Ok, I was thinking of the whole overhead of setting up the RO -- that's what the users care about (in many cases). > 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. Hmm... "The packet" refers to the packet being sent by the mobile node. If you go back to the beginning of the bullet list, just before "Direct Delivery" you should see this. I'm not sure we want to repeat anything additional here. Or did I misunderstand your comment? (Pekka) It isn't necessary to repeat, but when reading "Direct delivery", the packet formats are quite extensively described. Just thought it might make a sense to give some pointer for balance here, like changing: "The packet, formatted as described above, is sent to the home agent using IPv6 encapsulation [15]." (Jari) But the formats *are* different. In reverse tunneling none of the modifications apply. Just shove the packet into a tunnel and thats it. (Pekka) With my very inprecise addition I meant the connection between bidir tunneling and three bullets at the beginning of the section. That is, is is crystal clear which kind of contents the internal packet should include (Jari) Ok. I see the point now. I added "This mechanism is used for packets that use the mobile node's home address as the Source Address in the IPv6 header, or with multicast control protocol packets as described in Section 11.3.4." > 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. Its an extension. The IPsec RFCs do not describe what the semantics of the HAO are. But I'm not sure what else we can say here, it seems that the required functionality is specified in the text. Not edited. (Pekka) I guess the problem is that MIPv6 spec is making changes to IPsec processing rules -- one might want to be a bit more explicit about those, like add a reference, do a separate section like "Modifications to IPv6 Neighbor Discovery" or the like. (Jari) I added a statement to 11.3.2 about this ("RFC 2402 treatment of destination options is extended as follows"), but for the rest I think the HA-MN security draft should be sufficient. > 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? No. The required pattern is in the "*" bullet items above. I clarified this bullet item by adding the words "to reach the situation above" just before the comma. > [...] > 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? The problem you see is valid. Let's see what we can do with this... it seems like some folks would like to have the implementation advice about the value zero; maybe the following text change will make this clear: "Once the above checks ...., decrements segments left by one from the value it had on the wire, ..." > 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]./ Edited. > ==> 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 [...]". Edited. Changed text: "In this case, the mobile node MUST use its care-of address and MUST NOT use the Home Address destination option when sending MLD packets~\cite{rfc2710}." > 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. We've used exponential back-off throughout the draft, I don't think we want to switch to something else now. (I may even recall some AD comments on something _not_ using exponential back-off.) However, the right about of retransmissions is surely a question mark. Please note that its a MAY to retransmit, and that wireless links can be lossy. Particularly so when you first connect to them, just getting to the coverage area... the retransmissions aren't really so much for the home agent rebooting but rather for the possible packet loss in the path there. Since this is a MAY & exponential back-off I do not see a serious problem with keeping the current limit. Making the limit lower, however, would make it look like on some lossy link you might run of retries. Not edited. (Pekka) I can live with this even though I'm a bit puzzled at some values.. > 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. Right. Changed text: "... If a mobile node needs to use a source address (other than the unspecified address) in packets sent as a part of address autoconfiguration, it MUST use an IPv6 link-local address rather than its own IPv6 home 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? I'm not sure. Perhaps that is a topic for some future specification? They are debating DHCP and other mechanisms for IKEv2 right now, for instance. Not edited. (Pekka) Ok. > 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! Yes. "recently received" => "recently received (see Section 5.2.7)". > 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.. Right. This has been discussed, and is a part of future "things to do" list. > 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. Removed all organizations. > 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? This word was recommended to us by the security reviewer. Not edited. (Pekka) Ok > 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"?). Edited. "not by routers in between". > 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? Are you referring to the terms section, or the basic operations section? I can't see a problem in the latter. I think the former does have a problem, but then again I'm not sure how to avoid the circular definition. Not edited. (Pekka) IMO, the terminoloy is ok -- 'home subnet prefix' does not mention 'home link' (though does so via "home address"). However, in above: The "home address" is an IP address assigned to the mobile node within its home subnet prefix on its home link. "on its home link" is redundant as home subnet prefix already requires that it must be on home link, right? .. but I'm not sure if this is worth the effort.. (Jari) Ok, I'll ignore it then ;-) > 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 ? Changed. > 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/.(/. (/ Edited. > There MAY be additional information, associated with this Binding > Refresh Request message, that need not be present in all Binding > > ==> s/,// Edited. > 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) Changed. I used "cleared". > 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) Edited. > 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.. Different people wrote the texts. Now its aligned. > 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) Currently, no figures are split. I think there's a way to avoid this both in LaTeX and XML (both of which I'm using), but my current translation scripts from LaTeX do not allow for it. Lets leave this to the RFC Editor. Not edited. > 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? I'm not sure where you see a circular definition here. Not edited. (Pekka) The line: "as a home agent for the mobile node. The following additional" was probably left off by me. Home link <-> home agent. Even less worth it than the previous circular definition, so it's ok I guess. > 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/ ? Yes. Edited. > 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) Edited. > o L=0: Defend the given address. > > ==> s/ / / Edited.. not sure if the god of xml is merciful today though... we'll see what the result is. > o Cookie values used the Home Test Init and Care-of Test Init > messages. > > ==> s/used/used in/ ? Yes. Edited. > * 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." Edited. > 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." Edited. > 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./ Edited. > 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) Edited. > 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) Edited. > The mobile node SHOULD also mark its link-local address as tentative, > and follow standard Duplicate Address Detection procedures[13]. > > ==> s/[13]/ [13]/ Edited. > 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/ Edited. > 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! Yes. Edited. > 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)? Edited. > 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/ ? Edited. > 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" ? Edited. -------------------------- -------------------------- -------------------------- --------------------------