IPv6%20Node%20Requirements - PowerPoint PPT Presentation

About This Presentation
Title:

IPv6%20Node%20Requirements

Description:

draft-ietf-ipv6-node-requirements-07.txt. 35 Editorial TOC Closed ... It is RECOMMENDED that IPv6 nodes conform to the requirements in this document. ... – PowerPoint PPT presentation

Number of Views:29
Avg rating:3.0/5.0
Slides: 5
Provided by: JohnLo58
Learn more at: https://www.ietf.org
Category:

less

Transcript and Presenter's Notes

Title: IPv6%20Node%20Requirements


1
IPv6 Node Requirements
  • IETF 59
  • Tuesday March 2, 2004
  • Seoul, South Korea
  • IPv6 Node Requirements
  • http//www.ietf.org/internet-drafts/draft-ietf-ipv
    6-node-requirements-08.txt
  • John Loughney (editor)

2
Issue List
  • draft-ietf-ipv6-node-requirements-07.txt
  • 35 Editorial TOC Closed
  • 33 Editorial Path MTU -gt SHOULD Closed
  • 36 Technical MIB issues Closed
  • 34 Technical Security issues Closed
  • 32 Editorial editorial nits Closed
  • 37 Technical EDNS0 support Rejected

3
Fix Path MTU -gt SHOULD
  • Steve Bellovin
  • I'm astonished that Path MTU is a MAY -- I had
    thought it was a MUST. I'd really like some more
    text explaining what some of the many exceptions
    are that are alluded to here.
  • RFC 2460 states
  • It is strongly recommended that IPv6 nodes
    implement Path MTU Discovery RFC-1981, in order
    to discover and take advantage of path MTUs
    greater than 1280 octets. However, a minimal
    IPv6 implementation (e.g., in a boot ROM) may
    simply restrict itself to sending packets no
    larger than 1280 octets, and omit implementation
    of Path MTU Discovery.
  • Node Req. text now is
  • Path MTU Discovery RFC-1981 SHOULD be
    supported, though minimal implementations MAY
    choose to not support it and avoid large packets.
    The rules in RFC 2460 MUST be followed for packet
    fragmentation and reassembly.

4
Security issues
  • Security AD comments
  • The crypto algorithm requirements should be
    better aligned with recommendations from the
    IPsec wg. There's a draft that lists 3DES as
    SHOULD, not MAY.
  • I think that IKEv? should be a SHOULD, not a MAY.
    While the IESG hasn't yet seen
    draft-bellovin-mandate-keymgmt, it will soon and
    it describes automated key management as a
    "strong SHOULD". That's certainly the consensus
    in the security area.
  • Added the following text to Section 8.3
  • In addition to the above requirements,
    "Cryptographic Algorithm Implementation
    Requirements For ESP And AH" CRYPTREQ contains
    the current set of mandatory to implement
    algorithms for ESP and AH as well as specifying
    algorithms that should be implemented because
    they may be promoted to mandatory at some future
    time. It is RECOMMENDED that IPv6 nodes conform
    to the requirements in this document.
  • And the following text to Section 8.4
  • "Cryptographic Algorithms for use in the Internet
    Key Exchange Version 2" IKEv2ALGO defines the
    current set of mandatory to implement algorithms
    for use of IKEv2 as well as specifying algorithms
    that should be implemented because they made be
    promoted to mandatory at some future time. It is
    RECOMMENDED that IPv6 nodes implementing IKEv2
    conform to the requirements in this document.
Write a Comment
User Comments (0)
About PowerShow.com