| Newsgroups |
gmane.ietf.mobike |
| Message-ID |
<[email protected]> |
I agree with your proposals. As some people have expressed
that they have no interest in NAT-T, I think it's important
to also have (k): if you implement NAT-T, MOBIKE works with
that, but implementing MOBIKE does not force you to do NAT-T
if you don't want.
Best regards,
Pasi
> -----Original Message-----
> From: Jari Arkko
> Sent: Friday, May 13, 2005 1:05 PM
> To: MOBIKE Mailing List
> Subject: [Mobike] issue 3 - nats
>
<snip>
>
> Here are also some tentative answers to the questions:
>
> (a) Can we move behind a NAT?
> [Yes. But requires NAT-D payloads in the address change
> message, as discussed under issue 11.]
> (b) Can we move out from a NAT?
> [Yes. Does not require much. But see item h.]
> (c) To which extent do we support the case that
> party outside the NAT moves?
> [No. This one is really hard. We will make our life much
> simpler by saying no here. Outsider may not be able to
> initiate anything inside. The only exception is covered under
> item f.]
> (d) If we are behind a NAT, can peer have multiple
> addresses?
> [Yes. Contrary to mobility, multihoming is possible
> quite easily. Detailed protocol design has some further
> details that need to be developed later, e.g., is there
> a need to do keepalives on all address pairs? Tentatively,
> the answer to that is no.]
> (e) If we are behind a NAT on one interface, can
> another interface work without NAT/NAT-T?
> [Yes.]
> (f) Can the responder be behind a NAT?
> [Yes, but in a very limited scenario, when the NAT is
> a static NAT and not a NAPT.]
> (g) Do we need NAT prevention?
> [Yes.]
> (h) Do we want to disable UDP encapsulation when moving outside
> from behind a NAT?
> [Yes.]
> (i) Send keepalives on current or on all paths?
> [To be decided later.]
> (j) How do we detect NATs?
> [Using NAT-T functionality.]
> (k) Is NAT-T support still optional within MOBIKE?
> [Yes. You should be able to use MOBIKE in plain v6
> environments, for instance.]
>
> --Jari