[strongSwan] Query reg UDP encapsulation for IPv6

[Mukesh Yadav]

Hi Ryan,

Definitely NAT is not needed in case of IPv6 tunnel end-points.
But RFC 5996 doesn't clearly say something about it.
Also there mentioned a use-case in RFC-5996 where firewalls might have been
configured for only UDP(port based) traffic to by-pass.
In that case peer might be using UDP-encapsulation for IPv6 tunnel even if
NATT is not detected..

Thanks
Mukesh

On 15 April 2015 at 19:45, Ruel, Ryan <rruel at akamai.com> wrote:

>  Mukesh,
>
>  I believe the idea is that for IPv6, NAT will not be needed (that's the
> beauty of having so much address space!).
>
>  Technically, sure, you could NAT IPv6.  But why?
>
>  /Ryan
>
>   From: Mukesh Yadav <write2mukesh84 at gmail.com>
> Date: Wednesday, April 15, 2015 at 9:56 AM
> To: "users at lists.strongswan.org" <users at lists.strongswan.org>
> Subject: [strongSwan] Query reg UDP encapsulation for IPv6
>
>   HI,
>
>  My question is more towards IKEv2 standard rather strongswan explicitly.
> UDP encasulation is used for NATT traversal in IPsec for both ESP/IKE.
>
>  RFC 5996, says even if NATT is not detection sending IKE/ESP on 4500 is
> optional but receiving should be handled.
> RFC 5666 reference:
> *"When either side is using port 4500, sending ESP with UDP encapsulation
> is*
> *   not required, but understanding received UDP-encapsulated ESP packets
> is required"*
>
>  Having said that this all fine for IPv4, but for IPv6 is it possible
> that NATT is not detection and still IKE/ESP exchanges are done on port
> 4500 as UDP encapsulated.
>
>  One reference from RFC I can is below which says that IKE/ESP can always
> be on port 4500 even if NAT not detected, but not clear whether same is
> applicable for IPv6 as well.
> *" IKEv2 will use UDP encapsulation of IKE and ESP packets. This encoding
> is slightly less*
> *   efficient but is easier for NATs to process.  In addition, firewalls*
> *   may be configured to pass UDP-encapsulated IPsec traffic but not
> plain, unencapsulated ESP/AH or vice versa."*
>
>  Any opinion or suggestion for same will appreciated.
>
>  Thanks
> Mukesh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20150415/d1974710/attachment.html>