Hi Elwyn Thanks a lot for detailed reviews. Please find my comments inline... I fixed the most of comments and attach the -11.txt and diff files.The updated version contains the modifications for Gerardo's comments, too.
On 2008/11/24, at 19:45, Elwyn Davies wrote:
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see _http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html_). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-monami6-multiplecoa-10.txt Reviewer: Elwyn Davies Review Date: 24 November 2008 IETF LC End Date: 17 November 2008 IESG Telechat date: (if known) - Summary: This document is almost ready for the IESG. It has a number of minor issues plus a fair number of editorial nits.I am sending the editirial issues to the authors separately as there arelots of acronyms needing expansion and minor english improvements that woild be tedious to transcribe. Apologies for the late review. Comments: Minor Issues: Backwards compatibility: It would be helpful to explain in theintroduction why this proposal is backwatds compatible with the RFC 3775 scheme. The explanations are there but are buried in the error cases ofs5.7 and is easily mossed (as I did on early reading).
I added the following text in the Protocol Overview. NEW This specification keeps backwards compatibility with [RFC-3775]. If a receiver (either home agent or correspondent node) does not support this specification, it does not understand the binding identifier mobility option. The receiver skip the unknown mobility option (i.e. Binding Identifier mobility option) and process the Binding Update as defined in [RFC-3775]. In order to keep the backward compatibility with [RFC-3775], when a mobile node sends a Binding Update message with extensions described in this document, the receiver needs to reflect the Binding Identifier mobility option in the Binding Acknowledgement. If the mobile node finds no Binding Identifier mobility options in the received Binding Acknowledgement, it assumes the other end node does not support this specification. In such case, the mobile node needs to fall back to the legacy RFC-3775 compliant mobile node. If it is the home registration, the mobile node MAY try to discover another home agent supporting BID mobility option for the home registration.
Extension to IPv4 correspondents etc: Something about this in the ontroduction would also help.
OK
s2 and several other places (s4.2, s5.1): Use of zero as a binding ID (BID) is forbidden. It is unclear why this value is not allowed - it does not AFAICS specify reversion to RFC 3775 behaviour or anything similar: Forbidding it seems gratuitous.
zero BID might be used to specify some meaning to a binding.For example, a binding using BID zero can be treated as a default binding.
The zero BID is not forbidden, but it's reserved.
I removed "MUST NOT" for using the zero BID.
OLD
Binding ID (BID)
The BID which is assigned to the binding indicated by the care-of
address in the Binding Update or the BID mobility option. The BID
is a 16-bit unsigned integer. The value of zero is reserved and
MUST NOT be used.
NEW
Binding ID (BID)
The BID which is assigned to the binding indicated by the care-of
address in the Binding Update or the BID mobility option. The BID
is a 16-bit unsigned integer. The value of zero is reserved and
may not be used without special purpose.
s2: Specifying that the BID must not be negative is sloghtly confusingbecause the protocol is specified so that negative values cannot be carried.
right. I erased this sentence.
s4.2 (two places), s6.2 (2nd bullet), s6.2 (6th bullet, 1st sub- bullet):The length of the Binding Address mobility option for the IPv4 case is specified inconsistently. Some places have been corrected from 12 to 8 but several others remain.
thanks, we did fix these errors.
s4.2: The Reserved fiels is normally specified as 'SHOULD be ignored bythe receiver'. Makes it easier to cope with later changes.
fixed.
s4.3 (MCOA NOTCOMPLETE) and elsewhere (s6.2): I am dubious about the non-transactional nature of bulk registrations: some additional discussion of why it should be reasonable that a bulk registration can fail in part would be useful
OK. see my comments to the same question at the end of this mail.
s4.3 (MCOA MALFORNED): Some indoication of the circumstances under whichthis can occur would be useful.
Added more texts in section 4.3
OLD
MCOA MALFORMED (TBD more than 128)
Registration failed because Binding Identifier mobility option was
not formatted correctly.
NEW
MCOA MALFORMED (TBD more than 128)
Registration failed because Binding Identifier mobility option was
not formatted correctly. This value is used when the wrong length
value is specified (neither 4, 8 nor 20) in the length field of
the Binding Identifier mobility or when invalid address is
specified in the care-of address field.
s4.3 (MCOA BULK REGISTRATION PROHIBITED) and s5.3: I think there is a'crner case' in which a bulk registration is sent to a leagcay RFC 3775 node: the node would not be capable of this response. This corner caseis not described in s5.3
This comment is related to the Backwards compatibility. If a legacy RFC-3775 node receives a BU in the bulk registration mode,it can simply process only the BU and skip the binding identifier option.
It does not use this BULK REG PROHIBITED value in the BA status code.The MN can distinguish whether the receiver of BU is legacy RFC-3775 node or MCoA extended node by
checking Binding Acknowledgement. See the second paragraph of section5.7. " If a mobile node includes a Binding Identifier mobility option in a Binding Update with the 'A' flag set, a Binding Acknowledgement MUST carry a Binding Identifier mobility option. According to [RFC-3775], the receiver of the Binding Update ignores unknown mobility options and process the Binding Update without the unknown mobility option. Therefore, if no such mobility option is included in the Binding Acknowledgement in response to a Binding Update for multiple care-of address registration, this indicates that the originating node of the Binding Acknowledgement does not support processing the Binding Identifier mobility option regardless of status value. In such case, the receiver of the Binding Update may create a regular binding. The mobile node then stop multiple care-of address registration with that node. If it is home registration, the mobile node MAY attempt to discover another home agent supporting BID mobility option for the home registration."
s5.3: What error status is sent if the user has an Alernate care-of address option with a bulk registration?
Very good comment. I re-checked this parts and found this part is very unclear.The reason of eliminating Alternate care-of address option is not only for bulk registration. In RFC-3775, Alternate CoA is mandatory for home registration, but not for binding registration to correspondent node. Alternate CoA mobility option is required when BU is protected with IPsec ESP.
Therefore, we clearly mention this point in the draft.
In section 5.2
OLD
When IPsec ESP is used for protecting the Binding Update,
the care-of address can be carried in the Care-of Address field of
the Binding Identifier mobility option. If this is done, the
alternate care-of address option MUST NOT be included in the Binding
Update.
NEW
When IPsec ESP is used for protecting the Binding Update, a care-of
address MUST be carried in an alternate care-of address mobility
option as described in [RFC-3776]. However, in this specfication,
the care-of address MUST be carried in the Care-of Address field of
the Binding Identifier mobility option. In order to save bits of the
Binding Update, the alternate care-of address option MUST NOT be
included.
In section 5.3
OLD
The alternate care-of address option MUST NOT be used.
NEW
When IPsec ESP is used for protecting the Binding Update, a care-of
address MUST be carried in an alternate care-of address mobility
option as described in [RFC-3776]. However, in the bulk
registration, the care-of addresses are always carried in the Care-of
Address field of the Binding Identifier mobility option. In order to
save bits of the Binding Update, the alternate care-of address option
MUST NOT be included in such Binding Update.
In section 6.2
ADD
o If the Binding Update is protected with IPsec ESP, the care-of
address MUST be appeared in the Binding Identfier mobility option.
If no address is appeared in the care-of address field in that
mobility option, it MUST reject the Binding Identifier mobility
option and returns the status value set to [MCOA MALFORMED].
o If the care-of address is appeared in both the alternate care-of
address mobility option and the BInding Identifier mobility option
at the same time, it MUST ignore the alternate care-of address
mobility option and can continue processing the Binding Update
with the care-of address specified in the BInding Identifier
mobility option.
s5.5.2, last para: Arguably, if the interface is shut down the node os not (IP) connected to its home link!
right. This was discussed on the ML, too. There is no specific description of returning home in this section,but we explain how MN de-registers the binding of the shut-down interface from the active interface.
s5.6.3 (2nd bullet) and s6.1 (para 2): Using 'ex.' is not good: It is not a standard abbreviation. I take it 'except' is meant.
fixed.
s5.6.3 (3rd bullet): 'The mobile node SHOULD include the Link-layer Address (LLA) Option': I do not understand how the home agent would beable to send to the mobile node if the LLA option was omitted. I thinkthis is a 'MUST' or maybe a 'needs to'.
If the link between HA and MN is P2P (example is 3GPP/WiMAX), we expect HA might be able to get the LL address in the L2 mechanism. Therefore, we use SHOULD instead of MUST.
s5.6.4 (2nd top level bullet): 'the home agent SHOULD use the link- layer address carried by the Link Layer Address option': Again I am not surewhat alternative there is? Replace with either 'MUST' or 'needs to'.
see above. A home link can be P2P link in some scenario.
s5.7 (2nd bullet): s/SHOULD/needs to/: This is not something sthat isan option in the protocol. Also I think it should state that the mobilenode needs to assume that none of the attempted registrations were successful.
OLD
o If the Status value is [MCOA BULK REGISTRATION NOT SUPPORT], the
mobile node SHOULD stop using bulk registrations with the node
that sent the Binding Acknowledgement.
NEW
o If the Status value is [MCOA BULK REGISTRATION NOT SUPPORT], all
the attemped registration in the bulk registration mode are
failed. Therefore, the mobile node MUST stop using bulk
registrations with the node that sent the Binding Acknowledgement.
s5.7 (3rd bullet): Explain what could cause the packet to be malformed.
It is now explained in section 4.3.
s5.7 (4th bullet): Replace 1st instance of SHOULD with 'needs to'.Explain that the 2nd case can occur during 'bootsatrpa' (pointer to s5.9).
fixed.
s6.2 (para 2): If bulk registrations are not transactional (which I would have preferred) need to make it clear what happens with thevrarious multiple mobility options when some are succcessful and some fail.
It is not designed as transactional.However, it might be a case when HA cannot accept more than two bindings, but MN sends 3 CoAs in bulk BU. In such case, HA should accept two bindings and reject one. In the BA, HA should set either one of those error codes for the rejected BID.
128 Reason unspecified
129 Administratively prohibited
130 Insufficient resources
I didn't make any modification to this comments.
If this reason is reasonable and is worth to write in the draft,
I will add new texts.
s6.2 (2nd bullet): 'When the Length value is either 8 or 20, the care-of address MUST be present in the Binding Identifier mobility option. If the valid care-of address is not present, the receiver MUST reject the Binding Identifier mobility option and returns the statusvalue set to [MCOA MALFORMED].' This is poorly phrased. If the lengthis set to 8 or 20, then there is space in the option for an address ofsome sort. It sort of implies that the bit pattern can be tested to seeif it is a valid address - how is this done?
This address verification is mainly to check the CoA is truly unicast routable address or not.
The same verification is defined in RFC3775.
OLD
o When the Length value is either 8 or 20, the care-of address MUST
be present in the Binding Identifier mobility option. If the
valid care-of address is not present, the receiver MUST reject the
Binding Identifier mobility option and returns the status value
set to [MCOA MALFORMED].
NEW
o When the Length value is either 8 or 20, the care-of address MUST
be present in the Binding Identifier mobility option. If the
unicast routable address [RFC-3775] is not present in the care-of
address field, the receiver MUST reject the Binding Identifier
mobility option and returns the status value set to [MCOA
MALFORMED].
It strikes me tht it would simpler just to day that the address is ignored if present when not required (or, if being paranoid, must be the same as was previously registered (if present) when deleting a registration).
If the care-of address is not required, the length value must be 4.There is no space to include the care-of address in the binding identifier option.
s6.2 (1st para after lost of bullets): s/can be omitted/MAY be omitted/
fixed.
Editorial: I have sent a Word document with many nits marked up to the authors.
I have fixed all the editorial comments. Thanks!!!! regards, ryuji ps. I'm away from the office on a business trip for two weeks. I am now in New Orleans, but will catch flights to Spain this morning.Title: Diff: draft-ietf-monami6-multiplecoa-10.txt - draft-ietf-monami6-multiplecoa-11.txt
| draft-ietf-monami6-multiplecoa-10.txt | draft-ietf-monami6-multiplecoa-11.txt | |||
|---|---|---|---|---|
| MEXT Working Group R. Wakikawa (Ed.) | MEXT Working Group R. Wakikawa (Ed.) | |||
| Internet-Draft Toyota ITC/Keio Univ. | Internet-Draft Toyota ITC/Keio Univ. | |||
| Intended status: Standards Track V. Devarapalli (Ed.) | Intended status: Standards Track V. Devarapalli (Ed.) | |||
| Expires: May 8, 2009 Wichorus | Expires: June 8, 2009 Wichorus | |||
| T. Ernst | T. Ernst | |||
| INRIA | INRIA | |||
| K. Nagami | K. Nagami | |||
| INTEC NetCore | INTEC NetCore | |||
| November 4, 2008 | December 5, 2008 | |||
| Multiple Care-of Addresses Registration | Multiple Care-of Addresses Registration | |||
| draft-ietf-monami6-multiplecoa-10.txt | draft-ietf-monami6-multiplecoa-11-20081205.txt | |||
| Status of this Memo | Status of this Memo | |||
| By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
| applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||
| have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |||
| aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
| skipping to change at page 1, line 39 | skipping to change at page 1, line 39 | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| This Internet-Draft will expire on May 8, 2009. | This Internet-Draft will expire on June 8, 2009. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (C) The IETF Trust (2008). | Copyright (C) The IETF Trust (2008). | |||
| Abstract | Abstract | |||
| According to the current Mobile IPv6 specification, a mobile node may | According to the current Mobile IPv6 specification, a mobile node may | |||
| have several care-of addresses, but only one, called the primary | have several care-of addresses, but only one, called the primary | |||
| care-of address, that can be registered with its home agent and the | care-of address, that can be registered with its home agent and the | |||
| skipping to change at page 2, line 27 | skipping to change at page 2, line 27 | |||
| Mobility) Basic Support protocol as well. | Mobility) Basic Support protocol as well. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 | 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 11 | 4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 12 | |||
| 4.1. Binding Cache Structure and Binding Update List . . . . . 11 | 4.1. Binding Cache Structure and Binding Update List . . . . . 12 | |||
| 4.2. Binding Identifier Mobility Option . . . . . . . . . . . . 11 | 4.2. Binding Update Message . . . . . . . . . . . . . . . . . . 12 | |||
| 4.3. New Status Values for Binding Acknowledgement . . . . . . 13 | 4.3. Binding Identifier Mobility Option . . . . . . . . . . . . 13 | |||
| 4.4. New Status Values for Binding Acknowledgement . . . . . . 14 | ||||
| 5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 15 | 5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 17 | |||
| 5.1. Management of Care-of Address(es) and Binding | 5.1. Management of Care-of Address(es) and Binding | |||
| Identifier(s) . . . . . . . . . . . . . . . . . . . . . . 15 | Identifier(s) . . . . . . . . . . . . . . . . . . . . . . 17 | |||
| 5.2. Binding Registration . . . . . . . . . . . . . . . . . . . 15 | 5.2. Binding Registration . . . . . . . . . . . . . . . . . . . 17 | |||
| 5.3. Bulk Registration . . . . . . . . . . . . . . . . . . . . 16 | 5.3. Bulk Registration . . . . . . . . . . . . . . . . . . . . 18 | |||
| 5.4. Binding De-Registration . . . . . . . . . . . . . . . . . 17 | 5.4. Binding De-Registration . . . . . . . . . . . . . . . . . 19 | |||
| 5.5. Returning Home: Using Single Interface . . . . . . . . . . 17 | 5.5. Returning Home: Using Single Interface . . . . . . . . . . 19 | |||
| 5.5.1. Using only Interface attached to the Home Link . . . . 17 | 5.5.1. Using only Interface attached to the Home Link . . . . 19 | |||
| 5.5.2. Using only Interface attached to the Visited Link . . 17 | 5.5.2. Using only Interface attached to the Visited Link . . 20 | |||
| 5.6. Returning Home: Simultaneous Home and Visited Link | 5.6. Returning Home: Simultaneous Home and Visited Link | |||
| Operation . . . . . . . . . . . . . . . . . . . . . . . . 18 | Operation . . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
| 5.6.1. Problems of Simultaneous Home and Foreign | 5.6.1. Problems of Simultaneous Home and Foreign | |||
| Attachments . . . . . . . . . . . . . . . . . . . . . 18 | Attachments . . . . . . . . . . . . . . . . . . . . . 20 | |||
| 5.6.2. Overview and Approach . . . . . . . . . . . . . . . . 18 | 5.6.2. Overview and Approach . . . . . . . . . . . . . . . . 21 | |||
| 5.6.3. Sending Deregistration Binding Update . . . . . . . . 20 | 5.6.3. Sending Deregistration Binding Update . . . . . . . . 22 | |||
| 5.6.4. Sending Binding Acknowledgement . . . . . . . . . . . 20 | 5.6.4. Sending Binding Acknowledgement . . . . . . . . . . . 23 | |||
| 5.6.5. Sending Packets from the Home Link . . . . . . . . . . 22 | 5.6.5. Sending Packets from the Home Link . . . . . . . . . . 24 | |||
| 5.6.6. Leaving from the Home Link . . . . . . . . . . . . . . 22 | 5.6.6. Leaving from the Home Link . . . . . . . . . . . . . . 25 | |||
| 5.7. Receiving Binding Acknowledgement . . . . . . . . . . . . 23 | 5.7. Receiving Binding Acknowledgement . . . . . . . . . . . . 25 | |||
| 5.8. Receiving Binding Refresh Request . . . . . . . . . . . . 24 | 5.8. Receiving Binding Refresh Request . . . . . . . . . . . . 26 | |||
| 5.9. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 24 | 5.9. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 27 | |||
| 6. Home Agent and Correspondent Node Operation . . . . . . . . . 25 | 6. Home Agent and Correspondent Node Operation . . . . . . . . . 28 | |||
| 6.1. Searching Binding Cache with Binding Identifier . . . . . 25 | 6.1. Searching Binding Cache with Binding Identifier . . . . . 28 | |||
| 6.2. Processing Binding Update . . . . . . . . . . . . . . . . 25 | 6.2. Processing Binding Update . . . . . . . . . . . . . . . . 28 | |||
| 6.3. Sending Binding Refresh Request . . . . . . . . . . . . . 28 | 6.3. Sending Binding Refresh Request . . . . . . . . . . . . . 31 | |||
| 6.4. Receiving Packets from Mobile Node . . . . . . . . . . . . 28 | 6.4. Receiving Packets from Mobile Node . . . . . . . . . . . . 31 | |||
| 7. Network Mobility Applicability . . . . . . . . . . . . . . . . 29 | 7. Network Mobility Applicability . . . . . . . . . . . . . . . . 32 | |||
| 8. DSMIPv6 Applicability . . . . . . . . . . . . . . . . . . . . 30 | 8. DSMIPv6 Applicability . . . . . . . . . . . . . . . . . . . . 33 | |||
| 8.1. IPv4 Care-of Address Registration . . . . . . . . . . . . 30 | 8.1. IPv4 Care-of Address Registration . . . . . . . . . . . . 33 | |||
| 8.2. IPv4 HoA Management . . . . . . . . . . . . . . . . . . . 31 | 8.2. IPv4 Home Address Management . . . . . . . . . . . . . . . 34 | |||
| 9. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 32 | 9. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 35 | |||
| 9.1. Use of Care-of Address in the IKEv2 exchange . . . . . . . 32 | 9.1. Use of Care-of Address in the IKEv2 exchange . . . . . . . 35 | |||
| 9.2. Transport Mode IPsec protected messages . . . . . . . . . 33 | 9.2. Transport Mode IPsec protected messages . . . . . . . . . 36 | |||
| 9.3. Tunnel Mode IPsec protected messages . . . . . . . . . . . 33 | 9.3. Tunnel Mode IPsec protected messages . . . . . . . . . . . 36 | |||
| 9.3.1. Tunneled HoTi and HoT messages . . . . . . . . . . . . 33 | 9.3.1. Tunneled Home Test Init and Home Test messages . . . . 36 | |||
| 9.3.2. Tunneled Payload Traffic . . . . . . . . . . . . . . . 34 | 9.3.2. Tunneled Payload Traffic . . . . . . . . . . . . . . . 37 | |||
| 10. Security Considerations . . . . . . . . . . . . . . . . . . . 35 | 10. Security Considerations . . . . . . . . . . . . . . . . . . . 38 | |||
| 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 | 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 | |||
| 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38 | 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41 | |||
| 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 | 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 | |||
| 13.1. Normative References . . . . . . . . . . . . . . . . . . . 38 | 13.1. Normative References . . . . . . . . . . . . . . . . . . . 41 | |||
| 13.2. Informative References . . . . . . . . . . . . . . . . . . 38 | 13.2. Informative References . . . . . . . . . . . . . . . . . . 41 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 | |||
| Intellectual Property and Copyright Statements . . . . . . . . . . 41 | Intellectual Property and Copyright Statements . . . . . . . . . . 44 | |||
| 1. Introduction | 1. Introduction | |||
| A mobile node may use various types of network interfaces to obtain | A mobile node may use various types of network interfaces to obtain | |||
| durable and wide area network connectivity. This is increasingly | durable and wide area network connectivity. This has increasingly | |||
| become true with mobile nodes having multiple interfaces such as | become true with mobile nodes having multiple interfaces such as | |||
| 802.2, 802.11, 802.16, cellular radios, etc.. The motivations for | 802.2, 802.11, 802.16, cellular radios, etc. The motivations for and | |||
| and benefits of using multiple points of attachment are discussed in | benefits of using multiple points of attachment are discussed in [ID- | |||
| [ID-MOTIVATION]. When a mobile node with multiple interfaces uses | MOTIVATION]. When a mobile node with multiple interfaces uses Mobile | |||
| Mobile IPv6 [RFC-3775] for mobility management, it cannot use its | IPv6 [RFC-3775] for mobility management, it cannot use its multiple | |||
| multiple interfaces to send and receive packets while taking | interfaces to send and receive packets while taking advantage of | |||
| advantage of session continuity provided by Mobile IPv6. This is | session continuity provided by Mobile IPv6. This is because Mobile | |||
| because Mobile IPv6 allows the mobile node to only bind one care-of | IPv6 allows the mobile node to only bind one care-of address at a | |||
| address at a time with its home address. See [ID-MIP6ANALYSIS] on a | time with its home address. See [ID-MIP6ANALYSIS] for a further | |||
| further analysis of using multiple interfaces and addresses with | analysis of using multiple interfaces and addresses with Mobile IPv6. | |||
| Mobile IPv6. | ||||
| This document proposes extensions to Mobile IPv6 to allow a mobile | This document proposes extensions to Mobile IPv6 to allow a mobile | |||
| node to register multiple care-of addresses for a home address and | node to register multiple care-of addresses for a home address and | |||
| create multiple binding cache entries. A new Binding Identification | create multiple binding cache entries. A new Binding Identification | |||
| (BID) number is created for each binding the mobile node wants to | (BID) number is created for each binding the mobile node wants to | |||
| create and sent in the binding update. The home agent that receives | create and sent in the binding update. The home agent that receives | |||
| this Binding Update creates separate binding for each BID. The BID | this Binding Update creates a separate binding for each BID. The BID | |||
| information is stored in the corresponding binding cache entry. The | information is stored in the corresponding binding cache entry. The | |||
| BID information can now be used to identify individual bindings. The | BID information can now be used to identify individual bindings. The | |||
| same extensions can also be used in Binding Updates sent to the | same extensions can also be used in Binding Updates sent to the | |||
| correspondent nodes. | correspondent nodes. | |||
| 2. Terminology | 2. Terminology | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
| document are to be interpreted as described in [RFC-2119]. | document are to be interpreted as described in [RFC-2119]. | |||
| Terms used in this draft are defined in [RFC-3775], [RFC-3753] and | Terms used in this draft are defined in [RFC-3775], [RFC-3753] and | |||
| [RFC-4885]. In addition or in replacement of these, the following | [RFC-4885]. In addition to or as a replacement of these, the | |||
| terms are defined or redefined: | following terms are defined or redefined: | |||
| Binding Identification number (BID) | Binding Identification number (BID) | |||
| The BID is an identification number used to distinguish multiple | The BID is an identification number used to distinguish multiple | |||
| bindings registered by the mobile node. Assignment of distinct | bindings registered by the mobile node. Assignment of distinct | |||
| BIDs allows a mobile node to register multiple binding cache | BIDs allows a mobile node to register multiple binding cache | |||
| entries for a given home address. The BIDs assigned to a same | entries for a given home address. The BIDs assigned to a same | |||
| home address MUST NOT be duplicated at a time. Zero and negative | home address must not be duplicated at a time. Zero value is | |||
| values MUST NOT be used. Each BID is generated and managed by a | reserved for future extension. Each BID is generated and managed | |||
| mobile node. The BID is stored in the Binding Update List and is | by a mobile node. The BID is stored in the Binding Update List | |||
| sent by the mobile node in the Binding Update. A mobile node MAY | and is sent by the mobile node in the Binding Update. A mobile | |||
| change the value of a BID at any time according to its | node may change the value of a BID at any time according to its | |||
| administrative policy, for instance to protect its privacy. An | administrative policy, for instance to protect its privacy. An | |||
| implementation must carefully assign the BID so as to keep using | implementation must carefully assign the BID so as to keep using | |||
| the same BID for the same binding even when the status of the | the same BID for the same binding even when the status of the | |||
| binding is changed. More details can be found in Section 5.1. | binding is changed. More details can be found in Section 5.1. | |||
| Binding Identifier Mobility Option | Binding Identifier Mobility Option | |||
| The Binding Identifier mobility option is used to carry the BID | The Binding Identifier mobility option is used to carry the BID | |||
| information. | information. | |||
| Bulk Registration | Bulk Registration | |||
| A mobile node can register multiple bindings at once by sending a | A mobile node can register multiple bindings at once by sending a | |||
| single Binding Update. A mobile node can also replace some or all | single Binding Update. A mobile node can also replace some or all | |||
| the bindings available at the home agent with the new bindings by | the bindings available at the home agent with the new bindings by | |||
| using the bulk registration. Bulk registration is supported only | using the bulk registration. Bulk registration is supported only | |||
| for home registration (i.e. with the home agent) as explained in | for home registration (i.e. with the home agent) as explained in | |||
| Section 5.3. A mobile node MUST NOT perform bulk registration | Section 5.3. A mobile node must not perform bulk registration | |||
| mechanism described in this specification with a correspondent | mechanism described in this specification with a correspondent | |||
| node. | node. | |||
| 3. Protocol Overview | 3. Protocol Overview | |||
| A new extension called the Binding identification number (BID) is | A new extension called the Binding identification number (BID) is | |||
| introduced to distinguish between multiple bindings pertaining to the | introduced to distinguish between multiple bindings pertaining to the | |||
| same home address. If a mobile node configures several IPv6 global | same home address. If a mobile node configures several IPv6 global | |||
| addresses on one or more of its interfaces, it can register these | addresses on one or more of its interfaces, it can register these | |||
| addresses with its home agent as care-of addresses. If the mobile | addresses with its home agent as care-of addresses. If the mobile | |||
| skipping to change at page 6, line 32 | skipping to change at page 6, line 32 | |||
| node, and if the BID in the Binding Update does not match the one | node, and if the BID in the Binding Update does not match the one | |||
| with the existing entry, the home agent MUST create a new binding | with the existing entry, the home agent MUST create a new binding | |||
| cache entry for the new care-of address and BID. The mobile node can | cache entry for the new care-of address and BID. The mobile node can | |||
| register multiple care-of addresses either independently in | register multiple care-of addresses either independently in | |||
| individual Binding Updates or multiple at once in a single Binding | individual Binding Updates or multiple at once in a single Binding | |||
| Update. | Update. | |||
| If the mobile host wishes to register its binding with a | If the mobile host wishes to register its binding with a | |||
| correspondent node, it must perform return routability operations as | correspondent node, it must perform return routability operations as | |||
| described in [RFC-3775]. This includes managing a Care-of Keygen | described in [RFC-3775]. This includes managing a Care-of Keygen | |||
| token per care-of address and exchanging CoTi and CoT message with | token per care-of address and exchanging Care-of Test Init and | |||
| the correspondent node for each care-of address. The mobile node MAY | Care-of Test message with the correspondent node for each care-of | |||
| use the same BID that it used with the home agent for a particular | address. The mobile node MAY use the same BID that it used with the | |||
| care-of address. For protocol simplicity, bulk registration to | home agent for a particular care-of address. For protocol | |||
| correspondent nodes is not supported in this document. This is | simplicity, bulk registration to correspondent nodes is not supported | |||
| because the Return Routability mechanism introduced in [RFC-3775] | in this document. This is because the Return Routability mechanism | |||
| cannot be easily extended to verify multiple care-of addresses stored | introduced in [RFC-3775] cannot be easily extended to verify multiple | |||
| in a single Binding Update. | care-of addresses stored in a single Binding Update. | |||
| Figure 1 illustrates the configuration where the mobile node obtains | Figure 1 illustrates the configuration where the mobile node obtains | |||
| multiple care-of addresses at foreign links. The mobile node can | multiple care-of addresses at foreign links. The mobile node can | |||
| utilize all the care-of addresses. In Figure 1, the home address of | utilize all the care-of addresses. In Figure 1, the home address of | |||
| the mobile node (MN) is 2001:db8::EUI. The mobile node has 3 | the mobile node (MN) is 2001:db8::EUI. The mobile node has 3 | |||
| different interfaces and possibly acquires care-of addresses 1-3 | different interfaces and possibly acquires care-of addresses 1-3 | |||
| (CoA1, CoA2, CoA3). The mobile node assigns BID1, BID2 and BID3 to | (CoA1, CoA2, CoA3). The mobile node assigns BID1, BID2 and BID3 to | |||
| each care-of address. | each care-of address. | |||
| +----+ | +----+ | |||
| | CN | | | CN | | |||
| +--+-+ | +--+-+ | |||
| | | | | |||
| +---+------+ +----+ | +---+------+ +----+ | |||
| +------+ Internet |----------+ HA | | +------+ Internet |----------+ HA | | |||
| | +----+---+-+ +--+-+ | | +----+---+-+ +--+-+ | |||
| CoA2| | | | Home Link | CoA2| | | | Home Link | |||
| +--+--+ | | ------+------ | +--+--+ | | ------+------ | |||
| | MN +========+ | | | MN +--------+ | | |||
| +--+--+ CoA1 | | +--+--+ CoA1 | | |||
| CoA3| | | CoA3| | | |||
| +---------------+ | +---------------+ | |||
| Binding Cache Database: | Binding Cache Database: | |||
| home agent's binding (Proxy neighbor advertisement is active) | home agent's binding (Proxy neighbor advertisement is active) | |||
| binding [2001:db8::EUI care-of address1 BID1] | binding [2001:db8::EUI care-of address1 BID1] | |||
| binding [2001:db8::EUI care-of address2 BID2] | binding [2001:db8::EUI care-of address2 BID2] | |||
| binding [2001:db8::EUI care-of address3 BID3] | binding [2001:db8::EUI care-of address3 BID3] | |||
| correspondent node's binding | correspondent node's binding | |||
| skipping to change at page 8, line 12 | skipping to change at page 8, line 12 | |||
| particular care-of address. However, the binding cache lookup using | particular care-of address. However, the binding cache lookup using | |||
| policy or flow filters is out of scope for this document. If no such | policy or flow filters is out of scope for this document. If no such | |||
| mechanism is available and no BID is found for a packet, a node | mechanism is available and no BID is found for a packet, a node | |||
| SHOULD use the binding which was last verified by receiving data | SHOULD use the binding which was last verified by receiving data | |||
| packets or signaling from the mobile node. In case the binding cache | packets or signaling from the mobile node. In case the binding cache | |||
| lookup for data packets, using the combination of home address and | lookup for data packets, using the combination of home address and | |||
| BID, does not return a valid binding cache entry, the home agent | BID, does not return a valid binding cache entry, the home agent | |||
| SHOULD perform the lookup based on only the home address as described | SHOULD perform the lookup based on only the home address as described | |||
| in [RFC-3775]. | in [RFC-3775]. | |||
| In any case, to avoid problems with upper layer protocols and TCP in | ||||
| particular, a single packet flow as identified by the 5-tuple SHOULD | ||||
| only be sent to a single care-of address at a time. | ||||
| The mobile node may return to the home link through one of its | The mobile node may return to the home link through one of its | |||
| interfaces. There are two options possible for the mobile node when | interfaces. There are two options possible for the mobile node when | |||
| its returns home. Section 5.6 and Section 5.5.1 describe the | its returns home. Section 5.6 and Section 5.5.1 describe the | |||
| returning home procedures in more detail. | returning home procedures in more detail. | |||
| 1. The mobile node uses only the interface with which it attaches to | 1. The mobile node uses only the interface with which it attaches to | |||
| the home link. This is illustrated in Figure 2. It de-registers | the home link. This is illustrated in Figure 2. It de-registers | |||
| all bindings with the home agent related to all care-of | all bindings with the home agent related to all care-of | |||
| addresses. The interfaces still attached to the visited link(s) | addresses. The interfaces still attached to the visited link(s) | |||
| are no longer going to be receiving any encapsulated traffic from | are no longer going to be receiving any encapsulated traffic from | |||
| skipping to change at page 8, line 40 | skipping to change at page 9, line 14 | |||
| +----+ | +----+ | |||
| | CN | | | CN | | |||
| +--+-+ | +--+-+ | |||
| | | | | |||
| +---+------+ +----+ | +---+------+ +----+ | |||
| +------+ Internet |----------+ HA | | +------+ Internet |----------+ HA | | |||
| | +----+-----+ +--+-+ | | +----+-----+ +--+-+ | |||
| CoA2| | | Home Link | CoA2| | | Home Link | |||
| +--+--+ | --+---+------ | +--+--+ | --+---+------ | |||
| | MN +========+ | | | MN +--------+ | | |||
| +--+--+ CoA1 | | +--+--+ CoA1 | | |||
| | | | | | | |||
| +---------------------------+ | +---------------------------+ | |||
| Binding Cache Database: | Binding Cache Database: | |||
| home agent's binding | home agent's binding | |||
| none | none | |||
| correspondent node's binding | correspondent node's binding | |||
| binding [2001:db8::EUI care-of address1 BID1] | binding [2001:db8::EUI care-of address1 BID1] | |||
| binding [2001:db8::EUI care-of address2 BID2] | binding [2001:db8::EUI care-of address2 BID2] | |||
| skipping to change at page 9, line 4 | skipping to change at page 9, line 25 | |||
| +--+--+ CoA1 | | +--+--+ CoA1 | | |||
| | | | | | | |||
| +---------------------------+ | +---------------------------+ | |||
| Binding Cache Database: | Binding Cache Database: | |||
| home agent's binding | home agent's binding | |||
| none | none | |||
| correspondent node's binding | correspondent node's binding | |||
| binding [2001:db8::EUI care-of address1 BID1] | binding [2001:db8::EUI care-of address1 BID1] | |||
| binding [2001:db8::EUI care-of address2 BID2] | binding [2001:db8::EUI care-of address2 BID2] | |||
| Figure 2: Using only Interface Attached to Home Link | Figure 2: Using only Interface Attached to Home Link | |||
| 2. The mobile node may simultaneously use both the interface | 2. The mobile node may simultaneously use both the interface | |||
| attached to the home link and the interfaces still attached to | attached to the home link and the interfaces still attached to | |||
| the visited link(s) as shown in Figure 3. There are two possible | the visited link(s) as shown in Figure 3. There are two possible | |||
| topologies depending on whether the home agent is only router on | topologies depending on whether the home agent is the only router | |||
| the home link or not. The operation of Neighbor Discovery [RFC- | on the home link or not. The operation of Neighbor Discovery | |||
| 4861] is different in the two topologies. More details can be | [RFC-4861] is different in the two topologies. More details can | |||
| found in Section 5.6. The home agent and the correspondent node | be found in Section 5.6. The home agent and the correspondent | |||
| have the binding entries listed in Figure 3 in their binding | node have the binding entries listed in Figure 3 in their binding | |||
| cache database in both topologies. The home agent also knows | cache database in both topologies. The home agent also knows | |||
| that the mobile node is attached to the home link. All the | that the mobile node is attached to the home link. All the | |||
| traffic from the Internet is intercepted by the home agent first | traffic from the Internet is intercepted by the home agent first | |||
| and routed to either the interface attached to the home link or | and routed to either the interface attached to the home link or | |||
| the one of the foreign links. How the home agent decides to | the one of the foreign links. How the home agent decides to | |||
| route a particular flow to the interface attached to the home | route a particular flow to the interface attached to the home | |||
| link or foreign link is out of scope in this document. | link or foreign link is out of scope in this document. | |||
| Topology-a) | Topology-a) | |||
| +----+ | +----+ | |||
| | CN | | | CN | | |||
| +--+-+ | +--+-+ | |||
| | | | | |||
| +---+------+ +----+ | +---+------+ +----+ | |||
| +------+ Internet |----------+ HA | | +------+ Internet |----------+ HA | | |||
| | +----+-----+ +--+-+ | | +----+-----+ +--+-+ | |||
| CoA2| | | Home Link | CoA2| | | Home Link | |||
| +--+--+ | --+---+------ | +--+--+ | --+---+------ | |||
| | MN +========+ | | | MN +--------+ | | |||
| +--+--+ CoA1 | | +--+--+ CoA1 | | |||
| | | | | | | |||
| +---------------------------+ | +---------------------------+ | |||
| Topology-b) | Topology-b) | |||
| +----+ | +----+ | |||
| | CN | | | CN | | |||
| +--+-+ | +--+-+ | |||
| | | | | |||
| +---+------+ Router +----+ | +---+------+ Router +----+ | |||
| +------+ Internet |-------R | HA | | +------+ Internet |-------R | HA | | |||
| | +----+-----+ | +--+-+ | | +----+-----+ | +--+-+ | |||
| CoA2| | | | Home Link | CoA2| | | | Home Link | |||
| +--+--+ | --+-+-------+------ | +--+--+ | --+-+-------+------ | |||
| | MN +========+ | | | MN +--------+ | | |||
| +--+--+ CoA1 | | +--+--+ CoA1 | | |||
| | | | | | | |||
| +---------------------------+ | +---------------------------+ | |||
| Binding Cache Database: | Binding Cache Database: | |||
| home agent's binding | home agent's binding | |||
| binding [2001:db8::EUI care-of address1 BID1] | binding [2001:db8::EUI care-of address1 BID1] | |||
| binding [2001:db8::EUI care-of address2 BID2] | binding [2001:db8::EUI care-of address2 BID2] | |||
| correspondent node's binding | correspondent node's binding | |||
| binding [2001:db8::EUI care-of address1 BID1] | binding [2001:db8::EUI care-of address1 BID1] | |||
| binding [2001:db8::EUI care-of address2 BID2] | binding [2001:db8::EUI care-of address2 BID2] | |||
| Figure 3: Simultaneous Home and Visited Link Operation | Figure 3: Simultaneous Home and Visited Link Operation | |||
| This specification keeps backwards compatibility with [RFC-3775]. If | ||||
| a receiver (either home agent or correspondent node) does not support | ||||
| this specification, it does not understand the binding identifier | ||||
| mobility option. The receiver skip the unknown mobility option (i.e. | ||||
| Binding Identifier mobility option) and process the Binding Update as | ||||
| defined in [RFC-3775]. In order to keep the backward compatibility | ||||
| with [RFC-3775], when a mobile node sends a Binding Update message | ||||
| with extensions described in this document, the receiver needs to | ||||
| reflect the Binding Identifier mobility option in the Binding | ||||
| Acknowledgement. If the mobile node finds no Binding Identifier | ||||
| mobility options in the received Binding Acknowledgement, it assumes | ||||
| the other end node does not support this specification. In such | ||||
| case, the mobile node needs to fall back to the legacy RFC-3775 | ||||
| compliant mobile node. If it is the home registration, the mobile | ||||
| node MAY try to discover another home agent supporting BID mobility | ||||
| option for the home registration. | ||||
| 4. Mobile IPv6 Extensions | 4. Mobile IPv6 Extensions | |||
| This section summarizes the extensions to Mobile IPv6 necessary for | This section summarizes the extensions to Mobile IPv6 necessary for | |||
| manage multiple bindings. | manage multiple bindings. | |||
| 4.1. Binding Cache Structure and Binding Update List | 4.1. Binding Cache Structure and Binding Update List | |||
| The BID is required to be stored in the binding cache and binding | The BID is required to be stored in the binding cache and binding | |||
| update list structure. | update list structure. | |||
| The sequence number value MUST be shared among all the binding update | The sequence number value MUST be shared among all the binding update | |||
| list entries related to binding updates sent to a particular home | list entries related to binding updates sent to a particular home | |||
| agent or correspondent node. Whenever a mobile node sends either | agent or correspondent node. Whenever a mobile node sends either an | |||
| individual or bulk binding update, the sequence number is | individual or a bulk binding update, the sequence number is | |||
| incremented. When a home agent receives an individual BU, it should | incremented. When a home agent receives an individual BU, it should | |||
| update the sequence number for all the bindings for a particular | update the sequence number for all the bindings for a particular | |||
| mobile node with the sequence number in the received BU. | mobile node with the sequence number in the received BU. | |||
| 4.2. Binding Identifier Mobility Option | 4.2. Binding Update Message | |||
| This specification extends the Binding Update message with a new | ||||
| flag. The flag is shown and described below. | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Sequence # | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| |A|H|L|K|M|R|P|F|T|O| Reserved | Lifetime | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | | | ||||
| . . | ||||
| . Mobility options . | ||||
| . . | ||||
| | | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Figure 4: Binding Update message | ||||
| Overwrite (O) flag | ||||
| When this flag is set, all the binding cache entries for a mobile | ||||
| node are replaced by new entries registering with this binding | ||||
| update message. This flag is only used when BID Mobility Option | ||||
| is carried with Binding Update. | ||||
| Reserved | ||||
| 6 bits Reserved field. | ||||
| 4.3. Binding Identifier Mobility Option | ||||
| The Binding Identifier mobility option is included in the Binding | The Binding Identifier mobility option is included in the Binding | |||
| Update, Binding Acknowledgement, Binding Refresh Request, and Care-of | Update, Binding Acknowledgement, Binding Refresh Request, and Care-of | |||
| Test Init and Care-of Test message. The Binding Identifier Mobility | Test Init and Care-of Test message. The Binding Identifier Mobility | |||
| Option has an alignment requirement of 2n if the Care-of Address | Option has an alignment requirement of 2n if the Care-of Address | |||
| field is not present. Otherwise, it has the alignment requirement of | field is not present. Otherwise, it has the alignment requirement of | |||
| 8n + 2. | 8n + 2. | |||
| 1 2 3 | 1 2 3 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Type = TBD | Length | | | Type = TBD | Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Binding ID (BID) | Status |O|H| Reserved | | | Binding ID (BID) | Status |H| Reserved | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ | |||
| + + | + + | |||
| : IPv4 or IPv6 care-of address (CoA) : | : IPv4 or IPv6 care-of address (CoA) : | |||
| + + | + + | |||
| +---------------------------------------------------------------+ | +---------------------------------------------------------------+ | |||
| Figure 4: BID Mobility Option | Figure 5: BID Mobility Option | |||
| Type | Type | |||
| Type value for Binding Identifier is TBD | Type value for Binding Identifier is TBD | |||
| Length | Length | |||
| 8-bit unsigned integer. Length of the option, in octets, | 8-bit unsigned integer. Length of the option, in octets, | |||
| excluding the Type and Length fields. It MUST be set to either 4, | excluding the Type and Length fields. It MUST be set to either 4, | |||
| 12, or 20 depending on the care-of address field. When the | 8, or 20 depending on the care-of address field. When the care-of | |||
| care-of address is not carried by this option, the length value | address is not carried by this option, the length value MUST be | |||
| MUST be set to 4. If the IPv4 care-of address is stored in the | set to 4. If the IPv4 care-of address is stored in the care-of | |||
| care-of address field, the length MUST be 12. Otherwise, the | address field, the length MUST be 8. Otherwise, the Length value | |||
| Length value MUST be set to 20 for IPv6 care-of address. | MUST be set to 20 for IPv6 care-of address. | |||
| Binding ID (BID) | Binding ID (BID) | |||
| The BID which is assigned to the binding indicated by the care-of | The BID which is assigned to the binding indicated by the care-of | |||
| address in the Binding Update or the BID mobility option. The BID | address in the Binding Update or the BID mobility option. The BID | |||
| is a 16-bit unsigned integer. The value of zero is reserved and | is a 16-bit unsigned integer. The value of zero is reserved and | |||
| MUST NOT be used. | SHOULD NOT be used. | |||
| Status | Status | |||
| The Status field is an 8-bit unsigned integer. When the Binding | The Status field is an 8-bit unsigned integer. When the Binding | |||
| Identifier mobility option is included in a Binding | Identifier mobility option is included in a Binding | |||
| Acknowledgement, this field overwrites the status field in the | Acknowledgement, this field overwrites the status field in the | |||
| Binding Acknowledgement only for this BID. If this field is set | Binding Acknowledgement only for this BID. If this field is set | |||
| to zero, the receiver ignores this field and uses the registration | to zero, the receiver ignores this field and uses the registration | |||
| status stored in the Binding Acknowledgement message. The | status stored in the Binding Acknowledgement message. The | |||
| receiver MUST ignore this field if the Binding Identifier mobility | receiver MUST ignore this field if the Binding Identifier mobility | |||
| option is not carried within either the Binding Acknowledgement or | option is not carried within either the Binding Acknowledgement or | |||
| the Care-of Test messages. The possible status codes are the same | the Care-of Test messages. The possible status codes are the same | |||
| as the status codes of Binding Acknowledgement. This Status field | as the status codes of Binding Acknowledgement. This Status field | |||
| is also used to carry error information related to the care-of | is also used to carry error information related to the care-of | |||
| address test in the Care-of Test message. | address test in the Care-of Test message. | |||
| Overwrite (O) flag | ||||
| When this flag is set, all the binding cache entries for a mobile | ||||
| node are replaced by new entries registering with this binding | ||||
| update message. This flag is only used when BID Mobility Option | ||||
| is carried with Binding Update. | ||||
| Simultaneous Home and Foreign Binding (H) flag | Simultaneous Home and Foreign Binding (H) flag | |||
| This flag indicates that the mobile node registers multiple | This flag indicates that the mobile node registers multiple | |||
| bindings to the home agent while is attached to the home link. | bindings to the home agent while is attached to the home link. | |||
| This flag is valid only for a Binding Update sent to the home | This flag is valid only for a Binding Update sent to the home | |||
| agent. | agent. | |||
| Reserved | Reserved | |||
| 5 bits Reserved field. The value MUST be initialized to zero by | 7 bits Reserved field. The value MUST be initialized to zero by | |||
| the sender, and MUST be ignored by the receiver. | the sender, and SHOULD be ignored by the receiver. | |||
| Care-of Address | Care-of Address | |||
| If a Binding Identifier mobility option is included in a Binding | If a Binding Identifier mobility option is included in a Binding | |||
| Update, either IPv4 or IPv6 care-of address for the corresponding | Update, either IPv4 or IPv6 care-of address for the corresponding | |||
| BID can be stored in this field. If no address is specified in | BID can be stored in this field. If no address is specified in | |||
| this field, the length of this field MUST be zero (i.e. not | this field, the length of this field MUST be zero (i.e. not | |||
| appeared in the option). If no address is specified in this | appeared in the option). If no address is specified in this | |||
| field, a care-of address is taken from the source address of the | field, a care-of address is taken from the source address of the | |||
| IPv6 header. If the option is included in any other messages than | IPv6 header. If the option is included in any other messages than | |||
| a Binding Update, the length of this field MUST be also zero. | a Binding Update, the length of this field MUST be also zero. | |||
| 4.3. New Status Values for Binding Acknowledgement | 4.4. New Status Values for Binding Acknowledgement | |||
| New status values for the status field in a Binding Acknowledgement | New status values for the status field in a Binding Acknowledgement | |||
| are defined for handling the multiple Care-of Addresses registration: | are defined for handling the multiple Care-of Addresses registration: | |||
| MCOA NOTCOMPLETE (TBD less than 128) | MCOA NOTCOMPLETE (TBD less than 128) | |||
| In bulk registration, not all the binding identifier mobility | In bulk registration, not all the binding identifier mobility | |||
| option are successfully registered. Some of them are rejected. | options were successfully registered. Some of them were rejected. | |||
| The error status value of the failed mobility option is | The error status value of the failed mobility option is | |||
| individually stored in the status field of the binding identifier | individually stored in the status field of the binding identifier | |||
| mobility option. | mobility option. | |||
| MCOA RETURNHOME WO/NDP (TBD less than 128) | MCOA RETURNHOME WO/NDP (TBD less than 128) | |||
| When a mobile node returns home, it MUST NOT use NDP for the home | When a mobile node returns home, it MUST NOT use Neighbor | |||
| address on the home link. This is explained in more detail in | Discovery Protocol for the home address on the home link. This is | |||
| Section 5.6 | explained in more detail in Section 5.6 | |||
| MCOA MALFORMED (TBD more than 128) | MCOA MALFORMED (TBD more than 128) | |||
| Registration failed because Binding Identifier mobility option was | Registration failed because Binding Identifier mobility option was | |||
| not formatted correctly. | not formatted correctly. This value is used in the following | |||
| cases. | ||||
| * when the wrong length value is specified (neither 4, 8 nor 20) | ||||
| in the length field of the Binding Identifier mobility option. | ||||
| * when a unicast routable address is not specified in the care-of | ||||
| address field of the Binding Identifier mobility option. | ||||
| * when a care-of address is not appeared in the care-of address | ||||
| field of the Binding Identifier mobility option stored in an | ||||
| IPsec ESP protected Binding Update. | ||||
| MCOA BID CONFLICT (TBD more than 128) | MCOA BID CONFLICT (TBD more than 128) | |||
| The home agent cannot cache both a regular binding and a BID | The home agent cannot cache both a regular binding and a BID | |||
| extended binding simultaneously. It returns this status value | extended binding simultaneously. It returns this status value | |||
| when the received binding conflicts with the existing binding | when the received binding conflicts with the existing binding | |||
| cache entry(ies). | cache entry(ies). | |||
| MCOA PROHIBITED(TBD more than 128) | MCOA PROHIBITED(TBD more than 128) | |||
| It implies the multiple care-of address registration is | It implies the multiple care-of address registration is | |||
| administratively prohibited. | administratively prohibited. | |||
| MCOA BULK REGISTRATION PROHIBITED(TBD more than 128) | MCOA BULK REGISTRATION PROHIBITED(TBD more than 128) | |||
| Bulk binding registration is not either permitted or supported. | Bulk binding registration is not either permitted or supported. | |||
| Note that the bulk registration is optional procedure and might | Note that the bulk registration is an optional procedure and might | |||
| not be available on a home agent. | not be available on a home agent. | |||
| MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED (TBD more than 128) | MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED (TBD more than 128) | |||
| Simultaneous home and foreign attachment is neither supported nor | Simultaneous home and foreign attachment is neither supported nor | |||
| permitted. | permitted. | |||
| 5. Mobile Node Operation | 5. Mobile Node Operation | |||
| 5.1. Management of Care-of Address(es) and Binding Identifier(s) | 5.1. Management of Care-of Address(es) and Binding Identifier(s) | |||
| skipping to change at page 15, line 32 | skipping to change at page 17, line 32 | |||
| of the announced prefixes. | of the announced prefixes. | |||
| The difference between the above two cases is only in the number of | The difference between the above two cases is only in the number of | |||
| physical network interfaces and therefore irrelevant in this | physical network interfaces and therefore irrelevant in this | |||
| document. What is of significance is the fact that the mobile node | document. What is of significance is the fact that the mobile node | |||
| has several addresses it can use as care-of addresses. | has several addresses it can use as care-of addresses. | |||
| A mobile node assigns a BID to each care-of address when it wants to | A mobile node assigns a BID to each care-of address when it wants to | |||
| register them simultaneously with its home address. The BID MUST be | register them simultaneously with its home address. The BID MUST be | |||
| unique for a given home address and care-of address pair. The value | unique for a given home address and care-of address pair. The value | |||
| should be an integer between 1 and 65535. Zero value MUST NOT be | should be an integer between 1 and 65535. Zero value SHOULD NOT be | |||
| used as BIDs. If a mobile node has only one care-of address, the | used as BIDs. If a mobile node has only one care-of address, the | |||
| assignment of a BID is not needed until it has multiple care-of | assignment of a BID is not needed until it has multiple care-of | |||
| addresses to register with, at which time all of the care-of | addresses to register with, at which time all of the care-of | |||
| addresses MUST be mapped to BIDs. | addresses MUST be mapped to BIDs. | |||
| 5.2. Binding Registration | 5.2. Binding Registration | |||
| For the multiple Care-of Addresses registration, the mobile node MUST | For the multiple Care-of Addresses registration, the mobile node MUST | |||
| include a Binding Identifier mobility option(s) in the Binding Update | include a Binding Identifier mobility option(s) in the Binding Update | |||
| as shown in Figure 5. The BID is copied from a corresponding Binding | as shown in Figure 6. The BID is copied from a corresponding Binding | |||
| Update List entry to the BID field of the Binding Identifier mobility | Update List entry to the BID field of the Binding Identifier mobility | |||
| option. When IPsec ESP is used for protecting the Binding Update, | option. | |||
| the care-of address can be carried in the Care-of Address field of | ||||
| the Binding Identifier mobility option. If this is done, the | When IPsec ESP is used for protecting the Binding Update, a care-of | |||
| alternate care-of address option MUST NOT be included in the Binding | address MUST be carried in an alternate care-of address mobility | |||
| Update. For binding registration to a correspondent node, the mobile | option as described in [RFC-4877]. However, in this specification, | |||
| node MUST have both active Home and Care-of Keygen tokens for Kbm | the care-of address MUST be carried in the Care-of Address field of | |||
| (see Section 5.2.5 of [RFC-3775]) before sending the Binding Update. | the Binding Identifier mobility option. In order to save bits of the | |||
| The care-of Keygen tokens MUST be maintained for each care-of address | Binding Update, the alternate care-of address option MUST NOT be | |||
| that the mobile node wants to register to the correspondent node. | included. | |||
| For binding registration to a correspondent node, the mobile node | ||||
| MUST have both active Home and Care-of Keygen tokens for Kbm (see | ||||
| Section 5.2.5 of [RFC-3775]) before sending the Binding Update. The | ||||
| care-of Keygen tokens MUST be maintained for each care-of address | ||||
| that the mobile node wants to register to the correspondent node. | ||||
| The Binding Update to the correspondent node is protected by the | The Binding Update to the correspondent node is protected by the | |||
| Binding Authorization Data mobility option that is placed after the | Binding Authorization Data mobility option that is placed after the | |||
| Binding Identifier mobility option. | Binding Identifier mobility option. | |||
| IPv6 header (src="" class="delete">oA, dst=HA) | IPv6 header (src="" class="insert">are-of Address, dst=Home Agent Address) | |||
| IPv6 Home Address Option | IPv6 Home Address Option | |||
| ESP Header* | ESP Header* | |||
| Mobility header | Mobility header | |||
| Binding Update | Binding Update | |||
| Mobility Options | Mobility Options | |||
| Binding Identifier mobility option | Binding Identifier mobility option | |||
| Binding Authorization mobility option+ | Binding Authorization mobility option+ | |||
| (*) if necessary, for home registration | (*) if necessary, for home registration | |||
| (+) if necessary, for route optimization | (+) if necessary, for route optimization | |||
| Figure 5: Binding Update for Binding Registration | Figure 6: Binding Update for Binding Registration | |||
| If the mobile node wants to replace existing registered bindings on | If the mobile node wants to replace existing registered bindings on | |||
| the home agent with the single binding in the sent Binding Update, it | the home agent with the single binding in the sent Binding Update, it | |||
| sets the 'O' flag. Section 6.2 describes this registration procedure | sets the 'O' flag. Section 6.2 describes this registration procedure | |||
| in detail. | in detail. | |||
| 5.3. Bulk Registration | 5.3. Bulk Registration | |||
| Bulk registration is an optimization for binding multiple care-of | Bulk registration is an optimization for binding multiple care-of | |||
| addresses to a home address using a single Binding Update. This is | addresses to a home address using a single Binding Update. This is | |||
| very useful if the mobile node, for instance, does not want to send a | very useful if the mobile node, for instance, does not want to send a | |||
| lot of signaling messages through an interface where the bandwidth is | lot of signaling messages through an interface where the bandwidth is | |||
| scarce. This document specifies bulk registration only for the | scarce. This document specifies bulk registration only for the | |||
| mobile node's home registration. A mobile node performing bulk | mobile node's home registration. A mobile node performing bulk | |||
| registration with a correspondent node is out of scope. | registration with a correspondent node is out of scope. | |||
| To use bulk registration, the mobile node includes a Binding | To use bulk registration, the mobile node includes a Binding | |||
| Identifier Mobility option for each BID and Care-of address pair it | Identifier Mobility option for each BID and Care-of address pair it | |||
| wants to register in the same Binding Update message. This is shown | wants to register in the same Binding Update message. This is shown | |||
| in Figure 6. The rest of the fields and options in the Binding | in Figure 7. The rest of the fields and options in the Binding | |||
| Update such as Lifetime, Sequence Number, and the flags in the | Update such as Lifetime, Sequence Number, and the flags in the | |||
| Binding Update are common across all care-of addresses. The | Binding Update are common across all care-of addresses. | |||
| alternate care-of address option MUST NOT be used. | ||||
| IPv6 header (src="" dst=HA) | When IPsec ESP is used for protecting the Binding Update, a care-of | |||
| address MUST be carried in an alternate care-of address mobility | ||||
| option as described in [RFC-4877]. However, in the bulk | ||||
| registration, the care-of addresses are always carried in the Care-of | ||||
| Address field of the Binding Identifier mobility option. In order to | ||||
| save bits of the Binding Update, the alternate care-of address option | ||||
| MUST NOT be included in such Binding Update. | ||||
| IPv6 header (src="" Address, dst=Home Agent Address) | ||||
| IPv6 Home Address Option | IPv6 Home Address Option | |||
| ESP Header | ESP Header | |||
| Mobility header | Mobility header | |||
| Binding Update | Binding Update | |||
| Mobility Options | Mobility Options | |||
| Binding Identifier mobility options (CoA) | Binding Identifier (including Care-of Address) | |||
| Figure 6: Binding Update for Bulk Registration | ||||
| Figure 7: Binding Update for Bulk Registration | ||||
| If the mobile node wants to replace existing registered bindings on | If the mobile node wants to replace existing registered bindings on | |||
| the home agent with the multiple bindings in the sent Binding Update, | the home agent with the multiple bindings in the sent Binding Update, | |||
| it sets the 'O' flag. | it sets the 'O' flag in the Binding Update. | |||
| 5.4. Binding De-Registration | 5.4. Binding De-Registration | |||
| When a mobile node decides to delete all the bindings for its home | When a mobile node decides to delete all the bindings for its home | |||
| address, it sends a regular de-registration Binding Update with | address, it sends a regular de-registration Binding Update with | |||
| lifetime set to zero as defined in [RFC-3775]. The Binding | lifetime set to zero as defined in [RFC-3775]. The Binding | |||
| Identifier mobility option is not required. | Identifier mobility option is not required. | |||
| If a mobile node wants to delete a particular binding(s) from its | If a mobile node wants to delete a particular binding(s) from its | |||
| home agent and correspondent nodes, the mobile node sends a Binding | home agent and correspondent nodes, the mobile node sends a Binding | |||
| skipping to change at page 17, line 50 | skipping to change at page 20, line 14 | |||
| described in Section 5.4. After the de-registration step, all the | described in Section 5.4. After the de-registration step, all the | |||
| packets routed by the home agent are only forwarded to the interface | packets routed by the home agent are only forwarded to the interface | |||
| attached to the home link, even if there are other active interfaces | attached to the home link, even if there are other active interfaces | |||
| attached to the visited link(s). While the mobile node de-registers | attached to the visited link(s). While the mobile node de-registers | |||
| all the bindings from the home agent, it may continue registering | all the bindings from the home agent, it may continue registering | |||
| bindings for interface(s) attached to visited link(s) to the | bindings for interface(s) attached to visited link(s) to the | |||
| correspondent node as shown in Figure 2. | correspondent node as shown in Figure 2. | |||
| 5.5.2. Using only Interface attached to the Visited Link | 5.5.2. Using only Interface attached to the Visited Link | |||
| The mobile node returns home in physically and shuts down the | The mobile node returns home physically but shuts down the interface | |||
| interface attached to the home link. As a result, a mobile node does | attached to the home link. As a result, a mobile node does not | |||
| not return home even though it attaches to the home link by one of | return home even though it attaches to the home link by one of | |||
| interfaces. Following procedures should be taken by the mobile node. | interfaces. Following procedures should be taken by the mobile node. | |||
| Before shutting down the interface, any binding for the care-of | Before shutting down the interface, any binding for the care-of | |||
| address previously associated with the interface should be deleted. | address previously associated with the interface should be deleted. | |||
| To delete the binding cache entry, the mobile node SHOULD send a de- | To delete the binding cache entry, the mobile node SHOULD send a de- | |||
| registration Binding Update with the lifetime set to zero and include | registration Binding Update with the lifetime set to zero and include | |||
| the corresponding BID information. If the mobile node does not send | the corresponding BID information. If the mobile node does not send | |||
| a de-registration Binding Update, the binding for the care-of address | a de-registration Binding Update, the binding for the care-of address | |||
| previously assigned to the interface remains at the home agent until | previously assigned to the interface remains at the home agent until | |||
| its lifetime expires. | its lifetime expires. | |||
| skipping to change at page 18, line 28 | skipping to change at page 20, line 40 | |||
| 5.6. Returning Home: Simultaneous Home and Visited Link Operation | 5.6. Returning Home: Simultaneous Home and Visited Link Operation | |||
| 5.6.1. Problems of Simultaneous Home and Foreign Attachments | 5.6.1. Problems of Simultaneous Home and Foreign Attachments | |||
| The mobile node returns home and continues using all the interfaces | The mobile node returns home and continues using all the interfaces | |||
| attached to both foreign and home links as shown in Figure 3. The | attached to both foreign and home links as shown in Figure 3. The | |||
| mobile node indicates this by setting the 'H' flag in the BID | mobile node indicates this by setting the 'H' flag in the BID | |||
| mobility option as defined below. There are additional requirements | mobility option as defined below. There are additional requirements | |||
| on the Returning Home procedures for possible Neighbor Discovery | on the Returning Home procedures for possible Neighbor Discovery | |||
| states conflicts at the home link. | state conflicts at the home link. | |||
| In [RFC-3775], the home agent intercepts packets meant for the mobile | In [RFC-3775], the home agent intercepts packets meant for the mobile | |||
| node using the Proxy Neighbor Discovery [RFC-4861] while the mobile | node using Proxy Neighbor Discovery [RFC-4861] while the mobile node | |||
| node is away from the home link. When the mobile node returns home, | is away from the home link. When the mobile node returns home, the | |||
| the home agent deletes the binding cache and stops proxying for the | home agent deletes the binding cache and stops proxying for the home | |||
| home address so that a mobile node can configure its home address on | address so that a mobile node can configure its home address on the | |||
| the interface attached to the home link. In this specification, a | interface attached to the home link. In this specification, a mobile | |||
| mobile node may return home, configure the home address on the | node may return home, configure the home address on the interface | |||
| interface attached to the home link, but still use the interfaces | attached to the home link, but still use the interfaces attached to | |||
| attached to the foreign links. In this case, a possible conflict | the foreign links. In this case, a possible conflict arises when the | |||
| arises when the both the home agent and the mobile node try to defend | both the home agent and the mobile node try to defend the home | |||
| the home address. If the home agent stops proxying for the home | address. If the home agent stops proxying for the home address, the | |||
| address, the packets are always routed to the interface attached to | packets are always routed to the interface attached to the home link | |||
| the home link and are never routed to the interfaces attached to the | and are never routed to the interfaces attached to the visited links. | |||
| visited links. It is required to avoid the conflict between the home | It is required to avoid the conflict between the home agent and the | |||
| agent and the mobile node, while still allowing the simultaneous use | mobile node, while still allowing the simultaneous use of home and | |||
| of home and foreign links. The following describes the mechanism for | foreign links. The following describes the mechanism for achieving | |||
| achieving this. | this. | |||
| 5.6.2. Overview and Approach | 5.6.2. Overview and Approach | |||
| In this specification, the home agent MUST intercept all the packets | In this specification, the home agent MUST intercept all the packets | |||
| meant for the mobile node and decide whether to send the traffic | meant for the mobile node and decide whether to send the traffic | |||
| directly to the home address on the link or tunnel to the care-of | directly to the home address on the link or tunnel to the care-of | |||
| address. The home agent intercepts all the packets even when the | address. The home agent intercepts all the packets even when the | |||
| mobile node is attached to the home link through one of its | mobile node is attached to the home link through one of its | |||
| interfaces. The home agent would make this decision based on the | interfaces. The home agent would make this decision based on the | |||
| type of flow. How to make this decision is out of scope in this | type of flow. How to make this decision is out of scope in this | |||
| skipping to change at page 19, line 22 | skipping to change at page 21, line 34 | |||
| Home Agent is the only router at the home link or not. The | Home Agent is the only router at the home link or not. The | |||
| difference is on who defends the home address by (Proxy) Neighbor | difference is on who defends the home address by (Proxy) Neighbor | |||
| Discovery on the home link. | Discovery on the home link. | |||
| 1. Mobile node defends the home address by the regular Neighbor | 1. Mobile node defends the home address by the regular Neighbor | |||
| Discovery Protocol (illustrated as topology-a in Figure 3). The | Discovery Protocol (illustrated as topology-a in Figure 3). The | |||
| home agent is the only router on the home link. Therefore the | home agent is the only router on the home link. Therefore the | |||
| home agent is capable of intercepting packets without relying on | home agent is capable of intercepting packets without relying on | |||
| the proxy Neighbor Discovery protocol and the mobile node can | the proxy Neighbor Discovery protocol and the mobile node can | |||
| manage the Neighbor Cache entry of the home address on the home | manage the Neighbor Cache entry of the home address on the home | |||
| link as a regular IPv6 node.　However, there is one | link as a regular IPv6 node. However, there is one limitation of | |||
| limitation of this scenario. If a correspondent node is located | this scenario. If a correspondent node is located at the home | |||
| at the home link, the home agent may not intercept the packets | link, the home agent may not intercept the packets destined to | |||
| destined to the mobile node. These packets are routed only via | the mobile node. These packets are routed only via the home | |||
| the home link, but this is most optimized path for the mobile | link, but this is the most optimal path for the mobile node to | |||
| node to communicate with nodes on the home link. | communicate with nodes on the home link. | |||
| 2. If there are other routers on the home link apart from the home | 2. If there are other routers on the home link apart from the home | |||
| agent, then it cannot be guaranteed that all packets meant for | agent, then it cannot be guaranteed that all packets meant for | |||
| the mobile node are routed to the home agent. In this case, the | the mobile node are routed to the home agent. In this case, the | |||
| mobile node MUST NOT operate Neighbor Discovery protocol for the | mobile node MUST NOT operate the Neighbor Discovery protocol for | |||
| home address on the home link. This allows the home agent to | the home address on the home link. This allows the home agent to | |||
| keep using proxy neighbor discovery and thus it keeps receiving | keep using proxy neighbor discovery and thus it keeps receiving | |||
| all the packets sent to the mobile node's home address. If the | all the packets sent to the mobile node's home address. If the | |||
| home agent, according to its local policy, needs to deliver | home agent, according to its local policy, needs to deliver | |||
| packets to the mobile node over the home link, an issue arises | packets to the mobile node over the home link, an issue arises | |||
| with respect to how the home agent discovers the mobile node's | with respect to how the home agent discovers the mobile node's | |||
| link local address. This specification uses Link-layer Address | link local address. This specification uses the Link-layer | |||
| (LLA) Option defined in [RFC-5268] in order to carry the mobile | Address (LLA) Option defined in [RFC-5268] in order to carry the | |||
| node's link-layer address in the Binding Update. Likewise, the | mobile node's link-layer address in the Binding Update. | |||
| mobile node would also know the link-layer address of the default | Likewise, the mobile node would also know the link-layer address | |||
| router address to send packets from the home link without | of the default router address to send packets from the home link | |||
| Neighbor Discovery. The link-layer address is used to transmit | without Neighbor Discovery. The link-layer address is used to | |||
| packets from and to the mobile node on the home link. The | transmit packets from and to the mobile node on the home link. | |||
| packets are transmitted without the Neighbor Discovery protocol | The packets are transmitted without the Neighbor Discovery | |||
| by constructing the link-layer header manually. This operation | protocol by constructing the link-layer header manually. This | |||
| is similar to Mobile IPv6 [RFC-3775] when a mobile node sends a | operation is similar to Mobile IPv6 [RFC-3775] when a mobile node | |||
| deregistration binding update to the home agent's link-layer | sends a deregistration binding update to the home agent's link- | |||
| address in returning home operation. | layer address in the operation for returning home. | |||
| 5.6.3. Sending Deregistration Binding Update | 5.6.3. Sending Deregistration Binding Update | |||
| o As soon as a mobile node returns home, it sends a de-registration | o As soon as a mobile node returns home, it sends a de-registration | |||
| Binding Update to the home agent from the interface attached to | Binding Update to the home agent from the interface attached to | |||
| the home link. | the home link. | |||
| o The mobile node MUST include the BID mobility option specifying | o The mobile node MUST include the BID mobility option specifying | |||
| the BID the mobile node had previously associated with the | the BID the mobile node had previously associated with the | |||
| interface attached to the home link. The 'H' flag MUST be set in | interface attached to the home link. The 'H' flag MUST be set in | |||
| the BID mobility option. For the binding deregistration, a mobile | the BID mobility option. For the binding deregistration, a mobile | |||
| node SHOULD NOT store a care-of address in the Care-of Address | node SHOULD NOT store a care-of address in the Care-of Address | |||
| field of the BID mobility option. The receive, the home agent, | field of the BID mobility option. The receive, the home agent, | |||
| can match the removed binding with BID value in the BID mobility | can match the removed binding with BID value in the BID mobility | |||
| option. If the mobile node has to remove multiple bindings | option. If the mobile node has to remove multiple bindings | |||
| simultaneously, it contains multiple BID mobility options with O | simultaneously, it contains multiple BID mobility options and sets | |||
| flag set. When the 'H' flag is set, the home agent recognizes | 'O' flag in the Binding Update message. When the 'H' flag is set, | |||
| that the mobile node wants to continue using interfaces attached | the home agent recognizes that the mobile node wants to continue | |||
| to both home and visited links. Note that H flag MUST be set for | using interfaces attached to both home and visited links. Note | |||
| all the binding updates sent from the mobile node (ex. Binding | that H flag MUST be set for the subsequent binding updates sent | |||
| Update for the interface(s) attached to the foreign link(s)). If | from the mobile node (ex. Binding Update for the interface(s) | |||
| the home agent does not allow this scenario, it MUST send a | attached to the foreign link(s)). If the home agent does not | |||
| Binding Acknowledgement with the status code [MCOA SIMULTANEOUS | allow this scenario, it MUST send a Binding Acknowledgement with | |||
| HOME AND FOREIGN PROHIBITED] set. | the status code [MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED] | |||
| set. | ||||
| o The mobile node SHOULD include the Link-layer Address (LLA) Option | o The mobile node SHOULD include the Link-layer Address (LLA) Option | |||
| [RFC-5268] to notify the mobile node's link-layer address to the | [RFC-5268] to notify the mobile node's link-layer address to the | |||
| home agent, too. The option code of the Link-layer Address (LLA) | home agent, too. The option code of the Link-layer Address (LLA) | |||
| option MUST be set to '2' (Link-layer Address of the mobile node). | option MUST be set to '2' (Link-layer Address of the mobile node). | |||
| This link-layer address is required for the home agent to send the | This link-layer address is required for the home agent to send the | |||
| Binding Acknowledgement and to forward the mobile node's packet. | Binding Acknowledgement and to forward the mobile node's packet. | |||
| o According to [RFC-3775], the mobile node MUST start responding to | o According to [RFC-3775], the mobile node MUST start responding to | |||
| Neighbor Solicitation for its home address right after it sends | Neighbor Solicitation for its home address right after it sends | |||
| the deregistration Binding Update to the home agent. However, in | the deregistration Binding Update to the home agent. However, in | |||
| this specification, the mobile node MUST NOT respond to Neighbor | this specification, the mobile node MUST NOT respond to Neighbor | |||
| Solicitation before receiving a Binding Acknowledgement, since the | Solicitation before receiving a Binding Acknowledgement, since the | |||
| home agent may continue proxying for the home address. If the | home agent may continue proxying for the home address. If the | |||
| mobile node receives [MCOA RETURNHOME WO/NDP (TBD)] status value | mobile node receives [MCOA RETURNHOME WO/NDP (TBD)] status value | |||
| in the received Binding Acknowledgment, it MUST NOT respond to | in the received Binding Acknowledgment, it MUST NOT respond to | |||
| Neighbor Solicitation even after the Binding Acknowledgement. | Neighbor Solicitation even after the Binding Acknowledgement. | |||
| 5.6.4. Sending Binding Acknowledgement | 5.6.4. Sending Binding Acknowledgement | |||
| The operations described in this section is for Home Agent and not | ||||
| for Mobile Node. However, the Home Agent operations described in | ||||
| this section are related to the returning home using simultaneous use | ||||
| of home and foreign links. | ||||
| o When the home agent sends the Binding Acknowledgement after | o When the home agent sends the Binding Acknowledgement after | |||
| successfully processing the binding de-registration, it MUST set | successfully processing the binding de-registration, it MUST set | |||
| the status value to either 0 [Binding Update Accepted] or to [MCOA | the status value to either 0 [Binding Update Accepted] or to [MCOA | |||
| RETURNHOME WO/NDP (TBD)] in the Status field of the Binding | RETURNHOME WO/NDP (TBD)] in the Status field of the Binding | |||
| Acknowledgment depending on home agent configuration at the home | Acknowledgment depending on home agent configuration at the home | |||
| link. The new values are: | link. The new values are: | |||
| * Binding Update Accepted (0): NDP is permitted for the home | * Binding Update Accepted (0): Neighbor Discovery Protocol is | |||
| address at the home link. This is regular returning home | permitted for the home address at the home link. This is | |||
| operation of [RFC-3775] | regular returning home operation of [RFC-3775] | |||
| * MCOA RETURNHOME WO/NDP (TBD): NDP is prohibited for the home | * MCOA RETURNHOME WO/NDP (TBD): Neighbor Discovery Protocol is | |||
| address at the home link | prohibited for the home address at the home link | |||
| If the binding update is rejected, the appropriate error value | The respective Binding Identifier mobility options need to be | |||
| MUST be set to the status field. In this case, the home agent | included in the Binding Acknowledgement. | |||
| operation is same as [RFC-3775]. | ||||
| o If the binding update is rejected, the appropriate error value | ||||
| MUST be set in the status field. In this case, the home agent | ||||
| operation is the same as [RFC-3775]. | ||||
| o Only if the home agent is certainly the only router in the home | o Only if the home agent is certainly the only router in the home | |||
| link, it MAY turn off Neighbor Discovery for the requested home | link, it MAY turn off Neighbor Discovery for the requested home | |||
| address and responds with the [Binding Update Accepted] status | address and responds with the [Binding Update Accepted] status | |||
| value to the mobile node. Since the mobile node will not reply to | value to the mobile node. Since the mobile node will not reply to | |||
| Neighbor Solicitation for the home address before receiving the | Neighbor Solicitation for the home address before receiving the | |||
| Binding Acknowledgement, the home agent SHOULD use the link-layer | Binding Acknowledgement, the home agent SHOULD use the link-layer | |||
| address carried by the Link Layer Address option [RFC-5268] in the | address carried by the Link Layer Address option [RFC-5268] in the | |||
| received Binding Update. After the completion of the binding | received Binding Update. After the completion of the binding | |||
| deregistration, the mobile node starts regular Neighbor Discovery | deregistration, the mobile node starts regular Neighbor Discovery | |||
| skipping to change at page 21, line 38 | skipping to change at page 24, line 13 | |||
| exchange of Neighbor Solicitation and Neighbor Advertisement. | exchange of Neighbor Solicitation and Neighbor Advertisement. | |||
| o On the other hand, the home agent returns [MCOA RETURNHOME WO/NDP] | o On the other hand, the home agent returns [MCOA RETURNHOME WO/NDP] | |||
| value in the Status field of the BID mobility option. The home | value in the Status field of the BID mobility option. The home | |||
| agent learns the mobile node's link-layer address by receiving the | agent learns the mobile node's link-layer address by receiving the | |||
| link-layer address option carried by the Binding Update. It | link-layer address option carried by the Binding Update. It | |||
| stores the link-layer address as a neighbor cache entry for the | stores the link-layer address as a neighbor cache entry for the | |||
| mobile node so that it can send the packets to the mobile node's | mobile node so that it can send the packets to the mobile node's | |||
| link-layer address. | link-layer address. | |||
| o Note that the use of proxy Neighbor Discovery is easier way to | o Note that the use of proxy Neighbor Discovery is an easier way to | |||
| intercept the mobile nodes' packets instead of IP routing in some | intercept the mobile nodes' packets instead of IP routing in some | |||
| deployment scenarios. Therefore, even if a home agent is the only | deployment scenarios. Therefore, even if a home agent is the only | |||
| router, it is an implementation and operational choice whether the | router, it is an implementation and operational choice whether the | |||
| home agent returns [Binding Update Accepted] or [MCOA RETURNHOME | home agent returns [Binding Update Accepted] or [MCOA RETURNHOME | |||
| WO/NDP]. | WO/NDP]. | |||
| o If BID option is not included in the Binding Acknowledgement, the | o If BID option is not included in the Binding Acknowledgement, the | |||
| home agent might not recognize the simultaneous home and foreign | home agent might not recognize the simultaneous home and foreign | |||
| attachment. The home agent might have processed the de- | attachment. The home agent might have processed the de- | |||
| registration Binding Update as a regular de-registration as | registration Binding Update as a regular de-registration as | |||
| skipping to change at page 22, line 30 | skipping to change at page 25, line 4 | |||
| of the mobile node). A mobile node learns the default router's | of the mobile node). A mobile node learns the default router's | |||
| link-layer address from a Source Link-Layer Address option in | link-layer address from a Source Link-Layer Address option in | |||
| Router Advertisements. The mobile node sends packets directly to | Router Advertisements. The mobile node sends packets directly to | |||
| the default router's link-layer address. This is done by | the default router's link-layer address. This is done by | |||
| constructing the packet including link-layer header with the | constructing the packet including link-layer header with the | |||
| learned link-layer address of the default router. The home agent | learned link-layer address of the default router. The home agent | |||
| also forwards the packet to the mobile node on the home link by | also forwards the packet to the mobile node on the home link by | |||
| using the mobile node's link-layer address. The link-layer | using the mobile node's link-layer address. The link-layer | |||
| address SHOULD be cached when the home agent received the | address SHOULD be cached when the home agent received the | |||
| deregistration Binding Update message. Note that the default | deregistration Binding Update message. Note that the default | |||
| router MUST NOT cache the mobile node's link-layer address as a | router MUST NOT cache the mobile node's link-layer address in the | |||
| neighbor cache when it forwards the packet from the mobile node to | neighbor cache when it forwards the packet from the mobile node to | |||
| the home agent. | the home agent. | |||
| 5.6.6. Leaving from the Home Link | 5.6.6. Leaving from the Home Link | |||
| o When the mobile node detaches from the home link, it SHOULD | o When the mobile node detaches from the home link, it SHOULD | |||
| immediately send a binding update for one of active care-of | immediately send a binding update for one of active care-of | |||
| address with H flag unset. When the 'H' flag of BID option is | address with H flag unset. When the 'H' flag of BID option is | |||
| unset in any Binding Update, the home agent stop forwarding the | unset in any Binding Update, the home agent stop forwarding the | |||
| mobile node's packet to the home link. | mobile node's packets to the home link. | |||
| 5.6.6.1. Changing Behavior during the attachment to the home link | 5.6.6.1. Changing Behavior during the attachment to the home link | |||
| If a mobile node decides to return home completely without any active | If a mobile node decides to return home completely without any active | |||
| foreign link attachment, it simply sends a deregistration binding | foreign link attachment, it simply sends a deregistration binding | |||
| update as described in Section 5.5.1. Once the home agent receives | update as described in Section 5.5.1. Once the home agent receives | |||
| such de-registration binding update, the home agent clears all the | such de-registration binding update, the home agent clears all the | |||
| binding and states for the mobile node. | binding(s) and state for the mobile node. | |||
| If a mobile node decides to stop using the interface attached to the | If a mobile node decides to stop using the interface attached to the | |||
| home link, it simply sends a binding update from the one of active | home link, it simply sends a binding update from one of the active | |||
| care-of address. In the Binding Update, the mobile node should | care-of addresses. In the Binding Update, the mobile node should | |||
| include the BID option for the care-of address and unset the H flag | include the BID option for the care-of address and unset the H flag | |||
| of BID option. The home agent clears the states of the mobile node | of the BID option. The home agent clears the state of the mobile | |||
| for the interface attached to the home link and stop forwarding the | node for the interface attached to the home link and stops forwarding | |||
| packets to the mobile node on the home link. | the packets to the mobile node on the home link. | |||
| 5.7. Receiving Binding Acknowledgement | 5.7. Receiving Binding Acknowledgement | |||
| The verification of a Binding Acknowledgement is the same as Mobile | The verification of a Binding Acknowledgement is the same as Mobile | |||
| IPv6 (section 11.7.3 of [RFC-3775]). The operation for sending a | IPv6 (section 11.7.3 of [RFC-3775]). The operation for sending a | |||
| Binding Acknowledgement is described in Section 6.2. | Binding Acknowledgement is described in Section 6.2. | |||
| If a mobile node includes a Binding Identifier mobility option in a | If a mobile node includes a Binding Identifier mobility option in a | |||
| Binding Update with the 'A' flag set, a Binding Acknowledgement MUST | Binding Update with the 'A' flag set, a Binding Acknowledgement MUST | |||
| carry a Binding Identifier mobility option. According to [RFC-3775], | carry a Binding Identifier mobility option. According to [RFC-3775], | |||
| the receiver of the Binding Update ignores unknown mobility options | the receiver of the Binding Update ignores unknown mobility options | |||
| and process the Binding Update without the unknown mobility option. | and processes the Binding Update without the unknown mobility option. | |||
| Therefore, if no such mobility option is included in the Binding | Therefore, if no such mobility option is included in the Binding | |||
| Acknowledgement in response to a Binding Update for multiple care-of | Acknowledgement in response to a Binding Update for multiple care-of | |||
| address registration, this indicates that the originating node of the | address registration, this indicates that the originating node of the | |||
| Binding Acknowledgement does not support processing the Binding | Binding Acknowledgement does not support processing the Binding | |||
| Identifier mobility option regardless of status value. In such case, | Identifier mobility option regardless of status value. In such case, | |||
| the receiver of the Binding Update may create a regular binding. The | the receiver of the Binding Update may create a regular binding. The | |||
| mobile node then stop multiple care-of address registration with that | mobile node then no longer attempts multiple care-of address | |||
| node. If it is home registration, the mobile node MAY attempt to | registration with that node. If this occurs with home registration | |||
| discover another home agent supporting BID mobility option for the | the mobile node MAY attempt to discover another home agent supporting | |||
| home registration. | BID mobility option for the home registration. | |||
| If a Binding Identifier mobility option is present in the received | If a Binding Identifier mobility option is present in the received | |||
| Binding Acknowledgement, the mobile node checks the status field in | Binding Acknowledgement, the mobile node checks the status field in | |||
| the option. If the status value in the Binding Identifier mobility | the option. If the status value in the Binding Identifier mobility | |||
| option is zero, the mobile node uses the value in the Status field of | option is zero, the mobile node uses the value in the Status field of | |||
| the Binding Acknowledgement. Otherwise, it uses the value in the | the Binding Acknowledgement. Otherwise, it uses the value in the | |||
| Status field of the Binding Identifier mobility option. | Status field of the Binding Identifier mobility option. | |||
| If the status code is greater than or equal to 128, the mobile node | If the status code is greater than or equal to 128, the mobile node | |||
| starts relevant operations according to the error code. Otherwise, | starts relevant operations according to the error code. Otherwise, | |||
| the mobile node assumes that the originator (home agent or | the mobile node assumes that the originator (home agent or | |||
| correspondent node) successfully registered the binding information | correspondent node) successfully registered the binding information | |||
| and BID for the mobile node. | and BID for the mobile node. | |||
| o If the Status value is [MCOA PROHIBITED], the mobile node MUST | o If the Status value is [MCOA PROHIBITED], the mobile node MUST | |||
| stop registering multiple bindings to the node that sent the | stop registering multiple bindings with the node that sent the | |||
| Binding Acknowledgement. | Binding Acknowledgement. | |||
| o If the Status value is [MCOA BULK REGISTRATION NOT SUPPORT], the | o If the Status value is [MCOA BULK REGISTRATION NOT SUPPORT], the | |||
| mobile node SHOULD stop using bulk registrations with the node | mobile node needs to stop using bulk registrations with the node | |||
| that sent the Binding Acknowledgement. | that sent the Binding Acknowledgement. It should assume that none | |||
| of the attempted registrations were successful. | ||||
| o If [MCOA MALFORMED] is specified, it indicates that the binding | o If [MCOA MALFORMED] is specified, it indicates that the binding | |||
| identifier mobility option is formatted wrongly. | identifier mobility option is formatted wrongly presumably due to | |||
| a programming error or major packet corruption. . | ||||
| o If [MCOA BID CONFLICT] is specified, the binding entry specified | o If [MCOA BID CONFLICT] is specified, the binding entry specified | |||
| by the Binding Identifier mobility option is already registered as | by the Binding Identifier mobility option is already registered as | |||
| a regular binding. In such case, the mobile node SHOULD stop | a regular binding. In such case, the mobile node needs to stop | |||
| sending Binding Updates with BID, or SHOULD use the 'O' flag to | sending Binding Updates with BID, or SHOULD use the 'O' flag to | |||
| reset all the registered bindings. | reset all the registered bindings as described in Section 5.9. | |||
| 5.8. Receiving Binding Refresh Request | 5.8. Receiving Binding Refresh Request | |||
| The verification of a Binding Refresh Request is the same as in | The verification of a Binding Refresh Request is the same as in | |||
| Mobile IPv6 (section 11.7.4 of [RFC-3775]). The operation of sending | Mobile IPv6 (section 11.7.4 of [RFC-3775]). The operation of sending | |||
| a Binding Refresh Request is described in section Section 6.3. | a Binding Refresh Request is described in Section 6.3. | |||
| If a mobile node receives a Binding Refresh Request with a Binding | If a mobile node receives a Binding Refresh Request with a Binding | |||
| Identifier mobility option, it indicates that the node sending the | Identifier mobility option, it indicates that the node sending the | |||
| Binding Refresh Request message is requesting the mobile node to send | Binding Refresh Request message is requesting the mobile node to send | |||
| a new Binding Update for the BID. The mobile node SHOULD then send a | a new Binding Update for the BID. The mobile node SHOULD then send a | |||
| Binding Update at least for the respective binding. The mobile node | Binding Update at least for the respective binding. The mobile node | |||
| MUST include a Binding Identifier mobility option in the Binding | MUST include a Binding Identifier mobility option in the Binding | |||
| Update. | Update. | |||
| 5.9. Bootstrapping | 5.9. Bootstrapping | |||
| When a mobile node bootstraps and registers multiple bindings for the | When a mobile node bootstraps and registers multiple bindings for the | |||
| first time, it MUST set the 'O' flag in the Binding Identifier | first time, it MUST set the 'O' flag in the Binding Update message. | |||
| mobility option. If old bindings still exists at the home agent, the | If old bindings still exists at the home agent, the mobile node has | |||
| mobile node has no knowledge of which bindings still exist at the | no knowledge of which bindings still exist at the home agent. This | |||
| home agent. This scenario happens when a mobile node reboots and | scenario happens when a mobile node reboots and loses state regarding | |||
| looses state regarding the registrations. If the 'O' flag is set, | the registrations. If the 'O' flag is set, all the bindings are | |||
| all the bindings are replaced by the new binding(s). If the mobile | replaced by the new binding(s). If the mobile node receives the | |||
| node receives the Binding Acknowledgement with the status code set to | Binding Acknowledgement with the status code set to 135 [Sequence | |||
| 135 [Sequence number out of window], it MUST follow the operations | number out of window], it MUST follow the operations described in | |||
| described in [RFC-3775]. | [RFC-3775]. | |||
| The 'O' flag can also be used in individual Binding Updates sent to | The 'O' flag can also be used in individual Binding Updates sent to | |||
| the correspondent nodes to override any existing binding cache | the correspondent nodes to override any existing binding cache | |||
| entries at the correspondent node. | entries at the correspondent node. | |||
| 6. Home Agent and Correspondent Node Operation | 6. Home Agent and Correspondent Node Operation | |||
| 6.1. Searching Binding Cache with Binding Identifier | 6.1. Searching Binding Cache with Binding Identifier | |||
| If either a correspondent node or a home agent has multiple bindings | If either a correspondent node or a home agent has multiple bindings | |||
| for a mobile node in their binding cache database, it can use any of | for a mobile node in their binding cache database, it can use any of | |||
| the bindings to communicate with the mobile node. This section | the bindings to communicate with the mobile node. This section | |||
| explains how to retrieve the desired binding for the binding | explains how to retrieve the desired binding for the binding | |||
| management. This document does not provide any mechanism to select | management. This document does not provide any mechanism to select | |||
| the suitable binding for forwarding data packets. | the suitable binding for forwarding data packets. | |||
| A node which is either a correspondent node or a home agent SHOULD | A node which is either a correspondent node or a home agent SHOULD | |||
| use both the home address and the BID as the search key of the | use both the home address and the BID as the search key of the | |||
| binding cache if it knows the corresponding BID (ex. when processing | binding cache if it knows the corresponding BID (example: when | |||
| signaling messages). In the example below, if a node searches the | processing signaling messages). In the example below, if a node | |||
| binding with the home address and BID2, it gets binding2 for this | searches the binding with the home address and BID2, it gets binding2 | |||
| mobile node. | for this mobile node. | |||
| binding1 [2001:db8::EUI, care-of address1, BID1] | binding1 [2001:db8::EUI, care-of address1, BID1] | |||
| binding2 [2001:db8::EUI, care-of address2, BID2] | binding2 [2001:db8::EUI, care-of address2, BID2] | |||
| binding3 [2001:db8::EUI, care-of address3, BID3] | binding3 [2001:db8::EUI, care-of address3, BID3] | |||
| Figure 7: Searching the Binding Cache | Figure 8: Searching the Binding Cache | |||
| The node learns the BID when it receives a Binding Identifier | The node learns the BID when it receives a Binding Identifier | |||
| mobility option. At that time, the node MUST look up its binding | mobility option. At that time, the node MUST look up its binding | |||
| cache database with the home address and the BID retrieved from the | cache database with the home address and the BID retrieved from the | |||
| Binding Update. If the node does not know the BID, it searches for a | Binding Update. If the node does not know the BID, it searches for a | |||
| binding with only the home address. In such a case, the first | binding with only the home address. In such a case, the first | |||
| matched binding is found. If the node does not desire to use | matched binding is found. If the node does not desire to use | |||
| multiple bindings for a mobile node, it can simply ignore the BID. | multiple bindings for a mobile node, it can simply ignore the BID. | |||
| 6.2. Processing Binding Update | 6.2. Processing Binding Update | |||
| If a Binding Update does not contain a Binding Identifier mobility | If a Binding Update does not contain a Binding Identifier mobility | |||
| option, its processing is same as in [RFC-3775]. If the receiver | option, its processing is the same as in [RFC-3775]. If the receiver | |||
| already has multiple bindings for the home address, it MUST replace | already has multiple bindings for the home address, it MUST replace | |||
| all the existing bindings by the received binding. As a result, the | all the existing bindings by the received binding. As a result, the | |||
| receiver node MUST have only one binding cache entry for the mobile | receiver node MUST have only one binding cache entry for the mobile | |||
| node. If the Binding Update is for de-registration, the receiver | node. If the Binding Update is for de-registration, the receiver | |||
| MUST delete all existing bindings from its Binding Cache. | MUST delete all existing bindings from its Binding Cache. | |||
| If the Binding Update contains a Binding Identifier mobility | If the Binding Update contains a Binding Identifier mobility | |||
| option(s), it is first validated according to section 9.5.1 of [RFC- | option(s), it is first validated according to section 9.5.1 of [RFC- | |||
| 3775]. Then the receiver processes the Binding Identifier mobility | 3775]. Then the receiver processes the Binding Identifier mobility | |||
| option(s) as described in the following steps. | option(s) as described in the following steps. | |||
| o The length value is examined. The length value MUST be either 4, | o The length value is examined. The length value MUST be either 4, | |||
| 8, or 20 depending on the Care-of Address field. If the length is | 8, or 20 depending on the Care-of Address field. If the length is | |||
| incorrect, the receiver MUST reject the Binding Update and returns | incorrect, the receiver MUST reject the Binding Update and returns | |||
| the status value set to [MCOA MALFORMED]. | the status value set to [MCOA MALFORMED]. | |||
| o When the Length value is either 12 or 20, the care-of address MUST | o When the Length value is either 8 or 20, the care-of address MUST | |||
| be present in the Binding Identifier mobility option. If the | be present in the Binding Identifier mobility option. If the | |||
| valid care-of address is not present, the receiver MUST reject the | unicast routable address [RFC-3775] is not present in the care-of | |||
| Binding Identifier mobility option and returns the status value | address field, the receiver MUST reject the Binding Identifier | |||
| set to [MCOA MALFORMED]. | mobility option and returns the status value set to [MCOA | |||
| MALFORMED]. | ||||
| o If the Binding Update is protected with IPsec ESP, the care-of | ||||
| address MUST be appeared in the Binding Identifier mobility | ||||
| option. If no address is appeared in the care-of address field in | ||||
| that mobility option, it MUST reject the Binding Identifier | ||||
| mobility option and returns the status value set to [MCOA | ||||
| MALFORMED]. | ||||
| o If the care-of address is appeared in both the alternate care-of | ||||
| address mobility option and the Binding Identifier mobility option | ||||
| at the same time, it MUST ignore the alternate care-of address | ||||
| mobility option and can continue processing the Binding Update | ||||
| with the care-of address specified in the Binding Identifier | ||||
| mobility option. | ||||
| o When multiple Binding Identifier mobility options are present in | o When multiple Binding Identifier mobility options are present in | |||
| the Binding Update, it is treated as bulk registration. If the | the Binding Update, it is treated as bulk registration. If the | |||
| receiving node is a correspondent node, it MUST reject the Binding | receiving node is a correspondent node, it MUST reject the Binding | |||
| Update and returns the status value in the binding Acknowledgement | Update and returns the status value in the binding Acknowledgement | |||
| set to [MCOA BULK REGISTRATION NOT SUPPORT] | set to [MCOA BULK REGISTRATION NOT SUPPORT]. | |||
| o If the Lifetime field in the Binding Update is set to zero, the | o If the Lifetime field in the Binding Update is set to zero, the | |||
| receiving node deletes the binding entry that corresponds to the | receiving node deletes the binding entry that corresponds to the | |||
| BID in the Binding Identifier mobility option. If the receiving | BID in the Binding Identifier mobility option. If the receiving | |||
| node does not have an appropriate binding for the BID, it MUST | node does not have an appropriate binding for the BID, it MUST | |||
| reject the Binding Update and send a Binding Acknowledgement with | reject the Binding Update and send a Binding Acknowledgement with | |||
| status set to 133 [not home agent for this mobile node]. | status set to 133 [not home agent for this mobile node]. | |||
| o If the 'O' flag is set in the de-registering Binding Update, it is | o If the 'O' flag is set in the de-registering Binding Update, it is | |||
| ignored. If the 'H' flag is set, the home agent stores a home | ignored. If the 'H' flag is set, the home agent stores a home | |||
| skipping to change at page 26, line 43 | skipping to change at page 30, line 9 | |||
| Section 5.6. | Section 5.6. | |||
| o If the Lifetime field is not set to zero, the receiving node | o If the Lifetime field is not set to zero, the receiving node | |||
| registers a binding with the specified BID as a mobile node's | registers a binding with the specified BID as a mobile node's | |||
| binding. The Care-of address is obtained from the Binding Update | binding. The Care-of address is obtained from the Binding Update | |||
| packet as follows: | packet as follows: | |||
| * If the Length value of the Binding Identifier mobility option | * If the Length value of the Binding Identifier mobility option | |||
| is 20, the care-of address is copied the IPv6 address from the | is 20, the care-of address is copied the IPv6 address from the | |||
| care-of address field in the Binding Identifier mobility | care-of address field in the Binding Identifier mobility | |||
| option. When the Length value is 12, the address MUST be the | option. When the Length value is 8, the address MUST be the | |||
| IPv4 valid address. Detail information can be found in | IPv4 valid address. Detail information can be found in | |||
| Section 8. | Section 8. | |||
| * If the Length value of the Binding Identifier mobility option | * If the Length value of the Binding Identifier mobility option | |||
| is 4, the care-of address is copied from the source address | is 4, the care-of address is copied from the source address | |||
| field of the IPv6 header. | field of the IPv6 header. | |||
| * If the Length value of the Binding Identifier mobility option | * If the Length value of the Binding Identifier mobility option | |||
| is 4 and an alternate care-of address is present, the care-of | is 4 and an alternate care-of address is present, the care-of | |||
| address is copied from the Alternate Care-of address mobility | address is copied from the Alternate Care-of address mobility | |||
| option. | option. | |||
| o Once the care-of address(es) have been retrieved from the Binding | o Once the care-of address(es) have been retrieved from the Binding | |||
| Update, the receiving nodes creates new binding(s). | Update, the receiving nodes creates new binding(s). | |||
| * If 'O' flag is not set in all the Binding Identifier options, | * If the 'O' flag is set in the Binding Update, the home agent | |||
| the home agent MUST return the status value [MCOA MALFORMED] by | removes all the existing bindings and registers the received | |||
| Binding Acknowledgement. | bindings. | |||
| * If the 'O' flag is set in the Binding Identifier mobility | ||||
| option, the home agent removes all the existing bindings and | ||||
| registers the received bindings. | ||||
| * If the receiver has a regular binding which does not have BID | * If the 'O' flag is unset in the Binding Update and the receiver | |||
| for the mobile node, it must not process the binding update. | has a regular binding which does not have BID for the mobile | |||
| The receiver should sent a binding acknowledgement with status | node, it must not process the Binding Update. The receiver | |||
| set to [MCOA BID CONFLICT]. | should sent a binding Acknowledgement with status set to [MCOA | |||
| BID CONFLICT]. | ||||
| * If the receiver already has a binding with the same BID but | * If the receiver already has a binding with the same BID but | |||
| different care-of address, it MUST update the binding and | different care-of address, it MUST update the binding and | |||
| respond with a Binding Acknowledgement with status set to 0 | respond with a Binding Acknowledgement with status set to 0 | |||
| [Binding Update accepted]. | [Binding Update accepted]. | |||
| * If the receiver does not have a binding entry for the BID, it | * If the receiver does not have a binding entry for the BID, it | |||
| registers a new binding for the BID and responds with a Binding | registers a new binding for the BID and responds with a Binding | |||
| Acknowledgement with status set to 0 [Binding Update accepted]. | Acknowledgement with status set to 0 [Binding Update accepted]. | |||
| If all the above operations are successfully completed, a Binding | If all the above operations are successfully completed, a Binding | |||
| Acknowledgement containing the Binding Identifier mobility options | Acknowledgement containing the Binding Identifier mobility options | |||
| MUST be sent to the mobile node. Whenever a Binding Acknowledgement | MUST be sent to the mobile node. Whenever a Binding Acknowledgement | |||
| is sent, all the Binding Identifier mobility options stored in the | is sent, all the Binding Identifier mobility options stored in the | |||
| Binding Update MUST be copied to the Binding Acknowledgement except | Binding Update MUST be copied to the Binding Acknowledgement except | |||
| the status field. The Care-of address field in each Binding | the status field. The Care-of address field in each Binding | |||
| Identifier mobility option, however, can be omitted, because the | Identifier mobility option, however, MAY be omitted, because the | |||
| mobile node can match a corresponding binding update list entry using | mobile node can match a corresponding binding update list entry using | |||
| the BID. | the BID. | |||
| When a correspondent node sends a Binding Acknowledgement, the status | When a correspondent node sends a Binding Acknowledgement, the status | |||
| value MUST be always stored in the Status field of the Binding | value MUST be always stored in the Status field of the Binding | |||
| Acknowledgement and the Status field of Binding Identifier mobility | Acknowledgement and the Status field of Binding Identifier mobility | |||
| option MUST be always set to zero. | option MUST be always set to zero. | |||
| When the home agent sends a Binding Acknowledgement, the status value | When the home agent sends a Binding Acknowledgement, the status value | |||
| can be stored in the Status field of either a Binding Acknowledgement | can be stored in the Status field of either a Binding Acknowledgement | |||
| or a Binding Identifier mobility option. If the status value is | or a Binding Identifier mobility option. If the status value is | |||
| specific to one of bindings in the bulk registration, the status | specific to one of bindings in the bulk registration, the status | |||
| value MUST be stored in the Status field in the corresponding Binding | value MUST be stored in the Status field in the corresponding Binding | |||
| Identifier mobility option. In this case, [MCOA NOTCOMPLETE] MUST be | Identifier mobility option. In this case, [MCOA NOTCOMPLETE] MUST be | |||
| set to the Status field of the Binding Acknowledgement so that the | set in the Status field of the Binding Acknowledgement so that the | |||
| receiver can examine the Status field of each Binding Identifier | receiver will examine the Status field of each Binding Identifier | |||
| mobility option for further operations. Otherwise, the status field | mobility option for further operations. Otherwise, the status field | |||
| of the Binding Identifier mobility option MUST be set to zero and the | of the Binding Identifier mobility option MUST be set to zero and the | |||
| home agent status field of the Binding Acknowledgement is used. | home agent status field of the Binding Acknowledgement is used. | |||
| 6.3. Sending Binding Refresh Request | 6.3. Sending Binding Refresh Request | |||
| When a node (home agent or correspondent node) sends a Binding | When a node (home agent or correspondent node) sends a Binding | |||
| Refresh Request for a particular binding created with the BID, the | Refresh Request for a particular binding created with the BID, the | |||
| node SHOULD include the Binding Identifier mobility option in the | node SHOULD include the Binding Identifier mobility option in the | |||
| Binding Refresh Request. The node MAY include multiple Binding | Binding Refresh Request. The node MAY include multiple Binding | |||
| skipping to change at page 30, line 23 | skipping to change at page 33, line 23 | |||
| registration works with IPv4 care-of and home addresses. | registration works with IPv4 care-of and home addresses. | |||
| 8.1. IPv4 Care-of Address Registration | 8.1. IPv4 Care-of Address Registration | |||
| The mobile node can use the extensions described in the document to | The mobile node can use the extensions described in the document to | |||
| register multiple care-of addresses, even if some of the care-of | register multiple care-of addresses, even if some of the care-of | |||
| addresses are IPv4 address. | addresses are IPv4 address. | |||
| Bulk registration MUST NOT be used for the initial binding from an | Bulk registration MUST NOT be used for the initial binding from an | |||
| IPv4 care-of address. This is because, the Binding Update and | IPv4 care-of address. This is because, the Binding Update and | |||
| binding acknowledgement exchange is used to detect NAT on the path | Binding Acknowledgement exchange is used to detect NAT on the path | |||
| between the mobile node and the home agent. So the mobile node needs | between the mobile node and the home agent. So the mobile node needs | |||
| to check for a NAT between each IPv4 care-of address and the home | to check for a NAT between each IPv4 care-of address and the home | |||
| agent. | agent. | |||
| The Binding Update MUST be sent to the IPv4 home agent address by | The Binding Update MUST be sent to the IPv4 home agent address by | |||
| using UDP and IPv4 headers as shown in Figure 8. It is similar to | using UDP and IPv4 headers as shown in Figure 9. It is similar to | |||
| [ID-DSMIPv6] except that the IPv4 care-of address option MUST NOT be | [ID-DSMIPv6] except that the IPv4 care-of address option MUST NOT be | |||
| used when the BID mobility option is used. | used when the BID mobility option is used. | |||
| IPv4 header (src="" dst=HA_V4ADDR) | IPv4 header (src="" dst=HA_V4ADDR) | |||
| UDP Header | UDP Header | |||
| IPv6 header (src="" dst=HAADDR) | IPv6 header (src="" dst=HAADDR) | |||
| ESP Header | ESP Header | |||
| Mobility header | Mobility header | |||
| -Binding Update | -Binding Update | |||
| Mobility Options | Mobility Options | |||
| - Binding Identifier (IPv4 CoA) | - Binding Identifier (IPv4 CoA) | |||
| *V4ADDR, HA_V4ADDR, V6HOA, HAADDR are defined in [ID-DSMIPv6] | ||||
| Figure 8: Initial Binding Update for IPv4 Care-of Address | Figure 9: Initial Binding Update for IPv4 Care-of Address | |||
| If a NAT is not detected, the mobile node can update the IPv4 care-of | If a NAT is not detected, the mobile node can update the IPv4 care-of | |||
| address by using bulk registration. The mobile node can register the | address by using bulk registration. The mobile node can register the | |||
| IPv4 care-of address along with other IPv4 and IPv6 care-of | IPv4 care-of address along with other IPv4 and IPv6 care-of | |||
| addresses. Figure 9 shows the Binding Update format when the mobile | addresses. Figure 10 shows the Binding Update format when the mobile | |||
| node sends a Binding Update from one of its IPv6 care-of addresses. | node sends a Binding Update from one of its IPv6 care-of addresses. | |||
| If the mobile node sends a Binding Update from IPv4 care-of address, | If the mobile node sends a Binding Update from IPv4 care-of address, | |||
| it MUST follow the format described in Figure 8. Note that the IPv4 | it MUST follow the format described in Figure 9. Note that the IPv4 | |||
| Care-of Address must be registered by non bulk Binding registration, | Care-of Address must be registered by non bulk Binding registration, | |||
| whenever it is changed. | whenever it is changed. | |||
| IPv6 header (src="" dst=HAADDR) | IPv6 header (src="" Address, dst=Home Agent Address) | |||
| IPv6 Home Address Option | IPv6 Home Address Option | |||
| ESP Header | ESP Header | |||
| Mobility header | Mobility header | |||
| -Binding Update | -Binding Update | |||
| Mobility Options | Mobility Options | |||
| - Binding Identifier (IPv6/v4 CoA) | - Binding Identifier (IPv6/v4 CoA) | |||
| - Binding Identifier (IPv6/v4 CoA) | - Binding Identifier (IPv6/v4 CoA) | |||
| - ... | - ... | |||
| Figure 9: Binding Bulk Registration for IPv4 care-of address | Figure 10: Binding Bulk Registration for IPv4 care-of address | |||
| If the home agent rejects the IPv4 care-of address, it MUST store the | If the home agent rejects the IPv4 care-of address, it MUST store the | |||
| error code value in the Status field of the BID mobility option. | error code value in the Status field of the BID mobility option. | |||
| 8.2. IPv4 HoA Management | 8.2. IPv4 Home Address Management | |||
| When the mobile node wants to configure an IPv4 home address in | When the mobile node wants to configure an IPv4 home address in | |||
| addition to the IPv6 home address, it can request for one using the | addition to the IPv6 home address, it can request for one using the | |||
| IPv4 Home Address option in the Binding Update. If the home agent | IPv4 Home Address option in the Binding Update. If the home agent | |||
| accepts the Binding Update, the mobile node can now register multiple | accepts the Binding Update, the mobile node can now register multiple | |||
| care-of addresses for the IPv4 home address in addition to the IPv6 | care-of addresses for the IPv4 home address in addition to the IPv6 | |||
| home address. The same set of care-of addresses will be registered | home address. The same set of care-of addresses will be registered | |||
| for both IPv6 and IPv4 home addresses. The mobile node cannot bind | for both IPv6 and IPv4 home addresses. The mobile node cannot bind a | |||
| different set of care-of addresses to each home address. | different set of care-of addresses to each home address. | |||
| According to [ID-DSMIPv6], the home agent includes the IPv4 address | According to [ID-DSMIPv6], the home agent includes the IPv4 address | |||
| acknowledgement option in the Binding Acknowledgement only if the | acknowledgement option in the Binding Acknowledgement only if the | |||
| mobile node had requested for an IPv4 home address in the | mobile node had requested for an IPv4 home address in the | |||
| corresponding Binding Update. The IPv4 address acknowledgement | corresponding Binding Update. The IPv4 address acknowledgement | |||
| option MUST be present before any BID option. The status field of | option MUST be present before any BID option. The status field of | |||
| the IPv4 address acknowledgement option contains only the error code | the IPv4 address acknowledgement option contains only the error code | |||
| corresponding to the IPv4 home address management. The error values | corresponding to the IPv4 home address management. The error values | |||
| related to the IPv4 care-of address registration MUST be stored in | related to the IPv4 care-of address registration MUST be stored in | |||
| the BID mobility option. | the BID mobility option. | |||
| 9. IPsec and IKEv2 interaction | 9. IPsec and IKEv2 interaction | |||
| Mobile IPv6 [RFC-3775] and the NEMO protocol [RFC-3963] require the | Mobile IPv6 [RFC-3775] and the NEMO protocol [RFC-3963] require the | |||
| use of IPsec to protect signaling messages like Binding Updates, | use of IPsec to protect signaling messages including Binding Updates, | |||
| Binding Acknowledgements and return routability messages. IPsec may | Binding Acknowledgements and return routability messages. IPsec may | |||
| also be used protect all tunneled data traffic. The Mobile IPv6- | also be used protect all tunneled data traffic. The Mobile IPv6- | |||
| IKEv2 specification [RFC-4877] specifies how IKEv2 can be used to | IKEv2 specification [RFC-4877] specifies how IKEv2 can be used to | |||
| setup the required IPsec security associations. The following | setup the required IPsec security associations. The following | |||
| assumptions were made in [RFC-3775], [RFC-3963] and [RFC-4877] with | assumptions were made in [RFC-3775], [RFC-3963] and [RFC-4877] with | |||
| respect to the use of IKEv2 and IPsec. | respect to the use of IKEv2 and IPsec. | |||
| o There is only one primary care-of address per mobile node. | o There is only one primary care-of address per mobile node. | |||
| o The primary care-of address is stored in the IPsec database for | o The primary care-of address is stored in the IPsec database for | |||
| tunnel encapsulation and decapsulation. | tunnel encapsulation and decapsulation. | |||
| o When the home agent receives a packet from the mobile node, the | o When the home agent receives a packet from the mobile node, the | |||
| source address is verified against the care-of address in the | source address is verified against the care-of address in the | |||
| corresponding binding cache entry. If the packet is a reverse | corresponding binding cache entry. If the packet is a reverse | |||
| tunneled packet from the mobile node, the care-of address check is | tunneled packet from the mobile node, the care-of address check is | |||
| done against the source address on the outer IPv6 header. The | done against the source address on the outer IPv6 header. The | |||
| reverse tunnel packet could either be a tunneled HoTi message or | reverse tunnel packet could either be a tunneled Home Test Init | |||
| tunneled data traffic to the correspondent node. | message or tunneled data traffic to the correspondent node. | |||
| o The mobile node runs IKEv2 (or IKEv1) with the home agent using | o The mobile node runs IKEv2 (or IKEv1) with the home agent using | |||
| the care-of address. The IKE SA is based on the care-of address | the care-of address. The IKE SA is based on the care-of address | |||
| of the mobile node. | of the mobile node. | |||
| The above assumptions may not be valid when multiple care-of | The above assumptions may not be valid when multiple care-of | |||
| addresses are used by the mobile node. In the following sections, | addresses are used by the mobile node. In the following sections, | |||
| the main issues with the use of multiple care-of address with IPsec | the main issues with the use of multiple care-of address with IPsec | |||
| are addressed. | are addressed. | |||
| skipping to change at page 33, line 23 | skipping to change at page 36, line 23 | |||
| The home agent processes Mobile Prefix Discovery messages with the | The home agent processes Mobile Prefix Discovery messages with the | |||
| same rules of data packets described in Section 6.4. | same rules of data packets described in Section 6.4. | |||
| 9.3. Tunnel Mode IPsec protected messages | 9.3. Tunnel Mode IPsec protected messages | |||
| The use of IPsec in tunnel mode with multiple care-of address | The use of IPsec in tunnel mode with multiple care-of address | |||
| introduces a few issues that require changes to how the mobile node | introduces a few issues that require changes to how the mobile node | |||
| and the home agent send and receive tunneled traffic. The route | and the home agent send and receive tunneled traffic. The route | |||
| optimization mechanism described in [RFC-3775] mandates the use of | optimization mechanism described in [RFC-3775] mandates the use of | |||
| IPsec protection in tunnel mode for the HoTi and HoT messages. The | IPsec protection in tunnel mode for the Home Test Init and Home Test | |||
| mobile node and the home agent may also choose to protect all reverse | messages. The mobile node and the home agent may also choose to | |||
| tunneled payload traffic with IPsec in tunnel mode. The following | protect all reverse tunneled payload traffic with IPsec in tunnel | |||
| sections address multiple care-of address support for these two types | mode. The following sections address multiple care-of address | |||
| of messages. | support for these two types of messages. | |||
| 9.3.1. Tunneled HoTi and HoT messages | 9.3.1. Tunneled Home Test Init and Home Test messages | |||
| The mobile node MAY use the same care-of address for all HoTi | The mobile node MAY use the same care-of address for all Home Test | |||
| messages sent reverse tunneled through the home agent. The mobile | Init messages sent reverse tunneled through the home agent. The | |||
| node may use the same care-of address irrespective of which | mobile node may use the same care-of address irrespective of which | |||
| correspondent node the HoTi message is being sent. RFC 3775 requires | correspondent node the Home Test Init message is being sent. RFC | |||
| the home agent to verify that the mobile node is using the care-of | 3775 requires the home agent to verify that the mobile node is using | |||
| address that is in the binding cache entry, when it receives a | the care-of address that is in the binding cache entry, when it | |||
| reverse tunneled HoTi message. If a different address is used as the | receives a reverse tunneled Home Test Init message. If a different | |||
| source address, the message is silently dropped by the home agent. | address is used as the source address, the message is silently | |||
| This document requires the home agent implementation to decapsulate | dropped by the home agent. This document requires the home agent | |||
| and forward the HoTi message as long as the source address is one of | implementation to decapsulate and forward the Home Test Init message | |||
| the care-of addresses in the binding cache entry for the mobile node. | as long as the source address is one of the care-of addresses in the | |||
| binding cache entry for the mobile node. | ||||
| When the home agent tunnels a HoT message to the mobile node, the | When the home agent tunnels a Home Test message to the mobile node, | |||
| care-of address used in the outer IPv6 header is not relevant to the | the care-of address used in the outer IPv6 header is not relevant to | |||
| HoT message. So regular IPsec tunnel encapsulation with the care-of | the Home Test message. So regular IPsec tunnel encapsulation with | |||
| address known to the IPsec implementation on the home agent is | the care-of address known to the IPsec implementation on the home | |||
| sufficient. | agent is sufficient. | |||
| 9.3.2. Tunneled Payload Traffic | 9.3.2. Tunneled Payload Traffic | |||
| When the mobile sends and receives multiple traffic flows protected | When the mobile sends and receives multiple traffic flows protected | |||
| by IPsec to different care-of addresses, the use of the correct | by IPsec to different care-of addresses, the use of the correct | |||
| care-of address for each flow becomes important. Support for this | care-of address for each flow becomes important. Support for this | |||
| requires the following two considerations on the home agent. | requires the following two considerations on the home agent. | |||
| o When the home agent receives a reverse tunneled payload message | o When the home agent receives a reverse tunneled payload message | |||
| protected by IPsec in tunnel mode, it must check that the care-of | protected by IPsec in tunnel mode, it still needs to be aware of | |||
| address is one of the care-of addresses in the binding cache | which care-of address is being used. According to RFC 4306, the | |||
| entry. According to RFC 4306, the IPsec implementation on the | IPsec implementation on the home agent does not check the source | |||
| home agent does not check the source address on the outer IPv6 | address on the outer IPv6 header. However, the stack on the home | |||
| header. Therefore the care-of address used in the reverse | agent MUST still be informed about the source address in order to | |||
| tunneled traffic can be different from the care-of address used as | choose the most recently used care-of address, as discussed in | |||
| the source address in the IKEv2 exchange. However, the Mobile | Section 3 (in the absence of a user-supplied policy). | |||
| IPv6 stack on the home agent MUST verify that the source address | ||||
| is one of the care-of addresses registered by the mobile node | ||||
| before decapsulating and forwarding the payload traffic towards | ||||
| the correspondent node. | ||||
| o For tunneled IPsec traffic from the home agent to the mobile node, | o For tunneled IPsec traffic from the home agent to the mobile node, | |||
| The IPsec implementation on the home agent may not be aware of | The IPsec implementation on the home agent may not be aware of | |||
| which care-of address to use when performing IPsec tunnel | which care-of address to use when performing IPsec tunnel | |||
| encapsulation. The Mobile IP stack on the home agent must specify | encapsulation. The Mobile IP stack on the home agent must specify | |||
| the tunnel end point for the IPsec tunnel. This may require tight | the tunnel end point for the IPsec tunnel. This may require tight | |||
| integration between the IPsec and Mobile IP implementations on the | integration between the IPsec and Mobile IP implementations on the | |||
| home agent. | home agent. | |||
| 10. Security Considerations | 10. Security Considerations | |||
| skipping to change at page 35, line 25 | skipping to change at page 38, line 25 | |||
| With simultaneous binding support, it is possible for a malicious | With simultaneous binding support, it is possible for a malicious | |||
| mobile node to successfully bind a number of victims' addresses as | mobile node to successfully bind a number of victims' addresses as | |||
| valid care-of addresses for the mobile node with its home agent. | valid care-of addresses for the mobile node with its home agent. | |||
| Once these addresses have been bound, the malicious mobile node can | Once these addresses have been bound, the malicious mobile node can | |||
| perform a re-direction attack by instructing the home agent (e.g. | perform a re-direction attack by instructing the home agent (e.g. | |||
| setting filtering rules to direct a large file transfer) to tunnel | setting filtering rules to direct a large file transfer) to tunnel | |||
| packets to the victims' addresses. Such risk is highlighted in [ID- | packets to the victims' addresses. Such risk is highlighted in [ID- | |||
| MIP6ANALYSIS]. These attacks are possible because the care-of | MIP6ANALYSIS]. These attacks are possible because the care-of | |||
| addresses sent by the mobile node in the Binding Update messages are | addresses sent by the mobile node in the Binding Update messages are | |||
| not verified by home agent, i.e., the home agent does not check if | not verified by the home agent, i.e., the home agent does not check | |||
| the mobile node is at the care-of address it is claiming to be. The | if the mobile node is at the care-of address it is claiming to be. | |||
| security model for Mobile IPv6 assumes that there is a trust | The security model for Mobile IPv6 assumes that there is a trust | |||
| relationship between the mobile node and its home agent. Any | relationship between the mobile node and its home agent. Any | |||
| malicious attack by the mobile node is traceable by the home agent. | malicious attack by the mobile node is traceable by the home agent. | |||
| This acts as a deterrent for the mobile node to launch such attacks. | This acts as a deterrent for the mobile node to launch such attacks. | |||
| Although such risk exists in Mobile IPv6, the risk level is escalated | Although such a risk exists in Mobile IPv6, the risk level is | |||
| when simultaneous multiple care-of address bindings are performed. | increased when simultaneous multiple care-of address bindings are | |||
| In Mobile IPv6, a mobile node can only have a single care-of address | performed. In Mobile IPv6, a mobile node can only have a single | |||
| binding per home address at a given time. However, for simultaneous | care-of address binding per home address at a given time. However, | |||
| multiple care-of address bindings, a mobile node can have more than | for simultaneous multiple care-of address bindings, a mobile node can | |||
| one care-of address binding per home address at a given time. This | have more than one care-of address binding per home address at a | |||
| implies that a mobile node using simultaneous binding support can | given time. This implies that a mobile node using simultaneous | |||
| effectively bind more than a single victim's address. Another | binding support can effectively bind more than a single victim's | |||
| difference is the degree of risk involved. In the single care-of | address. Another difference is the degree of risk involved. In the | |||
| address binding case, once the re-direction attack is initiated, a | single care-of address binding case, once the re-direction attack is | |||
| malicious mobile node would be unable to use its home address for | initiated, a malicious mobile node would be unable to use its home | |||
| communications (such as to receive control packets pertaining to the | address for communications (such as to receive control packets | |||
| file transfer). However, in the simultaneous binding support case, a | pertaining to the file transfer). However, in the simultaneous | |||
| malicious mobile node could bind a valid care-of address in addition | binding support case, a malicious mobile node could bind a valid | |||
| to multiple victims addresses. This valid care-of address could then | care-of address in addition to multiple victims addresses. This | |||
| be used by the malicious mobile node to set up flow filtering rules | valid care-of address could then be used by the malicious mobile node | |||
| at its home agent, thereby controlling and/or launching new re- | to set up flow filtering rules at its home agent, thereby controlling | |||
| direction attacks. | and/or launching new re-direction attacks. | |||
| Thus, in view of such risks, it is advisable for a home agent to | Thus, in view of such risks, it is advisable for a home agent to | |||
| employ some form of care-of address verification mechanism before | employ some form of care-of address verification mechanism before | |||
| using the care-of addresses as a valid routing path to a mobile node. | using the care-of addresses as a valid routing path to a mobile node. | |||
| These mechanisms are out-of scope for this document. The home agent | These mechanisms are out-of scope for this document. The home agent | |||
| can also choose to reject bulk registration by using [MCOA BULK | can also choose to reject bulk registration by using [MCOA BULK | |||
| REGISTRATION PROHIBITED] in a Binding Acknowledgement. | REGISTRATION PROHIBITED] in a Binding Acknowledgement. | |||
| 11. IANA Considerations | 11. IANA Considerations | |||
| skipping to change at page 38, line 30 | skipping to change at page 41, line 30 | |||
| [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
| [RFC-4861] Narten, T., Nordmark, E., W. Simpson, and H. Soliman, | [RFC-4861] Narten, T., Nordmark, E., W. Simpson, and H. Soliman, | |||
| "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, September | "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, September | |||
| 2007.. | 2007.. | |||
| [RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support | [RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support | |||
| in IPv6", RFC 3775, June 2004. | in IPv6", RFC 3775, June 2004. | |||
| [RFC-4877] V. Devarapalli, F. Dupont, "Mobile IPv6 Operation with | ||||
| IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007. | ||||
| [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. | [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. | |||
| Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, | Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, | |||
| January 2005. | January 2005. | |||
| [RFC-4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with | [RFC-4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with | |||
| IKEv2 and the revised IPsec Architecture", RFC 4877, April 2007. | IKEv2 and the revised IPsec Architecture", RFC 4877, April 2007. | |||
| [ID-DSMIPv6] Soliman, H., "Mobile IPv6 support for dual stack Hosts | ||||
| and Routers (DSMIPv6)", draft-ietf-mext-nemo-v4traversal-05 (work in | ||||
| progress), July 2008. | ||||
| [RFC-5268] R. Koodli, "Mobile IPv6 Fast Handovers", RFC 5268, June | ||||
| 2008. | ||||
| 13.2. Informative References | 13.2. Informative References | |||
| [ID-MOTIVATION] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and | [ID-MOTIVATION] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and | |||
| K. Kuladinithi, "Motivations and Scenarios for Using Multiple | K. Kuladinithi, "Motivations and Scenarios for Using Multiple | |||
| Interfaces and Global Addresses", | Interfaces and Global Addresses", | |||
| draft-ietf-monami6-multihoming-motivation-scenario-03 (work in | draft-ietf-monami6-multihoming-motivation-scenario-03 (work in | |||
| progress), May 2008. | progress), May 2008. | |||
| [RFC-4980] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of | [RFC-4980] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of | |||
| Multihoming in Network Mobility Support", RFC 4980, October 2007. | Multihoming in Network Mobility Support", RFC 4980, October 2007. | |||
| skipping to change at page 39, line 11 | skipping to change at page 43, line 5 | |||
| [ID-MIP6ANALYSIS] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and | [ID-MIP6ANALYSIS] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and | |||
| K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6", | K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6", | |||
| draft-ietf-monami6-mipv6-analysis-05 (Work in progress), May 2008. | draft-ietf-monami6-mipv6-analysis-05 (Work in progress), May 2008. | |||
| [RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology", | [RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology", | |||
| RFC 3753, June 2004. | RFC 3753, June 2004. | |||
| [RFC-4885] Ernst, T. and H. Lach, "Network Mobility Support | [RFC-4885] Ernst, T. and H. Lach, "Network Mobility Support | |||
| Terminology", RFC 4885, July 2007. | Terminology", RFC 4885, July 2007. | |||
| [ID-DSMIPv6] Soliman, H., "Mobile IPv6 support for dual stack Hosts | ||||
| and Routers (DSMIPv6)", draft-ietf-mext-nemo-v4traversal-05 (work in | ||||
| progress), July 2008. | ||||
| [RFC-5268] R. Koodli, "Mobile IPv6 Fast Handovers", RFC 5268, June | ||||
| 2008. | ||||
| Authors' Addresses | Authors' Addresses | |||
| Ryuji Wakikawa | Ryuji Wakikawa | |||
| Toyota ITC / Keio University | Toyota ITC / Keio University | |||
| 6-6-20 Akasaka, Minato-ku | 6-6-20 Akasaka, Minato-ku | |||
| Tokyo 107-0052 | Tokyo 107-0052 | |||
| Japan | Japan | |||
| Phone: +81-3-5561-8276 | Phone: +81-3-5561-8276 | |||
| Fax: +81-3-5561-8292 | Fax: +81-3-5561-8292 | |||
| End of changes. 118 change blocks. | ||||
| 320 lines changed or deleted | 412 lines changed or added | |||
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||
MEXT Working Group R. Wakikawa (Ed.)
Internet-Draft Toyota ITC/Keio Univ.
Intended status: Standards Track V. Devarapalli (Ed.)
Expires: June 8, 2009 Wichorus
T. Ernst
INRIA
K. Nagami
INTEC NetCore
December 5, 2008
Multiple Care-of Addresses Registration
draft-ietf-monami6-multiplecoa-11-20081205.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 8, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 1]
Internet-Draft MCoA December 2008
Abstract
According to the current Mobile IPv6 specification, a mobile node may
have several care-of addresses, but only one, called the primary
care-of address, that can be registered with its home agent and the
correspondent nodes. However, for matters of cost, bandwidth, delay,
etc, it is useful for the mobile node to get Internet access through
multiple accesses simultaneously, in which case the mobile node would
be configured with multiple active IPv6 care-of addresses. This
document proposes extensions to the Mobile IPv6 protocol to register
and use multiple care-of addresses. The extensions proposed in this
document can be used by Mobile Routers using the NEMO (Network
Mobility) Basic Support protocol as well.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 12
4.1. Binding Cache Structure and Binding Update List . . . . . 12
4.2. Binding Update Message . . . . . . . . . . . . . . . . . . 12
4.3. Binding Identifier Mobility Option . . . . . . . . . . . . 13
4.4. New Status Values for Binding Acknowledgement . . . . . . 14
5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 17
5.1. Management of Care-of Address(es) and Binding
Identifier(s) . . . . . . . . . . . . . . . . . . . . . . 17
5.2. Binding Registration . . . . . . . . . . . . . . . . . . . 17
5.3. Bulk Registration . . . . . . . . . . . . . . . . . . . . 18
5.4. Binding De-Registration . . . . . . . . . . . . . . . . . 19
5.5. Returning Home: Using Single Interface . . . . . . . . . . 19
5.5.1. Using only Interface attached to the Home Link . . . . 19
5.5.2. Using only Interface attached to the Visited Link . . 20
5.6. Returning Home: Simultaneous Home and Visited Link
Operation . . . . . . . . . . . . . . . . . . . . . . . . 20
5.6.1. Problems of Simultaneous Home and Foreign
Attachments . . . . . . . . . . . . . . . . . . . . . 20
5.6.2. Overview and Approach . . . . . . . . . . . . . . . . 21
5.6.3. Sending Deregistration Binding Update . . . . . . . . 22
5.6.4. Sending Binding Acknowledgement . . . . . . . . . . . 23
5.6.5. Sending Packets from the Home Link . . . . . . . . . . 24
5.6.6. Leaving from the Home Link . . . . . . . . . . . . . . 25
5.7. Receiving Binding Acknowledgement . . . . . . . . . . . . 25
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 2]
Internet-Draft MCoA December 2008
5.8. Receiving Binding Refresh Request . . . . . . . . . . . . 26
5.9. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 27
6. Home Agent and Correspondent Node Operation . . . . . . . . . 28
6.1. Searching Binding Cache with Binding Identifier . . . . . 28
6.2. Processing Binding Update . . . . . . . . . . . . . . . . 28
6.3. Sending Binding Refresh Request . . . . . . . . . . . . . 31
6.4. Receiving Packets from Mobile Node . . . . . . . . . . . . 31
7. Network Mobility Applicability . . . . . . . . . . . . . . . . 32
8. DSMIPv6 Applicability . . . . . . . . . . . . . . . . . . . . 33
8.1. IPv4 Care-of Address Registration . . . . . . . . . . . . 33
8.2. IPv4 Home Address Management . . . . . . . . . . . . . . . 34
9. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 35
9.1. Use of Care-of Address in the IKEv2 exchange . . . . . . . 35
9.2. Transport Mode IPsec protected messages . . . . . . . . . 36
9.3. Tunnel Mode IPsec protected messages . . . . . . . . . . . 36
9.3.1. Tunneled Home Test Init and Home Test messages . . . . 36
9.3.2. Tunneled Payload Traffic . . . . . . . . . . . . . . . 37
10. Security Considerations . . . . . . . . . . . . . . . . . . . 38
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
13.1. Normative References . . . . . . . . . . . . . . . . . . . 41
13.2. Informative References . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
Intellectual Property and Copyright Statements . . . . . . . . . . 44
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 3]
Internet-Draft MCoA December 2008
1. Introduction
A mobile node may use various types of network interfaces to obtain
durable and wide area network connectivity. This has increasingly
become true with mobile nodes having multiple interfaces such as
802.2, 802.11, 802.16, cellular radios, etc. The motivations for and
benefits of using multiple points of attachment are discussed in [ID-
MOTIVATION]. When a mobile node with multiple interfaces uses Mobile
IPv6 [RFC-3775] for mobility management, it cannot use its multiple
interfaces to send and receive packets while taking advantage of
session continuity provided by Mobile IPv6. This is because Mobile
IPv6 allows the mobile node to only bind one care-of address at a
time with its home address. See [ID-MIP6ANALYSIS] for a further
analysis of using multiple interfaces and addresses with Mobile IPv6.
This document proposes extensions to Mobile IPv6 to allow a mobile
node to register multiple care-of addresses for a home address and
create multiple binding cache entries. A new Binding Identification
(BID) number is created for each binding the mobile node wants to
create and sent in the binding update. The home agent that receives
this Binding Update creates a separate binding for each BID. The BID
information is stored in the corresponding binding cache entry. The
BID information can now be used to identify individual bindings. The
same extensions can also be used in Binding Updates sent to the
correspondent nodes.
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 4]
Internet-Draft MCoA December 2008
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC-2119].
Terms used in this draft are defined in [RFC-3775], [RFC-3753] and
[RFC-4885]. In addition to or as a replacement of these, the
following terms are defined or redefined:
Binding Identification number (BID)
The BID is an identification number used to distinguish multiple
bindings registered by the mobile node. Assignment of distinct
BIDs allows a mobile node to register multiple binding cache
entries for a given home address. The BIDs assigned to a same
home address must not be duplicated at a time. Zero value is
reserved for future extension. Each BID is generated and managed
by a mobile node. The BID is stored in the Binding Update List
and is sent by the mobile node in the Binding Update. A mobile
node may change the value of a BID at any time according to its
administrative policy, for instance to protect its privacy. An
implementation must carefully assign the BID so as to keep using
the same BID for the same binding even when the status of the
binding is changed. More details can be found in Section 5.1.
Binding Identifier Mobility Option
The Binding Identifier mobility option is used to carry the BID
information.
Bulk Registration
A mobile node can register multiple bindings at once by sending a
single Binding Update. A mobile node can also replace some or all
the bindings available at the home agent with the new bindings by
using the bulk registration. Bulk registration is supported only
for home registration (i.e. with the home agent) as explained in
Section 5.3. A mobile node must not perform bulk registration
mechanism described in this specification with a correspondent
node.
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 5]
Internet-Draft MCoA December 2008
3. Protocol Overview
A new extension called the Binding identification number (BID) is
introduced to distinguish between multiple bindings pertaining to the
same home address. If a mobile node configures several IPv6 global
addresses on one or more of its interfaces, it can register these
addresses with its home agent as care-of addresses. If the mobile
node wants to register multiple bindings, it MUST generate a BID for
each care-of address and store the BID in the binding update list. A
mobile node can manipulate each binding independently by using the
BIDs. The mobile node then registers its care-of addresses by
sending a Binding Update with a Binding Identifier mobility option.
The BID is included in the Binding Identifier mobility option. After
receiving the Binding Update with a Binding Identifier mobility
option, the home agent MUST copy the BID from the Binding Identifier
mobility option to the corresponding field in the binding cache
entry. If there is an existing binding cache entry for the mobile
node, and if the BID in the Binding Update does not match the one
with the existing entry, the home agent MUST create a new binding
cache entry for the new care-of address and BID. The mobile node can
register multiple care-of addresses either independently in
individual Binding Updates or multiple at once in a single Binding
Update.
If the mobile host wishes to register its binding with a
correspondent node, it must perform return routability operations as
described in [RFC-3775]. This includes managing a Care-of Keygen
token per care-of address and exchanging Care-of Test Init and
Care-of Test message with the correspondent node for each care-of
address. The mobile node MAY use the same BID that it used with the
home agent for a particular care-of address. For protocol
simplicity, bulk registration to correspondent nodes is not supported
in this document. This is because the Return Routability mechanism
introduced in [RFC-3775] cannot be easily extended to verify multiple
care-of addresses stored in a single Binding Update.
Figure 1 illustrates the configuration where the mobile node obtains
multiple care-of addresses at foreign links. The mobile node can
utilize all the care-of addresses. In Figure 1, the home address of
the mobile node (MN) is 2001:db8::EUI. The mobile node has 3
different interfaces and possibly acquires care-of addresses 1-3
(CoA1, CoA2, CoA3). The mobile node assigns BID1, BID2 and BID3 to
each care-of address.
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 6]
Internet-Draft MCoA December 2008
+----+
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----+---+-+ +--+-+
CoA2| | | | Home Link
+--+--+ | | ------+------
| MN +--------+ |
+--+--+ CoA1 |
CoA3| |
+---------------+
Binding Cache Database:
home agent's binding (Proxy neighbor advertisement is active)
binding [2001:db8::EUI care-of address1 BID1]
binding [2001:db8::EUI care-of address2 BID2]
binding [2001:db8::EUI care-of address3 BID3]
correspondent node's binding
binding [2001:db8::EUI care-of address1 BID1]
binding [2001:db8::EUI care-of address2 BID2]
binding [2001:db8::EUI care-of address3 BID3]
Figure 1: Multiple Care-of Address Registration
If the mobile node decides to act as a regular mobile node compliant
with [RFC-3775], it sends a Binding Update without any Binding
Identifier mobility options. The receiver of the Binding Update
deletes all the bindings registering with a BID and registers only a
single binding for the mobile node. Note that the mobile node can
continue using the BID even if it has only a single binding that is
active.
Binding cache lookup is done based on the home address and BID
information if a BID is available. This is different from RFC 3775,
where only the home address is used for binding cache lookup.
Binding cache lookup is operated for either protocol signaling and
data packets. For the protocol signaling such as a binding update,
BID should be always carried by a BID sub-option in a protocol
signaling. Therefore, a correspondent binding cache that matches the
specified BID MUST be found from the binding cache database. On the
other hand, for the data packets, no BID information is carried in a
packet. The binding cache lookup may involve policy or flow filters
to retrieve a correspondent BID per packet in cases where some policy
or flow filters are used to direct a certain packet or flow to a
particular care-of address. However, the binding cache lookup using
policy or flow filters is out of scope for this document. If no such
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 7]
Internet-Draft MCoA December 2008
mechanism is available and no BID is found for a packet, a node
SHOULD use the binding which was last verified by receiving data
packets or signaling from the mobile node. In case the binding cache
lookup for data packets, using the combination of home address and
BID, does not return a valid binding cache entry, the home agent
SHOULD perform the lookup based on only the home address as described
in [RFC-3775].
In any case, to avoid problems with upper layer protocols and TCP in
particular, a single packet flow as identified by the 5-tuple SHOULD
only be sent to a single care-of address at a time.
The mobile node may return to the home link through one of its
interfaces. There are two options possible for the mobile node when
its returns home. Section 5.6 and Section 5.5.1 describe the
returning home procedures in more detail.
1. The mobile node uses only the interface with which it attaches to
the home link. This is illustrated in Figure 2. It de-registers
all bindings with the home agent related to all care-of
addresses. The interfaces still attached to the visited link(s)
are no longer going to be receiving any encapsulated traffic from
the home agent. On the other hand, the mobile node can continue
communicating with the correspondent node from the other
interfaces attached to foreign links by using route optimization.
Even if the mobile node is attached to the home link, it can
still send Binding Updates for other active care-of addresses
(CoA1 and CoA2) to correspondent nodes. Since the correspondent
node has bindings, packets are routed to each Care-of Addresses
directly.
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 8]
Internet-Draft MCoA December 2008
+----+
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----+-----+ +--+-+
CoA2| | | Home Link
+--+--+ | --+---+------
| MN +--------+ |
+--+--+ CoA1 |
| |
+---------------------------+
Binding Cache Database:
home agent's binding
none
correspondent node's binding
binding [2001:db8::EUI care-of address1 BID1]
binding [2001:db8::EUI care-of address2 BID2]
Figure 2: Using only Interface Attached to Home Link
2. The mobile node may simultaneously use both the interface
attached to the home link and the interfaces still attached to
the visited link(s) as shown in Figure 3. There are two possible
topologies depending on whether the home agent is the only router
on the home link or not. The operation of Neighbor Discovery
[RFC-4861] is different in the two topologies. More details can
be found in Section 5.6. The home agent and the correspondent
node have the binding entries listed in Figure 3 in their binding
cache database in both topologies. The home agent also knows
that the mobile node is attached to the home link. All the
traffic from the Internet is intercepted by the home agent first
and routed to either the interface attached to the home link or
the one of the foreign links. How the home agent decides to
route a particular flow to the interface attached to the home
link or foreign link is out of scope in this document.
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 9]
Internet-Draft MCoA December 2008
Topology-a)
+----+
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----+-----+ +--+-+
CoA2| | | Home Link
+--+--+ | --+---+------
| MN +--------+ |
+--+--+ CoA1 |
| |
+---------------------------+
Topology-b)
+----+
| CN |
+--+-+
|
+---+------+ Router +----+
+------+ Internet |-------R | HA |
| +----+-----+ | +--+-+
CoA2| | | | Home Link
+--+--+ | --+-+-------+------
| MN +--------+ |
+--+--+ CoA1 |
| |
+---------------------------+
Binding Cache Database:
home agent's binding
binding [2001:db8::EUI care-of address1 BID1]
binding [2001:db8::EUI care-of address2 BID2]
correspondent node's binding
binding [2001:db8::EUI care-of address1 BID1]
binding [2001:db8::EUI care-of address2 BID2]
Figure 3: Simultaneous Home and Visited Link Operation
This specification keeps backwards compatibility with [RFC-3775]. If
a receiver (either home agent or correspondent node) does not support
this specification, it does not understand the binding identifier
mobility option. The receiver skip the unknown mobility option (i.e.
Binding Identifier mobility option) and process the Binding Update as
defined in [RFC-3775]. In order to keep the backward compatibility
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 10]
Internet-Draft MCoA December 2008
with [RFC-3775], when a mobile node sends a Binding Update message
with extensions described in this document, the receiver needs to
reflect the Binding Identifier mobility option in the Binding
Acknowledgement. If the mobile node finds no Binding Identifier
mobility options in the received Binding Acknowledgement, it assumes
the other end node does not support this specification. In such
case, the mobile node needs to fall back to the legacy RFC-3775
compliant mobile node. If it is the home registration, the mobile
node MAY try to discover another home agent supporting BID mobility
option for the home registration.
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 11]
Internet-Draft MCoA December 2008
4. Mobile IPv6 Extensions
This section summarizes the extensions to Mobile IPv6 necessary for
manage multiple bindings.
4.1. Binding Cache Structure and Binding Update List
The BID is required to be stored in the binding cache and binding
update list structure.
The sequence number value MUST be shared among all the binding update
list entries related to binding updates sent to a particular home
agent or correspondent node. Whenever a mobile node sends either an
individual or a bulk binding update, the sequence number is
incremented. When a home agent receives an individual BU, it should
update the sequence number for all the bindings for a particular
mobile node with the sequence number in the received BU.
4.2. Binding Update Message
This specification extends the Binding Update message with a new
flag. The flag is shown and described below.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|F|T|O| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Binding Update message
Overwrite (O) flag
When this flag is set, all the binding cache entries for a mobile
node are replaced by new entries registering with this binding
update message. This flag is only used when BID Mobility Option
is carried with Binding Update.
Reserved
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 12]
Internet-Draft MCoA December 2008
6 bits Reserved field.
4.3. Binding Identifier Mobility Option
The Binding Identifier mobility option is included in the Binding
Update, Binding Acknowledgement, Binding Refresh Request, and Care-of
Test Init and Care-of Test message. The Binding Identifier Mobility
Option has an alignment requirement of 2n if the Care-of Address
field is not present. Otherwise, it has the alignment requirement of
8n + 2.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding ID (BID) | Status |H| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
+ +
: IPv4 or IPv6 care-of address (CoA) :
+ +
+---------------------------------------------------------------+
Figure 5: BID Mobility Option
Type
Type value for Binding Identifier is TBD
Length
8-bit unsigned integer. Length of the option, in octets,
excluding the Type and Length fields. It MUST be set to either 4,
8, or 20 depending on the care-of address field. When the care-of
address is not carried by this option, the length value MUST be
set to 4. If the IPv4 care-of address is stored in the care-of
address field, the length MUST be 8. Otherwise, the Length value
MUST be set to 20 for IPv6 care-of address.
Binding ID (BID)
The BID which is assigned to the binding indicated by the care-of
address in the Binding Update or the BID mobility option. The BID
is a 16-bit unsigned integer. The value of zero is reserved and
SHOULD NOT be used.
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 13]
Internet-Draft MCoA December 2008
Status
The Status field is an 8-bit unsigned integer. When the Binding
Identifier mobility option is included in a Binding
Acknowledgement, this field overwrites the status field in the
Binding Acknowledgement only for this BID. If this field is set
to zero, the receiver ignores this field and uses the registration
status stored in the Binding Acknowledgement message. The
receiver MUST ignore this field if the Binding Identifier mobility
option is not carried within either the Binding Acknowledgement or
the Care-of Test messages. The possible status codes are the same
as the status codes of Binding Acknowledgement. This Status field
is also used to carry error information related to the care-of
address test in the Care-of Test message.
Simultaneous Home and Foreign Binding (H) flag
This flag indicates that the mobile node registers multiple
bindings to the home agent while is attached to the home link.
This flag is valid only for a Binding Update sent to the home
agent.
Reserved
7 bits Reserved field. The value MUST be initialized to zero by
the sender, and SHOULD be ignored by the receiver.
Care-of Address
If a Binding Identifier mobility option is included in a Binding
Update, either IPv4 or IPv6 care-of address for the corresponding
BID can be stored in this field. If no address is specified in
this field, the length of this field MUST be zero (i.e. not
appeared in the option). If no address is specified in this
field, a care-of address is taken from the source address of the
IPv6 header. If the option is included in any other messages than
a Binding Update, the length of this field MUST be also zero.
4.4. New Status Values for Binding Acknowledgement
New status values for the status field in a Binding Acknowledgement
are defined for handling the multiple Care-of Addresses registration:
MCOA NOTCOMPLETE (TBD less than 128)
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 14]
Internet-Draft MCoA December 2008
In bulk registration, not all the binding identifier mobility
options were successfully registered. Some of them were rejected.
The error status value of the failed mobility option is
individually stored in the status field of the binding identifier
mobility option.
MCOA RETURNHOME WO/NDP (TBD less than 128)
When a mobile node returns home, it MUST NOT use Neighbor
Discovery Protocol for the home address on the home link. This is
explained in more detail in Section 5.6
MCOA MALFORMED (TBD more than 128)
Registration failed because Binding Identifier mobility option was
not formatted correctly. This value is used in the following
cases.
* when the wrong length value is specified (neither 4, 8 nor 20)
in the length field of the Binding Identifier mobility option.
* when a unicast routable address is not specified in the care-of
address field of the Binding Identifier mobility option.
* when a care-of address is not appeared in the care-of address
field of the Binding Identifier mobility option stored in an
IPsec ESP protected Binding Update.
MCOA BID CONFLICT (TBD more than 128)
The home agent cannot cache both a regular binding and a BID
extended binding simultaneously. It returns this status value
when the received binding conflicts with the existing binding
cache entry(ies).
MCOA PROHIBITED(TBD more than 128)
It implies the multiple care-of address registration is
administratively prohibited.
MCOA BULK REGISTRATION PROHIBITED(TBD more than 128)
Bulk binding registration is not either permitted or supported.
Note that the bulk registration is an optional procedure and might
not be available on a home agent.
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 15]
Internet-Draft MCoA December 2008
MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED (TBD more than 128)
Simultaneous home and foreign attachment is neither supported nor
permitted.
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 16]
Internet-Draft MCoA December 2008
5. Mobile Node Operation
5.1. Management of Care-of Address(es) and Binding Identifier(s)
There are two cases when a mobile node might acquire several care-of
addresses. A mixture of the two cases is also possible. Note that a
mobile node can use BID regardless of the number of interfaces and
care-of addresses. Whether a mobile node uses BID or not is
determined by a local configuration.
1. A mobile node may be using several physical network interfaces
and acquires a care-of address on each of its interfaces.
2. A mobile node uses a single physical network interface, but
receives advertisements for multiple prefixes on the link the
interface is attached to. This will result in the mobile node
configuring several global addresses on the interface from each
of the announced prefixes.
The difference between the above two cases is only in the number of
physical network interfaces and therefore irrelevant in this
document. What is of significance is the fact that the mobile node
has several addresses it can use as care-of addresses.
A mobile node assigns a BID to each care-of address when it wants to
register them simultaneously with its home address. The BID MUST be
unique for a given home address and care-of address pair. The value
should be an integer between 1 and 65535. Zero value SHOULD NOT be
used as BIDs. If a mobile node has only one care-of address, the
assignment of a BID is not needed until it has multiple care-of
addresses to register with, at which time all of the care-of
addresses MUST be mapped to BIDs.
5.2. Binding Registration
For the multiple Care-of Addresses registration, the mobile node MUST
include a Binding Identifier mobility option(s) in the Binding Update
as shown in Figure 6. The BID is copied from a corresponding Binding
Update List entry to the BID field of the Binding Identifier mobility
option.
When IPsec ESP is used for protecting the Binding Update, a care-of
address MUST be carried in an alternate care-of address mobility
option as described in [RFC-4877]. However, in this specification,
the care-of address MUST be carried in the Care-of Address field of
the Binding Identifier mobility option. In order to save bits of the
Binding Update, the alternate care-of address option MUST NOT be
included.
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 17]
Internet-Draft MCoA December 2008
For binding registration to a correspondent node, the mobile node
MUST have both active Home and Care-of Keygen tokens for Kbm (see
Section 5.2.5 of [RFC-3775]) before sending the Binding Update. The
care-of Keygen tokens MUST be maintained for each care-of address
that the mobile node wants to register to the correspondent node.
The Binding Update to the correspondent node is protected by the
Binding Authorization Data mobility option that is placed after the
Binding Identifier mobility option.
IPv6 header (src=Care-of Address, dst=Home Agent Address)
IPv6 Home Address Option
ESP Header*
Mobility header
Binding Update
Mobility Options
Binding Identifier mobility option
Binding Authorization mobility option+
(*) if necessary, for home registration
(+) if necessary, for route optimization
Figure 6: Binding Update for Binding Registration
If the mobile node wants to replace existing registered bindings on
the home agent with the single binding in the sent Binding Update, it
sets the 'O' flag. Section 6.2 describes this registration procedure
in detail.
5.3. Bulk Registration
Bulk registration is an optimization for binding multiple care-of
addresses to a home address using a single Binding Update. This is
very useful if the mobile node, for instance, does not want to send a
lot of signaling messages through an interface where the bandwidth is
scarce. This document specifies bulk registration only for the
mobile node's home registration. A mobile node performing bulk
registration with a correspondent node is out of scope.
To use bulk registration, the mobile node includes a Binding
Identifier Mobility option for each BID and Care-of address pair it
wants to register in the same Binding Update message. This is shown
in Figure 7. The rest of the fields and options in the Binding
Update such as Lifetime, Sequence Number, and the flags in the
Binding Update are common across all care-of addresses.
When IPsec ESP is used for protecting the Binding Update, a care-of
address MUST be carried in an alternate care-of address mobility
option as described in [RFC-4877]. However, in the bulk
registration, the care-of addresses are always carried in the Care-of
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 18]
Internet-Draft MCoA December 2008
Address field of the Binding Identifier mobility option. In order to
save bits of the Binding Update, the alternate care-of address option
MUST NOT be included in such Binding Update.
IPv6 header (src=Care-of Address, dst=Home Agent Address)
IPv6 Home Address Option
ESP Header
Mobility header
Binding Update
Mobility Options
Binding Identifier (including Care-of Address)
Figure 7: Binding Update for Bulk Registration
If the mobile node wants to replace existing registered bindings on
the home agent with the multiple bindings in the sent Binding Update,
it sets the 'O' flag in the Binding Update.
5.4. Binding De-Registration
When a mobile node decides to delete all the bindings for its home
address, it sends a regular de-registration Binding Update with
lifetime set to zero as defined in [RFC-3775]. The Binding
Identifier mobility option is not required.
If a mobile node wants to delete a particular binding(s) from its
home agent and correspondent nodes, the mobile node sends a Binding
Update with lifetime set to zero and includes a Binding Identifier
mobility option(s) with the BID(s) it wants to de-register. The
receiver will remove only the care-of address(es) that match(es) the
specified BID(s). The care-of addresses field in each mobility
option SHOULD be omitted by the sender (i.e. the field does not
appear in the option) and MUST be ignored by the receiver. This is
because the receiver will remove the binding that matches the
specified BID.
5.5. Returning Home: Using Single Interface
The mobile node may return to the home link, by attaching to the home
link through one of its interfaces. When the mobile node wants to
return home, it should be configured with information on what
interface it needs to use.
5.5.1. Using only Interface attached to the Home Link
The mobile node returns home and de-registers all the bindings as
shown in Figure 2 and as defined in [RFC-3775]. De-registering all
the bindings is the same as binding de-registration from foreign link
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 19]
Internet-Draft MCoA December 2008
described in Section 5.4. After the de-registration step, all the
packets routed by the home agent are only forwarded to the interface
attached to the home link, even if there are other active interfaces
attached to the visited link(s). While the mobile node de-registers
all the bindings from the home agent, it may continue registering
bindings for interface(s) attached to visited link(s) to the
correspondent node as shown in Figure 2.
5.5.2. Using only Interface attached to the Visited Link
The mobile node returns home physically but shuts down the interface
attached to the home link. As a result, a mobile node does not
return home even though it attaches to the home link by one of
interfaces. Following procedures should be taken by the mobile node.
Before shutting down the interface, any binding for the care-of
address previously associated with the interface should be deleted.
To delete the binding cache entry, the mobile node SHOULD send a de-
registration Binding Update with the lifetime set to zero and include
the corresponding BID information. If the mobile node does not send
a de-registration Binding Update, the binding for the care-of address
previously assigned to the interface remains at the home agent until
its lifetime expires.
In this scenario, despite the fact that the mobile node is connected
to its home link, all of its traffic is sent and received via the
home agent and its foreign links.
5.6. Returning Home: Simultaneous Home and Visited Link Operation
5.6.1. Problems of Simultaneous Home and Foreign Attachments
The mobile node returns home and continues using all the interfaces
attached to both foreign and home links as shown in Figure 3. The
mobile node indicates this by setting the 'H' flag in the BID
mobility option as defined below. There are additional requirements
on the Returning Home procedures for possible Neighbor Discovery
state conflicts at the home link.
In [RFC-3775], the home agent intercepts packets meant for the mobile
node using Proxy Neighbor Discovery [RFC-4861] while the mobile node
is away from the home link. When the mobile node returns home, the
home agent deletes the binding cache and stops proxying for the home
address so that a mobile node can configure its home address on the
interface attached to the home link. In this specification, a mobile
node may return home, configure the home address on the interface
attached to the home link, but still use the interfaces attached to
the foreign links. In this case, a possible conflict arises when the
both the home agent and the mobile node try to defend the home
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 20]
Internet-Draft MCoA December 2008
address. If the home agent stops proxying for the home address, the
packets are always routed to the interface attached to the home link
and are never routed to the interfaces attached to the visited links.
It is required to avoid the conflict between the home agent and the
mobile node, while still allowing the simultaneous use of home and
foreign links. The following describes the mechanism for achieving
this.
5.6.2. Overview and Approach
In this specification, the home agent MUST intercept all the packets
meant for the mobile node and decide whether to send the traffic
directly to the home address on the link or tunnel to the care-of
address. The home agent intercepts all the packets even when the
mobile node is attached to the home link through one of its
interfaces. The home agent would make this decision based on the
type of flow. How to make this decision is out of scope in this
document.
Two scenarios are illustrated in Figure 3, depending on whether the
Home Agent is the only router at the home link or not. The
difference is on who defends the home address by (Proxy) Neighbor
Discovery on the home link.
1. Mobile node defends the home address by the regular Neighbor
Discovery Protocol (illustrated as topology-a in Figure 3). The
home agent is the only router on the home link. Therefore the
home agent is capable of intercepting packets without relying on
the proxy Neighbor Discovery protocol and the mobile node can
manage the Neighbor Cache entry of the home address on the home
link as a regular IPv6 node. However, there is one limitation of
this scenario. If a correspondent node is located at the home
link, the home agent may not intercept the packets destined to
the mobile node. These packets are routed only via the home
link, but this is the most optimal path for the mobile node to
communicate with nodes on the home link.
2. If there are other routers on the home link apart from the home
agent, then it cannot be guaranteed that all packets meant for
the mobile node are routed to the home agent. In this case, the
mobile node MUST NOT operate the Neighbor Discovery protocol for
the home address on the home link. This allows the home agent to
keep using proxy neighbor discovery and thus it keeps receiving
all the packets sent to the mobile node's home address. If the
home agent, according to its local policy, needs to deliver
packets to the mobile node over the home link, an issue arises
with respect to how the home agent discovers the mobile node's
link local address. This specification uses the Link-layer
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 21]
Internet-Draft MCoA December 2008
Address (LLA) Option defined in [RFC-5268] in order to carry the
mobile node's link-layer address in the Binding Update.
Likewise, the mobile node would also know the link-layer address
of the default router address to send packets from the home link
without Neighbor Discovery. The link-layer address is used to
transmit packets from and to the mobile node on the home link.
The packets are transmitted without the Neighbor Discovery
protocol by constructing the link-layer header manually. This
operation is similar to Mobile IPv6 [RFC-3775] when a mobile node
sends a deregistration binding update to the home agent's link-
layer address in the operation for returning home.
5.6.3. Sending Deregistration Binding Update
o As soon as a mobile node returns home, it sends a de-registration
Binding Update to the home agent from the interface attached to
the home link.
o The mobile node MUST include the BID mobility option specifying
the BID the mobile node had previously associated with the
interface attached to the home link. The 'H' flag MUST be set in
the BID mobility option. For the binding deregistration, a mobile
node SHOULD NOT store a care-of address in the Care-of Address
field of the BID mobility option. The receive, the home agent,
can match the removed binding with BID value in the BID mobility
option. If the mobile node has to remove multiple bindings
simultaneously, it contains multiple BID mobility options and sets
'O' flag in the Binding Update message. When the 'H' flag is set,
the home agent recognizes that the mobile node wants to continue
using interfaces attached to both home and visited links. Note
that H flag MUST be set for the subsequent binding updates sent
from the mobile node (ex. Binding Update for the interface(s)
attached to the foreign link(s)). If the home agent does not
allow this scenario, it MUST send a Binding Acknowledgement with
the status code [MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED]
set.
o The mobile node SHOULD include the Link-layer Address (LLA) Option
[RFC-5268] to notify the mobile node's link-layer address to the
home agent, too. The option code of the Link-layer Address (LLA)
option MUST be set to '2' (Link-layer Address of the mobile node).
This link-layer address is required for the home agent to send the
Binding Acknowledgement and to forward the mobile node's packet.
o According to [RFC-3775], the mobile node MUST start responding to
Neighbor Solicitation for its home address right after it sends
the deregistration Binding Update to the home agent. However, in
this specification, the mobile node MUST NOT respond to Neighbor
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 22]
Internet-Draft MCoA December 2008
Solicitation before receiving a Binding Acknowledgement, since the
home agent may continue proxying for the home address. If the
mobile node receives [MCOA RETURNHOME WO/NDP (TBD)] status value
in the received Binding Acknowledgment, it MUST NOT respond to
Neighbor Solicitation even after the Binding Acknowledgement.
5.6.4. Sending Binding Acknowledgement
The operations described in this section is for Home Agent and not
for Mobile Node. However, the Home Agent operations described in
this section are related to the returning home using simultaneous use
of home and foreign links.
o When the home agent sends the Binding Acknowledgement after
successfully processing the binding de-registration, it MUST set
the status value to either 0 [Binding Update Accepted] or to [MCOA
RETURNHOME WO/NDP (TBD)] in the Status field of the Binding
Acknowledgment depending on home agent configuration at the home
link. The new values are:
* Binding Update Accepted (0): Neighbor Discovery Protocol is
permitted for the home address at the home link. This is
regular returning home operation of [RFC-3775]
* MCOA RETURNHOME WO/NDP (TBD): Neighbor Discovery Protocol is
prohibited for the home address at the home link
The respective Binding Identifier mobility options need to be
included in the Binding Acknowledgement.
o If the binding update is rejected, the appropriate error value
MUST be set in the status field. In this case, the home agent
operation is the same as [RFC-3775].
o Only if the home agent is certainly the only router in the home
link, it MAY turn off Neighbor Discovery for the requested home
address and responds with the [Binding Update Accepted] status
value to the mobile node. Since the mobile node will not reply to
Neighbor Solicitation for the home address before receiving the
Binding Acknowledgement, the home agent SHOULD use the link-layer
address carried by the Link Layer Address option [RFC-5268] in the
received Binding Update. After the completion of the binding
deregistration, the mobile node starts regular Neighbor Discovery
operations for the home address on the home link. The neighbor
cache entry for the home address is created by the regular
exchange of Neighbor Solicitation and Neighbor Advertisement.
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 23]
Internet-Draft MCoA December 2008
o On the other hand, the home agent returns [MCOA RETURNHOME WO/NDP]
value in the Status field of the BID mobility option. The home
agent learns the mobile node's link-layer address by receiving the
link-layer address option carried by the Binding Update. It
stores the link-layer address as a neighbor cache entry for the
mobile node so that it can send the packets to the mobile node's
link-layer address.
o Note that the use of proxy Neighbor Discovery is an easier way to
intercept the mobile nodes' packets instead of IP routing in some
deployment scenarios. Therefore, even if a home agent is the only
router, it is an implementation and operational choice whether the
home agent returns [Binding Update Accepted] or [MCOA RETURNHOME
WO/NDP].
o If BID option is not included in the Binding Acknowledgement, the
home agent might not recognize the simultaneous home and foreign
attachment. The home agent might have processed the de-
registration Binding Update as a regular de-registration as
described in [RFC-3775] and deletes all the registered binding
cache entries for the mobile node. Thus, the mobile node SHOULD
stop using the interface attached to foreign link and use only the
interface attached to the home link.
5.6.5. Sending Packets from the Home Link
o When the mobile node receives the Binding Acknowledgement with the
status value 'Binding Update Accepted' and the BID option, it can
configure its home address to the interface attached to the home
link and start operating Neighbor Discovery for the home address
on the home link. Packets can be transmitted from and to the
mobile node as if the mobile node is a regular IPv6 node.
o If the mobile node receives the status [MCOA RETURNHOME WO/NDP] in
the Binding Acknowledgement, it MUST NOT operate Neighbor
Discovery for the home address. When the mobile node sends
packets from the interface attached to the home link, it MUST
learn the link-layer address of the next hop (i.e. default router
of the mobile node). A mobile node learns the default router's
link-layer address from a Source Link-Layer Address option in
Router Advertisements. The mobile node sends packets directly to
the default router's link-layer address. This is done by
constructing the packet including link-layer header with the
learned link-layer address of the default router. The home agent
also forwards the packet to the mobile node on the home link by
using the mobile node's link-layer address. The link-layer
address SHOULD be cached when the home agent received the
deregistration Binding Update message. Note that the default
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 24]
Internet-Draft MCoA December 2008
router MUST NOT cache the mobile node's link-layer address in the
neighbor cache when it forwards the packet from the mobile node to
the home agent.
5.6.6. Leaving from the Home Link
o When the mobile node detaches from the home link, it SHOULD
immediately send a binding update for one of active care-of
address with H flag unset. When the 'H' flag of BID option is
unset in any Binding Update, the home agent stop forwarding the
mobile node's packets to the home link.
5.6.6.1. Changing Behavior during the attachment to the home link
If a mobile node decides to return home completely without any active
foreign link attachment, it simply sends a deregistration binding
update as described in Section 5.5.1. Once the home agent receives
such de-registration binding update, the home agent clears all the
binding(s) and state for the mobile node.
If a mobile node decides to stop using the interface attached to the
home link, it simply sends a binding update from one of the active
care-of addresses. In the Binding Update, the mobile node should
include the BID option for the care-of address and unset the H flag
of the BID option. The home agent clears the state of the mobile
node for the interface attached to the home link and stops forwarding
the packets to the mobile node on the home link.
5.7. Receiving Binding Acknowledgement
The verification of a Binding Acknowledgement is the same as Mobile
IPv6 (section 11.7.3 of [RFC-3775]). The operation for sending a
Binding Acknowledgement is described in Section 6.2.
If a mobile node includes a Binding Identifier mobility option in a
Binding Update with the 'A' flag set, a Binding Acknowledgement MUST
carry a Binding Identifier mobility option. According to [RFC-3775],
the receiver of the Binding Update ignores unknown mobility options
and processes the Binding Update without the unknown mobility option.
Therefore, if no such mobility option is included in the Binding
Acknowledgement in response to a Binding Update for multiple care-of
address registration, this indicates that the originating node of the
Binding Acknowledgement does not support processing the Binding
Identifier mobility option regardless of status value. In such case,
the receiver of the Binding Update may create a regular binding. The
mobile node then no longer attempts multiple care-of address
registration with that node. If this occurs with home registration
the mobile node MAY attempt to discover another home agent supporting
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 25]
Internet-Draft MCoA December 2008
BID mobility option for the home registration.
If a Binding Identifier mobility option is present in the received
Binding Acknowledgement, the mobile node checks the status field in
the option. If the status value in the Binding Identifier mobility
option is zero, the mobile node uses the value in the Status field of
the Binding Acknowledgement. Otherwise, it uses the value in the
Status field of the Binding Identifier mobility option.
If the status code is greater than or equal to 128, the mobile node
starts relevant operations according to the error code. Otherwise,
the mobile node assumes that the originator (home agent or
correspondent node) successfully registered the binding information
and BID for the mobile node.
o If the Status value is [MCOA PROHIBITED], the mobile node MUST
stop registering multiple bindings with the node that sent the
Binding Acknowledgement.
o If the Status value is [MCOA BULK REGISTRATION NOT SUPPORT], the
mobile node needs to stop using bulk registrations with the node
that sent the Binding Acknowledgement. It should assume that none
of the attempted registrations were successful.
o If [MCOA MALFORMED] is specified, it indicates that the binding
identifier mobility option is formatted wrongly presumably due to
a programming error or major packet corruption. .
o If [MCOA BID CONFLICT] is specified, the binding entry specified
by the Binding Identifier mobility option is already registered as
a regular binding. In such case, the mobile node needs to stop
sending Binding Updates with BID, or SHOULD use the 'O' flag to
reset all the registered bindings as described in Section 5.9.
5.8. Receiving Binding Refresh Request
The verification of a Binding Refresh Request is the same as in
Mobile IPv6 (section 11.7.4 of [RFC-3775]). The operation of sending
a Binding Refresh Request is described in Section 6.3.
If a mobile node receives a Binding Refresh Request with a Binding
Identifier mobility option, it indicates that the node sending the
Binding Refresh Request message is requesting the mobile node to send
a new Binding Update for the BID. The mobile node SHOULD then send a
Binding Update at least for the respective binding. The mobile node
MUST include a Binding Identifier mobility option in the Binding
Update.
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 26]
Internet-Draft MCoA December 2008
5.9. Bootstrapping
When a mobile node bootstraps and registers multiple bindings for the
first time, it MUST set the 'O' flag in the Binding Update message.
If old bindings still exists at the home agent, the mobile node has
no knowledge of which bindings still exist at the home agent. This
scenario happens when a mobile node reboots and loses state regarding
the registrations. If the 'O' flag is set, all the bindings are
replaced by the new binding(s). If the mobile node receives the
Binding Acknowledgement with the status code set to 135 [Sequence
number out of window], it MUST follow the operations described in
[RFC-3775].
The 'O' flag can also be used in individual Binding Updates sent to
the correspondent nodes to override any existing binding cache
entries at the correspondent node.
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 27]
Internet-Draft MCoA December 2008
6. Home Agent and Correspondent Node Operation
6.1. Searching Binding Cache with Binding Identifier
If either a correspondent node or a home agent has multiple bindings
for a mobile node in their binding cache database, it can use any of
the bindings to communicate with the mobile node. This section
explains how to retrieve the desired binding for the binding
management. This document does not provide any mechanism to select
the suitable binding for forwarding data packets.
A node which is either a correspondent node or a home agent SHOULD
use both the home address and the BID as the search key of the
binding cache if it knows the corresponding BID (example: when
processing signaling messages). In the example below, if a node
searches the binding with the home address and BID2, it gets binding2
for this mobile node.
binding1 [2001:db8::EUI, care-of address1, BID1]
binding2 [2001:db8::EUI, care-of address2, BID2]
binding3 [2001:db8::EUI, care-of address3, BID3]
Figure 8: Searching the Binding Cache
The node learns the BID when it receives a Binding Identifier
mobility option. At that time, the node MUST look up its binding
cache database with the home address and the BID retrieved from the
Binding Update. If the node does not know the BID, it searches for a
binding with only the home address. In such a case, the first
matched binding is found. If the node does not desire to use
multiple bindings for a mobile node, it can simply ignore the BID.
6.2. Processing Binding Update
If a Binding Update does not contain a Binding Identifier mobility
option, its processing is the same as in [RFC-3775]. If the receiver
already has multiple bindings for the home address, it MUST replace
all the existing bindings by the received binding. As a result, the
receiver node MUST have only one binding cache entry for the mobile
node. If the Binding Update is for de-registration, the receiver
MUST delete all existing bindings from its Binding Cache.
If the Binding Update contains a Binding Identifier mobility
option(s), it is first validated according to section 9.5.1 of [RFC-
3775]. Then the receiver processes the Binding Identifier mobility
option(s) as described in the following steps.
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 28]
Internet-Draft MCoA December 2008
o The length value is examined. The length value MUST be either 4,
8, or 20 depending on the Care-of Address field. If the length is
incorrect, the receiver MUST reject the Binding Update and returns
the status value set to [MCOA MALFORMED].
o When the Length value is either 8 or 20, the care-of address MUST
be present in the Binding Identifier mobility option. If the
unicast routable address [RFC-3775] is not present in the care-of
address field, the receiver MUST reject the Binding Identifier
mobility option and returns the status value set to [MCOA
MALFORMED].
o If the Binding Update is protected with IPsec ESP, the care-of
address MUST be appeared in the Binding Identifier mobility
option. If no address is appeared in the care-of address field in
that mobility option, it MUST reject the Binding Identifier
mobility option and returns the status value set to [MCOA
MALFORMED].
o If the care-of address is appeared in both the alternate care-of
address mobility option and the Binding Identifier mobility option
at the same time, it MUST ignore the alternate care-of address
mobility option and can continue processing the Binding Update
with the care-of address specified in the Binding Identifier
mobility option.
o When multiple Binding Identifier mobility options are present in
the Binding Update, it is treated as bulk registration. If the
receiving node is a correspondent node, it MUST reject the Binding
Update and returns the status value in the binding Acknowledgement
set to [MCOA BULK REGISTRATION NOT SUPPORT].
o If the Lifetime field in the Binding Update is set to zero, the
receiving node deletes the binding entry that corresponds to the
BID in the Binding Identifier mobility option. If the receiving
node does not have an appropriate binding for the BID, it MUST
reject the Binding Update and send a Binding Acknowledgement with
status set to 133 [not home agent for this mobile node].
o If the 'O' flag is set in the de-registering Binding Update, it is
ignored. If the 'H' flag is set, the home agent stores a home
address in the Care-of Address field of the binding cache entry.
The home agent MUST follow the descriptions described in
Section 5.6.
o If the Lifetime field is not set to zero, the receiving node
registers a binding with the specified BID as a mobile node's
binding. The Care-of address is obtained from the Binding Update
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 29]
Internet-Draft MCoA December 2008
packet as follows:
* If the Length value of the Binding Identifier mobility option
is 20, the care-of address is copied the IPv6 address from the
care-of address field in the Binding Identifier mobility
option. When the Length value is 8, the address MUST be the
IPv4 valid address. Detail information can be found in
Section 8.
* If the Length value of the Binding Identifier mobility option
is 4, the care-of address is copied from the source address
field of the IPv6 header.
* If the Length value of the Binding Identifier mobility option
is 4 and an alternate care-of address is present, the care-of
address is copied from the Alternate Care-of address mobility
option.
o Once the care-of address(es) have been retrieved from the Binding
Update, the receiving nodes creates new binding(s).
* If the 'O' flag is set in the Binding Update, the home agent
removes all the existing bindings and registers the received
bindings.
* If the 'O' flag is unset in the Binding Update and the receiver
has a regular binding which does not have BID for the mobile
node, it must not process the Binding Update. The receiver
should sent a binding Acknowledgement with status set to [MCOA
BID CONFLICT].
* If the receiver already has a binding with the same BID but
different care-of address, it MUST update the binding and
respond with a Binding Acknowledgement with status set to 0
[Binding Update accepted].
* If the receiver does not have a binding entry for the BID, it
registers a new binding for the BID and responds with a Binding
Acknowledgement with status set to 0 [Binding Update accepted].
If all the above operations are successfully completed, a Binding
Acknowledgement containing the Binding Identifier mobility options
MUST be sent to the mobile node. Whenever a Binding Acknowledgement
is sent, all the Binding Identifier mobility options stored in the
Binding Update MUST be copied to the Binding Acknowledgement except
the status field. The Care-of address field in each Binding
Identifier mobility option, however, MAY be omitted, because the
mobile node can match a corresponding binding update list entry using
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 30]
Internet-Draft MCoA December 2008
the BID.
When a correspondent node sends a Binding Acknowledgement, the status
value MUST be always stored in the Status field of the Binding
Acknowledgement and the Status field of Binding Identifier mobility
option MUST be always set to zero.
When the home agent sends a Binding Acknowledgement, the status value
can be stored in the Status field of either a Binding Acknowledgement
or a Binding Identifier mobility option. If the status value is
specific to one of bindings in the bulk registration, the status
value MUST be stored in the Status field in the corresponding Binding
Identifier mobility option. In this case, [MCOA NOTCOMPLETE] MUST be
set in the Status field of the Binding Acknowledgement so that the
receiver will examine the Status field of each Binding Identifier
mobility option for further operations. Otherwise, the status field
of the Binding Identifier mobility option MUST be set to zero and the
home agent status field of the Binding Acknowledgement is used.
6.3. Sending Binding Refresh Request
When a node (home agent or correspondent node) sends a Binding
Refresh Request for a particular binding created with the BID, the
node SHOULD include the Binding Identifier mobility option in the
Binding Refresh Request. The node MAY include multiple Binding
Identifier mobility options if there are multiple bindings that need
to be refreshed.
6.4. Receiving Packets from Mobile Node
When a node receives packets with a Home Address destination option
from a mobile node, it MUST check that the care-of address that
appears in the source address field of the IPv6 header MUST be equal
to one of the care-of addresses in the binding cache entry. If no
binding is found, the packets MUST be discarded. The node MUST also
send a Binding Error message as specified in [RFC-3775]. This
verification MUST NOT be done for a Binding Update.
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 31]
Internet-Draft MCoA December 2008
7. Network Mobility Applicability
The binding management mechanisms are the same for a mobile host that
uses Mobile IPv6 and for a mobile router that is using the NEMO Basic
Support protocol [RFC-3963]. Therefore the extensions described in
this document can also be used to support a mobile router with
multiple care-of addresses. [RFC-4980] is a document for an analysis
of NEMO multihoming.
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 32]
Internet-Draft MCoA December 2008
8. DSMIPv6 Applicability
Dual Stack Mobile IPv6 (DSMIPv6) [ID-DSMIPv6] extends Mobile IPv6 to
register an IPv4 care-of address instead of the IPv6 care-of address
when the mobile node is attached to an IPv4-only access network. It
also allows the mobile node to acquire an IPv4 home address in
addition to an IPv6 home address for use with IPv4-only correspondent
nodes. This section describes how multiple care-of address
registration works with IPv4 care-of and home addresses.
8.1. IPv4 Care-of Address Registration
The mobile node can use the extensions described in the document to
register multiple care-of addresses, even if some of the care-of
addresses are IPv4 address.
Bulk registration MUST NOT be used for the initial binding from an
IPv4 care-of address. This is because, the Binding Update and
Binding Acknowledgement exchange is used to detect NAT on the path
between the mobile node and the home agent. So the mobile node needs
to check for a NAT between each IPv4 care-of address and the home
agent.
The Binding Update MUST be sent to the IPv4 home agent address by
using UDP and IPv4 headers as shown in Figure 9. It is similar to
[ID-DSMIPv6] except that the IPv4 care-of address option MUST NOT be
used when the BID mobility option is used.
IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
UDP Header
IPv6 header (src=V6HoA, dst=HAADDR)
ESP Header
Mobility header
-Binding Update
Mobility Options
- Binding Identifier (IPv4 CoA)
*V4ADDR, HA_V4ADDR, V6HOA, HAADDR are defined in [ID-DSMIPv6]
Figure 9: Initial Binding Update for IPv4 Care-of Address
If a NAT is not detected, the mobile node can update the IPv4 care-of
address by using bulk registration. The mobile node can register the
IPv4 care-of address along with other IPv4 and IPv6 care-of
addresses. Figure 10 shows the Binding Update format when the mobile
node sends a Binding Update from one of its IPv6 care-of addresses.
If the mobile node sends a Binding Update from IPv4 care-of address,
it MUST follow the format described in Figure 9. Note that the IPv4
Care-of Address must be registered by non bulk Binding registration,
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 33]
Internet-Draft MCoA December 2008
whenever it is changed.
IPv6 header (src=Care-of Address, dst=Home Agent Address)
IPv6 Home Address Option
ESP Header
Mobility header
-Binding Update
Mobility Options
- Binding Identifier (IPv6/v4 CoA)
- Binding Identifier (IPv6/v4 CoA)
- ...
Figure 10: Binding Bulk Registration for IPv4 care-of address
If the home agent rejects the IPv4 care-of address, it MUST store the
error code value in the Status field of the BID mobility option.
8.2. IPv4 Home Address Management
When the mobile node wants to configure an IPv4 home address in
addition to the IPv6 home address, it can request for one using the
IPv4 Home Address option in the Binding Update. If the home agent
accepts the Binding Update, the mobile node can now register multiple
care-of addresses for the IPv4 home address in addition to the IPv6
home address. The same set of care-of addresses will be registered
for both IPv6 and IPv4 home addresses. The mobile node cannot bind a
different set of care-of addresses to each home address.
According to [ID-DSMIPv6], the home agent includes the IPv4 address
acknowledgement option in the Binding Acknowledgement only if the
mobile node had requested for an IPv4 home address in the
corresponding Binding Update. The IPv4 address acknowledgement
option MUST be present before any BID option. The status field of
the IPv4 address acknowledgement option contains only the error code
corresponding to the IPv4 home address management. The error values
related to the IPv4 care-of address registration MUST be stored in
the BID mobility option.
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 34]
Internet-Draft MCoA December 2008
9. IPsec and IKEv2 interaction
Mobile IPv6 [RFC-3775] and the NEMO protocol [RFC-3963] require the
use of IPsec to protect signaling messages including Binding Updates,
Binding Acknowledgements and return routability messages. IPsec may
also be used protect all tunneled data traffic. The Mobile IPv6-
IKEv2 specification [RFC-4877] specifies how IKEv2 can be used to
setup the required IPsec security associations. The following
assumptions were made in [RFC-3775], [RFC-3963] and [RFC-4877] with
respect to the use of IKEv2 and IPsec.
o There is only one primary care-of address per mobile node.
o The primary care-of address is stored in the IPsec database for
tunnel encapsulation and decapsulation.
o When the home agent receives a packet from the mobile node, the
source address is verified against the care-of address in the
corresponding binding cache entry. If the packet is a reverse
tunneled packet from the mobile node, the care-of address check is
done against the source address on the outer IPv6 header. The
reverse tunnel packet could either be a tunneled Home Test Init
message or tunneled data traffic to the correspondent node.
o The mobile node runs IKEv2 (or IKEv1) with the home agent using
the care-of address. The IKE SA is based on the care-of address
of the mobile node.
The above assumptions may not be valid when multiple care-of
addresses are used by the mobile node. In the following sections,
the main issues with the use of multiple care-of address with IPsec
are addressed.
9.1. Use of Care-of Address in the IKEv2 exchange
For each home address the mobile node sets up security associations
with the home agent, the mobile node must pick one care-of address
and use that as the source address for all IKEv2 messages exchanged
to create and maintain the IPsec security associations associated
with the home address. The resultant IKEv2 security association is
created based on this care-of address.
If the mobile node needs to change the care-of address, it just sends
a Binding Update with the care-of address it wants to use, with the
corresponding Binding Identifier mobility option, and with the 'K'
bit set. This will force the home agent to update the IKEv2 security
association to use the new care-of address. If the 'K' bit is not
supported on the mobile node or the home agent, the mobile node MUST
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 35]
Internet-Draft MCoA December 2008
re-establish the IKEv2 security association with the new care-of
address. This will also result in new IPsec security associations
being setup for the home address.
9.2. Transport Mode IPsec protected messages
For Mobile IPv6 signaling message protected using IPsec in transport
mode, the use of a particular care-of address among multiple care-of
addresses does not matter for IPsec processing.
The home agent processes Mobile Prefix Discovery messages with the
same rules of data packets described in Section 6.4.
9.3. Tunnel Mode IPsec protected messages
The use of IPsec in tunnel mode with multiple care-of address
introduces a few issues that require changes to how the mobile node
and the home agent send and receive tunneled traffic. The route
optimization mechanism described in [RFC-3775] mandates the use of
IPsec protection in tunnel mode for the Home Test Init and Home Test
messages. The mobile node and the home agent may also choose to
protect all reverse tunneled payload traffic with IPsec in tunnel
mode. The following sections address multiple care-of address
support for these two types of messages.
9.3.1. Tunneled Home Test Init and Home Test messages
The mobile node MAY use the same care-of address for all Home Test
Init messages sent reverse tunneled through the home agent. The
mobile node may use the same care-of address irrespective of which
correspondent node the Home Test Init message is being sent. RFC
3775 requires the home agent to verify that the mobile node is using
the care-of address that is in the binding cache entry, when it
receives a reverse tunneled Home Test Init message. If a different
address is used as the source address, the message is silently
dropped by the home agent. This document requires the home agent
implementation to decapsulate and forward the Home Test Init message
as long as the source address is one of the care-of addresses in the
binding cache entry for the mobile node.
When the home agent tunnels a Home Test message to the mobile node,
the care-of address used in the outer IPv6 header is not relevant to
the Home Test message. So regular IPsec tunnel encapsulation with
the care-of address known to the IPsec implementation on the home
agent is sufficient.
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 36]
Internet-Draft MCoA December 2008
9.3.2. Tunneled Payload Traffic
When the mobile sends and receives multiple traffic flows protected
by IPsec to different care-of addresses, the use of the correct
care-of address for each flow becomes important. Support for this
requires the following two considerations on the home agent.
o When the home agent receives a reverse tunneled payload message
protected by IPsec in tunnel mode, it still needs to be aware of
which care-of address is being used. According to RFC 4306, the
IPsec implementation on the home agent does not check the source
address on the outer IPv6 header. However, the stack on the home
agent MUST still be informed about the source address in order to
choose the most recently used care-of address, as discussed in
Section 3 (in the absence of a user-supplied policy).
o For tunneled IPsec traffic from the home agent to the mobile node,
The IPsec implementation on the home agent may not be aware of
which care-of address to use when performing IPsec tunnel
encapsulation. The Mobile IP stack on the home agent must specify
the tunnel end point for the IPsec tunnel. This may require tight
integration between the IPsec and Mobile IP implementations on the
home agent.
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 37]
Internet-Draft MCoA December 2008
10. Security Considerations
The security considerations for securing the Binding Update and
binding acknowledgement messages with multiple care-of address are
very similar to the security considerations for securing the Binding
Update and binding acknowledgement. Please see [RFC-3775] for more
information. The Binding Update and binding acknowledgement messages
with multiple care-of addresses are securely exchanged as described
in [RFC-3775], [RFC-4877] and Section 9. Additional security
considerations are described below.
With simultaneous binding support, it is possible for a malicious
mobile node to successfully bind a number of victims' addresses as
valid care-of addresses for the mobile node with its home agent.
Once these addresses have been bound, the malicious mobile node can
perform a re-direction attack by instructing the home agent (e.g.
setting filtering rules to direct a large file transfer) to tunnel
packets to the victims' addresses. Such risk is highlighted in [ID-
MIP6ANALYSIS]. These attacks are possible because the care-of
addresses sent by the mobile node in the Binding Update messages are
not verified by the home agent, i.e., the home agent does not check
if the mobile node is at the care-of address it is claiming to be.
The security model for Mobile IPv6 assumes that there is a trust
relationship between the mobile node and its home agent. Any
malicious attack by the mobile node is traceable by the home agent.
This acts as a deterrent for the mobile node to launch such attacks.
Although such a risk exists in Mobile IPv6, the risk level is
increased when simultaneous multiple care-of address bindings are
performed. In Mobile IPv6, a mobile node can only have a single
care-of address binding per home address at a given time. However,
for simultaneous multiple care-of address bindings, a mobile node can
have more than one care-of address binding per home address at a
given time. This implies that a mobile node using simultaneous
binding support can effectively bind more than a single victim's
address. Another difference is the degree of risk involved. In the
single care-of address binding case, once the re-direction attack is
initiated, a malicious mobile node would be unable to use its home
address for communications (such as to receive control packets
pertaining to the file transfer). However, in the simultaneous
binding support case, a malicious mobile node could bind a valid
care-of address in addition to multiple victims addresses. This
valid care-of address could then be used by the malicious mobile node
to set up flow filtering rules at its home agent, thereby controlling
and/or launching new re-direction attacks.
Thus, in view of such risks, it is advisable for a home agent to
employ some form of care-of address verification mechanism before
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 38]
Internet-Draft MCoA December 2008
using the care-of addresses as a valid routing path to a mobile node.
These mechanisms are out-of scope for this document. The home agent
can also choose to reject bulk registration by using [MCOA BULK
REGISTRATION PROHIBITED] in a Binding Acknowledgement.
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 39]
Internet-Draft MCoA December 2008
11. IANA Considerations
The following Extension Types MUST be assigned by IANA:
o Binding Identifier mobility option type: This must be assigned
from the same space as mobility option in [RFC-3775].
o New Successful Status of Binding Acknowledgement: This status code
must be assigned from the same space as binding acknowledgement
status codes in [RFC-3775].
* MCOA NOTCOMPLETE (TBD)
* MCOA RETURNHOME WO/NDP (TBD)
o New Unsuccessful Status of Binding Acknowledgement: These status
codes must also be assigned from the same space as binding
acknowledgement status codes in [RFC-3775].
* MCOA MALFORMED (TBD)
* MCOA BID CONFLICT (TBD)
* MCOA PROHIBITED(TBD)
* MCOA BULK REGISTRATION PROHIBITED (TBD)
* MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED (TBD)
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 40]
Internet-Draft MCoA December 2008
12. Acknowledgements
The authors would like to special thank George Tsirtsis for thorough
review and suggestions. The authors would also like to thank
Masafumi Aramoto, Keigo Aso, Julien Charbon, Tero Kauppinen, Benjamin
Lim, Martti Kuparinen, Romain Kuntz, Heikki Mahkonen, Nicolas
Montavont, Chan-Wah Ng for their discussions and inputs. Thanks to
Susumu Koshiba, Hiroki Matutani, Koshiro Mitsuya, Koji Okada, Keisuke
Uehara, Masafumi Watari and Jun Murai for earlier work on this
subject.
13. References
13.1. Normative References
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-4861] Narten, T., Nordmark, E., W. Simpson, and H. Soliman,
"Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, September
2007..
[RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC-4877] V. Devarapalli, F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007.
[RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[RFC-4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the revised IPsec Architecture", RFC 4877, April 2007.
[ID-DSMIPv6] Soliman, H., "Mobile IPv6 support for dual stack Hosts
and Routers (DSMIPv6)", draft-ietf-mext-nemo-v4traversal-05 (work in
progress), July 2008.
[RFC-5268] R. Koodli, "Mobile IPv6 Fast Handovers", RFC 5268, June
2008.
13.2. Informative References
[ID-MOTIVATION] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and
K. Kuladinithi, "Motivations and Scenarios for Using Multiple
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 41]
Internet-Draft MCoA December 2008
Interfaces and Global Addresses",
draft-ietf-monami6-multihoming-motivation-scenario-03 (work in
progress), May 2008.
[RFC-4980] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of
Multihoming in Network Mobility Support", RFC 4980, October 2007.
[ID-MIP6ANALYSIS] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and
K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6",
draft-ietf-monami6-mipv6-analysis-05 (Work in progress), May 2008.
[RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[RFC-4885] Ernst, T. and H. Lach, "Network Mobility Support
Terminology", RFC 4885, July 2007.
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 42]
Internet-Draft MCoA December 2008
Authors' Addresses
Ryuji Wakikawa
Toyota ITC / Keio University
6-6-20 Akasaka, Minato-ku
Tokyo 107-0052
Japan
Phone: +81-3-5561-8276
Fax: +81-3-5561-8292
Email: ryuji@xxxxxxxxxxxxxxxxx
Vijay Devarapalli
Wichorus
3590 North First St
San Jose, CA 95134
USA
Email: vijay@xxxxxxxxxxxx
Thierry Ernst
INRIA
INRIA Rocquencourt
Domaine de Voluceau B.P. 105
Le Chesnay, 78153
France
Phone: +33-1-39-63-59-30
Fax: +33-1-39-63-54-91
Email: thierry.ernst@xxxxxxxx
URI: http://www.nautilus6.org/~thierry
Kenichi Nagami
INTEC NetCore Inc.
1-3-3, Shin-suna
Koto-ku, Tokyo 135-0075
Japan
Phone: +81-3-5565-5069
Fax: +81-3-5565-5094
Email: nagami@xxxxxxxxxxxx
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 43]
Internet-Draft MCoA December 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@xxxxxxxxx
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Wakikawa (Ed.), et al. Expires June 8, 2009 [Page 44]
_______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf