RFC%204068bis%20draft-ietf-mipshop-fmipv6-rfc4068bis-01.txt

1
RFC 4068bisdraft-ietf-mipshop-fmipv6-rfc4068bis-0
1.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.