Re: Seeking clarity on IPv6 IPsec AH requirement ... pending IPsec draft changes AH requirement to "MAY" from "MUST" ...

I believe the IPsec specifications take precedence here.
Note that the 2401 and AH are also referenced from
draft-ietf-ipv6-node-requirements (currently in RFC Ed
queue). A "bis" version of that RFC-to-be should also
reference the new specs. (Its too late to change now
because the IPsec specs are, I think, still in the WG process
and it might take some time before they can be normatively
referenced without delays.)

--Jari

John Spence, CCSI, CCNA, CISSP wrote:

>Looking at "draft-ietf-ipsec-rfc2401bis-05.txt" (Security Architecture for
>the Internet Protocol), I noticed the "pending confusion" shown below.  The
>IPv6 Specification suggests that both AH and ESP are requirements for full
>IPsec support, and the draft slated to replace the overarching IPsec
>Specification makes it clear that IPsec AH is optional.
>
>We'll need to clarify somewhere if IPv6 is requiring a higher standard than
>the future IPsec Spec, or if the IPsec Spec takes precedence, and a full
>IPv6 IPsec implementation will also consider AH "optional".
>
>My belief is that the IPsec Spec rules here, and IPv6 should only require
>IPsec "as described in the IPsec Spec of record".  Today there is no
>conflict, but there will be when the IPsec draft goes RFC. 
>
>-------------- start --------------------
>
>3.2 How IPsec Works
>
><snip>
>
> IPsec implementations MUST support ESP and MAY
>   support AH. (Support for AH has been downgraded to MAY because
>   experience has shown that there are very few contexts in which ESP
>   cannot provide the requisite security services. 
>
><snip>
>---------------- end ------------------
>
>Looking at RFC 2460, I see this:
>
>-------------- start --------------------
>
>4.  IPv6 Extension Headers
>
><snip>
>
>   A full implementation of IPv6 includes implementation of the
>   following extension headers:
>
>           Hop-by-Hop Options
>           Routing (Type 0)
>           Fragment
>           Destination Options
>           Authentication
>           Encapsulating Security Payload
>
>   The first four are specified in this document; the last two are
>   specified in [RFC-2402] and [RFC-2406], respectively.
>
><snip>
>---------------- end ------------------
>
>----------------------------------------------------
>John Spence, CCSI, CCNA, CISSP
>Native6, Inc.
>IPv6 Training and Consulting
>jspence@native6.com
>www.native6.com
>----------------------------------------------------
>
>
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>ipv6@ietf.org
>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------
>
>  
>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------