1. RFC 4068bis draft-ietf-mipshop-fmipv6-rfc4068bis-01.txt Rajeev Koodli

2. Revisions to FMIPv6 Since July 2005, –Input from multiple implementations –Lot of discussion (archives, tracker) –Work on companion protocols to secure FBU/FBack signaling Update on all the issues resolved Tracker: mip4.org/issues/tracker/mipshop

3. Issue 19: Description of IPv6 address in section 6.4.1 "IPv6 Address: The IP address for the unit defined by the Type field.” "IPv6 Address: The IP address defined by the Option-code field."

4. Issue 20: Text about wildcard for New AP LLA in Section 6.1.1 "New Access Point Link-Layer Address.. This field can also be a wildcard address with all bits set to zero.” "New Access Point Link-Layer Address.. This field can also be a wildcard address. See LLA Option in Section 6.4.3"

5. Issue 21: Revise MH-LLA Option in Section 6.4.4 Remove Pad0. Include Option-Code in Length field calculation along the lines of rfc3775 Length field definition. No alignment requirement. Done

6. Issue 22: Clarify LLA Length in LLA Option The LLA Option in Section 6.4.3 does not have the length field for the LLA itself. How do implementations determine the LLA size based only on the Length field for the LLA option? The LLA option format is similar to the format used in RFC 2461. Implementations should consult the specific link layer over which this protocol is run in order to determine the content and length of the LLA.

7. Issue 23: Clarify Lifetime field usage in Section 6.3.1 Old: Lifetime See RFC 3775 New: Lifetime The requested time in seconds for which the sender wishes to have a binding

8. Issue 5: Usage clauses for HI and HAck Currently, the HI and HAck messages are "MUST be supported and SHOULD be used".This may not be appropriate for all scenarios. SUGGESTION: Specify the usage scenarios for HI and HAck in a separate section and specify the clauses accordingly. HI and HAck are recommended (i.e., SHOULD) Some uses: –allowance for providing a duplicate-free address from NAR –signaling for handover-specific buffering – other uses (Context Transfer)

9. Issue 12: Add a new code value in Section 6.2.2 Currently, there is no code value in HAck to reflect the case when NAR rejects NCoA but agrees to support PCoA. There is some text that describes this however. Add a new code value “5: Handover accepted, use PCoA”. Add text: "When PAR receives a HAck message with Code 5, it establishes a tunnel to NAR in order to forward packets arriving for PCoA"

10. Issue 17: Clarify text in Section 4 on HI processing Section 4: “.. The NAR MAY use the link-layer address to verify if a corresponding IP address exists in its forwarding tables." 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.

11. Issue 7: Role of FNA Proposal is to remove FNA all-together and let ND address resolution and reachability algorithms to forward packets. Deprecated. Instead, "Unsolicited NA with 'O'=0" (UNA) is required.

12. Issue 14: Normative clause for using NCoA supplied in NAACK If the MN receives a Router Advertisement with a NAACK option, it MUST use the IP address,.. From Sec 6.4.5 (page 36) of the spec, "The MN SHOULD use.. Revise the clause to SHOULD.

13. Issue 15: Tunnel between PAR - NAR Current spec has an option for the access routers to set up a tunnel between them if NAR cannot support NCoA for whatever reason. The issue is whether to continue to keep this as an option. Keep as an option.

14. Issue 18: Sending FBack in reactive mode Add: "The PAR MAY send FBack immediately in the reactive mode" after "The Fast Binding Acknowledgment message SHOULD NOT be sent to the MN before the PAR receives a HAck message from the NAR."

15. Issue 16: PAR buffering packets Background: Based on the earlier discussion in the ML, buffering provision at PAR was specified as an option (MAY) when PrRtSol is processed. This would allow to reduce packet loss in case the MN leaves with sending FBU from PAR's link. Draft does not forbid PAR buffering. Precautions to be taken if implementations chose to have PAR buffering (FIFO buffer and forward) are outlined

16. Issue 6: Should the specification specify a particular stateful address assignment mechanism? Should the FMIP specification define _how_ the NAR is able to provide NCoA for a MN to use? Or, merely define transport Define transport. Do not specify the mechanism itself

17. Issue 9: Verify changes to REACHABLE state Verify with IPv6 WG if the ND state for NCoA can be set directly to REACHABLE,which is considered as an option. There is no requirement (or option) to set the state to REACHABLE in the draft anymore.