Re: issue 3: nat traversal

I agree. The conclusion is that

- we need to support MOBIKE in a NAT traversal situation
- we need to support MOBIKE moving in and out of a NAT
   traversal situation
- NAT prevention can be provided by MOBIKE if people
   want to put that in (but that seems to be outside the
   original scope of this issue)

However, I believe part of the reason for the original
issue was the "how" part -- the above addresses only
the "what" part. I guess one of the questions going
forward is whether people think draft-eronen-mobike-mopo-01.txt
and draft-dupont-ikev2-addrmgmt-06.txt provide a sufficient
coverage of the "what" part and a sufficient answer to the
"how" part.

--Jari

Tschofenig Hannes wrote:
> hi all, 
> 
> let us try to close the nat traversal issue (issue 3) from 
> http://www.vpnc.org/ietf-mobike/issue3.txt
> 
> here is what we currently have: 
> 
> - charter says that we should not modify the ikev2 nat traversal mechanism.
> none of the proposal tries to todo that. 
> - draft <draft-eronen-mobike-simple-00.txt> addresses nat traversal. 
> - draft <draft-eronen-mobike-mopo-01.txt> and
> <draft-dupont-ikev2-addrmgmt-06.txt> additionally add a mechanism to
> indicate nat traversal prevention.
> 
> a number of people pointed to the need to support nat traversal. 
> 
> hence, i think that we could have support for
> - nat traversal and
> - a nat traversal prevention (if you think you don't need it)
> without conflicting with the charter.  
> 
> to address the scenarios there also needs to support for an end host moving
> from not-behind a nat to behind a nat.  
> 
> ciao
> hannes
>  
> 
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
> 
>