RE: [Mipshop] Re: AD review of draft-ietf-mipshop-fmipv6-rfc4068bis

["Hesham Soliman" <Hesham at elevatemobile.com>]

Has this draft already passed WG LC ?  Did I miss the announcement? 

Hesham

 > -----Original Message-----
 > From: Rajeev Koodli [mailto:rajeev.koodli at nokia.com] 
 > Sent: Thursday, October 25, 2007 8:23 AM
 > To: ext Jari Arkko; 
 > draft-ietf-mipshop-fmipv6-rfc4068bis at tools.ietf.org; Mipshop
 > Subject: [Mipshop] Re: AD review of 
 > draft-ietf-mipshop-fmipv6-rfc4068bis
 > 
 > 
 > Hi Jari,
 > 
 > Thanks for your review.
 > 
 > On 10/23/07 3:22 PM, "ext Jari Arkko" <jari.arkko at piuha.net> wrote:
 > 
 > > 
 > > - Interaction with duplicate address detection, and how 
 > duplicates are
 > > avoided needs further work.
 > > 
 > 
 > Section 4, Page 14:
 > 
 > " As soon as the MN establishes link connectivity with the NAR, it
 > 
 >       1. sends a UNA message (see Section 6.4).  If the MN has not
 >       received an FBack by the time UNA is being sent, it 
 > SHOULD send an
 >       FBU message following the UNA message.
 > 
 >       2. joins the all-nodes multicast group and the solicited-node
 >       multicast group corresponding to the NCoA
 > 
 >       3. starts a DAD probe for NCoA.  See [rfc2462]."
 > 
 > Section 4, Page 15:
 > 
 >    "Once the MN has confirmed its NCoA (either through DAD or when
 >    provided for by the NAR), it SHOULD send a Neighbor Advertisement
 >    message with the 'O' bit set, to the all-nodes multicast address.
 >    This message allows MN's neighbors to update their neighbor cache
 >    entries."
 >  
 > 
 > Section 5.5 is for DAD handling.
 > 
 > The protocol does not specify how to avoid duplicates. When 
 > duplicate-free
 > addresses are available at NAR, it specifies the container 
 > messages (HAck,
 > FBack, NAACK option) to provide them.
 > 
 > 
 > 
 > > - Clearer specification is needed on what the hosts have 
 > to do on the
 > > new link wrt. existing ND procedures.
 > > 
 > 
 > A host does what it normally does when it attaches to a new 
 > link wrt to ND
 > operations. In addition, it sends messages defined by the 
 > protocol. See
 > above (section 4, page 14).
 > 
 > In general, the protocol does not require changes to other 
 > protocols, their
 > timing etc, including MIP6.
 > 
 > > - Security considerations need to be expanded and clarified.
 > 
 > Could you please be more specific? I will look below..
 > 
 > > 
 > > - Need to be capable of indicating netlmm-like 
 > functionality where the
 > > same prefix follows the mobile node on a new link.
 > > 
 > 
 > Hmm.. Does that belong here? There is an ID on the topic:
 > 
 > http://www.ietf.org/internet-drafts/draft-yokota-mipshop-pfmi
 > pv6-00.txt
 > 
 > > - What happens when DHCP, not stateless address 
 > autoconfiguration is
 > > used in the network? Or is that prohibited?
 > > 
 > 
 > Two cases:
 > 
 > - NAR provides an address from a pool (in which case, any 
 > DHCP messages from
 > the MN on the new link are also answered by the NAR)
 > - protocol simply supports forwarding for PCoA, which allows 
 > the MN to go
 > about doing DHCP operations as usual
 > 
 > 
 > > - This document introduces a number of new Neighbor 
 > Discovery messages.
 > > Should this document also specify how SEND (if used) is 
 > applied on them?
 > 
 > Actually, the document does not introduce any new ND 
 > messages. They are
 > ICMPv6 messages. The security consideration section refers 
 > to using SEND on
 > RtSolPr and PrRtAdv messages.
 > 
 > > 
 > > - What changes, if any, are needed to the conceptual data 
 > structures
 > > held by ND?
 > 
 > No changes to the data structures held by ND. No new state 
 > being defined.
 > 
 > > 
 > > - A fair number of protocol details need correction and/or 
 > clarification.
 > 
 > I guess you will point them out.. :-)
 > 
 > > 
 > > Given the tight integration to ND functions, I have also asked for
 > > review from the IETF ND experts in the IP Directorate.
 > > 
 > 
 > I would like to understand this better. Other than 
 > specifying that an RA MAY
 > be sent as a response to the Unsolicited NA, I am wondering 
 > where there is
 > tight integration. I also agree it specifies using proxy NA 
 > functionality
 > when the NAR defends an address.
 > 
 > As a reference, folks at fmipv6.org have implemented it at 
 > as a userland
 > program in Linux. 
 > 
 > 
 > > In more detail, here are the substantial issues:
 > > 
 > >>    When it is not feasible, FBU is sent from the new 
 > link.  Care must be
 > >>    taken to ensure that NCoA used in FBU does not conflict with an
 > >>    address already in use by some other node on link.
 > >>   
 > > 
 > > How? Be more specific.
 > 
 > The last sentence does not belong anymore (some old, 
 > remaining text..)
 > 
 > 
 > > 
 > >> For all these operations, the protocol provides
 > >>    "Handover Initiate (HI)" and "Handover Acknowledge 
 > (HAck)" messages
 > >>    (see Section 6.2
 > >> 
 > <http://tools.ietf.org/html/draft-ietf-mipshop-fmipv6-rfc4068
 > bis-03#section-6
 > >> .2>).  Both of these messages SHOULD be used.  The
 > >>    access routers MUST have necessary security 
 > association established
 > >>    by means outside the scope of this document.
 > > 
 > > In the security considerations section you say that IPsec 
 > is used for
 > > this purpose. I would actually not talk about security 
 > associations as
 > > such. But you need to specify mandatory-to-implement security
 > > functionality and the expected configuration:
 > > 
 > > - use of IPsec
 > > - use of key management protocol for IPsec
 > > - security policy and credential/shared secret configuration
 > > 
 > 
 > Isn't this deployment-specific? The protocol is not specifying key
 > management, SA configuration.
 > 
 > 
 > > 
 > > But if the MN leaves before FBack has arrived, how does the MN
 > > differentiate between the NAR defending his address vs. 
 > some other node
 > > already using it?
 > > 
 > 
 > It does not. Hence it sends the UNA message first which has 
 > its LLA and the
 > NCoA. 
 > 
 > 
 > 
 > >>       1. determines whether NCoA supplied in the HI 
 > message is a valid
 > >>       address for use, and if it is, starts proxying [rfc2461
 > >> <http://tools.ietf.org/html/rfc2461>] the
 > >>       address for PROXY_ND_LIFETIME during which the MN 
 > is expected to
 > >>       connect to NAR.  In case there is already an NCoA 
 > present, NAR may
 > >>       verify if the LLA is the same as its own or that of 
 > the MN itself.
 > >>       If so, NAR may allow the use of NCoA.
 > >>   
 > > 
 > > 1) How does the NAR know what addresses are present on the link?
 > 
 > The above assumes that the NAR can only know those addresses 
 > which are
 > present in its NCE. When creating an NCE, NAR can check if 
 > the new "node"
 > being created is already in the linked list (or a similar 
 > data structure).
 > 
 > > 
 > > 2) For the case that LLA equals the MN's LLA: how do we 
 > know that the
 > > LLA in the HI message is not spoofed?
 > 
 > We assume that HI and Hack are between trustworthy routers 
 > which have SA
 > between them. 
 > 
 > > 
 > > 
 > >>       2.  If the new access point is connected to the 
 > PAR's current
 > >>       interface (to which MN is attached), PAR responds 
 > with a Code
 > >>       value indicating that the new access point is 
 > connected to the
 > >>       current interface, but not send any prefix 
 > information.  This
 > >>       scenario could arise, for example, when several 
 > wireless access
 > >>       points are bridged into a wired network.  No 
 > further protocol
 > >>       action is necessary.
 > >>   
 > > 
 > > This is good. But I wonder about two things:
 > > 
 > > 1) Is there something that you need to specify about interactions
 > > regarding current ND rules on new links? Are there 2461bis 
 > rules that
 > > change as a result? this RFC updates RFC 2461bis? The same question
 > > would also apply to DNA, but the new DNA design isn't ready yet.
 > 
 > AFAICT, no. The PAR is only informing the MN that it is 
 > going to an AN which
 > is on the same subnet as the MN is currently on (hence, no 
 > further protocol
 > action is necessary).
 > 
 > > 
 > > 2) Is there something that you should do in order to 
 > ensure that non-L3
 > > entities on the path learn the things they need. For instance, MLD
 > > snooping switches (RFC 4541)?
 > > 
 > 
 > I don't think that non-L3 nodes need to behave differently. 
 > What we need is
 > the knowledge that a target L2 device (i.e., AP) is on a 
 > different subnet
 > (or not) for IP fast handover purposes.
 > 
 > 
 > >>    Once the MN has confirmed its NCoA (either through DAD or when
 > >>    provided for by the NAR), it SHOULD send a Neighbor 
 > Advertisement
 > >>    message with the 'O' bit set, to the all-nodes 
 > multicast address.
 > >>    This message allows MN's neighbors to update their 
 > neighbor cache
 > >>    entries.
 > >>   
 > > 
 > > Is reference to 4861 Section 7.2.6 needed? Which of the 
 > requirements
 > > from that section apply, which do not? For instance, are there
 > > requirements on the maximum number of such messages per 
 > unit of time?
 > > 
 > 
 > I guess it depends on the host implementation. For those MNs that do
 > implement 4861, they should be following the "updates" from 
 > 2461 anyway, no?
 > 
 > 
 > 
 > >> However, the MN itself does not have to
 > >>    wait on PAR's link for this exchange to take place.  
 > It can handover
 > >>    any time after sending the FBU message; sometimes it 
 > may be forced to
 > >>    handover without sending the FBU.  In any case, it can 
 > still confirm
 > >>    using NCoA from NAR's link by sending the UNA message.
 > > 
 > > But if it does this too early, won't the NAR detect a 
 > collision for the
 > > new care of address?
 > 
 > I didn't quite follow this..
 > 
 > 
 > >>    When per-mobile prefix assignment is used, the 
 > ``AR-Info'' advertised
 > >>    in PrRtAdv still includes the (aggregate) prefix valid on the
 > >>    interface to which the target AP is attached, unless the access
 > >>    routers communicate with each other (using HI and HAck 
 > messages) to
 > >>    manage per-mobile prefix.  The MN still formulates an 
 > NCoA using the
 > >>    aggregate prefix.  However, an alternate NCoA based on 
 > the per-mobile
 > >>    prefix is returned by NAR in the HAck message.  This 
 > alternate NCoA
 > >>    is provided to the MN in either the FBack message or 
 > in the NAACK
 > >>    option.
 > > Note that you earlier in Section 4 you described the three possible
 > > outcomes that the PrRtAdv message can give you (unknown, 
 > same interface,
 > > known other router).
 > 
 > Yes. It's still the case: the prefix in the "known other router" is
 > aggregate unless the routers exchange per-MN prefix in 
 > HI/HAck, and PAR
 > provides that per-MN prefix in PrRtAdv.
 > 
 > > 
 > > You should also take into account things like NETLMM, where it is
 > > possible that there's a different device but the network keeps the
 > > mobile's prefix intact.
 > > 
 > 
 > Basically, the protocol binds PCoA to NCoA.
 > 
 > In NETLMM, "PCoA" is HoA, and "NCoA" is NAR's IP address. 
 > This is how it
 > works in fmipv4, and it would work the same way here.
 > 
 > I could specify it here. There is also the ID I mentioned above.
 > 
 > 
 > 
 > >>    This document specifies messages which can be used to provide
 > >>    duplicate-free addresses but the document does not 
 > specify how to
 > >>    create or manage such duplicate-free addresses.  In 
 > some cases the
 > >>    NAR may already have the knowledge required to assess 
 > whether the
 > >>    MN's address is a duplicate or not before the MN moves 
 > to the new
 > >>    subnet.  For example, the NAR can have a list of all 
 > nodes on its
 > >>    point-to-point radio network, and by searching this 
 > list, it can
 > >>    confirm whether the MN's address is a duplicate or not.
 > > 
 > > I do not understand how this is possible. On a shared link 
 > you would not
 > > know if there are other nodes that have decided to adopt a given
 > > address. 
 > 
 > On such links, the NAR would have to have a pool of 
 > duplicate-free addresses
 > that it can provide. Presumably, you would do stateful 
 > configuration on such
 > links.
 > 
 > 
 > > On a point-to-point link you would presumably give different
 > > prefixes for the different links, so its not clear why the 
 > addresses of
 > > the other nodes even matter.
 > > 
 > 
 > Right. This needs to be clarified.
 > 
 > > More specification and/or more accurate description of 
 > limitations needed.
 > > 
 > >>          New Router's IP Address: The IP address of NAR.  
 > This option
 > >>          MUST be included when Code is 0 or 1.
 > >> 
 > >>          New Router Prefix Information Option: Specifies 
 > the prefix of
 > >>          the Access Router the message is proxied for and 
 > is used for
 > >>          address auto-configuration.  This option MUST be 
 > included when
 > >>          Code is 0 or 1.  However, when this prefix is 
 > the same as what
 > >>          is used in the New Router's IP Address option 
 > (above), the
 > >>          Prefix Information option need not be present.
 > >>   
 > > If so, what would the prefix length be?
 > 
 > The Prefix Length field in Section 6.5.1 indicates this.
 > 
 > > 
 > >>       2.  The MN does not receive FBack on the previous link.  One
 > >>       reason for this is that the MN has not sent the 
 > FBU.  The other is
 > >>       that the MN has left the link after sending the 
 > FBU, which may be
 > >>       lost, but before receiving an FBack.  Without 
 > receiving an FBack
 > >>       in the latter case, the MN cannot ascertain whether PAR has
 > >>       successfully processed the FBU.  Hence, the MN (re)sends FBU
 > >>       immediately after sending the UNA message.  If NAR 
 > detects that
 > > ...
 > > 
 > >>    The MN sends FBU message any time after receiving a 
 > PrRtAdv message.
 > >>    If the MN moves prior to receiving a PrRtAdv message, 
 > it SHOULD send
 > >>    a FBU to the PAR after configuring NCoA on the NAR according to
 > >>    Neighbor Discovery and IPv6 Address Configuration protocols.
 > >>   
 > > 
 > > There appears to be a contradiction. In the first 
 > paragraph you say that
 > > the UNA is sent on the new link, whereas in the latter 
 > case you say that
 > > plain old ND protocols are run (presumably DAD would be 
 > included). Which
 > > is it?
 > > 
 > 
 > Good point. Without PrRtAdv, the MN does not know if it has 
 > crossed the
 > PAR's subnet to NAR's. Hence, it should not send UNA.
 > 
 > I will clarify.
 > 
 > 
 > 
 > >>    The source IP address is PCoA when FBU is sent from 
 > PAR's link, and
 > >>    the source IP address is NCoA when sent from NAR's link.
 > >> 
 > >>    The FBU MUST also include the Home Address Option and the Home
 > >>    Address is PCoA.  A FBU message MUST be protected so 
 > that PAR is able
 > >>    to determine that the FBU message is sent by a genuine MN.
 > > Is the HAO included even when the source address is the PCoA?
 > > 
 > 
 > Yes, just to maintain the simplicity of operation. We 
 > _could_ state that it
 > MAY be omitted.
 > 
 > 
 > >>       `K' flag: See See [rfc3775 
 > <http://tools.ietf.org/html/rfc3775>].
 > > 
 > > 
 > > I am surprised to see K flag here. Its use does not appear to be
 > > possible, given that movements between NAR and PAR do not 
 > merely change
 > > the address of one of the participants, but the node 
 > itself changes.
 > > Sharing of key state is not recommended.
 > > 
 > 
 > It's there because it is dependent on the security protocol used to
 > establish the SA, which is specified separately.
 > 
 > You mean the routers by "node" above? If yes, the MN 
 > changing the routers is
 > similar to the MN in MIP changing the routers. The SA is 
 > still wrt to PAR
 > only. It is not shared with NAR; the MN has to establish 
 > that separately.
 > 
 >  
 > >>       6.4. Unsolicited Neighbor Advertisement (UNA)
 > >> 
 > >>    The MN sends a UNA message to the NAR, as soon as it regains
 > >>    connectivity on the new link.  Arriving or buffered 
 > packets can be
 > >>    immediately forwarded.  If NAR is proxying NCoA, it creates a
 > >>    neighbor cache entry in STALE state but forwards packets as it
 > >>    determines bidirectional reachability.  If there is an entry in
 > >>    INCOMPLETE state without a link-layer address, it sets 
 > it to STALE.
 > >>    If there is no entry at all, creating an entry in 
 > STALE state is
 > >>    recommended since forwarding can immediately begin when packets
 > >>    arrive without first invoking Neighbor Solicitation 
 > and Advertisement
 > >>    (which may involve retransmission delay in the event 
 > of messages
 > >>    being lost).  During the process of creating a 
 > neighbor cache entry,
 > >>    NAR can also detect if NCoA is in use, and immediately 
 > sends a Router
 > >>    Advertisement with NAACK option in the event of collision.
 > >> 
 > >>    The combination of NCoA (present in source IP address) 
 > and the Link-
 > >>    Layer Address (present as a Target LLA) SHOULD be used 
 > to distinguish
 > >>    the MN from other nodes.
 > > 
 > > I would like to understand whether the behaviour for the 
 > router differs
 > > from that specified in RFC 2461. If not, please refer to 
 > the right RFC
 > > and make sure that the above is merely an explanation of 
 > what happens.
 > 
 > It is pretty much an explanation of what happens. However..
 > 
 > > If yes, the use of the same message as in ND may be inappropriate.
 > 
 > The recommendation above to create an entry in STALE state 
 > when there is no
 > entry at all is new. Also new is sending the RA with NAACK 
 > option when
 > necessary. 
 > 
 > 
 > >> During the process of creating a neighbor cache entry,
 > >>    NAR can also detect if NCoA is in use, and immediately 
 > sends a Router
 > >>    Advertisement with NAACK option in the event of collision.
 > > How does it detect this?
 > 
 > As it tries to insert a new entry into a linked list, it can 
 > see that an
 > entry already exists.
 > 
 > > 
 > > Also, what if a legacy IPv6 node sends a regular UNA 
 > message. How do you
 > > know this is a request to confirm the NCoA vs. merely the 
 > desire of a
 > > host to re-assert that it is at this link layer address?
 > 
 > Such a legacy UNA message will have the 'O' bit set, not cleared.
 > 
 > 
 > >> If the NAACK indicates that the Link
 > >>    Layer Address is unrecognized, the MN MUST NOT use the 
 > NCoA or the
 > >>    PCoA and SHOULD start immediately the process of 
 > acquiring different
 > >>    NCoA at the NAR.
 > > How does the router decide that a link layer address is 
 > "unrecognized"?
 > > Presumably it is never unrecognized, given that this 
 > address must have
 > > appeared in the UNA.
 > > 
 > 
 > If the LLA in UNA was from another radio link than the one 
 > to which the MN
 > (and the NAR) is currently attached to.
 > 
 > 
 > >>    The following security vulnerabilities are identified, 
 > and suggested
 > >>    solutions mentioned.
 > >>   
 > > 
 > > This section should clearly list the solutions that are 
 > mandatory to
 > > implement.
 > > 
 > 
 > So, the required document is the companion SEND-based 
 > handovers keys draft.
 > 
 > 
 > 
 > >>       If an access router can ensure that the source IP 
 > address in an
 > >>       arriving packet could only have originated from the 
 > node whose
 > >>       link-layer address is in the router's neighbor 
 > cache, then a bogus
 > >>       node cannot use a victim's IP address for malicious 
 > redirection of
 > >>       traffic.  Such an operation is recommended at least 
 > on neighbor
 > >>       discovery messages including the RtSolPr message.
 > >>   
 > > How the router ensure that the packet can only have come 
 > from the right
 > > node? Note that you can also spoof L2 addresses. Please explain.
 > > 
 > 
 > Actually, in light of the SEND handovers keys ID, this text 
 > can be deleted.
 > 
 > 
 > >>       Secure FBU, malicious or inadvertent redirection: 
 > in this case,
 > >>       the FBU is secured, but the target of binding 
 > happens to be an
 > >>       unsuspecting node either due to inadvertent 
 > operation or due to
 > >>       malicious intent.  This vulnerability can lead to a MN with
 > >>       genuine security association with its access router 
 > redirecting
 > >>       traffic to an incorrect address.
 > >>       However, the target of malicious traffic 
 > redirection is limited to
 > >>       an interface on an access router with which the PAR 
 > has a security
 > >>       association.  The PAR MUST verify that the NCoA to 
 > which PCoA is
 > >>       being bound actually belongs to NAR's prefix.  In 
 > order to do
 > >>       this, HI and HAck message exchanges are to be used. 
 >  When NAR
 > >>       accepts NCoA in HI (with Code = 0), it proxies NCoA 
 > so that any
 > >>       arriving packets are not sent on the link until the 
 > MN attaches
 > >>       and announces itself through UNA.  So, any inadvertent or
 > >>       malicious redirection to a host is avoided.  It is 
 > still possible
 > >>       to jam NAR's buffer with redirected traffic.  
 > However, since NAR's
 > >>       handover state corresponding to NCoA has a finite 
 > (and short)
 > >>       lifetime corresponding to a small multiple of 
 > anticipated handover
 > >>       latency, the extent of this vulnerability is arguably small.
 > >>   
 > > I have a hard time understanding what is being said here. 
 > Do you mean
 > > the vulnerability where a host redirects its own traffic 
 > to a victim? Or
 > > a host redirecting victim's traffic to itself or some third party?
 > > 
 > 
 > It's the host redirecting its own traffic to a victim 
 > (Secure FBU, malicious
 > or inadvertent rediretion).
 > 
 > 
 > 
 > >>       Sending FBU from NAR's link: a malicious node may 
 > send FBU from
 > >>       NAR's link providing an unsuspecting node's address 
 > as NCoA.  This
 > >>       is similar to base Mobile IP where the MN can 
 > provide some other
 > >>       node's IP address as its CoA to its Home Agent.  As 
 > in base Mobile
 > >>       IP, the extent of such a misdelivery can be controlled and
 > >>       recovery is possible.  In addition, it is possible 
 > to isolate the
 > >>       MN if it continues to misbehave.
 > >>   
 > > 
 > > But Mobile IPv6 has mechanisms (care of address test) to 
 > deal with this.
 > > What mechanisms does FMIP have for this?
 > > 
 > 
 > CoA Test is not done with the HA.
 > You could consider the PAR as MN's temporary HA.
 > 
 > 
 > >>    compromised, the MN's RtSolPr message may be answered 
 > by an attacker
 > >>    that provides a rogue router as the resolution.  
 > Should the MN attach
 > >>    to such a rogue router, its communication can be compromised.
 > >>    Similarly, a network-initiated PrRtAdv message (see Section 3.3
 > >> 
 > <http://tools.ietf.org/html/draft-ietf-mipshop-fmipv6-rfc4068
 > bis-03#section-3
 > >> .3>) from
 > >>    an attacker could cause a MN to handover to a rogue 
 > router.  Where
 > >>    these weaknesses are a concern, a solution such as 
 > Secure Neighbor
 > >>    Discovery (SEND) [rfc3971 
 > <http://tools.ietf.org/html/rfc3971>] SHOULD be
 > >> considered.
 > > But this specification does not provide details to do so. I would
 > > suggest describing the rules to be used for securing the 
 > new ND messages
 > > with SEND, here. Assuming it is not in the companion 
 > document yet...
 > > 
 > 
 > It does not because it inherits the weaknesses of ND. I think any
 > specification on how to secure them using SEND belongs to 
 > the companion
 > document.
 > 
 > 
 > 
 > >>   The HI and HAck messages between the access routers need to be
 > >>    secured using a pre-existing security association 
 > between the access
 > >>    routers to ensure at least message integrity and 
 > authentication, and
 > >>    should also include encryption.  For this, IPsec ESP [rfc2406
 > >> <http://tools.ietf.org/html/rfc2406>]
 > >>    authentication MUST be used and IPsec ESP encryption 
 > SHOULD be used.
 > > Some words about the expected configuration would be 
 > needed here. E.g.,
 > > policies set to protecting all ICMPv6 type XXX messages 
 > between specific
 > > pairs of routers.
 > > 
 > 
 > See my comment (way) above.
 > 
 > 
 > > Editorial:
 > > 
 > >>    Mobile IPv6 [rfc3775 
 > <http://tools.ietf.org/html/rfc3775>] describes the
 > >> protocol operations for a mobile
 > >>    node to maintain connectivity to the Internet during 
 > its handover
 > >>    from one access router to another.  These operations 
 > involve movement
 > >>    detection, IP address configuration, and location update.
 > > 
 > > This presents an IP layer centric view of the situation. 
 > In reality,
 > > link layer signaling is also a significant factor in how 
 > efficiently
 > > handover can be performed. Suggested rewrite:
 > > 
 > >    Mobile IPv6 [rfc3775 
 > <http://tools.ietf.org/html/rfc3775>] describes the
 > > protocol operations for a mobile
 > >    node to maintain connectivity to the Internet during 
 > its handover
 > >    from one access router to another.  These operations 
 > involve link layer
 > >    procedures, movement detection at IP layer, IP address 
 > configuration,
 > >    and location update.
 > > 
 > 
 > Okay.
 > 
 > 
 > > 
 > >>    The ability to immediately send packets from a new subnet link
 > >>    depends on the "IP connectivity" latency, which in 
 > turn depends on
 > >>    the movement detection latency and the new CoA 
 > configuration latency.
 > >>   
 > > As above.
 > > 
 > >>       3. starts a DAD probe for NCoA.  See [rfc2462
 > >> <http://tools.ietf.org/html/rfc2462>].
 > > References need updating to the new RFCs. Applies to the 
 > ND RFCs as well
 > > as IPsec RFCs.
 > > 
 > 
 > Okay.
 > 
 > 
 > >>    can be up to RTSOLPR|RETRIES, but MUST use an 
 > exponential backoff in
 > > 
 > > I see a bar, not underscore in the name. Is this what was intended?
 > > 
 > 
 > Ah, typo.
 > 
 > 
 > > 
 > >>       When the Option-Code field in the New Access Point 
 > LLA option is
 > >>       7, it means that the NAR does not support fast 
 > handover.  The MN
 > >>       MUST stop fast handover protocol operations.  No 
 > other options are
 > >>       required in this case.
 > >> 
 > >>       A Proxy Router Advertisement with Code 3 means that 
 > new router
 > >>       information is present only for a subset of access points
 > >>       requested.  The Option-Code field values (defined 
 > above including
 > >>       a value of 1) distinguish different outcomes for 
 > individual access
 > >>       points.
 > > The second paragraph and onwards should not have the same 
 > indentation.
 > > 
 > >>    to determine that the FBU message is sent by a genuine MN.
 > > "genuine" may not be the right term. s/a genuine MN/the MN that
 > > legitimately holds the given IP address/.
 > > 
 > 
 > Okay.
 > 
 > Thanks,
 > 
 > -Rajeev
 > -- 
 > http://people.nokia.net/~rajeev
 > 
 > 
 > 
 > >> 
 > >>     Appendix C. Change Log
 > >> 
 > > Differences to RFC 4068 list would be useful.
 > > 
 > > Jari
 > > 
 > 
 > 
 > 
 > 
 > 
 > 
 > _______________________________________________
 > Mipshop mailing list
 > Mipshop at ietf.org
 > https://www1.ietf.org/mailman/listinfo/mipshop
 > 




_______________________________________________
Mipshop mailing list
Mipshop at ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop