Re: [MEXT] WGLC for draft-ietf-monami6-multiplecoa-05.txt
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MEXT] WGLC for draft-ietf-monami6-multiplecoa-05.txt
Hi George,
Thanks a lot for comments, please find my reply inline.
On 2008/02/12, at 0:07, George Tsirtsis wrote:
> Hi Vijay/Ryuji et.al.,
>
> This version (pre-6) is much improved so well done. There are still
> several minor technical issues, unlear text, and nits, which I
> indicate below, but I want to highlight a few more important technical
> issues upfront:
>
> 1) Lifetime of BIDs: I think the relation between BIDs and BU Lifetime
> field is not clear. I think the assumption has been that the Lifetime
> is common across all BIDs.
Yes. This is because BID option does not have lifetime field.
> IMO there needs to be more explicit
> language in the spec to make this clear..
OK
>
> - a BU with one or more BIDs, O=0, and Lifetime != 0, updates the
> lifetime of all the BIDs in the binding cache. i.e., to maintain all
> the BIDs you just need to send a Binding refresh including at least
> BID.(right?)
> - a BU with O=1 replaces all BIDs and associates them with lifetime
> in the BU
> - a BU with one or more BIDs, O=0, and Lifetime = 0, removes only the
> listed BIDs and does not affect the lifetime of other BIDs in the
> binding cache
All you mentioned above are correct.
> - a BU with lifetime=0 and H=1 indicates the MN is at home link, but
> the lifetime of other BIDs is not affected.
right.
> How is the home link
> state maintained though? This looks like hard state at the moment and
> I do not like it. Any ideas?
I might miss your question.
HA should verify the reachability of the mobile node at the home link.
If the reachability is missed, the HA should clean up the all the home
link states.
> 2) Changing BIDs. the draft indicates that BIDs can be changed for
> privacy reasons. While I still do not understand what these reasons
> are,
The point is not privacy or security reason, but MN can always pick a
new BID.
> I also do not see anywhere how BIDs can be changed. Is is done by
> sending a BU with a new BID mapped to a CoA that is already in the
> binding cache (but mapped to another BID)?
yes.
> I indicate that this could
> be added somewhere inline, but some additional care also needs to be
> taken e.g., can you reuse the BID you are replacing in the same BU?
This seems to be corner-case, but we will clarify it.
> 3) Section 5.6.2 (using only IF attached to visitied) is very
> confusing: I copy here the comment I also placed inline below:
> My understanding is that in this scenario the MN simply DOES NOT
> connect to the home link. If the MN connected to a link which is
> identified or detected to be its home link, it simply disconnects
> without sending a BU to the HA. So, as far as the HA is concerned the
> MN is NOT connected at its home link and operations continue as
> normal. The text in this section, however, says something different
> which does not match my understanding at all. Am I confused?
We need one more operation here.
What about the binding cache for the CoA previously assigned to the
interface(which is now disconnected)?
The interface is now disconnected, but the old binding cache for the
previous CoA assigned to that interface
might be still active at the home agent.
It should explicitly send de-registration BU for that binding cache,
since
MN has other active interfaces to send that BU.
We will revise the texts of section 5.6.2.
thanks
ryuji
> Thanks again for all the effort and see the rest of the detailed
> review below.
>
> George
>
>
>
> -------------------------------------------------------------------------------------------------------------------------------
> 1. Introduction
>
> ...
>
> But assigning a single home address to a node is more
> advantageous than assigning multiple home addresses because
> applications do not need to be aware of the multiplicity of home
> addresses.
>
> GT> I am not sure I agree with this statement. I think effective use
> of multiple home addresses by applications is a better and more robust
> technique but it does require applications to be written in a certain
> way. Multiple CoAs allow multihoming awareness to be outsourced to a
> different part of the IP stack but, especially when combined with per
> flow bindings, it results in routing that is not purely destination
> address based. This is not necessarily a good thing for Internet
> routing as a whole and only acceptable because it is only confined in
> HAs. I think we can have a bit better applicability statement that is
> more objective and looks at the big picture. i.e., at the
> architectural limitations of this approach.
>
> ...
> 3. Protocol Overview
>
> A new extension called the Binding identification number (BID) is
>
> GT> I think the name of the extension is "Binding Identifier
> Mobility Option"?
>
> 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 the if the BID in the Binding Update does not match the
> one
>
> GT> // and the if/ and if
>
> 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.
> This includes managing a Care-of Keygen token per care-of address
> and
> exchanging CoTi and CoT message with the correspondent node for each
> care-of address. It is RECOMMENDED that the mobile node uses the
> same BID that it used with the home agent for a particular care-of
> address.
>
> GT> I do not see why this is RECOMMENDED either :-). At most this is
> a MAY, since I can not think of any reason why this not totally an
> implementation decision.
>
> 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.
>
> 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 BID even if only has a single binding is active.
>
> GT> //BID even if only has a/BIDs even if it has only a/
>
>
> Binding cache lookup is done based on the home address and BID
> information. This is different from RFC 3775, where only the home
> address is used for binding cache lookup. The binding cache lookup
> may also involve policy or flow filters in cases where some policy
> or
> flow filters are used to direct certain packets or flows to a
> particular care-of address. The binding cache lookup using policy
> or
> flow filters is out of scope for this document. In case the binding
> cache lookup, using the combination of home address and BID, does
> not
> return a valid binding cache entry, the home agent MAY perform
> another lookup based on only the home address. This is
> implementation dependent and configurable on the home agent.
>
> The mobile node may return to the home link through one of its
> interfaces. There are three options possible for the mobile node
> when its returns home.
>
> 1. The mobile node uses only the interface with which it attaches
> to
> the home link. It de-registers all bindings related to all
> care-of addresses. The interfaces still attached to the visited
> link are no longer going to be receiving any encapsulated
> traffic
>
> GT> //link/link(s)
>
> from the home agent.
>
> 2. The mobile node uses only the interfaces still attached to the
> visited link.
>
> GT> //link/link(s)
>
> The interface with which the mobile node attaches
> to the home link is not used.
>
> 3. The mobile node may simultaneously use both the interface
> attached to the home link and the interfaces still attached to
> the visited links.
>
> GT> //links/link(s)
>
> ...
>
>
> Wakikawa (Ed.), et al. Expires August 11, 2008
> [Page 8]
>
> Internet-Draft MCoA February
> 2008
>
>
> Status
>
> When the Binding Identifier mobility option is included in a
> Binding Acknowledgement, this field overwrites the status field
> correspondent to each binding in the Binding Acknowledgement. If
> this field is zero, the receiver MUST use the registration status
> stored in the Binding Acknowledgement message. This Status field
> can be used to carry error information for a Care-of Test
> message.
> The status is 8-bit unsigned integer.
>
> The possible status codes
> are the same as the status codes of Binding Acknowledgement.
>
> GT> This is not true, right? New values are defined in section 4.5.
> Care-of address (C) flag
>
> When this flag is set, it indicates that a valid care-of address
> is present in the care-of address field in the BID mobility
> option. This flag MUST be set whenever the mobile node sends
> multiple care-of addresses in a single Binding Update, i.e., bulk
> registration. It MAY also used as a substitute for alternate
> care-of address option even for Binding Updates that are sent
> only
> for one care-of address. This flag is valid only for Binding
> Update sent to the home agent.
>
> Overwrite (O) flag
>
> When this flag is set, a mobile node requests the recipient to
> replace all the bindings to binding entries stored in a 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.
> This flag is valid only for a Binding Update sent to the home
> agent.
>
> DSMIPv6 (D) flag
>
> This flag indicates that the care-of address is an IPv4 address.
> When this flag is set, the care-of address field MUST contain an
> IPv4 address.
>
> Reserved
>
> 5 bits Reserved field. The reserved field MUST be zero.
>
>
>
>
>
>
>
> Wakikawa (Ed.), et al. Expires August 11, 2008
> [Page 9]
>
> Internet-Draft MCoA February
> 2008
>
>
> Care-of Address
>
> This field has the variable length depending on the specified
> flags. When the 'C' flag is set and the 'D' flag is not, an IPv6
> care-of address for the corresponding BID is stored in this
> field.
> If both 'C' and 'D' flags are set, an IPv4 Care-of Address is
> carried in this field. This field MUST NOT be used if a Binding
> Identifier mobility option is included in any other message other
> than a Binding Update.
>
> GT> For completeness you may want to add: "...or if the 'C' flag is
> not set."
> ...
> 5. Mobile Node Operation
>
> 5.1. Management of Care-of Addresses and Binding Identifier
>
> // Addresses and Binding Identifier/ Address(es) and Binding
> Identifier(s)
>
> There are two cases when a mobile node might acquire several care-of
> addresses. Note that a mixture of the two cases are also possible.
>
> GT> //are/is
>
> 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 and negative values
> MUST NOT be used as a BID. If a mobile node has only one care-of
>
> GT> //as a BID/as BIDs
>
> 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. Return Routability: Sending CoTI and Receiving CoT
>
> When a mobile node wants to register multiple care-of address with a
> correspondent node, it MUST have the valid Care-of Keygen token per
> care-of address.
>
> For the Home Keygen, the mobile node needs only for
> the home address.
>
> GT> Rephrase the above: "The mobile node needs only one Home Keygen
> for its home address."
>
>
> The mobile node MUST include a Binding Identifier mobility option in
> the Care-of Test Init message. It MUST NOT set any flags in the
> mobility option. The receiver (i.e. correspondent node) will
> calculate a care-of Keygen token as specified in [RFC-3775] and
> reply
> with a Care-of Test message, with the Binding Identifier mobility
> option as described in Section 6.2. When the mobile node receives
> the Care-of Test message, the message is verified as in [RFC-3775].
> If a Binding Identifier mobility option is not present in the CoT
> message in reply to the CoTI message that included a Binding
> Identifier mobility option, the mobile node must assume that the
> correspondent node does not support Multiple Care-of Address
>
>
>
> Wakikawa (Ed.), et al. Expires August 11, 2008 [Page
> 12]
>
> Internet-Draft MCoA February
> 2008
>
>
> registration. Thus, the mobile node MUST NOT use a Binding
> Identifier mobility option in any future Binding Updates to that
> correspondent node. The mobile node MAY skip re-sending regular
> CoTI
> message and keep the received care-of Keygen token for the regular
> Binding Update.
>
>
> GT> Should we also say anything about Enhanced RO based on RFC4866?
>
>
> 5.3. 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 2. 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,
> the care-of address cam be carried in the Care-of Address field of
>
> GT> //cam/can
>
> the Binding Identifier mobility option. If this is done, the
> alternate care-of address option MUST NOT be included in the Binding
> Update.
> 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=CoA, dst=HA)
> IPv6 Home Address Option
> ESP Header (for home registration)
> Mobility header
> -BU
> Mobility Options
> - Binding Identifier mobility option
> - Binding Authorization mobility option
> (for Route Optimization)
>
> Figure 2: Binding Update for Binding Registration
>
> 5.4. 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.
>
> 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
>
>
>
> Wakikawa (Ed.), et al. Expires August 11, 2008 [Page
> 13]
>
> Internet-Draft MCoA February
> 2008
>
>
> in Figure 3. The rest of the fields and options in the Binding
> Update such as Lifetime, Sequence Number, the flags in the Binding
> Update are common across all care-of addresses. The alternate
> care-of address option MUST NOT be used.
>
> In the bulk registration, the Sequence Number field of a Binding
> Update SHOULD be carefully configured. This is because all the
> bulk-
> registered bindings uses the same Sequence Number specified in the
>
> GT>//uses/use
>
> Binding Update. If each binding uses different sequence number, a
> mobile node MUST use the largest sequence number from the Binding
> Update list entries used for the bulk registration. If the mobile
> node cannot select a sequence number for all the bindings due to
> sequence number out of window, it MUST NOT use the bulk registration
> for the binding whose sequence number is out of window. A separate
> Binding Update should be sent for the binding.
>
> IPv6 header (src=CoA, dst=HA)
> IPv6 Home Address Option
> ESP Header
> Mobility header
> -BU
> Mobility Options
> - Binding Identifier mobility options
> (C flag is set, O flag is optional,
> BID and CoA are stored)
>
> Figure 3: Binding Update for Bulk Registration
>
> If the mobile node wants to replace existing registered bindings on
> the home agent with the bindings in the sent Binding Update, it sets
> the 'O' flag. Section 6.3 describes this registration procedure in
> detail.
>
> 5.5. 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 (e.g. from foreign link), the
>
> GT> Remove "(e.g. from foreign link)" it is not clear what it means.
>
> 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 of each mobility option SHOULD be omitted, because
> the receiver will remove the binding matching the specified BID.
>
> GT> // SHOULD be omitted/ SHOULD be omitted by the sender and MUST be
> ignored by the receiver/
>
> Wakikawa (Ed.), et al. Expires August 11, 2008 [Page
> 14]
>
> Internet-Draft MCoA February
> 2008
>
>
> 5.6. Returning Home
>
> 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. The mobile node may use only the
> interface with which it is attached to the home link, only the
> interfaces still attached to the visited link or use both interfaces
> attached to the home link and visited link simultaneously. The
> following describes each option in more detail.
>
> 5.6.1. Using only Interface attached to the Home Link
>
> The mobile node returns home and de-registers all the bindings as
> shown in Figure 9.
>
> GT> add: "...and as defined in [RFC3775].
>
> De-registering all the bindings is the same as
> binding de-registration from foreign link described in Section 5.5.
> 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. While the mobile node de-registers all the bindings from the
> home agent, it may continue registering bindings for interface
> attached to visited link to the correspondent node as shown in
> Figure 9.
>
> 5.6.2. Using only Interface attached to the Visited Link
>
> The mobile node returns home and shuts down the interface attached
> to
> the home link as shown in Figure 10. 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 MUST send a de-registration Binding Update
> with the lifetime set to zero and include the corresponding BID
> information. This scenario is not the most efficient because all
> the
> traffic to and from the mobile node is going through the bi-
> directional tunnel, whereas the mobile node is now accessible at one
> hop on the home link from its home agent.
>
> GT> This scenario is still confusing to me. My understanding is that
> in this scenario the MN simply DOES NOT connect to the home link. If
> the MN connected to a link that is identified or detected to be its
> home link, it simply disconnects without sending a BU to the HA. So,
> as far as the HA is concerned the MN is NOT connected at its home link
> and operations continue as normal. The paragraph above, however, says
> something different which does not match my understanding at all. Am I
> confused?
>
>
>
> 5.6.3. Simultaneous Home and Visited Link Operation
>
> In this case, the mobile node returns home and continues using all
> the interfaces attached to both foreign and home links as shown in
> Figure 11. The mobile node indicates this by setting the 'H' flag
> in
> the BID mobility option.
>
> GT> Add: " ...as defined below."
>
> There are additional requirements on the
> Returning Home procedures for possible ND conflicts at the home link
> described below.
>
> In [RFC-3775], the home agent intercepts packets meant for the
> mobile
> node using proxy Neighbor Discovery while the mobile node is away
>
>
>
> Wakikawa (Ed.), et al. Expires August 11, 2008 [Page
> 15]
>
> Internet-Draft MCoA February
> 2008
>
>
> 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
> 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.
>
> 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 packets and flows. How to make this decision is out of
> scope
> in this document. The critical part would be to create a neighbor
> cache entry for the mobile node so that the home agent can deliver
> the packets on-link. The home agent would need to know the Layer-2
> address of the interface with which the mobile node is attached to
> the home link. In order to create the neighbor cache entry for the
> mobile node, following operations are required.
>
> The mobile node sends a de-registration Binding Update to the home
> agent from the interface attached to the home link. In the Binding
> Update, the BID mobility option must include the BID the mobile node
> had previously associated with the interface attached to the home
> link.
>
> GT> When was this association done? What does "previously" refer to?
>
> The 'H' flag MUST be set in the BID mobility option. The 'C'
> flag MUST NOT be set and the care-of address field MUST NOT be
> included. 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. If the 'H' flag is unset, the home agent
> deletes either all the bindings or the binding corresponding to the
> BID included in the Binding Identifier mobility option.
>
> When the home agent sends the Binding Acknowledgement, it MUST set
> the status value to either 0 [Binding Update Accepted] or to [MCOA
> RETURNHOME WO/NDP (TBD)] in the BID mobility option depending on
> home
> agent configuration at the home link. The new values are:
>
>
>
>
>
> Wakikawa (Ed.), et al. Expires August 11, 2008 [Page
> 16]
>
> Internet-Draft MCoA February
> 2008
>
>
> o Binding Update Accepted (0): NDP is permitted for the home
> address
> at the home link. This is regular returning home operation of
> [RFC-3775]
>
> o MCOA RETURNHOME WO/NDP (TBD): NDP is prohibited for the home
> address at the home link
>
> When the home agent is the only router at the home link, it can
> intercept all the packets by normal IP routing without using
> proxying
> for the home address. It stops proxy ND for the requested home
> address and responds with the [Binding Update Accepted] status value
> to the mobile node. The neighbor cache entry for the mobile node is
> created by the regular exchange of Neighbor Solicitation and
> Neighbor
> Advertisement. If the home agent is not the only router on the home
> link, it MUST continue defending the home address by proxy neighbor
> discovery in order to intercept the mobile node's traffic. The home
> agent, then, returns [MCOA RETURNHOME WO/NDP] value in the Status
> field of the BID mobility option. The home agent also learns the
> mobile node's layer-2 address (i.e., MAC address) during this
> binding
> de-registration. It stores the learnt layer-2 address in a neighbor
> cache entry for the mobile node so that it can construct the layer-2
> header for the packets meant for the mobile node and forwards them
> directly to the mobile node's interface attached to the home link.
>
> According to [RFC-3775], the mobile node MUST NOT assign the home
> address to the interface attached to the home link and MUST NOT
> attempt NDP operations for the home address before the completion of
> binding de-registration. It MUST NOT send and reply to Neighbor
> Solicitation for the home address. The home address MUST be
> tentative address at this moment until it receives Binding
> Acknowledgement with success status value.
>
> When the mobile node receives the Binding Acknowledgement and BID
> mobility option, it assigns home address to the interface attached
> to
> the home link according to the status field of the BID. If the
> value
> is [Binding Update Accepted], the mobile node can start defending
> the
> home address using regular Neighbor Discovery.
>
> If the mobile node receives the [MCOA RETURNHOME WO/NDP], it MUST
> NOT
> defend its home address on the home link. When the mobile node
> sends
> packets from the interface attached to the home link, it MUST learn
> the layer 2 address (i.e., MAC address) of the next hop (i.e.
> default
> router, it can be home agent) during the binding de- registration
> and
> construct the packet including layer 2 header with the learnt
> layer-2
> address of the default router or the home agent.
>
>
>
> GT> Something needs to be said about the lifetime of the BU with 'H'
> flag set. If the MN has to send a de-reg to the HA with Lifetime=0 and
> 'H' set, for how ling is this state valid? What happens to the
> lifetime of the other bindings??
>
>
> Wakikawa (Ed.), et al. Expires August 11, 2008 [Page
> 17]
>
> Internet-Draft MCoA February
> 2008
>
>
> 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.3.
>
> 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. 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.
> The mobile node MUST then stop multiple care-of address registration
> with that node.
>
> 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.
>
> o If [MCOA MALFORMED] is specified, it indicates that the binding
> identifier mobility option is formatted wrongly. For example, if
> the 'C' flag is set, all mobility options MUST have 'C' flag. It
> is same for 'O' flag.
>
> GT> What do you mean here with the 'C' and 'O' flags? It is not clear.
> Also it is not nice to find MUSTs with respect on how to use the flags
> when talking about the error codes. These MUSTs, if needed, should be
> moved elsewhere.
>
>
> 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.
>
>
>
>
> Wakikawa (Ed.), et al. Expires August 11, 2008 [Page
> 18]
>
> Internet-Draft MCoA February
> 2008
>
>
> 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.4.
>
> 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 only for the respective binding. The mobile node
> MUST
> include a Binding Identifier mobility option in the Binding Update.
>
> If no Binding Identifier mobility option is present in a Binding
> Refresh Request, the mobile node sends a Binding Update according to
> its Binding Update List. On the other hand, if the mobile node does
> not have any Binding Update List entry for the requesting node, the
> mobile node needs to register either a single binding or multiple
> bindings depending on its binding management policy.
>
> 5.9. Sending Packets to Home Agent
>
> When a multihomed mobile node sends packets to its home agent, there
> are conceptually two ways to construct packets.
>
> 1. Using Home Address Option. (required additional 24 bytes)
>
> 2. Using IPv6-IPv6 tunnel. (required additional 40 bytes)
>
> GT> Remove the period or remove the ( ) and capitalize the R.
>
> Beside the difference in the size of packets, there is no difference
> between the two. The routing path does not get affected. With
> extensions specified in this document, the mobile node is capable of
> using multiple care-of addresses for outgoing packets. This is a
> problem on the home agent side because it must verify the Care-of
> address for all the packets received from the mobile node (i.e.
> ingress filtering). When the mobile node uses the Home Address
> option, the home agent MAY check the care-of address in the packet
> with the registered binding entries. This causes additional
> overhead
> to the home agent. Therefore, the mobile node SHOULD use the bi-
> directional tunnel even if it registers a binding(s) to the home
> agent.
>
> GT> This confuses me a bit. Is there anything different from RFC3775?
> Why is this section needed?
>
>
> 5.10. Bootstrapping
>
> When a mobile node bootstraps and registers multiple bindings for
> the
> first time, it SHOULD set the 'O' flag in the Binding Identifier
> mobility option.
>
> GT> Should this be a MUST? Otherwise what is the behavior of the HA?
>
> If old bindings still exists at the home agent, the
> mobile node has no knowledge of which bindings still exist at the
>
>
>
> Wakikawa (Ed.), et al. Expires August 11, 2008 [Page
> 19]
>
> Internet-Draft MCoA February
> 2008
>
>
> 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 retry sending a Binding
> Update with the last accepted sequence number indicated in the
> Binding Acknowledgement.
>
> 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.
>
>
> GT> Again the 'O' flag MUST be set the first time MCoA is used with a
> CN I think.
>
>
>
>
>
>
>
>
> Wakikawa (Ed.), et al. Expires August 11, 2008 [Page
> 20]
>
> Internet-Draft MCoA February
> 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. How to select the
> most suitable binding from the binding cache database is out of
> scope
> in this document.
>
> Whenever a correspondent node searches a binding cache for a home
> address, it SHOULD uses both the home address and the BID as the
> search key if it knows the corresponding BID.
>
> GT> This is a bid strange. Why would the HA or CN use a BID as a key?
> The HoA is used as a key because the HA/CN want to send a packet with
> the HoA as destination address, which causes Mobile IP to use the HoA
> as a key to find an appropriate CoA. I do not think that the BIDs are
> needed for this. With MCoA, the only difference is that a lookup of
> the HoA will return multiple CoAs; and which one is used is out of
> scope for this document.
>
> GT> So, the BIDs are only used as key when the receiver processes a BU
> message including a BID Mobility option. Is this what this is about?
>
> In the example below,
> if a correspondent node searches the binding with the home address
> and BID2, it gets binding2 for this mobile node.
>
> binding1 [a:b:c:d::EUI, care-of address1, BID1]
> binding2 [a:b:c:d::EUI, care-of address2, BID2]
> binding3 [a:b:c:d::EUI, care-of address3, BID3]
>
> Figure 4: Searching the Binding Cache
>
> A correspondent node earns the BID when it receives a Binding
>
> GT> //earns/learns
>
> Identifier mobility option. At the time, the correspondent node
> MUST
>
> GT>//At the time/At that time
>
> look up its binding cache database with the home address and the BID
> retrieved from the Binding Update. If the correspondent 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
> correspondent node does not desire to use multiple bindings for a
> mobile node, it can simply ignore the BID.
>
> GT> This whole section needs to be cleaned based on the comment above.
>
>
> 6.2. Receiving CoTI and Sending CoT
>
> When a correspondent node receives a CoTI message which contains a
> Binding Identifier mobility option, it processes it as follows.
>
> First, the CoTI message is verified as specified in [RFC-3775]. The
> Binding Identifier mobility option is processed as follows:
>
> o If a correspondent node does not understand a Binding Identifier
> mobility option, it just ignores and skips processing the option.
> The calculation of a care-of Keygen token will thus be done
> without a BID value. The correspondent node returns a CoT
> message
> without a Binding Identifier mobility option. The mobile node
> knows whether the correspondent supports processing the Binding
> Identifier mobility option, by checking if the option is present
> in the CoT message.
>
>
>
>
> Wakikawa (Ed.), et al. Expires August 11, 2008 [Page
> 21]
>
> Internet-Draft MCoA February
> 2008
>
>
> o If either the 'C' or the 'O' flag is set in the Binding
> Identifier
> mobility option, the correspondent Node SHOULD NOT calculate a
> care-of Keygen token, but MUST include a Binding Identifier
> mobility option with status value set to [MCOA MALFORMED] in the
> Care-of Test message.
>
> o Otherwise, the correspondent node MUST include a Binding
> Identifier mobility option with status value set to zero
> (success)
> in the Care-of Test message.
>
> o The Care-of address field of each Binding Identifier mobility
> option, can be omitted, because the mobile node can identify the
> corresponding Binding Update list entry using the BID.
>
> 6.3. 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 validated according to section 9.5.1 of [RFC-3775]
> and the following steps.
>
> o If the home registration flag is set in the Binding Update, the
> home agent MUST carefully operate Duplicate Address Detection
> (DAD) for the received home address. If the home agent has
> already had a binding(s) for the mobile node, it MUST avoid
> running DAD for the home address on the home link when it
> receives
> the Binding Update.
>
>
> GT> Why is this here? This is normal RFC3775 operation and should not
> be affected by MCoA, no?
>
> The receiver MUST process the Binding Identifier mobility option(s)
> in the following steps. 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 set to zero.
>
> GT> The last sentence does not make sense. Please rephrase.
>
> For the home agent, 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 to the Status field of
> the Binding Acknowledgement so that the receiver can examine the
>
>
>
> Wakikawa (Ed.), et al. Expires August 11, 2008 [Page
> 22]
>
> Internet-Draft MCoA February
> 2008
>
>
> Status field of each Binding Identifier mobility option for further
> operations.
>
> o The length value is examined. The length value MUST be either 4,
> 8, or 20 depending on the 'C' and 'D' flags. If the length is
> incorrect, the receiver MUST reject the Binding Update and
> returns
> the status value set to [MCOA MALFORMED].
>
> o When the 'C' flag is set, the care-of address MUST be present in
> the Binding Identifier mobility option. Otherwise, the receiver
>
> GT> It is not clear what "Otherwise" refers to. Replace with: "If the
> care-of address is not present..."
>
> MUST reject the Binding Identifier mobility option and returns
> the
> status value set to [MCOA MALFORMED]. The operation of 'D' flag
> is described in Section 8
>
> 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].
>
> GT>This does not make sense. If the BID does not exist then the
> binding never existed or has already been deleted so I would send a BA
> and BID Mobility option with status 0. Status 133 means that the HoA
> is not valid...which is a different issue already covered in RFC3775.
> Also please move this bullet one place down to be next to Lifetime !=
> zero case.
>
>
> o If the 'O' flag is set in the de-registering Binding Update, the
> receiver can ignore this flag for de-registration.
>
> GT> This sentence is strange please rephrase.
>
> 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 also
> stops performing proxy ND for the mobile node's home address.
>
> 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 'C' flag is set in the Binding Identifier mobility
> option, the care-of address is copied from the care-of address
> field in the Binding Identifier mobility option.
>
> * If the 'C' flag is not set in the Binding Identifier mobility
> option, the care-of address is copied from the source address
> field of the IPv6 header.
>
> * If the 'C' flag is not set and an alternate care-of address is
> present, the care-of address is copied from the Alternate
>
>
>
> Wakikawa (Ed.), et al. Expires August 11, 2008 [Page
> 23]
>
> Internet-Draft MCoA February
> 2008
>
>
> Care-of address mobility option.
>
> o Once the care-of address(es) has been retrieved from the Binding
>
> GT>//has/have
>
> Update, the receiving nodes creates new binding(s).
>
> * If only 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].
>
> GT> This makes no sense. What do you mean?
>
>
> * If the receiver already has a binding with the same BID, it
>
> GT>// same BID, it/ same BID and different care-of address, it
>
> MUST update the binding and responds with a Binding
>
> GT>//responds/respond
>
> 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].
>
> GT> What happens if one receives a new BID mapped to a CoA already in
> the binding cache (but mapped to different BID?) Is this allowed? Is
> this how one can change the BIDs it is using?
>
>
> 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.
>
> GT> Something needs to be said about the lifetime of the bindings. I
> assume that the Lifetime field of the BU updates the lifetime of all
> the bindings, whether a regular or bulk MCoA registration is
> performed.
>
>
> 6.4. 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.
>
> GT> This needs a bit more...which BID mobility option is included?
> Just one? All of them? Again we need to be clear what the lifetime
> does and how it relates to each of the CoAs.
>
> 6.5. 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 silently discarded.
>
> GT> Why don't we just point to RFC3775 and say that the exact same
> processing is used here?
>
> 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 August 11, 2008 [Page
> 24]
>
> Internet-Draft MCoA February
> 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. Figure 5 shows an example format of a
> Binding Update sent by a mobile router.
>
> IPv6 header (src=CoA, dst=HA)
> IPv6 Home Address Option
> ESP Header
> Mobility header
> -BU
> Mobility Options
> - Binding Identifier
> - Mobile Network Prefix
>
> Figure 5: NEMO Binding Update
>
>
>
>
>
> GT> Why is this example here? I would remove it together with the
> last sentence.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Wakikawa (Ed.), et al. Expires August 11, 2008 [Page
> 25]
>
> Internet-Draft MCoA February
> 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 6. 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
> -BU
> Mobility Options
> - Binding Identifier (IPv4 CoA)
>
> Figure 6: Initial Binding Update for IPv4 Care-of Address
>
> Whenever a NAT is detected, mobile node MUST NOT use bulk
> registration for the IPv4 care-of address.
>
> GT> This was repeated above. Delete.
>
> If a NAT is not detected,
> the mobile node can update the IPv4 care-of address by using BULK
>
> GT>//BULK/bulk
>
> registration. The mobile node can register the IPv4 care-of address
> along with other care-of addresses. Figure 7 shows the Binding
>
> GT>// other care-of addresses/ other IPv4 and IPv6 care-of addresses
>
> Update format when the mobile node sends a Binding Update from one
> of
> its IPv6 care-of addresses. If the mobile node sends a BU from IPv4
> care-of address, it MUST follow the format described in Figure 6.
> Note that the IPv4 Care-of Address must be registered by non bulk
>
>
>
> Wakikawa (Ed.), et al. Expires August 11, 2008 [Page
> 26]
>
> Internet-Draft MCoA February
> 2008
>
>
> Binding registration, whenever it is changed.
>
>
> NAT detection MUST be
> carried out for every new IPv4 addresses.
>
> GT> Again, this was repeated above. Delete.
>
> IPv6 header (src=V6CoA, dst=HAADDR)
> IPv6 Home Address Option
> ESP Header
> Mobility header
> -BU
> Mobility Options
> - Binding Identifier (IPv6/v4 CoA)
> - Binding Identifier (IPv6/v4 CoA)
> - ...
>
> Figure 7: 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.
> The
> home agent MUST send the Binding Acknowledgement and all the
> received
> BID mobility options to the mobile node.
>
> GT> This has already been explained in other sections. It is not good
> to repeat MUST statements about the same thing. Delete the whole
> paragraph….or just point to HA processing section.
>
>
>
> 8.2. IPv4 HoA 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
> different set of care-of addresses to each home address.
>
> The home agent includes the IPv4 address acknowledgement option in
> the Binding Acknowledgement only if the mobile node had requested
> for
> the IPv4 home address.
>
> GT> Rephrase: "According to [DSMIPv6], the home agent includes the
> IPv4 address acknowledgement option in the Binding Acknowledgement
> only if the mobile node requests 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
> regarding
> IPv4 home address management.
>
> GT>// the error code regarding IPv4 home address management/ the error
> code corresponding to the IPv4 home address.
>
> The error values related to the IPv4
> care-of address registration MUST be stored in the BID mobility
> option.
>
>
>
>
>
>
>
>
>
>
>
>
> Wakikawa (Ed.), et al. Expires August 11, 2008 [Page
> 27]
>
> Internet-Draft MCoA February
> 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 like Binding Updates,
> Binding Acknowledgements and return routability messages. IPsec may
> also be used protect all reverse tunneled data traffic. The Mobile
>
> GT> //used protect all reverse tunneled data / used to protect all
> tunneled data/
>
> 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 the MIP6-IKEv2
> specification with respect to the use of IKEv2 and IPsec.
>
> GT> Why is MIP6-IKEv2 not properly referenced?
>
> 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.
>
> GT> Add "according to MIP6-IKEv2 ..." until you have something new.
>
> 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 August 11, 2008 [Page
> 28]
>
> Internet-Draft MCoA February
> 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.
>
>
>
> On Feb 8, 2008 4:35 PM, Vijay Devarapalli
> <vijay.devarapalli at azairenet.com> wrote:
>> Hello,
>>
>> There is a pre-06 version of this draft available at
>> http://dvijay.com/ietf/internet-drafts/mext/mcoa.txt
>>
>> The draft has been cleaned up a bit. In case, you haven't reviewed
>> the document yet, please review the pre-06 version. In case you
>> have already reviewed version 05, please send your comments based
>> on version 05.
>>
>> The diff between 05 and pre-06 can be found at
>> http://dvijay.com/ietf/internet-drafts/mext/diff-05-06.html
>>
>> Vijay
>>
>>
>> marcelo bagnulo braun wrote:
>>> Hi,
>>>
>>> With this email we issue the WGLC for draft-ietf-monami6-
>>> multiplecoa-05.txt
>>> The WGLC will be open till the 11 of february.
>>> We kindly ask the WG to review the document and provide comments.
>>>
>>> Please note that a valid comment at this stage is positive feedback
>>> about the document being ready to be shipped.
>>> So, please if you think the doc is ready, do express this to the ml
>>> (or to the chairs)
>>>
>>> For you convenience, additional information about the document:
>>>
>>> Title : Multiple Care-of Addresses Registration
>>> Author(s) : R. Wakikawa, et al.
>>> Filename : draft-ietf-monami6-multiplecoa-05.txt
>>> Pages : 44
>>> Date : 2008-01-27
>>>
>>> http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-05.txt
>>>
>>> Thanks, Julien and marcelo
>>> _______________________________________________
>>> MEXT mailing list
>>> MEXT at ietf.org
>>> http://www.ietf.org/mailman/listinfo/mext
>>
>> _______________________________________________
>> MEXT mailing list
>> MEXT at ietf.org
>> http://www.ietf.org/mailman/listinfo/mext
>>
>
_______________________________________________
MEXT mailing list
MEXT at ietf.org
http://www.ietf.org/mailman/listinfo/mext
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
