ICMPv6 Update

1
ICMPv6 Update

• IETF58 Minneapolis
• November 2003
• Bob Hinden

2
BACKGROUND

• RFC2463 published as Draft Standard in December
  1998
• W.G. produced update to recycle at Draft
  Standard ltdraft-ietf-ipngwg-icmp-v3-02.txtgt
• Submitted to IESG for Draft Standard
• Comments received from AD
• Current effort is to resolve issues and have
  update published

3
CHANGES FROM RFC2463

• Corrected typos in section 2.4, where references
  to sub-bullet e.2 were supposed to be references
  to e.3.
• Added token-bucket method as an example
  rate-limiting mechanism for ICMP error messages,
  and changed default value for the fixed timer
  approach, parameter T, from 1 second to 0.5
  second.
• Added specification that all ICMP error messages
  shall have exactly 32 bits of type-specific data,
  so that receivers can reliably find the embedded
  invoking packet even when they don't recognize
  the ICMP message Type.
• In the description of Destination Unreachable
  messages, Code 3, added rule prohibiting
  forwarding of packets back onto point-to- point
  links from which they were received, if their
  destination addresses belong to the link itself
  ("anti-ping-ponging" rule).
• Added description of Time Exceeded Code 1
  (fragment reassembly timeout).
• Added "beyond scope of source address" message to
  the family of "unreachable destination" type ICMP
  error messages (section 3.1).
• Added a NOTE in section 2.4, that specifies ICMP
  message processing rules precedence.
• Added ICMP REDIRECT to the list in Section 2.4 e)
  of cases in which ICMP error messages are not to
  be generated.
• Made minor editorial changes in Section 2.3 on
  checksum calculation, and in Section 5.2.
• Clarified in section 4.2, regarding the Echo
  Reply Message, that the source address of an Echo
  Reply to an anycast Echo Request should be a
  unicast address, as in the case of multicast.

4
AD COMMENTS

• Rate Limiting
• Security Considerations
• Needs IANA Considerations Section
• Editorial
• Abstract needs to be improved
• Separate normative and informative references
• Add text that this document replaces RFC2463

5
RATE LIMITING
gt Rate limiting gt gt The limit parameters
(e.g., T or F in the above examples) MUST gt be
configurable for the node, with a conservative
default value gt (e.g., T 0.5 second, NOT 0
seconds, or F 2 percent, NOT 100 gt percent).

• Current default suggestions are too high (e.g.,
  T.5 seconds, F2)
• Change to lower values with some discussion of
  the issues, or remove timer setting and only
  specify percentages of the link.
• Keep current text or revise?
• Suggestion to change timer text to use token
  bucket?

6
SECURITY CONSIDERATIONS

• Needs updating. Hasnt changed since RFC2463.
  Examples
• ESP can be used for authentication only now
• Assumption that IPSEC solves all security
  problems isnt correct. For example How does a
  node know that a SA is authorized to speak on
  behalf of a particular IP Address?
• Overstates value of checksum when AH/ESP is used
• Conclusion
• Security Considerations needs to be updated.

7
NEEDS IANA CONSIDERATIONS

• Need to provide guidance to IANA on how new
  message types and values should be assigned
• Suggest using RFC2780 (section 7) as a starting
  point
• Recommend
• New message types and values assigned by IETF
  action
• Include several code points for experimentation