[MEXT] Comments on draft-ietf-monami6-multiplecoa-10
arno@natisbad.org (Arnaud Ebalard) Wed, 03 December 2008 08:06 UTC
Return-Path: <mext-bounces@ietf.org>
X-Original-To: monami6-archive@megatron.ietf.org
Delivered-To: ietfarch-monami6-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 5522E3A68B1;
Wed, 3 Dec 2008 00:06:08 -0800 (PST)
X-Original-To: mext@core3.amsl.com
Delivered-To: mext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 299FF3A67F0
for <mext@core3.amsl.com>; Wed, 3 Dec 2008 00:06:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.239
X-Spam-Level:
X-Spam-Status: No, score=-3.239 tagged_above=-999 required=5 tests=[AWL=0.360,
BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id m6F7aqDvVUQK for <mext@core3.amsl.com>;
Wed, 3 Dec 2008 00:06:03 -0800 (PST)
Received: from copper.chdir.org (copper.chdir.org [88.191.97.87])
by core3.amsl.com (Postfix) with ESMTP id EA9723A68B1
for <mext@ietf.org>; Wed, 3 Dec 2008 00:05:43 -0800 (PST)
Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78]
(helo=localhost.localdomain)
by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69)
(envelope-from <arno@natisbad.org>)
id 1L7mjm-0006SX-Qt; Wed, 03 Dec 2008 09:05:35 +0100
X-Hashcash: 1:20:081203:ryuji.wakikawa@gmail.com::5km//sfYsja2T3So:00000000000000000000000000000000000003TL5
X-Hashcash: 1:20:081203:vijay@wichorus.com::u3NPRdilGD75KxDI:00000000000000000000000000000000000000000000359
X-Hashcash: 1:20:081203:mext@ietf.org::NgDYAGuJMRxXeLFl:000035qB
From: arno@natisbad.org (Arnaud Ebalard)
To: Ryuji Wakikawa <ryuji.wakikawa@gmail.com>,
Vijay Devarapalli <vijay@wichorus.com>
X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc
X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026
Date: Wed, 03 Dec 2008 00:03:39 -0800
Message-ID: <877i6h7kis.fsf@natisbad.org>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Cc: IETF MEXT WG ML <mext@ietf.org>
Subject: [MEXT] Comments on draft-ietf-monami6-multiplecoa-10
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>,
<mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>,
<mailto:mext-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mext-bounces@ietf.org
Errors-To: mext-bounces@ietf.org
Hi,
Here are some comments and corrections on the latest version of the
draft (-10).
> 1. Introduction
>
> A mobile node may use various types of network interfaces to obtain
> durable and wide area network connectivity. This is increasingly
> become true with mobile nodes having multiple interfaces such as
^^^^^^
becoming
> 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 or in 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 and negative
> values MUST NOT be used. 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.
BID are protected (encrypted) when exchanged between MN and HA so there
is no need in that case. Just to be sure, this privacy concern is only
for BID exchanged with CN, right?
> 3. Protocol Overview
>
> [snip]
>
> 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
^^^
it
> returning home procedures in more detail.
>
> [snip]
>
> 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 only router on
^^^^^^^^
is the only
> 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.
This may create asymetric routing situations.
> 4. Mobile IPv6 Extensions
>
> This section summarizes the extensions to Mobile IPv6 necessary for
> manage multiple bindings.
^^^^^^
managing
> 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
> individual or bulk binding update, the sequence number is
> incremented. When a home agent receives an individual BU, it should
^^^^^^
Why not making it a MUST?
> update the sequence number for all the bindings for a particular
> mobile node with the sequence number in the received BU.
>
> 4.2. 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 |O|H| Reserved |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
> + +
> : IPv4 or IPv6 care-of address (CoA) :
> + +
> +---------------------------------------------------------------+
>
> Figure 4: BID Mobility Option
>
> Type
>
> Type value for Binding Identifier is TBD
>
>
>
>
>
>
>
> Wakikawa (Ed.), et al. Expires May 8, 2009 [Page 11]
>
> Internet-Draft MCoA November 2008
>
>
> Length
>
> 8-bit unsigned integer. Length of the option, in octets,
> 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 am I missing something?
> 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
^^^^
I don't think DSMIPv6 has been introduced
before that point.
> care-of address field, the length MUST be 12. Otherwise, the
^^
8
> 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
> MUST NOT be used.
>
> 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.
>
> 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.
What about adding at the end. "When present, it must be found in all BID
Mobility Option carried in the Binding Update".
>
> 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.
^^^^^^^^^^^^^^^^^
while attached
> This flag is valid only for a Binding Update sent to the home
> agent.
No processing requirement here. Maybe a pointer to the interesting
section(s) should be added.
>
> Reserved
>
> 5 bits Reserved field. The value MUST be initialized to zero by
^
6
> 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.
^^^^^^^^
acquire
> 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 MUST 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.
Last sentence should be removed. First part does not bring anything
and last part has already been stated previously in the document.
> 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.
Nothing against it (seems logical), but last sentence adds an additional
constraint compared to 3775. Any reason?
> 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
> 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 in physically and 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.
What is the motivation for that scenario?
> 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
> states conflicts at the home link.
>
> In [RFC-3775], the home agent intercepts packets meant for the mobile
> node using the 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
^^^^^^^^
both
> the home 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
>
>
>
> Wakikawa (Ed.), et al. Expires May 8, 2009 [Page 18]
>
> Internet-Draft MCoA November 2008
>
>
> 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 most optimized 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 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 Link-layer 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 returning home operation.
>
>
>
>
> Wakikawa (Ed.), et al. Expires May 8, 2009 [Page 19]
>
> Internet-Draft MCoA November 2008
>
>
> 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.
associated with the
addresses configured on 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,
^^^^^^^
receiver
> 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 with O
> flag set. 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
> all the 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
> 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
>
> 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
>
>
>
> Wakikawa (Ed.), et al. Expires May 8, 2009 [Page 20]
>
> Internet-Draft MCoA November 2008
>
>
> link. The new values are:
>
> * Binding Update Accepted (0): NDP is permitted for the home
> address at the home link. This is regular returning home
> operation of [RFC-3775]
>
> * MCOA RETURNHOME WO/NDP (TBD): NDP is prohibited for the home
> address at the home link
>
> If the binding update is rejected, the appropriate error value
> MUST be set to the status field. In this case, the home agent
> operation is 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.
>
> 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 easier way to
^^^^^^
the easiest
> 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
^^^^^^^
deleted
> cache entries for the mobile node. Thus, the mobile node SHOULD
> stop using the interface attached to foreign link and use only the
^^^^
links
>
>
>
> Wakikawa (Ed.), et al. Expires May 8, 2009 [Page 21]
>
> Internet-Draft MCoA November 2008
>
>
> 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
^^^^^^^^
receives
> 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 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.
>
> 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 to the node that sent the
> Binding Acknowledgement.
>
> 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.
>
>
>
> Wakikawa (Ed.), et al. Expires May 8, 2009 [Page 23]
>
> Internet-Draft MCoA November 2008
>
>
> o If [MCOA MALFORMED] is specified, it indicates that the binding
> identifier mobility option is formatted wrongly.
^^^^^^^^^^^^^^^^^
wrongly formatted
>
> 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 SHOULD stop
> sending Binding Updates with BID, or SHOULD use the 'O' flag to
> reset all the registered bindings.
>
> 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 Section 6.3.
^^^^^^^^^^^^^^^
remove one
> 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.
>
> 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 Identifier
> mobility option. 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
> looses 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 May 8, 2009 [Page 24]
>
> Internet-Draft MCoA November 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 (ex. 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 7: 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 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 May 8, 2009 [Page 25]
>
> Internet-Draft MCoA November 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 12 or 20, the care-of address MUST
^^
8
> 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].
>
> 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
> 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 12, the address MUST be the
^^
8
> 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
>
>
>
> Wakikawa (Ed.), et al. Expires May 8, 2009 [Page 26]
>
> Internet-Draft MCoA November 2008
>
>
> 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 'O' flag is not set in all the Binding Identifier options,
> the home agent MUST return the status value [MCOA MALFORMED] by
> Binding Acknowledgement.
>
> * 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
> 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, can be omitted, because the
> mobile node can match a corresponding binding update list entry using
> 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
^^
of the
> value MUST be stored in the Status field in the corresponding Binding
>
>
>
> Wakikawa (Ed.), et al. Expires May 8, 2009 [Page 27]
>
> Internet-Draft MCoA November 2008
>
>
> Identifier mobility option. In this case, [MCOA NOTCOMPLETE] MUST be
> set to the Status field of the Binding Acknowledgement so that the
> receiver can 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
^^^^^^^
there is already a MUST at the beginning of the sentence: is
BTW, am I wrong to think that this requirement prevents the initial
registration?
> 8. DSMIPv6 Applicability
I skipped this section.
> 9. IPsec and IKEv2 interaction
>
> Mobile IPv6 [RFC-3775] and the NEMO protocol [RFC-3963] require the
> use of IPsec to protect signaling messages like 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 HoTi 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.
What about adding a pointer to [MIGRATE] as a possible solution to do
that (draft-ebalard-mext-pfkey-enhanced-migrate-00).
>From a general standpoint, this has probably already been discussed, but
the handling of the Home Network case adds a lot of complexity to
something pretty simple at the beginning. Moreover, the various cases to
support using the foreign links when at home also add complexity on top
of that w/o providing motivation for this scenario. Even if this has
already been extensively discussed on the list (I did not browse the
archives), this should probably be introduced in the doc.
Cheers,
a+
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext
- [MEXT] Comments on draft-ietf-monami6-multiplecoa… Arnaud Ebalard