Subject: [Mip6] Re: NAT, heartbeats and app interruptions (was: When behind NAT...)

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 02 May 2006 14:26:24 +0200

Hi Henrik, thanks for the reply.  If there's interest I'll try to split
the discussion into simplest topics.

Henrik Levkowetz wrote:
>> Do you think a DS-MIPv6 section about "Assumptions on NAT for NAT 
>> Traversal for DS-MIPv6" would be appropriate?  Know that I'm not 
>> trying to have my name in the draft.  Anybody can write it.  Should
>>  at least contain "This draft assumes that the NAT leaves open the
>>  DS-MIPv6 port number [TBD]".
> 
> No.  That's not even a NAT functionality you're talking about, it's a
>  firewall functionality.

I think you're right.  That port left open is firewall functionality in
common thinking.

But then how about a section with assumptions more precisely on NAT, not
firewalling.  For example:

"The NAT functionality assumed by this document is the following.  A NAT
  box translates IPv4 private address space into one (or more) IPv4
  public addresses.  NAT receives a packet from MN addressed to its HA,
  hashes it into a unique id, saves state keyed by this id, changes
  the source address into its IP public address and finally forwards to
  HA.  Then NAT receives a response packet from HA, hashes it into the
  same unique id, searches its set of states to find out the private IP
  address of MN, substitutes the dst address with the private address,
  and forwards to MN."

Do we have the same high-level understanding of NAT working this way?

If yes, then there are NATs who when they receive a UDP packet from MN
will change the src port number too (not only the src IP address).  Do
we agree on the existence of such NATs?

If yes, then there are NATs who will keep the mentioned state active for
about 5 minutes.  After the 5 minutes they will change again the src
port number and will save a different state (even if heartbeating every
1s).  Do we agree? (the reason why NAT forces to change this src port
number may be because there are only 65535 available and active users
are more than that).

If yes, there may be a UDPv6 application on HA streaming packets to MN.
  This app only sends UDPv6 packets to MN for one hour, during which time
MN does not send any UDPv6 app messaging to HA.  Do we agree that (in
absence of tunnel heartbeat) the packet stream from HA to MN will be
interrupted after 5 minutes, until MN sends a packet to HA?

If yes, and if we add tunnel maintenance in the picture, do we agree
that that UDPv6 streaming application may be stopped at worst until next
heartbeat is sent by MN (the 120seconds figure was mentioned)?

Alex

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 02 May 2006 14:48:36 +0200

Henrik Levkowetz wrote:
> Hi,
> 
> on 2006-04-29 01:23 Alexandru Petrescu said the following:

> "The keepalive is every second RA and ping from both directions" is
> very far from what's described in 3519.

Well, 3519 says it should be a UDP-encapsulated icmp echo request,
right?  So that's what I was doing.  Ping encapsulated in the UDP
tunnel.  Using RA is indeed not specified.  I've tried RA in UDPv4
because I thought that NAT forces tunnel change because NAT would
consider ICMP as tunnel keepalive, and assumed NAT knows nothing about
IPv6/ICMPv6.  So in my tests while the 1s ping runs there are also 1s
RAs from [GW], hoping state would not change, but it does.

Also, 3519 says that MN should send keepalive if there's no ongoing udp
app packets for K seconds.  But this comes down to the same problem when
NAT changes state even if keepalive running.  Unless that K seconds is
in the order of milliseconds, the app streaming from [GW] to MN may
suffer interruptions.  No?

Do you think one can choose an appropriate K such that the NAT will keep
state unchanged (don't change src port number)?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 02 May 2006 15:28:03 +0200

Henrik Levkowetz wrote:

> When the MN acquires an IPv4 address in an IPv4-only network and uses
>  that as a MIPv6 CoA, there is **no** IPv6 CoA involved anywhere.

Ok, if there is an RA on the UDP tunnel and MN has an EUI-64 and
auto-configures an address, is it abnormal to call it an IPv6 CoA?

If HA uses the IPv6 address MN uses on its UDP tunnel interface as a
MIPv6 CoA, I think the terminology is right.

I suggest we call the MN's IPv6 v4-mapped private IPv4 address a
"DS-MIPv6 IPv4 CoA".  I.e. a definition section entry saying "DS-MIPv6
CoA can be: an IPv6 CoA, an IPv4-mapped IPv6 address, etc".

>>>> The fact that DS-MIPv6 requires MN to support IPv4 Home 
>>>> Addresses, but does not permit MN to have a real IPv6 CoA when 
>>>> behind NAT is none of my faults either.
>>> No, but understanding the basics of the mechanism is, I believe, 
>>> your responsibiltiy.
>> Henrik, the WG can't impose some users what the WG thinks the user
>>  needs.  If an IPv6 user on some IPv6 MN is behind a NAT needs an 
>> IPv6 address to run his/her IPv6 application, the WG can't tell 
>> him/her "no no, use an v4-mapped CoA, it's better".
> 
> An application on a MN running MIPv6 sees the MN's IPv6 home address,
>  (HoA) and shouldn't care whether MIPv6 uses an IPv4 CoA to transport
>  the app's IPv6 traffic to the HA.

That is right, with DS-MIPv6 as drafted.

> It now seems to me (and I'm saying this because it's just what it 
> here seems like, no other reason) that you're saying 'CoA' when you 
> are referring to the address the applications see.  But that is the 
> MN's HoA, nothing else.

I see, there may have been some confusion on my part.  Let me try to
clarify.

The v6 address MN configures on its UDP tunnel interface may be a Home
Address when the MN is connected behind NAT most of the time.  In this
case, if the MN temporarily (i.e. less time) attaches to an IPv6 access
network it will configure a CoA on its true not virtual UDP interface.

If on the other hand, if the MN is mostly connected to WiFi on an IPv6
access network it will use that as a MIPv6 Home Address, and the one on
the UDP tunnel interface as a CoA.

Thirdly, if the MN is always connected to v4 access (never on v6
access), the IPv6 address on one UDP tunnel is the HoA and the other
tunnel is the CoA.

Thinking out all possible access possibilities, the IPv6 address on the
UDP tunnel interface can either be HoA or CoA, no restriction.

>>>> Ok, but can MIPv6 MN (3775, 3776) still support an IPv6 Care-of
>>>>  Address for this Mobile Node when MN behind NAT, over the UDP 
>>>> "tunnel" interface?
>>> Oh, I'm sure we could arrange for that, but there is no reason 
>>> to, I believe.
>> Why not?  Having a real IPv6 address on the MN is a godsend for 
>> pure IPv6 applications and pure IPv6 DNS.  I won't ask you why you 
>> think there's no reason because I don't want to troll.
> 
> Because the apps use the IPv6 HoA provided by MIPv6!

Completely agree, I was wrong to write "apps".

But I think RR and 3776 (not the apps) may be very tighly bound to IPv6
being a 128-bit IPv6 address (not a v4-mapped which is inherently
link-local).

>>>> How does HA know to whom to send traffic it intercepts for MN's
>>>>  HoA when the CoA is NAT's public address and there's no port 
>>>> number saved?
>>> The statement that there's no port number used is incorrect.
>> Currently the port numbers aren't in the binding cache.
> 
> I don't care where you put them in your implementation.  They have to
>  be known and remembered.

I partly agree.  NAT, and the way DS-MIPv6 stores and checks
private/public addresses and the port numbers has potential security
issues, depending how IKE is being used.  Maybe we'll look at that later.

> ???  If the MN is in an IPv4 only network, that seems a bit weird. 
> Are you proposing that we set up a 6to4 tunnel so we can get a MIPv6
>  address which we can use as a CoA?

No, not on the 6to4 tunnel, but on the UDP tunnel.  I don't see any
difference anyways.  My implementation has it on the UDP tunnel and I
can put it on the 6to4 IPv6-in-IPv4 tunnel too (except that the 6to4
Gateways I use don't send RAs on these tunnels).

> That approach has been discussed, but has much higher overhead than 
> the current proposal. See 
> http://tools.ietf.org/html/draft-larsson-v6ops-mip-scenarios-01

Ok, if you think it is useful we can discuss that draft's results
separately.  Overhead of having an IPv6 CoA on the UDP tunnel interface
is 0 (on v6-in-v4 too).  Contrary to what that draft states, there's no
need of 6to4 on the entire home network, but only on a unique Gateway,
but separated from the HA.

>>>> And finally, what do you guys have against MN having a real 
>>>> IPv6 CoA when behind NAT?  What would that break?  Wouldn't 
>>>> software reusability be good?  3775, 3776 and bootstrapping 
>>>> work work unmodified.
>>> If you want that functionality, define an extension for it.  I 
>>> don't see any reason to fake an IPv6 CoA when the active CoA is 
>>> IPv4.
>> It's not a "fake IPv6" CoA.  It's a real IPv6 address.  It's 
>> publicly routable on the entire IPv6 Internet.  It's distributed to
>>  it from the real IPv6 prefix advertised to it by the HA (that I 
>> currently call GW).
> 
> Seems to me you're talking about the HoA, then.  The whole purpose of
>  the current draft is to provide an IPv6 HoA by means of MIPv6. But 
> if you insist on calling the HA by the name of 'GW', and calling the
>  HoA by the name of 'CoA'

Right.  The IPv6 address configured on the UDP tunnel interface could be
either a HoA (if MN mostly on same NATed access) or a CoA otherwise.
That IPv6 address can play any role, HoA or CoA.

About HA and GW: I think it is useful to separate the HA doing MIP6 from
the GW doing NAT traversal and other v6-v4 translation.  For several
reasons, but we can discuss separately.

Alex

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 02 May 2006 16:39:38 +0200

Hi Alexandru,

This is my last message to you.  See the comments inside.  This is too
much of a drain on my time, to no benefit I can see.

> auto-configures an address, is it abnormal to call it an IPv6 CoA?

Yes.

> MIPv6 CoA, I think the terminology is right.

No.

> CoA can be: an IPv6 CoA, an IPv4-mapped IPv6 address, etc".

The concept of a MIP CoA is very clear and simple.  Don't enforce
your own past complications in understanding on others, please.

> the UDP tunnel interface as a CoA.

No.  Now you're calling a potential IPv6 CoA by the name 'MIPv6 Home Address'.
That's also incorrect.

> access), the IPv6 address on one UDP tunnel is the HoA and the other

No, this still seems confused to me.  MIP provides the HoA to the applications,
and does this by using a locally assigned/configured CoA (or multiple CoAs).

> UDP tunnel interface can either be HoA or CoA, no restriction.

If you're talking about the MIP tunnel, the answer is: Nope, not at all.
It is the HoA, which isn't the CoA.

> being a 128-bit IPv6 address (not a v4-mapped which is inherently

The v4traversal draft does not aim at providing route optimization
when using an IPv4 CoA, so although what you say seems correct, it's
not relevant.

> issues, depending how IKE is being used.  Maybe we'll look at that later.

I don't think you have more security issues that those clearly described
in the security considerations of 3519.

> separately.

No, I'm not about to dive into that.  That's another rathole as far
as the current draft is concerned.

>  Overhead of having an IPv6 CoA on the UDP tunnel interface

Nope, the IPv6 address provided by MIP on the MIP 'tunnel interface'
is never called the CoA.

> That IPv6 address can play any role, HoA or CoA.

No.  It is the HoA.

> reasons, but we can discuss separately.

No.  See the beginning of the message.

	Henrik