1 / 13

RFC 4068bis

RFC 4068bis. draft-koodli-mipshop-rfc4068bis-00.txt Rajeev Koodli. Background. RFC 4068 is Fast Handovers for Mobile IPv6 Being revised towards a Proposed Standard At least two publicly available implementations fmipv6.org Tarzan Issue tracker: mipv4.org Discuss the issues.

kirkk
Télécharger la présentation

RFC 4068bis

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. RFC 4068bis draft-koodli-mipshop-rfc4068bis-00.txt Rajeev Koodli

  2. Background • RFC 4068 is Fast Handovers for Mobile IPv6 • Being revised towards a Proposed Standard • At least two publicly available implementations • fmipv6.org • Tarzan • Issue tracker: mipv4.org • Discuss the issues

  3. Issue 8: Correct the sentence in paragraph 4, section 3.1 • Spec currently reads: "To reduce the Binding Update latency, the protocol specifies a tunnel between the Previous CoA (PCoA) and the NCoA." • Change to: "To reduce the Binding Update latency, the protocol specifies a binding between the Previous CoA (PCoA) and the NCoA." • Revised

  4. Issue 11: Clarify text in step 3, page 12 • Currently, the text says "MAY create a host route entry for PCoA in case NCoA cannot be accepted or assigned." • Proposed text: "MAY create a host route entry for PCoA (on the interface to which the MN is attaching to) in case NCoA cannot be accepted or assigned." • Revised

  5. 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. • Proposal: 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" • added code, text revised in Section 6.2.2

  6. 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 messages which can carry the NCoA, but does not specify the mechanism used by NAR to obtain a (duplicate-free) NCoA?

  7. Issue 7: Role of FNA • FNA is used to announce attachment to NAR. Before NAR creates a NCE in REACHABLE state, it also looks for any possible overwrites. • Proposal is to remove FNA all-together and let ND address resolution and reachability algorithms to forward packets. • We need to state that sending an unsolicited Neighbor Advertisement is required. The implementation input suggests that setting the entry to REACHABLE should be available as an option. The implementation input suggests that kernel changes, except for IPv6, Neighbor Discovery, MIP6 are not desirable from a distribution of the code perspective (some implementations may do kernel changes anyway).

  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. • The spec should also clarify the role of HI/HAck in address duplicate handling, if any.

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

  10. Issue 10: SPI in FBU • Given that the FBU needs to be secured, there is a need for a handover key between the MN and PAR. Derivation of handover keys is addressed by other drafts. However, without an SPI in the FBU, the handover key must be tied to the CoA of the MN. It will be a lot cleaner if there was a way for the MN to include an SPI in the FBU sent to the PAR, so that the AR can use that to look up the SA.

  11. Issue 13: redundant tunnels in FMIPv6? • Withdrawn (Rejected)

  12. 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.

  13. 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.

More Related